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!

The author had found a vulnerability in the Linux networking stack called BleedingTooth. From there, they wanted a privilege escalation as well. While reading through old vulnerabilities like CVE-2016-3134 and CVE-2016-4997, this inspired the author to look for memcpy() and memset() in the Netfilter code. This is the start of the process.

When IPT_SO_SET_REPLACE or IP6T_SO_SET_REPLACE is called in capability mode, structures need to be converted from 32-bit to 64-bit in order to be processed. Since this is an error prone process, the author went through the code that does this translation.

The following code is ran: memset(t->data + target->targetsize, 0, pad);. The vulnerability is that the targetsize does NOT account for this offset in the allocation of the target data. This conversion creates an out of bounds memset() with nullbytes as a result. In particular, we can write 4 nullbytes to an offset of at MOST 0x4c bytes out of bounds. The offset is not DIRECTLY controlled by an attacker but can be influenced with different types of objects.

Notes on the primitive:

• Write 4 nullbytes to some controlled offset.
• The offset is NOT directly controlled. However, using different objects gives us the ability to influence the location of this; the maximum offset is 0x4c bytes.
• The GFP_KERNEL_ACCOUNT can vary in size. This allows for the changing of malloc slabs (similar to bins) that can be attacked.
• Only kernel objects with the GFP_KERNEL_ACCOUNT could be used because it uses its own slab.

With such a limited primitive, what are good targets? Reference counters, free list pointers and pointers within structs. msg_msg has the GFP_KERNEL_ACCOUNT flag and has been used in many many exploits. The author could not find any good reference counters so they went down the pointer route with msg_msg.

The field m_list is a linked list structure with a previous and next pointer. The messages are kept in a linked list. In general, the idea is to have a primary message in the 4096 slab (since msg_msg is dynamic in size) and a secondary message in the 1024 slab. This operation is performed over and over again as a spray in order to make the likelihood of exploitation higher.

Once this is setup, every 1024th primary message is freed to put a whole within the grouping of objects. After this, we trigger the vulnerability to overwrite the final 2 bytes of msg_msg->m_list.next. This will point the msg_msg next pointer to a DIFFERENT secondary message than where it should be. Since everything should be page aligned and we successfully sprayed, our exploit should be consistent.

Why do we want to point this? Now, we can free one of the message objects to create an unexpected use after free on this object. To make matters better, the messages can even be queried to know which one has been corrupted. Use after free achieved! Using socketpair we swap in a fake object to imitate the msg_msg object. By abusing a sort of type confusion here, the length buffer can be changed to a large size, which leaks memory from the heap.

Because this is a unix socket, the structure sk_buff will have a bad reference if we free the message this points to. This object is better for use after frees because the msg_msg object gets unlinked, requiring two writable pointers. If we get this reallocated and write to this buffer, we have a completely data controlled use after free. The author targets the pipe_buffer which has an object that points to function pointers.

The above use after free can be used to bypass KASLR. Additionally, the code pointers of the kernel can be leaked from this as well, allowing for JOP/ROP chains to be done. With this, a ROP chain can be developed with the overwritten function pointers. The ROP chain calls commit_creds to install kernel credentials and switch_task_namespaces(find_task_by_vpid(1), init_nsproxy) to change the namespace of a process to be the same as the initial process. Game over!

Overall, I enjoyed the diagrams and exploit explanation. The bug is subtle and it is amazing to see how this bug was taken to code execution.

BeReal users receive a single notification en masse prompting them to take two photos — simultaneous images, shot through the front- and back-facing lens on their phone cameras. Everyone is given two minutes to take the photographs, which are then shared with their followers on the app. This is the purpose of the new social media app.

The application had some privacy issues. In particular, it was sending the exact longitude and latitude of the location of a picture. Additionally, when posts are public, the feed is randomly generated to users with 10 in each request.

The random feed is a little scary, since data like gender, hair color and other personal information can be found quite quickly with these public posts. This is because the posts have a photo that was just taken by the user.

The author came up with a SUPER interesting attack for the /friendSuggestions API. If you only pass one friend into the friends parameter of this request, then this basically reduces to just finding all of the friends of the given friend that we pass in. Interesting! So inherently, you’re telling BeReal (and now, let’s say, everyone) who your closest friends are

Privacy is hard to do and the expected data to be shared needs to be defined beforehand. This is a good example of that.

The firmware is "something that doesn’t change or something that is not likely to change"; being firm! In the context of our modern computers, this is everything below the operating system (OS). There are many articles on making a BIOS; so, I will point out a few of the interesting points or new things from my end.

The boot process is fairly simple:

1. CPU runs the firmware on the ROM chip of the motherboard.
2. Firmware does a Power-On Self Test (POST) on all hardware components before activating them.
3. A bootable drive is foudn and attempted to boot. This section always ends with 0xAA55.
4. The bootloader loads into the address 0x7c00 in RAM, with control going over to this.
5. The bootloader will hit the OS loader to boot in the kernel.

The author goes through an awesome setup for getting this going. Namely, they use nasm as an assembler and qemu for emulating the computer.

They go through the process of writing a bootloader that will print some text to the screen and nothing more. A few things are worth noting though: the file must be exactly 0x1FE in size, with the final two bytes being 0xAA55. The other interesting note is that the instruction [org 0x7c00] will tell the assembler (nasm) to load the program at the address 0x7c00.

What are interrupts? When the instruction int 0x# with # being an actual number is called, this will generate a temporary halt of the CPU to run special instructions. Within the Interrupt Vector Table (IVT), there is a list of function pointers that will be pointed to Interrupt Service Routines (ISR).

The ISRs are initialized by the firmware and are created by the manufacturer of the CPU itself, by default. This is special machine code that is executed whenever an interrupt is executed to do things, such as display characters on the screen and many other things.

Overall, good article on some things that have always felt like black magic before! I would recommend going through the complete process of writing the bootloader, to get an understanding of it.

The author of this post was looking into a private program that offered a network monitoring solution. While running some basic tests and clicking around through the app, they noticed an endpoint that sent a full PDF copy by email of a web page.

In the request, there is a query parameter called location that has a full URL path inside of it. Since this was an authenticated endpoint, they assumed this was a SSRF bug waiting to happen, where only the PATH was controllable; the domain was being set somewhere else.

What can you do while only controlling the path? There is a well-known trick that uses the @ in order to change the domain of the request. When an @ sign is used, the FIRST part is the username/password is the data after the @ sign becomes the domain. So, by adding this character, such as example.com|my_path to example.com|@my_domain.com| will change the domain used.

The author of this post then starts getting complete screenshots, via email, of whatever page they want. More importantly, this is on the LAN side of the network and has authentication on it. We need impact now though! They tried things on localhost, but nothing came up. So, they searched Github and other places for internal domains only to find an instance of Redash running.

For whatever reason, the credentials were being auto-saved into the login page of Redash in plaintext. According to DayZeroSec, it is fairly common that credentials are auto-filled on internal sites for convenience.

While manually looking for more things, they found an instance of puppet. This is a software used to manage the infrastructure of server configuration and other things. By looking at this, they were able to find all other domains on the internal network including kibana, grafana and many other things.

The author then have an extremely clever idea: the request being made takes a screenshot of an authenticated page, has a user provided email and is a GET endpoint. What does all of this mean? It is the perfect candidate for a cross-site request forgery (CSRF) attack!

The CSRF bug is absolutely amazing! Since this makes an authenticated internal request as this user, requests for settings and other things can be taken. To make this even worse, this can be done blindly and at scale.

But, here's the final icing on the cake: if we use the original @attacker.com trick from before, we can make a request to our own server. Now, this request will have the header X-CH-Auth-Api-Token attached to it, which allows us to have the API key of the organization.

I had never thought about using the @ symbol with domains. Since it is common to only control the path of a request, I will keep this in mind! Additionally, the two ways they went about exploiting this were amazing; either one of these was of horrific impact.

Cortex XDR is a detection and response system by Palo Alto Networks that is installed on user machines. An actor, with control over the machine, should not be able to remove this.

To disable the agent, a single registry key needs to be modified. Since the permissions are not set properly on the registry key, anybody can modify the string ServiceDll to disable it.

Cortex XDR has various global settings. The tool cytool.exe has the ability to do important thing as system, such as disable the protections and many other things. By default, this has the password, Password1. If this is left on, anybody can disable or uninstall XDR.

Even if the password is changed, the hash is stored locally and it can be cracked. However, this uses Argon2, which is hard to crack. This can be done by using the Generate Support File, which creates a dump of the persistence folder, which has the hash in it.

Overall, good finds! Sometimes, the people making security services do not care much about security themselves. These are all simple logic or access control bugs.

UI misrepresentation is an attack that is not commonly used but can be impactful, such as UI re-dress attack.

When a message in Signal, WhatsUp and other things contains a valid URL, then it is colored and marked as a hyperlink. However, this is printed to screen before sanitizing Unicode Control Characters, which results in URI spoofing via specially crafted messages.

RTLO (right to left) is a unicode control character that reverses the display of the text. In the case of iOS, WhatsUp and other things, we can trick users to click on a malicious link but make them believe the link is going somewhere else.

For example, use the RTLO character followed by a link such as gepj.net/selif#/moc.rugmi. However, after the RTLO does its thing in the display, the link is reversed into imgur.com/#files/ten.jpeg for the display. As a result, a user would think they are going to imgur.com when they are really going to gepj.net.

Overall, interesting finding that affected most platforms. Control characters are an important thing to consider while on a pentest.

AWS Relational Database Services (RDS) uses Amazon Aurora PostgresSQL. This is a hosted database service that are meant to ONLY be used for the database and nothing else. A user can interact with the psql shell to do things to the database.

The author tries some really simple attacks, such as write to or read from a file. However, the author quickly notices that the highest permissioned user is not accessible to them. As such, their current user cannot do a multitude of things considered dangerous, such as read local files or run system commands.

Time for more recon! After diving into other parts of the setup, they noticed a default extension called log_fdw. To use this feature, a log file can be selected for both reads and writes. Unfortunately, there is validation on the file names, making it not possible to exploit off the bat. How do these extensions work?

PostgreSQL allows access to data that resides outside of PostgreSQL using regular SQL queries. Such data is referred to as foreign data and is accessed with help from a foreign data wrapper to access things like files. There are three fields that must be defined: handler, validator and options.

The log_fdw code has both a validator and a handler. Since the validator is not 100% necessary, it can be removed. Once this function has been removed, arbitrary files can be read on the system!

While exploring the file system, they noticed a reference to a file that had the word credentials in it, which had an access key, secret access key and a session token. Finally, they used the STS API to get the caller identity. At this point, they realized this gave them access to the internal account so they stopped hacking.

Overall, awesome finding within a fairly locked down system. Sometimes, third party updates are the killer, even though your code is secure.

The bcm61650 is a 3G femtocell. A femtocell is a cellular base station that is commonly used at homes or a small businesses. This particular one allowed for a connection over a DSL/fiber line.

While in the box, the board presents itself as a PCI ethernet chip. The board present itself as a pci ethernet chip, that performs a bootp and load its firmware over tftp. Then, it connects to a hardcoded IP to establish an ipsec tunnel to the core network. To make their life easier, they desoldering the link between the Ethernet chip and the BCM61650.

With a few probes, the author managed to get the board powered and booting. Luckily for us, there is a nice UART output that we can see. The author wanted to boot their own firmware; however, the firmware loaded over TFTP had a digital signature, making it impossible to alter.

With the OS image in hand, the author extracts it with binwalk. In /etc/passwd, they build a nice hashcat rule to break the password. To his amazement, the password is completely empty!

Once they have access to the image (I assume over UART but it does not say), they load a kernel driver to the system. According to them, the classic dd command did not work on /dev/mem for whatever reason. With access to the ROM, they can now check out the firmware verification process.

After reversing the code for a while, they think the whole verification process is secure. This leads them to their OWN tweet: "When your rooting of a device implies breaking RSA or sha256, it's time to realize you're doing it the wrong way, and to be creative."

The code for loading the information for the headers of the firmware takes in a user provided length. From this length, it performs a memcpy into a static buffer. Below the data that we are copying in, is the stack pointer!

By smashing the stack with the perfect length, the $RA register (used for return address in MIPS), can be smashed. By overwriting this to the full bootloader process, the signature verification can be completely bypassed. From there, they patch the bootloader itself to skip the kernel verification process. Boom!

This turns out to be an unpatchable ROM secure boot bypass from memory corruption. If you do not program securely then the crazy crypto does not work! Good read but I wish some background/details were added for clarity, such as HOW the command line was being hit, which I assumed was UART.

The Sound Blaster X7 is a Digital to Analog (DAC) converter and amplifier. It takes several inputs, mixes them into a single output. There is an Android App over Bluetooth or (for Windows) over USB. The author just wanted to change their audio on their headphones!

To capture Bluetooth traffic on an Android device, there is a cool setting to output Bluetooth into a pcap file: Bluetooth HCI snoop log. The author then takes captures with VERY specific actions: on, volume up, volume down and off. This is to KNOW what each command does.

Once in Wireshark, viewing the pcap file, they had a bunch of character encoding issues (lolz); after they installed the right fonts ,every became better. The Bluetooth packet was showing RFCOMM as the information in the packet.

What do these values actually mean? 5a29050001000000 is change output to headset but we have NO idea what this means. Luckily for us, Android apps are super easy to reverse engineer using Jadx and APKTool.

From reversing the application, here is what they picked up on the format:

1. X7 Control packets start with 0x5A.
2. The second byte is the command ID, which seemed to always be 0x29.
3. The third byte is the LENGTH of the packet.
4. The rest is the command payload.

For the commands get/setSpeakerConfiguration, the first byte of the payload determined if this was a READ or a WRITE. The rest of the data, for setSpeakerConfiguration, was for changing the specific settings, such as changing the speaker being used and advanced settings.

Muting is done with the command setHardwareButtonState (38), with a byte for the button ID. Apparently, this code is reused for other applications, since this had MANY other hardware buttons that did not exist on the regular device.

The tricky part was the VOLUME. The volume being in dB, a logarithmic scale, definitely caused the author problems. First, replaying didn't work perfectly, with the same input producing different outcomes. Originally, they tried to use a percentage, which doesn't make sense in the logarithmic scale.

The inputs ended up having REALLY complicated formulas to get the actual output volume. In the end, they figured out that it was an INCREASE or DECREASE, instead of an actual value. Since this was keeping state, it made things a tad more complicated.

Overall, fun reversing project with practical implications. I appreciate the Bluetooth reversing notes!

Netgear is a popular router that is made by Comcast. While looking at attack surface analysis on the WAN interface on the Nethawk Smart Router, they noticed an already reverse engineered binary called /bin/circled. The daemon is started by default, even when turned off on the router.

They decided to target the update mechanism of this service. The check is launched at boot and every two hours; in the event of a crash, the process restarts.

The function update_database located at 0xCE38 parses a file in order to check if any updates apply. While parsing the lines of the update file, it uses sscanf to write two strings into buffers of size 256 each.

The vulnerability is that sscanf will read until a space has been found. As a result, this leads to a stack based buffer overflow. The overflow is good enough to corrupt the $PC on the stack.

To get the file for updating, it makes a request to curl. However, although the update request is made via HTTPs, the request has the -k flag, which disables certification verification. This means that the vulnerability for updating can be triggered if we can somehow control the response to this request.

In order to exploit this, the authors of the post setup a DHCP server for the Netgear routes. By doing this, it is easy to setup a DNS server and an HTTP update server as well. Since the -k is in the curl command, there is no verification on the certificate, making this attack possible.

A few things to consider for the exploitation of this bug:

• ASLR is only partially turned on (with a 1 instead of a 2) and without PIE
• Nullbytes cannot be written, this this is done via a format string.
• $R4, $R11 and $PC are the controllable registers in this request.

The authors found a magic gadget that allows them to control a parameter while calling system. Since this vulnerability was able to be hit twice, this allowed for the usage of a SINGLE nullbyte.

Although the heap is not randomized, we are not 100% sure where the string will be at but we know that the string will be in memory. As a result, they use a NOP-sled-like attack. They put a HUGE collection of As then a semi colon which is followed by the actual command. If the string hits any of the As, the first command will error out, resulting in the ACTUAL target command to run. A NOP sled for a bash command!

To patch this vulnerability, Netgear removed the -k switch and modified the parser to no longer have the buffer overflow vulnerability. To me, this felt weird for a Pwn2Own entry because it had limitations on WHEN it could be executed with a complicated networking setup. But, overall, great and fun write up!