Recently in Security Category

Dancing madly on the lip of a volcano



John Oliver spent 18 minutes discussing the latest iteration of the crypto wars sparked by the recent Apple v. FBI case. In his summation, he provided a fantastic metaphor for cybersecurity, "dancing madly on the lip of a volcano". I think this metaphor is especially pointed as we see a greater increase in regulatory intervention by bodies with very limited views or education into security. There is no global consensus on cyber security and the house is on fire as of late.  

Security researcher Matt Blaze (@mattblaze), who was featured in Oliver's piece, tweeted the following:


PrivacyWonk moves to TLS (finally...)

After waiting for what seemed like an eternity, the site finally has a Let's Encrypt certificate!

I took some time to setup TLS properly this evening (total project time: 2 hours), following fantastic guides from Mozilla and other sources (WeakDH.org, Qualys SSL Server Test, and Scott Helme's SecurityHeaders) ensure a secure and modern implementation. See reports below.

Was this necessary for a site that simply serves up my idle thoughts on privacy and security? Absolutely.

Why?

Because if I can do it for my little blog serving an annual readership of 20k (most of which are SEO spammers), you can do it for your web app that collects, uses, and disseminates data. 

It's 2015, it's time for this level of encryption and site protection to become the new normal. Invest in AppSec, invest in Security Engineering, and invest in the trust of your customer or reader.

--------------------- 

Qualys Report: Yahtzee!

SecurityHeader Report: Content-Security Policy and Public-Key-Pins will be future projects for the site


IP analysis shell function

Brian Warehime of nullsecure.org published a new threat intel piece, walking his readers through his analysis of incidents captures through his honeypot. The entire post, http://nullsecure.org/threat-intel-web-crew/, is fantastic and I encourage you to read it top to bottom. One snippet I found incredibly useful was a simple bash shell function that saves a great deal of time when performing IP based analysis.


function ipgrab() { read line; echo $line | grep -E -o '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}'; while read line; do echo $line | grep -E -o '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}'; done echo $line | grep -E -o '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}'; }


Drop this into your .bashrc file and invoke it when analyzing files for IP addresses. For example:
cat /var/log/httpd.log | ipgrab > ips.txt


Breach response for the jaded

I heard about the breach at [$COMPANY_NAME$] and the [$BREACH_QUANTITY$] [$DATA_TYPE$ one of "credit card", "patient record", "social security number", "user login", "hashed passwords", "national security secrets", "Hollywood star's 'selfies'"] compromised. Of course this is a serious matter and is the largest since [$YESTERDAY_DATE$]

The people at [$COMPANY_NAME$] have not yet released details, which is appropriate given an incident response of this magnitude. I understand that they have the [$RESPONDER_NAME$ multiple of "FBI", "NSA", "CIA", "Mandiant", "army of consultants", "Keystone Kops"] involved and have issued a press release.

My guess is that the attackers were able to initially breach the target using a [$ATTACK_TYPE$ one of "phishing attack", "brilliantly clever targeted phishing attack", "piece of custom malware", "cat with a WiFi interface implanted in its head", "SQL injection attack", "basic website vulnerability", "army of ninjas", "variant of Stuxnet"] which is [$UNEXPECTED$ one of "totally unexpected", "the way it usually happens", "innovative", "obscure as hell", "bloody typical"] form of attack that is often used by [$USUAL_SUSPECTS$ multiple of "China", "North Korea", "CIA", "NSA", "Anonymous", "brotherhood of blades", "Bavarian Illuminati", "Trilateral commission", "hackers who have read 'Hacking Exposed'", "any complete newbie"]  Until I know more about it, I can't really guess about the details.

However, this illustrates the basic issues in information security, which is that organizations don't appear to have effective responses to basic malware and/or phishing attacks, and have aggregated critical data into central locations on their networks where it is accessible. Once an attacker gets inside, it is pretty easy for them to escalate privileges, find out where the data is, and exfiltrate it. Organizations with critical data should segregate it off their network, perform regular vulnerability audits and remediation, maintain detailed system logs, and use two factor authentication for administrator access. If it's a large organization, Big Data also helps, but I am not sure how.

Sony hack commentary

Vice has a great interview with Peter Singer. Singer makes some excellent points, especially when it comes to applying the word terrorism to the Sony pictures hack.

The FBI's definition of terrorism is as follows:
18 U.S.C. ยง 2331 defines "international terrorism" and "domestic terrorism" for purposes of Chapter 113B of the Code, entitled "Terrorism":

"International terrorism" means activities with the following three characteristics:

  • Involve violent acts or acts dangerous to human life that violate federal or state law;
  • Appear to be intended (i) to intimidate or coerce a civilian population; (ii) to influence the policy of a government by intimidation or coercion; or (iii) to affect the conduct of a government by mass destruction, assassination, or kidnapping; and
  • Occur primarily outside the territorial jurisdiction of the U.S., or transcend national boundaries in terms of the means by which they are accomplished, the persons they appear intended to intimidate or coerce, or the locale in which their perpetrators operate or seek asylum.*

Calling what happened to Sony terrorism cheapens the idea of terrorism for those who have suffered violence. The 132 children who were recently killed by the Taliban in Pakistan were victims of terrorism. Their families were victims of terrorism. What Sony is suffering from is embarrassment.

NB: Above, I am speaking solely of The Hack. Ensuing threats of violence from the Guardians of Peace certainly fall into the definition. But again, as Singer points out: is there capability to follow through with said threat?

Sony's label of "cyber terrorism" is being echoed by organizations like the MPAA who sent out this gem of a Press Release:
"The FBI's announcement that North Korea is responsible for the attack on Sony Pictures is confirmation of what we suspected to be the case: that cyber terrorists, bent on wreaking havoc, have violated a major company to steal personal information, company secrets and threaten the American public. It is a despicable, criminal act.

Disappointingly, that fact has been lost in a lot of the media coverage of this over the past few weeks. This situation is larger than a movie's release or the contents of someone's private emails. This is about the fact that criminals were able to hack in and steal what has now been identified as many times the volume of all of the printed material in the Library of Congress and threaten the livelihoods of thousands of Americans who work in the film and television industry, as well as the millions who simply choose to go to the movies. The Internet is a powerful force for good and it is deplorable that it is being used as a weapon not just by common criminals, but also, sophisticated cyber terrorists. We cannot allow that front to be opened again on American corporations or the American people" [emphasis added].
 
Which is it? Terrorists or criminals? These are dangerous waters being waded into in describing the hack. 

Was Sony at fault for this?
An acquaintance recently summed up some philosophical nuances: "...there is an important moral difference between 'creating a situation with a predictable effect they should have foreseen' and 'asking for it' or 'inviting it.' The latter phrases mitigate the immorality of the attackers, as if it makes it less wrong to do something predictably wrong. If you 'invite' or 'ask for' something you are condoning it. If you just stupidly leave yourself open to it, you are responsible for being stupid, but not for the wrong act that results."

DPRK (official according to FBI) is 100% at fault for the morality of their actions, i.e. that they were wrong. Sony is the victim. 

Now, let's talk about the responsibility Sony had.

Sony had a responsibility to their employees and shareholders to protect their personal and intellectual property. They had a responsibility to identify, understand, and operate within their threat environment. Sony failed to uphold that responsibility in an epic and very public fashion. Sony has not acknowledged this failure. "Being a victim is more palatable than having to recognize the intrinsic contradictions of one's own governing philosophy." ? Tom Clancy, The Hunt for Red October

Sony has chosen a response I certainly would not have advised had I been standing in their incident response room. Singer calls this the 'lose our shit' mentality, "[t]he reality is we can either choose a 'lose our shit' mentality, or we can choose a mentality that is far more successful, which is focusing on resilience." 

Perhaps Sony can stop losing their shit and focus on resilience.





Cybersecurity as Realpolitik by Dan Geer

Dan Greer delivered the following speech at this year's (2014) BlackHat. The video and text are presented below. I have republished the text below but edited from original text format to be a bit more readable and printable.



[ nominal delivery draft, 6 August 2014 ]

Cybersecurity as Realpolitik
Dan Geer


Good morning and thank you for the invitation to speak with you today. The plaintext of this talk has been made available to the organizers. While I will not be taking questions today, you are welcome to contact me later and I will do what I can to reply. For simple clarity, let me repeat the abstract for this talk:

Power exists to be used. Some wish for cyber safety, which they will not get. Others wish for cyber order, which they will not get. Some have the eye to discern cyber policies that are "the least worst thing;" may they fill the vacuum of wishful thinking.

Privacy and security folks rely on encryption as a means to ensure the confidentiality and integrity of information, protecting it at rest and in transit. But what happens when a fundamental control is thoroughly compromised? When a protective control becomes an attack vector? How should we react?

It is critical to note that proof of concept exploit code is already in the wild. This is not a theoretical emergency.

Today, we should be activating Incident Response Plans (or screaming, loudly, with hair on fire) within our organizations to do the following:
  • Identify all external and internal sites using SSL/TLS
    • This could be a website, API interface, e-mail connection, VPN concentrator, etc.
  • Check if they are vulnerable 
    • There are a few sites offering to "check if you're vulnerable" ; however, don't rely on them. They could be actively exploiting you and you wouldn't know it. Keep it in house.
    • Note for above: your client must support 'heartbeat' otherwise you will get false positives.
    • Find one of your system admins and have them conduct a check:
    • The following command (or something similar) can provide quick feedback (replace google.com with the target server)
openssl s_client -connect google.com:443 -tlsextdebug 2>1 | grep 'server extension "heartbeat" (id=15)' || echo safe
  • If the site is not vulnerable, celebrate. You've avoided the heartbleed problem but...
    • Don't celebrate too hard, it likely means you're running a very old OpenSSL version and are vulnerable to many other issues.
  • If the site is vulnerable, do the following:
    • Patching affected systems to OpenSSL 1.0.1g
    • Update any other dependent software/hardware
    • Procure new certificates
    • Revocation of the old keypairs that were just supersceded
    • Changing all passwords
    • nvalidating all session keys and cookies
    • Evaluating the actual content handled by the vulnerable servers that could have been leaked, and reacting accordingly
    • Evaluating any other information that could have been revealed, like memory addresses and security measures
    • Ensure all end-user browsers all check Certificate Revocation Lists, this functionality is generally off by default
Updating certificates will cost you money. However, the risk is that your site has already been compromised before you remediated the risk. If someone has your private key, you're forever compromised until you replace the certificates. Since, as of writing this, you cannot tell if you've been compromised or not, it is much better to err on the side of caution and spend the money replacing your certificates. 

In some cases, hardware based platforms will not have a quick fix for this vulnerability. You should have conversations with your IT, Business, and Security Operations people. Investigate the possibility of unplugging that piece of hardware, depending on how critical it is, until it can be fixed. This is a big decision and trade offs will need to be understood thoroughly. However, the gravity and seriousness of the heartbleed situation should be clearly communicated. This is the fire drill we never really wanted to have.

-------------------------- Background on OpenSSL and vulnerability --------------------------

OpenSSL (wikipedia) is an open-source implementation of the SSL and TLS protocols. The library is supported on multiple OS platforms (Unix, Windows, etc) , multiple connection types (web, email, VPN, XMMP chat, APIs, etc.), and is extensively used. Trust me when I say, it's in your environment. Likely in many places. Specific OpenSSL versions have a vulnerability that can completely compromise all information transmitted over the connection, rendering the protection moot. The vulnerability allows for compromise of the private keys on the server side. The attack, so far, is not detectable. This is very, very, bad.

Questions? Concerns? Comments are welcome below and on twitter @PrivacyWonk.

Security Advisory from OpenSSL - https://www.openssl.org/news/secadv_20140407.txt

OpenSSL Security Advisory [07 Apr 2014]
========================================

TLS heartbeat read overrun (CVE-2014-0160)
==========================================

A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
preparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.0.2 will be fixed in 1.0.2-beta2.
Additional Sources:

Humor:

Adam Shostack and Threat Modeling

Adam Shostack (@adamshostack) discusses Threat Modeling on Mozilla Air. Excellent presentation (so far)

Generating keys and CSR requests for your Public Key Infrastructure (PKI) needs is tedious and annoying without proper tools. Remembering openssl commands and syntax requires a constant visit to the man page or the googles. So what does any good geek do when faced with a repetitive problem? They write a script or download a tool. I wrote a script because I love reinventing the wheel.

The script below (after the jump) creates a customized openssl config file and generates private keys and CSRs. The input to the script is a flat file with either FQDNs, email addresses, or whatever your want that is plugged into the Common Name field of the key/CSR. The script is nothing more than a glorified for loop that helps reduce errors and ensures consistency across a large key base.

This can be really useful when setting up EAP-TLS for your WiFi or other device authentication.

Please leave any feedback you may have in the comments.


Why biometrics are bad authenticators

The Chaos Computer Club, a Germany based hacker collective with a rich history of publicly demonstrating security risks, published an article describing how it had broken the new iPhone Biometric authentication service. They used tools and techniques originally developed in 2004 to fool the iPhone fingerprint sensor. 

"The biometrics hacking team of the Chaos Computer Club (CCC) has successfully bypassed the biometric security of Apple's TouchID using easy everyday means. A fingerprint of the phone user, photographed from a glass surface, was enough to create a fake finger that could unlock an iPhone 5s secured with TouchID. This demonstrates - again - that fingerprint biometrics is unsuitable as access control method and should be avoided."

The CCC hacker Starbug, who conducted much of the biometric research, said in 2007, "As we have said now for more than years, fingerprints should not be used to secure anything. You leave them everywhere, and it is far too easy to make fake fingers out of lifted prints."