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!

Most chips have a debug mode for testing. When the device with this chip is put into a production, the debug mode is turned off. It is turned off by a mechanism called Access Port Protection by Nordic.

APPROTECT guarantees that no readouts on the port can happen unless the RAM and Flash are completely erased.

The author then gets a development kit in order to test out the APPROTECT feature himself. From testing, he discovered that a Power On Reset resets the entire chip, including the Debug port.

Because the Boot process is entirely in hardware (no BootROM), this value had to be set in some way!

How does this get pwned? The answer is always going to be voltage glitching! After analyzing the voltage of particular areas of the SoC, he noticed a particular pattern that looked to be the Debug Port value being set.

From there, he glitches at this exact moment that the value was being set. After the glitch, the debug port is now turned on. This allows for easy connections via GDB with full debugging capabilities (also known as game over).

I found the article interesting because the author discusses the chip itself, the entire process for exploitation and the glitching setup. A really good article if you are looking to get into hardware hacking research.

This is just a HUGE collection of exploits on iOS. Within each exploit is the following:

• A description of the vulnerability
• A strategy overview for the exploitation of the vulnerability
• Mitigations because of the vulnerability or further notes on the exploit
• Links and references to blog posts about the bug, POC and more.

The main goal was to do a survey of iOS kernel exploits. Having all of these in one place will be useful to have as an iOS exploit developer.

The beginning of the article discusses Windows Internals (which is even the blog name) about the printer service.

The bug is actually pretty simple... but first, some background! A printer has a specified port that which is where the file being printed gets published to. But, did you know that the printer port can also be a file!? Yes, it can.

Another piece of background is needed: because printer jobs can error part way through the printing job, there is a level of persistence that it has to have.

Now, back the bugs... In the case of a crash (of the printer service) the privileges can jumped back into as System. Now, we can write anywhere as system (that the service allows). This is where the second bypass occurs.

We could just specify the port to be an important Windows file and gain access (like some DLL). Well, this was thought of: there is a check to see if the user has permissions over this file. But, in actuality, the check was ONLY client side! So, by evoking the same functionality via Powershell.

It's now possible to go from a regular user to System via using the printing service in a particular way!

Items to note:

1. Client-side checks even happen in Native services.
2. Undefined situations in the source code can lead to security vulnerabilities. Think outside of the box of how a service can be used :)

A super classic issue for privilege escalation: symbolic links.

By creating a symbolic link to the log file from Symantec over a file of our choosing, the file (arbitrary name) will have the information from the log with high privileges.

The information, in the log file, can be partially controlled to execute commands. So, easy priv esc.

An interesting extra step that had to be done: this was to delete the Logs folder in the UserData section in order for the symbolic link issue to occur.

What's the calling for a symbolic link issue? High privilege programs writing to files in potentially user controlled areas.

Checkpoint Research found a path traversal bug in the Microsoft RDP client. The research came back up once again this same bug was found in the MacOs client.

Microsoft fixed the path traversal using the Windows API function PathCchCanonicalize. This function gets the absolute path of a path. According to the official Windows API documentation, this is the main way to prevent path traversal.

In Windows, paths use ' \' . However, both forward slashes and backslashes are valid in Windows paths. What Checkpoint Research discovered was absolutely startling...

PathCchCanonicalize only recognizes ' \' and not ' /'! This means that path traversal can still be performed, even after Microsoft's suggested mitigation. Microsoft will NOT be fixing this; they have to keep things like this for legacy.

In the future, while looking at Windows applications, make sure to check for path traversal. It is likely that the developers think that PathCchCanonicalize fixes the problem (even though it actually does not).

TLS (Transport Layer Security) does all of the fancy encryption of internet traffic. A feature of TLS is that it has the ability to resume a previous session.

The resumption feature (on GNU TLS) does not validate that the previous connector and the new connector are different! There is supposed to be a credential check at this resumption stage. However, this appears to be missing.

In TLS 1.3, this can be used to bypass authentication for the server. For TLS 1.2, the keys have NOT been zeroed out. Hence, it is possible to recover previous messages!

OSX (Mac) is really annoying to get running on other systems. For the purpose of a CTF or anything else, having an easy dockerized setup is a good thing to have!

The Hobbes Functional Interpreter has the ability to use arrays. However, it does NOT support negative indexing and does not protect from going outside of the bounds. See where this is going?

Now, we essentially have an arbitrary read and an arbitrary write! Anytime this is achieved, it is essentially game over.

The exploitation path was interesting though. First, they use a GOT/PLT overwrite to redirect code execution. The GOT is a list of function pointers to dynamically loaded libraries, such as LibC.

Now, he has ability to redirect code execution. But, where to direct to? Apparently (for an unknown reason) the location that input is placed is in a RWX location! So, simply place the shellcode into this region and jump to it via the controlled path.

Although, this bug may not be fixed... which seems odd to me. The researcher absolutely went through the proper disclosure process and everything too.

The researcher just pokes at open source projects. Could be something interesting to look into! :)

The CMD in Windows is a shell, similar to the terminal in Linux-land. It is common (but difficult to secure) to use a CMD command, with user supplied input, and get the result.

In theory, if you escape all of the insecure characters (in bash these would be $,`,; and others), then this can be done securely. However, this article explains a bypass for this!

The example used is the ping command with an IP address as the IP to ping. So, normally, this looks like the following: cmd.exe /c "ping 127.0.0.1".

This is where the bypass comes in: by confusing the CMD interpreter, the argument can be used to use another program. Here's an example that opens the calculator: cmd.exe /c "ping 127.0.0.1/../../../../../../../../../../windows/system32/calc.exe". YES! Even though the ping is the specified command, this opens a calculator!

The rest of the article goes into why the above feature works the way it does and how it was discovered in the reverse engineering process.

There are two parts to this article; the first part talks about macOS calendar, how it works and how the research originated. The second article explains the actual attack.

A Mail Event actually has a file URI included in the format. Why!? So, naturally, giving someone a malicious ICS file, convincing them to invite you to that event would then leak whatever file you wanted!

But, this was not sly enough. So, the author went back to the spec (which is really the theme of the article). The SCHEDULE-FORCE-SEND would allow a malicious actor to set someone else as the organizer.

With the previous directive being used above, a malicious actor could send a bad ICS file that would steal arbitrary files from your computer (with some caveats).

Two main things stood out to me:

• The amount of knowledge that the author of the article had about the specification. This allowed for the attack to become stealthier and stealthier over time.
• The bad URI being used was interesting. In how many other places does this exist? Definitely something to look out for in the future.