Catching the Angler | TechSNAP 235

chris

7 years ago

Debug mode exposes sensitive data, Cisco’s Talos group exposes the Angler exploit kit & how a Microsoft exposed Conficker with an egg hunt.

Plus some great feedback, a huge round up & much, much more!

Thanks to:

Get Paid to Write for DigitalOcean

Direct Download:

RSS Feeds:

Become a supporter on Patreon:

— Show Notes: —

Danish bank leaves production server in debug mode, exposes sensitive data

While at Chaos Communication Camp, the Dutch researcher was talking with some Danish hackers about the security of Danish banks, especially their terrible HTTPS settings that result in an F from Qualys SSL Labs
Upon arriving back home, he opened up the bank’s website, and decided to look at the HTML of the page
On it, he found a giant URL encoded javascript comment
Upon decoding it, he was that it leaked a huge amount of information, some of it sensitive
It returned session cookie id, the entire contents of the cookie submitted by the user, and a bunch of other cookies.
It also revealed that the site was written in Microsoft ASP, shows the path to the files on the web server, the internal IP addresses
Worse, while looking at the data, he realized that the data was not infact his, but belonged to the session of another user
“If I refreshed the login screen again, I would get to see a different set of data, from another customer. I repeated that a few times and got back different records each time.”
He also noticed that the server port was 80, and HTTPS was “off”, this suggests it is a normal web server without TLS, with some kind of SSL Terminator appliance in front of it. It would be best practise to use TLS on the internal network as well, else a sysadmin, or someone who manages to compromise the web application, could snoop usernames and passwords as they passed between the terminator and the web servers.
The researcher resisted the urge to add the cookie he had just seem go by to his own browser and login as some unsuspecting customer
It seems likely that if viewing this same dump from a page that involved an HTTP POST, it would have included plain text username and password
“The variables HTTP_SOPDB2MEMBER, HTTP_SOPQMGR and HTTP_SOPFECICS indicate that their Microsoft IIS server is connecting to a z/OS server that runs a DB2 database, message queue software and CICS. That’s a pretty normal (but old!) software stack for a bank. Probably also means they’re still using COBOL code on their backend.”
He then tried to report the issue
“Easier said than done. They don’t have a responsible disclosure process in place, so there was no e-mail address I could mail my findings to. I called a phone number on their web site and the lady that I spoke didn’t seem to understand the problem and said: “our technical guy will look at your finding”. I asked for her e-mail address so I could mail the details to her but she said that wasn’t possible. I didn’t get the feeling I was taken seriously, so I started looking on LinkedIn for IT security personnel that worked at the bank.”
“Found someone that worked in the security incident response department and mailed him my findings. That worked! I saw that within 24 hours the vulnerability was patched.”
The response from the bank: “Thank you for reporting a potential security vulnerability on our website. We investigated your report immediately. However, the data you saw was not real customer sessions or data – just some debug information. Our developers corrected this later that day.”
“A potential vulnerability? Are you serious? The server was leaking all kinds of highly technical data. And what about using not real customer data? Is it suggested that Danske Bank is using test customer data in their production environment? That would be against all safety guards and all best practices. And creating test cookie data in production in combination with an IP address and user agent? Never seen that one before.”
“For at least two weeks, but probably a lot longer, very confidential customer data in the form of session cookies were leaking on Danske Bank’s web site. With these cookies it should have been possible to hijack internet banking accounts of their customers. They closed the security hole quickly, but are now in denial of it.”
“Update October 8: Because of all publicity this story gets, Danske Bank now admits that their production server was in debug mode and that I saw information and cookies from other visitors (!). That’s quite a turn! Seems that media attention forces the bank to be honest. They still hold on that I couldn’t hijack banking sessions.”
Researcher’s Blog

Cisco Talos tackles the Angler exploit kit

Angler is one of the largest exploit kit found on the market and has been making news as it has been linked to several high profile malvertising/ransomware campaigns.
In its research, Cisco determined that an inordinate number of proxy servers used by Angler were located on servers of service provider Limestone Networks with the primary threat actor responsible for up to 50 percent of Angler Exploit Kit activity, targeting up to 90,000 victims a day, and generating more than $30M annually.
The Talos organization gained additional visibility into the global activity of the network through their ongoing collaboration with Level 3 Threat Research Labs.
Thanks to their continued collaboration with OpenDNS they were able to gain in depth visibility into the domain activity associated with the adversaries.
The dataset was originally from July 2015 and included data from all sources available. July provided a unique opportunity because Angler went through several iterations of development, including URL structure changes and implementation of several unpatched Adobe Flash vulnerabilities. During the analysis, trends and patterns emerged. This paper will discuss trends in hosting, domain usage, referers, exploits, and payloads. It was the trends associated with the hosting that lead to the most significant discoveries.
While analyzing the data they found that a large amount of Angler activity was focused with a single hosting provider, Limestone Networks. Talos collaborated with Limestone to gather some previously unknown insight into Angler. This includes details related to data flow, management, and scale.
Angler is actually constructed in a proxy/server configuration. There is a single exploit server that is responsible for serving the malicious activity through multiple proxy servers.
Additionally, there is a health monitoring server that is conducting health checks, gathering information about the hosts that are being served exploits, and remotely erase the log files once they have been fetched. This health server revealed the scope and scale of the campaign, and helped allow us to put a monetary value on the activity.
A single health server was seen monitoring 147 proxy servers over the span of a month and generating in excess of $3,000,000 USD in revenue.
Despite not having a large footprint, Angler is able to compromise a significant amount of users, for a presumably small amount of customers. An interesting aspect is the lack of IP variety from day to day. Angler starts with an IP address (i.e. 74.63.217.218) as the system compromises users and generates noise the adversaries shift to an adjacent IP (i.e. 74.63.217.219).
This activity would continue through contiguous blocks of IP space being used from a single provider. Indicating that the actors likely had multiple servers available moving from one server to the next as they were blocked.
Looking at the amount of unique IP’s, while it is still clear that Hetzner and Limestone Networks were the primary sources of Angler, Limestone Networks was the largest single provider.
Talos approached both Hetzner and Limestone related to the information we gathered on these threat actors. Limestone Networks responded and cooperated fully with this investigation.
For example one Talos account purchased 815 servers during the course of a week using stolen credit cards originating from different countries. This would continue gradually allowing the users to accumulate a fair amount of server infrastructure. Eventually the credit cards would be identified as stolen and significant costs are incurred. According to Limestone Networks our adversaries “contributed approximately $10,000 in cost and lost revenue each month.” The vast majority of this in charge backs due to fraudulent credit card charges.
Limestone Networks was also able to provide Talos with copies of images of the servers that were being used as well as network captures of the communications the servers were conducting for short time periods. As a result of this Talos was able to get valuable information that exposed previously undisclosed aspects of Angler, as well as the scope of the users impacted.
Users do not just browse to an exploit kit they are pushed into it there via malicious iFrames and malvertising. Both were found in significant volume during the course of the month. Talos observed popular websites redirecting users to the Angler exploit kit via malvertising including hundreds of major news, real estate, and popular culture sites.
Additionally, Talos noticed a couple of smaller volume referer chains that were being used, either as a way to directly get users to Angler or just add a layer to the redirection chain. The first was the use of dynamic DNS services.
A similar type of service has also been observed gaining volume recently. It also made use of an additional tier of redirection using shadowed domains.
These were almost exclusively javascript files that are hosted under englishword based sub folders
A huge variety of different browsers and operating systems hit Angler landing pages (including Netscape 4.0 which was a bit surprising, but not all of those users were served exploits). Overwhelmingly the most common browsers to be served actual exploits were Internet Explorer and the reasons we believe are two fold. First is that Angler leveraged CVE-2014-6332 heavily for the last six months and continues to do so (Angler also recently added CVE-2015-2419 also targeting IE), this exploit is targeted specifically at Internet Explorer users. The second is that the other major web browsers, Chrome and Firefox, have gone to great lengths to either sandbox Adobe Flash or prevent any flash rendering with outdated versions. Firefox even went so far as to block all Flash activity when the Hacking Team 0days (CVE-2015-5119, CVE-2015-5122) were disclosed to prevent its users from being impacted.
Talos has observed both Cryptowall 3.0 as well as Teslacrypt 2.0 being delivered by Angler during this time period. Both ransomware variants leverage compromised wordpress sites to push data for later retrieval.
Not surprisingly the overwhelming majority of the exploits Angler was serving were tied to Adobe Flash. Almost 75% of the exploits served to users were Adobe Flash related.
One of the biggest reasons that Angler has been so pervasive and able to infect as many users is the lack of antivirus coverage. During the month of July Talos observed almost 3,000 unique hashes associated with exploits. That data was then queried against VirusTotal which found that only 6% of the hashes were in VirusTotal. Of that 6% the average detection was low, with usually less than ten AV engines detecting it. This, coupled with the recent large scale malvertising campaign, reinforces that a user browsing the internet using Internet Explorer with only basic antivirus protection is highly vulnerable to an Angler infection.
Additional Coverage: TheStack

The story of MS08-067, the 2008

This is the story of a zero-day exploit against all versions of Windows that came to light in 2008
“The attackers had a remote code execution (RCE) vulnerability that affected every version of Windows, gave them full control at SYSTEM level rights, left almost no forensic footprint, and could be used anonymously from anywhere on the Internet. Their exploit was 95% reliable. Almost perfect. Almost.”
“To understand MS08-067 you need to understand MS07-029, an RCE vulnerability in Windows DNS. MS07-029 was one of a series of Remote Procedure Call (RPC) server vulnerabilities that were steadily being ferreted out by Microsoft, attackers, and security researchers alike. There was one difference. MS07-029 was the first RCE that where we had our Visual Studio return address protection (/GS) and Windows Data Execute Prevention (DEP) in effect. We refer to these defenses as exploit mitigations and we had been steadily adding them since XP SP2. It was one of the ways we were using security engineering to combat security issues in engineering. Once an exploit has trashed the internal memory of a process, there is no recovery and the only option is to force a crash—a terrible user experience for sure, but better than resulting in a compromised machine.”
“By September 2008 we had built a system that screened millions of crashes for security exploits. Along the way I felt like I joined the world’s smallest profession—that of an exploit failure engineer. On September 25th a crash came in that got my attention–an exploit in netapi32.dll. This new crash was in very similar code, but in a different WER bucket. It was not in the top 100 or top 1,000 issues. It was bucket #45,000 with exactly 2 hits ever. This was living in the tail. ”
“What made this tiny bucket stand out? First, there was an exploit. It found shellcode in the crash dump. I reviewed the shellcode and saw that it used an egghunt to find the payload. An egghunt is an exploit engineering technique used when a buffer overrun is constrained in terms of how much payload can be sent.”
“The second thing unusual about this crash dump was not just the way it failed. It was the way it was succeeding before it crashed. I looked beyond the crashing thread to the other threads in the process. One of them revealed the attacker had already exploited the process and the shellcode was in the middle of downloading a payload using URLDownloadToFileA!”
“While egghunts weren’t new, this was a new flavor of shellcode for netapi32 exploits and clear evidence of a successful exploit. The final nail in the coffin was the version information in the crash dump. Netapi32.dll was fully patched! There seemed to be only one explanation for this: a new 0-day in the wild. “
“Most of the time security researchers find a vulnerability then work to write an exploit. I was going in reverse: examining an exploit to determine the vulnerability, armed with only a forensic crash and no way to reproduce it. Had the exploit blown away the crucial clues in the buffer overrun itself? I studied the crash over and over. I looked at the source code for netapi32. Vulnerabilities are often obvious in hindsight but stubborn to reveal themselves at first. Here was my dilemma: if I could not find the vulnerability, despite having a clear exploit, we could not act.”
“I brought the case to the manager of the MSRC security engineers, Andrew Roths. I remember the moment Andrew stopped by my office. He said, “I found a vulnerability.””
“We walked down the hallway to the office of the crisis manager, Phillip. He was in the middle of a meeting with someone in his office. There must have been something about the expression on our faces because he turned to his visitor and abruptly said, “I’ll talk with you later”. We entered and I said, “we have a zero day.” We explained the basic facts. We had a vulnerability, that could be exploited remotely, anonymously, that affected all versions of Windows. It was wormable and someone was already exploiting it. When you say the word ‘wormable’ to a crisis manager, it activates some latent response DNA. In his quiet way he went from 1 to 11 and immediately got to work mobilizing everyone. Scarred by Code Red and Blaster, when an issue is wormable, at Microsoft everyone shows up and works it as job #1.”
“On Windows Vista and Windows Server 2008 it always failed. The Security Development Lifecycle (SDL) process at Microsoft made sure those OS editions had full ASLR and DEP for the svchost.exe”
“Their solution for this was to first call the vulnerable function with a benign input that had the slash character but would not trigger the vulnerability. This data would stay latent on the stack, like a ghost, the next time the function was called. This technique was perfectly reliable if Windows used the same thread for both requests. This happened nearly all the time. Nearly. In a quirk of fate, the Windows RPC thread pool handed the second request containing the exploit to a different thread—one that did not have the carefully placed slash character. The netapi32 code kept searching for it, eventually running off the end of the thread stack, hitting the guard page, and crashing the process with a stack overflow error (0xC00000fd).”
“Once MSRC was ready with the patch, we made the decision to ship it as an out-of-band update. Every patch release starts the clock in terms of copycat exploits. This is the one of those dilemmas in the MSRC business. Naturally you want to ship an update as soon as it’s ready. But when you ship an out-of-band update, many IT teams aren’t ready and this slows down how quickly systems are updated. Attackers don’t hesitate to download the patch, diff it, and start building exploits, and defenders caught on their back foot may be at a disadvantage as they scramble to rearrange their schedule to deploy the update. We considered. Can you hold until Patch Tuesday when IT teams around the world are ready to receive and act? Or do you ship early and disrupt customers? The answer was clear. We had a critical vulnerability. We saw an uptick in activity. The patch was ready. We went out-of-band.”
“Ask anyone about MS08-067 and most will mention Conficker. At this point in October, Conficker did not even exist. Conficker, as disruptive as it was, affected only the tail of computers that had not patched. Imagine what would have happened if Conficker had half a billion more systems to infect.”