Security – How does the updated Shellshock vulnerability test for CVE-2014-7169 work

There are a number of problems, ranging from minor to fatal (all of the fatal ones have to do with the "cat...while...read" line). Let me go through them in order:

• As Dennis Williamson pointed out, the "#!/bin/cat" and "declare..." lines don't do anything.
• You set FILE to result.var near the top, but then never use this variable. Assuming it's intended to allow you to change the filename in just one place, you should replace all other references to result.var with "$FILE"
• The while statement needs a "do...done" - or rather, it would if you actually needed the while statement in the first place. Since you're only reading one RESULT from the file, you don't need a loop.
• Since the "read RESULT" is part of a pipeline, it runs in a subshell, and the value of RESULT it sets is lost when that subshell exits. You could fix this by using something like 'read RESULT <"$FILE"'.
• What's the "IFS=:" bit there for? It sets the internal field separator to ":" for the duration of the read command, but since you're only reading one field (RESULT), the only thing it does is to trim leading or trailing colons from what's read from result.var. If you meant to ignore everything after a colon (i.e. only use the first colon-delimited field from result.var), you should use "IFS=: read RESULT IGNOREDJUNK" instead.
• Unless you're actually trying to trim/parse the contents of result.var, or need to use it several times, you don't need to read it into a variable at all; just use 'mv "ll_bkup" "$(cat "$FILE")"'. But I claim you want to use it again (see below).
• The script is rather fragile in the sense that it doesn't check to make sure result.var exists (and since the script moves that file, if run twice in a row it's guaranteed to fail the second time); similarly, it doesn't check if "$RESULT" already exists before trying to rename ll_bkup to it, leading to potentially unpredictable results.
• Speaking of which, your description says result.var gets copied, but the actual code moves it. Which is the intended behavior?
• Finally, the "else... exit 0" section does nothing that the "exit 0" at the end isn't about to do anyway.

Gripe, gripe, gripe... anyway, here's my proposed rewrite:

#!/bin/bash
# Restores original directory name for next LogLogic Update
#TCJ 6/1/09
FILE=result.var
cd /home/nb-backup/backups/nb-st3000/ll_bkup_65.99.220.172/
if [ -d ll_bkup -a -f "$FILE" ]; then
    read RESULT <"$FILE"
    if [ ! -e "$RESULT" ]; then
        mv  "ll_bkup" "$RESULT"
        mv "$FILE" /home/storegrid/scripts/results/result-`date +%y%m%d%s`.var
    fi
fi
exit 0

It's really, really, really hard. It requires a very complete audit. If you're very sure the old person left something behind that'll go boom, or require their re-hire because they're the only one who can put a fire out, then it's time to assume you've been rooted by a hostile party. Treat it like a group of hackers came in and stole stuff, and you have to clean up after their mess. Because that's what it is.

• Audit every account on every system to ensure it is associated with a specific entity.
• Accounts that seem associated to systems but no one can account for are to be mistrusted.
• Accounts that aren't associated with anything need to be purged (this needs to be done anyway, but it is especially important in this case)
• Change any and all passwords they might conceivably have come into contact with.
• This can be a real problem for utility accounts as those passwords tend to get hard-coded into things.
• If they were a helpdesk type responding to end-user calls, assume they have the password of anyone they assisted.
• If they had Enterprise Admin or Domain Admin to Active Directory, assume they grabbed a copy of the password hashes before they left. These can be cracked so fast now that a company-wide password change will need to be forced within days.
• If they had root access to any *nix boxes assume they walked off with the password hashes.
• Review all public-key SSH key usage to ensure their keys are purged, and audit if any private keys were exposed while you're at it.
• If they had access to any telecom gear, change any router/switch/gateway/PBX passwords. This can be a really royal pain as this can involve significant outages.
• Fully audit your perimeter security arrangements.
• Ensure all firewall holes trace to known authorized devices and ports.
• Ensure all remote access methods (VPN, SSH, BlackBerry, ActiveSync, Citrix, SMTP, IMAP, WebMail, whatever) have no extra authentication tacked on, and fully vet them for unauthorized access methods.
• Ensure remote WAN links trace to fully employed people, and verify it. Especially wireless connections. You don't want them walking off with a company paid cell-modem or smart-phone. Contact all such users to ensure they have the right device.
• Fully audit internal privileged-access arrangements. These are things like SSH/VNC/RDP/DRAC/iLO/IMPI access to servers that general users don't have, or any access to sensitive systems like payroll.
• Work with all external vendors and service providers to ensure contacts are correct.
• Ensure they are eliminated from all contact and service lists. This should be done anyway after any departure, but is extra-important now.
• Validate all contacts are legitimate and have correct contact information, this is to find ghosts that can be impersonated.
• Start hunting for logic bombs.
• Check all automation (task schedulers, cron jobs, UPS call-out lists, or anything that runs on a schedule or is event-triggered) for signs of evil. By "All" I mean all. Check every single crontab. Check every single automated action in your monitoring system, including the probes themselves. Check every single Windows Task Scheduler; even workstations. Unless you work for the government in a highly sensitive area you won't be able to afford "all", do as much as you can.
• Validate key system binaries on every server to ensure they are what they should be. This is tricky, especially on Windows, and nearly impossible to do retroactively on one-off systems.
• Start hunting for rootkits. By definition they're hard to find, but there are scanners for this.

The decision to kick off an audit of this incredible scope needs to be made at a very high level. The decision to treat this as a potential criminal case will be made by your Legal team. If they elect to do some preliminary investigation first, go for it. Start looking.

If you find any evidence, stop immediately.

• Notify your legal team as soon as you find something likely.
• The decision to treat it as a criminal case will be made at that time.
• Further action by untrained hands (you) can spoil evidence and you don't want that, not unless you want the perp to walk free.
• If outside security experts are retained, you are their local expert. Work with them, to their direction. They understand the legal requirements for evidence, you do not.
• There will be a lot of negotiation between the security experts, your management, and legal counsel. That's expected, work with them.

But, really, how far do you have to go? This is where risk management comes into play. Simplistically, this is the method of balancing expected risk against loss. Sysadmins do this when we decide which off-site location we want to put backups; bank safety deposit box vs an out-of-region datacenter. Figuring out how much of this list needs following is an exercise in risk-management.

In this case the assessment will start with a few things:

• The expected skill level of the departed
• The access of the departed
• The expectation that evil was done
• The potential damage of any evil
• Regulatory requirements for reporting perpetrated evil vs preemptively found evil. Generally you have to report the former, but not the later.

The decision of how far down the above rabbit-hole to dive will depend on the answers to these questions. For routine admin departures where expectation of evil is very slight, the full circus is not required; changing admin-level passwords and re-keying any external-facing SSH hosts is probably sufficient. Again, corporate risk-management security posture determines this.

For admins who were terminated for cause, or evil cropped up after their otherwise normal departure, the circus becomes more needed. The worst-case scenario is a paranoid BOFH-type who has been notified that their position will be made redundant in 2 weeks, as that gives them plenty of time to get ready; in circumstances like these Kyle's idea of a generous severance package can mitigate all kind of problems. Even paranoids can forgive a lot of sins after a check containing 4 months pay arrives. That check will probably cost less than the cost of the security consultants needed to ferret out their evil.

But ultimately, it comes down to the cost of determining if evil was done versus the potential cost of any evil actually being done.