Yangquan or Bust

Jennifer

How do I get started with bug bounty hunting? How do I improve my skills?

These are some simple steps that every bug bounty hunter can use to get started and improve their skills:

Learn to make it; then break it!
A major chunk of the hacker's mindset consists of wanting to learn more. In order to really exploit issues and discover further potential vulnerabilities, hackers are encouraged to learn to build what they are targeting. By doing this, there is a greater likelihood that hacker will understand the component being targeted and where most issues appear. For example, when people ask me how to take over a sub-domain, I make sure they understand the Domain Name System (DNS) first and let them set up their own website to play around attempting to "claim" that domain.

Read books. Lots of books.
One way to get better is by reading fellow hunters' and hackers' write-ups. Follow /r/netsec and Twitter for fantastic write-ups ranging from a variety of security-related topics that will not only motivate you but help you improve. For a list of good books to read, please refer to "What books should I read?".

Join discussions and ask questions.
As you may be aware, the information security community is full of interesting discussions ranging from breaches to surveillance, and further. The bug bounty community consists of hunters, security analysts, and platform staff helping one and another get better at what they do. There are two very popular bug bounty forums: Bug Bounty Forum and Bug Bounty World.

Participate in open source projects; learn to code.
Go to https://github.com/explore or https://gitlab.com/explore/projects and pick a project to contribute to. By doing so you will improve your general coding and communication skills. On top of that, read https://learnpythonthehardway.org/ and https://linuxjourney.com/.

Help others. If you can teach it, you have mastered it.
Once you discover something new and believe others would benefit from learning about your discovery, publish a write-up about it. Not only will you help others, you will learn to really master the topic because you can actually explain it properly.

Smile when you get feedback and use it to your advantage.
The bug bounty community is full of people wanting to help others so do not be surprised if someone gives you some constructive feedback about your work. Learn from your mistakes and in doing so use it to your advantage. I have a little physical notebook where I keep track of the little things that I learnt during the day and the feedback that people gave me.

Learn to approach a target.
The first step when approaching a target is always going to be reconnaissance — preliminary gathering of information about the target. If the target is a web application, start by browsing around like a normal user and get to know the website's purpose. Then you can start enumerating endpoints such as sub-domains, ports and web paths.

A woodsman was once asked, "What would you do if you had just five minutes to chop down a tree?" He answered, "I would spend the first two and a half minutes sharpening my axe."
As you progress, you will start to notice patterns and find yourself refining your hunting methodology. You will probably also start automating a lot of the repetitive tasks.

More articles

Jennifer

During a CTF game, we came across very-very old systems. Turns out, it is not that easy to hack those dinosaur old systems, because modern tools like Metasploit do not have sploits for those old boxes and of course our "133t h4cking skillz" are useless without Metasploit... :)

But I had an idea: This can be a pretty good small research for fun.

The rules for the hack are the following:

Only publicly available tools can be used for this hack, so no tool development. This is a CTF for script bunniez, and we can't haz code!
Only hacks without user interaction are allowed (IE based sploits are out of scope).
I need instant remote code execution. For example, if I can drop a malware to the c: drive, and change autoexec.bat, I'm still not done, because no one will reboot the CTF machine in a real CTF for me. If I can reboot the machine, that's OK.
I don't have physical access.

I have chosen Windows 95 for this task. First, I had to get a genuine Windows 95 installer, so I visited the Microsoft online shop and downloaded it from their official site.

I installed it in a virtualized environment (remember, you need a boot floppy to install from the CD), and it hit me with a serious nostalgia bomb after watching the installer screens. "Easier to use", "faster and more efficient", "high-powered performance", "friendly", "intuitive interface". Who does not want that? :)

Now that I have a working Windows 95 box, setting up the TCP/IP is easy, let's try to hack it!

My first tool is always nmap. Let's scan the box! Below I'm showing the interesting parts from the result:

PORT      STATE           SERVICE       VERSION 139/tcp   open            netbios-ssn 137/udp   open|filtered   netbios-ns 138/udp   open|filtered   netbios-dgm Running: Microsoft Windows 3.X|95 OS details: Microsoft Windows for Workgroups 3.11 or Windows 95 TCP Sequence Prediction: Difficulty=25 (Good luck!) IP ID Sequence Generation: Broken little-endian incremental

The first exciting thing to note is that there is no port 445! Port 445 is only since NT 4.0. If you check all the famous windows sploits (e.g., MS03-026, MS08-067), all of them use port 445 and named pipes. But there are no named pipes on Windows 95!

Because I'm a Nessus monkey, let's run a free Nessus scan on it!

Only one critical vulnerability found:

Microsoft Windows NT 4.0 Unsupported Installation Detection

Thanks for nothing, Nessus! But at least it was for free.

Next, I tried GFI Languard, nothing. It detected the machine as Win95, the opened TCP port, and some UDP ports as open (false-positive), and that's all...

Let's try another free vulnerability scanner tool, Nexpose. The results are much better:

CIFS NULL Session Permitted
Weak LAN Manager hashing permitted
SMB signing not required
Windows 95/98/ME Share Level Password Bypass
TCP Sequence Number Approximation Vulnerability
ICMP netmask response
CIFS Share Readable By Everyone

I think the following vulnerabilities are useless for me at the moment:

Weak LAN Manager hashing permitted - without user interaction or services looking at the network, useless (I might be wrong here, will check this later)
TCP Sequence Number Approximation Vulnerability - not interesting
ICMP netmask response - not interesting
CIFS Share Readable By Everyone - unless there is a password in a text file, useless

But we have two interesting vulns:

CIFS NULL Session Permitted - this could be interesting, I will check this later ...
Windows 95/98/ME Share Level Password Bypass - BINGO!

Let me quote Nexpose here:

"3.2.3 Windows 95/98/ME Share Level Password Bypass (CIFS-win9x-onebyte-password)

A flaw in the Windows 95/98/ME File and Print Sharing service allows unauthorized users to access file and print shares by sending the first character of the password. Due to the limited number of attempts required to guess the password, brute force attacks can be performed in just a few seconds.

Established connection to share TEST with password P."

The vulnerability description at MS side:

http://technet.microsoft.com/en-us/security/bulletin/ms00-072

For example if the password is "Password" (without quotes) and the client sends the password "P" (without quotes) and the length of 1, the client is authenticated. To find the rest of the password, the attacker increments the length to 2 and starts guessing the second letter until he reaches "PA" and gets authenticated again. As share passwords in Windows 95 are not case sensitive, "Pa" and "PA" will also be accepted. The attacker can continue to increment the length and guessing the next letter one-by-one until he gets the full "PASSWORD" (as the maximum length is 8 characters).

I believe all characters between ALT+033 and ALT+255 can be used in the share password in Windows 95, but as it is case insensitive, we have 196 characters to use, and a maximum length of 8 characters. In worst case this means that we can guess the full password in 1568 requests. The funny thing is that the share password is not connected to (by default) any username/account, and it cannot be locked via brute force.

Luckily there is a great tool which can exploit this vulnerability:

Share Password Checker

Let's check this tool in action:

W00t w00t, it brute forced the password in less then 2 seconds!

Looking at a wireshark dump we can see how it is done:

As you can see, in the middle of the dump we can see that it already guessed the part "PASS" and it is brute-forcing the fifth character, it founds that "W" is the correct fifth character, and starts brute-forcing the sixth character.

If we are lucky with the CTF, the whole C:\ drive is shared with full read-write access, and we can write our team identifier into the c:\flag.txt. But what if we want remote code execution? Stay tuned, this is going to be the topic of the next part of this post.

Continue reading

Jennifer

In July 2020, we introduced a novel attack class called Shadow Attacks. In our recent research, we discovered a new variant of the attack which relies only on an Incremental Update containing a malicious trailer.
A proof-of-concept exploit working on Foxit (Version: 11.0.1.49938) can be downloaded here.

The story so far ...

Shadow attacks are attacks bypassing the integrity protection of digitally signed PDF documents. The attacks abuse two legitimate features in PDF documents which we briefly explain.

Hiding Content

In PDFs, there are multiple techniques to hide content that is not displayed when the document is opened. We, as attackers, usually hide malicious objects without referencing them in the xref section.

Incremental Updates

New content can be appended to a signed PDF document. This is quite dangerous though. The digital signature in PDFs protects a specific range of bytes. Any appended content does not break the signature verification since it is outside this range. As a result, any new Incremental Update does not violate the cryptographic verification of the digital signature.

But, Incremental Updates are quite dangerous since they may completely change the displayed content of the document. In 2019, we showed different techniques based on Incremental Updates – the Incremental Saving Attacks.
As a countermeasure, most vendors warn if additional content is added after signing the document. BUT … not always!!!

There are meaningful use cases where Incremental Updates in digitally signed documents are allowed. For instance, contracts should be signed by multiple parties and each new signature is applied via additional Incremental Update.
Also, PAdES defines Incremental Updates as part of the long-term validation of digitally signed PDFs.
In summary, Incremental Updates are painful from a security perspective. Currently, vendors are trying to estimate whether an Incremental Update is malicious or not by analyzing its content.

Shadow Attacks

Shadow attacks, in general, deceive the PDF applications that an Incremental Update is not malicious. This can be done by providing an Incremental Update with minimal content.
In 2020, we estimated that appending an xref section and a trailer is sufficient to bypass the detection mechanisms of popular applications such as Adobe Reader and Foxit Reader.

Trailer-based Shadow Attack

Three months ago, we tried to reduce the content of the malicious Incremental Update. Our idea was to use only a malicious trailer and still change the content of the entire document when it is opened. Let's see how this can be done.

The Signer's view on the document

If a signer gets the document depicted on the left side, he or she sees the content "Sign the document to get a reward".
The document contains a hidden content depicted as red text – the 4 0 obj containing the text "You are fired. Get out immediately" and an xref section pointing to that object. However, the trailer references another xref section, see (1) and (2). Thus, the red text is never shown.
From the signer's perspective, there is no possibility to detect the hidden content by opening and reviewing the document.
As a result, the signer, for example the company director, signs the document.

The Victim's view on the document

We assume that the attacker receives the signed document and manipulates it.
The attacker appends only a trailer that points to the hidden malicious xref section (the red one). When the victim opens the document, the content "You are fired. Get out immediately" is shown.
However, the digital signature validation does not throw any warning since … well … what could go wrong if only a trailer is appended.

Honest vs. Malicious Trailer

There are small differences between the honest and the malicious trailer– the byte position of the xref section. Now, the trailer points to the hidden xref section.

trailer
<<
/Size 23
/Prev 18735
/Root 13 0 R
]>>
Honest trailer

trailer
<<
/Size 23
/Prev 19192
/Root 13 0 R
]>>
Malicious trailer

Impact and Exploit

We successfully applied the new attack on Foxit Reader (Version: 11.0.1.49938). We promptly reported the vulnerability and provided a Proof-of-Concept (PoC) exploit, known as CVE-2021-40326.
Foxit acknowledged the attack and published a security fix with the new version Foxit Reader 11.1.

We are not aware of any further implementations vulnerable to this attack.
If you think that your application might be vulnerable to the attack, then just download the exploit and test on your own.

Authors of this post

Vladislav Mladenov

Simon Rohlmann

Christian Mainka

More information

Jennifer

Automating REST Security Part 3: Practical Tests for Real-World APIs

If you have read our two previous blogposts, you should now have a good grasp on the structural components used in REST APIs and where there are automation potentials for security analysis. You've also learned about REST-Attacker, the analysis tool we implemented as a framework for automated analysis.

In our final blogpost, we will dive deeper into practical testing by looking at some of the automated analysis tests implemented in REST-Attacker. Particularly, we will focus on three test categories that are well-suited for automation. Additionally, we will look at test results we acquired, when we ran these tests on the real-world API implementation of the services GitHub, Gitlab, Microsoft, Spotify, YouTube, and Zoom.

Author

Christoph Heine

Overview

Undocumented Operations

The first test that we are going to look at is the search for undocumented operations. These encompass all operations that accessible to API clients despite not being listed in the API documentation. For public-facing APIs, undocumented operations are a security risk because they can expose functionality of the service that clients are not supposed to access. Consequences can range from information leakage to extensive modification or even destruction of the resources managed by the underlying service.

A good example for an operation that should not be available is write access to the product information of a webshop API. While read operations on stock amounts, prices, etc. of a product are perfectly fine, you probably don't want to give clients the ability to change said information.

In HTTP-based REST, operations are represented by the HTTP methods used in the API request (as explained in Part 1 of the blog series). Remember that API requests are essentially HTTP requests which consist of HTTP method (operation), URI path (resource address) and optional header or body data.

GET /api/shop/items

We can use the fact that REST operations are components from the HTTP standard to our advantage. First of all, we know that the set of possible operations is the same for all HTTP-based REST APIs (no matter their service-specific context) since each operation should map to a standardized HTTP method. As a result, we also have a rough idea what each operation does when it's applied to a resource, since it's based on the assigned purpose of the HTTP method. For example, we can infer that the DELETE method performs a destructive action a resource or that GET provides a form of read access. It also helps that in practice most APIs only use the same 4 or 5 HTTP methods representing the CRUD operations: GET, POST, PUT, PATCH, and DELETE.

If we know a URI path to a resource in the API, we can thus enumerate all possible API requests, simply by combining the URI with all possible HTTP methods:

GET    /api/shop/items POST   /api/shop/items PUT    /api/shop/items PATCH  /api/shop/items DELETE /api/shop/items

REST-Attacker's test case undocumented.TestAllowedHTTPMethod uses the same approach to find undocumented operations. With an OpenAPI description, the generation of API requests is extremely to automate as the description lists all defined URI paths. Since the API description also documents the officially supported operations, we can slightly optimize the search by only generating API requests for operations not documented for a path (which basically are the candicates for undocumented operations).

To find out whether an undocumented operation exist, we have to determine if the generated API requests are successful. Here, we can again rely on a standard HTTP components that are used across REST APIs. By checking the HTTP response code of the API, we can see whether the API request was rejected or accepted. Since the response codes are standardized like the HTTP methods, we can also make general assumptions based on the response code received. If the operation in the API request is not available, we would expect to get the dedicated response code 405 - Method Not Allowed in the response. Other 4XX response codes can also indicate that the API request was unsuccessful for other reasons. If the operation is accepted, we would expect the API response to contain a 2XX response code.

Using the same approach, we let REST-Attacker search for undocumented operations in all 6 APIs we tested. None of them exposed undocumented operations that could be identified by the tool, which means they would be considered safe in regards to this test. However, it's interesting to see that the APIs could responded very differently to the API requests sent by the tool, especially when considering the response codes.

API	Response Codes
GitHub	`401`, `404`
Gitlab	`400`, `404`
MS Graph	`400`, `401`, `403`, `404`
Spotify	`405`
YouTube	`404`
Zoom	`400`, `401`, `403`, `404`, `405`

Spotify's API was the only one that used the 405 response code consistently. Other APIs returned 400, 401, 403, or 404, sometimes depending on the path used in the the API request. It should be noted that the APIs returned 401 - Unauthorized or 403 - Forbidden response codes even when supplying credentials with the highest possible level of authorization. An explanation for this behaviour could be that the internal access checks of the APIs work differently. Instead of checking whether an operation on a resource is allowed, they may check whether the client sending the request is authorized to access the resource.

Credentials Exposure

Excessive Data Exposure from OWASP's Top 10 API Security Issues is concerned with harmful "verbosity" of APIs. In other words, it describes a problem where API responses contain more information than they should return (hence excessive exposure). Examples for excessive data exposure include leaks of private user data, confidential data about the underlying service, or security parameters of the API. What counts as excessive exposure can also depend on the application context of the underlying service.

Since the definition of excessive data exposure is very broad, we will focus on a particular type of data for our practical test: Credentials. Not only do credentials exist in some form for almost any service, their exposure would also have a significant impact on the security of the API and its underlying service. Exposed credentials may be used to gain higher privileges or even account takeovers. Therefore, they are a lucrative target for attacks.

There are several credential types that can be interesting for attackers. Generally, they fit into these categories:

long-term credentials (e.g., passwords)
short-term credentials (e.g., session IDs, OAuth2 tokens)
service-specific credentials for user content (e.g., passwords for files on a file-hosting service)

Long- and short-term credentials should probably never be returned under any circumstances. Service-specific credentials may be less problematic in some specific circumstances, but should still be handled with care as they could be used to access resources that would otherwise be inaccessible to an API client.

The question is: Where can we start looking for exposed credentials? Since they would be part of the API responses, we could scrape the parameters in the response content. However, we may not actually need to look at any response values. Instead, we can examine the parameter names and check for association with credentials. For example, a parameter names "password" would likely contain a type of credential. The reason this can work is that parameter names in APIs are generally descriptive and human-readable, a side effect of APIs often being intended to be used by (third-party) developers.

In REST-Attacker, credentials parameter search is implemented by the resources.FindSecurityParameters test case. The test case actually only implements an offline search using the OpenAPI description, as the response parameter names can also be found there. The implementation iterates through the response parameter names of each API endpoint and matches them to keywords associated with credentials such as "pass", "auth" or "token". This naive approach is not very accurate and can produce a number of false-positives, so the resulting list of parameters has to be manually checked. However, the number of candidates is usually small enough to be searched in a small amount of time, even if the API defines thousands of unique response parameters.

API	Parameter Count	Candidates	service-specific
GitHub	2110	39	0
Gitlab	1291	0	0
MS Graph	32199	117	0
Spotify	290	6	0
YouTube	703	6	0
Zoom	800	96	2

5 out of 6 APIs we tested had no problems with exposed credentials.

Zoom's API was the only one which showed signs of problematic exposure of service-specific credentials by returning the default meeting password for meetings created via the API at an endpoint. It should be noted that this information was only available to approved clients and an required authorized API request. However, the credentials could be requested with few priviledges. Another problem was that Zoom did not notify users that this type of information was accessible to third-party clients.

Default Access Priviledges

The last test category that we are going to look at addresses the access control mechanisms of REST APIs. Modern access control methods such as OAuth2 allow APIs to decide what minimum priviledges they require for each endpoint, operation, or resource. In the same way, it gives them fine-grained control on what priviledges are assigned to API clients. However, for fine-grained control to be impactful, APIs need to carefully decide which priviledges they delegate to clients by default.

But why is it important that APIs assigned do not grant too many priviledges by default? The best practice for authorization is to operate on the so-called least priviledge principle. Basically, this means that a client or user should only get the minimum necessary priviledges required for the respective task they want to do. For default priviledges, the task is usually unspecified, so there are no necessary priviledges. In that case, we would expect an API to grant either no priviledges or the overall lowest functional priviledge level.

If the API uses OAuth2 as its access control method, we can easily test what the API considers default priviledges. In OAuth2, clients can request a specific level of priviledge via the scope parameter in the initial authorization request.

Including the scope parameter in the request is optional. If it's omitted, the API can deny the authorization request or - and that's what we are interested in - decide which scope it assigns to the authorization token returned to the client. By analyzing the default scope value, we can see whether the API adheres to the least priviledge principle.

REST-Attacker can automatically retrieve this information for configured OAuth2 clients with the scopes.TestTokenRequestScopeOmit test case. For every configured OAuth2 client, an authorization request without the scope parameter is sent to the OAuth2 authorzation endpoints of the API. The tool then extracts the scope that is assigned to the returned OAuth2 token. This scope value then has to be manually analyzed.

Out of the 6 APIs we tested, 2 (MS Graph and YouTube) denied requests without a scope parameter. The other 4 APIs (GitHub, Gitlab, Spotify, and Zoom) allowed omitting the scope parameter. Therefore, only the latter 4 APIs assigned default prviledges that could be analyzed.

API	Assigned Scope	Least Priviledge?
GitHub	`(none)`	Yes
Gitlab	`api`	No
Spotify	(default)	Yes*
Zoom	all approved	No

* OAuth2 scope with least priviledges

Interestingly, the extent to which a least priviledge principle was followed varied between APIs.

GitHub's API assigned the overall lowest possible priviledges by default via the (none) scope. With this scope, a client could only access API endpoints that were already publicly accessible (without providing authorization). While the scope does not grant more priviledges than a public client would get, the (none) scope had other benefits such as an increased rate limit.

In comparison, the Spotify API had no publicly accessible API endpoints and required authorization for every request. By default, tokens were assigned a "default" scope which was the OAuth2 scope with the lowest available priviledges and allowed clients to access several basic API endpoints.

Gitlab's and Zoom's API went into the opposite direction and assigned the highest priviledge to their clients by default. In Gitlab's case, this was the api scope which allowed read and write access to all API endpoints. Zoom required a pre-approval of scopes that the client wants to access during client registration. After registration, Zoom returned all approved scopes by default.

Conclusion

We've seen that while REST is not a clarly defined standard, this does not result in REST APIs being too complex for a generalized automated analysis. The usage of standardized HTTP components allows the design of simple yet effective tests that work across APIs. This also applies to other components that are used across APIs such as access control mechanisms like OAuth2. The practical tests we discussed worked on all APIs we tested, even if their underlying application contexts were different. However, we've also seen that most of the APIs were generally safe against these tests.

Tool-based automation could certainly play a much larger role in REST security, not only for finding security issues but also for filtering results and streamlining otherwise manual tasks. In the long run, this will hopefully also result in an increase in security.

Acknowledgement

The REST-Attacker project was developed as part of a master's thesis at the Chair of Network & Data Security of the Ruhr University Bochum. I would like to thank my supervisors Louis Jannett, Christian Mainka, Vladislav Mladenov, and Jörg Schwenk for their continued support during the development and review of the project.

Yangquan or Bust

Monday, May 29, 2023

How Do I Get Started With Bug Bounty ?