Dealing with low hanging fruit

I've written before about preparing for a penetration test and the need to deal with any low hanging fruit.  In this post I'm going to describe some quick (and not so quick) fixes that can help reduce risk.  As I mentioned before, you don't want to pay a penetration tester (ethical hacker) to tell you about these things - you want to fix them in advance.

Old accounts

Simultaneously the easiest and most difficult thing to do.  On the one hand it should be really easy to get rid of accounts.  An employee leaves so you delete their account - simple.  The reality is that often accounts get left behind as managers may need access for a period or, worse, ICT just don't get told an employee has left the organisation.  As organisations get bigger the problem gets worse.

Ideally you want your account creation and deprovisioning processes linked to the human resources (HR) system so accounts are created and removed automatically.  Services like Okta and OneLogin can help here by allowing you to create workflows to handle this process - not available to all budgets though.

To do this manually it's worth doing the following:

• Run a report on last logon dates.  For any accounts that last logged on more than a year ago disable them
• After a few months, to account for long term sickness and maternity, obtain permission to delete the account from the relevant manager or HR
• Update account creation procedures to be more auditable
• Look for supplier and third party accounts.  Disable and remove once it's confirmed they're no longer needed (e.g. when a contract ends)
• Review accounts regularly

Account memberships

Ensuring appropriate access permissions is crucial to keeping your system secure.  Regularly review privileged groups, which in a Windows Active Directory domain includes Domain Admins, Enterprise Admins, Schema Admins (should be empty unless you're actively making schema changes) and the domain's builtin Administrators group.  The worst case I found was that every authenticated user was a member of Administrators, essentially making them administrators of the domain.  I explained to that company that they had significant issues.

Password hygeine

Passwords aren't going away any time soon, and sadly nor is the combination of season + year (Summer2018).  Encouraging good password hygiene is essential and the best way is through user education.  Unfortunately the IT industry, including me, spent years telling users that passwords had to be complicated to guess (and thus hard to remember) so it'll be a while before we can move people to the newer way of thinking.

Three random words of four characters (or more) each will make a long password that's easy to remember.  The longer the password the better it is, roughly.

Non expiring passwords

Our current vulnerability scanning tool has a check for non-expiring passwords on accounts but you can also check with a PowerShell script to return a list of accounts with "password does not expire" ticked.  Ideally you only want to see service accounts set to not expire - their mitigating factor is that their password should be long.

If you're looking to reduce your risk score in a tool like Rapid7's InsightVM it's worth remembering that each domain account set to not expire will be logged against each domain controller.  Fixing the problem once will drop the score a number of times.

Default passwords

I recommend putting a clause in your password policy that states default passwords, those present on the device or application at install time, should not be used.  The advantage of a policy is that senior management have approved it and that means staff (hopefully) take notice.  Default usernames and passwords (like admin:admin, cisco:cisco, admin:<blank>, admin:password etc.) pose a real threat to your environment because applications and hardware are easily available to both the inquisitive and the malicious attacker.

Two key examples spring to my mind.  First there was a printer that allowed you to download previous print jobs as a PDF once you'd logged in.  With the password left as the default I was able to download a significant quantity of sensitive, personal data.  Very much unnecessary.

The second issue was arguably more serious and related to an uninterruptable power supply (UPS) attached to a datacentre.  By logging in with default credentials it was possible to shut the whole datacentre down and place the organisation firmly in disaster recovery and business continuity territory.  Again this was easy to avoid.

Once you've got a relevant clause in your organisation's password policy it's important to ensure any vendors and contractors working with you are aware of the requirement.

Web servers

IIS default page

When you add the Internet Information Services (IIS) role to a Windows server it comes with a handy default page to confirm to you the web server is working.  This is fairly common practice (Apache HTTPD does the same, for example) but there's no need for the pages to be in place once the testing is done.

Rapid7's Insight vulnerability scanning tool gives the presence of this page a risk score of 591.  That's a fairly arbitrary figure out of context but I'm trying to demonstrate that this simply fixed problem carries a reasonable amount of weight (a fully patched Windows server can easily have a score of less than 2,000 "risk points").  By telling the attacker what you're running you make their job easier, so let's sort that out.

If you're not using the IIS Default Web Site, having opted to place your content in another "site", then you can stop this demo page by right clicking Default Web Site, choosing manage and then stop.  That will mean the page won't be served.

Alternatively you can delete the files (not a bad idea anyway) from the server.  Generally the default files can be found at C:\inetpub\wwwroot and their name will depend on the version of IIS.  Current versions use iisstart.htm and iisstart.png but there's been a few over the years.  You'll easily be able to identify the files in that directory though - they look like what you see in your browser if you browse to the site.

X-Powered-By headers

Sticking with IIS for a moment, out of the box IIS will send the X-Powered-By header with a value of ASP.NET.  This gives away further details about your configuration but does nothing to help the browser or visitors to your site.  I encourage you to look at Troy Hunt's excellent blog post about HTTP headers where he gives a lot more guidance on this.  To remove this header from IIS:

1. Open the IIS management console (Start > Run > inetmgr > OK)
2. Click on the site you want to change
3. Open the HTTP Response Headers section
4. Right click on X-Powered-By and then click remove

Troy gives instructions on how to remove a number of other headers too, including Server and X-ASPNet-Version.

Firewalling

I've explained the purpose of a firewall before but it's surprising how often the firewall that's built into the Operating System is turned off.  Sometimes this is because it was turned off for troubleshooting and the administrator forgot to turn it back on.  Other times it's because someone was too lazy to configure it collectly.

Using the built in firewall can really reduce your attack surface.  For example, imagine I have a health monitoring agent on my server whose job it is to communicate the system status to the central health monitoring server.  Every so often the central health server asks the agent how things are and the agent responds accordingly.  There's no reason for every device on the network to be able to communicate with the agent, only the central server.  To that end it's a good idea to configure the local firewall to restrict inbound connections to only be permitted from the central server.

By restricting access in this way you not only reduce the likelihood of a successful exploit (the connection will be denied) but your testers (or attackers) may not know a particular service is listening in the first place.  When it comes to reading the penetration tester's report this is very handy - less to read and less to be marked down on.  Nonetheless, you'll still need to keep the server's software (e.g. the agent) patched and up to date - hiding your vulnerabilities won't keep you safe forever.

File shares

Audit your servers for file shares, paying attention to what is shared, with whom, and consider if the share can be restricted further.  Remember that file access auditing is not enabled by default on many operating systems and that once a file has been copied you probably won't know.  Someone can then exfiltrate that data without your knowledge.

File shares often get opened as a temporary measure to accomplish a particular task, then they get left behind.  If the share is no longer needed take a moment to remove it and possibly its data too.  Passwords may be left in scripts in file shares giving an attacker a way in.

Use HTTPS

Despite being 2020 HTTPS is still not on everybody's radar.  I've spoken to three vendors in the last year who have advised that HTTPS isn't something they do.  One told our ICT team that we had to set it up for them.  Another charged for the work as a billable extra and the third simply cannot do it.  In each case there's very sensitive data involved.

Even for sites where there's little personal data it's worth enabling HTTPS.  Organisations such as Let's Encrypt can provide free certificates, as do Cloudflare, so this really should be a solved problem.  Before an external audit, take some time to review sites for your organisation and get HTTPS implemented.

Conclusion

I've no doubt that I'm preaching to the converted given some of my readers, however, for those that this is new: "welcome to the club".  You've now got some quick fixes to help you increase your security provision and reduce your vulnerability to attack.

Banner image, fruit by Almeidah, on Openclipart.org