Almost every network with an Internet presence will expose some web servers and a mail server.
Most vulnerabilities in a web server now stem from installed technologies that run on them, such as PHP, Tomcat and ASP.NET. As they are much more complex technologies and are user configurable, the scope to introduce a vulnerability is higher. Attacks have recently been developed that target external communications made by the web server, which are starting to be used by attackers and testing companies alike.
Mail Servers themselves are rarely vulnerable to a remotely exploitable condition that will grant access to them, with the last major widely used issue affecting Sendmail back in 2003. However, mail servers ultimately deliver emails and attachments to internal users, so are the most common way to bypass firewalls, IDS / IPS, WAF devices and a whole heap of other corporate protection tools.
We’ve identified some common threats and emerging attacks against these technologies to look out for:
It is important that along with the Web Servers, any installed technologies are also patched in a timely manner. There may be a concern around patching web servers due to the risk of performance issues; however, this risk should be weighed up against the risk of a web server being compromised and an attacker having access to any data that may be stored on the associated database.
Updates for web servers are also not that common, so it should be easy for administrators to test and patch them. Web technologies, such as PHP, ASP.NET etc are often overlooked as part of a patching cycle, usually, because they just aren’t thought about or because an external development company was used to design the web app and no one knows if patching will break anything. It is extremely common to find versions of ASP.NET and PHP dating back over 10 years during our tests and, as they are popular targets for vulnerability researchers, there is a myriad of exploits available for them; in fact, there are entire exploit frameworks designed to only attack web technologies.
Web Technologies / CMS
As web servers are generally hard to attack and useful exploits are few and far between, it is much easier for an attacker to target what is installed on the web server instead. Common technologies such as PHP, Tomcat, Java, ASP.NET,
WordPress, Drupal, ColdFusion etc, all have their own fundamental flaws and can easily be misconfigured in such a way to allow an attacker access to the host.
Common issues are default credentials, guessable credentials, unpatched vulnerabilities, incorrect access controls, exposed management login portals, unverified 3rd party plugins and web application vulnerabilities. Each of these technologies have their own flaws, for example, WordPress is hugely popular target for an attacker and a quick search of the Common Vulnerabilities and Exposures
(CVE) web site for WordPress returns over 5,300 entries. The reason this is such as popular target is that it supports the installation of 3rd party plugins that have not been verified by anyone, so even if your actual WordPress installation is fully up-to-date, any plugins you have enabled could be either accidentally vulnerable to attack or even deliberately coded to be vulnerable and released for publication.
Quite often web servers, and more importantly web technologies, fall through the gap when considering who will manage and maintain them. Servers, workstations, laptops, firewalls etc. normally always fall under the remit of the IT department (who will know what is present on their network and can add them to patching cycles, maintenance upgrades etc.), but it’s not unusual for IT staff to assume someone else looks after a web application and the software that makes it run; for example is it the database administrator, an internal developer who codes the application or an external development company who provided the code? Does marketing look after the corporate website and do IT want to touch it in case it breaks? It is for these management reasons that the most common avenue of attack we find during our External Penetration Tests is via installed web technologies on web servers; conversely, it is also one of the hardest areas to manage and to decide who manages due to the risks and consequences of a key web application going offline.
A relatively new method of attack against a web server and web application is to force a connection to be sent from inside the network to a host under the control of an attacker. This attack relies on functionality being externally accessible to make the web server, or the host the web server is installed on, initiate a connection to a resource that can be controlled by an attacker, so they are able to control the traffic that is sent back. For example, when using a web application and registering a new account with an email address, it is common for a DNS lookup to be made from the web server that verifies if the Domain Name specified in the email is valid. If an attacker controls the DNS server the query will be sent to, then they can control the data sent back to the web server in the DNS response; therefore, if there is an exploitable condition in the DNS server it could allow an attacker access to the host.
A recently disclosed DNS vulnerability that almost all Linux hosts are vulnerable to could, and is, being used for an attack such as this http://openwall.com/lists/osssecurity/2017/06/27/8. At the time of writing this guide, these types of attacks are starting to mature as they become more widely understood and it won’t be long before public exploits are made available for a variety of software that uses this type of behaviour. For this reason, it is important to fully understand what a web application will request from external hosts, such as DNS records etc. to ensure you are aware of all connections that it will try to make.
As with Web Servers, almost every network will expose at least one mail server to allow emails to be sent into and out of an organisation:
Practically, it’s easy to assume that a mail server needs unfiltered access to the internet to allow anyone to send email to it; how can you set up access restrictions if you don’t know who is going to need to send you an email? However, many companies use external mail filtering services to check all emails for spam, viruses, malware etc. and to then send the mail on to internal users. If this is in place for your network then it means you know exactly where all emails will come from, as it will always be from your mail-filtering provider. The DNS records for your domain name will have to point to your filtering provider to ensure the emails are sent here first.
For example, the MX records for mti.com state that all mail will be sent to mailcontrol.com:
mti.com MX preference = 10, mail exchanger = cust8436-2.in.mailcontrol.com
mti.com MX preference = 5, mail exchanger = cust8436-1.in.mailcontrol.com
This allows for Access Control Lists to be set on the firewall to only permit connections to the mail server to come from mailcontrol.com IP addresses, thereby, removing the mail server from the Internet but without affecting any email delivery.
Typically SMTP based mail, such as Exchange will use port TCP:25 so this is where the ACL can be set. If you use another protocol such as POP or IMAP then the ports will be different.
Client Side / Phishing Attacks
Client-Side Attacks also known as Phishing Attacks often use email as the means of delivery when attacking an organisation. This type of attack is so dangerous and prevalent in today’s world that we have produced a separate document outlining them and how to help protect against them, so this guide will include a brief overview only.
A Client-Side attack will usually involve sending an email to users that have a malicious attachment or instructs a user to visit a certain URL. The email will normally be constructed to look like a genuine email from a trusted source, such as from HR outlining a new service to view payslips etc. or an employee discount scheme. They will either entice a user to visit a URL that loads up exploit code in their web browser and tries to attack their workstation or will ask them to submit their credentials into a login form to gain access to the site (is 2FA enabled on your VPN?).
If successful, the attack will invariably grant access to the workstation that the user is on and will then attempt to carry out more sophisticated attacks against the Operating System or other hosts on the network – like the recent WannaCry ransomware attack that used a Windows vulnerability to propagate around networks.
Part of the defence against these attacks is to have effective mail filtering in place that robustly scans all attachments and prevents access to any deemed malicious but also examines any URL’s in an email and then examines the web page linked to for malicious content. A lot of technologies are emerging that will do this type of scanning. This also needs to be backed up by regular user awareness training and education sessions to ensure users can spot these attacks when they occur.
Penetration Testing for Web & Mail Servers
There are two types of penetration tests that address these threats: External penetration tests and client-side phishing tests.
External tests examine all Internet-facing hosts such as web servers and mail servers, ascertaining the versions of software installed on them to determine if they are vulnerable to any known attacks – and detect any misconfigurations. Mail servers should be tested for common attacks and should also attempt to relay mail inside and outside of an organisation to test if access controls are in place.
The client-side attack is a complex test that works best when spread over several months using multiple different scenarios. Look for a provider that can facilitate this, when our testing teams conduct this test, we often wait until new vulnerabilities are detected in common software, then either develop our own exploit or obtain a commercial one that we can use as part of the test to attempt sending it into the organisation.
These kinds of tests review internal patching cycles, malware / AV defences, mail filtering and a user’s susceptibility to open unsolicited attachments – this is the best way to mimic a real-world attack.
Work with a well-established security testing service provider that has developed intelligent and specifically designed testing scenarios that increase chances of identifying flaws but ‘fly below the radar’. For example, we have found that constructing many different email scenarios and targeting a small number of users at a time gives the test the best chance of getting a useful set of results. Simply sending the same email to 500 users all at once will nearly always arouse suspicion and detract from the value of the test; ultimately giving a very low value on the financial investment made in the test.
Our own testing teams conduct regular online and onsite training exercises to educate users about this type of attack, helping them recognise when they are being targeted and how to handle email communications in a safe manner.