Hack Yourself First (Module 1 - TLP)

What do we do with ourselves during the time between Christmas and New Year’s? After a lovely relaxing few days of self-care and stuffing my face with lots of delicious food, I wanted to learn a little more about Web Security.

As you may already know, Troy Hunt - creator of “Have I Been Pwned”, Microsoft Regional Director and MVP who travels the world speaking at events and training technology professionals, is one of the most well-known professionals in the Cybersecurity world. In hopes to explore more within the world of Cybersecurity, I decided to take some time to do his course on Pluralsight: Hack Yourself First: How to go on the Cyber-Offense.

Source: NDC Conferences

Introduction

This course aims to:

Source: Pluralsight Hack Yourself First
  • Understand the relative cost of bug fixes
  • Learn how to use Fiddler
  • Explore Response/Requests
  • Decrypt HTTPS traffic with Fiddler
  • Modify raw requests and reconstructing them in order to mount text onto the target website
  • Use Intruder21 for fuzzing of web apps

Module 1: Transport Layer Protection (TLP)

3 objectives of TLP

  1. Authenticity
    Do we know who we’re connecting to?
    How can we guarantee their identity?
  2. Integrity
    Can we trust that our requests aren’t being manipulated?
    Confidence that responses are modified
  3. Confidentiality
    Keeping data private in transit
    Responses sent to our browser is protected from “prying eyes”

Man-in-the-middle attack: When an attacker can sit and observe or modify the content of a private conversation

There are so many points where a man-in-the-middle attack can take place:

  • Starts with a device (PC, tablet, mobile, IoT, etc)
  • In a typical request, that data is sent through as an HTTP request to a WAP (wireless access point) router
  • The router then sends that data out over external infrastructure
  • ISP → Internet service provider which facilitates internet connectivity
  • ISP then sends a request out to all over the world (as the destination server could literally be anywhere)
  • The request then lands on the destination server
  • Then response gets sent back via all these nodes before it reaches the user device

If we have traffic where authenticity, integrity, or confidentiality is important, then we should always send that via an HTTPS connection. Anytime we send via an HTTP connection, we should automatically assume it can be observed by an attacker.

Protecting sensitive data in transit

  • Open Fiddler to observe the traffic and requests made
  • Comparing the registration page on an insecure (HTTP) and a secure site (HTTPS)
  • HTTP shows all sensitive data and was able to inspect the POST request data, but HTTPS doesn’t allow Fiddler to intercept the POST request data
Source: Pluralsight Hack Yourself First

Persisting authentication state via cookies

Source: Pluralsight Hack Yourself First
  • HTTPS is a stateless protocol → Uses unique auth cookies instead
  • Risk of sending cookies over insecure connections
  • Insecure website:
    - Resources tab in the DevTools, then inspect cookies
    - Name: AuthCookie
    -Intercept using Fiddler to inspect AuthCookie
    -Testing that the AuthCookie can be maliciously used even in Incognito mode to hijack the session
  • Secure website:
    -It is crucial to pass the AuthCookies only via HTTPS
    -If we check in Fiddler, only 2 requests can be intercepted by the man in the middle (HTTP requests)

Risk of loading login forms via HTTP

Source: Pluralsight Hack Yourself First
  • Attacker has access to login form
  • Inspect the Network tab in DevTools
  • Using Fiddler as a proxy to mount attacks
  • Modify the “OnBeforeResponse” → after the server has responded but before it makes its way back to the browser
  • Inject the JavaScript keylogger into the page by appending the script to the end of the body and also set the destination variable to the attacker website, and then save
  • Logout, then reload the page and inspect the source code (keylogger should be there)
  • As we type the username + password, the keylogger logs the data to the attacker’s site

Secure website redirects insecure HTTP login page, to HTTPS login page

Examples of security vulnerabilities:
1. www.socialsecurity.gov → Click “Submit a form” on the homepage redirects link to HTTPS, but accessing the form via Google Search leads to it being insecure
2. The Tunisian Internet Agency was blamed for the presence of injected JS that captures usernames and passwords on login pages for Gmail, Yahoo and Facebook in 2011.

Exploiting mixed-mode content

Source: Pluralsight Hack Yourself First
  • Shield icon → Load unauthenticated sources/unsafe script
  • As a security defence mechanism, some browsers will automatically not load the unsafe script, some will warn you with a shield, sometimes it’ll load it anyways
Source: Pluralsight Hack Yourself First
  • If the unsafe script loads, it opens up the user to be vulnerable to a man-in-the-middle attack
  • As a result, the “HTTPS” prefix in the URL will be crossed out in red as a warning sign:
Source: Pluralsight Hack Yourself First

What a malicious attacker might do with unsafe scripts on an insecure website:

  • Fiddler to intercept request — OnBeforeResponse event
  • Overwriting the body and embed the keylogger script and also set the destination variable to the attacker website, and then save
  • Reload page to ensure that keylogger is injected.
  • As we type the username + password, the keylogger logs the data to the attacker’s site (similar to the previous one)

On a secure website, it’s essential to embed the JavaScript prototype file via HTTPS. There are multiple ways of doing this:

  1. Reference the script via the HTTPS scheme and embed it as “https://xyz.com
  2. Protocol Relative URL → starts with “//“ instead of explicitly stating “https://xyz.com”. If the parent page is loaded over “HTTPS”, the protocol will use the same. Likewise for “HTTP”. It is giving the ability to make an “HTTP” request when it doesn’t need to be secure, but automatically switching to “HTTPS” when necessary.
Source: Pluralsight Hack Yourself First

HSTS (HTTP Strict Transport Security) Header

Enforce requests from the browser to only be made over secure connections under certain conditions. It acts as a useful layer of defence.

Problem:
The attacker might be able to just load the CSS using HTTP by removing the “s” from the prefix if it doesn’t redirect to “HTTPS”. This means the attacker might be able to access the AuthCookie.

Solution:
Make a change to the Headers → add “Strict-Transport-Security” and set value to “max-age=1440” (1440 minutes = one day). This means that the browser can no longer issue HTTP requests to this website for the next 1440 minutes. If we attempt to do this, it will just convert it to an HTTPS request.

Source: Pluralsight Hack Yourself First

Issue mentioned:
HSTS isn’t available on all browsers yet (only Chrome and Firefox). But as the course was published in 2013, there has been a lot of improvements since then and now more browsers do support HSTS:

Source: HSTS MDN Web Docs

Update regarding HSTS: This course was published in 2013. Thanks to my friend Paulo for mentioning to me and to this Stack Overflow page for providing the following info:

“As of December 2014, Paul Irish’s blog on protocol-relative URLs says:

2014.12.17: Now that SSL is encouraged for everyone and doesn’t have performance concerns, this technique is now an anti-pattern. If the asset you need is available on SSL, then always use the https:// asset.

Unless you have specific performance concerns (such as the slow mobile network) you should use https:// to protect your users.”

That’s all for Module 1: Transport Layer Protection! In the next module, we’ll be learning more about Cross-Site Scripting (XSS). Follow my blog for updates and please give a few claps if you found this blog post helpful.

Software Engineer • Cybersecurity • Quadrilingual • BBA Luxury Marketing & Intl Business Development