Burp Suite For Macos
Burp Suite Professional Key. Burp Suite is an integrated platform for performing web application security testing. It is not a point-and-click tool, it is designed to be used by testers in manual mode to support the testing process. With a little effort, anyone can start using key Burp features to test the security of their applications. There are many alternatives to Burp Suite for Mac if you are looking to replace it. The most popular Mac alternative is mitmproxy, which is both free and Open Source.If that doesn't suit you, our users have ranked 19 alternatives to Burp Suite and eight of them are available for Mac so hopefully you can find a suitable replacement.
Introduction:
Burp suite is an intercepting proxy that can intercept requests from client side & responses from the server side. The ability to intercept allows hackers to manipulate requests/responses to look for & exploit vulnerabilities. It is mainly used by experienced security engineers & pen testers as it presents a single interface with various integrated toolsets.
Burp Suite has multiple capabilities. The professional & Enterprise version of the tool have scanner feature that scans a target web application / API to discover vulnerabilities. This is possible only if we are able to intercept the requests first.
Burp Suite Professional also as an extender tab where in we can add a set of extensions that can look for additional security violations or work slightly in a different way to discover some default vulnerability checks applied by the scanner
Getting Burp Suite :
Burp Suite is available in following types
Burp Suite Community
Burp Suite Professional
Burp Suite Enterprise
The community version is available for everyone & free to use. It can be downloaded from the portswigger official website. The Professional & Enterprise versions are available as a commercial use. If you are someone that didn’t try this tool & if your organization hasn’t requested for a trial license before then you can use this chance to request for trial version valid for 30 days with full features(note: this option is available while publishing this content, may change in future). Assume we are going to request for trial license for valid reasons to make best use of it.
Installing Burp Suite:
Burp Suite can be run on any operating system (OS) if the OS supports the specific java version installed as it is a java application & available in a JAR format to launch & use the tool.
We are using Burp Suite Pro v2020.2.1 & it requires minimum Java version 8 to install / run the tool.
Configuring Burp Suite:
Before we can use Burp suite, we need to configure it with our client so we can intercept requests/responses. Follow the sections 1,2,3 below to configure
Section 1, Configure browser with Burp Suite
open Burp —> proxy —> Options—> Add Proxy Listener
By Default burp suite runs on 8080 port. so the default proxy listener is localhost:8080. We need to set this proxy listener in our browser to intercept requests/responses.
open Firefox —> Preferences —> Network settings —> set Manual proxy configuration to localhost:8080
Section 2, Install Burp root CA certificate
This is required to intercept encrypted traffic.
open Burp —> proxy —> Options—> click import/export CA certificate to export the certificate
After the certificate is exported, now open Firefox —> Preferences —> certificates —> Import certificate
Section 3, set Upstream proxy server
In some corporate networks, there is a proxy configured to connect to internet. To access external sites hosted outside the corporate network or to connect to internet we are required to set the upstream proxy.
to set this, open Burp —> User Options —> Add Upstream Proxy Servers
Burp Suite Integrated toolsets:
Repeater : It is used to replay the base request with altered/manipulated request parameters & observe the response from server. This feature helps to confirm the existence of a vulnerability as we can replay & observe responses. It becomes a bit easier to check for access control violations with the use of repeater as we will need to alter specific id’s or resources of a user with another user
Intruder : It is used to target specific request parameters with a list of custom payloads & observe the responses for each of the payloads/manipulated requests.
Sequencer : It is used to check for the strength of the tokens such as session cookies , forgot password tokens or user invited tokens etc.,
Decoder : It is used to decode/encode data in to specific formats such as base64, url encode/decode, hex format etc.,
Comparer : It is used to compare two requests or responses to check for any variations.
Burp HotKeys:
we can use key board short cuts to traverse between various sections/tabs of the tools. It can configured from user options —> Misc —> Hot keys
on MacOs, some hot key examples are
command+shift+R —> Repeater tab
command+shift+T —> Target tab
command+shift+I —> Intruder tab
Spidering / Crawling :
Crawl is an interesting feature as the tool automatically crawls a target website to discover all traversable links, parameters, resources etc.,It is recommended to set the scope of the spider to ensure only target site is crawled & consider setting specific crawl parameters to ensure the scanner isn’t overloaded with unrealistic crawl settings
for example : Unique location discovered : should be a realistic/appropriate value
Passive scanning:
During this phase the scanner doesn’t actual send any malicious requests on its own to the server, it simply observes all intercepted requests / responses & reports if there are any missing security header settings , secure cookie settings , sensitive tokens in GET request , other passive checks etc.,
some of the passive checks are applied as soon as the requests/responses are intercepted. To do a passive scan to cover all passive rules, we need to add the target site to scope & right click the target site to choose, passively scan this host
Active Scanning:
During this phase the scanner sends malicious requests on its own to the server from the initial or baseline intercepted requests , observes the responses from the server for each of this malicious requests to identify & report vulnerabilities such as SQL Injection, XSS , etc.,
To do an active scan, we need to add the target site to scope & right click the target site to choose, Actively scan this host
Adding Extensions:
Burp suite has an menu option, Extender. Most of the extensions are either developed in python, java or Ruby. For this reason, we need to set the environment settings under Options section of Extender Tab. Generally to set the java environment settings, we need to point to the location of the java JRE bin installed path, like wise for python, we need to set the location of Jythonstandalone.jar file present in our machine.
After the environment settings are completed, we can add extensions in two different ways. The easiest way to add an extension is go to BApp Store under the Extender tab & choose a extension from the list that you may want to add & use as per your need. Just click install from the right pane to install the extension. To successfully install a extension, the relevant environment setting is a must. Some extensions are available for community version but some are available for only professional version of the tool.
Burp Suite BAppStore has a limited set of extensions, there are lot more extensions available from other resources, such as github, we recommend that you use only extensions that are required & to avoid overloads. Some extensions will fall part of the default scanner to look for vulnerabilities but some will need to be used in a manual way.
Disable Extensions :
There are couple of ways to disable extensions, to disable all extensions, we can tick the checkbox “Disable extensions” while launching burp.
To disable a specific extension, go to Extender tab —> Extensions —> uncheck a specific extension that you do not wish to use.
Project Options:
Configurations & settings apply to the current project hacking session
(Macros, session Handling rules, cookie jar etc.,)
when following redirections, understand the predefined types, JavaScript-Driven is not enabled by default.
Project options —> HTTP —> Redirections
some useful project options
Project Options—> Misc —> Scheduled Tasks, Burp Collaborator Server
Project Options —> sessions —> Session Handling Rules / Cookie Jar / Macros
User Options:
Configurations & settings that apply to Burp suite
(proxy listener,upstream proxy, hotkeys etc.,)
some useful user options:
User Options —> Display —-> User Interface / HTTP Message Display
User Options —> Misc —> Proxy Interception
Platform Authentication
Saving Options for Future Use
Engagement Tools — Search / Find Comments / Find Scripts / Find References / Analyse Target / Simulate Manual Testing
Search : Used to search for specific strings or to search & look for sensitive information disclosure such as API keys, credentials etc.,
Find Comments : When used shows all comments left over by developers in target site resources
Find References: When used shows the reference of the target site in various places of the intercepted requests / responses
Analyze Target: when used displays, number of dynamic urls, static urls,parameters, unique parameter names
Simulate Manual Testing: Let’s you take a break while the tool automatically sends requests to the target site to avoid session timeouts.
Intercepting HTTP proxies such as Burp Suite or mitmproxy are extremely helpful tools - not just for pentesting and security research but also for development, testing and exploring APIs. I actually find myself using Burp more for debugging and learning than for actual pentesting nowadays. It can be extremely helpful to look “under the hood” at actual HTTP requests being made to make sense of complex APIs or to test that one of my scripts or tools is working correctly.
The general use case for a tool like Burp or mitmproxy is to configure a browser to communicate through it, and there are plenty of write-ups and tutorials on how to configure Firefox, Chrome, etc to talk to Burp Suite and to trust the Burp self-signed Certificate Authority.
However, I often want/need to inspect traffic that comes from other tools besides browsers - most notably command line tools. A lot of CLI tools for popular services are just making HTTP requests, and being able to inspect and/or modify this traffic is really valuable. If a CLI tool is not working as expected and the error messages are unhelpful, the problem can become obvious as soon as you look at the actual HTTP requests and responses it’s making/receiving.
I have used these techniques to inspect popular CLI tools like the Azure CLI (az) and Zeit’s now utility. In the past, I have even proxied the CLI tools provided by a commercial security tool we used and learned about some undocumented APIs and behaviors that were not in their documentation. With this knowledge, I was able to automate certain things that were not possible through their vanilla CLI or the published API docs.
In this post, I want to show various techniques for configuring different CLI tools written in different languages to proxy their HTTP(S) traffic through Burp Suite - even if the tools themselves don’t offer easy proxy settings. In general there are two things we must configure:
- Make the CLI proxy traffic to Burp
- Make the CLI trust the Burp CA (or ignore trust)
The second step is often more difficult, but never impossible :)
In most of these examples, I have Burp Suite listening on localhost:8080 and am running the CLI tools from the same machine. If Burp is running on a different host or interface, you should be able to just replace localhost with the IP of Burp.
For the first example, I’ll show how to proxy the old standbys curl and wget. Both tools can easily be configured to point to a proxy and are “proxy aware”. They pick up their proxy settings from environment variables:
http_proxyhttps_proxy
You can either export the variables first, or run them inline with the command:
We will see the curl and wget requests in Burp:
That works great because it’s just HTTP. What about HTTPS? If you try to run it out of the box, you will get failures:
curl does not trust the certificate that Burp is presenting. However the error message is quite helpful. Most CLI tools will fallback to the operating system when deciding what certificates to trust. So we have two main options:
- Disable trust verification
- Configure our operating system to trust the Burp CA
The first option is easiest. For curl use -k or for wget use --no-check-certificate:
And you will see the HTTPS traffic in Burp.
Trusting the Proxy Certificate at the OS Level
For option 2, we have to export the Burp CA from within Burp. We can download the Burp Certificate in DER format to ~/certs. We’ll also convert it to PEM:
Note: if you are using mitmproxy, the certs are already in ~/.mitmproxy
Installing and trusting the certificate is very OS dependent.
Burp Suite For Mac Os 11
Note: be aware of what this is doing. You are weakening the security of your OS. Consider the risk.
Mac OSX
On a Mac, just double click the downloaded DER file and OSX will prompt you to add the cert to the keychain. If you select “System” it will be trusted by all users on the machine. Then after importing it, you must trust it. Search the keychain for “PortSwigger” and open up the certificate. Under “Trust” select “Always Trust” for SSL:
Windows
On Windows, double-click on the DER file and select “Install Certificate”. Select the “Trusted Root Certification Authorities” certificate store to install and trust the Burp CA.
Linux
For most distros, trusted certificates are in /usr/share/ca-certificates. Copy the burpca.crt file to /usr/share/ca-certificates and then run:
With the Burp CA trusted by your OS, you no longer have to use -k with curl or --no-check-certificates with wget and you will see HTTPS traffic in Burp:
While I would obviously prefer a Python or npm package or a Go binary - a lot of CLI tools I deal with are JARs, including all the CLI utilities for my company’s SAST solution. Now some of these utilities have proxy support out of the box that can be configured with command line options, however some of them don’t and I need to force the JAR to talk to my proxy.
A few years go, a security scanner my company was using at the time had a horribly documented API, and the only approved way to interact with it using API tokens was through their Java JAR CLI tool. We needed to scale our automation and wanted to write a Python package for talking with the API, so I used this exact technique to proxy their JAR and figure out how to authenticate with API tokens and what APIs we needed to hit.
I won’t pick on that security vendor here, so instead I will demo on a random Atlassian CLI tool I found for talking with Jira. For example, I can use this CLI to query the Jira version running on a random cloud hosted instance:
Let’s figure out how it’s doing that so I can recreate the API calls manually. Unfortunately, the CLI tool doesn’t have any options for specifying a proxy. Thankfully, it’s actually pretty straightforward to force the JVM to use a proxy through some properties when launching Java:
http.proxyHosthttp.proxyPorthttps.proxyHosthttps.proxyPorthttp.nonProxyHosts
To proxy a JAR through Burpsuite, we need to set the first 4 options to our proxy, and ensure the last one is blank. This will force Java to proxy all hosts through Burp. We do that by adding these as command line flags to the java command before we specify the JAR:
But we now get an SSL error!
Burp Suite For Mac Os Pro
Even though I have the Burp certificate trusted in my OS keychain, Java actually uses its own keystore. So we need to add the Burp certificate there also.
Adding certificates to Java Keystore
The default keystore is located in $JAVA_HOME/lib/security/cacerts. If the $JAVA_HOME environment variable isn’t set for you, you can also quickly find it by using java:
To add certificates to Java’s keystore, we utilize Java’s keytool utility, which is included at $JAVA_HOME/bin/keytool. To import our Burp certificate, we must import the PEM formatted file to the trusted CA certs:
This will prompt you for the keystore password. By default the value is changeit. Then specify “yes” to trust the certificate:
Now with the Burp certificate trusted by Java, we can run the same command and see the HTTP traffic in Burp:
There it is! It makes a simple REST call to /rest/api/latest/serverinfo. Yes, this is publicly documented and I could have figured it out by RTFM but that’s not as fun :)
Moving along, this next example will focus on Python CLIs. Lately I’ve been using this a lot as I’ve doing quite a bit of Azure automation at work and wanted to peak under the hood of the official az CLI. In this example though, I’ve already installed the Azure CLI using homebrew (brew install azurecli) and done an az login.
I can view my available resource groups with:
Let’s intercept this request to figure out the call(s) it’s making.
Fortunately, Python will try to honor the “normal” proxy environment variables. However trying to set that results in…the typical SSL error:
Since I have the Burp CA trusted by my OS, Python is not using it.
Adding Certificates to Python
Python’s CA handling is a little strange. Most Python CLI’s probably use the requests library, which uses it’s own CA bundle, and then will also look at the CA bundle included with another library called certifi, which uses Mozilla’s bundle. To trust our CA, we can add it to the Mozilla bundle included with certifi.
It’s important to note that each Python interpreter get’s its own - so if you are using virtual environments you need to make sure you run the following commands with the correct Python.
First, I want to verify how az calls Python and which version it is using:
So az is calling its own embedded Python interpreter that was installed with homebrew at /usr/local/Cellar/azure-cli/2.0.74/libexec/bin/python.
First, to identify where the certificates are loaded from we import certifi and run certifi.where()
That cacert.pem file is a list of all trusted CAs in PEM format. To add our Burp CA, we can just append the PEM to the file:
With the Burp CA added to the Mozilla bundle, we can now proxy the az command!
And now any other az command we want to run we can start viewing/tampering with. This has been a lifesaver for me to see “real world” examples of Azure’s API I can recreate in my automation scripts.
In this example, I wanted to be able to proxy the traffic that comes from the now NPM package for interacting with https://zeit.co/. I have already installed the tool with
After logging in, I can view my current deployments with:
Unfortunately, it appears that Node does not honor the proxy environment variables. Running:
returns the data as expected, with nothing appearing in Burp. Unfortunately, Node does not support a global proxy setting, and there has been long discussions about it. But that doesn’t mean we can’t force one.
First, let’s see what the now command is calling:
The now utility is one large, ugly, minified JS file located in Node’s bin directory with a node shebang. We can also run the same now command by calling that file with node directly:
While node does not have global proxy support, this is an awesome project called global-agent which will set up a configurable proxy in a Node project by simply importing it. To use it, we use npm to install it into our current directory.
Note: you must be on Node 12 or higher
The module uses the GLOBAL_AGENT_HTTP_PROXY environment variable, so we must export that first. Now from within that directory (because it’s where node_modules is) we can inject the new requirement into the now package:
Node forces the now client to import global-agent/bootstrap which runs automatically. Now the now command will proxy requests to the URL set in the environment variable.
Now to add the SSL certificate for Burp.
Adding Certificates to Node
This is actually quite a bit easier than Python. The Node command understands an environment variable called NODE_EXTRA_CA_CERTS. To load our Burp certificate as trusted, we just export that environment variable as well and point it to the PEM file from Burp:
And it now works! We can view the traffic from the now package in Burp:
It is becoming increasingly popular for developers to distribute CLIs as static Go binaries. This is, of course, awesome because Go is awesome. It’s also awesome because proxying Go is actually very easy since out of the box every Go program understands the environment variables http_proxy and https_proxy.
For this example, I’ll proxy Github’s hub utility. With hub downloaded and installed, in a Git repo I can check on my current CI status like this:
Since hub is a Go binary, I simply need to set the environment variable for the proxy:
And we get an SSL error.
Trusting Certificates with Go
Unfortunately, Go doesn’t have a convenient place to trust an additional CA certificate. For each platform, Go looks in OS dependent places for trusted CAs. You can view these in the source code:
This is where you have to add the Burp certificate to your system keychain (as outlined above). After that, Go will pick it up and you can proxy Go binaries just fine:
Hopefully you find this as helpful as I do. Whether you are pentesting an app or CLI, or just developing and wanting to debug - intercepting HTTP traffic is really valuable. I love when I can apply some of my pentesting skills to increase development velocity and be creative.
Python, Node and Go encompass the vast majority of CLI tools I use, but of course there are others. In a future post, I’ll cover how to force an invisible proxy onto a process that is not proxy aware at all through layer 3 redirection.
Let me know if you have any questions or other ideas I missed!
-ropnop