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!

Apparently WiFi Direct is a specific for P2P transfer over WiFi. Who knew!? These P2P communication protocols have several severe issues.

The LG SmartShare Beam had issues with authorization. In particular, a session ID was not required for transferring from one device to another. So, you could force send force to users devices with arbitrary names.

The Huawei Share was trivial to crash. Because of this, an application (running on the device), could purposely cause a crash on the file transfer server then bind their own port to this service. At this point, you can serve your own files using this API. Interesting attack scenario!

Xiaomi Mi Share was the most secure of the bunch. There was a DoS by sending a crazy large file and session tokens were 19-digits long and generated by the weak Java Random implementation.

Overall, the read is enjoyable. I appreciated how crashing the service actually turned into an exploitable vulnerability that was NOT just a DoS.

Docker is a container that allows code to run anywhere in a mostly safe way. Besides this, it acts as a sandbox from the regular machine. Being able to go from container to host is a huge vulnerability

A socket is a mechanism that allows communication between two processes via network communication. In Unix, these are represented with a file path. However, there are also abstract sockets which are a little different. Regular sockets cannot be connected through Docker; but, abstract sockets can! This creates a little attack surface for us.

Abstract sockets (unlike regular sockets) do not have access controls tied to the Unix file permissions; these permissions have to be implemented by the creator of the abstract socket.

There is a particular abstract socket that is interesting: containerd-shim. This has a custom binary running on it that is accessible from the container. The tldr; is that by using this binary (over gRPC) it is possible to compromise the host process!

But why is this possible? The only validation is to check if the user connecting is the SAME as the user in containerd-shim. Normally, this is root. Additionally, the user using in the container is ALSO root. So, the gRPC thinks that this is the same user, allowing us to connect.

The article goes into how to escalate to root on the host from the API. There are several ways to go about it but they all stem from using the Create or Start RPC calls. The only trick (discussed in the article) is getting a proper configuration file to this startup process. Once this is done, a container that runs with the --privileged flag can be used to gain root access.

In the future, I will look out for abstract sockets, as they have different security implications than one might expect.

The Desktop application has a localhost application that can be communicated through web sockets. Web sockets do not follow the Same Origin Policy (SOP) so data can be altered and returned from this location arbitrarily. An attacker can have their website loaded and talk to the application because of this.

The second issue is that the websocket communication line has a lot of control on what the Desktop app does. In particular, it can be used to open arbitrary sites on the Desktop Application.

Finally, PlayStation Now uses Electron. With the ability to load arbitrary websites into the Desktop App, this sounds like a disaster waiting to happen... well, it is.

Electron is based upon NodeJs. There is setting to disable NodeJs integration on the application; but it is not always set (in this case, it was not). So, by loading a malicious website, it can be used in order to run commands on the local system using Node.

Using these three issues together (lack of CSRF on webssockets, arbitrary URL load & Node Integration Turned On), a CSRF RCE was possible by simply visiting a malicious actors website.

Watch out for the SOP! It provides a lot of protection, but not on everything.

CSRF allows an attacker to make request on behalf of the user upon visiting the attackers site. This is mitigated by having large and random values called CSRF tokens that are sent with the request. The trick is that the tokens are NOT known by the attacker.

Finding a way to circumvent CSRF tokens commonly leads to account takeovers.

In this case, the CSRF tokens had a specific structure and were validated based upon this structure. --encoded-string--:--encoded-string--:--encoded-string-- with a length validation somewhere in there.

Because of the complicated CSRF token format, a bunch of validation had to be done. This included if the token is session tied, validation of the format itself, was the token cross-account... and other things.

However, if the token had an invalid length an exception occurred that was NOT caught. Because of this lack of exception handling, the token verification passed!

This bug was found by accident when the author of the vulnerability removed the first character on a copy and paste. What does this mean? CSRF tokens are vulnerable to logic bugs just like anything else. Sometimes, messing around with the size, characters or anything else can lead to an unexpected bypass.

C++ programmers convert between types as often as they go out for beers. The C++ compiler has few built in protections for catching insecure type casting. Because of this, C++ type confusion commonly leads RCE, especially with C++ virtual function tables being some prevalent. The bug class type confusion is the focus of this con talk.

In C++, there are multiple ways of casting but we will focus on two: static_cast and dynamic_cast. With static casts, a check is done at compile time to convert a pointer of one type to another. Static casts ONLY checks for a feasibility check for the type in the class hierarchies. Dynamic casts have a runtime check (RTTI) in order to distinguish between objects. But, is NOT used in performance critical code and is ONLY limited to polymorphic classes.

When do these types of issues occur?

• Illegal downcasts. For instance, going from child2->parent->child1. The child1 conversion from parent can technically legal from the hierarchical perspective. But, this may not be a valid conversion in terms of memory safety.
• Static Casts allow for conversions from child2->child1 directly! Even though these are different classes, because they have the same parent the type conversion is allowed.
• Dynamic Casts (that are not polymorphic (virtual)) have these issues because no check is done at compile time or runtime for these.
• C-style casting has small checks in place at compile time to validate if the cast is valid or not. But, this is limited.
• Polymorphic child to a non-polymorphic base. This is because the VTable is stored at the beginning of the child, while the base class will NOT have this.

The presentation then proposes a solution to this type casting problem. For all casts (during the compilation process), a type hierarchy is made in order to validate EACH cast that happens. At runtime, instrumentation is added in order to use the hierarchy to validate the conversions. This was done by an LLVM pass that validates within the Clang compiled binary.

To make this more efficient, only the types being casted in the program were added to the type hierarchy. Additionally, the code that verified bugs are compile time was NOT added with instrumentation for runtime. Although, this COULD lead to further memory corruption (down the road) to take a small bug and turn it into a bigger one via this type confusion.

Simply from compiling software and running it found 4 type confusion bugs. By fuzzing with AFL, they found 13 other bugs with the HexType instrumentation. This works well when instrumented with AFL; this is super awesome to hear for C++ projects to find type confusion bugs.

The type confusion checking CAN lead to a significant amount of false positives because of some quirks of C++. Although some things may be a type confusion, they may not be exploitable.

They have this code public in a Github repo at HexType.

Fun fact from the questions... I'm fairly sure that the women that speaks about Safari is Natalie Silvanovich from Project Zero, whose finding the speaker referenced in their slides. Just something that is super odd that I'm not sure the speaker realized (lolz).

The beginning of a philosophy on the art of exploit development. In particular, it goes over the development process at Apple and how it tries to mitigate bugs with secure architecture design, exploit mitigations and (recently) fuzzing. However, a determined attacker (with resources) will find bugs and exploit them. This project took Ian Beer 6 months from start to finish as a single person.

From the reversing side of things, Ian Beer had a special copy of an iOS beta build that had symbols still in it. This allowed for much easier reverse engineering. While Mr. Beer was looking through this in a decompiler (particularly moving for memmove operations).

While reversing, the function IO80211AWDLPeer::parseAwdlSyncTreeTLV stood out because of "TLVs (Type, Length, Value) are often used to give structure to data, and parsing a TLV might mean it's coming from somewhere untrusted". From this (even without knowing AWDL), he took a closer look at the code.

The code did some parsing and the data sent it. Ian looked at some error messages for length checks (normal place to find vulns). He noticed that the error messages being thrown were not fatal. This means that the error would happen but would just CONTINUE! This reminds me of the There's a hole in the Boot bug a while ago.

Using the information from above, the author attached a debugger on MacOS (this driver exists on both MacOS and iOS) and altered the payload to another MacOS computer. By barely altering this TLV object, it caused the kernel to go into a kernel panic from a buffer overflow. And we have a bug!

As a note on reversing, the control flow graphs seems to help Ian quite a bit on finding this bug. Seeing code from different angles allows for different problems to be found. Additionally, this is a remotely touchable service; Apple-proprietary mesh networking protocol is what was being hit on this. Finally, the author read several papers on AWDL and built off the work of others to get this to actually work.

AWDL allows iDevices to connect to mesh networks automatically. "Chances are that if you own an Apple device you're creating or connecting to these transient mesh networks multiple times a day without even realizing it." That is crazy to think about, for an attack surface.

AWDL is built ON the WiFi layer of the radio. Most people (including myself) think about the infrastructure network of the home being connected to. However, the WiFi layer has much more than just this. The idea (behind the protocol) is that if the WiFi signal is already there going to ALL devices, why not just talk to the devices directly (peer-to-peer)? This is what AWDL does.

An interesting thing to note is that the AWDL protocol allows for devices to BOTH be on the infrastructure network AND participate in the peer-to-peer communication on the same network interface. This is done by time sharing in 16ms intervals. Although this could miss frames, radio is considered to be a unreliable anyway (meaning that handling this missed data is already part of the protocol).

There is quite a bit more background on the attack surface, the protocol, reversing and MUCH more. However, for the sake of conciseness, it will not be included here. Only interesting notes will be included from these points for now on.

The vulnerability discovered from a linear heap buffer overflow in the storage of MAC Addresses. There is an inline array that should only hold a maximum of 10 objects but does not limit this. By adding a bunch of peers to the mesh network, it is possible to corrupt many different sections of data.

To perform the actual exploitation, libpcap was used in order to inject raw data into 802.11 frames (WiFi). He also used an Raspberry Pi for the network data transferring. An additional note was on debugging the kernel driver... both the MacOS kernel debugger and Dtrace were used to dynamically understand the kernel object allocation. Overall, setting up an injection framework for WiFi took a significant amount of time and understanding to do.

The added mitigation of Pointer Authentication Codes (PAC) made the exploitation much more difficult by cryptograpically signing function pointers. With the original POC, it was possible to overwrite a Vtable function pointer. However, this no longer trivially works because of PAC. PAC validates the signature AND the function prototype. To bypass PAC, either signing gadget needs to be found or a function with a similar prototype and leaked VTable signature needs to be used. It should be noted that PAC is ONLY for function pointers and NOT regular pointers.

For grooming the heap, there is a mitigation in place that returns chunks of the SAME SIZE in random order to the user. However, in this case, the ordering was not important as long as a particular type of object was being used.

For building primitives, a safe objects needs to be made. The following is what is considered a safe object:

• arbitrary size
• unlimited allocation quantity
• allocation has no side effects
• controlled contents
• contents can be safely corrupted
• can be free'd at an arbitrary, controlled point, with no side effects

From previous iOS research, there was a good idea of them. But, the remote attack surface makes finding these an entirely new ball game.

The OG leak technique did not work (relative overwrite of pointer) because of a boundary issue. However, after updating to the newest version of iOS, some new fields were added that created new hope. After a crazy amount of reversing the code, an arbitrary read primitive could be constructed in order to leak data from a buffer by overwriting a pointer.

Getting the first leak is difficult; if everything is randomized then where do you go? Either relative overwrites or targeting places with insufficient randomness is your best bet. By allocating a BUNCH of heap data (referenced as zone) with the frames, we can create enough memory then safely read from this section to leak arbitrary data. In particular, they use the PAC pointer to leak KASLR address.

Two other bugs were accidentally discovered. The first one was a double free vulnerability for a pointer on the steering_msg_blob object. It can be triggered by DOING NOTHING. The second bug was an integer underflow on parsing of a length value.

What now? Time to create an arbitrary write primitive! By using the leak from before, a relative arbitrary add can be created in order to write to where ever we want. This primitive ADDs whatever value we specify to the current location in memory. Using memory leaks, it is possible to turn this into a a FULL arbitrary write.

However, there is an issue... if we write, the program crashes RIGHT afterwards unless a specific if statement is taken, which requires specific timing. This if statement required a bunch of playing around and proper timing in order to work properly.

With a true read-write primitive in the kernel, what is next in order to get code execution? Popping a calc was done by altering a kernel object being sent back to userspace. Once this function pointer (without PAC going to userspace) is altered, we can pop a Calc :) From here, the author goes into making this exploit FASTER by using different types of settings.

There is one final trick: getting the AWDL interface to be open. This can be done by brute forcing a contact ID (last 2 bytes of a SHA-256 hash). Once this is open, we can launch our full attack.

The rest of the article goes into taking the kernel read-write primitive into a fake application that will steal all of the data from the phone.

This is an amazing piece of engineering! To me, the takeaways are endless.. from reversing to exploit dev, it is tremendous. I see that setting up a crazy tech stack for the attack and the massive amount of reversing makes the exploit doable. In the future, it might be wise to look into harder to reach surfaces, such as radio protocols.

This vulnerability used a plethora of different quirks of the Windows Spooler service in order to get privilege escalation. The Windows Print Spooler is a high value target because printer drivers need to be installed with high privileges, without creating any other issues.

An older version of the Windows Print Spooler service worked in a different directory and searched for this. However, this directory now does not exist.

By using the APIs provided, the author makes the version 4 driver directory world-writable. Once this is the case, we can trivially add new DLLs to this location. This took a bunch of application logic that was very specific to the Windows Spooler service.

The other interesting quirk was that the vulnerability could only be started while the Printer Spooler was being initialized. So, they needed a crash oracle in order to make this work. This was done by loading the DLL AppVTerminator.dll into a printer spooler.

Overall, this is a good dive into the Spooler service and an interesting bug. However, the article is difficult to read because the bulk of it is just background into the Spooler service. I wish that there was a step-by-step on what is needed for the attack.

Snapchat had a SSRF vulnerability in an application that retrieved resources from a different location. This is the classic place to find a SSRF bug.

The SSRF vulnerability was not trivial to exploit though. The page (being taken from Snapchat) loads the setup into a browser. Because this is in a browser, grabbing data across origin is NOT possible unless the CORS policy is setup in a janky way.

DNS Rebinding is an attack that uses a small TTL (time to live) in order to change the IP associated with a domain. This is done by changing the IP of the current webpage to the internal network IP. Now, the loaded web page thinks that this internal IP is on the same origin!

In order to access data on the internal network, DNS Rebinding was used. By changing the IP from the current webpage to the internal network IP of the Google Metadata service, it was possible to steal the credentials of the instance! It is fascinating to see the DNS Rebinding attack used in the wild.

The VMWare cloud had a weird password reset implementation. They used the current password for the entropy on the reset token. Password reset tokens are supposed to be completely random!

So, what is the issue? If you know the password, then there is no reason for the password reset implementation. Well, there was a disabled backdoor user that had a hard coded password.

By using this disabled user (with the known reset link from the known password), the user became enabled! And, the best part, we knew the password.

The auth bypass was the main issue. However, there were other issues in the system that eventually led to compromise, such as a SQLi, file inclusion and directory traversal.

The Microsoft Teams application has a user facing application and a privileged XPC client. Historically, the XPC client on macOS has been a high-valued target, as it has high permissions.

The first issue is an insure validation of the sender of the requests to the XPC client. Of course, we ONLY want a specific application sending data to the XPC client. This is supposed to use an AuditToken to do. However, the application used the PID instead.

By using a classic PID reuse attack, an attacker controlled application can get the PID. This allows for arbitrary calling of the XPC daemon by an attacker.

Another interesting issue was that the application has the com.apple.security.cs.disable-library-validation. This means that any of the libraries within the application can be replaced with something else, without being validated. Both this and the first issue can be used in order to take control of the daemon.

What do we target within the XPC communication? The target of the attack was the Update mechanism. The update mechanism proper validates the Microsoft signature but does not block older installations with known vulnerabilities. Because of this, install the Auto Updater that is vulnerable to CVE-2020-0984 and exploit this known vulnerability.

Overall, XPC communication is difficult to do right, look over the entitlements of an application and NEVER forget about downgrade attacks.