1

I'm not sure if this is the right medium to ask this but I'm looking for pointers or if this is being done. I realize that this is still a bit of a open question.

When internal network holds critical data and control software/hardware, airgapping is the norm. But as we've seen in Stuxnet/Flame and their siblings, it has it's limits. And now that the cat's out of the bag, we'll likely see non-state sponsored attackers using this vector.

So, let's assume sophisticated and motivated attacker without physical access. Attacker will try to smuggle in tainted firmware via hardware interceptions, social engineering or novel approaches. Auditing firmware before connecting to network would be ideal but even then, might not be possible to get 100% detection. I'm looking for ways to mitigate the damage and minimize time until detection if they succeed.

Assumptions: Access to source of everything we run inside the network. Datadrives are encrypted. Attacker knows broadly software and hardware used, has good estimate of network architechture. Doesn't have physical access to system. Attacker has zero-day vulnerabilities on-hand that'll allow them to breach higher level defenses like user privileges.

Could this threat be mitigated by making precompiled code unable to run in the system by making whole internal network unable to run precompiled code? How could we achieve this?

I'm thinking in lines of linking everything against local libraries with enough differences that compiling against those libraries would be required for attack to work. What else can we shuffle? Goal being to maximise added difficulty while retaining the ability to integrate new software by compiling it in-system.

Would this even help? Firmware would still run and could do a lot of damage. But limiting ability to inject stuff would increase the risk of detection which is after all the most we can hope for.

I realize security-by-obscurity is frowned upon but I feel that it might have it's place in this. Since the obscured part is site specific, attacker would need to have accoplice on-site and we need to rely on personnel security to prevent that.

To recap in form of questions:

  1. Is it possible to meaningfully limit foreign code from running inside the network by changes requiring locally built binaries?
  2. Is this being done?
  3. Does this even make sense?
  • 1
    I don't think this makes sense. Most exploits take advantage of already running code. You have to have some mechanism to run code on these systems? If you're assuming knowledge of everything running on the system then this mechanism would be known, and most likely leveraged. – RoraΖ Feb 19 '15 at 17:42
  • @raz: Ah, you're right. I forgot to add that. Memory injections from breached firmware would be a strong attack vector. Wouldn't shuffling system code provide some security from that tho? Making more difficult for the malware to inject the code if attacker can't build a similar system off-site to plan the injection. And to the second point, I'm assuming that obscured part (what was shuffled) is not known. If it was, it would provide no benefit. – WhimsicalWombat Feb 19 '15 at 18:01
  • Fighting firmware-based exploits is something that would be very difficult to have be entirely secure. The best approach would be thinking defense in depth; network ACLs, VLANs, IDSs, and other network security features to monitor behavior on the network so you can catch badness before it succeeds. I don't believe there's any way to 100% protect from the firmware-level attacks but you can do things to limit it's potential. – Nathan V Sep 8 '15 at 21:20

Your Answer

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

Browse other questions tagged or ask your own question.