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!

CVE-2022-0435 is a remotely triggable buffer overflow in the Transparent Inter-Process Communication (TIPC) stack of the Linux kernel. Within the structure tipc_mon_domain, there is a field that holds an array of domain records (u32 members[64]); a domain record is the network topology. However, the bounds of the array being written to are never checked.

What are the constraints on this overflow? Several of the fields, such as len, gen and a few others have constrained values. the members field, with our overall, can be arbitrary. The author says that this exploit would require an additional vulnerability to break KASLR and the stack canaries.

This overflow takes place on the stack and the author is exploiting a x86_64 machine. As a result, we can control many of the registers being replaced at the end of the stack frame, including the RSP and RIP. Since NX, SMEP and SMAP are turned on, we have to be clever with our exploitation. This is done by calling set_memory_x($RSP & ~0xFFF, 1) in order to make the stack page executable. Once this is done, we can execute our shellcode from the stack overflow before.

Are we done? Not really! We still need to clean some things up first. The author puts a few things into consideration: stack frame clobbered and locks that need to be released. With this, we can fix the locks and frames, then jump to the closest non-destroyed stack frame.

Even once we have cleaned up the code, we still need to get into the process context. Apparently, the networking stack is completely isolated from this. In order to hook into the userspace, syscall hooking can be done. Once a syscall has been hooked by writing to the sys_call_table, we can execute code in userspace.

The author of this post added shellcode to add custom code to an arbitrary userspace process in its own mmap program. Interesting stuff to write an remote exploit for the Linux networking stack.

The mitigations heavily restricted this; the remote nature made this much harder to exploit. In particular, the stack canary and KASLR caused problems. Overall, good write up on a Linux Kernel stack based buffer overflow and the exploitation of it.

Virtual Box is an open source virtualization platform. This post goes into getting a suitable environment for research into this. In particular, this post goes into creating a debug build, setting up AFL instrumentation (which is harder than you think) and setting up a harness. Something I may need in the future!

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.