Hack Yourself First (Module 4 — Internal Implementation Disclosure)

Happy New Year! It’s officially 2021 🍾🥳🎉

I had a delightful(but cold) new year’s walk with my sister at St James Park this morning. We managed to see so many beautiful birds and chubby squirrels.

St James Park Squirrel — Source: Reddit

As the new year commences, I am determined and motivated to learn! Today’s module is focused on Internal Implementation Disclosure.

Module 4: Internal Implementation Disclosure

How an attacker builds a website risk profile

Almost like a bank robber trying to understand how to enter in a bank (reconnaissance)

  • Points of untrusted data entry
  • Sanitisation practices implemented
  • Frameworks/libraries and version used (e.g using NIST (National Vulnerability Database) → CVE databases)
CVE search for wordpress vulnerabilities — Source: Pluralsight Hack Yourself First
  • Structure of the website
  • HTML source
  • Internal error messages bubbling up to browser?
  • Web server logs
  • Sufficient access controls on diagnostic data?

Server response header disclosure

  • Finding out more about the framework/libraries and version used
  • DevTools → Network Tab → inspect the response headers of a request
Response Headers revealing non-HTTP spec custom headers — Source: Pluralsight Hack Yourself First
  • We might want to hide this as it doesn’t add any real value to end-users to expose information that reveals the type of technology the web is running on
The response reveals exactly what server the website is running on — Source: Pluralsight Hack Yourself First
  • Making the information more generic makes it more difficult for an attacker to find out what technology is being used

Locating at-risk websites

  • Search for the technology with the specific version number to find risks and vulnerabilities involved
  • Shodan → find websites that might be vulnerable to a certain risk due to version of the technology used

HTTP fingerprinting of servers

  • Even when the response headers are hidden, we can still use HTTP fingerprinting to try and identify particular attributes of a website to find out what might be running underneath
  • Less explicit but still possible to be done
  • Use Fiddler to look at response headers:
    - Is the order of the Date + Server headers the same (comparing different sites)?
    - Change HTTP version from HTTP/1.1 to HTTP/x.1 to see how the server responds → are the error messages same or different for a variety of websites?
400 error shown on www.wsco.com — Source: Pluralsight Hack Yourself First
Same 400 error but displayed differently for hackyourselffirst.troyhunt.com — Source: Pluralsight Hack Yourself First
Same 400 error but again, displayed differently for nginx server — Source: Pluralsight Hack Yourself First

Important to remember:

  • Turn off HTTP headers which disclose your internal frameworks
  • Make sure that server x powered and any non-HTTP spec custom headers (aka. Headers starting with “X-“) are turned off and not disclosing internal implementations
  • Fingerprinting can still allow the attacker to narrow down the server that the website is actually running on

Disclosure via robots.txt

  • Implements the robots exclusion standard → provides guidance to web crawlers about index-able content
  • The robots.txt allows the attacker to find out what the developer doesn’t want anyone to know about
The robots.txt file reveals that the images, scripts, and secret/admin paths are set to disallow — Source: Pluralsight Hack Yourself First
  • Security through obscurity is bad

The risks in an HTML source:
-
Viewing the page source of what’s in the robots.txt file
- Comments in HTML sources that leak sensitive information

- Missing access controls makes it even easier for attackers to access sensitive data
- JavaScript frameworks often have vulnerabilities that attackers can discover from viewing the HTML source

Comments in HTML source code reveals sensitive information — Source: Pluralsight Hack Yourself First

Internal error message leakage

Yellow screen of death — Source: Pluralsight Hack Yourself First
  • Unhandled exceptions in code can be goldmines for an attacker
  • The attacker might be able to see:
    - Lines of code from the error message
    - Where the source code is located
    - Any SQL queries that can lead to SQL Injection attacks
    - The sequence of how an error might have occurred and where it occurs
    - Version information
  • Error handling is very important in order for sensitive information to not be leaked
  • If there is an error, the path should not change in order to hide the fact that an unhandled exception has occurred to keep that information away from an attacker

Lack of access controls on diagnostic data

  • For Microsoft frameworks, there is ELMAH (Error Log Modules And Handlers) → When an exception is raised and not properly handled, it will log that information so the developer can view this later on
Example of an ELMAH — Source: Pluralsight Hack Yourself First
  • Looking into the “Detail” part of an error log, allows us to see a lot of sensitive data
  • Searching for error logs is incredibly easy thanks to search engines
Source: Pluralsight Hack Yourself First
A high amount of results for error logs — Source: Pluralsight Hack Yourself First
A high amount of results for config files— Source: Pluralsight Hack Yourself First
  • Sufficient access controls for error logs and diagnostic information is crucial

Summary

  • Keep information on frameworks and server versions private
  • Don’t rely on obfuscation of frameworks and server headers
  • Be conscious of what you’re inadvertently disclosing
  • Internal exceptions should never bubble up to end-users
  • Internal logs must have proper access controls and their exposure can be absolutely catastrophic

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