Curl Sleeper Agent | TechSNAP 266

chris

6 years ago

Zero-day exploits striking over 100 systems, if you think copying links to bash scripts from the internet is okay, maybe you shouldn’t be root & the day Google automated itself off the internet.

Plus your questions, our answers, a huge round up & more!

Thanks to:

Get Paid to Write for DigitalOcean

Direct Download:

RSS Feeds:

Become a supporter on Patreon:

Show Notes:

Zero-day exploits against Microsoft used against PoS systems of over 100 companies

“More than 100 North American companies were attacked by crooks exploiting a Windows zero day vulnerability. The attacks began in early March and involved the zero day vulnerability CVE-2016-0167 reported and partially fixed in April’s Patch Tuesday security bulletins by Microsoft. The zero day was found by researchers at FireEye, who on Tuesday disclosed details.”
“The kernel-mode driver in Microsoft Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, and Windows 10 Gold and 1511 allows local users to gain privileges via a crafted application, aka “Win32k Elevation of Privilege Vulnerability””
“FireEye said the flaw is a local elevation of privilege flaw in the win32k Windows Graphics subsystem. Attackers are able to exploit the flaw once they are able to remotely execute code on the targeted PC. Microsoft patched the vulnerability on April 12 and released a subsequent update (MS16-062) this week”
“In March 2016, a financially motivated threat actor launched several tailored spear phishing campaigns primarily targeting the retail, restaurant, and hospitality industries. The emails contained variations of Microsoft Word documents with embedded macros that, when enabled, downloaded and executed a malicious downloader that we refer to as PUNCHBUGGY.”
“PUNCHBUGGY is a dynamic-link library (DLL) downloader, existing in both 32-bit and 64-bit versions, that can obtain additional code over HTTPS. This downloader was used by the threat actor to interact with compromised systems and move laterally across victim environments.”
“In some victim environments, the threat actor exploited a previously unknown elevation of privilege (EoP) vulnerability in Microsoft Windows to selectively gain SYSTEM privileges on a limited number of compromised machines”
“This actor has conducted operations on a large scale and at a rapid pace, displaying a level of operational awareness and ability to adapt their operations on the fly. These abilities, combined with targeted usage of an EoP exploit and the reconnaissance required to individually tailor phishing emails to victims, potentially speaks to the threat actors’ operational maturity and sophistication”
“Security experts say, as more U.S. companies snuff out point of sale malware by deploying chip-and-PIN bank card technology, attackers are rushing to exploit existing magnetic strip card systems still vulnerable to malware. FireEye, for example, reported last month that that a group of hackers that go by the name Bears Inc. are behind the latest barrage of attacks with a custom-built point of sale malware called Treasurehunt. This latest zero day vulnerability follows the same trend.”
I would argue that chip&pin does not make the PoS terminal any less vulnerable to malware
While it does make it harder to clone cards, it think it should not be viewed as a solution to malware
FireEye Report

If you think doing curl|bash is ok, you shouldn’t have root

“Installing software by piping from curl to bash is obviously a bad idea and a knowledgeable user will most likely check the content first. So wouldn’t it be great if a malicious payload would only render when piped to bash?”
So, we all know it is bad, some some people do it anyway. They tell themselves it is alright because they check the contents of the script before they run it
That only works if what you end up downloading is the same as what you actually reviewed
“Luckily the behaviour of curl (and wget) changes subtly when piped into bash. This allows an attacker to present two different versions of their script depending on the context :)”
“It’s not that the HTTP requests from curl when piped to bash look any different than those piped to stdout, in fact for all intents and purposes they are identical”
“Execution in bash is performed line by line and so the speed that bash can ingest data is limited by the speed of execution of the script. This means if we return a sleep at the start of our script the TCP send stream will pause while we wait for the sleep to execute. This pause can be detected and used to render different content streams.”
“Unfortunately it’s not just a simple case of wrapping a socket.send(“sleep 10”) in a timer and waiting for a send call to block. The send and receive TCP streams in linux are buffered on a per socket basis, so we have to fill up these buffers before the call to send data will block. We know the buffer is full when the receiving client to replies to a packet with the Window Size flag set to 0”
“The only character you can really use to fill the buffer is a null byte as it won’t render in most consoles. It also won’t render in chrome when the charset text/html is specified. As we don’t know the content-length data is transferred with chunked encoding with each chunk being a string of null bytes same size as the TCP send buffer.”
So, the attacker sends chunks of null bytes until all of the buffers on the client side are full, because bash is sleeping and not reading any more data yet
So the attacker just has to see if you are piping the content to bash, or to your terminal or browser. Only in the case of bash do they send the “payload”
There is a nice demo included in the article

Post Mortem: When google automated itself off the internet

“On Monday, 11 April, 2016, Google Compute Engine instances in all regions lost external connectivity for a total of 18 minutes, from 19:09 to 19:27 Pacific Time.”
This is the story of how automation knocked all of GCE off of the internet
“Google uses contiguous groups of internet addresses — known as IP blocks — for Google Compute Engine VMs, network load balancers, Cloud VPNs, and other services which need to communicate with users and systems outside of Google. These IP blocks are announced to the rest of the internet via the industry-standard BGP protocol, and it is these announcements which allow systems outside of Google’s network to ‘find’ GCP services regardless of which network they are on.”
“To maximize service performance, Google’s networking systems announce the same IP blocks from several different locations in our network, so that users can take the shortest available path through the internet to reach their Google service. This approach also enhances reliability; if a user is unable to reach one location announcing an IP block due to an internet failure between the user and Google, this approach will send the user to the next-closest point of announcement. This is part of the internet’s fabled ability to ‘route around’ problems, and it masks or avoids numerous localized outages every week as individual systems in the internet have temporary problems.”
Also know as “anycast”
“At 14:50 Pacific Time on April 11th, our engineers removed an unused GCE IP block from our network configuration, and instructed Google’s automated systems to propagate the new configuration across our network. By itself, this sort of change was harmless and had been performed previously without incident. However, on this occasion our network configuration management software detected an inconsistency in the newly supplied configuration. The inconsistency was triggered by a timing quirk in the IP block removal – the IP block had been removed from one configuration file, but this change had not yet propagated to a second configuration file also used in network configuration management. In attempting to resolve this inconsistency the network management software is designed to ‘fail safe’ and revert to its current configuration rather than proceeding with the new configuration. However, in this instance a previously-unseen software bug was triggered, and instead of retaining the previous known good configuration, the management software instead removed all GCE IP blocks from the new configuration and began to push this new, incomplete configuration to the network.”
“One of our core principles at Google is ‘defense in depth’, and Google’s networking systems have a number of safeguards to prevent them from propagating incorrect or invalid configurations in the event of an upstream failure or bug. These safeguards include a canary step where the configuration is deployed at a single site and that site is verified to still be working correctly, and a progressive rollout which makes changes to only a fraction of sites at a time, so that a novel failure can be caught at an early stage before it becomes widespread. In this event, the canary step correctly identified that the new configuration was unsafe. Crucially however, a second software bug in the management software did not propagate the canary step’s conclusion back to the push process, and thus the push system concluded that the new configuration was valid and began its progressive rollout.”
So, the automation software detected that the new configuration was bad, but, ignored this signal and went ahead anyway
“As the rollout progressed, those sites which had been announcing GCE IP blocks ceased to do so when they received the new configuration. The fault tolerance built into our network design worked correctly and sent GCE traffic to the the remaining sites which were still announcing GCE IP blocks.”
“With no sites left announcing GCE IP blocks, inbound traffic from the internet to GCE dropped quickly, reaching >95% loss by 19:09. Internal monitors generated dozens of alerts in the seconds after the traffic loss became visible at 19:08, and the Google engineers who had been investigating a localized failure of the asia-east1 VPN now knew that they had a widespread and serious problem. They did precisely what we train for, and decided to revert the most recent configuration changes made to the network even before knowing for sure what the problem was. This was the correct action, and the time from detection to decision to revert to the end of the outage was thus just 18 minutes.”
“With the immediate outage over, the team froze all configuration changes to the network, and worked in shifts overnight to ensure first that the systems were stable and that there was no remaining customer impact, and then to determine the root cause of the problem. By 07:00 on April 12 the team was confident that they had established the root cause as a software bug in the network configuration management software.”
Moving forward, Google will add:
Monitoring targeted GCE network paths to detect if they change or cease to function
Comparing the IP block announcements before and after a network configuration change to ensure that they are identical in size and coverage
Semantic checks for network configurations to ensure they contain specific Cloud IP blocks.
“We take all outages seriously, but we are particularly concerned with outages which affect multiple zones simultaneously because it is difficult for our customers to mitigate the effect of such outages. This incident report is both longer and more detailed than usual precisely because we consider the April 11th event so important, and we want you to understand why it happened and what we are doing about it. It is our hope that, by being transparent and providing considerable detail, we both help you to build more reliable services, and we demonstrate our ongoing commitment to offering you a reliable Google Cloud platform.”

Drama at the Internet’s malware dumping ground

VirusTotal is a popular online malware aggregation service started in 2004, and acquired by Google in 2012.
It allows researchers and users to submit malware samples which are tested against the static detection engines of some 50+ anti-virus vendors
An example analysis
However, there is concern that many “NextGen” Security startups, are just abusing the VirusTotal API rather than building their own detection engine
Worse, this type of use doesn’t contribute anything back to the community
So Google has changed the Terms of Services: “All scanning companies will now be required to integrate their detection scanner in the public VT interface, in order to be eligible to receive antivirus results as part of their VirusTotal API services”
“Additionally, new scanners joining the community will need to prove a certification and/or independent reviews from security testers according to best practices of Anti-Malware Testing Standards Organization (AMTSO)”
Traditional vendors have applauded the move:
Trend Micro
MalwareBytes
Of course, there is also a response from the other side
The AV Bomb That Never Was
Includes responses from Cylance, and SentinelOne, two of the larger “NextGen” security companies
Also has summaries from Palo Alto Networks and CrowdStrike
How this actually impacts the industry is yet to be seen, but I don’t expect much outside of a few shady startups going away, but they were going to do that anyway
Additional Coverage