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!

Your vulnerability is in another OEM!- 611

SynackTIV    Reference →Posted 4 Years Ago
  • For PWN2OWN 2021 IoT edition, this team decided to tackle the Western Digital PR4100 NAS. They targeted the APIs, which used the command gateway interface.
  • The authors found a fairly straight forward buffer overflow vulnerability when handling passwords. The overflow occurs because of a strcpy, which never checks the length of the buffer. Because there is NO PIE and no Stack canaries, this should be trivial to exploit.
  • At the point of the overflow, many of the registers are controlled, one of them points to free in LibC and two of them point to the stack. The overflow can only have a single NULLbyte at the end, because it's a strcpy. This is where exploitation becomes hard and fun! With no way to control a parameter to System some magic had to be done.
  • Since the password was base64 encoded, the original string could contain nullbytes. The new goal was to use a stack pivot to point the stack to where our base64 decoded password is at in order to set RDI with a nice string to call system.
  • After finding ROP gadgets to do actually this, they had a command via system with 47 characters. To do something impactful, the authors pushed a static netcat binary into the /Public SAMBA share and called this. Game over :)
  • A few ending remarks:
    • WD Digital patched this bug right before Pwn2Own, which they were not happy about.
    • WD equipment is similar to DLink NAS devices since DLink started to wind down this product division and sold it to WD. As a result, if bugs are in DLink NAS's, check WD as well.
    • eb fe is an infinite loop in x86_64 assembly. This can be a good debugging trick for exploit devs.

Analysis of a Parallels Desktop Stack Clash Vulnerability and Variant Hunting using Binary Ninja - 610

Reno Robert - ZDI    Reference →Posted 4 Years Ago
  • Parallels Desktop uses a paravirtual PCI device called the Parallels ToolGate for communication between guest and host OS. The request format is a variable sized structure. The guest sends data to the host as inline bytes or pointers to paged buffers by writing the physical address of the structure.
  • If the size provided by the guest is more than the total size of the stack, it is possible to shift the Stack Pointer (RSP) into other regions of process memory. This vulnerability class is known as a Stack Clash vulnerability.
  • When handling a specific operation, the application does not validate the ByteCount provided as part of the buffer. This value is then used to increase the size of the stack prior to writing data into it.
  • After finding this vulnerability, the authors wanted to do taint analysis and look for other cases of this bug. Most stack increases have a static size; for those that are not static, Binary Ninja marks this as UndeterminedValue. By searching for these occurrences it was possible to find 2 other variants of this bug in other places!
  • The authors dive into a mitigations to prevent Stack Clash issues. In particular, they mention called -fno-stack-check on MacOS and iOS. This mitigation is for calls to alloca or a variable length array. When incresing the stack, instrumentation is added to validate all allocation requests to be to valid stack memory, require an increase or crash safely. This was not included in the binary.
  • The author does not mention exploitation at all but points to the Qualys post linked to above; this post has a bunch of information relating to the exploitation of these types of bugs, specifically on Unix based systems, with many interesting examples. In order to exploit this, the Stack Guard page needs to be skipped. Even though we have a buffer length to jump to another part of memory, we cannot write to the bulk of it.

Roll D.O.R Attacks - Getting permanent accesses in garages- 609

Penthertz    Reference →Posted 4 Years Ago
  • This video is a demonstration of hacking a garage door remote. While trying to find out more about Penthertz, I stumbled upon their publications page which has dozens of other articles on hacking with radios. If you are looking to see hands-on radio hacking, this is an amazing place to be, since this guy is a wizard with GNU radio.
  • In real time, the creator of the video creates GNU radio flows to do a bunch of things. At the beginning, they use a QT Sink to show the data with the remote and slightly increases the frequency in the sink until the proper frequency is found. They use the max hold and waterfall view to see how the data is formed, which clearly gives away two main points that are binary encoded between the two points. Since there are two frequencies being used for this, it indicates that FSK or frequency shift keying is being used.
  • To decode the data, you can use the FM (frequency modulation) or the quadratic demodulator. The FM demodulator is simple and easy to use, but the author elects to use the quadratic demodulator to make the demoulation more precise. In this step, they also add an import block to add the math package in GNU radio, which I had no idea was possible!
  • With the timing changes and error that is inherit with technology, the author needed a way to decode this properly. As a result, the symbol sync which helps found the symbol rate. Additionally, there is a deviation factor to handle the clock drift, a squelch control (muting a channel with nothing on it) automatic gain control and a threshold block to handle the slight differences that are not caught from this block. At the end of this section, the author just turns on Inspetrum and universal radio hacker (which decoded the signal easily), since doing it automatically or by hand is easier than using GNU radio (lolz).
  • URH protocol features are nifty! It shows the comparison between the two recording, support for seperating parts of the protocol (header, footer, data, fixed, padding, etc.) and many other features that help with analyzing. From looking at the changes, the author notes that this is a rolling code, since some of the values are different between two different clicks of the same button.
  • Microchip based remotes use KeeLoq, which is an encryption block cipher used all over the place. By using a hopping code with some data encrypted over the wire with a unique counter, replay attacks are not possible. An additional technology is a challenge-response called IFF (Identify Friend or Foe).
  • Against Keyloq, there are a few known attacks though.
    • RollJam. There is no timestamp. As a result, an attacker can record the signal when sent but interfere with the signal going to the receiver. Since the signal was neve received, a replay will now work!
    • Cryptoanalysis
    • Extracting the key from the firmware.
  • DOR is a process for cloning remotes over the air. In practice, this passes the state in the rolling code to the remote. Of course, being able to sniff this code as an attacker is the dream, as this would allow for another remote to be created to put this onto another remote.
  • Can we do this with a remote? Yes we can! A recent project has came out called Kaiju for breaking rolling codes and generating rolling codes. In the demo, only a single capture was needed in order to get the next value in the rolling code for the device. Damn, that is terrifying! Keeloq does not feel secure against more advanced attackers. I feel like I'm missing something on why this attack works here.

Bypassing Windows Lock Screen- 608

halov    Reference →Posted 4 Years Ago
  • The Windows Lock screen on an open computer is what makes physical attacks hard. Otherwise, an attacker could waltz right in and steal all of the information on the computer.
  • A post in Jonaslyk described a flaw in 2020 that allowed for the settings to be hit via the sticky keys pop. Once in the settings, it is trivial to pass the lockscreen.
  • From this finding, the author was curious if any other bypasses were possible and testing many features. If a computer has a Microsoft account hooked up to the computer, this can be used to reset the password on the computer.
  • When typing in a wrong password, a small arrow appears next to the email address. By clicking on this icon a pop up with a link appears about using physical security keys. Clicking on this link does nothing! What if this opens up the settings in the background?
  • The original post mentions using narrator to help navigate what is going on. Since the page is in the background (and not seeable), it is really easy to miss this! This opens the how to open screen. Using the narrator, we can open Microsoft Edge to open up the settings to do malicious things!
  • To make matters better for the attacker, the user is NT AUTHORITY\Authenticated Users! So, we can do whatever we want on the computer we full access.
  • It is insane that these bugs still exist in such mature operating systems. Interesting article on a Kiosk-like escape.

Code execution outside the virtualized guest in bhyve- 607

Agustin Gianni - Github Security Labs    Reference →Posted 4 Years Ago
  • Bhyve is the hypervisor used in BSD Unix operating system.
  • In Bhyve vtrnd is an implementation of RNG, a paravirtualized device that is exposed as a hardware RNG device to the guest. he randomness values are transferred into the guest memory by reading queues defined by the guest by using vq_getchain to fill a struct iovec structure with the memory ranges specified by the guest.
  • When calling functions in vtrnd, it is very important to check the return value and check it properly. There are multiple occurrences of NO checks of this return values and signness conversion issues.
  • Issue #1 describes that the iovec needs to be initialized and check the amount of file descriptors there are. However, since the return value is never checked, this can be used without ever being initialized. If the right data can be put into these locations, major memory corruption could be caused.
  • This same issue exists in other spots for Issue #2, #3 and #5 as well.
  • Issues #2 and #4 have to do with integer conversion. The return value is a signed integer from the function. However, using the value as an unsigned integer and returning the error case of -1 would be a problem.
  • Issue #2 puts the return value into the type size_t. This return value is used for a size in a memcpy as -1.
  • Issue #4 stores the return value into a uint16_t. When an assert clause is ran, the check is to make sure the value is greater than or equal to 1. Since this is an unsigned integer -1 becomes a very large positive number, bypassing the security check. Does this assert clause actually do anything, since it is in a production build? That may be another CVE!
  • All of these bugs lead to uninitialized memory access, which, with proper data placement, can be devastating. It is fascinating how a simple lack of validation of return values can lead to the compromise of a program.

DoS Denial of Shopping: Analyzing and Exploiting Shopping Cart Systems- 606

Joseph Gabay - DEF CON    Reference →Posted 4 Years Ago
  • Many shopping cart wheels have a protection in place that will disallow people from stealing the cart. Once the cart is taken outside of the pre-approved boundary, one of the wheels will lock itself. How does this work? Welcome to the rabbit hole! The author has a funny quote at the beginning "It's not worth doing something unless someone, somewhere, would much rather you weren't doing it" - Sir Terry Pratchett.
  • The system works by having an underground magnetic that is sending out a signal at all times. This is typically buried underneath the parking lot at stores. If the cart senses this magnetic field, the cart automatically locks itself. At this point, the store staff comes and gets the shopping cart with a remote to unlock them.
  • As a robotics engineer, the author of the talk discusses how the actual lock and electronics work. The wheel has an inner casing that is flexible. When the wheel wants to stop, a motor expands this inner wheel to cause a lock via some ridges on the inside. Interesting system!
  • The PCB has two antennas: a 2.4GHz antenna that is physically in the PCB and an inductor that runs at 7.8K, which acts like an antenna. The Microcontroller is a TI CC2510, which has a built in 2.4GHz transceiver. There is a 10 pin JTAG port that can be used as well.
  • To learn how this works as a signal level, there are a few places to turn: FCC website, patent searches and other hackers. This can get information like a user manual, frequency, modulation and many other things. In this case, the frequencies and modulation were shown in the documentation.
  • Frequencies under 1MHz are not supported by most SDRs. So, what do we do? 7KHz is in the audio range! The author creates a janky home made antenna and records it using a standard audio application; this is amazing that is actually worked. They analyze this in a spectrogram software and in audio processing software.
  • Phone speakers/headerphones are essentially crappy antennas! It is a coil of wire attached to a membrane with current going through the membrane. This causes the signal, or audio that we hear. Because the frequency we are working in is audio, literally using speakers/headerphones works to unlock these devices.
  • Using the signal above we can lock any shopping cart in the area; this is pretty amazing! But, what about the remote? Of course, these can be bought on eBay! Using this, we can unlock and lock the shopping carts at will and know the actual codes that are sent.
  • The signal decodes to a total of 8 bits. The difference between the two remotes is that one of them uses the 7KHz frequency and uses a OOK encoding while the other uses the 2.4GHz frequency with FSK encoding. Besides this, the unlock and the lock signal on the device are the exact same. The unlock and lock signals are just the inverse of each other as well.
  • The range of the audio was extremely small. As a result, the author created a proof of concept using the HackRF that worked from across the room for unlocking. The lock signal does not run on the 7KHz frequency, probably because the creators of this did not want hackers or store owners locking all of the nearby carts.
  • The author mentions a lot of great tools, such as universal radio hacker, GQRX and the HackRF. Additionally, they mention an article on previous research from 2008 called Consumer B Gone that reversed how some of these worked. Overall, this talk had great presentation and amazing research!

Now Patched Vulnerability in WhatsApp could have led to data exposure of users- 605

Dikla Barda and Gal Elbaz - Checkpoint    Reference →Posted 4 Years Ago
  • WhatsUp is an incredibly popular messaging application. As a result, the authors decided to fuzz it with AFL. In particular, they fuzzed a few image types and filters. While doing the blackbox fuzzing of these functinos the authors got a crash in one of the filters.
  • After validating on the crash on a phone app and crazy amount of reverse engineering the crash, they found the root cause. When dealing with the filters, there is an assumption that the source and destination filters have the same bytes per pixel.
  • When handling the height, stride (pixel size) and the width of a picture, the height is advanced by groups of 4. However, there is not always the case; what if the destination and source image have different pixel sizes. The code did not prepare for this! Only the source pixel size is actually checked.
  • Therefore, when a maliciously crafted source image has only 1 byte per pixel, the function tries to read and copy 4 times the amount of the allocated source image buffer, which leads to an out-of-bounds memory access. This OOB read could be used to steal secret information from the application, if setup properly. This could go in the other direction for a memory write as well.
  • The fix validates that the image format and uses the proper stride for the format. To trigger this bug, a user must use a specific filter on a specific image; this would require a self-attack or a substantial amount of reverse engineering to full off.
  • Overall, this is an interesting business logic bug that led to the wrong stride (pixel size) being used. I appreciated the exploit method, as it was not all about code execution (which is what most memory corruption bugs are). This reminded me a lot of Heartbleed as a result.

Acura and Honda Key Fob Security Issues- 604

HackingIntoYourHeart     Reference →Posted 4 Years Ago
  • Key fobs are a common way to open cars or even turn on cars now-a-days. My car does not even have a physical key hole anymore. With more technical integration, comes a larger likelihood of making a mistake though.
  • Key Fobs send a signal over radio in order to open the car or do something else. Because the data is sent over the air, it needs to be replay protected. It is common to use rolling codes in order to prevent replay attacks. This works by using a set algorithm and sending only values on this algorithm; the known place of the algorithm must be known.
  • The signal for the car uses Frequency Shift Keying (FSK). After decoding the values, the author noticed that the data being sent was the same every time. So, what would happen if we resent this signal? It just works!
  • The fob uses a header to sync to the car; this is so that multiple remotes cannot unlock the same car. Besides this though, everything else is completely constant. Once we know the identifier for the car, the code can be reconstructed to do other things than the original signal did!
  • As a result, somebody could be recording the key fob on the car for a lock request. Then, an attacker can modify the code to unlock or turn on the car. So, a single recording of anything on the car results in a complete compromise.
  • The authors tested this on 5 different cars, ranging from 2009 to 2020; but, it is assumed that all cars using the key fobs are vulnerable. Honda/Acura has refused to comment on this, even though the author tried to reach out all the way back in 2019. Hopefully the 2021+ models use rolling codes and are more secured.

MonkeyType Vulnerabilities - 603

Tyler Butler - Obsrva    Reference →Posted 4 Years Ago
  • MonkeyType.com is a popular open source type testing application with over 100K unique daily users. As a result, vulnerabilities on this are quite impactful!
  • The first vulnerability was stored XSS in the chat functionality. Both the message and name parameters do not sanitize input on the backend; they only sanitize it on the frontend prior to sending it back to the backend. As a result, XSS is fairly trivial to perform and can be used to steal auth tokens and take over the account.
  • The second vulnerability is a user spoofing issue. While sending messages to other users in the web sockets, the user is a controllable parameter. Hence, this value can be controlled to change the display name of the user, which should not be possible.
  • The final vulnerability is an authorization issue on the leaderboards. When somebody obtains a high score, they should be able to submit this to the leaderboards. However, the requests to change the leaderboard are done via the client-side. As a result, we can arbitrarily set high scores with usernames on the leaderboard. Clearly, this is a problem.
  • The final two findings are cases of the client not considering the content being sent and the dangers of this functionality. These are the intended features but are just being abused to impersonate other users and alter the scoreboard. Overall, good findings!

Local File Read via Stored XSS in The Opera Browser - 602

Renwa    Reference →Posted 4 Years Ago
  • Browser security is not all about memory corruption vulnerabilities. In fact, there are a lot of bugs around the thin line of web page and access to everything on your computer. Since Opera is built onto of Chromium, the author took a look at the new features. One of these was the Pinboard.
  • The Pinboard API accepted an HREF when something was added. By setting the link to a JavaScript URI, we had stored XSS. In particular, the payload was javascript:’@opera.com/’;alert(1), to pop an alert box. Since this was opened within the opera URI, it has special permissions that other web pages do not.
  • Since the attribute target=_blank was set, the XSS would only execute on the page if a middle click on control click was done. This is still a one click XSS though! What damage can be caused within the opera URI? This is similar to the firefox or chrome URI.
  • The Opera scheme has the ability to view other pages, bypass the same origin policy (SOP) request files and many other things. However, there are some restrictions in place to make an XSS in the browser not a complete game over. The author made an exploit that opened a new tab with /etc/passwd inside of it. Next, they take a screenshot of this page to see the information. Finally, they base64 encode the password and send it to themselves.
  • Overall, good post with an interesting exploitation method.