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.
About discover: discover is a custom bash scripts used to automate various penetration testing tasks including recon, scanning, parsing, and creating malicious payloads and listeners with Metasploit Framework. For use with Kali Linux, Parrot Security OS and the Penetration Testers Framework (PTF). About authors:
RECON 1. Passive 2. Active 3. Import names into an existing recon-ng workspace 4. Previous menu Passive uses ARIN, dnsrecon, goofile, goog-mail, goohost, theHarvester, Metasploit Framework, URLCrazy, Whois, multiple websites, and recon-ng.
Active uses dnsrecon, WAF00W, traceroute, Whatweb, and recon-ng. [*] Acquire API keys for Bing, Builtwith, Fullcontact, GitHub, Google, Hashes, Hunter, SecurityTrails, and Shodan for maximum results with recon-ng and theHarvester.
API key locations: recon-ng show keys keys add bing_api <value> theHarvester /opt/theHarvester/api-keys.yaml
Person:Combines info from multiple websites. RECON First name: Last name: Parse salesforce:Gather names and positions into a clean list.
Create a free account at salesforce (https://connect.data.com/login). Perform a search on your target company > select the company name > see all. Copy the results into a new file. Enter the location of your list: About SCANNING in discover Generate target list:Use different tools to create a target list including Angry IP Scanner, arp-scan, netdiscover and nmap pingsweep. SCANNING 1. Local area network 2. NetBIOS 3. netdiscover 4. Ping sweep 5. Previous menu
CIDR, List, IP, Range, or URL Type of scan: 1. External 2. Internal 3. Previous menu
External scan will set the nmap source port to 53 and the max-rrt-timeout to 1500ms.
Internal scan will set the nmap source port to 88 and the max-rrt-timeout to 500ms.
Nmap is used to perform host discovery, port scanning, service enumeration and OS identification.
Matching nmap scripts are used for additional enumeration.
Addition tools: enum4linux, smbclient, and ike-scan.
Matching Metasploit auxiliary modules are also leveraged.
About WEB in discover Insecure direct object reference Using Burp, authenticate to a site, map & Spider, then log out. Target > Site map > select the URL > right click > Copy URLs in this host. Paste the results into a new file.
Enter the location of your file: Open multiple tabs in Firefox Open multiple tabs in Firefox with: 1. List 2. Directories from robots.txt. 3. Previous menu
Use a list containing IPs and/or URLs.
Use wget to pull a domain's robot.txt file, then open all of the directories.
Nikto Run multiple instances of Nikto in parallel. 1. List of IPs. 2. List of IP:port. 3. Previous menu SSL: Use sslscan and sslyze to check for SSL/TLS certificate issues. Check for SSL certificate issues. Enter the location of your list: About MISC in discover Parse XML Parse XML to CSV. 1. Burp (Base64) 2. Nessus (.nessus) 3. Nexpose (XML 2.0) 4. Nmap 5. Qualys 6. revious menu Generate a malicious payload Malicious Payloads 1. android/meterpreter/reverse_tcp 2. cmd/windows/reverse_powershell 3. java/jsp_shell_reverse_tcp (Linux) 4. java/jsp_shell_reverse_tcp (Windows) 5. linux/x64/meterpreter_reverse_https 6. linux/x64/meterpreter_reverse_tcp 7. linux/x64/shell/reverse_tcp 8. osx/x64/meterpreter_reverse_https 9. osx/x64/meterpreter_reverse_tcp 10. php/meterpreter/reverse_tcp 11. python/meterpreter_reverse_https 12. python/meterpreter_reverse_tcp 13. windows/x64/meterpreter_reverse_https 14. windows/x64/meterpreter_reverse_tcp 15. Previous menu Start a Metasploit listener Metasploit Listeners 1. android/meterpreter/reverse_tcp 2. cmd/windows/reverse_powershell 3. java/jsp_shell_reverse_tcp 4. linux/x64/meterpreter_reverse_https 5. linux/x64/meterpreter_reverse_tcp 6. linux/x64/shell/reverse_tcp 7. osx/x64/meterpreter_reverse_https 8. osx/x64/meterpreter_reverse_tcp 9. php/meterpreter/reverse_tcp 10. python/meterpreter_reverse_https 11. python/meterpreter_reverse_tcp 12. windows/x64/meterpreter_reverse_https 13. windows/x64/meterpreter_reverse_tcp 14. Previous menu
In the last two years, we changed the TLS-Attacker Project quite a lot but kept silent about most changes we implemented. Since we do not have so much time to keep up with the documentation (we are researchers and not developers in the end), we thought about creating a small series on some of our recent changes to the project on this blog.
We hope this gives you an idea on how to use the most recent version (TLS-Attacker 2.8). If you feel like you found a bug, don't hesitate to contact me via GitHub/Mail/Twitter. This post assumes that you have some idea what this is all about. If you have no idea, checkout the original paper from Juraj or our project on GitHub.
TLDR: TLS-Attacker is a framework which allows you to send arbitrary protocol flows.
So, what changed since the release of the original paper in 2016? Quite a lot! We discovered that we could make the framework much more powerful by adding some new concepts to the code which I want to show you now.
Action System
In the first Version of TLS-Attacker (1.x), WorkflowTraces looked like this:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Although this design looks straight forward, it lacks flexibility. In this design, a WorkflowTrace is basically a list of messages. Each message is annotated with a <messageIssuer>, to tell TLS-Attacker that it should either try to receive this message or send it itself. If you now want to support more advanced workflows, for example for renegotiation or session resumption, TLS-Attacker will soon reach its limits. There is also a missing angle for fuzzing purposes. TLS-Attacker will by default try to use the correct parameters for the message creation, and then apply the modifications afterward. But what if we want to manipulate parameters of the connection which influence the creation of messages? This was not possible in the old version, therefore, we created our action system. With this action system, a WorkflowTrace does not only consist of a list of messages but a list of actions. The most basic actions are the Send- and ReceiveAction. These actions allow you to basically recreate the previous behavior of TLS-Attacker 1.x . Here is an example to show how the same workflow would look like in the newest TLS-Attacker version:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As you can see, the <messageIssuer> tags are gone. Instead, you now indicate with the type of action how you want to deal with the message. Another important thing: TLS-Attacker uses WorkflowTraces as an input as well as an output format. In the old version, once a WorkflowTrace was executed it was hard to see what actually happened. Especially, if you specify what messages you expect to receive. In the old version, your WorkflowTrace could change during execution. This was very confusing and we, therefore, changed the way the receiving of messages works. The ReceiveAction has a list of <expectedMessages>. You can specify what you expect the other party to do. This is mostly interesting for performance tricks (more on that in another post), but can also be used to validate that your workflow executedAsPlanned. Once you execute your ReceiveAction an additional <messages> tag will pop up in the ReceiveAction to show you what has actually been observed. Your original WorkflowTrace stays intact.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
During the execution, TLS-Attacker will execute the actions one after the other. There are specific configuration options with which you can control what TLS-Attacker should do in the case of an error. By default, TLS-Attacker will never stop, and just execute whatever is next.
Configs
As you might have seen the <messageIssuer> tags are not the only thing which is missing. Additionally, the cipher suites, compression algorithms, point formats, and supported curves are missing. This is no coincidence. A big change in TLS-Attacker 2.x is the separation of the WorkflowTrace from the parameter configuration and the context. To explain how this works I have to talk about how the new TLS-Attacker version creates messages. Per default, the WorkflowTrace does not contain the actual contents of the messages. But let us step into TLS-Attackers point of view. For example, what should TLS-Attacker do with the following WorkflowTrace:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Usually, the RSAClientKeyExchange message is constructed with the public key from the received certificate message. But in this WorkflowTrace, we did not receive a certificate message yet. So what public key are we supposed to use? The previous version had "some" key hardcoded. The new version does not have these default values hardcoded but allows you as the user to define the default values for missing values, or how our own messages should be created. For this purpose, we introduced the new concept of Configs. A Config is a file/class which you can provide to TLS-Attacker in addition to a WorkflowTrace, to define how TLS-Attacker should behave, and how TLS-Attacker should create its messages (even in the absence of needed parameters). For this purpose, TLS-Attacker has a default Config, with all the known hardcoded values. It is basically a long list of possible parameters and configuration options. We chose sane values for most things, but you might have other ideas on how to do things. You can execute a WorkflowTrace with a specific config. The provided Config will then overwrite all existing default values with your specified values. If you do not specify a certain value, the default value will be used. I will get back to how Configs work, once we played a little bit with TLS-Attacker.
TLS-Attacker ships with a few example applications (found in the "apps/" folder after you built the project). While TLS-Attacker 1.x was mostly a standalone tool, we currently see TLS-Attacker more as a library which we can use by our more sophisticated projects. The current example applications are:
TLS-Client (A TLS-Client to execute WorkflowTraces with)
TLS-Server (A TLS-Server to execute WorkflowTraces with)
Attacks (We'll talk about this in another blog post)
TLS-Forensics (We'll talk about this in another blog post)
TLS-Mitm (We'll talk about this in another blog post)
TraceTool (We'll talk about this in another blog post)
TLS-Client
The TLS-Client is a simple TLS-Client. Per default, it executes a handshake for the default selected cipher suite (RSA). The only mandatory parameter is the server you want to connect to (-connect).
The most trivial command you can start it with is:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Note: The example tool does not like "https://" or other protocol information. Just provide a hostname and port
Depending on the host you chose your output might look like this:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
So what is going on here? Let's start with the first execution. As I already mentioned. TLS-Attacker constructs the default WorkflowTrace based on the default selected cipher suite. When you run the client, the WorkflowExecutor (part of TLS-Attacker which is responsible for the execution of a WorkflowTrace) will try to execute the handshake. For this purpose, it will first start the TCP connection. This is what you see here:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
After that, it will execute the actions specified in the default WorkflowTrace. The default WorkflowTrace looks something like this:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is basically what you see in the console output. The first action which gets executed is the SendAction with the ClientHello.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Then, we expect to receive messages. Since we want to be an RSA handshake, we do not expect a ServerKeyExchange message, but only want a ServerHello, Certificate and a ServerHelloDone message.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
and finally, we want to receive a ChangeCipherSpec and Finished Message:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In the first execution, these steps all seem to have worked. But why did they fail in the second execution? The reason is that our default Config does not only allow specify RSA cipher suites but creates ClientHello messages which also contain elliptic curve cipher suites. Depending on the server you are testing with, the server will either select and RSA cipher suite, or an elliptic curve one. This means, that the WorkflowTrace will not executeAsPlanned. The server will send an additional ECDHEServerKeyExchange. If we would look at the details of the ServerHello message we would also see that an (ephemeral) elliptic curve cipher suite is selected:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Since our WorkflowTrace is configured to send an RSAClientKeyExchange message next, it will just do that:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Note: ClientKeyExchangeMessage all have the same type field, but are implemented inside of TLS-Attacker as different messages
Since this RSAClientKeyExchange does not make a lot of sense for the server, it rejects this message with a DECODE_ERROR alert:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If we would change the Config of TLS-Attacker, we could change the way our ClientHello is constructed. If we specify only RSA cipher suites, the server has no choice but to select an RSA one (or immediately terminate the connection). We added command line flags for the most common Config changes. Let's try to change the default cipher suite to TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As you can see, we now executed a complete ephemeral elliptic curve handshake. This is, because the -cipher flag changed the <defaultSelectedCiphersuite> parameter (among others) in the Config. Based on this parameter the default WorkflowTrace is constructed. If you want, you can specify multiple cipher suites at once, by seperating them with a comma.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We can do the same change by supplying TLS-Attacker with a custom Config via XML. To this we need to create a new file (I will name it config.xml) like this:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
You can then load the Config with the -config flag:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For a complete reference of the supported Config options, you can check out the default_config.xml. Most Config options should be self-explanatory, for others, you might want to check where and how they are used in the code (sorry).
Now let's try to execute an arbitrary WorkflowTrace. To do this, we need to store our WorkflowTrace in a file and load it with the -workflow_input parameter. I just created the following WorkflowTrace:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As you can see I just send a ServerHello message instead of a ClientHello message at the beginning of the handshake. This should obviously never happen but let's see how the tested server reacts to this. We can execute the workflow with the following command:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The server (correctly) responded with an UNEXPECTED_MESSAGE alert. Great!
Output parameters & Modifications
You are now familiar with the most basic concepts of TLS-Attacker, so let's dive into other things TLS-Attacker can do for you. As a TLS-Attacker user, you are sometimes interested in the actual values which are used during a WorkflowTrace execution. For this purpose, we introduced the -workflow_output flag. With this parameter, you can ask TLS-Attacker to store the executed WorkflowTrace with all its values in a file. Let's try to execute our last created WorkflowTrace, and store the output WorkflowTrace in the file out.xml:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As you can see, although the input WorkflowTrace was very short, the output trace is quite noisy. TLS-Attacker will display all its intermediate values and modification points (this is where the modifiable variable concept becomes interesting). You can also execute the output workflow again.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Note that at this point there is a common misunderstanding: TLS-Attacker will reset the WorkflowTrace before it executes it again. This means, it will delete all intermediate values you see in the WorkflowTrace and recompute them dynamically. This means that if you change a value within <originalValue> tags, your changes will just be ignored. If you want to influence the values TLS-Attacker uses, you either have to manipulate the Config (as already shown) or apply modifications to TLS-Attackers ModifiableVariables. The concept of ModifiableVariables is mostly unchanged to the previous version, but we will show you how to do this real quick anyway.
So let us imagine we want to manipulate a value in the WorkflowTrace using a ModifiableVariable via XML. First, we have to select a field which we want to manipulate. I will choose the protocol version field in the ServerHello message we sent. In the WorkflowTrace this looked like this:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For historical reasons, 0x0303 means TLS 1.2. 0x0300 was SSL 3. When they introduced TLS 1.0 they chose 0x0301 and since then they just upgraded the minor version.
In order to manipulate this ModifiableVariable, we first need to know its type. In some cases it is currently non-trivial to determine the exact type, this is mostly undocumented (sorry). If you don't know the exact type of a field you currently have to look at the code. The following types and modifications are defined:
As a rule of thumb: If the value is only up to 1 byte of length we use a ModifiableByte. If the value is up to 4 bytes of length, but the values are used as a normal number (for example in length fields) it is a ModifiableInteger. Fields which are used as a number which are bigger than 4 bytes (for example a modulus) is usually a ModifiableBigInteger. Most other types are encoded as ModifiableByteArrays. The other types are very rare (we are currently working on making this whole process more transparent). Once you have found your type you have to select a modification to apply to it. For manual analysis, the most common modifications are the XOR modification and the explicit value modification. However, during fuzzing other modifications might be useful as well. Often times you just want to flip a bit and see how the server responds, or you want to directly overwrite a value. In this example, we want to overwrite a value. Let us force TLS-Attacker to send the version 0x3A3A. To do this I consult the ModifiableVariableREADME.md for the exact syntax. Since <protocolVersion> is a ModifiableByteArray I search in the ByteArray section.
I find the following snippet:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If I now want to change the value to 0x3A3A I modify my WorkflowTrace like this:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
With Wireshark you can now observe that the protocol version got actually changed. You would also see the change if you would specify a -workflow_output or if you start the TLS-Client with the -debug flag.
More Actions
As I already hinted, TLS-Attacker has more actions to offer than just a basic Send- and ReceiveAction (50+ in total). The most useful, and easiest to understand actions are now introduced:
ActivateEncryptionAction
This action does basically what the CCS message does. It activates the currently "negotiated" parameters. If necessary values are missing in the context of the connection, they are drawn from the Config.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This action does the opposite. If the encryption was active, we now send unencrypted again.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Prints the last application data message either sent or received.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Prints the secrets (RSA) from the current connection. This includes the nonces, cipher suite, public key, modulus, premaster secret, master secret and verify data.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Resets the message digest. This is usually done if you want to perform a renegotiation.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Closes and reopens the connection. This can be useful if you want to analyze session resumption or similar things which involve more than one handshake.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Send a ClientKeyExchange message, and always chooses the correct one (depending on the current connection state). This is useful if you just don't care about the actual cipher suite and just want the handshake done.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
(Maybe) sends a ServerKeyExchange message. This depends on the currently selected cipher suite. If the cipher suite requires the transmission of a ServerKeyExchange message, then a ServerKeyExchange message will be sent, otherwise, nothing is done. This is useful if you just don't care about the actual cipher suite and just want the handshake done.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This lets TLS-Attacker sleep for a specified amount of time (in ms).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If TLS-Attacker helps you to find a bug in a TLS implementation, please acknowledge our tool(s). If you want to learn more about TLS, Juraj and I are also giving a Training about TLS at Ruhrsec (27.05.2019).
This post is about PKCE [RFC7636], a protection mechanism for OAuth and OpenIDConnect designed for public clients to detect the authorization code interception attack.
At the beginning of our research, we wrongly believed that PKCE protects mobile and native apps from the so called „App Impersonation" attacks. Considering our ideas and after a short discussion with the authors of the PKCE specification, we found out that PKCE does not address this issue.
In other words, the protection of PKCE can be bypassed on public clients (mobile and native apps) by using a maliciously acting app.
OAuth Code Flow
In Figure 1, we briefly introduce how the OAuth flow works on mobile apps and show show the reason why we do need PKCE. In our example the user has two apps installed on the mobile phone: an Honest App and an Evil App. We assume that the Evil App is able to register the same handler as the Honest App and thus intercept messages sent to the Honest App. If you are more interested in this issue, you can find more information here [1].
Figure 1: An example of the "authorization code interception" attack on mobile devices.
Step 1: A user starts the Honest App and initiates the authentication via OpenID Connect or the authorization via OAuth. Consequentially, the Honest App generates an Auth Request containing the OpenID Connect/OAuth parameters: client_id, state, redirect_uri, scope, authorization_grant, nonce, ….
Step 2: The Browser is called and the Auth Request is sent to the Authorization Server (usually Facebook, Google, …).
The Honest App could use a Web View browser. However, the current specification clearly advice to use the operating system's default browser and avoid the usage of Web Views [2]. In addition, Google does not allow the usage of Web View browser since August 2016 [3].
Step 3: We asume that the user is authenticated and he authorizes the access to the requested resources. As a result, the Auth Response containing the code is sent back to the browser.
Step 4: Now, the browser calls the Honest App registered handler. However, the Evil App is registered on this handler too and receives the code.
Step 5: The Evil App sends the stolen code to the Authorization Server and receives the corresponding access_token in step 6. Now, the Evil App can access the authorized ressources.
Optionally, in step 5 the App can authenticate on the Authorization Server via client_id, client_secret. Since, Apps are public clients they do not have any protection mechanisms regarding the storage of this information. Thus, an attacker can easy get this information and add it to the Evil App.
Proof Key for Code Exchange - PKCE (RFC 7636)
Now, let's see how PKCE does prevent the attack. The basic idea of PKCE is to bind the Auth Request in Step 1 to the code redemption in Step 5. In other words, only the app generated the Auth Request is able to redeem the generated code.
Figure 2: PKCE - RFC 7636
Step 1: The Auth Request is generated as previosly described. Additionally, two parameters are added:
The Honest App generates a random string called code_verifier
The Honest App computes the code_challenge=SHA-256(code_verifier)
The Honest App specifies the challenge_method=SHA256
Step 2: The Authorization Server receives the Auth Request and binds the code to the received code_challenge and challenge_method.
Later in Step 5, the Authorzation Server expects to receive the code_verifier. By comparing the SHA-256(code_verifier) value with the recieved code_challenge, the Authorization Server verifies that the sender of the Auth Request ist the same as the sender of the code.
Step 3-4: The code leaks again to the Evil App.
Step 5: Now, Evil App must send the code_verifier together with the code. Unfortunatelly, the App does not have it and is not able to compute it. Thus, it cannot redeem the code.
PKCE Bypass via App Impersonation
Again, PKCE binds the Auth Request to the coderedemption.
The question rises, if an Evil App can build its own Auth Request with its own code_verifier, code_challenge and challenge_method.The short answer is – yes, it can.
Figure 3: Bypassing PKCE via the App Impersonation attack
Step 1: The Evil App generates an Auth Request. The Auth Request contains the client_id and redirect_uri of the Honest App. Thus, the User and the Authorization Server cannot recognize that the Evil App initiates this request.
Step 2-4: These steps do not deviate from the previous description in Figure 2.
Step 5: In Step 5 the Evil App sends the code_verifier used for the computation of the code_challenge. Thus, the stolen code can be successfully redeemed and the Evil App receives the access_token and id_token.
OAuth 2.0 for Native Apps
The attack cannot be prevented by PKCE. However, the IETF working group is currently working on a Draft describing recommendations for using OAuth 2.0 for native apps.
Hacktronian Installation Termux users must install Python and Git first: pkg install git python Then enter these commands: You can watch the full installation tutorial here:
That's It... If You Like This Repo. Please Share This With Your Friends. And Don't Forget To Follow The Author At Twitter, Instagram, Github & SUBSCRIBE His YouTube Channel!!!
Posts
