Diary of a pen tester
David Beesley, director, Network Defence
Foreign hackers, weak passwords, backdoors and buffer overflows
— just another day at the office for Network Defence's penetration
testers. Here's a look at sample pages from the head tester's diary
— and what companies can learn from the results.
Monday 2nd
We tested the website of a manufacturing company, and found the
web server was installed on the company's internal network. Our
tests revealed that the firewall rule was to permit any inbound
traffic to connect to this server. Exposure of the Microsoft directory
services ports to the internet allowed us to connect to this server,
from there a weak password gave us access to a domain administrator
account. A couple of simple policy errors made it possible for a
hacker to gain control of the network.
The lesson here is to check your firewall rule-sets carefully and
regularly. One mistake can allow an attacker in.
Wednesday 11th
We were at a financial services company today. In 2004 the company's
website was hit by the widespread Sasser worm, which causes buffer
overruns and shuts down unpatched machines that run Windows XP and
2000. It can also let attackers upload code, or modify data. Of
course, Sasser is widely known, so most companies have updated anti-virus
software and have patched their systems, which is why we were doing
a pen test.
We identified some points on the network that had not been patched.
This is potentially serious for a financial services company, as
vulnerabilities could be exploited to obtain user IDs, passwords
and personal information.
The moral is: keep your anti-virus software up-to-date and install
the latest patches as they become available.
Thursday 19th
We went to a major chain of car dealers today. One of its IIS 5.0
servers had been hacked by a foreign spamming group. They intended
to use the server as a spam "proxy", thus concealing their
identity. This demanded quick action.
We pulled the server from the internet so that we could identify
and remove the rogue code, and we installed new firewall software
onto the machine.
Friday 27th
We tested the websites of a large property management company. This
customer is one of our regulars, for whom we conduct regular pen
tests. On the sites we had tested regularly, we did not find anything
apart from a couple of low-risk vulnerabilities that had appeared
since the previous test.
However, this week we tested one of its newly-developed e-commerce
websites. We found it to be susceptible to multiple SQL insertion
attacks that would have allowed us to take almost full control of
the system. To minimise the risk we immediately explained how this
was possible and gave guidance for remedial action.
Tuesday 7th
We did an external penetration test for a social housing company
today. We discovered that the firewall permits remote administration,
and that the administrator account was still using the default password.
This caused some red faces in the company's IT department —
the default password had been left on by the firewall installer
who had told the IT manager to change it; this had never happened.
This also highlights just how frequently weak passwords crop up.
We always recommend that passwords should include a mix of letters
and numbers, upper and lower case and should be as random as possible.
Also, administrator access from outside the firewall should be switched
off; in this case, security is more important than convenience.
Tuesday 14th
Our test at a college of further education revealed the mail server
to be an open mail relay. This is an obvious target for spammers;
they will use it to send millions of spam messages worldwide.
As well as creating a nuisance for the recipients, the college’s
bandwidth would be compromised and the college would have its email
domain blacklisted by antispam agents. It is easy to test mail set-ups
for open relays, so do it before someone else does.
Thursday 23rd
A test of a company's web server revealed that the firewall was
well set-up and the server had up-to-date patches. So far, so good.
However, we could gain access to the password-protected part of
the site using an SQL injection trick; this allowed us to log in
without knowing either username or password. This was possible because
the ASP code did not provide sufficient input validation on theforms.
You should always check your application coding, because smart
hackers can compromise even a well-configured firewall and a patched
server.
|
