⚠ Disclaimer This trip was made by possible by the funding provided by the HITCON 2020 Student Program. While select students are required to write a publicly accessible review of the event, HITCON was NOT given any copy approval or an early preview. I try to present my articles as unbiased as possible.
Prologue
Attending HITCON Community conference has basically been a yearly routine of mine since 2018. Year and year I’m more and more amazed by the quality of the talks and the overall conference - this year was no exception. Every year the organization has surpassed my expectations with their ambitions.
Due to COVID-19, the organization went out of their way to set up remote sessions for both domestic and foreign attendees. While I’ve heard there were numerous hiccups with the online sessions, I believe it’ll get better over time (assuming this is kept a tradition for the coming years). With everything else going on in the world in 2020, I’d like to think we’re extraordinarily lucky to be able to have the physical conference running. Since most events are moved to online if not outright canned around the world this year due to the pandemic, the fact that Taiwan was barely impacted is nothing short of a miracle.
To Taiwan and the rest of the world, I do believe this truly is a turning point for everyone involved - not only because of the various hazards going on right now. In terms of information security, I can certainly feel that the government this year is feeling some sort of pressure from the recent infosec incidents that had occurred in the past 3 years. During this year’s AIS3 (Advanced Information Security Summer School) courses, there was a noticeable presence of National Security and Industrial Control System related courses - which was unprecedented on this scale. In fact, it seems like such a crucial topic that the Vice President of Taiwan even showed up during this year’s HITCON opening ceremony.
Day 1
Day 1 Agenda
2020 Industrial Cybersecurity Landscape (ICS & Infosec)
After the opening, the rising importance of OT (Operational Technology, as opposed to IT - Information Technology) security was made apparent with the first talk of the day - “Industrial Cybersecurity Landscape in 2020: Trends, Challenges, and Opportunities.” Various APT groups have been preying on Taiwan in the past few years, and the OT industry is perhaps the biggest target of all, as TSMC was attacked by WannaCry in 2018. In fact, the entire semiconductor industry has been under continuous attack even outside of the OT environment, as evidenced by the Black Hat 2020 APT Chimera report by CyCraft.
Lunch Break (Intermissions!)
I skipped over the next period of talks as I didn’t find anything particularly interesting that I wanted to listen to - which was rare. Alas, I went to work on my slides for my Lightning Talk session (I’ll get to that later). As always, the included meals and bonuses that came with the conference were amazing to have. This would be a fantastic chance for non-Taiwanese visitors to try out bentos.
Under normal circumstances, I would have preferred to listen to the “APT Chimera - Operation targets Semiconductor Vendors” talk after the lunch break; fortunately, though, I had the chance to listen to the Dr. Bletchley’s excellent talk during this year’s AIS3 summer school. For those curious, you can find the slides on Black Hat’s website, as this talk was also shown off at this year’s Black Hat.
Anyways, what I ended up doing was tuning in to the “company recruitment” segment, where sponsors do their sponsored segments and advertise their company in the hope of getting new blood. As mentioned in the prologue, 2020 is a turning point for everyone - the entire infosec industry, Taiwan, every country that suffered from COVID-19, and me.
Why me? Because I’ve been on the lookout for a job myself as well. Not just any job, but a job that I can find myself enjoying in. Over the past few years, I’ve decided that the best type of job for me would be becoming a Security Researcher, joining a Red Team of sorts, or doing forensics-related work. In other words, I’ve been hoping to find companies that offer this type of job opportunity. Several companies did peak my interest, CyCraft, TeamT5, Panasonic Cybersecurity Lab, and several more. Getting a job may not sound like that big of a deal, but for me to get any jobs like that would require me to move to Taipei, the capital of the country. Where I’m from is very different from the bustling life of metropolis, which is why I’m kinda anxious about the future as well. I’ll make an updated rambling if I do manage to land a job, though.
Operation: I Am Tom (AD Infiltration)
The next segment I chose to tune in to was “Operation: I Am Tom,” a talk focusing on various attack vectors and methods TeamT5 had encountered when handling incident responses. Unfortunately, this session was marked as “On-site Only,” which means I’m not allowed to show off any of the slides featured in the talk. What I am allowed to do, though, is talk about some of the exciting highlights from the session.
- The hosts mentioned the reason why the section was named “I Am Tom” was because while dealing with one of the incident response cases, the threat actor noticed the presence of SecOp and decided to drop a file called
iamtom.txtunder the root directory.- This shows that these threat actors are not only not afraid of these security researchers but would even dare fight back on the spot.
- Threat actors will try whatever possible to run Mimikatz on the victim server
- Those who had dealt with Windows Server red teaming should need no introduction to Mimikatz. It is an open-source software used to dump NTLM keys. Threat actors love to use Mimikatz in order to move laterally within the victim organization.
- The researchers noted the use of injection of
mimilib.dll, a library that Mimikatz uses, into the Security Support Provider. If you are interested, XPN has an excellent article on this subject matter over at Exploring Mimikatz - Part 2 - SSP.
- Use of genuine third-party software is not uncommon
- In one of the cases, the attacker used a software called “Easy File Locker,” which was a genuine piece of software used to hide user’s files. The threat actor used the software to hide itself from SecOps.
- While this type of attack method is rather uncommon, as these threat actors would typically embed such functionality in their malware instead of relying on an external program, this example shows that it can still happen.
- Use of old-tricks are still fairly common even when dealing with APTs
- In this case, the researchers noted that some threat actors had sneakily replaced
sethc.exe(Accessibility Shortcut Keys) withcmd.exe. By replacing the executable, the threat actor can then launchcmd.exeby invoking the sticky keys (pressingShift5 times).
- In this case, the researchers noted that some threat actors had sneakily replaced
- Use of Telegram API as RAT
- To create inconspicuous traffic, threat actors may use third-party IM APIs in order to communicate with the C2 station. In this instance, the threat actor chose to use Telegram as their C2 endpoint.
- The threat actor may use Telegram to send pre-determined commands to victim machines, and the victim machines would return the results in the same Telegram channel.
- While the use of inconspicuous traffic as C2 stations is nothing new, this incident still shows that this trick is still actively being used to this day.
Many more topics were presented in this talk, but the above were the ones I found the most interesting.
Tropic Trooper’s USBFerry (APT vs. Air-gapped Environments)
Next up was Trend Micro’s talk on the APT group, Tropic Trooper’s, attack among air-gapped systems (a detailed report is on Trend Micro’s blog - Tropic Trooper’s USBFerry Targets Air-Gapped Networks).
This is one of the talks that I found the most fascinating. After all, breaking into a both physically-secured and technologically-secured environment is almost impossible - unless you are a very well-trained group of internet assassins, which honestly, sounds like what the APT group is like IRL.
A quick rundown of a physically isolated system is as such,
- Usually disconnected from the public network
- This means attacking over remote is almost out of the picture.
- Rely on well-protected strategies for data exchange
- e.g. biometric secured flash drives, using a quarantined machine to scan the device, air-gap switcher, etc.
To fight against this, the APT group used a type of attack they dubbed “Ferry,” which, in this case, means “to cross the shore by ship to another.” Essentially, the malware would have to travel from devices to devices via removable media (such as USB thumb drives, floppy disks, memory cards, etc.), all while hoping that the malware would not be detected by the AV on the middle-man scanning machine as previously mentioned.
According to the report, the threat actors infiltrated the group via the typical spear-phishing attack, with emails designed for military personnel (e.g., documents with specific weapon information, tanks, etc.). With this information in mind, it becomes apparent that the group behind the attack was most likely state-sponsored, as there’s no way your average Joe would have intelligence regarding weapon blue maps and such.
Perhaps the most interesting bit was that the researchers noted that the APT group would sometimes “forget” to exclude PDB strings in their malware when dropping new versions into the systems. From there, several intriguing version strings can be extracted from the debug symbol paths. The variant went from having the PH initial to UF, and when the name change happened, the directory name also included the word USBFerry. Going from a no-name project to one with a name means that the project has garnered enough reputation among the group members that they perhaps felt it was necessary to give it a name - and that’s why Trend Micro dubbed the attack “USBFerry.”
This explanation did not sit well with me, though - surely, the APT group wouldn’t be dumb enough to leave the PDB path exposed during the build process, right? To me, this seems more like an intentional move from them to show off, perhaps? Not sure. Either way, I don’t think the PDB symbol paths were left intact just because they “forgot.” This type of attack is undoubtedly the most gripping to me, though, as the threat actors were obviously highly trained for this level of infiltration.
A CTF-Style Escape Journey on VMWare Workstation (Guest-to-Host RCE)
This talk was the one I was the most excited about in Day 1. Vulnerabilities that escape from the VM world to the userland are always considered the holy grail for malware. While fewer and fewer of them exist, this talk shows that it is still possible - well, was, after the vulnerability was patched. This vulnerability was assigned CVE-2019-5515 and VMSA-2019-0021, which affects VMWare Workstation 15.5 and other previous 15.x builds. Unfortunately, though, the bug is relatively old, as it was patched some time late last year, so most users are likely invulnerable to this exploit anymore. Either way, it was still very impressive that Chaitin Technology was able to find such obscure vulnerability.
So, where was the exploit found? The vulnerability lies within the virtual e1000e ethernet driver. With a bunch of out-of-bound writes, the threat actor could successfully execute a RCE to the host machine. Unfortunately, a lot of what was featured in the talk was and is outside of my expertise, and the team did not release an official write-up regarding this vulnerability. As much as I’d love to look more into the case, there isn’t a whole lot I can base my research off of (and no, I do not have any photos outside of the 3 featured above).
End of Day 1
Day 1 was exhausting.
Though I guess it applies to any conferences I go to these days, as they are typically filled with non-stop information barrage. Didn’t help that I only slept for a couple of hours at the hostel the day prior. From the topics presented throughout the entire day, I was the most intrigued with presentations like the air-gapped targeted attack and the real-world AD attack.
Compared to last year though, the day one experience was less exciting this year around. Not sure if it was because I didn’t visit the booth events or because the talks on that particular day didn’t interest me enough. I think it would certainly help if I had someone else go with me.
Anyways, after the event, I thought I’d take this opportunity to look around the city. Y’know, to take in the capital of the island, since I’m more of a suburb city type of person - still not used to all this crowd and whatnot. The street near the hostel I stayed at was a bustling one. The entire street was lively, but feels… I don’t know, kinda dead men walking in a way? Not sure if it was just me, but I felt certain tension in the air as I was walking around the streets. Maybe I just was not used to the city, still, or I was simply tired. Either that, or busy cities are always like this.
Anyhow, I dropped by the nearby department stores and bookstores to take my mind off things after getting some tea and dumplings as supper. Every time I go to bookstores and whatnot, I wish I could go out not empty-handed - but nah, I kept my cool and decided not to spend my already tight budget. It’s been a couple of grueling months not being able to afford entertainment. Hope I can get a new job soon. Still, it was cool seeing illustration books and oddities in places like these - especially seeing bookshelves full of Fate stuff.
Day 2
Feeling much more refreshed, I got ready, checked out at the hostel and went out.
As I was heading out, I noticed that there a small breakfast shop just beneath the hostel. It seemed like a good moms’n’pops type of breakfast place. Always enjoyed this aspect of Taiwan, where local restaurants feel truly local instead of “just another chain fast food store” type of deal.
Anyhow, I got a sandwich that was like, $35 NTD (~1 USD) or something and paid with a $1000 NTD (~$35 USD) bill. The woman who was busy working and frying food at the counter hastily took my bill and got me the change - until moments after I realized she literally handed me back another $1000 NTD bill with $465 dollars in change. I stood there for like, 30 seconds, thinking that it must have been a mistake, but should I tell her? I ended up asking “hey, uh, this change doesn’t look quite right?” She took a look at the change, and realized what a huge mistake she made and replaced the $1000 NTD note with a $500 NTD one. That’s more like it.
As I was making my way to the nearby subway station, I pondered to myself, “what would have happened if I didn’t tell her about the change?” Y’know, I could have easily made some money then and there - and I know that would be wrong. The idea of it possibly happening though. The moment of panic that they’d realize that chunk of their money would be missing by the end of the day. They sure didn’t look poor, but they didn’t look like they were swimming in money either. What if that loss of money impacted the rest of their week or even month? Since we don’t know what their financial situation. It’s food for thought.
Day 2 Agenda
The first period looked very promising compared to the first day. Study regarding recent DVR/IoT DDoS attacks, smart card duping, bug bounty experience, and breaking a Galaxy S10 - all promising stuff. I ended up picking the S10 Secure Boot attack talk - we’ll get to why I ended up choosing that one later.
Exploiting Samsung S10 Secure Boot (Root w/o Tripping KNOX)
⚠ Warning Incoming rant. Skip two paragraphs if you only want to hear the details of the talk and my thoughts on it.
Before I get into the talk, I’d like to talk about one of the reasons why I refuse to buy a Samsung device - lack of developer freedom. Sure, they offer revolutionary hardware and had brought us amazing devices like the Galaxy Z Flip 2 that was recently launched, but they are very stringent on “security.” Perhaps the best example for this argument is KNOX, an e-fuse that is blown should the user decide to unlock their bootloader. KNOX is a stored in a write-once memory chip, so once the fuse has been tripped, it is impossible to reset the fuse state without replacing the entire board.
I never really understood how this increases the overall “security” of the device. I can understand the standard Android approach where a warning has to be displayed when the bootloader is unlocked, as it warns the user that the device may be or may have been tampered with. I can also understand the benefit that KNOX may bring, such as invalidating the security keys used to encrypt user-space content to erase contents of secured folder. I get that. But does it have to be a permanent thing? If the fuse is blown, Samsung can reject your warranty request just because you tried to unlock your bootloader and flashed something else. What if I didn’t want OneUI? The consumer should have a choice in doing so and not be tied with this crap.
Anyways, now that we know that KNOX is a write-once-only bit on a chip that is tripped when a bootloader unlock or root attempt is detected, let’s move on. I chose to tune in to this talk because I had some prior knowledge regarding how Android handles its bootloading process (dm-verity and whatnot) and was curious to see how the researcher was able to not only defeat KNOX but also how Samsung handled the entire case.
The researcher, Jeffxx, first demoed how this type of execution could be carried out in a real-world scenario. For instance, say Bob’s phone is dead and he wants to borrow Alice’s charger. Alice’s like, “sure, you go relax, and I’ll plug it up.” Bob goes away for a coffee while Alice enters ODIN mode on the device, pushes the malicious code, and reboots the device. After a while, Bob returns and asks for his phone. Bob unlocks his device and goes on about his day. Meanwhile, Alice has already prepared a script that dumps information from the phone remotely after the device has been unlocked. Mission complete! All of this was demonstrated in a pre-filmed video with actual acting. I love the effort that was put into the talk.
After the demo, Jeffxx did a quick explanation on the boot process of a modern Samsung device. Like any other modern secure device, there is a chain of trust involved. If the onboard Secure Boot passes the necessary security check, the bootloader then passes this signal to the kernel, then DM-verity takes care of the system integrity check, and if the integrity check passes, Android boots.
ℹ Information For a more detailed explanation on how Android performs its boot verification checks using dm-verity, see Implementing dm-verity and Verifying Boot on the official Android SDK docs. Note that the booting process explained in the documentation does not relate to Samsung’s KNOX and TrustZone implementation. The Samsung implementation occurs before the dm-verity stage.
As explained in Samsung’s various documentations (see An Overview of the Samsung KNOX Platform (2016) whitepaper, Sensitive Data Protection (SDP), File-based encryption (FBE) and full-disk encryption (FDE)), newer Galaxy devices store the (partial? unsure) KNOX encryption/decryption key within the hardware. Once the user enters their credentials via the Android keyguard, storage spaces that have been encrypted using FBE (File-based Encryption) are then decrypted via the hardware-backed credential storage. The said key is purged from RAM when the device is locked.
While it is not documented in the official documentation (at least I couldn’t find it), it seems that the keys are reset once the KNOX has been tripped. Therefore, data encrypted using FBE (e.g., Secure Folder) may not be retrieved after tripping KNOX.
In laymen’s term, sensitive data may not be retrieved if the following occurs:
- KNOX e-fuse has been blown
- Encryption/decryption keys reset
- Device not yet unlocked by the user
- Android-space, refers to Android keyguard status
So, the challenge here is to a) obtain root without alerting KNOX b) plant files under decrypted storage space. The attacker has to achieve the above in order to access sensitive information stored on the device before TrustZone initialization.
There are very few attack surfaces in a pre-boot environment. Jeffxx decided to tackle this attack from the ODIN download mode.
ℹ Information Samsung’s ODIN mode is used to flash stock firmware signed by Samsung - and as noted by the official whitepaper, a rollback prevention e-fuse is in place, so version rollback is not possible.
ℹ Information I won’t dive too deep into the details in the following sections, as it is totally above my pay grade. A more detailed explanation can be found in Jeffxx’s full slide released at Blackhat 2020.
Through multiple weak ODIN image checks, improper vulnerability patches, and physical hardware glitches (nothing fancy, literally just disconnecting the USB cable at the right time), it is possible to perform arbitrary code execution through overflows. With this in mind, all that’s left is for the user to unlock the device to access the key stored in the credential guard. It’s even possible to chain the vulnerability with known vulns if the user refuses to update. Unfortunately, Samsung still didn’t quite get the bug fixed. It took almost a year for the bugs to be properly patched (see SVE-2019-15872, SVE-2020-16712).
Despite all this though, Jeff made it very clear that the attack surface is so complex that it is not particularly trivial to access the secured data. A lot of techniques (like getting physical access to the device in the first place) are required to pull this attack off. As usual with theoretical or complex attacks like this though, the moral of the story is don’t leave your device unattended.
Despite not having the skill to find vulnerabilities within early low-level bootloader stage, this talk still taught me a lot regarding the bootloader mechanism featured on Samsung devices. With that being said though, I still do not see the point of KNOX, as previously mentioned in my rant above.
Certainly Samsung has put in a lot of extra protections to ensure that the user data is secure in the event that TrustZone is defeated, but I still do not believe the whole write-once e-fuse thing is necessary for consumer devices. It’s certainly fascinating to study the security measures implemented at hardware-level, though.
LNK to RCE: Bugs in Windows Shell Link Parser (Windows *.lnk CVEs)
When I first saw the title of the talk, I didn’t know what to expect. It didn’t dawn on me what LNK meant until the talk had started. Yes, it’s exactly what you think it is - the shortcut file extension, .lnk.
The presenter was Lays (yes, that Lays), who had previously been named a Microsoft MVP researcher in both 2019 and 2020 - and they co-founded Pwnable.tw, which is arguably one of the largest Pwn-focused CTF platform out there.
Anyhow, the motivation for the research was simply to make a good use of the fuzzer project they made when they were finishing their master degree. While looking for potential targets, they found out that the LNK file format seemed to be the best one. Due to the nature of a shortcut file in Windows, link files are always parsed by Windows Explorer before the icon is ever presented to the user. This behavior makes it a perfect target for RCE, as it is almost impossible to tell Windows not to load the file in memory.
Leave a comment