The Harms of Forced Data Localization

How we store data---and how we think about keeping our memories available over the long term---has changed in the last few years. The world has become better at keeping data secure and safe by distributing it to multiple continents. However, some leaders are calling for "national Internets"---censored, walled gardens set up to appease special interest groups that range from political factions, to property cartels, to religious police. Other leaders have taken a different tack, called forced localization; rather than blocking your communications, they want to require that all your data (and all the computers that handle it) be inside a single country: theirs, for whichever country they represent. These would be major changes to the structure of the Internet---changes that would harm both businesses and the general public.

Scarcity of Cybersecurity Expertise

Scarcity of cybersecurity experts is a real problem that can be quantified and described---but not one that can easily be solved. Limited resource availability, the basis for our entire economic system, is ordinarily a problem of finding raw materials or advanced machinery, not one of hiring the workers we need to defend our assets---but with more than one million cybersecurity positions unfilled worldwide, currently-identified cybersecurity needs could not be met if every employee at GM, Costco, Home Depot, Delta, and Procter \& Gamble became security experts tomorrow. Those one million positions span all industries, specializations, and requirements, and include approximately 25,000 non-military positions in the United States' federal civil service.

The Next Level

“That’s where the money is!”
– Attributed to Willie Sutton, Non-Traditional Withdrawals Specialist

Willie Sutton was quoted as having said the above (he denied coining the phrase) in response to the question, “Why do you rob banks?” At the time, it was an obvious choice; in a pre-networked world, value was primarily transmitted by moving physical objects around the world, whether they were bars of precious metalsmineral crystals, or slips of paper. A non-traditional account withdrawal, then, relied on transporting physical objects from point A (a location controlled by the bank) to point B (a location controlled by the attacker).

Leviathan's (Mandatory) Heartbleed Blog Entry

It's been 5 days since the release of CVE-2014-0160, better known as Heartbleed. This vulnerability in the OpenSSL security suite utilized by a significant portion of the webservers on the Internet - perhaps half a million as well as many other security and encryption products. In this posting, we'll provide some insight and detail for the two main viewpoints, Business Risk and Technology, before walking through some Considerations which we feel are crucial to conclude an organization's response to the vulnerability.

SpiderOak's Crypton: Design and Implementation Evaluation

Leviathan recently took a critical look at a technology currently in development by SpiderOak called Crypton. Crypton, an open-source project hosted on github, aims to be a zero-knowledge, cryptographically-secure storage framework upon which zero-knowledge cloud applications can be written. Its primary functional goal is to provide assurance that data stored on the server can only be read by the client who possesses the key and cannot be read by the server or anyone else.

Use of Windows exception handling metadata

64-bit Windows and the Intel 64 environment have brought a number of changes to the way processes interact with their environment. Among these is the elimination of the base pointer by default, and with it, the ability to unwind the stack based only on the values of the stack and base pointer and the values at these locations on the stack. This frees RBP up for use as a general purpose register in addition to the 8 new ones introduced in the new architecture.

Introducing ftrace

Ftrace V0.1 [[email protected]]

DESCRIPTION:

ftrace is a reverse engineering tool designed to help map out the execution flow of ELF executables (32bit and 64bit). Instead of printing system calls or library function calls, it prints out the local function calls as they are happening, and attempts to retrieve the function arguments and determine whether they are immediate or pointer type. As of version 0.1, function arguments are only shown for 64bit executables. This program is useful when wanting to see the function flow of a given executable during runtime without having to set incremental breakpoints and backtraces in a debugger like gdb. Ftrace relies on symbols for seeing a functions actual name, but the -S option will show function calls for functions without symbols as well, displaying them as sub_<addr>.

Source: https://github.com/leviathansecurity/ftrace

COMPILE:

gcc ftrace.c -o ftrace

 

USAGE:

ftrace [-p <pid>] [-Stsve] <prog> <args>

 

ARCHITECTURE:

For 32bit executables set FTRACE_ARCH=32, it defaults to 64.

 

OPTIONS:

[-v] Verbose output, print symbol table info etc.

[-p] This option is used to attach to an existing process ID.

[-s] This option will show strings as they are passed through functions (As best it knows how)

[-e] This will show certain ELF info such as symbols, and lists the shared library deps.

[-t] Type detection will guess what pointer type a function argument is, if it is a pointer.

It will detect pointers that are within the range of the text segment, data segment, heap and the stack.

[-S] Show function calls that don't have a matching symbol (For stripped binaries)

 

EXAMPLE:

[email protected]:~/code/ftrace/ftrace$ ./ftrace -t /usr/bin/whoami[+] Function tracing begins here:[email protected]: __libc_start_main()[email protected]: strrchr(0x2f)[email protected]: __printf_chk(0x6,(text_ptr *)0x404444)[email protected]: bindtextdomain((text_ptr *)0x40448a,(text_ptr *)0x404498,(text_ptr *)0x40448a,(text_ptr *)0x404498)[email protected]: textdomain((text_ptr *)0x40448a,(text_ptr *)0x40448a,0x7f6197f75b90,(text_ptr *)0x40448a)[email protected]: getopt_long((text_ptr *)0x404444)[email protected]: __errno_location()[email protected]: geteuid()[email protected]: getpwuid()[email protected]: puts()[email protected]: fwrite()[email protected]: __fpending()[email protected]: malloc()[email protected]: realloc()[email protected]: realloc()[email protected]: __fpending()[email protected]: malloc()[email protected]: realloc()[email protected]: realloc()

BUGS:

  • Semi Rare EIO ptrace error (In progress to fix)
  • Memory leak with -s (In progress to fix)

 

FUTURE:

  • Add support for function arguments on 32bit
  • Add support for following fork'd children of target process
  • Extend heuristics of 64bit procedure prologue calling convention for function args.
  • Add support for showing return value
  • Add function depth tracking for callgraph
  • Add dwarf2 support for .debug section to get function prototype info
  • Port to FreeBSD

Who needs cracking? Give me the plaintext!

Another Defcon has come and gone. As far as I know, everybody I went with made it back safely, so I consider it a great success! 

One of the most frightening things I learned this year was the existence of a tool called Windows Credential Editor (or "WCE"). As far as I know, this wasn't covered in any particular talks, but I had several offline conversations with password researchers. They all told me how downright terrifying this tool is.

Now, I used to be fairly deep in the password game. I competed in Korelogic's Crack Me If You Can challenge the first year it was out (my team ranked second place of eligible teams, with about 1/5 the size of larger teams). I've hosted (and still host) countless password lists, and I almost finished a database-driven breach site (I'll finish it one day, I swear). All of this is great for password cracking, but who needs to crack password hashes when you can dump plaintext passwords?

Let's rewind a little bit, and talk about the state-of-the-art of Windows password cracking, as I recently knew it. Windows has traditionally stored two types of password hashes: LANMAN and NTLM.

The idea is, an attacker (perhaps a script kiddie with nothing better to do, or perhaps one of the nebulous "APT" characters) has compromised a machine on your network. Maybe it's because a secretary was fooled into running a malicious Java Applet, perhaps it was a Web server with a command-injection flaw, or maybe it was a developer who needed to have that special screensaver with the embedded Trojan. Who knows how it happened, but the attacker is on your network.

To continue the attack, the attacker is going to try and move to other machines. To do this, he or she dumps passwords from memory. In a traditional attack, that means they got a list of LANMAN- and NTLM-hashed passwords.

LANMAN-hashed passwords are essentially DES - a known string ("[email protected]#$%") is encrypted with the seven character password (a DES block uses a 56-bit key and 8 bits of parity to encrypt 64-bits of data). If your password is longer than seven characters, it's helpfully split into two seven character strings that are hashed individually. If your password is longer than 14 characters, well, this was the 80s; 15+ character passwords weren't invented yet.

How do you crack LANMAN? Well, let's just say that brute-force guessing a 7-character password can be done quite fast. Heck, my cell phone probably has enough power to crack a LANMAN password with enough cycles left over to work on beating my high score in Angry Birds.

In Windows 3.1, LANMAN was superseded by NTLM (though both were stored for many years for compatibility reasons). NTLM passwords are hashed using MD4. The security mainly comes from converting the password to UTF-16 before hashing it, thus doubling the effective length of the password by adding NUL bytes! In all seriousness, because your password can now effectively be unlimited length, this was a huge step. Since it was 1992, back when I was still in grade school, and DECs still roamed the earth this was actually an impressive step.

NTLM passwords can, of course, be brute forced in much the same way as DES. By using a combination of pure guessing and modifications of common passwords, the majority of NTLM passwords can be brute forced fairly quickly. To give an idea, the 2013 Crack Me If You Can contest gave contestants about 33,000 NTLM passwords with an average length of 14 characters, and the top team cracked about 12,000 of them in 48 hours. That's right - almost 40% of NTLM-hashed passwords, with an average length of 14 characters, could be cracked in just two days. For comparison, cracking one password is often enough to compromise your network.

So, LANMAN can be trivially cracked, and NTLM takes more effort but will still crack relatively easily. From Vista onwards, LANMAN passwords were no longer stored on Windows machines, but some companies still choose to re-enable them for compatibility reasons (though it's a mystery to me who wants to maintain compatibility with DOS).

This was the state-of-the-art a year ago. Let's look at modern Windows password attacks with Windows Credential Editor. 

From the website for the tool, it advertises that it can:

  • Perform Pass-the-Hash on Windows
  • 'Steal' NTLM credentials from memory (with and without code injection)
  • 'Steal' Kerberos Tickets from Windows machines
  • Use the 'stolen' Kerberos Tickets on other Windows or Unix machines to gain access to systems and services
  • Dump clear text passwords stored by Windows authentication packages

 Now maybe it's just me, but there are a few terrifying points there. It can steal plaintext passwords, it can steal passwords from domain users, and it can steal Kerberos tickets to access other systems. If an attacker compromises your system, it's more "game over" than ever before.

This can be done two different ways: either inject code into the LSASS.exe process and call the MSV1_0.dll function GetPrimaryCredentials() or reverse engineer that function and implement it entirely in another process. Both cases are completely OS independent (as far as current Windows releases go), but the first one may be unsafe because if it crashes the entire system crashes.

This tool supports all current versions of Windows. I tested it myself on Windows 8 64-bit, and it worked beautifully:--

C:\Users\ron\Desktop>wce.exe -w

WCE v1.41beta (X64) (Windows Credential Editor) - (c) 2010-2013 Amplia
Security - by Hernan Ochoa ([email protected])
Use -h for Help.

ron\WINDOWS8:iagotest8

 C:\Users\ron\Desktop>

I also tested it on a Windows 7 domain-connected machine, and it worked there as well with the domain account. It would also be trivial to have a domain administrator connect to my machine to steal his or her password.

And that sort of calls out the one drawback to this tool. It requires a user to be actively logged into the host.

Anyway, that's all the info I can give. For more information, here are notes from an in-depth talk on all its inner workings:

http://www.ampliasecurity.com/research/WCE_Internals_RootedCon2011_ampliasecurity.pdf

And here's a guide on using it for post exploitation:

http://www.ampliasecurity.com/research/wce12_uba_ampliasecurity_eng.pdf

 I hope you guys found that as interesting as me. See you at the next conference!