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.
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)
- 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
- 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
- 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?
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
- 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
Internal error message leakage
- 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
- 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
- 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
