1
$\begingroup$

Background:

A corporate saboteur manages to get into his competitor's building and finds the computer of one of the system admins left on running scans. Excited with the opportunity he rushes over to the computer and starts poking around, and to his delight, the sysadmin has setup a method in which he can remotely turn on all computers and remotely download a program and install it on all computers, on the network. So the saboteur knowing he doesn't have a lot of time, quickly writes a small program that runs this fork bomb, %0|%0|%0. He then installs it on all the computers and makes it so that it runs on startup (all computers on the network are windows). Then he remotely shuts down all computers, including the one he is on.

Updates:

There are about 300 computers on the network, and this is the corporations only location.

Booting from another disk/drive is prevented as a security precaution, so booting from another disk or drive attached is not an option.

Question:

How damaging would this attack be to the corporation assuming that the program that started the fork bomb executed whenever the computer turned on?

How would the corporation recover from such an attack?

Note: Any feedback on improving the question is appreciated. If anything is unclear and needs more explanation, please let me know and I will do my best to explain it better.

$\endgroup$
  • $\begingroup$ How many computers? All in the same location? Are there IT personnel at each location with a computer? If the computers are off, does the install run before the fork bomb or not? Will the remote turn off turn off the computers while the fork bomb is running? $\endgroup$ – Brythan Dec 18 '15 at 18:06
  • $\begingroup$ "Whenever the computer is turned on" is vague. Please specify the exact step in the power-on/boot process that causes the fork bomb to execute. A fork bomb that is started from a Windows GPO is very different from something dropped into the Startup folder is very different from something that causes the firmware to be unable to initialize the hardware, for example. The impact would be different for each. $\endgroup$ – a CVn Dec 18 '15 at 18:08
  • $\begingroup$ @Brythan updated with some info. the IT personnel are those hired by the company. the company only has one location and has about 300 computers. I'm unsure of what you mean by the install running before the fork bomb, and the remote turn off might work if there is enough resources to perform it, otherwise a hard power off is required $\endgroup$ – Dragonrage Dec 18 '15 at 18:17
  • $\begingroup$ @MichaelKjörling i am not entirely familiar with how exactly boot sequences work, so whatever is standard for programs that load with windows $\endgroup$ – Dragonrage Dec 18 '15 at 18:21
3
$\begingroup$

No actual data is compromised, and the hardware would be fine, so I'm in agreement with Draco. Three hundred computers could probably be fixed by a single person in two or three days, four at the most, by just going around with a linux live USB and removing the bad batch file from the hard disk. Add one-half to one day for someone to diagnose exactly what's going on and borrow someone's laptop to make the USB (assuming there wasn't one to hand already) give a range of 2.5 to 5 days to get everything back online. If the bomb doesn't run in safe mode (it probably doesn't), this might save a half-day of time over using a live USB (if the USB is already made).

This assumes that once one computer is saved there's not an easy way to just mass remove the file once one computer is restored. Since the admin can mass push files out, I'd assume there's a way to mass delete files, but you didn't specify it so I'll assume there isn't. If there is the recover time could go as low as maybe an hour or two.

I see that in your comment you wanted the computers to be designed not to boot from external media. That's a fairly normal security measure for corporate environments, but it's usually set up so that an admin password is needed to boot from external media rather than disabling it completely, and we have the admin helping us out. If you really disabled somehow, it should be easily re-enabled in the BIOS (which may also be admin-password protected, but again, we have the admin). If for some reason the BIOS is inaccessible (which I find implausible), you can reset it by moving the CMOS jumper on the motherboard or simply removing the CMOS battery.

In the easy case (admin password needed to boot from external media) this adds basically no time. In the hardest case (the unlikely situation that you need to hardware reset the BIOS) this could add maybe one to two days of time to open up all of the computers, and perhaps up to a week to reconfigure every BIOS if there are a lot of customized settings. However, this could be done after bringing all of the computers back online, so it's not really part of the timetable.

So, let's round off and say 2 to 5 days for a single IT guy to get all of these computers back into working order, assuming he has to do each one individually. You can multiply this time by the average profit-per-day of this company to see how much value is lost. If it greatly exceeds the cost of hiring a couple extra IT guys for a day to get it done in 1-2 days instead of 2-5 days, the company will do that. If the company can still perform some fraction of its business without the computers, scale down the losses accordingly.

$\endgroup$
3
$\begingroup$

A single live-cd that boots a different operating system does wonders. Boot to the CD (avoids the on-startup fork bomb) and then go in and remove the fork bomb from the startup directory. Repeat for all machines. If he doesn't have one on hand, all it takes is a single non-infected machine (say, someone's take-home laptop) with a write-capable drive and some blank CDs/DVDs.

The sysadmin would hate his life for a few days as the Corp is brought to a functional standstill, unable to do any work until the problem is fixed. But in the grand scheme of things no permanent damage is done (and the sysadmin learns a valuable lesson about logging off when he leaves).

$\endgroup$
  • $\begingroup$ i forgot to add that external boot from disk/external drive is prevented $\endgroup$ – Dragonrage Dec 18 '15 at 18:20
  • $\begingroup$ Oh. Well. That makes the problem only the tiniest bit harder: put the affected hard drive as a slave drive in another machine. This adds about 5 minutes worth of physical labor to the task, and the sysadmin is likely fired. $\endgroup$ – Draco18s Dec 18 '15 at 18:25
  • $\begingroup$ would it be that simple to figure out what is happening? if they didnt know what they were infected with, would it be a simple job figuring out what the problem is? $\endgroup$ – Dragonrage Dec 18 '15 at 18:30
  • $\begingroup$ Any sysadmin in charge of a company with more than 100 machines should be aware of the symptoms of a fork bomb. Even if they're not, simply examining the first machine's hard drive for startup tasks will quickly discover the process that hangs the machine. The easiest solution would be to just clear the entire startup directory (even if some are legitimate) and see if that fixes it. In order to do serious damage you have to be much more subtle, such as injecting spyware into the company printer's firmware. $\endgroup$ – Draco18s Dec 18 '15 at 18:33
0
$\begingroup$

Even assuming that someone has to manually remove the hard drive from each computer and delete the fork bomb program, this should be fixable within a week.

Note that it is standard on Windows computers to be able to boot without launching the startup programs (Safe mode). So IT personnel should be able to just manually boot each computer, delete the program, and restart. This takes something like ten to fifteen minutes and can be partially parallelized. So five computers in the same location might take thirty-five minutes to do (figure five minutes to start each computer and ten minutes to finish the last one). If there are three IT personnel, they could probably do this in two days.

And all this assumes that they can't just power off all the computers and run a remote uninstall. The remote uninstall should run with higher priority than the startup programs for exactly this reason. But it is by no means impossible that this was done incorrectly in this case. After all, the sysadmin leaves open an administrator machine.

$\endgroup$
  • $\begingroup$ the last method would also be unavailable if the fork bomb was installed on the sys admins computer as well correct? $\endgroup$ – Dragonrage Dec 18 '15 at 18:44
  • $\begingroup$ Fixing one computer is relatively simple. So fix the admin computer first and then use the last method on everything else. It's true that it makes it harder, but not a lot harder. $\endgroup$ – Brythan Dec 18 '15 at 21:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.