Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Windows Defender Antivirus is an Antivirus that runs on Windows by default. Windows Defender parses lots of input, such as files, coming in. Because of how much data it processes, and it run as SYSTEM, it is an awesome target for attackers.

One of the file formats it tries ot unpack is ASProtected binaries. ASProtect is a complicated multi-stage exepacker designed to make reverse engineering very difficult. One of the unpacking stages involves executing some bytecode embedded in the executable. In order to interpret that bytecode, the packer encrypts and embeds a DLL that contains the virtual machine.

Instead of trying to interpret and parse this weird file format, Microsoft uses a clever trick: they simply run the packed executable in an emulator and allow it to unpack itself. The parsing has disappeared but the file can now be viewed!

The packer itself comes with the file. This is so, naturally, the file can be unpacked. However, what if the packer itself was malicious? While Microsoft treats the packed binary as malicious, they do not treat the packer/unpacker as malicious when running the emulation step.

Because of this oversight, the parsing of the ASProtect DLL (to setup the emulator) has almost no sanity checks. The vulnerability occurs within the parsing of the file headers. When viewing the RelativeVirtualAddress (RVA) of the header, it blindly trusted to use as on offset into a buffer in the emulator.

This leads to a controlled value going to a controlled relative offset of the binary. Using this, the author was able to overwrite RIP to control the flow of execution but did not go down the full exploitation yet. To make matters worse, vulnerability occurs in the startup of the emulator, resulting in the compromise of a SYSTEM process.

The author adds a POC. But, they make sure to encrypt the zip file because they know Windows Defender will extract the Zip and crash otherwise. In order to find weird exploits (like this one), we need to think like a developer. What assumptions would the developing team make while making this product on security? This is where lots of weird attack scenarios arise from.

The ISC implementations DHCP (dynamic host configuration protocol) relies on a the posix random function and is seeded in an odd way. It is done with the time, pid of the process and the last 4 bytes of the MAC address. Because GCPs IP and Mac Address share the last 4 bytes, both 1 & 3 (time and MAC address), are essentially public.

The DHClient process starts rather early on Linux; somewhere between a pid of 290 and 315. All of the randomness of the DHCP client for a random function is broken! Now what?

From another post in 2020 on privilege escalation within the Google Cloud, there is a trick that can be used to take over boxes with insecure DHCP usage. In particular, a bad xid value can cause issues. The xid is a random value that is used to associate the client with an incoming DHCP pending message request.

As described in the post above, the knowledge of the xid value is enough to trick the local host into accepting arbitrary networking information. With how GCP processes these connections, it allows for the overwriting of the current network configurations of any service we want. On GCP, the metadata service is over HTTP as well. By overwriting the IP of the metadata server, the authentication information can be altered to always return true!

The previous attack required access to the machine because the xid's were being stored in the system logs. However, the new piece of information is that the xid's are now known because of the bad randomness. Using a similar attack as before with DHCP will rewrite the /etc/hosts of the metadata server with something a location that we control!

After overwriting the IP of the address of metadata.google.com, the connection goes offline for a moment. Then, google_guest_agent will attempt to create a TCP connection to our rouge metadata server. Now, we can instruct it to add our own SSH keys and log into the box.

There are some limitations to this attack though. The main limitation is that this attack only works when DHCP is requesting data. This only happens when DHCP renews the lease or the VM is restarted. To run this attack remotely the GCP firewall needs to be turned off because it filters out DHCP related packets.

The author reported this issue a while ago but GCP has not fixed the handling of the DHCP on the /etc/hosts file. So, the GCP boxes are still vulnerable to this attack. Although the DHCP issue is only exploitable on GCP because of a multitude of specific things, the issue is actually in an implementation of DHCP in this particular library. Overall, this is an awesome post that required an amazing amount of creativity and spec reading to work.

MFA (multi-factor authentication) is used in order to prevent a data breach from completely compromising an account. The solution to the simple point of failure is to have a second authentication method that an attacker would not have access to.

2FA tends to have multiple ways to do it. For instance, OTPs on a synced phone app, SMS text message, phone call and many others. Having a vulnerability in any of them, because of the choice, results in a bypass of 2FA.

There is a common vulnerability with the phone call feature: voicemail. When a call is missed, the caller has the chance to leave a message for them. However, does leaving a 2FA code on voicemail a good idea? The argument of this article is that this is a horrible idea!

In previous research done by Sophos and a few other instances, voicemail is known to be semi-insecure. In Australia, a large amount of Telco's were vulnerable to attacks that allowed anybody to access the voicemail. But how?

If the ANI/Caller ID matches the account holder on a phone call, the system does NOT ask for a code to verify the account. In the US, the pin is requested regardless of the caller id. Because the caller id can be spoofed, this is a horrible idea!

By using a spoofing provider, a VoIP spoofing service or SpoofCard, the caller id check can be bypassed. With access to the voicemail (which is a vulnerability by itself), 2FA can be bypassed.

The next step was reaching out to the companies to ask them to stop putting 2FA tokens into voicemail. Some of the companies contacted (Google) claimed this was not an issue with their system but the Telcos system. Others, such as Facebook, LinkedIn, Duo, Authy, just removed the functionality of using the voicemail for 2FA, preventing the attack.

Less is a preprocessor language for CSS styling. It offers functionality, such as variables, to make CSS easier to use. In a situation, like Wordpress, where arbitrary styling can be added, the threat vector of this needs to be considered!

Prior to Less 3.0, JavaScript evaluation within the Less files was allowed. Using this, using an inline backtick to include JavaScript could be used to compromise the CSS preprocessor. In newer versions, the setting javaScriptEnabled must be set to true for this to work. Besides the obvious case for RCE, this makes for simple XSS if the env is isolated. All of this was prior research.

What else can be done? The import syntax can be used to import files that should NOT be allowed. For instance, AWS credentials is something that can be removed. Additionally, import supports URL based imports. As a result, SSRF is also possible.

Less also supports plugins, which can be included directory into the Less code from a remote source. Because an attacker can control the content of the plugin, this creates a great opportunity for compromise! If processed on the client side, it is XSS. if processed on the server-side, it is RCE. Wow, that's really bad!

The author took the liberty of taking this research and using it on codepen.io. The local file inclusion (LFI) bug worked like a share to leak the /etc/passwd and AWS credentials. Additionally, because it was processed on the server side, they got code execution on the box as well.

The more feature rich something is, the more likely it will be used to compromise you. Be careful how feature rich something is!

Digital Rights Management (DRM) is meant to prevent illegal usage of software. Commonly, it is used in order to prevent the copying of software.

Microsoft Adventure was a text based adventure game released in 1979. It was a re-implementation of the original text based adventure game that ran on mainframes. The game came on a single floppy disk.

Microsoft knew that hackers would attempt to duplicate the floppy drivers. In order to prevent this, they added complicated obfuscation to the disk. The floppy disk was chosen because of the ability to quickly go to random spots on the disk quickly, unlike tape on a cassette drive.

On a floppy disk, there are rings on it; these rings are known as tracks. A standard disk has 36 tracks (0-35). Track 0 was used as the boot sector for the floppy disk. This code was used to tell the computer how to start loading everything.

The obfuscation was done by changing the track numbers. Normally, the listed tracks are 0-35. However, the bootloader changes the numbers to 127-61 with decrements of 2 (127, 125,...61). Because of this, disk copiers did not know how to copy the drive and believed it was corrupted.

The author of this post discusses that a teenager built a custom disk formatter that knew how to read the odd sector information. Eventually, the author just renamed the sectors as well, to make copying even easier.

Ultima III used a similar type of protection on the Apple II. The Apple II disks had the boot block on track 17. However, the Read Write Track Sector function was edited to use sector 7 instead of sector 17. Because the 17th sector was not formatted at all, this made disk copiers crash and burn.

Ultima III has an additional protection as well: Group Code Recording (GCR) obfuscation. Storage of data was done with data and address fields where there were prologue and epilogue values to denote specific values. Ultima III rewrote these values where the values were stored in the custom RWTS. Damn, that is hardcore!

In order to crack this, the custom RWTS can be read by pausing the execution of the boot process. Then, the translation can occur in order to make this storage information usable again.

There are a few more copy protections in here that are worth the read! At the end of the day, there are simply obfuscation that would all eventually fall to attackers. It's interesting to see how companies tried to protect their IP back in the day.

Uber added a feature for sending an OTP pin via a voice call. For this flow to work, the I didn't receive a code button needs to be used.

Most OTP phone calls will not put the code into the voicemail. However, Uber did not have a protection for this in place. So, what's the issue with this? Apparently, voicemail boxes are not very secure!

Voicemail services, just like anything else, may have some security issues about it. The article references an exploit for accessing voicemail for a Telco in Australia. In general, the exploits work by exploiting callerid spoofing attacks when trying to access your mobile number.

The Uber OTP code being placed into the voicemail is not a vulnerability by itself. But, because voicemails are commonly hackable, this becomes an issue. Uber decided not to pass out for this issue because it requires a vulnerability in a separate product. To me, not writing the OTP code to voicemail is a good defense-in-depth measure.

The process for starting a computer has many stages. With UEFI, the process is a little more streamlined but is still quite verbose. After the initial bootloader, the UEFI bootmanager is launched. From there, the OS and many other things can be launched properly.

The partition for the boot manager (EFI file) is stored in a FAT file system. Because of this, they do not have ACLs or any security information on the files. In order to account for this issue with the EFI partition, Windows does behind-the-scenes magic to ensure that the EFI partition is not overwritten.

The problem comes down to how these protections were put in place. As stated before, Windows does behind-the-scenes magic to ensure that the partition is not overwritten. But, this magic is likely hard to implement.

The protections extend to not mounting the EFI System partition; the OS simply rejects this from happening. As it turns out, an attacker can call the CreateFile and specify the partition in this API without mounting the drive.

The first problem is that the GUID of the volume is random. Using FindFirstVolume and FindNextVolume, enumerating the volumes can find the GUID for the EFI volume.

The call to GetSecurityInfo results in a file descriptor. Sadly, any attempts to open the file for reading or writing result in access denied. So, Microsoft thought about a lot of these things!

Although this seems counter-intuitive, the key is to not request any access. Instead, call CreateFile with no permissions but specify CREATE_ALWAYS. This flag will truncate the file to a size of zero, if it exists, prior to opening the file.

Here's the problem: the access check does not happen upon the CreateFile call; it happens only when the handle is created. By making this call, it will open up the EFI partition and wipe it!

This attack ends up being a denial of service and nothing else. But, it completely destroys the computer. When trying to demonstrate impact, the authors had issue reproducing the issue depending on the virtualization platform being used.

The law of chromatic superior is something that I really stick to while testing. If two things act differently, then they must be different! With security testing, this means that two things are implemented differently, meaning they should BOTH be tested. If two pieces of functionality do the same thing in theory, there's a good chance that one of them is implemented poorly, leading to a security bug.

Microsoft Edge has a inline translation feature called Microsoft Auto Translation. Because there are so many languages, this is a commonly used feature by foreign users.

The auto translation feature takes text in one language and replaces it inline. What would happen if this was done insecurely? By definition of text manipulation, this is a good uXSS attack vector.

When Edge was replacing the data inline, they were not filtering out malicious characters or HTML encoding then. Additionally, the content was being added directly into the DOM. Because of this, when the content was added back to the page with the new formatting, it was possible to escape the HTML attribute to get XSS.

The payload is quite simple: “>img src=x onerror=alert(1)>. The HTML attribute is escaped with the double quote (") and the current HTML element is closed. Finally, the XSS payload put next.

To demonstrate impact, the author put this payload into a Facebook profile, a YouTube comment and a few other places. Universal XSS is extremely impactful on even the most secure of applications, as it affects the browser as a whole.

The bug is simply and impactful. I wonder about other features that would similarity be vulnerable in modern browsers?

Paypal is a site that everyone has heard of; as a result, finding XSS on the site is a huge deal.

To find the XSS, they used the new in-house tool DOM Invader. Burp's Embedded browser goes to the site and injects a canary to see which sources and sinks are used on the page. Once it finds a few links, XSS-like characters are injected in order to see if they are allowed.

After using this semi-automated technique on that page, they found a few interesting sink points that allowed for bad characters. By using the tool, the reflection was easy to see, instead of being hidden in the DOM. The vulnerability was in the ID parameter of a span not escaping the quote.

The input had to be a valid CSS selector. After coming up with a crazy payload, the exploit worked! Well, kind of and PayPal did not agree; the CSP was restricting the XSS, sadly.

PayPal should assess this as XSS at face value; a CSP bypass should not be required to demonstrate impact. PortSwigger went about finding a bypass to the CSP. Obviously, the first thing to look at is the CSP.

At first glance, the CSP allows certain domains, such as *.paypalobjects.com and *.paypal.com. Additionally, it allows for the 'unsafe-eval' directive which would allow the use of eval, the Function constructor and other JavaScript execution sinks.

First, they plowed through the potential attack surface, seeing what was loaded and such. With no progress on known gadgets they tackled PayPal specific gadgets. Eventually, they found a gadget that was an obvious DOM XSS inside of it on trusted page. By loading jQuery and the previous page mentioned, the second exploited vulnerability was able to bypass the CSP by calling jQuery functions.

The author claims that "...jQuery is CSP's nemesis. It converts scripts, and will happily execute them with policies, using the 'unsafe-eval' directive". It turned out that because the original value being injected was in a jQuery selector, the separate XSS bypass is not needed. JQuery really is the enemy of the CSP!

I had two main takeaways: DOM Invader is an awesome tool that I should learn how to use. Secondly, do not rely on a CSP to protect the site, as it can likely be bypassed.

ForgeRock is an access management service. While working on previous OpenID (newer OAuth2), the author found a serious finding that did not relate to OAuth at all.

While doing source code analysis, there are a few things to look for. First, how is the authorization done? Secondly, insecure methods such as serialization, command injection, XML processing and other pain points. Although source code analysis tools work, Michael highly recommends grinding through the source code by hand.

While looking through the application, the author noticed the usage of Jato. Jato is a 20 year old legacy framework without a single CVE assigned to it. Old and untouched seems like something to hit.

Within Jato, there was a field that was being arbitrarily deserialized that appeared to be user controllable. To test out the exploitability out the deserialization, Michael created a Java object to test out the functionality.

After finding a custom gadget chain, he tried his luck on a few other applications within bug bounty scope. To find the chain, Michael used two tools at gadgetinspector and serianalyzer. One of them returned a valid chain, which allowed for code execution.

The research for gadget finding is interesting, but not my cup of tea; there are more details in this post about how the gadgets work. In order to patch this bug, the endpoint was removed entirely that had the user controllable data going to Jato.