An NGO Web Portal Security Audit 2.0
Wednesday, 15 June 2016
A previous version of this article initially appeared on »House of Hackers« in June 2008, posted by seconded
agent A. Denton of directorate I: intelligence (ICT). Some aspects of it long remained significant for the
organization's sectret day-to-day operations. On these grounds the article could not be declassified and published
before.
In 2008 ED Denton used to work as an apprentice in the field of web engineering and security, when she was asked to assist GD Hollstein in an NGO web portal security audit. A subsequent report, which included a CoA along with a security and QA statement, had to be composed in due time.
Step 1 – System Lookup+Scans: The team first gathered target information, i.e. ISP and location, DNS records, OS and web/app server details. Further everything about the ISP's infrastructure itself, as well as information for later social engineering, was ascertained. To accomplish that, unixoid OSs and programs, i.e the 2007 BackTrack 3 GNU/Linux, next to publicly available database records from several authorities were employed [1]. Of course every such software also required basic knowledge about ISO models, protocols, RFCs, networks and OSs to avoid potential hazards. Eventually the team discovered the targets were Gentoo GNU/Linux systems with kernel v2.4.22, hardened with grsecurity and running services like hardened OpenSSH v4.7, Postfix SMTPd, Apache v2.2.6 Unix with mod_ssl v2.2.6 plus OpenSSL v0.9.8g and PHP v5.2.5; basically no ordinary stand-alone web servers. Therefore one should avoid scans from private or corporate infrastructures to prevent track-downs, note that OSINT is helpful oftentimes, and profit from accessible expert knowledge, like e.g. Mixter's [2].
In 2008 ED Denton used to work as an apprentice in the field of web engineering and security, when she was asked to assist GD Hollstein in an NGO web portal security audit. A subsequent report, which included a CoA along with a security and QA statement, had to be composed in due time.
Step 1 – System Lookup+Scans: The team first gathered target information, i.e. ISP and location, DNS records, OS and web/app server details. Further everything about the ISP's infrastructure itself, as well as information for later social engineering, was ascertained. To accomplish that, unixoid OSs and programs, i.e the 2007 BackTrack 3 GNU/Linux, next to publicly available database records from several authorities were employed [1]. Of course every such software also required basic knowledge about ISO models, protocols, RFCs, networks and OSs to avoid potential hazards. Eventually the team discovered the targets were Gentoo GNU/Linux systems with kernel v2.4.22, hardened with grsecurity and running services like hardened OpenSSH v4.7, Postfix SMTPd, Apache v2.2.6 Unix with mod_ssl v2.2.6 plus OpenSSL v0.9.8g and PHP v5.2.5; basically no ordinary stand-alone web servers. Therefore one should avoid scans from private or corporate infrastructures to prevent track-downs, note that OSINT is helpful oftentimes, and profit from accessible expert knowledge, like e.g. Mixter's [2].
Step 2 – Goolag Scanner: Because its name resounded throughout the land when it appeared in 2007, the team wanted to
evaluate the software in the field
[3].
The Goolag Scanner turned out to be a versatile program to collect information of any given website, as long as it
was well known enough by Google, depending on (accidental) indexation. The basic concept of it was to ask Google for
known insecurities about a given target site. The team queried Google using Goolag Scanner with high delays in
between to ensure Google would not block further requests, which happened fairly often throughout the whole process.
Interestingly, one of the vulnerabilities found seemed to be a documented flaw within the Intelligent Platform
Management Interface (IPMI) of the system hardware. In total Goolag checked for the presence of 1400+ known flaws,
within the target environment. Thus we can say that Goolag Scanner proved to be helpful, although nowadays more
powerful services like SHODAN, Majestic and DWT search are available to investigators.
Step 3 – WebHack Analyzer: The team executed these scans to find out whether the systems had additional known security flaws. Scans for approx. 200+ more sophisticated vulnerabilities took place, which resulted in the retrieval of total system accesses numbers, besides traffic accounting data and internal system monitoring data, like resource usage and system load. Eventually, the already discovered severe flaw within the Intelligent Platform Management Interface (IPMI) was confirmed, which clarified what kind of exploits really worked in that specific case [4]. Inasmuch as the systems were ones from a shared hosting environment the team wanted to know who else was located in reach, to get a better idea of these target systems and their surrounding infrastructure. Finally social engineering tactics were used, and a phone call made, to get the remaining digits needed to attack the systems. Therefore one should not feel secure, because only a few hardened services are visible form the outside, since a single flawed one may lead to complete system compromise.
Step 4 – NTO Web/Insight: The team employed the NTO scanners under WINE on GNU/Linux, which provided insight on the target sites structure, including possible attack vectors [5]. Hence the user authentication mechanism, implemented in insecure PHP, was successfully analyzed. The actual login required a cookie, PHPSESSID, IP checks and an internal account table, with stored hashes and salt to grant access, whose implementation was correct. However the target systems did not engage SSLv3 or TLSv1 secured transfer by default, to provide basic immunity against the revelation of session credentials. Further the team executed an ECMAScript analysis and a thorough markup/HTML check. It then made sure there were no flaws within other (PHP) parts of the wCMS, identifiable through code analysis or by other audit techniques. Surprisingly there were only minor bugs found within the source code. It was also discovered that an SQL database was indeed missing. The data was stored as text/XML for security reasons, like e.g. in toendaCMS, which was why SQL injections silently failed [6]. Attacks via XSS were unfeasible to conduct likewise, due to effective an correct XSS-prevention implemented.
Thus the team concluded its web portal security audit with a report, which asserted that the actual high-level wCMS implementation was sane and secure. Nonetheless it emphasized the importance of social engineering and again drew attention to the severe flaw, found early within the Intelligent Platform Management Interface (IPMI). In addition to that, mandatory authentication and encryption schemes were advised, besides perimeter defense with WAF and IDS/IPS. The team finally recommended to further secure the given hosting environment and to avoid PHP whenever possible, since the interpreter was ever flawed in terms of security, unlike the ones of Perl or Python [7]. Moreover, applications should be sandboxed or otherwise security enhanced with containers, BSD jails, AppArmor, SELinux or TrustedBSD; as should server plus service configurations be hardened. Ultimately the team urged to make security audits an integral and mandatory part of every single development and engineering project, executed by skilled security practitioners [8].
Step 3 – WebHack Analyzer: The team executed these scans to find out whether the systems had additional known security flaws. Scans for approx. 200+ more sophisticated vulnerabilities took place, which resulted in the retrieval of total system accesses numbers, besides traffic accounting data and internal system monitoring data, like resource usage and system load. Eventually, the already discovered severe flaw within the Intelligent Platform Management Interface (IPMI) was confirmed, which clarified what kind of exploits really worked in that specific case [4]. Inasmuch as the systems were ones from a shared hosting environment the team wanted to know who else was located in reach, to get a better idea of these target systems and their surrounding infrastructure. Finally social engineering tactics were used, and a phone call made, to get the remaining digits needed to attack the systems. Therefore one should not feel secure, because only a few hardened services are visible form the outside, since a single flawed one may lead to complete system compromise.
Step 4 – NTO Web/Insight: The team employed the NTO scanners under WINE on GNU/Linux, which provided insight on the target sites structure, including possible attack vectors [5]. Hence the user authentication mechanism, implemented in insecure PHP, was successfully analyzed. The actual login required a cookie, PHPSESSID, IP checks and an internal account table, with stored hashes and salt to grant access, whose implementation was correct. However the target systems did not engage SSLv3 or TLSv1 secured transfer by default, to provide basic immunity against the revelation of session credentials. Further the team executed an ECMAScript analysis and a thorough markup/HTML check. It then made sure there were no flaws within other (PHP) parts of the wCMS, identifiable through code analysis or by other audit techniques. Surprisingly there were only minor bugs found within the source code. It was also discovered that an SQL database was indeed missing. The data was stored as text/XML for security reasons, like e.g. in toendaCMS, which was why SQL injections silently failed [6]. Attacks via XSS were unfeasible to conduct likewise, due to effective an correct XSS-prevention implemented.
Thus the team concluded its web portal security audit with a report, which asserted that the actual high-level wCMS implementation was sane and secure. Nonetheless it emphasized the importance of social engineering and again drew attention to the severe flaw, found early within the Intelligent Platform Management Interface (IPMI). In addition to that, mandatory authentication and encryption schemes were advised, besides perimeter defense with WAF and IDS/IPS. The team finally recommended to further secure the given hosting environment and to avoid PHP whenever possible, since the interpreter was ever flawed in terms of security, unlike the ones of Perl or Python [7]. Moreover, applications should be sandboxed or otherwise security enhanced with containers, BSD jails, AppArmor, SELinux or TrustedBSD; as should server plus service configurations be hardened. Ultimately the team urged to make security audits an integral and mandatory part of every single development and engineering project, executed by skilled security practitioners [8].
References:
- ↟ "Kali Linux | Penetration Testing and Ethical Hacking Linux [..]"↗. Offsec Services Ltd. / J. O’Gorman, I. Frankovic, et al. Retrieved 15 June 2016.
- ↟ "Packet Storm - Files from Mixter"↗. Packet Storm. / The Packet Storm Team, et al. Retrieved 15 June 2016.
- ↟ "PC-WELT - Goolag Scanner - File Download (2015)"↗. IDG Tech Media GmbH. / C. Löbering, et al. Retrieved 15 June 2016.
- ↟ "Rapid7 Community | A Penetration Tester's Guide to IPMI [..]"↗. Rapid7 LLC. / hdmoore, et al. Retrieved 15 June 2016.
- ↟ "Rapid7 | Rapid7 Extends IT Security Data and Analytics [..]"↗. Rapid7 LLC. / C. E. Thomas, T. Giakouminakis, et al. Retrieved 15 June 2016.
- ↟ "GitHub - ahadb/ flat-file-cms: A list of strictly flat-file cms [..]"↗. GitHub, Inc. / ahadb (A. Bokhari). Retrieved 15 June 2016.
- ↟ "fuzzy notepad - PHP: a fractal of bad design"↗. eev.ee / Eevee (Alexis aka. "Lexy" Munroe). Retrieved 15 June 2016.
- ↟ "OWASP - OWASP Guide Project"↗. OWASP (NPO). / M. Curphey, B. Chesney, et al. Retrieved 15 June 2016.
Last Updated (Wednesday, 15 March 2017)
