When I heard about the emergency disclosure of CVE-2019-2215 by Project Zero, I decided to replicate the exploit on my local device to see it in action. I so happened to have a vulnerable Pixel 2 with the exact kernel version as my main device (don’t hack me). All I needed to do was compile the exploit and run it over ADB. I downloaded the latest Android NDK and compiled the proof of concept:
[grant ~/Downloads/android-ndk-r20 >> ./toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android29-clang -o poc ../poc.c [grant ~/Downloads/android-ndk-r20 >> adb push poc /data/local/tmp/poc poc: 1 file pushed. 0.8 MB/s (22528 bytes in 0.026s)
I ran it on my device and confirmed that I was able to reproduce Maddie Stone’s screenshot exactly.
The base PoC left us with a full kernel read/write primitive, essentially game over for the systems’ security, but left achieving root as an exercise for the reader. This raises the question, what does “root” really mean for a modern Android system? To answer this, we must first understand how Android enforces its security policies.
Welcome to a journey of AArch64 kernel exploitation, from the least privileged, to the most secure privilege level on the ARMv8 platform. For this year’s HITCON CTF, I played with my academic team, Kernel Sanders. When scanning through the problems, I quickly latched on to the Super Hexagon challenge once I heard it involved ARM exploitation. Here is the challenge prompt:
Escape each level for your six flags.
EL0 - Hard
EL1 - Harder
EL2 - Hardest
S-EL0 - Hardester
S-EL1 - Hardestest
S-EL3 - Hardestestest
nc 184.108.40.206 6666
Author: sean, atdog
Super Hexagon - 1: 39 Teams solved.
Super Hexagon - 2: 9 Teams solved.
Super Hexagon - 3: 4 Teams solved.
Super Hexagon - 4: 2 Teams solved.
Super Hexagon - 5: 1 Team solved.
Super Hexagon - 6: 1 Team solved.
Backing up or moving a VMWare Fusion VM to an external hard drive is usually no problem - except when your destination filesystem is FAT-32.
I use FAT-32 on my external drives for maximum compatibility between Mac, Windows and Linux. Unfortunately, FAT-32 is quite dated and doesn’t allow any file larger than 4GiB.
One night while playing Counter Strike: Condition Zero (CZ), I decided to take a break and challenge myself to find an exploitable bug in the old engine known as GoldSrc. Condition Zero, Half-Life 1, and CS 1.6 all run on the GoldSrc engine, which was created by Valve and is based upon the original Quake engine.
What makes Counter Strike an interesting target is that it relies on a game lobby for players to find and select servers to play on. Upon connecting to the server, the game client will automatically download any required resources (maps, textures, sounds, etc.). Once all of the resources have been downloaded, they have to be loaded and parsed from disk into memory. Only then will the client begin receiving commands and entity updates from the server.
This automatic resource fetching looked like the ticket to a remotely exploitable vulnerability via a local file.
The vulnerability discussed in this article has been disclosed to Valve Security and the patch publicly deployed on July 10th.
I would like to extend my thanks to the Valve Security team and specifically to Alfred Reynolds who was my liaison during the disclosure process. The whole process, from initial email to fix, lasted less than 30 days. I certainly look forward to disclosing to Valve in the future.
This is a follow up to my previous post on creating a CRC-32 chip from scratch using Cadence. Check it out as it goes over the design details.
tl;dr: see die shot images
After submitting my CRC-32 design to MOSIS for fabrication, I had to wait quite a while for the results (over 6 months), but considering it was
- An actual chip that I can physically hold in my hands
- Something I designed myself from scratch
I was willing to wait. The wait was finally over in late December of 2015.
We are given a PCAPNG file with a bunch of USB packets. By scanning through the PCAP, I noticed that there appears to be a large amount of
URB_INTERRUPTpackets after some initial configuration and setup. On a hunch, I immediately suspected either a USB keyboard or mouse due to the amount of data and the fact that all incoming packets were created from interrupts (i.e some kinda of slow I/O device driven by a human).
While looking at the packets, I initially assumed this was a keyboard as it would be straight forward to hide a flag in keyboard data. I tried the obvious choice and googled for some Python that already solved this problem and I came across this keyboard PCAP parser. I noticed that the offsets used in the file were not close to the size of the packets I was seeing, so I did some more research on USB HID devices and I came across this great page on USB mice packets.
The packet structure described here matched what I was seeing in the PCAP data. I confirmed this by looked for a USB descriptor packet from the device. I found the right packet at number 84 (below).
No. | Time | Source | Dest | Protocol | Length | Info ----+----------+--------+------+----------+--------+------------------------------ 84 | 6.505211 | 1.3.0 | host | USB | 46 | GET DESCRIPTOR Response DEVICE
The device descriptor decoding showed that this was definitely a mouse.
Author’s note: this report was written by me for Practical Malware Analysis (CAP6137 spring 2016) at UF. It’s written in a role-playing fasion.
Our team at Skynth Security has discovered and analyzed a new ransomware sample categorized as
W32.VeryBadNews!Ransom. Upon execution, it changes the desktop background to an extortion image asking for money and it encodes important user files with a fixed Xor key. It logs all encoded files and pops up a notable message in notepad: “Very bad news”.
Unlike more sophisticated ransomware, this malware does not actually encrypt files in a cryptographically sound way. Nor does it randomly generate a key or public-private keypair for per computer encryption. It uses a fixed Xor key that is used for encrypting and decrypting all files.
The best part is that the malware author included a routine for decrypting the file system as well. Using the command line argument
rafgapnkucmghgklmgtiftqgtswqtrim, the malware will read the CryptoLogFile and decrypt any file path present in there.
There are no significant obfuscation methods besides some strange repeating strings. The binary is quite easy to read and is not packed. It is apparent that is traversing the file system due to the imports
If this were to be accurately detected, a host check for the creation of either
C:\Ïðî÷òè Ìåíÿ - êàê ðàñøèôðîâàòü ôàéëû.txtwould be sufficient.
This semester at UCF I enrolled in a 5000 level (graduate level) Very Large Scale Integration (VLSI) class entitled EEE5390 “Full-Custom VLSI Design”. It caught my eye back in the Spring of 2014 when I noticed another student’s screen as they designed a chip. The mash-up of colored rectangles and wiring intrigued me. Later I learned that the best designs would actually be fabricated through MOSIS, a university chip fabrication service. This was a big pull in my decision to take the class – how often do you get to say your design is baked in to a working piece of silicon?
With that, I decided to give it a shot this spring.
This week a friend of mine suggested that I make something cool with bitmaps. Normally most of the code I write is pretty low level, but I’ve gotten more and more interested in graphics. So, I thought of an interesting idea and challenged myself to implement it. Here are some of the results:
My previous experience with exploitation from the IO wargame on Smash the Stack led me to choose this challenge as my first target in the CSAW competition.
The challenge text is such:
nc 220.127.116.11 54321
Read the key out of ./key in the current working directory.
Okay, lets run the command and see what type response we get. Note: on my machine `nc’ is `ncat’ because I am using the version that comes with nmap:
I’ll take that misspelling as subtle humor. This seems pretty straight forward: we give the program a specially crafted input name and it gives us the key. Time to investigate the executable.
After downloading the executable, I use file to get some information:
Uh oh. My system is 32 bit and I don’t have any cross compilers installed. Luckily, I have an Amazon AWS account. I spin up a generic Ubuntu 64 bit micro instance, transfer the file, and begin investigating.
A quick run of the program prints the target key, but it’s encrypted. No command line arguments are accepted, therefore this problem requires a patch.