Showing posts with label cryptography. Show all posts
Showing posts with label cryptography. Show all posts

Sunday, November 30, 2014


When UNIX co-progenitor and super-smarty-pants Ken Ritchie was given a Turing Award, he provided a warning to those within ear shot. Admins and developers often find it satisfactory to review the source code of applications to determine maliciousness. And to a certain extent, this works out all right. Over time we have built a series of expectations of where to expect naughty code based on our experience. We have also chosen to trust other types of tools that we use during this process. We discriminate.

But there's no reason that bad stuff *has* to be in the applications that we expect to find it in. Yes, the clever among us know that compilers can be bad. But we check the source of our compilers and find no bad stuff, and so we assume we are safe.

We do, though, compile the compiler, don't we?

Well, alright then some megalomaniac at Intel or somewhere far upstream decided to embed badness in the embedded distro compilation software. We can still look at the binary of compiled programs to determine What Is Really Going On.

We do, though, tend to use applications to help make machine code human readable, though, don't we?

The point to the thought experiment isn't to stop the unbelievable interchange of ideas and applications that has brought us to where we are today in modern computing. It would be impossible to manually read the machine code of all of the applications that we use and still function in the workplace and our other communities as we are expected to.

Rather, we should be aware of the trust that we place in our tools. We should be aware that when we set out to solve or review problems, we take certain things for granted.

The point is not, that we should never trust. The point is that we should make trust decisions willfully and based on reasonable deductions and facts; not impulse or ease of use.

I came across Ritchie's chat today in a CS class, and its still as relevant today as it ever was. You can read the whole thing here.

Sunday, October 12, 2014

NSA Targets Systems Administrators with no Relations to Extremism

The Details

This is a bit of an old story, but I've found to my unpleasant surprise that the issues surrounding the story are not widely understood or known. Here's the gist: leaks from the US intelligence service have explicilty confirmed that the NSA targets systems administrators that have no ties to terrorism or extremist politics. If you are responsible for building and maintaining networks, the NSA will place you under surveillance both personally or professionally; they will hack your email, social network accounts and cell phone. The thinking behind this alarming strategy is that compromising a sysadmin provides root-level access to systems that enable further surveillance; hack an extremist's computer, and you track just that extremist. Hack a sysadmin's computer, and you can track thousands of users who may include extremists among them (its a strategy that is remarkably similar to the targeting of doctors in war zones).

Five years ago such a lead paragraph would be among the most wild-eyed of conspiracy theories. Now, after the Snowden leaks and the work of other sources within the US Intelligence community, the sysadmin targeting scheme has been proven conclusively through supporting documents circulated through a "wiki" style system within the NSA and explained and reported by Ryan Gallagher and Peter Maas of The Intercept. The name of the scheme is I hunt sys admins. The entire document outlining the goals and methods of the I hunt sys admins scheme is available on The Intercept (While I typically publish source documents directly on this website for ease of use, publishing these documents present unique legal concerns that The Intercept is better equipped to handle - I apologize to users for the inconvenience of having to visit a second site to confirm sources but I assure you it is well worth the effort).

There are a few excerpts worth noting explicitly. First and foremost, the document describes that the surveillance typically begins by acquiring the administrator's webmail or Facebook account username. The NSA agent then uses an Agency tool called QUANTUM to inject malware into the admin's account pages. The Intercept has put together a video outlining the QUANTUM tool's capabilities that is worth watching. The existence and capabilities of the tool are themselves also confirmed through extensive NSA documentation. QUANTUM uses a Man-On-The-Side attack to hijack user sessions and redirect traffic to one of the NSA's Tailored Access Operations (TAO) Servers. In this case, the application server used is called FOXACID. The same application is used to compromise Firefox and Tor users (a related program in place at Britain's GCHQ called FLYING PIG offers similar functionality even while using SSL).

QUANTUM has a variety of different uses besides the one outlined above. QUANTUM has a series of plugins that allows NSA agents to take control or IRC networks, compromise DNS queries, run denial of service attacks, corrupt file downloads and replace legitimate file downloads with malware payloads.

The methodology is important as it demonstrates the importance of maintaining operational security even during personal time. These are not attacks that target political or military organizations; they do not even target corporations. They explicitly target individual system administrators.

And there's more.

NSA Agents use the tool Discoroute to retrieve router configurations from passive telnet sessions. NSA documents outline how, rather than use sysadmins to target the corporations they work for, NSA is interested in doing the reverse - using corporate router configurations to target individual sysadmins. For example, using Discoroute, a surveillance agent retrieves the access-list ruleset associated with the router. Using that access-list can reveal home IP addresses that admins use to login to systems remotely. While this may seem to be an egregious security oversight, the access-lists in question are not necessarily for core routers. The access-list could just as easily be retrieved from a PIX; an IP used to allow access to an intranet website.

The I hunt sys admins documents continue by outlining some methods to identify and surveil malicious users. The author of I hunt sys admins references the NSA's access to massive untargeted recordings of SSH sessions. Perhaps we can take some security in that the author apparently does not take it for granted that the NSA can easily decrypt SSH session data. However, quite a bit can be accomplished by analyzing encrypted data. In this instance, I hunt sys admins recommends reviewing the size of SSH login attempts to determine which are successful and which are failed. IP addresses which are recorded failing multiple attempts to large numbers of IPs can safely be identified as belonging to brute force attempters.

Why You Should Care About NSA Surveillance Even if You Do Not Care About NSA Surveillance

This is a website about technology; not politics. Whatever your opinions are about the legitimacy or warrantless surveillance, the actions of the NSA and the other Five Eyes surveillance agencies are having a significant and deleterious impact on the internet and those who build and support it. Additional leaks have demonstrated that NSA provided security firm RSA with $10 million to use the flawed Dual_EC_DRBG random number generator in its unfortunately-named BSAFE cryptographic library, providing a back door to all applications relying on BSAFE. Even more disturbing are confirmations that the NSA has obtained copies of root CA certificates and used them to compromise SSL implemented by major internet services.

But why should we care? I'm not guilty and so I have nothing to hide, as the oft-used rationalization goes. Warrantless surveillance by governments is only one consequence of the actions outlined above. Chief among concerns for the admins targeted by these policies that are unconcerned with government surveillance is that actors other than the Five Eyes nations can easily engage in the same practices as explained in the I hunt sys admins documents; frankly, few if any of the I hunt sys admins guidelines were actually invented by NSA. These are techniques designed by criminals, and criminals have massive incentives to continue innovating those techniques. To protect our privacy from criminals we must follow security best practices, and by following best practices we necessarily protect ourselves against government surveillance as well.

The fact remains that sysadmins will remain a desirable target for those seeking to break into protected systems. Protecting those systems and the users who depend on them is part of our mandate as administrators. Now that we know the extent to which the security environment has changed, the question becomes whether we continue to adapt to the new environment to best protect our applications and users, or whether we disregard our mandate.

Wednesday, September 19, 2012

More Fun With PCI

I received a notification from a large security auditing firm that of the ciphers currently available, only RC4 ciphers will be considered PCI compliant.

My assumption based on the notification is that this move is intended as a rejection of CBC (Cipher Block Chaining). Well, that's fine as far as I am concerned. CBC has some serious issues as implemented in SSL v3 / TLS v1.0. In a nutshell, you can time responses for applications using the block cipher to get ranges of possible data in SSLv3 and partial payload decryption in TLS. So-called "stream" ciphers like RC4 are immune to this particular attack vector. You don't get private keys from the attack, its by no means a fast attack (minimum of three hours), and you need access to monitor the session. Further, patches for CBC exist to over-ride the timing exploit (for example the NSS libraries used by Mozilla have been patched).

I will save debunking the man in the middle hysteria for a later post. What frustrates me about the requirement of RC4 stream ciphers for PCI compliance is not that CBC ciphers are no good - they are weak - it is the notion that somehow RC4 is somehow sufficient. Some points to consider:

-RC4 exploit using SSH with null password prevention enabled

-RC4 is frequently implemented poorly within applications other than sshd, for example by using poor to no random number generation

-Successful attack vectors exist, but they have yet to be put into a helpful graphical interface for use by your neighborhood teenager (as the BEAST framework did for CBC). Paul and Maitra published on RC4 key reconstruction techniques in 2007 (Permutation after RC4 Key Scheduling Reveals the Secret Key. SAC 2007), based on keystream byte assignment biases first published by Roos in 1995. This means, unlike CBC, there is a published algorithmic approach to full private key decryption of RC4. 

It cant be stressed enough that all of these vectors assume an attacker on your wireless or local network. If that is the case than SSL is the very least of your problems. While theoretical dismissal of this or that cipher based on penetration ability is sound and valuable, the PCI standard suggests a holistic approach to security. The various levels of PCI-DSS compliance suggest admission of the reality that the goals of securing a system will differ based on the purpose of that system. Banning the use of CBC will not serve to get less sites hacked, but it will keep administrators preoccupied with yet more busy work, switching from one cipher with published flaws to another cipher with published flaws.

Sunday, April 29, 2012

Phil Zimmerman's Latest Project

Phil Zimmerman of PGP Encryption fame is launching a new project, Silent Circle -  The idea is an application suite complete with encrypted VOIP, email and IM. Exciting stuff! Lets hope it works out better than Hushmail!

Wednesday, April 18, 2012

Random Number Generation

Latest Update from Basement Dweller News:

A great primer on random number generation from a few smart cookies at Intel, by way of IEEE:

On a very related note, let's keep our eyes on systemic issues with encryption keys in the wild:

I have yet to formalize an opinion as to the validity of any systemic key issues intrinsic to RSA (because I was a "D" math student I have to wait for the grown-ups to weigh in on these Deep Thoughts. I would like to see larger keys in use standardized and don't see any good reason not to)

A compelling critique of the survey, urging for additional data before judgment is reached:

RAT Bastard

Earlier this week, several servers I maintain were targeted by automated attempts to upload a remote access trojan (RAT). The RAT is a simpl...