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!
- WebOS is a Linux based distro that was built by Palm back in the day. In recent times, LG uses it on a large amount of their smart devices.
- WebOS's application are all called web apps, which was essentially JavaScript applications running. webOS also implements an API that allows for communication with the underlying system called Luna.
- One of these APIs allows for the downloading of files onto the system. Only privileged users can specify the download location. What if we could convince the service that we should be able to hit this endpoint?
- The service validates that a specify string is in the package name prior to running it (
com.palm, com.webos and com.lge.). To me, this looks extra permissive. From researching the setuid binaries, one of the CLI tools had a prefix with this package name! - Because of this, the CLI tools could be used in order to hit this endpoint and specify the location to download the file AS root.
- For exploitation, a binary cannot simply be overwritten because the file will not have the executable bit turned on (this is a good thing for security). So, the author choose to overwrite a configuration file that pointed to a shell script, which runs at booting time. Just restart the box and we have root :)
Chaining Multiple bugs for Unauthenticated RCE in the SolarWinds Orion Platform
Sivathmican Sivakumaran - ZDI Reference →Posted 5 Years Ago- The Solarwinds breach affected the bulk of Fortune 500 companies across the United States. For obvious reasons, people started looking at this widely used software's security.
- The most impactful bug was an authorization bypass by containing one of the following keys: Skipi18n, i18n.ashx and others. The idea was that the JavaScript and CSS files needed to be gathered without authorization. So, these keyed strings were checked for. However, simply adding these to the request (unsure if this is just the path or query parameters too) skipped authorization.
- With the authorization bypass in place, it is time to take over the device. A non-administrative user is able to specify a running VBS script to execute upon some alert happening. But, the path for the interpreter is included, allowing an attacker to set this to
cmd.exeThe final bug is just the ability to run arbitrary SQL from a request, by design. I personally feel this is an intended feature and not a vulnerability though. The threat model assumes that only authenticated users can access this functionality anyway.Cache poisoning in popular open source packages
Adam Goldschmidt - Snyk Reference →Posted 5 Years Ago- Web caching poisoning was thought to be a theoretical issue until recently when James Kettle published some awesome research. The basics of caching are that data that has already been sent out to other users should simply be stored somewhere instead of regenerating the request.
- This creates a tricky problem though; how do we know what is the same? This is done via key and value matches on parts of the request. The idea behind the attack is to confuse the keying to cache something that should not be cached. This article goes into attacking many open source libraries for cache poisoning.
- The first issue was GET parameter cloaking. Using a semi-colon (;) to separate out queries (I didn't know this was a thing!?), the cache can get confused and not realize this is a separator. Because of this, the cache will save an item that should NOT be saved.
- Using this technique, we can control a usually keyed parameter to be sent back to other users. This vulnerability was found in Bottle, Tornado and Rack because of a parsing bug in
parse_qslfor Python. Additionally, Ruby on Rails suffered from the same issue, as well. The remediation is to NOT parse the semi-colon as a separator (this is deprecated anyway). - The next issue was labeled FATGet parameters. Typically, GET parameters are passed in the query string of the URL. However, the HTTP specification allows for GET parameters to be in the body of the request. If the cache uses the URLparameters but the backend uses the body parameters then a difference can be created.
- Using this difference, we can save a request in the cache using the GET parameters but get a different response from the body parameters. Now, the cache is poisoned with improper data. This issue was found when NGINX was used with Tornado.
- The final issue described is that arbitrary parameters can be injected into the request because they are NOT keyed. Although this is not a vulnerability by itself, using this with the proper gadgets can lead to some interesting affects. For example, adding the
_methodto a request in Flask could change the request method being used to a user. - Because cache poisoning is becoming more and more accessible, I feel that normally unexploitable XSS (such as in a reflected POST request) should be considered higher impact with this idea in mind. These are some good methods for cache poisoning that are library specific; I wonder what other bugs exist in libraries?
- Different technologies have different threat models, depending on the usage and sensitivity. In most scenarios, forcing a connection is not a huge deal. However, in the world of phones, being able to force audio or video on a call serious breach of privacy.
- Most of the cellular phone apps used for Real Time Communication (RTC) use the standard WebRTC, such as Signal, WhatsUp and many more. Using WebRTC for calls and video works well but can be still be hit by security issues. WebRTC makes the app creators store an internal state for the user, such as consent for a call.
- In Signal, the logic of the application did not check if the user accepting the call was the user callee. Because of this, an attacking user of the application could go through the routine for a call then force accept the connection for the user. By the way, Signal is on Github!
- The second issue was found in both Jiochat & Mocha. Both of these applications attempted to make the transition from accepting the call and being on the call faster. In order to do this, they used a non-WebRTC client in order to handle this and pre-establish the connection. At this point, the only thing missing was a candidate (user to connect to). Once this was added, the call would be accepted.
- With WebRTC, the candidate can be established on the initial connection. Because this was not the expected workflow, the WebRTC client had not implemented any logic for this! So, a phone could automatically be connected to just by sending the candidate object in the WebRTC call.
- With Google Duo, it suffered from a race condition on the startup process. Upon making a connection, the application tells the state machine to not allow video/audio (since they have not consented to it). However, because call is done asynchronously, a few video frames could be sent prior to the state machine updating.
- The author took 2 weeks in order to figure out a way to win the race. Eventually, she figured out that by adding multiple candidates to the connection (multiple ways to send data) and sending many messages at a time, the race could be won to get a few frames of data.
- At the end of this, the author makes a point about asynchronous call issues: "However, asynchronous calls make it more difficult to model how a state machine will behave in all situations, so it is important to be cautious about adding asynchronous calls to WebRTC signalling."
- Facebook Messenger was an entirely different beast! All of the previous apps had Java bindings (which decompiles nicely) but Messenger used C++ binding with a statically linked & stripped library. A good section of the article is just about reversing the messaging app itself.
- The author noticed that when a track connection is added, it is put into an inactive state immediately, prior to the call being answered. There are some really nice diagrams on how all of these connections work too.
- Several of the messages to this are completely ignored but some are processed, such as SdpUpdate. This was a feature that is called when a second device (phone and laptop) are both connecting to the call. Using this functionality, it is possible to force a connection!
- Overall, state handling is hard. Memory corruption bugs are awesome and have universal patterns; hence, they sometimes require a lesser understanding of the system. These logic bugs require a very deep understanding of the ecosystem, but are fruitful once it is understood.
Windows Kernel DoS/Privilege Escalation via a NULL Pointer Deref
Simon Zuckerbraun - ZDI Reference →Posted 5 Years Ago- The vulnerability is a NULL pointer dereference because of an assumption being made by the object being passed in. Essentially, the object expects for a particular type of handler to be there but does NOT require this. Without any validation the handler can be set to NULL to trigger a jump to address 0.
- Is this exploitable? It is a NULL pointer dereference after all. That is where the fun begins! In Windows, the NULL address is actually mapped for 16-bit processes under the
NTVDM subsystem, which is only available on 32-bit. So, it IS possible to execute code from there! - Well, kind of. Modern operating systems have a protection that separates kernel code vs. userland code. This means that even if we could map something to 0 directly in userland (with the situation above), the SMEP protection would crash if the kernel jumped to this point.
- Apparently, the author disabled SMEP and installed the NTVDM subsystem in order to verify that this exploit worked. Although this requires a very convoluted scenario, it is still possible to pull of!
- When creating an account with an email, it is common practice to verify the email by sending an email to this user. In some functionality, it is common for applications to give specific access depending on the email being used, such as Slack workspaces.
- What if you could break the parsing of the email verification? You could get credentials for something complicated! The application being tested used AWS Simple Email Service (SES) in order to send verification details but verified the domain using something else.
- After a bunch of tests, the author came up with an input that worked (after a BUNCH of tests) differently on the two services:
<aaa@bbb.com>ccc@ddd.com. AWS SES sends the message to theaaa@bbb.combut website usedddd.comas the domain for verification! - Using this discrepancy in the parsing, an email can be sent to one domain, but verified at another. This allows a bypass in the domain verification on the site.
- After finding this one vulnerability, the author decided to look at a plethora of different email address parsing libraries to see which combinations would be vulnerability. From combinations of Python to PHP to NodeJS, the author found one other combination that was vulnerable and two that might be.
- This is another classic discrepancy between two parsers leading to a security issue. This never gets old to read about!
- The SameSite cookie flag is a protection meant to protect users against CSRF at the browser-level instead of the server-side level. This cookie flag that only parties from the first-domain (google.com to google.com) can send cookies off.
- Recently (beginning of 2020), browsers have decided to have the SameSite cookie attribute to default to Lax (instead of None) in order to try to kill off the CSRF attack. But, with one special quirk...
- Cookies set within the last two minutes without the SameSite flag will NOT abide by this rule. This is in order to give developers time to fix the login flows on a bulk of websites while limiting the damage greatly.
- The author mentions this functionality, named LAX + POST, is temporary. But, as of January of 2021, it appears that nothing has changed.
Heap-based Buffer Overflow in Sudo (CVE-2021-3156)
Qualys - Baron Samedit Reference →Posted 5 Years AgoSudois a setuid program that allows a user to execute commands as another user (impersonation feature). Because of this, finding a vulnerability in sudo is an important privilege escalation.- When running
sudowith the-sor-iflag, turns on functionality that rewrites argv by concatenating all command-line arguments and by escaping all meta-characters with backslashes. Parsing is really hard! - When this transferring and escaping happens, is where the parsing issues occur. If a command line input ends with a single backslash, then issues happen with the copying functionality. It causes the while loop to over deviate because of an unexpected increase in the buffer. In other words, set_cmnd() is vulnerable to a heap-based buffer overflow, because the out-of-bounds characters that are copied to the "user_args" buffer were not included in its size.
- Here is the problem though: it is not possible to call this function with a single backslash, by default. By calling
sudoedit, the escape code can be skipped, causing the vulnerable path to hit. An example crashing exploit looks like thesudoedit -s '\' `perl -e 'print "A" x 65536'`. This hits iterates once too many, then copies extra data from the heap. - To an attacker, this buffer overflow is awesome because
- The size of the "user_args" buffer that we overflow, which is just the size of our concatenated command line arguments.
- Independently control the size and contents of the overflow itself. Our last command-line argument is conveniently followed by our first environment variables.
- Even write null bytes to the buffer that we overflow (every command-line argument or environment variable that ends with a single backslash writes a null byte to user_args.
- The original idea for exploitation was to corrupt locale strings in order to turn this into a format string exploit. This is a common exploitation for sudo and other binaries with locales used. However, this technique did not produce any good results.
- After setting up a fuzzer to find different exploitation primitives, a few ways were found that caused crashes with the proper heap grooming.
- The first interesting crash was a direct overwrite of a function pointer within
process_hooks_getenv. The main thing to note was that the function pointer could be partially overwritten in order to bypass ASLR. - The second exploitation method was found by a crash in
nss_load_library. Using this crash, it was possible to overwrite the file path of the library being loaded to load an arbitrary library. - The final way they found to exploit this was different than all of the others. From the fuzzing, they noticed that a bunch of directories were created with root privileges by overwriting the location of the def_timestampdir. Using this, we can overwrite this directory then we can race against Sudo's ts_mkdirs(), create a symlink to an arbitrary file and (or create) this arbitrary file as root, and write a struct timestamp_entry to it.
- Using this timestamp writing functionality, we can open
/etc/passwdand write a user into this. Now, we can use sudo and become root.
- PDFs are all over the internet, created without much effort and parsed everywhere. Does this have any security issues?
- The first classification of attacks is denial of service (DoS). Within PDFs set of supported languages (JavaScript, etc.) infinite loops can be created. Additionally, this a classic compression expansion technique (like a zip bomb) can be done with the deflate command.
- Using built in features of PDFs, data may be stolen. First, forms being filled out (by the user) can send the data off silently, exfiltrating the data. Calling home also leaks the IP address of the user, which is a privacy issue.
- The others are very theoretical and are specific to implementation, such as parsing issues with files. I did not find this part of the article very useful.
- The
go getdownloads and builds a package that contains import "C". With CLI tools, it is the goal of most systems (including Go) to limit code execution via commands being ran. - A bug in the package handling process allowed for setting the current directory to check for gcc when building the library. Because this occurs, we can control what gets executed! This means that running the
go getcommand can run arbitrary code on downloading. - So, what is the fix? They came up with two of them. The first solution was to pass the full path of the GCC compiler instead of a just a command. The second fix was to remove the ability to execute a command based upon the PATH variable having . inside of it.
