As Your Admin Walks Out the Door .., (Mon, Jun 19th)

One of our readers (thanks Gebhard) mailed us a link to an article on what the press is apparently now calling a Revenge Wipe - a system administrator who has left the organization, and as a last hurrah, deletes or locks out various system or infrastructure components.

In this case, the organization was a hosting company in the Netherlands (Verelox). In the case of cloud providers, a disgruntled admin may have access to delete entire networks, hosts, and associated infrastructure. In the case where its a smaller CSP, the administrator may also have access to delete customer servers and infrastructure as well. In Vereloxs situation, that seems to have been the case (from their press release at least)

The classic example of this is the City of San Francisco in 2008), where their main administrator (Terry Childs) refused to give up the credentials to their FiberWAN Network Infrastructure, even after being detained by law enforcement (he eventually did give the credentials directly to the Mayor). Ive listed several other examples in the references below - note that this was not a new thing even in 2008 - this has been a serious consideration for as long as weve had computers.

So, how should an organization protect themselves from a situation like this?

Use Separation of Duties:

Know who has access to what. Have multiple people with access to each system. Having any system with only a single administrator can turn into a real problem in the future.

Use Authorization:

It can be difficult, but wherever possible use Admin accounts with only the rights required. Its very easy to build an every Admin has all rights infrastructure. Its likely more difficult to build a why does the VMware admin need the rights to delete an entire LUN on the San config but its important to think along those lines wherever you can.

Use a back-end directory for authentication to network infrastructure:

What this often means is that folks implement NPS (RADIUS) services in Active Directory. This allows you to audit access and changes during regular production, and also allows you to deactivate network administrator accounts in one place

Where you can, use Two Factor Authentication

Use 2FA whereever possible, this makes password attacks much less of a threat. 2FA is a definite easy implement for VPN and other remote access, also for administration of almost all Cloud Services for your organization.

Just as a side note - I am still seeing that many smaller CSPs have not gone forward with 2FA - if you are looking at any new Cloud services, adding Two Factor Authentication as a must-have is a good way to go.

Deal with Stale Accounts:

Keep track of accounts that are not in use. I posted a powershell script for this (targeting AD) in a previous story == https://isc.sans.edu/diary/The+Powershell+Diaries+-+Finding+Problem+User+Accounts+in+AD/19833

Deal with Service Accounts:

Service accounts are used in Windows and other operating system to run things like Windows Services, or to allow scripts to login to various systems as they run. The common situation is that these service accounts have Domain Administrator or local Root access (depending on the OS).

Know in your heart that the person you are protecting the organization from is the same person who likely created one or all of these accounts.

Be sure that these service accounts are documented as they are created, so that if a mass change is required it can be done quickly.

Know that these use a central directory (such as AD or LDAP), so that if you need to change them or disable them, there is one place to go.

I posted a PowerShell script in a previous story to inventory service accounts in AD == https://isc.sans.edu/forums/diary/Windows+Service+Accounts+Why+Theyre+Evil+and+Why+Pentesters+Love+them/20029/

Restrict Remote Access:

Be sure that your administrative accounts dont have remote access (VPN, RDP Gateway, Citrix CAG etc). This falls into the same category as dont allow Administrators to check mail or browse the internet while logged in as a Domain Admin or root privileges.

On the day:

On the day of termination, be sure that all user accounts available to our administrator are deactivated during the HR interview. If youve used a central authentication store this should be easy (or at least easier)

Also force a global password change for all users (your departing admin has probably done password resets for many of your users), and if you have any stale accounts simply deactivate those.

For Service accounts, update the passwords for all of these. This is a good time to be sure that you arent following a pattern for these passwrods - use long random strings for these (L33t speak versions of your company or product name are not good choices here).

Im sure that Ive missed some important things - please, use our comment for to fill out the picture. This is a difficult topic, since many of us are admins for one thing or another this really hits close to home. But for the same reason, its important that we deal with it correctly, or as correctly as the situation allows.

References:

https://www.heise.de/newsticker/meldung/Revenge-Wipe-Ex-Admin-loescht-Daten-bei-niederlaendischem-Provider-3740243.html?view=print

https://translate.google.com/translate?sl=autotl=enu=https%3A//www.heise.de/newsticker/meldung/Revenge-Wipe-Ex-Admin-loescht-Daten-bei-niederlaendischem-Provider-3740243.html%3Fview%3Dprint

https://www.schneier.com/blog/archives/2008/07/disgruntled_emp.html

http://www.infoworld.com/article/2653004/misadventures/why-san-francisco-s-network-admin-went-rogue.html

https://www.scmagazine.com/former-system-admin-sentenced-to-34-mo-for-hacking-former-employer/article/640254/

https://www.wired.com/2016/06/admin-faces-felony-deleting-files-flawed-hacking-law/

http://www.independent.co.uk/news/business/news/disgruntled-worker-tried-to-cripple-ubs-in-protest-over-32000-bonus-481515.html

===============
Rob VandenBrink
Compugen

© SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Article Link: https://isc.sans.edu/diary/rss/22530