Insider Attack – a case study Jonny Tyers @JonnyTyers www ...

Insider Attack – a case study

Jonny Tyers@JonnyTyers

www.jonnytyers.co.uk

About me

Software Networks

Cyber Projects & Sales

Inside Attack Case Study

● a real attack– Poorly defended

● took place in 2002– though vulnerable, good security design can

effectively defend outdated technology!

● discuss the security design/principles which would have prevented this attack

Setting the scene● small academic

institution– roughly 350 students,

150 staff

● attackers examine defenses– no IT staff knowledge

until after attack

– attackers are legitimate users

A brief aside – Windows 98

A brief aside – Windows 98

● Built on Windows 95, which is runs atop of MS-DOS– system boots into MS-DOS and then loads Windows shell

● FAT filesystem only (i.e. no filesystem security)● Unlike Windows NT, not a network operating system by design

– no inbuilt security – no user accounts, auditing, or access control

– all processes are equal (with exception of user-space/kernel-space programs)

● MS abandoned Win9x when WinXP was released – basing it on Windows NT, [belatedly] recognising the need for a security model in its desktop OS

● still would have been possible to carry out this attack were the desktops running Windows NT

Attack team Objectives1. gain control over key network functons (file server,

authentication controls)– i.e. administrator account access

2. establish access to the organisation’s WAN connection such that it can be used undetected

3. maintain 1 and 2 for as long as possible

Phases of attack

Reconnaisance Scanning Gainaccess

Maintainaccess

Covertracks

Step 1 - ReconnaisanceObservations

● Windows 98 + apps + AV– Identical configs on all workstations

– Group Policy lockdown

● ~ 500 users / 100-150 workstations– all users access IT/internet through workstations, no BYOD/wifi

● Most workstations in IT office– IT office: open 8am-10pm, busy hours 9am-6pm, IT staff in from 8am to

~6pm

● Only 1 or 2 server machines visible in IT office● Physical security

– low for workstations

– server in IT staff office, and under lock and key when staff are out

Step 1 - ReconnaisanceSocial engineering

● As legitimate users, attackers build a rapport with the IT staff

● On-site proxy server filters & logs web requests● “a couple of main servers” - one of these runs Windows

NT4 Server– The NT server “does all the important stuff”

– (attackers assume this means DHCP, authentication, DNS, WINS)

– All file shares and storage comes from storage mounted on the NT4 server

● IT staff “don’t understand” the web proxy and manage it via a web interface only

Reconnaisance - Network layout

Internet

Server room / IT office

NT4 server

Server room / IT staff office

NT4 server

proxyserver

IT office – 100x workstations

Step 2 - Scanning

Group Policy Workarounds

Network tools

Scanning - Network layout

Internet


NT4 server


NT4 server

proxyserver


192.168.1.x

192.168.1.1

192.168.1.2

DHCP, DNS,

WIN

S

Scanning - Network layout

Internet


NT4 server


NT4 server

proxyserver


192.168.1.x

192.168.1.1

192.168.1.2

DHCP, DNS,

WIN

S

Weakest point = workstation

Workstation analysis

● Workstation in separate office● Unused Friday pm

– Disconnected network

– Connected laptop direct

– Booted off floppy disk and enabled Safe Mode booting

– Booted workstation in Safe Mode (bypassing login) and copied entire contents of drive C

– Loaded image into VM in a lab environment to analyse

Office


HDSBatch scripts which

replace entire registry with known-good

backup before Windows boots.

FileProtectWindows driver which

permits/blocks filesystem access depending on a whitelist configured

in the registry.

DiskClearProgram loaded at Windows

startup which deletes all files not in its whitelist (in the registry). Whitelist includes

Windows files and admin-authorised applications.

Anti-virusSignature-based detect/removal of well-known

threats found in the wild,scans on filesystem

operations.

AuditorLoaded at Windowsstartup. Captures

high-level audit events and sends to central

server.

HDS


FileProtect

DiskClearAnti-virus.

Found whitelisted directories in FP’s

config which attackers could write the keylogger to.

DC’s registry config changed to include the new

keylogger files to ensure they wouldn’t get deleted on boot.

Keylogger?

Use a keylogger not picked up by AVs. i.e. an obscure

commercial/”legit”, not designed for hackers.

AuditorKill while

installing keylogger.DOS batch scripts’ source code can be read. Easy to see how to

make HDS create a fresh known-good registry copy based on its current state.

Step 3 – Carry out attack

● Added keylogger files + registry settings to floppy disk● Made floppy disk bootable into MS-DOS● Used floppy disk to install keylogger onto workstations in IT

office outside of working hours before it was locked for the day– Installed on about 30 workstations

● Keylogger log files were manually downloaded via floppy disk– Minimise chance of detection

– No place on the network to store logs undetected


● Attackers waited for 3-4 months of normal workstation use

● During this period:– no evidence of detection of the keylogger by IT staff

(via social engineering)

– no evidence that killing the Auditor program had been deteced or acted upon

– only some workstations had been rebuilt

– credentials of ~150 users were captured

– captured credentials included domain admin account


● Attackers now had the Administrator password– next needed to verify without triggering alerts or leaving an

audit trail

– need a low-level operation that not trigger Audits

– killing Auditor did not appear to trigger security alerts previously, so…1) login using another user account

2) kill Auditor (just in case)

3) make low-level connection to

server using admin pw

4) immediately disconnect

Step 4 – Maintain Access

● Attackers were confident that the IT staff’s security hygiene was low by this point

● The attackers found a number of system accounts used by the provider’s software. – they created a new account named such that it

would appear as another system account

– set the password and added it to the Domain Domain Admins group

Step 5 – Cover Tracks?

● Keylogger software was left on workstations, on the basis it was very unlikely to be detected and had no link back to the attackers

● Attackers were keen not to launch high-level admin applications (such as the auditor software) directly on the server, as this may get detected

● In this case no action was taken to cover tracks


authentication controls) - DONE– i.e. administrator account access



Phases of attack


Maintainaccess

Covertracks

Gaining WAN access

● Aim: gain WAN access without detection

Internet


NT4 server


NT4 server

proxyserver


192.168.1.x

192.168.1.1

192.168.1.2

DHCP, D

NS, W

INS

● Proxy: likely to have strong audit configuration● Two challenges: 1) getting a physical connection, 2) using it without detection

As if by luck...

● Reconnaisance had found– Low physical security

– Some workstations located outside IT office

● Didn’t take long to find a switch cabinet in a dark corner

● [piccie – with key in it!]

Adding a new connection

Internet


NT4 server


NT4 server

proxyserver


192.168.1.x

192.168.1.1

192.168.1.2office

switch

AP

attackers’server

● physical link… solved!

Hiding the connection

● Normal workstations request IP addresses via DHCP, and use this to connect to the internet– already established that auditing is likely to be taking place

at high-level only (i.e. probably not DHCP)

– We can get around the risk that DHCP is logged by setting static IP addresses outside of the DHCP pool.

– From our scanning we know the gateway/DNS/mask info we need

● however, we assume proxy will be auditing access and do not want to try to compromise the proxy directly


● How to hide the fact our connection is illegitimate?– Option 1: we masquerade as a normal workstation

● Means that admin must be able to configure it using normal admin tools so as not to raise suspicions

● Means our machine must appear on all the admin tools

– Option 2: we make ourselves as invisible as possible

● Not “undetected” but the next best thing: if it is detected, make it impossible to work out what our machine is

● Can also randomise our MAC or IP address to frustrate blocking, if it is detected


● Going dark● Achieved by:

– Linux running on attacker server

– iptables, blocking all incoming traffic incl ICMP

– Using NAT to enable attacker machines ‘behind’ the server to access the wireless and WAN connection

officeattackers’server

Internetproxyserver


authentication controls) - DONE– i.e. administrator account access



Phases of attack


Maintainaccess

Covertracks

Security – what went wrong?

● What were the key design flaws?1.Principle of least priviledge

2.Defense in depth

3.Auditing

4.Software choice

5.Physical security

Principle of least Priviledge

● Don’t use a sledgehammer for basic tasks!– Using administrator account totally unnecessary

– Only rebuild priviledges needed – local admin at most!

● How to avoid?– Use granular accounts/access

– For one-off semi-auto tasks (e.g. rebuilds) use one-time accounts, or one-time passwords

Defence in Depth

● Go deep – and assume the bad guys have too– assume that defences have been compromised

– IT staff failed to see that workstations had weak security – and shouldn’t have used admin accounts there

– Immobilisers in cars

● How?– Every component should have appropriate security

standalone

– Keep high-value stuff (accounts, data, etc) away from low-security components

Auditing!

● Log, log and log again– Attackers could assume they wouldn’t be detected

thanks to no log monitoring

– Even with poor defences IT staff would have been able to contain attacks if they’d watched the logs

● How?– More alerts does not mean more secure

● Alert only on significant events, log lots of relevant data in case an investigation is needed

– Events should include any use of important accounts/access of sensitive data so that a human can check that it was authorised

Software Choice

● Use software that’s easy to protect– Using Win98 meant a lot of extra apps were needed to

provide basic security

– The insecure design meant that once the apps were bypassed the core OS was easily compromised

– NB this attack could have worked as easily with a more secure OS on the workstations, but it would have been harder

– Good software only works if you know what you’re doing

● How?– doesn’t need to be the most secure – Linux/Mac/modern

Windows have the basic security you need!

– Good patching regime

Physical Security

● “If you can see it, you can own it”– i.e. physical security is really important

● Physical security on this network was more appropriate– i.e. important assets (server) was kept secure, less

important assets (workstations) had more lax security

● Physical security feeds into defense in depth: if a device is accessible to potential attackers, assume it is compromised

In Summary

● This was a story of a secure server being compromised via bad practice in insecure systems connected to it

● Good security design trumps secure software– but secure software helps

● Contrary is true: bad security hygiene will bring down secure setups

Insider Attack – a case study

Jonny Tyers@JonnyTyers

www.jonnytyers.co.uk

Insider Attack – a case study Jonny Tyers @JonnyTyers www ...

Documents

Transcript of Insider Attack – a case study Jonny Tyers @JonnyTyers www ...