Tor

You can say that Tor is an open-source, anonymizing, encrypted, volunteer-operated proxy network. It distributes your traffic over several layers (or relays) so that no single point can link you with your destination. Basically, you go through these relays before reaching that destination.

This helps you reduce the risk from both simple and more complex network analysis.

For example, installing the Tor browser on your client (Windows) machine will place a Socks5 proxy on it. You can configure it to push all the Internet traffic you want through that proxy – taking the same path.

Packets sent are encrypted and enter the Tor network encrypted; after that, they get bounced from node to node until they reach the exit node, where the packets get decrypted, and you arrive at your final destination – like Facebook. We call this a Tor circuit.

The example above takes the clear web into consideration. To access Tor’s hidden services, you need a .onion URL, a special URL required to access the Tor Darknet. Note that the exit node is not really required in this case, as you’re not leaving the Tor network; you’re going to a server that’s within the network.

This also means that your traffic will stay encrypted (end-to-end). The main idea about Tor here is that no individual relay (node) will know the complete path you’ve taken. In fact, the client negotiates a different set of keys for each hop within the Tor circuit. Thus, no hop can trace these connections as they are passing through.

There’s 10 minutes or so window for circuits (Tor uses the same circuit) where it will use the same circuit, but the later requests will be given a new circuit, keeping people from linking your previous actions to your later ones.

It’s important to note that Tor is not solving all the privacy and anonymity problems! Tor does not cover everything and is not a silver bullet, but it can be an extremely useful tool to help you protect your privacy and anonymity when configured correctly and when used in conjunction with other tools/layers that will keep your privacy and anonymity unscathed.

Tor utilizes the Diffie-Hellman handshake, which is used to establish the session keys (I mentioned above that the client negotiates different keys for each node); Diffie-Hellman basically lets your client negotiate the session keys in such a way that even if the negotiation was listened to by a MiTM (Man in The Middle), they wouldn’t be able to establish what the mutually agreed session key was.

Another thing that Tor uses is something called Perfect Forward Secrecy, which means the session keys are used briefly and later replaced. This means that if one of the nodes were to get compromised, data that already passed through it can’t be decrypted with the private keys because the keys have changed since then.

Tor is both a piece of software and an anonymizing network. A live representation of the Tor network can be seen here. The Tor browser (software) is what lets you access the Tor network.

Most of the Tor relays are to be found in Central Europe. From the link above, you can see the network’s historical development. You might experience more (or less) latency depending on your proximity to the nodes. The Tor network is generally known to not be blazing fast.

The Tor browser itself is a hardened Mozilla Firefox ESR (it has NoScript, HTTPS Everywhere, and Tor proxy browser addons). It can be also run from a removable media (standalone) and is cross-platform – available on Windows, Mac, GNU/Linux.

You can verify and download it from https://www.torproject.org/.

Once installed, and started, you will see a Firefox-like UI, and will be greeted with a welcome message for the first time. I will not cover how you can configure these, for the most part, its almost the same as for your Firefox broswer, so if you’re a Firefox user, you’ll feel at home. I will just share some thoughts below (check the third screenshot); This is more to give you an idea on what approach we need to have here, but the more technical aspects is something I will gradually build up to as we go through the series.

Note the two options from the second screenshot. The New Circuit option will make you go through a different exit node, and will basically present a new IP address but you can still have trackable items in your browser (even though the browser tries to fight that anyway, its still possible), but the New Identity option will restart the browser itself. This is the big difference between the two options, the New Identity will attempt to wipe everything that is contained within the browser and could be linked/used for tracking, which is why it restarts.

For an attempt at anonimity, you want the security settings set at the Safest option, even though it might break some websites. But, if that’s not chosen, deanonymizing is much easier, and it kinda defeats the purpose of using Tor in the first place. You obviously want to restrict 3pp cookies, disable browser plugins (Flash), never record browsing history or website data, and change details that distinguish you from other Tor Browser users.

Resources

https://support.torproject.org/ – Check out the Most Frequently Asked Questions section

https://tor.stackexchange.com/ – A stackoverflaw-like Tor messageboard where you can find answers to your Tor-related questions

https://blog.torproject.org/ – A blog by the Torproject

https://gitlab.torproject.org/tpo/team – This used to be the Tor wiki, a lot of useful information here

https://www.reddit.com/r/tor – Tor subreddit which can be very useful to you

https://2019.www.torproject.org/projects/torbrowser/design/ – If you want to really jump down the rabbit hole that is Tor, this might be the best place to be, as these are basically the design documents for Tor

Conclusion

I hope you liked this article, and that I’ve managed to shed some light on Tor! There’s way more to unpack here, and I hope to gradually help you familiarize yourself with this enormous topic, by building upon what was written in previous articles, so, stay tuned for the next one!

Cover image – taken from https://torflow.uncharted.software/

#tor #tor-circuit #nodes #onion

Introduction

In addition to hosting millions of lines of code, Github contains a ton of secrets hidden in the depths of various repositories. These secrets are the product of developers unknowingly pushing their credentials, server secrets, passwords, etc. to the repository in addition to their code.

These secrets can be found with special Github search queries also called Github Dorks. A good collection of Github dorks is available here: https://github.com/techgaun/github-dorks

Let’s go through a couple examples of these to find secrets.

Dork 1 – filename:sftp-config.json

The file sftp-config.json is created by sublime text editor. Many developers prefer sublime text for remote development. For this purpose, sftp package in sublime comes handy. Sftp can be used with both password and/or key based authentication.

Once you setup the SFTP in sublime, sftp-config.json file is created as following:

This file contains sensitive information such as username, password, and IP address to connect.

So, if we search in github for sftp-config.json, we get several results, one of which is a web-programming project that contains credentials in plain text.

Dork 2 – filename:config.php dbpasswd

It is very common for php applications to hardcode database credentials. Usually the config.php file is used to provide configuration details for a php application which will be used to establish a database connection. So when we use this github dork, we get many results with php projects containing hardcoded credentials.

One example is valueclickbrands project.

Attackers can take advantage of this information disclosure bug to hijack the database completely and deal more damage.

Key Takeaway

Before making any project public, make sure the Github repository as well as previous commit branches does not contain hardcoded credentials and config files.

#github #dorks

For whipping up a quick web app or even creating a production level web API, Flask is arguably one of the top web frameworks according to Python developer survey 2022. Developers love it because it’s lightweight, easy to use, and does not require particular tools or libraries.

One of the many cool Flask features is the interactive debug console in the browser. The interactive debug console can be very useful to quickly test what part of your code is causing issues. But in many cases, developers explicitly enable the debug console and disable the pin protection on those debug consoles.

Thus, one of the consequences is remote command execution on these applications.

For this demonstration, we will be examining two projects that disable the pin protection: (1) Umber, a course management web application and (2) Shrunk, a URL shortener for Rutgers University.

Exploiting Umber

If we look under the environment file of the application, we can see that the application explicitly declares “export WERKZEUG_DEBUG_PIN=off”.

This command disables the pin protection on the debug console

Figure 1: Disabling the pin protection on the debug console

So, when we start the server, the debugger gets activated too.

Figure 2: Debugger is activated with PIN disabled

Now we can access the console web page at http://127.0.0.1:5000/console and execute our code.

Figure 3: Executing code remotely in Umber

Exploiting Shrunk

Another project that explicitly disables the pin protection is Shrunk, an internal project developed at Rutgers University to shorten the URL.

The shrunk server is started with a shell script called start.sh

The shell script explicitly disables the pin and runs the application in the debug mode.

Figure 4: Activating debugger mode disables the pin

So, same as the first example, when we start the server, we get the prompt that the Debugger is active and the Debugger PIN is disabled. These warnings are usually disabled and if deployed in production directly, then it can compromise the application.

Figure 5: Warning that the Debugger PIN is disabled

Figure 6: Executing code remotely in Shrunk

Key Takeaways

• Always check if your application has debugger enabled before deployment.
• Limit the console access to only specific internal IP ranges.
• Make sure that if you need the debugger active, it also has debugger pin enabled.

#NCSAM #exploit #research #vicarius_blog

You probably all know that headers are directives that web applications use to configure the security defense in web browsers.

They are also called seatbelts for web applications. The name describes their usage because they can save you in an emergency and are not difficult to use or time-consuming.

The header topic is vast and can be complex because of it. The best is to be familiar with all of them so you can choose which one to use for your type of web application.

In this article, I will focus on one type of header called the Nonce header. Nonce means “number used once”! This CSP additional layer of security could protect your web application from some attacks such as data injection attacks, CSRF, XSS, etc.

*As you probably know, if you are familiar with developing a web application, it is very easy to implement headers. You can apply them on the web server or in your code. They are often just one line of code to add or check a box to configure the web server.

What is CSP?

The nonce header is used as an extra added level of security for the Content Security Policy (CSP) security header. I will get back to it in the next section. I will just summarize the function of CSP:

CSP is a list of sources for content (such as scripts, images, frames, etc.) the web site is using which are outside of the domain. CSP usage would stop vulnerable web application calling out and running the secondary part of the attack.

The main win of CSP is to disallow inline styles and inline scripts. For example, CSP is used by adding this line of code, which would block everything for the static application. If you want to prevent not calling any content from anywhere, you can implement CSP like this:

Content-Security-Policy: default-src 'self'; block-all-mixed-content;

If you want to check out the list of additional layers you can use with CSP, check out this site.

Of course, there is plenty of documentation regarding CSP on the internet if you want to dig deeper into it.

What is the Nonce header?

So, let’s get back to the script-nonce header.

Nonce is a string of characters. It is used one single time to prove that a specific script is the one you mean to call. Using this setting means you require the nonce to run the script.

When and how is Nonce used?

The unsafe-inline directive should be avoided because it allows all inline scripts and styles. Nonce is used to avoid using mentioned directive because with nonce, we can allow only specific elements, such as specific inline script or style elements.

The nonce should be a secured random string, and you should not reuse it somewhere else in the application (it should be unique).

This directive is CSP level 2. This means that the support for nonce has existed since 2015 in Chrome and Firefox, Safari 10+, or Edge 15+. You can check out more about level 2 on this site.

If your script, which you want to allow, is static, you could also use CSP hash. The difference between these two is that hash is whitelisting precise script block, and nonce will allow the whitelisting of the entire script block no matter what is in there.

If we want to summarize the difference and make up your mind easily about what to use: nonce, hash, or default CSP, check out this table from TroyHunt site:

How to use Nonce?

To use nonce, we would provide the script tag a nonce attribute. Also, we would need to add nonce to our script-src directive. These two values of nonce attribute need to match.

<script type="text/javascript" nonce="55EemGb1xKptoIGTP4Nd"> </script>

and

Content-Security-Policy: default-src 'self'; script-src 'nonce-55EemGb1xKptoIGTP4Nd'

To get the nonce, you can generate a random base64-encoded string using a cryptographically secure random number generator on the site CyberChef or the classic site base64. The string should be at least 128 bits of data to be secure enough (32 hex characters or 24 base64 characters).

Very important to know is that nonces should be generated differently each time the page loads (single-time usage). So, if you are using node.js you can use randomBytes method and then convert it to toString base64. You can check out more about the mentioned method on this site.

When you create a nonce, the content is hidden. This means if the attackers try to get the attribute nonce, they will get the empty string! The nonce value can be just accessed by the nonce property of the script: script.nonce.

If you want to give trust to all scripts loaded by the root script when adding nonce (or maybe hash), you will also add ‘strict-dynamic’ directive.

The CSP would look like this if we are using nonce:

Content-Security-Policy: script-src 'strict-dynamic' 'nonce-55EemGb1xKptoIGTP4Nd'

Or like this, if we are using hash:

Content-Security-Policy: script-src 'strict-dynamic' ' sha256-0fr9ylGr2R2tsWMhq4lfEQc'

*Just to note that using a hash is CSP level 2 also. Level 2 specification also allows sha384 and sha512. Check out this site for more info!

Make sure that script tags with nonce attribute don’t have any untrusted variables within them!

Cool security header tool

There is one cool site where you can check out all the headers used in the web application. In the mentioned security headers site, you can just put the domain of your web application in the input field and click the scan button. After scanning, you will get a security report summary, all information about raw headers, and warnings about the used headers. You will also have new info about upcoming headers and see some additional information (more description of concepts used).

In the picture above, you can see one section about the headers which target application is using. You can also check out headers in the DevTools, but I like this tool because it is easy to use.

Browser compatibility on Oct 1, 2022

On Developer Mozilla official site you can find the latest information on browser compatibility for nonce attribute:

Conclusion

As I mentioned, Nonces are a very complex topic, and the implementation of this feature has changed over time. If you are planning to use it, you will need to be in touch with the latest information about updates. OWASP is always providing the latest info regarding CSP and you can find more information on their site.

There are so many cool security headers out there. We will for sure get back to some of them.

Cover photo by Brandi Redd

#Security_headers #CSP #Nonce

We are finally prepared to use the ZAP tool to perform some security testing in this part of the ZAP series.

If you are new to this topic, please check out the rest of the previous articles.

We will use DVWA (Damn Vulnerable Web Application) for this part of the series.

DVWA is a PHP/MySQL web application that is used to help security professionals to learn and test using security tools while staying clear of legal implications. It possesses many common vulnerabilities, so you don’t need to waste your time to set up the application from scratch.

To follow along with the testing, you will need to install DVWA. There is a great guide on installing it in a Linux environment (you should use the one we set up in the first part of the series (Kali machine). You can find it on this site.

We will divide this part of the series to cover a few topics:

· Setting up Dynamic SSL certificates

· Automated Scan – How to use Ajax Spider?

· Recommendations for Add-ons

· HUNT extensions for OWASP ZAP

Setting up Dynamic SSL certificates

We want to start testing the application, but the application possesses an SSL certificate, and we get the following error:

If you want to read more about Dynamic SSL certificates, check out this site.

Without importing ZAP Certificates in the browser, ZAP cannot handle simultaneous Web request forwarding and intercepting. So, we will need to set it up!

First, go to the menu tab Tools -> Options -> Dynamic SSL Certificates, generate and save the certificate file. 

Now we need to go to the browser we will use for the testing, I am using Brave, and we need to configure its settings. Go to the Privacy and Security section and use CTRL + F and look for “cert”, when you find the Manage certificates section, choose the Authorities tab and click on import and choose the certificate we saved from ZAP (when browsing to the cert file if you don’t see it, choose All files from dropdown).

The following window will appear, choose to trust the certificate (first option as it is in the picture).

That is it; you are ready to proceed!

How to use Ajax Spider?

By Owasp: The Ajax Spider is an add-on that integrates in ZAP a crawler of AJAX rich sites called Crawljax. You can use it in conjunction with the traditional spider for better results. It uses your web browser and proxy.

For more information about the add-on, you can check out OWASPs official site.

In the Marketplace, we choose Ajax Spider to install it first.

There are a few ways to do an automated scan, first and quickest is going to Quick start and choosing Automated Scan and then choosing the URL of the application you want to scan and clicking on the Attack button.

*In this step, you can also choose if you want to use traditional spider and/or Ajax. If the application you are testing is written using AJAX, you will definitely want to mark Ajax spider. Still, you can also mark the traditional one so you can cover the testing completely. The easiest way to use Ajax Spider is with HTMLUnit. If you don’t see it in the dropdown you would need to install it. Here is the place you can check out if you want to install it in Ubuntu.

After the scan (if you are using DVWA application) you will see the list of vulnerabilities in the results, such as in the following picture:

Recommendations for add-ons

From the toolbar choose Manage Add-ons (Add-ons Marketplace). You will see Installed and Marketplace tabs. We would like to add new add-ons, so we choose Marketplace.

This is the recommended list of add-ons:

• Directory List v2.3 (Provides files with directory names to be used with Forced Browse or Fuzzer add-on.)

• Directory List v2.3 LC (Provides files with lower case directory names to be used with Forced Browse or Fuzzer add-on.)

• FuzzDBFiles (Provides the FuzzDB files which can be used with the ZAP fuzzer. Some files which cause anti-virus software to flag or remove files have been split off into the FuzzDB Offensive add-on available via the ZAP Marketplace.)

• FuzzDBOffensive (FuzzDB web backdoors and attack files which can be used with the ZAP fuzzer or for manual penetration testing.)

• Python Scripting (The Python Scripting add-on allows you to integrate Python scripts in ZAP. When you create a new script, you will be given the option to use Python, as well as the option to choose from various Python templates.)

• JSON View (Provides a Request/Response panel view that shows JSON bodies nicely formatted.)

• JWT Support (Detect JWT requests and scan them)

• ViewState (ASP/JSF ViewState Decoder and Editor)

• Community Scripts (Useful ZAP scripts written by the ZAP community)

If you would need some other add-ons check out the list of add-ons on the ZAP official site and Github ZAP extensions. On the ZAP official site list, there is no information for new add-on JWT support; you can get more information about it on this site.

If you choose to download extension from Github you can also download add-ons and import them manually by clicking the File option in the toolbar and choosing Load Add-on File…” menu option (CTRL + L).

HUNT extensions for OWASP ZAP

There is one interesting extension you can check out, it is called Bugcrowd HUNT extensions, and it can be found on this site.

To use this extension, first, you need to be sure that you installed from Market Add-ons: Python Scripting and Community Scripts. Then, in ZAP options, choose Passive Scanner and mark “Only scan messages in scope” (enabled).

In the ZAP tree, click on the plus icon and add Scripts, new window will open, then expand Passive Rules and right-click on Hunt.py script and choose to Enable Scripts.

When you scan the application next time, this script will be included. The application will passively be scanned for SQLi, LFI, RFI, Path Traversal, OS Command Injection, Insecure Direct Object Reference, Logic & Debug Parameters, and Server-Side Template Injection.

You can finally start playing around and start scanning applications! Scan only your stuff or apps like DVWA so you don’t get into trouble!

Conclusion

We finally got to the stage where we started using ZAP. We have scratched the surface of its possibilities, but we will continue with ZAPs features in the next part of the series.

Hang tight!

#ZAP #AjaxSpider #DynamicSSL #HUNT

Cover photo by Markus Winkler