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 “” 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

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...
net session >nul 2>&1

if %errorLevel% == 0 (
       if exist C:\Windows\perfc (
              echo Computer already vaccinated .
       ) 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.
) else (
       echo Failure: You must run this batch file as Administrator.

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: or

Sunday, June 11, 2017

ComTech: sites communication options and CORS

Hi everyone
Monday tech is dead, all hail the new king ComTech (which stands for Comsec-Tech).
Monday tech wasn't always published on Mondays so I rebranded it.

Today I'm going to discuss the different ways 2 websites\web servers are able to exchange data.
There are many different data transfer options between 2 domains:

  • Regular HTTP Post request – Site A sends a post request to site B and then the execution flow continues in site B only. No response is returned to site A.
    This is a plain regular HTTP POST, CORS does not apply here so it doesn’t really matters whether they define it or not in this scenario (if they define the CORS header with * it is an unrelated finding of course).
    This is a scenario that can be vulnerable to CSRF attacks.
    Regardless, Site B can later redirect the flow back to site A – for example when an online shop redirects the flow to PayPal and then after processing PayPal redirects the flow back.
  • Ajax HTTP POST request – Site A sends a post request to site B and then gets the response back and the execution flow continues is site A.
    This is plain Ajax XHR, that the request format is in POST request and all CORS rules applies.
    Ajax requests can be sent as GET or POST request, it doesn’t matter which one is used and the same rules are applied.
  • Iframe loading without data return – Site A loads site B in an Iframe and doesn’t need to get any information back. For example putting an Iframe of Youtube in your website where the movie loads in an Iframe. This obviously has no relation to CORS and the rules of it does not apply, as well as third party resource loading such as loading pictures or JavaScript from a third party website.
    BTW loading Javascript using a HTML script tag can be used in order to call 3rd party web services without XHR and bypassing all CORS restricions in a technique that is called JSONP, but this was used before web messaging was invented (see next) and is considered obsolete and should not be used.
  • Iframe loading with data return – Site A loads site B in an Iframe and needs to get information back. For example when ecommerce site processes the payment using a 3rd party payment platform that is loaded in an Iframe (not PayPal example above).
    In this case site B can either use plain Ajax requests to send the data back to site A, but then CORS rules applies and site A needs to approve site B in the CORS header – further configuring is needed.
    This is the scenario usually you can and need to define all of the calling domains in the CORS header, and not use *.

    Another option is that site B can send data to site A using web messaging:
    Web Messaging is the way for documents to separates browsing context to share the data without Dom. It overrides the cross domain communication problem in different domains, protocols or ports.
    For example you want to send the data from your page to ad container which is placed at iframe or voice-versa, in this scenario,Browser throws a security exception. With web messaging we can pass the data across as a message event”.
    AKA Iframe communication directly with no web service calls at all.
    This solves Iframe and loading site communication being blocked by CORS.

    PCI DSS standard defines Iframe loading or full website redirection using regular HTTP Post requests and full execution flow redirection (and then redirection back later on) as the recommended way to process and load 3rd party payment platforms.

Thursday, June 1, 2017

Cyber Updates - 1st June 2016

Breach at Identity Provider

Cloud based identity management provider OneLogin reported a breach. Early indications are that it was bad with customers being requested to recycle OAuth tokens, API keys, certificates, credentials, etc. They have previously released detailed “post-mortem” explanations so hopefully they will do so again. It is noteworthy that OneLogin have an extensive and detailed explanation of their security and compliance regime on their site.

Key takeaways:
  • Breaches will happen even with the best controls - make sure you have a plan for when a breach occurs at your own company or at a key supplier.
  • This is especially important for a supplier like OneLogin which provide a centralised identity management platform which could literally hold "the keys to the kingdom" for its customers.
  • When engaging with a supplier like this, make sure you have performed a risk analysis and assessed their security controls and procedures to help inform your own internal breach planning.

This week's cool hack

A bug bounty hunter called Peter Adkins was able to take a Server-side Request Forgery (SSRF) attack where the attacker can make the application make an HTTP request to an arbitrary endpoint and escalate it to achieve Remote Code Execution (RCE) on the target server. He write a nice writeup found here.

Key takeaways:
  • This was possible due to mis-configuration in an "off the shelf" product, Hashicorp Consul. Make sure you are securely configuring all products in the environment, even those which are not externally exposed.
  • Periodic reminder that several vulnerabilities which seem to be low risk could be chained to create a higher risk so it is important to consider vulnerabilities together.

More exploits to be dumped

We have previously covered the release of live and dangerous exploits by TheShadowBrokers. In a new post, they have claimed they will start releasing exploits on a monthly basis to paying "subscribers".

Key takeaways:
  • Whilst this didn't happen last time, be ready for the possibility of dangerous exploits targeting unpatched vulnerabilities.
  • Companies should be ready to install critical patches but also be ready to mitigate unpatched vulnerabilities through other protective or detective controls.
  • Company's planning should include all devices which could be active in their technology ecosystem including mobile devices and "Internet of Things" devices.

Windows SMB: "Well that was a bad few weeks!", Samba: "Hold my beer!"

Details were released this week of a nasty Remote Code Execution vulnerability in Samba (the Linux re-implementation of SMB/CIFS) and proof of concept exploit code has been released. Guardicore have a nice write-up of the issue. There is no link to the recent Windows SMB vulnerabilities aside from the timing.

Key takeaways:
  • Patch your Linux machines or use the workaround 
  • Same as the previous section :)

Josh Grossman
Senior Information Security Consultant and Team Leader