Troubling Security Issues Highlighted at Black Hat / Defcon 2018

I returned a couple of weeks ago from my annual week-long pilgrimage to Vegas for BlackHat and DefCon. The summary is the same as it is every year: If an organization wants in and has time and money, they will gain access. The only questions are how hard will you make it for them and how quickly can you discover their presence and kick them out?

I’m not going to address the part about how to make it harder or how to find and remediate here, but instead I’m going to focus on the first statement. If you become a target, entities like Nation-State actors and well-funded criminal organizations WILL get in. DefCon presenters demonstrated this over and over in a variety of ways. I have summaries of 10 I saw in person (not everything I witnessed, just the highlights!)

1. Processor based vulnerabilities that elevate privileges from user (ring-3) to root/admin (ring-0)
https://www.defcon.org/html/defcon-26/dc-26-speakers.html#Domas2

The main point of this presentation is that x86 class processors (both 32 and 64 bit) have coprocessors that are sometimes documented and sometimes not. Those coprocessors, if found and documented outside the normal channels, can be used to compromise any OS by writing to the execution code of that specific processor directly. In this case, the presenter found an undocumented RISC-based processor that had direct read-write privileges to registers that the main processor used as well. He leveraged those privileges to elevate from ring-3 (user) to ring-0 (root) in 33 lines of C code. Each processor is different with its coprocessors and he acknowledged that this would only work with processors that had this specific and undocumented RISC-based coprocessor. However, this proves it can be done and with enough time and resources a bad actor could do the same. The easiest mitigation would be a patch to each OS that uses x86 processors of this type.

2. Demo of how to take advantage of private/public key Infineon calculation flaw, using big data to successfully calculate the private key. (BAD, very, very BAD!)
https://www.defcon.org/html/defcon-26/dc-26-speakers.html#Romailler

Earlier this year, a mistake by Infineon chipset of public/private key pair calculations was found (note: Intel chipset prime number mistake). This demonstration confirmed that some key pairs can be calculated with fairly standard 9 node big data platforms that any major threat actor would probably have the resources to stand up. He also demonstrated that capturing 200+ million key pairs out in the wild is not hard.

3. OWA vulnerability that allows MFA circumvention for on-prem Exchange
https://www.defcon.org/html/defcon-26/dc-26-speakers.html#Martin1

Many organizations still run on-prem MS Exchange and have not moved to Office365/Azure. This demonstration proved that without Azure based features added by moving to O365 or leveraging a hybrid authentication system, MS Exchange MFA is easily circumvented. The presenter started with the premise that user and password credentials have been obtained, but MFA is enforced. Using OWA, the presenter was able to log on without MFA. The access allowed for exfiltration and full Email creation and account control. The presenter recommended exfiltrating all the Email, finding a recent Email thread that had a high value target and replying with a phish in the thread internally from that account. It would almost certainly be fallen for.

4. AD vulnerabilities that allow for MFA circumvention (including how to cover your tracks)
https://www.defcon.org/html/defcon-26/dc-26-speakers.html#Metcalf

Sean Metcalf has presented some scary AD presentations over the years. This year was no different. He presented how MFA inside of AD is easily circumvented because of the way that AD works (or doesn’t, depending on your choice of English). He targeted hardware based tokens and software tokens from prominent vendors as all not being able to prevent this attack. He also presented this in a way that the user would never see any change to their account information and not see any resets, as well as how to cover your tracks for forensics after the fact.

5. AD vulnerabilities that allow for PAM circumvention
(Including how to cover your tracks)
(And how avoiding PAM may not be needed)
(And how trusted domains-forests can be bad)
https://www.defcon.org/html/defcon-26/dc-26-speakers.html#Metcalf

In the same presentation from Sean Metcalf above, he showed how PAM solutions can easily be circumvented as well. Again, he targeted big name vendors, but his solution would generally apply to any PAM solution. Of course, all while covering your tracks. He then showed that avoiding these PAM solutions may not even be needed since many organizations have not completed a full IGA discovery and clean up, often leaving administrative access not included in PAM solutions. Finally, he presented how read-only trusted forests doesn’t actually mean read-only and how they can be used to compromise adjacent forests.

6. Process injection without dropping a file or changing the MD5 hash (avoiding AV and white/blacklisting)
https://www.defcon.org/html/defcon-26/dc-26-speakers.html#Ma

This presenter showed how to leverage vfile flaws to compromise processes without changing the root MD5 hash, avoiding laying down any files. The result was process injection that provided for obfuscation enough to hide from AV and whitelist/blacklist solutions.

7. A free macOS firewall creator showed how all MacOS firewalls can be avoided for CnC, including his own
https://www.defcon.org/html/defcon-26/dc-26-speakers.html#Wardle1

The presenter first gave a pitch for his free host-based MacOS firewall, and then demonstrated vulnerabilities that made it easy to avoid nearly every commercial and free MacOS firewall to establish CnC of a system, even his own firewall. His final comment was interesting, “I’m not saying host based firewalls aren’t worth it, I created one because I think they’re useful.” Hmmm.

8. Reverse engineering MS Windows Defender to avoid AV detection and back-end engineering discovery
https://www.defcon.org/html/defcon-26/dc-26-speakers.html#Bulazel

Demonstrated that MS Windows Defender has a malware sandbox onboard that he broke into. He used an internal look at how the malware sandbox works to find ways to avoid detection by the software and also noted that some bread crumbs are inside that can help hide from Microsoft forensics investigations on the back end as well.

9. ICS network disruption to disable controls using WISN network. (theoretic on how to also take over control, but research not complete)
https://www.defcon.org/html/defcon-26/dc-26-speakers.html#Paternotte

The ICS control networks are old. With little advances, one of the main protocols, WISNs, have always been thought to be pretty tightly locked down. The presenter showed that he could DoS (Denial of Service) the WISN control commands, making any ICS systems alone on an island. This could be useful for either compromising without being detected (no logs going back) or causing service disruption if commands are needed on a periodic basis to keep the system running properly. He also showed theoretic ways to inject commands into the control frames, but did not embark on that research and demonstrate it.

10. An ingenious example of how Google Ads can be used to find out if a blue team / defender has discovered your malware and also if detected, whether they are reverse engineering it or not.
https://www.defcon.org/html/defcon-26/dc-26-speakers.html#0x200b

In an example of out of the box thinking, the presenter showed how being prepared, a high level hacker using a zero-day malware can know when to either drop another zero-day or morph (change the MD5 hash) of their malware. By planting a website with the MD5 hash and getting it indexed in search engines, as well as buying GoogleAds that specifically fire on the MD5 as a term, the attacker can know that someone has found his file hash. With good preparation and some money behind it, an advanced attacker can know within two hours that they have been discovered. Additionally, he suggested putting some unique garbage terms inside the zero-day code that would get searched for and doing the same process with a site and GoogleAds. This would allow the attacker to know that the blue team or defenders are reverse engineering the code and are advanced in detection state.