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!
- There are 12 extremely serious bugs that are mentioned (all critical). So, sit back, relax and enjoy findings from all of the Apple platforms!
- First, a complete authentication bypass was discovered on the Apple Distinguished Educators site, which used a Jive forum to work.
- This bypass was done because a custom password value (###INvALID#%!3) which was imbedded in the page, was used to determine if this was a new user or not. If this was a new user, then the sigin-with-apple account would be linked to this account, resulting in an authorization bypass with all accounts that had no registered on the site.
- After this, they wanted to get admin access to the Jive console. The URL admin/ had a deny list on it. However simply adding a semi-colon (/admin;/) to the URL would make it possible to go to the Jive admin console.
- The next bug was an authorization bypass of the manufacturing and distribution site that Apple used. At first, there is nothing interesting because you need credentials to login; otherwise, you are just redirected back. However, there is a special case where an authenticated user needs to access site functionality: password reset.
- The password reset functionality gave a user the account name Apple No Password User. Using these credentials, it was possible to use the OAuth endpoint in order to generate a Bearer token to use the rest of the site! After reversing the APIs, they had full access to the site.
- iCloud has an email client that you can use! The next vulnerability was a stored XSS via bad sanitization and altering of tags. Using this, there was an easy stored XSS (via email) that could be used to steal all iCloud information.
- What are other good targets for findings XSS? Hyperlinks are typically translated into actual links, within the web browser with anchor tags. However, doing this properly is extremely difficult to properly. So, the author found a way to break out of this with weird parsing to get XSS.
- The next bug is a simple command injection within the ePublisher functionality. This was found because of an error message that was returned that looked suspiciously like CLI output. From there, they add
|| test123and recieved the error message/bin/sh: 1: test123: not foundto make this fully known to be command injection. - With iCloud and the Open in Pages functionality, the URl was sending a request to a allowed-listed domain on the internal network. However, adding the @ourdomain.com, resulting in the first part of the URL appearing to be a username.
- Using then bug, a SSRF vulnerability could be used in order to exfiltrate the returned data from Apple, including the source code for iOS and other things.
- Another bug was providing by messages to a particular API gave back extremely verbose error messages that included authorization tokens. Using these authorization tokens, parts of some applications could be visited.
- Within Apple Books, they found two interesting bugs. First, a trivial XSS on the book title (no need to talk about this more). Secondly, a noticed that screenshots were being taken of HTML of books in an S3 bucket. By assumption, they assumed this MUST be using PhantomJS to do this.
- Because PhantomJS was being used, they added JS XSS payloads into the HTML in order to perform SSRF on the internal network. Because this was running in AWS, they could use the SSRF to steal arbitrary data from the S3 bucket and some AWS temporary creds.
- Next, a SpringBoot (eSign) application exposed the actuator/heapdump endpoint, which allowed for a complete compromise of the application. This dump (a .db file) had valid session tokens for Apple employees! This gave them access to 50+ new application endpoints on the site.
- XXE (no response) into a blind SSRF was another bug.
- An SQLi was found in the GBI Vertica endpoint. This endpoint was created custom SQL queries, with the ability to control most parts of a query. Although Vertica was trying to prevent SQLi, it was trivial to escape the queries and return arbitrary data. The only thing was bypassing the restrictions of the keywords with
/**/constants - A BUNCH of IDORs were discovered on various applications, including one in FindMyFriends.
- Overall, this shows a few important things:
- All things are hackable. Just spend the time, put in the effort and you will find vulns
- Apple has a high security-by-obscurity by restricting access as much as possible, which can give the illusion of security. However, these findings prove this does NOT work.
- XSS is still hard to prevent in complicated applications
- Error messages are really valuable for recon and info disclosure
- Recon is incredibly important! Take the time to understand the infrastructure and find all of the targets
- Apache Struts is a MVC framework for building Java-based web applications.
- Struts uses the Java Servlet API to provide a Controller (C in MVC) called Actions defined in an XML configuration file. They are accessed in the following way:
http://server:port/path/, where <action> is replaced with an action name. The .action is only by convention and some services uses ".do"..action - Struts also supports the use of Object Graph Navigational Language (OGNL) expressions to dynamically generate templated .jsp files. OGNL is a special Expression Language (EL) that is used in Java.
- When using templating, there are many 'gotchas' in terms of security. The one described in the article is known as double evaluation because of an improper templating type being used.
- This double evaluation is important because instead of only substituting the variable, the variable is substituted then executed! OGNL has access to a plethora of Java gadgets that eventually lead to code execution. The issue is using
%{...}or${...}in an unsafe way. - This Apache struts vulnerability was patched in the most recent version but ensuring proper validation of each value that is coming in. However, the root cause of using the templating in the wrong way is still there; looks like there are more bugs to be found here!
- DOMPurify is a common HTML sanitizer library that helps block untrusted HTML code into entering the page. Most importantly, it helps prevent XSS.
- Mutation XSS is the browser/library selectively altering the HTML in order to produce XSS where it did not exist before. In this case, the author used a quirk of the specification: forms cannot be nested inside of each other.
- There are three types of namespaces (in a DOM tree): HTML, SVG and MathML. These three different namespaces are parsed separate ways, but do have odd integration points.
- With these different namespaces and integration points, it was possible to do mutation XSS that was not even an XSS before! This is because a form tag gets stripped, resulting in the namespace of a tag to change.
- Overall, good write up for the XSS with good background. In the future, I think I'll be looking at the specs more :) This guy uses references the HTML specification quite a bit!
Enter the Vault: Authentication Issues in HashiCorp Vault
Felix Wilhelm - Project Zero Reference →Posted 5 Years Ago- HashiCorp Vault is a widely used tool for securely storing, generating and accessing secrets such as API keys, passwords or certificates. Although this does provide security benefits, it is a dream for an attacker, if they can get access. Because of how impactful this could be, it makes a wonderful target.
- The 'Vault' has MANY ways of authenticating to it, including AWS and GCP cloud environments, LDAP or Radius, OpenID Connect and many more. Within AWS, this looks like giving specific functions access to data via a Role (temporary credentials). This goes two ways: share a role name with Vault and create a role in AWS.
- When the Llambda function executes, it authenticates to Vault with a simple API call to
/v1/auth/aws/loginto return a short lived token to for the needed secret. Even though this appears to be secure, how does the endpoint validate roles? IAM is complex and using it outside of the AWS ecosystem is difficult to do properly. - The actual request (for the API in Vault) was signed (similar to AWS SigV4). However, it did not verify many things, such as the URL path, query, POST body or any HTTP headers. This lack of validation (although the rest of the request was signed) led to a complete compromise in the authentication.
- The first two ideas did not pan out: altering the query parameter itself (https://sts.amazonaws.com/:foo@example.com/test) and altering the host header did not yield any fruit. So, we have looked at the request, how about the response?
- The response looks for XML data from STS and just expects a status code of 200. However, the Vault never verifies the XML response, as STS should always send back good data. Why is this bad? It turns out that AWS also supports JSON responses and not just XML! For some reason, Go (which is the language used in this case) allows for non-XML data to be used and will attempt to parse whatever is passed in!
- The AssumeRoleWithWebIdentity is used in order to verify JWT's with an OpenID Connect (OIDC) provider into AWS IAM identities. SubjectFromWebIdentityToken is a response element that can be used for this type of STS token.
- So, again what do we control: path, request response type and some data being passed in. From the JSON response (and being able to control the path) it was possible to make a request to the OpenID and keep back a controllable field of the JWT that could contain XML: sub. Of course, this required a custom IdP in order to work (which the author had to make).
- What does this allow? We can spoof the response from STS to be something that is attacker controlled, allowing for the authentication of arbitrary user roles! We can now see all secrets in HashiCorp that use AWS. All an attacker needs to know is the role name to use.
- Now, for the GCP equivalent... The GCP env strictly uses JWT tokens throughout. JWTs have MANY ways to go wrong, especially in environments with multiple hierarchies of keys (such as google). People often see JWTs as a silver bullet but improper usage can be destroy to the security of the system.
- GCP has a multitude of ways to sign JWTs (with valid signatures). Even though the service verifying assumes that the claims are proper (from GCP), it is possible to use a GCP generated key to create arbitrary compute_engine claims to act as a metadata server. Of course, this JWT must have all other proper fields for it to be considered a proper VM.
- Boom, GCP version authorization bypass by creating a spoofed JWT.
- Quote in the conclusion - "In my experience, tricky vulnerabilities like this often exist where developers have to interact with external systems and services. A strong developer might be able to reason about all security boundaries, requirements and pitfalls of their own software, but it becomes very difficult once a complex external service comes into play. Modern cloud IAM solutions are powerful and often more secure than comparable on-premise solutions, but they come with their own security pitfalls and a high implementation complexity. As more and more companies move to the big cloud providers, familiarity with these technology stacks will become a key skill for security engineers and researchers and it is safe to assume that there will be a lot of similar issues in the next few years."
- To me, introducing the Cloud Computing revolution sounds great, but comes with its own risk of high complexity. There are many bugs like this out there, we just have to look!
- The HP Device Manager uses TCP port 1099 on the internal networks for lots of enterprises. This is the default port for Java Remote Method Invocation (RMI) service registry.
- With the remote call, deserialization must take place. So, the first idea was to attack this. Using some Java gadgets, it was possible to
- One of the remote calls was called ServGetUser and was used to retrieve HP Device Manager accounts. Using this call, it was possible to steal MD5 hashes of users. Using this, it would be possible to run a dictionary attack or brute force the hashes to the passwords.
- Hibernate is a query language that allows for object relational mapping object classes to relational database tables so that developers do not have to write SQL queries by hand. Hibernate Query Language(HQL) is one way to query for this information.
- There's this old thing called SQL Injection(SQLi). Although this vulnerability is impactful, it has largely been patched. This application had a query injection in a similar language: HQL Injection (HQLi). After some time planning around with injection queries into HQL, the author had successfully figured out how to smuggle arbitrary queries into HQL that would talk to the installed Postgres database.
- By being able to injection arbitrary commands into HQL (hence PostgresDB), the author used a known privilege escalation/RCE technique in PostgresDB in order to become root.
- From the HQL injection, it was become to become the root user! Overall, this was a well written article with many rabbit holes being discussed along the way.
- Cross-Site Request Forgery (CSRF) is a somewhat dying bug in the age of modern browsers. However, if found, the attack is quite devastating, as a single click can force actions to be performed as that user.
- This exploit is only possible on Google PDF products on Internet Explorer. The reason why? Content-Sniffing! This is the practice of inspecting request data to deduce the ACTUAL file format, even if a specific Content-Type is specified.
- Why is this a security issue? Well, what would happen if a text file could be converted into an HTML document when being loaded back? The HTML would execute, even though it was just a text file.
- In previous research is was shown that PDFs support a language called formcalc which can execute GET, POST and PUT commands. Why is this a big deal? Well, if they can upload PDF's, a user can create makes requests on an origins website using formcalc.
- This particular MIME sniffing attack can be used in order to trick I.E. into thinking that any URL is a PDF. This is a big deal because is bypasses the Same Origin Policy (SOP), allowing us to run requests (on the hosting domain) from the previous research done.
- To perform this attack, attach
;.pdfto the end a URL and have some PDF-looking content within the request. Using this, it is possible to make arbitrary requests in the users browser, on the hosting domain. The new piece of research here is adding the MIME sniffing attack to the PDF SOP bypass, making this MUCH more exploitable. - From the research, the most common place for this vulnerability was on CSV export/import functionality. Although this only affected IE and several clicks were required, Google paid out 30K!
- Slightly confused on this (the article is not the best explained article) so feel free to reach out to correct any wrong parts of this post. Thanks!
- This is a dedicated security guy who has been a senior engineer for Android and ChromeOS since 2011. Additionally, he was the technical security lead on the Ubuntu team for 6 years. So, this guy knows security!
- On his blog, he posts technical articles about software security mitigations. In particular, he does a security feature review of version releases for Linux, such as here.
- Overall, just a good guy to keep tabs on!
- Fork can fail! What does it fail when it returns? -1!
- What happens when you send a signal with kill with -1? It targets ALL processes!
- So, if you can get fork to fail (and it is not the checked), you can trick the signal call to send the signal to ALL processes!
- I did a similar thing with -1 while writing a CTF challenge. So, this was a fun little thing that I wanted to mark down.
Exploiting Other Remote Protocols in IBM WebSphere
Zero Day Initiative (ZDI) Reference →Posted 5 Years Ago- There are two vulnerabilities in this blog post: authorization bypass and arbitrary file write. They will be discussed in this order.
- The first vulnerability is really just poor logic. The authentication handling in IBM WebSphere has MANY different ways and is very complex. The program uses SOAP (XML stuff) in order to do the authorization dance.
- When using token based authorization, there was a check to see if the user DOES NOT have a proper authorization token, by checking for NULL. But, in reality, this passes a value back called Unauthenticated instead of NULL. Now, the user can use the rest of the program, with limited users access.
- From this minimal authorization bypass, it was possible to trigger a Deserialization Vulnerability that had already existed. But, the "patch" (notice the bunny ears) was to ensure that the user was authenticated. Because of this authorization bypass, this vuln was back on the table!
- After this, the author had to find a custom Deserialization Gadget (as most of the default Java ones have been fixed now), which has in a different blog post entirely
- The second vulnerability was a classic directory traversal in the file upload functionality. Of course, this allowed for an easy RCE :)
- Arbitrary URL redirections are a common vulnerability where the impact is often disputed. Some bug bounty reports do not consider this a vulnerability at all.
- So, with the arbitrary URL redirection, what else can be done? In order to increase the impact, the author of this article asked that question!
- On the 302 redirect, all URL encoded data was decoded and put into the body. In fact, this even includes newlines! Because of this, it was possible to alter the body of the 302 redirect. This is called a CRLF (carriage return, line feed) injection.
- From this, the author pulls up articles that found ways to get XSS via a 302 redirect. However, most modern browsers will not execute JavaScript in this context.
- After brute forcing several URIs, it was discovered that (on Firefox) using the websocket URIs (ws or wss) for the redirect link allowed for the JavaScript to be executed!
- To make matters even better, another user posted that a similar bypass exists (on Chrome) by not having a redirect link (just adding the newlines and the XSS payload) all together.
- So, have an arbitrary redirect? Try to make the impact even better by turning it into an XSS!
