I was recently part of a team that carried out a network and web application penetration test on the external network of a large UK company. Out of the many web servers providing online consumer services and online payments, one fairly innocuous server storing web log information turned out to be a real threat, writes Bil Bragg CISSP, a penetration tester, ISO 27001 auditor and director at Dionach.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The initial port scans revealed that the targets were a mixture of routers, firewalls and web servers, with additional services such as mail, VPN and remote administration.
The public Windows web servers had various cross-site scripting vulnerabilities and plenty of useful system information disclosure, but nothing that allowed direct access to sensitive data. There was, however, a password-protected Apache web server that stored web logs, which did have a series of issues.
The log server was protected by a login page, however this was vulnerable to exploitation using a form of SQL injection. Specifically, the login could be bypassed by injecting the MD5 hash of a valid password. In this case, a very weak password was found relating to the name of the company, which allowed access to the log server administration area. The admin area revealed that there were a number of users, some of which probably didn't need access anymore and some of which used very weak passwords.
|Five Top Tips on securing the network|
1. Know what you are exposing: identify all Internet facing hosts and their services.
2. Remove public access to administration ports such as SSH: restrict access from specific IP addresses if required.
3. Segregate groups of hosts into multiple DMZs, depending on the type of host and the information sensitivity.
4. Review user access rights on individual servers on a regular basis.
5. Secure batch scripts and avoid using passwords in them.
With access to the admin area, a further page vulnerable to SQL injection was discovered. As the application used "root" to connect to the MySQL database, this could be exploited to write a PHP script file to a web server directory. This also required the Apache user to have write privileges on this directory. This PHP script allowed operating system commands to be run and so allowed limited access to the server. The Linux server was found to have a number of local privilege escalation vulnerabilities, including one on the kernel. This was exploited to get full "root" control of the server. With full control, it was then possible to connect to the server remotely using SSH.
Using SSH tunnelling, the log server was discovered to be on the same DMZ (demilitarized zone) as the web servers providing online consumer services. Tunnelling the Windows SMB ports revealed that a few of the servers had some anonymous Windows shared folders. Two of these shared folders contained Windows batch files with administrator passwords. Additionally, some of the servers had local Windows accounts with very weak passwords.
|Five holes you probably have in your network|
| 1. Cross site-scripting on your public websites.
2. Unpatched operating system and application software with vulnerabilities.
3. Multiple remote access services such as Outlook Web Access, SSH and Remote Desktop, rather than one single service such as a VPN.
4. Direct access to the Internet from the DMZ on multiple ports.
5. Weak, guessable passwords for old service accounts.
Shortly thereafter, we had full control of all the DMZ servers that provided online consumer services, and access to the personal information of visitors. The servers accessed a mainframe on the internal network; the scope of the test was limited to the DMZ and so access was not attempted, however it is likely that we would have got access to the mainframe and possibly the internal network.
The log server had been identified as having vulnerabilities in a previous penetration test report, as company uses a pool of testing companies. However, the vulnerabilities had not been exploited to demonstrate the potential impact.
To reduce similar risks that you may have, first ensure that you know what assets you are exposing to the internet, even if you consider any of them to be unimportant. If a penetration test or vulnerability scan has identified serious vulnerabilities to lower value assets, consider the wider view if that asset is compromised. It is good practice to segregate servers where possible into different DMZs. If the log server was compromised and it was segregated with a firewall, it may have prevented access to sensitive personal data. A holistic approach such as certification to ISO 27001 would also help identify areas that require improvement.