Weekly infosec news summary for 2017.07.02 – 2017.07.09
M.E.Docs, NotPetya, and 4 months of breaches
Last week the malware NotPetya infected systems in Ukraine by way of the Ukrainian tax software M.E.Doc's auto-updates. The company accepted an offer from Cisco to help with incident response. Cisco wrote up what they found here. They first found a PHP web shell file, then from looking at logs, they found that the nginx server had been reconfigured to proxy update requests to a different server out of M.E.Doc's control. That other server has since been zero-wiped to remove evidence from it. The M.E.Doc's server had only been reconfigured for 3 hours for the NotPetya outbreak before it was returned to its original state. They only have logs for the past month, so it is unknown how long M.E.Doc's infrastructure had been compromised for, but there is evidence that the updates had been manipulated since at least April 14, 2017 with a backdoor. The implication of this is that any company running M.E.Doc's software had been compromised and data exfilled from it since 4 months ago. The backdoor used M.E.Doc's own server as the C2, making this extremely difficult to detect.
To touch on intelligence for a second, it is worth mentioning that by breaching M.E.Docs, the attacker collected intelligence (tax information on all companies that do business with Ukraine) of value on par with the intelligence value of the OPM and Anthem breaches. By additionally compromising all those companies, the impact of this is even more significant. Hopefully one of those companies has logs of what was done.
M.E.Docs was then raided this week by Ukrainian police in military outfits complete with automatic weapons. The video shows an apparent lack of many security controls at M.E.Docs, including no identifiable badges for the employees or badge readers on the doors, no surveillance cameras, and no cages on the servers. The Ukrainian police said they will be investigating M.E.Docs for negligence due to them knowing about their breach problem (link).
As a security team, what can you do to avoid being compromised by a malicious auto-update? Proper security within networks is always important to detect and avoid internal spreading as happened with NotPetya, but detecting a malicious auto-update that beacons back to the update server for C2 is not something many are prepared for. One thing to look for is abnormal activity of an application, for example by detecting it accessing files outside of its normal scope. Ensuring security best practices of the vendor is also important via questionnaires or other attestations and auditing. The application should run with least privileges. The auto-updates should be secure, meaning they use signed updates and an inability to downgrade versions. The Docker notary project lays out those goals well. Ideally, you would also have an auditable log of updates, much like the Certificate Transparency logs used by TLS Certificate Authorities.
Speaking of malicious auto-updates, Krebs found the vending machine company Avanti was hacked (link), and according to Risk Analytics, a malicious auto-update was pushed to all of the machines (link).
- 0x4D31/honeyLambda: A simple serverless application designed to create and monitor URL honeytokens, on top of AWS Lambda and Amazon API Gateway, similar to your own hosted version of Thinkst's canary tokens.
- G Suite adds OAuth app white-listing: Following on the "Google Docs" OAuth worm from May, Google now allows admins to white-list what OAuth apps their employees can use.
- Attack on Critical Infrastructure Leverages Template Injection: Talos shows how Microsoft Office documents can be made to pull files from remote servers, allowing for credential harvesting and telemetry data from victims. This tactic is being used against US critical infrastructure.
- Github introduces code owners: A new feature of Github allows you to ensure that certain people review any updates to protected branches.
Summit Route provides AWS Security Consulting services. Email me for more information.