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!

Our computers are filled with many URIs (universal resource identifiers). Our computers have packages with built in functionality to know how to handle these links. Common URIs are http and file. However, many applications create their own in order to allow for extra functionality inside of the application. The authors of this article went after the common URI handlers on Windows 10 to see if they could find any vulnerabilities.

The vulnerabilities in URI handlers commonly lead to code execution. While enumerating through registry keys on the system they came across the URI ms-officecmd. Since Office is crazy complex, this was a legacy protocol and would be installed everywhere, they started looking around this URI handling. The URI accepted valid JSON, with a simply payload being ms-officecmd:{}.

At this point, they had to start reverse engineering the application. Luckily for them, it was written in C#, which is easily decompiled with variable names and everything else still intact. After reverse engineering a few applications (including another URI called ms-officeapp:), they were able to get a valid payload to work. The

The JSON had the following format:

• appId: The office application to be opened. This included Access (1), Excel (2) and many other Microsoft products.
• Filename: This contained a file path or a URL to a file to be opened in the application that was chosen above.
• Name: The name of the application to open.
• Command: The local location to execute for the application.

The first bug was that an arbitrary URL could be added for Outlook. When a user opened the application, it would take them to Outlook with an open Webview with the web page. This is a great way to do a phishing campaign!

Besides the phishing attack, files could be specified. Even though the file:// was blocked, using C:// bypassed this validation to access a local file. Additionally, by adding a trailing / the file extension check is bypassed but is ignored once the executable is open. In the POC on the page, they should PUTTY being opened directly. If we can trick the user into downloading something, we could even run our own executable here!

In order to open up another application, the AppBridge.dll library handles the URI. To do this, they need to include some of the user input into a cmd argument directly. By adding a double quote (") into the filename parameter, they found this could be used to escape this parameter. As a result, argument injection was now possible for whatever application they were trying to load.

Argument injection on a simple application with one or two flags is not likely to be a problem. However, with the complexity of Word, Outlook and other things, this was a disaster waiting to happen. They believe it would be possible to use an add-on to Word or Excel, but never got this working.

In Microsoft teams, which is built on Electron, they figured out how to launch a man in the middle attack via the CLI parameters. By adding in the flag --ignore-certificate-errors and an IP host rewrite rule, this could be done. Because of previous CVEs in Electron, Electron decided to not parse information after a file URI. Still though, they made an exception for 1 letter URIs. With a bogus URI and our flag above, a MITM attack could now be performed.

In both Teams and Skype the flag --inspect flag could be inserted. This flag can specify a debugger port to connect to. Upon connecting exec("<command>") was executed, giving RCE on the device, assuming an attacker knew where to connect to. Another bug was a command injection via the --gpu-launcher parameter of Electron, which comes from Chrome. This trick was used in a previous exploit as well.

Overall, great article on the tails of their research. A few takeaways from this:

• Parsing and validation is hard to do properly! Even if validation prevents the obvious attack, see if some slight difference bypasses the validation but still works practically.
• Argument injection is a very serious bug!
• Do not trust vendors to pay out for what they say they will. There's always a loophole they will find.

Log4J is a popular logging framework for Java. This is used by many large applications, including AWS. The vulnerability is similar to that of a format string bug: data within a string was being treated as trusted input, when it should not have been. This resulted in strings, provided by the user, being capable of large capabilities.

The default configuration of Apache Log4J supports Java Naming and Directory Interface (JNDI) lookups. This means that it can execute arbitrary code. Besides that, it LDAP, DNS and Java object usage would also be possible. Really, it's that simple. Put a string with ${jndi:ldap://localhost:1389/a} that gets logged and it will make a call to this to execute arbitrary code.

The patch disables JNDI by default in the lookups. This is now a configurable feature that can be turned on again if you like RCE from logging (lolz).

In some non-default configurations, the vulnerability was still possible to exploit. When data is passed to some other locations besides the message, it can lead to issues. Praetorian shows a proof of concept of this exfiltrating data. Additional details can be found at a twitter thread.

CVE-2021-44228 and CVE-2021-45046 are some of the worst vulnerabilities ever discovered with how widespread the Log4J package is used. I suspect, down the road, this will be talked about alongside heartbleed and shellshock.

MediaTek chips are in 37% of all smart phone and IoT devices in the world. Modern chips contain AI processing unit (APU) and digital signal processing as well. The APU and the DSP have a custom architecture called Xtensa, where MediaTek even has their own custom instructions. How did they find all of this out? By a whole lot of reverse engineering!

First, they rooted a Xiaomi Android phone. The host operating system must communicate to the chip somehow; this was done via the audio_ipi at vendor/lib/hw/audio.primary.mt6853.so. This library has a single export: AudioMessengerAPI, which is responsible for Inter-processor interrupt (IPI) messages to the audio DSP. The driver has 6 ioctls, which the authors interact with directly during the later proof of concept.

The authors of the article got the firmware by stealing the factory update image file audio_dsp.img. However, this also could have been done by reading the /dev/block/platform/bootdevice/by-name/audio_dsp on a root device. The article dives into the format of this img as well but they do find out it runs a custom version of FreeRTOS. Here is the interesting part though: IDA has no idea how to process a large part of this code.

IDA Pro 7.6 supports the Tensilica Xtensa architecture. But, not well and there are many customized instructions, which can be variable length as well. Using the Xtensa SDK many more of the instructions can be decoded. Additionally, MediaTek had very helpful logging that made it easy to find functions and their usage. Not everything was perfectly decoded but it was good enough for this research.

The drivers, from the Android side, have to interact with the chip somehow. The authors reviewed this source to find the best possible entry points in the code for the DSP chip.

The first vulnerability they found was a classic heap overflow in one of the IPI message handlers (ID 6). When processing the input, the function copies the message payload into an object, with the amount of bytes being copied directly controllable by an attacker. There is no validation on this size, which leads to a memcpy out of bounds write on the heap. Sending more than 20 bytes triggers the bug.

A similar issue was found with an IPI ID of 7. A copy is performed with a user controlled size in a buffer of only 0x20 bytes. Even though there is a validation, it checks the wrong size value (0xE0). It is like somebody wrote the code with a hardcoded size but the eventually size of the buffer change, without the validation ever being changed.

The last vulnerability on the DSP processing is an out of bounds write via lack of validation of array indexing. Simply put, the user can provide an index but this index is never validated. By providing something outside of the expected range, a write can occur with a user controllable value.

These bugs are awesome but there is one problem: only specific processes are allowed to use these drivers. Some sort of privilege escalation would be required to hit these drivers! The authors noted that the Mediatek hardware abstraction layer (HAL) was controllable via standard function calls to the AudioManager. The authors believe that this was left over for testing purposes but gives us access to more things than we should!

Normally, the HAL configurations are set by the manufacturer and are not a source of malicious input. But, in this case, we can alter the HAL configuration to do whatever we want. Since this is not a normal location for input, the security was much weaker. On the Xiaomi device, they found a vulnerability that allowed for the calling of the DSP drivers from inside the library.

A few things that I took away from this:

• Hard to reverse targets tend to have easier bugs. The effort is just put into reversing instead of vulnerability hunting in this case.
• Sandboxes are quite useful! As we move more and more towards sandboxing, LPEs are going to become more common.
• Changes in unexpected places usually leads to security bugs.

NSO Group is a access-as-a-service company. They will build full & weaponizable exploits to compromise computers and phones for companies. The entrypoint of choice is via text message. One weird trick is that iMeessage supports GIFs; by specifying .gif as the extension but sending another file type, it will parse this file format instead. Since file parsing is notoriously hard to do. NSO uses the "fake gif" trick to target a vulnerability in the CoreGraphics PDF parser.

The PDF parser appears to be Apple proprietary code. But, the JBIG2 implementation is from Xpdf, which is open source. JBIG2 format is a series of segments, which can be thought of as a series of drawing commands which are executed sequentially in a single pass. The vulnerability is an integer overflow when combining referenced segments. The overflow occurs within a loop that is continually adding the segments size together.

The size above is then used for a call to malloc. Since the overflow occurred, the buffer is undersized! This leads to a buffer overflow inside this buffer. This should lead to a crash though, right? 32GB of data looks would be a large overflow!

To avoid the crash, NSO group does a crazy trick to stop the overflow from being too large and causing a crash. By doing heap grooming, it is possible to write off the end to the GList backing buffer. This buffer stores segment information and is used to find the segments to use for the writing process. By using the overflowing write to corrupt the backing buffer pointer with pointers to bitmaps, we can cause this program not to crash! Even function pointers still work properly since the bitmap type inherits from the Segment type.

At this point, we have caused an overflow and the program has not crashed. So, now what? Get a more powerful primitive! By carefully lining up some other objects in memory, three more Bitmap pointers can be written to the GList buffer. By doing this, the VTable for the object and the expected size of the buffer have been altered. This gives an unbounded drawing canvas. This means that future segment commands can read and write outside of the expected buffer length!

This gives the attackers an relative read and a relative write in this process. You may be asking yourself "If this is a parser, then it's a single pass, right?" The JBIG2 refinement format is flexible with many different operations. By performing these operations (XOR, AND, OR and XNOR) on out of bounds elements, on the unbounded memory, you have a turing complete computer to cause all of the damage that you need.

What if rather than operating on glyph-sized sub-rectangles you instead operated on single bits? You can now provide as input a sequence of JBIG2 segment commands which implement a sequence of logical bit operations to apply to the page. And since the page buffer has been unbounded those bit operations can operate on arbitrary memory. Now, you have a Turing complete computer!

According to the author, there are over 70K segment commands defining logical bit operations to make a tiny computer. It even has registers, a 64-bit adder and a comparator to search and perform arithmetic operations. The author says "The bootstrapping operations for the sandbox escape exploit are written to run on this logic circuit and the whole thing runs in this weird, emulated environment created out of a single decompression pass through a JBIG2 stream. ". This is truly amazing and probably took this team an insane amount of time to write.

The author says that the sandbox escape (which will be detailed in another post), uses the mini-computer described above. This post really blew me away with what is possible with weird machines.

Kubernetes is a container orchestration framework that was built by Google for deployment, easy scaling and simple management.

In Kubernetes there is a feature that allows the sharing of a volume inside the containers of a pad. For instance, this could be used for pre-populating a database or something like that.

Since the user can provide a path to be used for this, Kubernetes has to be extra careful when handling this path. Attacks with symbolic links and time of check vs. time of use (TOCTOU) issues are quite common in these areas.

A previous vulnerability involved a symbolic link. One container would create a symbolic link outside of the container. Then, when another container would start up and setup a volume according to this symbolic link, it would go to the host system instead.

A fix to another vulnerability was to make sure the subpath mount location is resolved and validated to be inside of the volume. This fixed a TOCTOU issue between the verification and the usage of the link.

The previous fix takes several steps to ensure that the directory being mounted is safely opened and validated. After the file is opened and validated, the kubelet uses the magic-link path under /proc/[pid]/fd directory for all subsequent operations to ensure the file remains unchanged, which is awesome. However, the authors found out that all of the efforts of this fix were for none because mount uses the procfs magic-link by default.

So, there is a small race condition: but is it exploitable? Very much so! There is a syscall called renameat2 which just swaps two files paths. But running this in a loop, it is possible to get the verification to do check thing but the mount to use another!

The solution to the bug was to add the --no-canonicalize flag to the mount command. This ensures that the tool doesn't use the magic links.

TOCTOU bugs are hard to find, as they usually only exist in complicated applications. Files are a great place to find these bugs though; using it securely is intuitive.

Sometimes, a username and password alone is not enough for security. In high sensitivity areas, additional levels of security are necessary. So, another way to demonstrate that someone owns an account is required; this is commonly called MFA (multi-factor authentication).

The Google Authenticator app and SMS text messages are common ways to do this. An attacker being able to bypass MFA is quite bad if they already have the username and password.

The bypass is quite simple: remove the MFA. Once the user is in a partially authenticated state (such as when they log in), the /mfa/unenrollment endpoint can be used to remove the MFA.

To remediate this, the user needs to be completely authenticated to remove the MFA. The author also mentions using a SaaS app to do MFA instead to avoid these types of issues.

In terms of testing, partially authenticated spaces are interesting to test. Most APIs use authorization between users and authentication as ONLY if the user is who they say they are. This API simply did not consider the case where a user had logged in with only the username/password. This is a good place to test at!

Glassdoor can load CSS on their domains via links in the URL. This has a domain allowlist, making sure that you cannot load your own CSS into the page.

The allowlisting functionality has a flaw though. By adding a domain as https://zonduu.me/example.css?http://www.glassdoor.com/ in the URL parameter, the CSS can be injected into the website via the link tag. To me, this looks like an issue with a regex or a case of in or contains being used improperly.

What can you do with arbitrary CSS being loaded into the page? In Internet Explorer, you can get XSS via the expression function. Additionally, using standard CSS selectors, the HTML source of the page can be read from the page. Another attack could be looking for sensitive information in URL query strings, such as OAuth tokens.

The report was initially reported as a medium but moved to a low with the service team saying this did not have much impact. To me, being able to infiltrate data from a page should be of higher severity but I'm unsure how to practically do this with CSS alone.

Satellites are absolutely everywhere! Are they secure? It turns out that a lot of data is being sent unencrypted over satellite broadband for both internet and TV. In the past, the HTTP requests were fine. But, as the internet has gotten more complicated and more used, the security did not improve with it.

Satellite communication for internet traffic is quite odd. This is the flow:

1. User makes a request.
2. Request is sent to the satellite.
3. Request is received by the satellite.
4. No processing is done. The request is sent back down to the ground station. In reality, this is a VERY large beam that covered a large portion of the earth.
5. The ground station converts the this to internet traffic.
6. Ground station sends data back to the satellite.
7. Satellite sends the data to the original location.

Who can read this traffic? It turns out that a cheap TV satellite dish with a card for processing the data is all you need. The researchers ended up spending about $400 for this. Using the tool EBSPro (used for finding satellite TV signals), a spectrogram shows the signals that come from satellite feeds. The card for processing the data can then be used to dump the raw data from the signal. The card has a card came with a tool called TBS recorder. The output is raw binary data. But, simply grepping for HTTP in this output shows us internet traffic! At this point, we can see private information, which is a serious security vulnerability. To make matters worse, this can be done from a different continent!

There are two main protocols for sending information are MPEG and Generic Stream Encapsulation (GSE). GSE is more common for maritime (boats), aviation and bigger clients. Past research focused on MPEG but this research built upon GSE. They built a tool called GSExtract that does a fuzzy search for HTTP traffic and can partially recover details with cheap equipment and bad streams.

What does this mean practically? None of the data for customers was encrypted by default. They essentially had the same viewpoint as an internet service provider (ISP). However, things get worse with maritime and other things. These customers used the protocol for LAN communication, which would normally be behind a firewall. Items such as LDAP, email and other things are open, editable and viewable. Even with TLS, DNS is still unencrypted.

As an example, the authors saw a ton of information about a lawyer. They could see private emails from themselves to a client, and the DNS traffic of the them, such as PayPal. Since they know the email of the lawyer, can see internet traffic and DNS, they could hit the reset password link on PayPal and take over the account. Damn, even though TLS is employed on HTTP traffic this does not mean that everything is secure!

Passwords to configuration operations, FTP services with electronic chart display and information system (ECDIS), point of sale (PoS) traffic with credit cards, GSM cellular devices on airplanes... All of this passive logging is absolutely terrible when looking at the bigger picture.

A particular interesting target was the aviation industry. When they started this research in 2020, everything was going well and they were viewing lots of traffic. However, the pandemic stops flights in their tracks, making their be way less traffic. But, there is silver lining here: less traffic from people using Instagram gave them almost ONLY operations of the airline or the airplane. This made completely possible (and a rare opportunity) to see how the satellite traffic of planes actually worked. Eventually, they were able to fingerprint the service for EFB on airlines and several other things. Interesting flip of the script!

Can anything active be done? TCP session hijacking! TCP has MANY random values that normally cannot be predicted as part of the three way handshake. By being able to do this, the traffic being sent down can be altered in some way. For instance, a website (not using HTTPs) talking to a ship could be altered to have a different response than what was expected. Even though we cannot send bad packets to the satellite itself, since we are apart of the internet, this creates a major problem.

How can we protect against these attacks? Simply just use encryption all over the place. DNSSEC, HTTPs and all that jazz are a good solution to the problem. When this is not possible, sending data over an encrypted VPN connection should be done. The authors were also building a tool called QPEP to still have good performance but encrypt the traffic.

The KVM (Kernel Virtual Machine) is a kernel based virtual machine. In the land of Linux, this is the built in virtualization platform. This vulnerability focuses on the SEV-ES (Secure Encrypted Virtualization - Encrypted State) functionality of KVM.

When a SEV-ES enabled guest triggers a VMGEXIT for a string I/O instruction, the function sev_es_string_io is called to copy the string between an unencrypted guest memory region and the virtualized target dev. When doing this copy, the size of the write and count variable (amount of bytes) are controlled by the attacker.

With this data is used, a memcpy is performed. However, the location being written to is limited in size to 0x1000 bytes! So, if we specify something outside of this range, for a write, then we have an out of bounds write primitive. In practice, size * count > 0x1000 is all we need to do.

A similar bug exists on the read side. Interestingly enough, the read functionality ALWAYS resulted in an out of bounds read if the value was greater than 1. That is sort of weird that this got through the code review process, as it was buggy from the start.

When running the kernel with KASAN (kernel ASAN) a crash occurs on both of these attempts; both for the out of bounds read and the out of bounds write. Why wasn't this discovered before? VMGExit is a shutdown function, which is not what is usually fuzzed. The more you fuzz the more things you will find!

A color profile is a set of data that characterizes a color input or output device, or a color space. In practice, a binary chunk-based format is used. The extension .icc and .icm are used for this. These files are common for embedded devices, making them good targets for attackers.

While fuzzing the macOS and iOS Apple ColorSync library the author found a crash. The crash occurs when using an invalid 8-bit input channel count field of 0. The issue causes a crash for reading at an invalid memory address.

The function first calculates the desired start address within a data point array, and then starts reading the data points in a loop. The address is calculated with the following expression: &lutAToB->CLUT.DataPoints[2 * x * y]. The variable y is initialized in a for loop prior to this access. However, if the amount of iterations in the loop is 0 then the variable is never initialized.

Since the variable is never initialized on the stack then it is used, the y coordinate can contain a large positive or negative value. If an attacker could control this value, it would create a very nice out of bounds read primitive.

Overall, this is an interesting bug! The value never gets initialized then gets used as an index. Even though somebody reading the code would assume the variable gets initialized in the for loop, this was not the case if the loop counter variable was set to 0.