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!

When my wife and I were expecting our first child, a good baby monitor was one of the top items on our shopping list. They decided on the Motorola Halo+. The security of a baby monitor is important; you do not want creepers looking in.

After reverse engineering the Android application, the author found a command injection on the device via the set_city_timezone function. They used a reboot command to see if the attack had worked.

The command injection would process spaces from the URL as %20 instead of a space. As a result, they had to use {IFS} for spaces in their command injection payload.

While doing additional research into how the MQTT API worked, they went into the MQTT explorer. Immediately, they started seeing messages from all of the other devices! The credentials must have been shared amongst all of the devices, which is horrible.

Good bug description and reverse engineering!

Jetbrains Datalore is a data exploration tool that can be built into Jetbrains, as an alternative to Jupyter.

While toying around with one of the authentication endpoints, the author found an open redirect vulnerability. By itself an open redirect vulnerability is not very impactful. However, if this can be chained with other bugs in the auth process, it becomes a big deal.

The endpoint that initiates the redirect to datalore (which has the JWT token) had a parameter that only had to be a subdomain of the Jetbrains URL. Remember the open redirect? It could now be useful!

When doing the first redirect, the JWT is added onto the location (straight appended). At this point, the redirect with the victim JWT goes to the endpoint with our open redirect.

Since the JWT is appended to the URL, we can append it to the URL with the open redirect, to eventually get it back. The name of the article is this way because the URL with the open redirect MUST have a valid JWT. To satisfy this condition, they pass in their own JWT.

Overall, the chaining of bugs is interesting! Parsing strings is hard to do and open redirects may be the starting of something huge!

For PWN2OWN 2021 IoT edition, this team decided to tackle the Western Digital PR4100 NAS. They targeted the APIs, which used the command gateway interface.

The authors found a fairly straight forward buffer overflow vulnerability when handling passwords. The overflow occurs because of a strcpy, which never checks the length of the buffer. Because there is NO PIE and no Stack canaries, this should be trivial to exploit.

At the point of the overflow, many of the registers are controlled, one of them points to free in LibC and two of them point to the stack. The overflow can only have a single NULLbyte at the end, because it's a strcpy. This is where exploitation becomes hard and fun! With no way to control a parameter to System some magic had to be done.

Since the password was base64 encoded, the original string could contain nullbytes. The new goal was to use a stack pivot to point the stack to where our base64 decoded password is at in order to set RDI with a nice string to call system.

After finding ROP gadgets to do actually this, they had a command via system with 47 characters. To do something impactful, the authors pushed a static netcat binary into the /Public SAMBA share and called this. Game over :)

A few ending remarks:

• WD Digital patched this bug right before Pwn2Own, which they were not happy about.
• WD equipment is similar to DLink NAS devices since DLink started to wind down this product division and sold it to WD. As a result, if bugs are in DLink NAS's, check WD as well.
• eb fe is an infinite loop in x86_64 assembly. This can be a good debugging trick for exploit devs.

Parallels Desktop uses a paravirtual PCI device called the Parallels ToolGate for communication between guest and host OS. The request format is a variable sized structure. The guest sends data to the host as inline bytes or pointers to paged buffers by writing the physical address of the structure.

If the size provided by the guest is more than the total size of the stack, it is possible to shift the Stack Pointer (RSP) into other regions of process memory. This vulnerability class is known as a Stack Clash vulnerability.

When handling a specific operation, the application does not validate the ByteCount provided as part of the buffer. This value is then used to increase the size of the stack prior to writing data into it.

After finding this vulnerability, the authors wanted to do taint analysis and look for other cases of this bug. Most stack increases have a static size; for those that are not static, Binary Ninja marks this as UndeterminedValue. By searching for these occurrences it was possible to find 2 other variants of this bug in other places!

The authors dive into a mitigations to prevent Stack Clash issues. In particular, they mention called -fno-stack-check on MacOS and iOS. This mitigation is for calls to alloca or a variable length array. When incresing the stack, instrumentation is added to validate all allocation requests to be to valid stack memory, require an increase or crash safely. This was not included in the binary.

The author does not mention exploitation at all but points to the Qualys post linked to above; this post has a bunch of information relating to the exploitation of these types of bugs, specifically on Unix based systems, with many interesting examples. In order to exploit this, the Stack Guard page needs to be skipped. Even though we have a buffer length to jump to another part of memory, we cannot write to the bulk of it.

This video is a demonstration of hacking a garage door remote. While trying to find out more about Penthertz, I stumbled upon their publications page which has dozens of other articles on hacking with radios. If you are looking to see hands-on radio hacking, this is an amazing place to be, since this guy is a wizard with GNU radio.

In real time, the creator of the video creates GNU radio flows to do a bunch of things. At the beginning, they use a QT Sink to show the data with the remote and slightly increases the frequency in the sink until the proper frequency is found. They use the max hold and waterfall view to see how the data is formed, which clearly gives away two main points that are binary encoded between the two points. Since there are two frequencies being used for this, it indicates that FSK or frequency shift keying is being used.

To decode the data, you can use the FM (frequency modulation) or the quadratic demodulator. The FM demodulator is simple and easy to use, but the author elects to use the quadratic demodulator to make the demoulation more precise. In this step, they also add an import block to add the math package in GNU radio, which I had no idea was possible!

With the timing changes and error that is inherit with technology, the author needed a way to decode this properly. As a result, the symbol sync which helps found the symbol rate. Additionally, there is a deviation factor to handle the clock drift, a squelch control (muting a channel with nothing on it) automatic gain control and a threshold block to handle the slight differences that are not caught from this block. At the end of this section, the author just turns on Inspetrum and universal radio hacker (which decoded the signal easily), since doing it automatically or by hand is easier than using GNU radio (lolz).

URH protocol features are nifty! It shows the comparison between the two recording, support for seperating parts of the protocol (header, footer, data, fixed, padding, etc.) and many other features that help with analyzing. From looking at the changes, the author notes that this is a rolling code, since some of the values are different between two different clicks of the same button.

Microchip based remotes use KeeLoq, which is an encryption block cipher used all over the place. By using a hopping code with some data encrypted over the wire with a unique counter, replay attacks are not possible. An additional technology is a challenge-response called IFF (Identify Friend or Foe).

Against Keyloq, there are a few known attacks though.

• RollJam. There is no timestamp. As a result, an attacker can record the signal when sent but interfere with the signal going to the receiver. Since the signal was neve received, a replay will now work!
• Cryptoanalysis
• Extracting the key from the firmware.

DOR is a process for cloning remotes over the air. In practice, this passes the state in the rolling code to the remote. Of course, being able to sniff this code as an attacker is the dream, as this would allow for another remote to be created to put this onto another remote.

Can we do this with a remote? Yes we can! A recent project has came out called Kaiju for breaking rolling codes and generating rolling codes. In the demo, only a single capture was needed in order to get the next value in the rolling code for the device. Damn, that is terrifying! Keeloq does not feel secure against more advanced attackers. I feel like I'm missing something on why this attack works here.

The Windows Lock screen on an open computer is what makes physical attacks hard. Otherwise, an attacker could waltz right in and steal all of the information on the computer.

A post in Jonaslyk described a flaw in 2020 that allowed for the settings to be hit via the sticky keys pop. Once in the settings, it is trivial to pass the lockscreen.

From this finding, the author was curious if any other bypasses were possible and testing many features. If a computer has a Microsoft account hooked up to the computer, this can be used to reset the password on the computer.

When typing in a wrong password, a small arrow appears next to the email address. By clicking on this icon a pop up with a link appears about using physical security keys. Clicking on this link does nothing! What if this opens up the settings in the background?

The original post mentions using narrator to help navigate what is going on. Since the page is in the background (and not seeable), it is really easy to miss this! This opens the how to open screen. Using the narrator, we can open Microsoft Edge to open up the settings to do malicious things!

To make matters better for the attacker, the user is NT AUTHORITY\Authenticated Users! So, we can do whatever we want on the computer we full access.

It is insane that these bugs still exist in such mature operating systems. Interesting article on a Kiosk-like escape.

Bhyve is the hypervisor used in BSD Unix operating system.

In Bhyve vtrnd is an implementation of RNG, a paravirtualized device that is exposed as a hardware RNG device to the guest. he randomness values are transferred into the guest memory by reading queues defined by the guest by using vq_getchain to fill a struct iovec structure with the memory ranges specified by the guest.

When calling functions in vtrnd, it is very important to check the return value and check it properly. There are multiple occurrences of NO checks of this return values and signness conversion issues.

Issue #1 describes that the iovec needs to be initialized and check the amount of file descriptors there are. However, since the return value is never checked, this can be used without ever being initialized. If the right data can be put into these locations, major memory corruption could be caused.

This same issue exists in other spots for Issue #2, #3 and #5 as well.

Issues #2 and #4 have to do with integer conversion. The return value is a signed integer from the function. However, using the value as an unsigned integer and returning the error case of -1 would be a problem.