Infiltrated dot Net

Five Deadly Security Venoms - You're Still Doing it Wrong
Written by J. Oquendo   

With all the hype and hooplah surrounding the US government's tapping of everything under the sun, I have seen an influx of articles related to security. "This is how you encrypt!", "this is how you secure!", "this is how... You're doing it wrong."

Having been around security for much longer than I care to admit nowadays, I often see many confuse the "concept of security," with the technological capabilities, and application of security. Meaning: actually securing communications. Be it via way of system level encryption (disk based), and network based encryption (SSL, TLS, VPNs), many in the industry are missing the fundamentals of it all. Horribly at that. This confusion is beginning to worry me, because I have been seeing some well known, and respected security professionals, evangelists, and "experts" making the same mistakes repeatedly. Not only via way of the processes involved with security, but pounding the pulpit with "this is how you secure your data/network/traffic" yet they are missing the reality that you really can't secure it all, at the end of the day.

While I don't want this to be a technical write up filled with Visio diagrams, RFC references, I need to add some to clarify my statement - "You're doing it wrong... still!" Let's begin with the fundamentals of disk based encryption, which WILL include message encryption. Message encryption could be anything you choose, PGP, steganography, it could be Pig Latin. The gist is, encrypting (scrambling) data before it leaves your computer, or is stored on your computer, so that the message cannot be understood by anyone else, who doesn't have a "key", "password", or any other means to decrypt the message. Forget Alice and Bob nonsense, its ancient.

Encryption solution caveman style: You create a "key" and encrypt a message using someone else's "key" only they can read it.

Five Deadly Venoms of Encryption

  1. You chose / recipient chose a weak password (PGP, SSL, TLS, Truecrypt, etc)
  2. Your key is compromised (PGP, SSL, TLS, Truecrypt, etc)
  3. The recipient's key is compromised (PGP, SSL, TLS, Truecrypt, etc)
  4. Your operating system is compromised
  5. Recipient's operating system is compromised


"You chose / recipient chose a weak password" and now with the influx of millions of passwords that were stolen [1], attackers have created wordlists which can crack your password in seconds. PEBKAC fail.

"Your key is compromised." With the current state of malware, viruses, and worms, do not think for a second, an adversary is not capable of obtaining your private key. As someone who has reverse engineered malware professionally, and as a hobby, I cannot tell you how many keys and certificates I have come across.

"The recipient's key is compromised." So you jumped through hoops and hurdles to ensure your key was secure. Doesn't mean the recipient did the same. It is simple as day and night.

"Your operating system is compromised." This statement is a loaded gun. From the onset, you would likely assume I meant: "a hacker got on your system somehow..." and you would be wrong. History has shown that vendors have continued to include backdoors on their products. This does not mean that "all" vendors include a backdoor, but the reality is what it is... How can you be sure there isn't a backdoor. Do you trust a vendor that much? If so, I pity you. If so, then you don't understand networking, and on that comment, I will explain further in the "Five Deadly Network Venoms."

"Recipient's operating system is compromised." Same as above. You can never be assured that someone has taken the same security measures that you have. I have seen the utmost security professionals get served their heads on a platter. [2]

Five Deadly Venoms of Networking

  1. It's a private MPLS/VPN/Tunnel
  2. I used main mode/aggressive mode (VPN)
  3. Weak passwords
  4. Trust
  5. Core/operating system


"It's a private MPLS/VPN/tunnel." Unless you own every single point along the network, do not assume traffic can't be decrypted. There are companies which specialize in decryptors. Couple this with #1 from the above "Five Deadly Venoms of Encryption" and security becomes a moot point using VPNs, MPLS and private networks. Recent Snowden disclosure of Google being tapped at the upstream illustrates this.

"I used main mode/aggressive mode." Once upon a time, main mode was the best choice but this too is a moot point, and I shouldn't even need to explain why anymore. (Weak passwords, flawed/backdoored equipment)

"Weak passwords." There is a running theme that a strong password will make you safe. "A 25-computer cluster that can cracks passwords by making 350 billion guesses per second. It was unveiled in December by Jeremi Gosney, the founder and CEO of Stricture Consulting Group. It can try every possible Windows passcode in the typical enterprise in less than six hours to get plain-text passwords from lists of hashed passwords" [3]

"Trust." You should be following the X-Files motto: "Trust No One." While I do trust my brother, I don't trust that his machine can't be compromised. See the issue here? With networking, there is consensus to "trust" a "peer" (BGP). This allows network operators to peer routers, and pass traffic. We all have seen how this can, and has been abused since the mid 90s. [4]

"Core/operating system." If you haven't been paying attention, at the core of it all, is the operating system. Even networking components can "be had," [5] and when they're not, vendors are still leaving backdoors, purposefully or not.

These are all "known knowns," that many in the security industry should be well aware of, yet many continue to get things wrong. I have been reading too many articles, snippets, tweets, etc., from those in the industry who are failing to get to the root of the problem, the underlying core (operating system). Then I read comments from the zealots: "But I use Linux/BSD/Solaris" often forgetting, ignoring, or even not knowing, that some for some of these systems it is even easier to hide malicious commands, codes, software, than it is on Windows. I have illustrated this before as a proof of concept [6] without even trying hard. So imagine what someone with "intent" can do.

This article can go on for days illustrating why professionals are getting it wrong. It does not include other theories I can put forth, so here is one last "OMG you got served" scenario. It is based on common sense, with additional "theory based" concepts borrowed from Stuxnet. When researchers (myself included) studied Stuxnet, it was discovered that it was highly targeted; geographically, based on what the system was running. If it detected it was on the wrong machine, it politely cleared itself out. So imagine the following illustrated in pseudo-code

targ = WhateverNetworkIChose
code = mycode
dest = WhateverNetworkIChoose

if [ $targ != list_of_targets ]
then
     exit
else
     $code $targ $dest
fi


Barebones translation: Check and see prior to running anything, if I am targeting the right machine/network. If I am not, exit, otherwise, run my code against this target and make sure all ends up wherever I want it to.

For example... Assume I wanted to SOLELY target Iranian machines. I could just go out and get their entire network blocks [7] and keep them in a list. I will call this: targetlist. Next I will/can have specific exploits to target an operating system (Windows, Linux, etc.), I will call this: exploitlist. Now, I need an endpoint destination for whatever reason, maybe I need the compromised machine to download code, an update, maybe I want to point the finger at someone else. I register a fake account and a cloud provider. I will call this: endpoint.

Endpoint is responsible for data exfiltration, pushing code, to be thought of as a "command and control" server. Take two:

targ=targetlist
expl=exploitlist
endl=endlish
cat $targ | while read target

 do
$expl $target re-route $endl
done


"Read this list of targets, exploit them, then re-route them" Are you getting the point? This is barebones security, because I can also check against an operating system (p0f [8]), and make sure I am sending Windows only exploits to Windows machines, and so forth. If I got on a system, I could change that system's hosts file (c:\windows\system32\drivers\etc\hosts /etc/hosts) and call it a day:

$endl  windowsupdate.com


No brainer, piece of cake. I can assure you that many experts and professionals wouldn't even see me coming. These types of attacks have occurred in the past, where every so often you'll read: "Persistent threat, hacked into company, undetected for years" so I need not speak more about that.  So what is the solution? I am unsure there is a solution at this point. All I keep thinking of is the dreaded term: minimization. Be it an air-gapped system, super SSL, TLS, VPN, uber supercrypto-routed-reverse-PNRG-PFS based system, the issue all boils down to the core. Who wrote the operating system - whether or not they can be trusted. That answer to me is no. No vendor, no network operator, no website, corporation can or should be trusted at the end of the day. This is something you must do at your own risk. Now, the reality is, if you have nothing to hide, who cares. However, that argument is too black and white, and it is one I will not get in to.

 



[1] http://money.cnn.com/2013/12/04/technology/security/passwords-stolen/
[2] http://arstechnica.com/tech-policy/2011/02/anonymous-speaks-the-inside-story-of-the-hbgary-hack/
[3] http://www.dailymail.co.uk/sciencetech/article-2331984/Think-strong-password-Hackers-crack-16-character-passwords-hour.html
[4] https://isc.sans.edu/forums/diary/New+bgp+hijack+isnt+very+new/4975
[5] http://www.youtube.com/watch?v=U8fu05Em3Lg
[6] http://infiltrated.net/scripts/plague
[7] https://www.countryipblocks.net/country_selection.php
[8] http://lcamtuf.coredump.cx/p0f3/