Thursday, August 3, 2017

Cyber Updates - 3rd August 2017

More Cryptocurrency Thefts

In the previous cyber update, we mentioned the theft of a $10m worth of Ethereum during the Coinbase ICO. Since that hack there have been (at least) 2 other serious cryptocurrency thefts. First, a vulnerability in a cryptocurrency wallet developed by Parity allowed attackers to steal $30m worth of Ethereum. Then, a few days later, another company in the middle of an Initial Coin Offering had $8.5m of their token stolen.

Key takeaways:

  • As we said previously, this is a continuing trend and should be addressed as a matter of urgency by companies in this space.

When your coffee machine infects you with ransomware

This story came from a reddit post so is not independently verified but sounds highly plausible. The author of this post effectively tells a story of how their company had Industrial Control Systems running an a separate, non-Internet connected network. They were therefore puzzled to discover that machines in this environment had been hit by ransomware. It turned out that a 3rd party supplier had installed a coffee machine which bridged the company's Internet connected and non-Internet networks so when it got infected, so did the machines in the non-connected network!

Key takeaways:


  • All networks should be monitored for unknown or unexpected devices.
  • On particularly sensitive networks, a new device should cause an alert and an investigation.
  • Any 3rd party working with the IT network should be under heavy supervision and escort.


Node.JS package typo squatting

Node.JS uses the npm package management tool to allow Node developers to make use of prebuilt libraries to perform particular functions or operations. A developer called Ivan Akulov wrote a blog post about how he discovered fake versions of popular packages which included code to send sensitive data such as API keys back to the malicious packages' developer.

Key takeaways:


  • Beware of your dependencies, make sure you are reviewing exactly which external libraries you are using.
  • Understand the importance of each dependency and how you would cope if it was suddenly removed.


OWASP Top 10 news

Following the controversy over RC1 of the OWASP Top 10 2017, OWASP published a blog post this week providing some updates from the new project leaders on the plans for the project. Anyone who is involved at all in Application Security would be advised to read the post in detail.

Key takeaways:


  • The most controversial addition, (A7 Insufficient Attack Protection) appears to have been rejected as it does not represent a vulnerability
  • AppSec professionals are being asked to provide data regarding vulnerabilities found in applications to help guide which vulnerabilities should be in the top 10.
  • AppSec professionals are also being asked to complete a future-looking survey about what newer vulnerabilities are on an upward trend and should therefore already be considered, even if they are currently less widespread.






Josh Grossman
Senior Information Security Consultant and Team Leader
joshg@comsecglobal.com

Monday, July 31, 2017

Defcon25 lecture: Call the plumber - you have a leak in your (named) pipe

Hello
Following my #defcon25 lecture in Las vegas, "Call the plumber - you have a leak in your (named) pipe" (https://www.defcon.org/html/defcon-25/dc-25-speakers.html#GCohen), here is the presentation file:
https://drive.google.com/open?id=0B3_AmubjewYTVERidTVGZW5uRnM

In addition, a similar presentation (minus some of the demos) was previously presented in the Hack in Paris 2017 conference, under the name "The forgoten interface: Windows named pipes", so it can be found here:
https://www.youtube.com/watch?v=m6zISgWPGGY&t=636s

Cheers :)



Gil Cohen
CTO
gilc@comsecglobal.com | www.comsecglobal.com

Wednesday, July 19, 2017

Cyber Updates - 19th July 2017

Coindash loses $10m in Ethereum cryptocurrency

Coindash, a company developing a Cryptocurrency tracking platform held an Initial Coin Offering this week whereby investors could pay Ethereum and receive "tokens" (like shares in the company) in return. Unfortunately, in their own words: "The moment the token sale went public, the CoinDash website was hacked and a malicious address replaced the CoinDash Token Sale address. As a result, more than 2,000 investors sent ETH to the malicious address." Indications are that a total of $10m worth of Ethereum was stolen as a result of this.

Key takeaways:

  • The CrytoCcurrency industry is in its infancy but when so much money is potentially at stake, it is vital that security is built in to all products and processes from the very start.
  • Crytocurrency theft due to cyber attack is a problem across the industry and it seems likely that potential investors will be putting companies' security under far greater scrutiny.

RCE in Cisco WebEx extension

Tavis Ormandy of Google's Project Zero discovered some vulnerabilities in Cisco's WebEx browser AddIn for Chrome and Firefox which could lead to remote code execution on a user's PC by browsing a web site.

This is not the first time that this has happened and it seems unlikely that it will be the last time.

Key takeaways:

  • Install the updated AddIn across your environment as soon as possible.
  • Consider disallowing this AddIn altogether, disallowing it for users who have no need for it or at the very least disallowing it on more sensitive workstations.


The #NotPetya/Nyetya fallout continues

It is clear that some companies are still suffering from this attack several weeks later. In particular, FedEx has indicated that its TNT operations were particularly badly hit having to return to manual processes in various areas. Similarly, shipping line Maersk was also badly hit and is still trying to restore their operations.

Key takeaways:

  • Make sure you have a comprehensive disaster recovery plan which also considers how long it will take to execute the plan.
  • Don't lose sight of the potential costs of a cyber attack and the subsequent restoration processes. Cyber-insurance may assist with this but check the small print!
  • Good communication and frequent updates (Maersk in particular are being praised for this) will be crucial for maintaining customer confidence.


Petya decryption key released

The author of the original Petya ransomware (not to be confused with the #NotPetya attack which, as the name suggests, was not actually Petya) which hit computers over a year ago has released the master decryption key for files. It seems highly unlikely that anyone still has data around encrypted by this which they have not replaced

Key takeaways:






Josh Grossman
Senior Information Security Consultant and Team Leader

Tuesday, July 11, 2017

ComTech - Fat\Thick client MiTM proxy interception for PT

Hello everyone
We all know how to intercept a request in a web application - simply activate your proxy, Fiddler or Burp suite and redirect your proxy setting to point to it. That's it.

But what about fat\thick clients applications?
When the client obeys the internet proxy settings, life is easy. You just set the proxy identically to a web application, and that's it.
=But what happens when it does not obey these settings? This is where things are starting to be complicated.

That first and fastest option to intercept requests is using the excellent Echo Mirage utility, which intercept network calls at the operating system level, and lets you change it. But in many cases, it won't work.
Another option is to configure your proxy as a reverse proxy. A proxy utility resides at the client side, and intercepts request before they leave the client's station. Reverse proxy on the other hand, pretends to be the server, and intercept the request after they leave the user's station (in theory of course - as you can set the reverse proxy in the same computer) but before reaching the real server.
They both intercept requests, its just a matter of where do you do it.

So you need to set your proxy as a reverse proxy (in burp you can also use invisible proxy in order to try to automatically forward the request to the right server), and then set your client to address the port of the proxy, so it can intercept the requests and move them forward to the real server.

If you have a clear-text configuration file - you can just change the server address very easily. If the client sends the address to the server hostname, you can just edit your hosts file and redirect everything to your proxy.
But what happens if your client connects to an IP address and cannot be changed easily? This is the hardest option of them all. In this case you need to either still change it somehow by reverse engineering the client (or decompile-recompile it, i'll talk about it next week), or you can use several tools such as Ettercap in order to perform arp poisoning attack, edit the communication and redirect it. Not an easy task.

And what if your communcation is not even HTTP communcation? Then you need to intercept it using binary proxy utilities such as the great TCP Catcher proxy.

Have fun!



Gil Cohen
CTO

Sunday, July 2, 2017

ComTech - Preventing applications running on rooted mobile devices

https://cydia.saurik.com/icon@2x/cydia7.png

(Note that the use of the word "rooted" below includes both jailbreaking on iOS and rooting on Android unless otherwise stated)

The Mobile Security Model and Sensitive Data

The iOS and Android security models rely heavily on the fact that one application cannot access another application’s data. If an application which we are testing only stores sensitive data in its own data store then we will generally assign a lower likelihood level compared to if it stores data in a shared location to which multiple applications have access, for example the Android SD card storage.

If a user has rooted their mobile device, any application can request root access which will then provide it access to any other application’s stored data. This therefore breaks this important element of the device security model. In general, it will also provide a malicious application with much wider access to the device and could potentially be used, for example, to intercept traffic.

To block or not to block?

We therefore generally recommend that clients prevent sensitive applications from running on rooted devices. The impact of such a finding generally depends on the sensitivity of data stored locally by the application. For example, we tested a payments application that stored long lived session data on the device. In this case, the potential impact of allowing the application to be used on rooted devices was quite high.

For another example, we tested an OTP application where we observed through testing that we were unable to reproduce the one-time codes on another device even if we had access to the stored variables. As such, we assigned a relatively low impact to this finding for this application.

On the other hand, even on a non-rooted device, a sophisticated malicious application may be able to exploit private/public vulnerabilities to gain root level access and therefore achieve the same result. This is the reason that we include findings on all sensitive data stored unprotected on the device, even if it is only in the application’s own storage area.

A detection arms race.

Whilst it will be relatively straightforward to perform root detection on iOS, it is a lot harder on Android as different “rooting” methods create different file structures.

A bigger problem which clients have described to us is that certain Android devices exhibit signs of being rooted even when they are not, generally the cheaper devices from Asia. This results in regular users who have not rooted their device being unable to use the application on their device and complaining to the application developer.

The other side of that problem is that there are tools on both iOS and Android which can be used to "hide" the fact that the device is rooted so that even if an application tries to detect the root, it will be unable do so.

So what to do?

In our opinion, this comes down to a case of a company's Information Security team deciding which of the following options is most appropriate based on the assessed sensitivity of the application and the issues explained above:

  1. Attempt full root detection across iOS and Android and prevent use from devices where it is detected despite the risk of preventing legitimate users from using the application.
  2. Perform full iOS root detection and prevent use from devices where it is detected but just provide a warning/disclaimer on Android devices to avoid the false positive risk.
  3. Just provide a warning/disclaimer on all devices.


Josh Grossman
Senior Information Security Consultant and Team Leader
@JoshCGrossman
joshg@comsecglobal.com 

Thursday, June 29, 2017

Cyber Updates - 29th June 2017

Well it was a relatively quiet few weeks, until it wasn't....

Here are some of the key stories that stuck out from the last few weeks.

The #NotPetya/Nyetya worm

We have already written at length about ransomware and about this specific attack. This worm hit a number of different companies, appearing like ransomware but in practice having no effective decryption mechanism. It appears to have originated from a breached Ukrainian software house from where it was distributed as part of a forged updates file. Once it infected a machine, it spread throughout the network using both the EternalBlue exploit but also by dumping passwords and reusing them on other networked machines via psexec and wmic. This blog post gives a good overview of why this attack should be especially concerning for blue-teamers.

Key takeaways:

  • More impetus to apply the MS17-010 if somehow this has not yet been done.
  • Reportedly, the malware spread incredibly fast so detection solutions maybe not have been enough in this case. Frequent, robust and offline backups would have been crucial for recovery.
  • The malware traversed networks in the same way as manual attackers. It's important to use different local passwords on all endpoints and segment the network as much as possible.

Malware that attacks power-grids

Dragos Inc who specialise in Industrial Control System (ICS) security and ESET released a report with detailed information about malware they have observed in the wild targeting power grid networks. They have seen this malware on attacks in the United States, Europe and Ukraine.

Key takeaways:

  • If you run industrial control networks, reading this report will provide valuable information for better protecting your network.
  • Even if you are not an ICS company, it is still important to consider what similar elements may exist in your environment, e.g. smart building components.


Threats from your routers

Wikileaks have alleged that the CIA have the capability to infect routers with malware and intercept sensitive traffic. Similarly, researchers from Ben Gurion University demonstrated a technique of exfiltrating sensitive data using the LEDs on a router.

Key takeaways:

  • Whilst neither of these threats may be particularly realistic for most company's threat models, it is important to consider the risk from all devices in the technology environment.
  • This is especially important in the "Internet of Things(IoT) age" where so many regular items have computers inside.


From weak password to RCE

This week’s nice hack is documented at the “pentest.blog” blog. The author found an external facing messaging server with a weak password and then reverse engineered the product to find a vulnerability which led to remote code execution.

Key takeaways:

  • Ensure that as little as possible is externally exposed. Consider mitigating controls where this is necessary.
  • Make sure external services in particular are kept up to date.
  • Make sure your security planning includes the “0 day” scenario




Josh Grossman
Senior Information Security Consultant and Team Leader
@JoshCGrossman
joshg@comsecglobal.com

Wednesday, June 28, 2017

Petya / Nyetya; A new ransomware attack hit the world

What is it?

It wasn’t long since the massive WannaCry ransomware hit the cyber-world, and starting from yesterday, Tuesday June 27tha massive new attack of the ransomware variant has been identified, affecting organizations around the globe (wired article).

This ransomware is a new version Petya, also known as NotPetya (as it is a variant that borrows code from Petya but it’s different) and has other different names as Petrwarp, Nyetra, SortaPetya and Petna.

The attack first took place in Ukraine and started spreading quickly throughout the world. It is reported by Kaspersky that more than 2000 organizations globally are infected, including Maersk, Rosneft, and many others. The result of the attack is a large scale power-down of sites and services around the globe, with a major effect on daily business and logistics.

Why is it so dangerous?

This ransomware is more aggressive compared to WannaCry, as it encrypts the MFT (Master File Tree) tables for NTFS partitions and overwrites the MBR (Master Boot Record) with a custom bootloader that shows a ransom note and prevents victims from booting their computer. It’s also forcefully reboots systems and prevents them from working altogether.

This ransomware also contains advanced propagation techniques that makes it more dangerous than any ransomware before.

Why can the attack spread so fast?

After infecting a single machine the ransomware then propagates using several techniques, one of them is in a similar fashion as WannaCry; through exploitation EternalBlue.

Another propagation technique includes stealing of credentials and exploiting users’ permissions and using legitimate methods of connecting to other hosts.

This what makes the current ransomware more dangerous compared to WannaCry that uses only the EternalBlue exploit, as credentials harvesting results in very fast lateral movement. It spreads like an oil spill with a logarithmic character.

If only 1 computer is infected in the network and this computer stores login credentials of a network administrator, the entire network is compromised.

Technically speaking, the ransomware uses PsExec, WMI and SMB connections via ADMIN$ in order to propagate in the LAN.

It then tries to forcefully reboot the system and also creates a scheduled task to reboot the infected system one hour after the initial infection. The full encryption happens when the system reboots. It is not 100% clear if no encryption happens prior to the reboot.

Where does it come from?

At this point there are no clear indicators where the attack comes from. With information currently available, it is suggested that Petya was deployed onto potentially several millions of computers by hacking Ukrainian accounting software called “MeDoc”. It then used their automatic update feature to download the malware onto all computers using the software. 

Although MeDoc being the initial infection vector is unconfirmed (andeven denied by the company itself), current evidence points to them (source1source2source3).

Who are or can be affected?

It appears a Windows only variant so far. So Windows users are at risk.
Multiple large enterprises are hit: Maersk, TNT, and several Ukrainian entities are amongst them.
Any other Windows-based organization can be hit as well.

How can we protect our company?

We in Comsec recommend the following recommendations, prevention and mitigation measures:

  • It is recommended to make all employees aware of this event to make sure suspicious emails are not opened and any suspicious email or activity is reported to the relevant IT personnel. 
  • Obtain and patch systems to the latest version using the manufacturer security update, as it is likely to believe that Petya is actively exploiting known vulnerabilities inside networks. (TechNet Article)
  • For unsupported or unpatched systems, it is recommended to isolate them from the network and to consider shutting them down if possible. Alternatively, Microsoft released a security update for the SMB vulnerability also for Windows platforms that are in custom support only, including Windows XP, Windows 8, and Windows Server 2003 (Technet Article. The system update is available here: KB4012598 
  • Disable SMBv1 in all unpatched machines, and in all machines where it does not impact their business purpose.
  • Isolate communication UDP ports 137 and 138 as well as TCP ports 139 and 445 in networks to avoid spreading or infection.
  • Update all AntiVirus and AntiMalware products signatures
  • Make sure all the organization’s critical data is backed up both in online and offline backup storage.
  • If possible, block the ADMIN$ share in the network. The worm uses this share with WMI to spread itself, thus disallowing access prevents the possible spread.
  • If you are infected, do not pay the 300$ asked ransom fee. The e-mail address referred to is no longer in service. The decryption key will not be received when you pay the fee.
  • The malware tries to reboot immediately and then again after 30-60 minutes. If infection is identified (pretends to be a windows CheckDisk scan) shut down the infected machine immediately.
  • In the recent hours it was found that a vaccine is available to prevent infection of a host. Create 3 read-only files named perfc, perfc.dll and perfc.dat in C:\Windows. This can be done by using the following script file (rename to vaccine.bat and execute in the entire domain using the GPO). It has to be noted that the vaccin works only if the executed / inject dll matches the exact name 'perfc'

@echo off

echo Administrative permissions required. Detecting permissions...
echo.
             
net session >nul 2>&1

if %errorLevel% == 0 (
       if exist C:\Windows\perfc (
              echo Computer already vaccinated .
              echo.
       ) else (
              echo Vaccination file. > C:\Windows\perfc
                echo Vaccination file. > C:\Windows\perfc.dll
                echo Vaccination file. > C:\Windows\perfc.dat

              attrib +R C:\Windows\perfc
                attrib +R C:\Windows\perfc.dll
                attrib +R C:\Windows\perfc.dat

              echo Computer vaccinated.
              echo.
       )
) else (
       echo Failure: You must run this batch file as Administrator.
)
 
pause


We can help you, just ask!

Comsec is constantly tracking the recent developments in the world and we update our blog accordingly. We are ready to assist with any questions or requests that you may have.


For further questions or help, please contact: timt@comsecglobal.com or gilc@comsecglobal.com