Monday, July 31, 2017

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

Following my #defcon25 lecture in Las vegas, "Call the plumber - you have a leak in your (named) pipe" (, here is the presentation file:

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:

Cheers :)

Gil Cohen

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

Sunday, July 2, 2017

ComTech - Preventing applications running on rooted mobile devices

(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