[Cyph0n]

> which operates just above the physical layer.

So at the link layer? If so, what you described does not sound like an effective technique to exfiltrate data over the internet, unless the NSA also controls the LAN/internal network the target device is on.

Why? Because any non-standard protocol data will be thrown out by the first switch or router on the path out of the target LAN. In other words, the exfiltrated data will not be forwarded on to the next router or switch, simply because the next router/switch will not have support for the NSA's custom protocol in its network stack.

[nickpsecurity]

"Why? Because any non-standard protocol data will be thrown out by the first switch or router on the path out of the target LAN. "

That's not necessarily true. Misconfigurations and weird issues in networking gear caused vendors to be kind of permissive about some things. Depending on the vendor, they might drop it or pass it through. Network security folks in the field, in or away from NSA, probably have a good idea of what things make it through most often plus fall-back options. They might even keep current documentation of it based on field reports over time. They'd just use that stuff. Also, intelligence work is very difficult and opportunistic already. A method doesn't have to work all the time: just enough to keep trying it.

[shawn]

One thing the NSA is very good at is getting access to virtually every type of networking card. If they achieve access to a target, it's likely they control a path to it.

If the target is a wifi device, the custom protocol becomes doubly effective: Exfiltration is a matter of having a receiver anywhere in the vicinity. And that receiver can amplify the signal to blast it a few miles. There are tools to sweep the EM spectrum looking for anomalies like this, but they seem to be rare, for the moment.

[viraptor]

> If they achieve access to a target, it's likely they control a path to it.

Without specific, documented cases this is speculation of course. But I don't see why they'd use a link level protocol. 1. It requires patching multiple networking devices in the path, which is not very quiet. 2. It sticks out in any monitoring (via mirror ports) more than a UDP packet to a random host. DNS or ntp as a transport would be much simpler to hide.

[amoshi]

And what exactly would be the problem for the NSA with patching networking devices? They even mention how it's useful specifically for these hard targets

>"some of the most productive operations in TAO because they pre-position access points into hard target networks around the world."

https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa...

[Bromskloss]

Could packet delays perhaps survive over the network?

[nickpsecurity]

Yes. I used both header fields and delays as covert channels in the past since I know security professionals never looked for them. I derived them by just applying a standard, covert-channel analysis on the protocol. Others have described some methods publicly:

https://defcon.org/images/defcon-10/dc-10-presentations/dc10...

https://engineering.purdue.edu/dcsl/publications/papers/2009...

The oldest methods of finding stuff like this are Kemmerer's Shared Resource Matrix (1983) for storage channels and Wray's updated characterization (1991) that were used in DOD's security certification (TCSEC). They work for hardware, too, since it's how they found cache-based, timing channels in hardware hosting the VAX Security Kernel in 1992.

http://www.cs.ucsb.edu/~sherwood/cs290/papers/covert-kemmere...

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.534....

For transport, military-grade security often mandated fixed-size, fixed-rate transmission with error handling itself not able to leak stuff. Tricky on error part, inefficient other part. A primitive software defense is to clear the storage channels while throttling and randomizing the timing of delivery. Works best on non-real-time or already-slow configurations. Idea fit for store-and-forward messaging, which was preferred for high-assurance security. Another option from 1990's high security was to have a PCI card or something running a security kernel do the actual transfer from a labeled source. As in, the source can be as malicious as it wants with it unlikely to effect secure kernel. The kernel might prevent it, detect it, shut it down, or preserve logs for traceability. There was also the "force everything over link/network encryptor" concept to attempt to cheat. Leaves some metadata which can be mitigated or obfuscated by other means including prior transmission method.

Hope that helps. Current work uses models or languages to track shared resources for automatically detecting storage or timing channels among other things. I'll dig some out of my collection if anyone wants them.

[artificial]

Interesting, please share when you’ve the time. Thanks!

[nickpsecurity]

Language-based Information Flow Security (2003)

http://www.cs.cornell.edu/andru/papers/jsac/sm-jsac03.pdf

Note: This is a great overview with plenty of terms you can use to find modern work. It's branching out in all these areas. Key words to use include "non-interference", "static analysis," "covert channels," "labels," "confidentiality," and "side channels."

Securing Information Flow at Runtime (2008)

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.142....

Note: Example of the language work they do to lay down foundations.

Static, Info-Flow Analysis That Handles Implicit Flows (2010)

http://www.cs.rpi.edu/~milanova/docs/csmr10.pdf

Note: This is a bit more like how you'd develop low-intervention, preventative analysis.

Static, Info-Flow Analysis on Hardware Language (2017)

https://www.cs.cornell.edu/andru/papers/trustzone/asplos17.p...

SecVerilog: Security-Typed HDL for Secure Hardware without Runtime Components (2017)

https://people.ece.cornell.edu/af433/pdf/ferraiuolo-dac-17.p...

Inline, Information-Flow Monitor for JIT-like Applications

https://www.cs.stevens.edu/~naumann/inlining/Chudnov_Informa...

Jif, Sif, and Fabric

https://www.cs.cornell.edu/jif/

Note: Used in Civitas secure voting app. Links to Sif and Fabric are down the page a bit. Note 2: You should be noticing by now that the Cornell teams (a) are pretty awesome and (b) were way ahead of most on this stuff.

Deterministically Deterring Timing Attacks in Deterland (2016)

https://pdfs.semanticscholar.org/6aa3/18e95cae5a932e330857e5...

Note: Thanks to a few events, there are piles of work on hardware ranging from invididual components to whole chips. So, I'm just grabbing examples of different types. This one is on VM's in cloud.

Øzone: Efficient Execution with Zero Timing Leakage for Modern Microarchitectures (2017)

https://arxiv.org/pdf/1703.07706.pdf

Note: Dedicated, execution unit.

SAFE processor

http://www.crash-safe.org/papers.html

Note: Its metadata engine can do secrecy labels. It can do a lot of policies actually. Commercially available for RISC processors as CoreGuard.

Software-based, Gate-level Information Flow Security for IoT Systems (2017)

http://rakeshk.crhc.illinois.edu/micro17_cam.pdf

Note: Throwing an attempt in that's trying to avoid secure processors. Only read abstract since I just found it. I'm always skeptical if commodity chips are involved, though. Best I've seen are hardware I.P. that reuse optimized processors sort of sitting between their cores and the decoders or RAM. Plus, multicore without shared caches or multiprocessing with each core/chip a security domain.

So, there's some different things for you. Kemmerer and Wray are definitive, older works. Sabelfield and Myers best overview of new stuff. After Meltdown/Spectre, the rest is coming so fast I'm not even tracking it. I'm glad someone asked justifying an attempt at a survey. Found some good links. :)

[jsjohnst]

It’s comments like yours why I always check the thread after reading an article. Thank you!!

[nickpsecurity]

Comments like yours keep me writing them. Thank you! :)