Angler – Jupiter Broadcasting https://www.jupiterbroadcasting.com Open Source Entertainment, on Demand. Thu, 24 Dec 2015 17:40:04 +0000 en-US hourly 1 https://wordpress.org/?v=5.5.3 https://original.jupiterbroadcasting.net/wp-content/uploads/2019/04/cropped-favicon-32x32.png Angler – Jupiter Broadcasting https://www.jupiterbroadcasting.com 32 32 Allan’s Favorite Things | TechSNAP 246 https://original.jupiterbroadcasting.net/91911/allans-favorite-things-techsnap-246/ Thu, 24 Dec 2015 09:40:04 +0000 https://original.jupiterbroadcasting.net/?p=91911 It’s a collection of Allan’s favorite moments from TechSNAP past. Plus the week’s new stories in the roundup & much more! Thanks to: Get Paid to Write for DigitalOcean Direct Download: HD Video | Mobile Video | MP3 Audio | OGG Audio | YouTube | HD Torrent | Mobile Torrent RSS Feeds: HD Video Feed […]

The post Allan's Favorite Things | TechSNAP 246 first appeared on Jupiter Broadcasting.

]]>

post thumbnail

It’s a collection of Allan’s favorite moments from TechSNAP past.

Plus the week’s new stories in the roundup & much more!

Thanks to:


DigitalOcean


Ting


iXsystems

Direct Download:

HD Video | Mobile Video | MP3 Audio | OGG Audio | YouTube | HD Torrent | Mobile Torrent

RSS Feeds:

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feed | Torrent Feed

Become a supporter on Patreon:

Patreon

— Show Notes: —

Episode 24: Ultimate RAID

  • Before be became a ZFS addict, Allan explains all of the various RAID levels and what you would use them for
  • If you are not using ZFS, you probably want to watch this
  • This episode also contains the details of the BEAST attack on SSL, back in the beginning of what would turn out to be an unending onslaught on SSL and its implementations (OpenSSL and friends)

Episode 34: Allan’s ZFS Server Build

  • Allan shows off his first ZFS server build
  • 16 TB SAS array (12 TB usable), separate 2×2 TB SATA mirrored UFS for the OS, because he didn’t trust root-on-ZFS yet
  • Paid for a RAID controller, which didn’t work well (was replaced with the onboard LSI HBA built into the motherboard)
  • Had a bunch of problems, with both Newegg, Adaptec, shipping, and configuration
  • If only I had known about iXsystems back then

Epsiode 78: Wire-Shark

  • With Chip-and-Pin finally arriving in the US, let us remember back to TechSNAP from September of 2012, when researchers at the University of Cambridge Computer Lab found a way to defraud the system
  • While the system is self is fairly secure, it relies on correct implementation, and many ATMs and PoS devices do not do it correctly
  • In this case a nounce (supposed to be a unique, unpredictable value), was just a counter or timestamp

Episode 128: Gentlemen, Start Your NGINX

  • Krebs covers crooks registering for your Social Security account, so they could redirect the direct deposits to their own account

Episode 100: 100% Uptime

  • Special in its own right, as our 100th episode
  • bit9 story
  • It was also the first time we mentioned Krebs (who I kept called Kerbs for the first few weeks until I was corrected enough times). At first I wasn’t even sure I liked Krebs, now I am quite the fan.

Episode 236: National Security Breaking Agency

  • Keylogging before computers
  • Great story from the Cold War

Round Up:


The post Allan's Favorite Things | TechSNAP 246 first appeared on Jupiter Broadcasting.

]]>
Catching the Angler | TechSNAP 235 https://original.jupiterbroadcasting.net/88851/catching-the-angler-techsnap-235/ Thu, 08 Oct 2015 18:32:06 +0000 https://original.jupiterbroadcasting.net/?p=88851 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: HD Video | Mobile Video | MP3 Audio | OGG […]

The post Catching the Angler | TechSNAP 235 first appeared on Jupiter Broadcasting.

]]>

post thumbnail

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:


DigitalOcean


Ting


iXsystems

Direct Download:

HD Video | Mobile Video | MP3 Audio | OGG Audio | YouTube | HD Torrent | Mobile Torrent

RSS Feeds:

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feed | Torrent Feed

Become a supporter on Patreon:

Foo

— 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.”

iXsystems — FreeNAS worst practices guide

Feedback:


Round up:


The post Catching the Angler | TechSNAP 235 first appeared on Jupiter Broadcasting.

]]>
Dude Where’s My Card? | TechSNAP 198 https://original.jupiterbroadcasting.net/76052/dude-wheres-my-card-techsnap-198/ Thu, 22 Jan 2015 21:16:58 +0000 https://original.jupiterbroadcasting.net/?p=76052 Adobe has a bad week, with exploits in the wild & no patch. We’ll share the details. Had your credit card stolen? We’ll tell you how. Plus the harsh reality for IT departments, a great batch of questions, our answers & much much more! Thanks to: Get Paid to Write for DigitalOcean Direct Download: HD […]

The post Dude Where's My Card? | TechSNAP 198 first appeared on Jupiter Broadcasting.

]]>

post thumbnail

Adobe has a bad week, with exploits in the wild & no patch. We’ll share the details. Had your credit card stolen? We’ll tell you how.

Plus the harsh reality for IT departments, a great batch of questions, our answers & much much more!

Thanks to:


DigitalOcean


Ting


iXsystems

Direct Download:

HD Video | Mobile Video | MP3 Audio | OGG Audio | YouTube | HD Torrent | Mobile Torrent

RSS Feeds:

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feed | Torrent Feed

Become a supporter on Patreon:

Foo

— Show Notes: —

New flash zero day found being exploited in the wild, no patch yet

  • The new exploit is being used in some versions of the Angler exploit kit (the new top dog, replacing former champ blackhole)
  • The exploit kit currently uses three different flash exploits:
  • CVE-2014-8440 – which was added to the exploit kit only 9 days after being patched
  • CVE-2015-0310 – Which was patched today
  • and a 3rd new exploit, which is still being investigated
  • Most of these exploit kits rely on reverse engineering an exploit based on the patch or proof of concept, so the exploit kits only gain the ability to inflict damage on users after the patch is available
  • However, a 0 day where the exploit kit authors are the first to receive the details, means that even at this point, researchers and Adobe are not yet sure what the flaw is that is being exploited
  • Due to a bug in the Angler exploit kit, Firefox users were not affected, but as of this morning, the bug was fixed and the Angler kit is now exploiting Firefox users as well
  • Additional Coverage – Krebs On Security
  • Additional Coverage – PCWorld
  • Additional Coverage – Malware Bytes
  • Additional Coverage – ZDNet

How was your credit card stolen

  • Krebs posts a write up to answer the question he is asked most often: “My credit card was stolen, can you help me find out how”
  • Different ways to get your card stolen, and your chance of proving it:
  • Hacked main street merchant, restaurant (low, depends on card use)
  • Processor breach (nil)
  • Hacked point-of-sale service company/vendor (low)
  • Hacked E-commerce Merchant (nil to low)
  • ATM or Gas Pump Skimmer (high)
  • Crooked employee (nil to low)
  • Lost/Stolen card (high)
  • Malware on Consumer PC (very low)
  • Physical record theft (nil to low)
  • “I hope it’s clear from the above that most consumers are unlikely to discover the true source or reason for any card fraud. It’s far more important for cardholders to keep a close eye on their statements for unauthorized charges, and to report that activity as quickly as possible.”
  • Luckily, since most consumers enjoy zero liability, they do not have to worry about trying to track down the source of the fraud
  • With the coming change to Chip-and-Pin in the US, the liability for some types of fraud will shift from the banks to the retailers, which might see some changes to the way things are done
  • Banks have a vested interest in keeping the results of their investigations secret, whereas a retailer who is the victim of fraudulent cards, may have some standing to go after the other vendor that was the source of the leak
  • Machine Learning for Fraud Detection

15% of business cloud accounts are hacked

  • Research by Netskope, a cloud analysis company, finds that only one in ten cloud apps are secure enough for enterprise use
  • In their survey, done using network probes, gateways, and other analysis techniques (rather than asking humans), they found that the average large enterprise uses over 600 cloud applications
  • Many of these applications were not designed for enterprise use, and lack features like 2 factor authentication, hierarchical access control, “group” features, etc
  • The report also found that 8% of files uploaded to cloud storage provides like Google Drive, Dropbox, Box.com etc, were in violoation of the enterprises’ own Data Loss Prevention (DLP) policies.
  • The downloading numbers were worst, 25% of all company files in cloud providers were shared with 1 or more people from outside the company. 12% of outsiders had access to more than 100 files.
  • Part of the problem is that many “cloud apps” used in the enterprise are not approved, but just individual employees using personal accounts to share files or data
  • When the cloud apps are used that lack enterprise features that allow the IT and Security teams to oversee the accounts, or when IT doesn’t even know that an unapproved app is being used, there is no hope of them being able to properly manage and secure the data
  • Management of the account life cycle: password changes, password resets, employees who leave or are terminated, revoking access to contractors when their project is finished, etc, is key
  • If an employee just makes a dropbox share, adds a few other employees, then adds an outside contractor that is working on a project, but accidently shares all files instead of only specific project files, then fails to remove that person later on, data can leak.
  • When password resets are managed by the cloud provider, rather than the internal IT/Security team, it makes it possible for an attacker to more easily use social engineering to take over an account
  • Infographic
  • Report

Feedback:


Round Up:


The post Dude Where's My Card? | TechSNAP 198 first appeared on Jupiter Broadcasting.

]]>