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!

There are a BUNCH of vulnerabilities in this. I will only touch on the unique/interesting ones.

Netgear has a protocol called Netgear Switch Management Protocol (NSDP) for network protocol discovery for switch configurations. The protocol authentication has two steps: asking for a random token and using this to generate a hash that will be used for authenticated requests.

If the first step is skipped at reboot, the random value is 0x0! Because we know the random value, we can send authenticated requests. The author shows a few ways of crashing the switch, making this a viable attack.

The firmware updating was done quite poorly. First, the firmware updating was not authenticated, which could allow for any signed version of the firmware to be put onto the device. Although this does not sound bad, downgrade attacks can common to use if a product has a previously known vulnerability.

Even with the validation check, it was not done properly. When validating the new firmware, the real file length can be spoofed and the maximum size of the firmware was not properly validated. Because of these oversights, the signature validation could be bypassed to add custom code to the device.

The device had some issues with authentication as well. The DHCP configuration functionality was completely unauthenticated and there was an information disclosure on the NSDP protocol.

Besides the items listed above, there were a plethora of general web app issues (XSS and CSRF), as well as several buffer overflows.

The IoT space is known for horrid security practices. So, this author decided to do some research into CCTV cameras.

The bulk of this attack comes down to spoofing in the architecture. When a device is camera is registered, it sends the server the details, such as the MAC address and cloud device ID. Now, the source IP is associated with this device ID.

When a client wants to see the video, the server tells the camera about a relay server and connects there to stream the data. This validates sends the username and password that the user provides prior to streaming.

Because of all of this logic, the author was interested in the registration functionality. What if you spoofed the registration under a different cloud camera ID and handled the relaying process? Because of we now control the camera, when a user tries to login, we can steal their credentials and stream their camera.

At this point, the author wanted to be a meme. So, with this far into the process of becoming a camera, they decided to inject video feed into the stream with the spoofed camera. The final video shows him launching this attack to freeze time like in National Treasure. It's pretty awesome!

The camera only requires authentication remotely. If on the same LAN as the camera, port 554 (RTSP) can be used in order to stream the contents of the camera directly.

Overall, this is an interesting attack that is different than pop a shell while still being effective. Business logic issues can be the worst bugs, they just require a deeper understanding of the system being used.

F5 Big IP allows for network traffic control and several other features. Naturally, this requires a bunch of data processing in order to do properly.

When processing response headers, there is a function that attempts to match if this is something that can be returned. While doing this processing, there is an integer underflow in a size validation. Because of this underflow, the validation does not work, this turns into a buffer overflow.

The F5 Big IP does not have any standard mitigations, such as ASLR or NX. Because of this, once the overflow occurs, shellcode can be embedded into the process to pop an easy shell.

The bug is complicated to trigger, as an attacker would not have direct access to the size of the response. So, this would take further steps in order to exploit.

SerenityOS is a Unix based hobby OS led by Andreas King. Because of it being an OS and relatively new, people love to look for bugs in it!

The vulnerability is a bad bounds check on a variable length array (VLA). The size provided from userspace (to the kernel) does not have a sanity check. The memory being written to & from has a check to ensure that the memory is in user space though.

VLAs allow us to dynamically change the size of our stack frame by altering the esp directly. This is done by taking our value and subtracting it from esp (sub esp, VALUE). The VLA acts funny when the change is larger than the stack itself!

By setting the size to a very larger value, we can put the esp to an arbitrary location in memory. This is awesome because the next usage of the stack will use the esp from this extremely weird allocation. Because we control the values being written, we can overwrite arbitrary data on the stack for a nice arbitrary write primitive!

There is one issue though: our original size being used will cause a crash to happen and end the process, removing the ability for this primitive to be used; this is a common wildcopy problem. So, we pass in very large size for our buffer but our buffer is not actually that big. This causes the syscall to gracefully exit because the buffer hits unmapped memory. This is a good thing because the exit from a userspace issue does not cause a kernel panic.

By using this primitive, we can overwrite the stack of other threads within the kernel! The easiest, and most reliable, is overwriting the kernel stack pointer for another thread when calling sleep. This allows us to always know what will be overwritten and consistently win the race. Once we overwrite the ESP of the stack frame, a ROP chain can be trivially created to become root.

I had personally never thought of exploiting VLAs like this before. It requires a very specific circumstance to do but is deadly when done properly.

All the way back in 2006, a vulnerability was found in the Apache Module mod_auth_kerb. The ISC BIND server (most popular DNS server on the internet) shared the vulnerable code in the SPNEGO component but was the patch was never merged.

At the beginning of a function, an allocation is used in order to get heap memory. After this, two indexs are set but only one subtraction on the length (more of a max size) variable occurs. Because of this off-by-one error, a single integer overflow occurs (4 bytes).

The article includes a description on how this could be exploited on GLibC 2.27. As a note, heap grooming in quite easy, as we control the amount of iterations on a loop and can free chunks at will.

To get an arbitrary write, the following is done:

• Use the buffer overflow to overwrite the chunk size of the next chunk.
• Allocate & free the corrupted chunk on the next request. Now, we have a chunk overlapping with a free chunk in a different tcache bin.
• Overwrite the 'fd' pointer of the free tcache chunk to set it to an arbitrary value. Once this is allocated, we will write to any location we want!

Because all Linux mitigations are enabled by default for BIND, we need to defeat them. The author includes a potential way to get a leak via a tcache dupping technique but it was unsuccessful because malloc would eventually abort, resetting the randomness.

This article rediscovers a 14 year old bug in a popular piece of software. This makes me wonder if there are other dependency issues in popular open source software that was never patched; the answer is probably yes!

Palo Alto SSL VPN is used to separate the corporate environment to outside attackers. It requires access to the VPN to even get on the internal network in the first place. Because the VPN itself has to be on the internet, this is an amazing attack surface which would be a high impact if something was found.

In C, format strings are used in order to dynamically add content to a string (printf, snprintf, etc.). However, what if the user can supply a format string? This is the bug! Because of an improper amount of parameters being passed to the function format string vulnerability was found.

By adding a format string (%n, %s, etc.) to a processed string, data can be read or written to at will! This bug class is almost dead (probably because compilers tell you this is a major security issue). But, if found, this vulnerability is enough for a read/write primitive by itself!

To verify this server on the backend, they initially for used a %n to crash the server. To the authors, this was not enough though. So, they sent 9999999%c in order to induce huge time delays to determine if this was a legit bug or not.

In order to exploit this bug, they use the %n specifier to overwrite the Global Offset Table (GOT) to be system. Now, we can trivially pass in a command, which will be ran in the terminal, to pop a shell. There appears to be no PIE on this binary, making this attack easy to exploit.

Palo Alto had recently found this bug and fixed it without telling anyone though... So, a CVE was never released and Palo Alto did not prompt anymore to update. Eventually, Orange Tsai and the crew found that a Uber server was vulnerable to this attack and compromised it. Posting about patched vulnerabilities is important!

Information disclosure vulnerabilities are not nearly as sexy as gaining control over the flow of execution. However, with modern binary protections that provide randomness, such as PIE and ASLR, memory leaks are a crucial point in the exploit chain.

PDFs have a section called the trailer. This is used for making application reading the file (Reader) have easy access to objects via cross-references. This is implemented as a key-value pair.

The exploit uses a field called ID and writes an extremely large value in it. The vulnerability occurs when processing this data.

The ID field is stored as a fixed sized value of 0x100. However, clearly the user controls the actual size when this gets operated on. At this point, the actual value is on the stack (truncated to 0x100) and a heap allocation is made of the large size (0x400).

When a memcpy is ran on this to copy the stack buffer to the heap buffer, a 0x300 byte OOB read occurs! 0x300 extra bytes, which can be queried by the application, allows the user to break ASLR and find the locations of Windows libraries.

When inserting an avatar link for support chat request, there is improper validation. Instead of strictly validating the domain it just checks if the domain contains the URL. Because of this, a user controlled link to an arbitrary server can be provided.

There are two ways to exploit this. First, because than attacker can control the link, they can see the IP address of the user. This creates a privacy violation that could be used in other attacks.

The second way to exploit this is a persistent denial of service (DoS) attack via a logout CSRF. By setting the avatar to be a logout request, the support agent is locked out of their account. To make matters worse, the avatar was loaded for all support professionals! Damn, that is an impactful DoS.

In a previous attack of fwupd, an S3 bucket was used to add files and signature bypass for the uploaded files. However, the signature validation vulnerability was expected behavior according to the developers, as the devs of the project (not the library) were claimed to be at fault for improper usage.

When checking for detached PGP signatures, the function can return a non-NULL pointer that contains a list of 0 signatures. In practice, the non-NULL value may be interpreted as a valid signature.

After seeing this, the author of this paper decided that this mistake must have been made in other places as well. So, they took to an open source code query engine to help find potential vulnerable cases of this being used.

With the search engine, they found at least 6 other cases of this function being used in an insecure way including in PhotonOS. This signature bypass could have been serious!

Overall, developers of the library re responsible for making code secure out of the box and not requiring expansive security knowledge. There is a reason that React and other frontend frameworks block XSS by default now-a-days.

Visual Studio Code is a common text editor used by developers. Because of this, downloading repositories and viewing the content in the repo is common.

By setting the npm.bin key of a project in the settings.json to a malicious script, viewing the package.json will execute whatever we point it to, such as a bash script. This vulnerability is bad because it breaks the assumption that source is safe to read.

Although this requires downloading a repo and opening a specific file, this attack could have been used in targeted attacks, such as the one against security researchers recently. Being able to control scripts being ran while just viewing code is a serious threat.