Sunday, September 17, 2017

ComTech: Do's and Don'ts in production environment pentest

Hello everyone
After a short break, ComTech is back.

Today's post will talk about something that is relevant to every pentest, the do's and the don'ts of pentesting a production environments.
Let's start:
  • Don't use or use a little as possible automated scanners.
    In application PT - use non, do all manual. In infrastructure PT - use only the most needed ones. The automated scanners that should be avoided include vulnerability scanners (Nessus, OpenVas in infra PT, Burp pro scanner, Acunetix in app PT).
  • Perform as much of the test manually.
  • Especially don't use any tools in OT environment (industrial control system, SCADA). These environments are especially sensitive, and a simple port scan might crash them altogether. 
  • If you do need to use tools in infra PT, make sure you mark the "safe checks" checkbox if exist (Nessus, OpenVas).
  • Don't use payloads that can cause any damange. This include innocent looking payloads such as the classic XSS and SQLI <script>alert('xss')</script> and ' or 1=1-- in app PT.
    The first might pop up a message in a production page in a persistent XSS, that would cause embarrassment to the client, and the second, if done in the wrong place, could delete all of the records in a table (if injected to a delete command), or issue a fetch command that would get all of the records and might bring the system down.
  • Always clean up after yourself, and do the best effort to delete any testing records and data, especially any data stored in a persistent storage (DB).
  • In infra PT (and also relevant to app PT) don't send a large input to a tested interface, as it might also cause the system to crash.
  • If money is involved, always ask the client for QA credit cards. Avoid using your own credit card in PTs. 
  • Don't change any configuration in an admin interface or CMS, unless explicitly permitted by the client.
  • Open and use your test emails to make sure you won't get spammed long after the test is over.
  • Don't do online login brute-force attack without permissions, as it might lockout production users.
  • If you are testing a hosted cloud-based system, always make sure you have the appropriate permissions to do so, and that the cloud provider is aware and approves it.
  • In spite of what is written above, always talk to the client and match expectations. There might be specific production environments that you could do the don'ts mentioned above.
Stay safe

Gil Cohen

Sunday, September 10, 2017

Cyber Updates - 10th September 2017

Welcome back to Cyber Updates, apologies for hiatus over the summer.

Cisco Meraki Cloud Data Loss

Cisco Meraki is a cloud based network management system. They recently experienced a loss of customer data which it appeared was not backed up and according to accounts from one customer a significant amount of manual work would be required to recreate the relevant data.

Key takeaways:

  • If you are reliant on cloud services, what happens when they are unavailable. If you have an SLA with a provider, do you offer the same SLA to your customers? Remember that you may receive compensation if SLA your provider violates the SLA but it is unlikely to be enough if the provider is business critical to you.
  • Even if you use a cloud service, some form of local or separated backup can be beneficial.

Chrome Extension Malware

The developer of a popular Chrome Extension called "Web Developer" was phished which allowed hackers access to his Google account. They used this to submit a malicious update to his extension which was then delivered to all extension users through the Chrome Extension updates mechanism. In this case it just seems to have been adware which was incorporated into the code but it could have been much more sinister.

Key takeaways:

  • Network admins should be monitoring which chrome extensions are installed and if necessary only allowing a whitelist of extensions.
  • Endpoints should always be considered at risk and monitored accordingly
  • Sensitive credentials should always be protected using Multi-factor Authentication

HTTP sites to be marked as insecure by Chrome in October

Starting in October, the Google Chrome browser will start marking HTTP sites with a red "Not secure" warning in the URL bar as a warning to users to not enter any sensitive information.

Key takeaways:

  • Any site which processes data or has login functionality should be communicating using HTTPS throughout.
  • This move should provide a marketing impetus for companies to push this ability to their sites.

HPKP considered harmful

Scott Helme, a UK based security consultant and lecturer, wrote a blog in which he declared that he had given up on the HTTP Public Key Pinning (HPKP) standard due to the difficulty in implementing it compared to the significant risks of getting it wrong. This caused quite a stir as he has been a strong supporter of secure web standards and his blog post makes for an interesting read into security tradeoffs.

Key takeaways:

  • Make sure you understand the complexity and risks of any new security standard.
  • This decision should be part of the cost benefit analysis of implementing a new security control.

Josh Grossman
Senior Information Security Consultant and Team Leader

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

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