Tuesday, November 29, 2016

As we all know, there's no shortage of hoaxes on the Internet. After writing about election hacking the other day, someone responded to me that hacking has already been demonstrated and offered this YouTube video as proof. The video was produced by Bev Harris from blackboxvoting.org.

The guy in the video who is supposedly a computer savvy professional explains that the reason he's sure the GEMS election reporting software is subject to hacking because votes can be counted in fractions. The proof? The database schema can support integer, single precision floating point, or double precision floating point for the vote counts. Sure, storing integers a as a float is stupid from a space perspective, but the fact that the schema allows for it isn't malicious by itself.

Do people take this seriously? Um, unfortunately yes...

He shows in the video how he can write software to restrict voting to a particular percentage by using fractional votes. But there's a chicken and egg problem here - how do you get access to this data in the first place and is there an audit trail? Also, sure you can do math with floating points given the access they demonstrate, but you could do it with integer votes too. Further, the idea that the GEMS election tally system would allow for single and double precision floating point is a feature. Some areas of the world do Cumulative Voting so this would be one way to store that data.

But besides common sense, how do we debunk something like this? Well, examine the video at around 10:10. The supposed computer expert explains single and double. He explains that a double can use between one and two decimal places and a single can use between zero and one (or something to that effect). He has no idea what these terms mean. Wikipedia has a better idea of what a double precision floating point number is. But that's the problem. Many will see this video and the supposed demonstration and be fooled because they have no idea what this "savant" is doing.

Sunday, November 27, 2016

Regardless of your political position, the upcoming voting recounts and e-voting audits are almost certain to spurn some feelings in every American. I personally don't have a dog in this fight, but I find the prospect of a post election audit of e-voting machines to be fascinating.

Every four years we criticize the security of the e-voting machines without actually doing anything about it. And security pundits talk about the risks. Some even demonstrate how the machines can be hacked (side note, I think the Cylance demo just days before the election was a reckless publicity stunt). Despite all the talk, to my knowledge we've never had a post-election audit of the e-voting system. Now that's a possibility and I for one couldn't be happier. I could even argue that with the US intelligence community openly blaming Russia for attacks, there's never been a better time to perform such an audit.

I'm most interested in the prospect of doing forensics on the voting machines and the computers that program, read, and report results from those machines. Many talk about how the voting machines are airgapped. But they all receive commands and ballots from some other machine on the network (many via PCMCIA cards). And let's not kid ourselves about the security of the machines used to program the ballots on the e-voting machines. Michigan can't even get the lead out of the water in Flint. How much attention and budget do you think they've been paying to the computer security of their election commissions? I'd bet the money in my pocket that I can be on the controller of at least one election district machine before the week is over. Any competent nation state can do it too.

This week, I'll blog about some of the complications of the audit from a DFIR and CTI standpoint.

For now I think it's interesting to consider a more important point of attribution. Suppose that the audit uncovers widespread compromise of e-voting machines or their controllers. What then? Cyber attack attribution is difficult in the best of circumstances. But in this case we've telegraphed our intention to audit the systems and in doing so have given any potential adversary time to cover their tracks. As we regularly tell clients at Rendition Infosec, it's nearly impossible for an adversary to completely cover their tracks and make it appear that an intrusion never took place. But anti-forensics techniques definitely complicate attribution.

Do you have some thoughts on how attackers might have covered tracks? Unique DFIR or CTI angles I haven't considered? Hit me up on Twitter using the hashtag #DFIRrecount and get the conversation going.

Tuesday, November 22, 2016

Yesterday Kris Kobach met with the president elect about plans for the Department of Homeland Security. The two posed for a photo after the meeting and that's where things get interesting.

Notice that although Kobach has a folio with him, he is carrying papers outside it. In today's world of high resolution photography, the words on the paper are clearly visible.

When we do penetration tests at Rendition Infosec, I find a tremendous amount of value in publicly available photographs. Sometimes these are pictures of employee badges (yes, Rendition has a badge printer). Other times photos reveal information about internal building layouts and other information that gives us an edge while pretexting in social engineering. In any case, this is a great example to remind your employees to be careful when cameras are around.

Monday, November 21, 2016

With many important things depending on time (think Kerberos), NTP is an important but often forgotten component of your network. Because the NTP daemon for Linux is relatively lightweight, it's rare for bugs to pop up in such a common service.

But a new bug has been found in the NTP daemon. It allows a single packet denial of service condition which can be exploited remotely without authentication. To make things more interesting, there's a trivial proof of concept exploit available. The exploit it CVE 2016-7434 and the exploit and advisory are linked here.

At Rendition Infosec we always recommend clients apply the latest patches. But in this case, that may not be possible. NTP runs on many embedded products and on many of those products it can't be patched. Some network appliances have fallen out of support with vendors or vendors may simply be slow to provide a patch. In those cases, restricting access to NTP from unauthorized locations may be your only recourse. If your network isn't architected for defense in depth, maybe now is a good time to consider what changes you can make today that will make defense tomorrow easier.

Sunday, November 6, 2016

Forensics doesn't work like you see on NCIS where Abbie does the impossible and does chip off and data recovery to get done with the case in time to make an arrest. Malware reversing doesn't work like you saw in CSI: Cyber where you just drop the code in a hex editor and the exploits and malware are just colored red (on a green background). Terrorists can't really take down the whole air traffic control network, but if they could, I wouldn't drive down the runway in a Porsche to download the software.

Forensics is technical and hard. It doesn't happen in the span of a single hour long show. While you've probably heard that nothing is EVER deleted, that's not really true. The more time that goes by between a deletion and the investigation, the less likely I am to recover anything. Think about that "The First 48 Hours" show you like so much. Sure, most of the time police get called right after the murder and get a fresh crime scene. But remember that episode where the police get called to a vacant lot months after the murder happened? That murder scene was fresh once too, but not when the police got there.

Forensics is (usually) a lot like that episode. Instead of getting a fresh crime scene, there was a thunderstorm that washed away some blood evidence. Some drunk college kid came by and urinated on the ground near the body. A young girl saw something shiny in the lot while walking home and removed a shell casing because it was "pretty" and she wanted it for her dolly. Three hoboes having an orgy came through and moved the body to use it as a mattress. The crime scene is a mess. Yeah, forensics is a lot like this crime scene - it's just a mess.

But for all the bad, forensics isn't all manual either. I'm not individually looking through each file on the system looking for keywords in your documents. I don't manually search through your browser history either. There a number of sites I don't ever want to see your password for. What investigative value could your saved password for Amazon have? The only value I see is you accusing me of purchasing something on your behalf. I have filters to remove this sort of private information.

And if you have tens or hundreds of thousands of files (say for instance emails) I'm going to use automated tools to reduce this number to something I can manually examine. All the interns in the world won't be able to cull through a hundred thousand emails in a timely fashion. I'm going to sort files into four bins:

Files that match a certain keyword of interest (blacklist)

Files that match a certain keyword you DON'T want to see (whitelist)

Files that contains words from the whitelist and the blacklist

Files that don't match anything

Depending on the parameters of my investigation, I might only look at those files that match the blacklist words. In other cases, I'll also examine those that match both the blacklist and the whitelist. Often, this second category is investigated by another independent investigator since items on the whitelist are often very sensitive. Even for documents that match my search terms, there may be many that are well known (matching cryptographic hashes to known files or files I've already examined). Using this method, I can get through tens of thousands of files quickly, providing my search terms are correctly defined.

So Mom, I opened this post by telling you about forensics works of fiction like CSI: Cyber, NCIS, and Scorpion. I'd like to help clear up another fictional forensics story. We both know the FBI has recently undertaken a very high profile forensic investigation involving large quantities of email. The FBI claims to have investigated all of the email and cleared the suspect. Some people have trouble understanding how this can happen so quickly (even though they apparently believe the timelines on NCIS, it's still on the air). You mentioned this to me today in a phone call and I'm going to set the record straight. You also know this isn't politically motivated since you know I'm nauseated by both candidates.

Let's examine a few facts about the recent FBI case:

The computer was never used by the subject of the investigation

There are 650k emails on the suspect machine

The number of emails in the 650k that match the blacklist is probably very low compared to the overall number of emails

Some number of these emails on the blacklist may have already been examined in a previous investigation

Considering these facts and knowing how email and files are processed in forensics investigations, it's completely possible that the FBI processed 650k emails for the context of this investigation in this timeframe.

Mom, it's fine if you want to distrust the FBI. A little distrust of authority is actually probably healthy. Say that the FBI is actively covering something up. Say that if they release the emails, Putin will start WW III. Say whatever you want, but don't subscribe to the "FBI couldn't have done it this quickly" narrative. It's not only wrong, it's provably wrong.

Also: Mom, I love you.

* For the person who hit me up on Twitter assuming that I was picking on all moms with this post, let me set the record straight. My mom, a great professional nurse, nursing administrator, etc., has a complete lack of understanding about technology. I honestly wrote this post in response to one of her shares on Facebook that highlighted some mistruths re: forensics.

A researcher identified only as Tea Leaves disclosed that he had access to passive DNS logs from one or more ISPs. Using this DNS data, he can see who is communicating with who (as long as they use domain names to communicate). I'm going to ignore the obvious ethical issues of disclosing private data in this post (more on that later). I'm also going to avoid the fact that the conclusions of the slate.com story have been debunked.

I do think it's worth discussing what researchers could do with ISP grade passive DNS data so you understand what can be done with it if someone were to abuse the data. You should know that most researchers with passive DNS data only see that resolutions occurred, not the specific IP addresses that made the requests. It is this unique data that allowed Tea Leaves to make the Trump server "conclusions."

A few things you could do with similar data:

See all the websites you visit and attribute these visits to you specifically and what times you visit them

Find out what antivirus software and other third party software is used in a corporate network

Discover a publicly traded company that has been compromised by malware and short their stock

I'm sure there are some other ideas out there, this is just a partial list to get you thinking. Yes, please tell me this is why you use a VPN. I'll say that's better, but doesn't in any way minimize the seriousness of what Tea Leaves did. Also, anyone with ISP level data access can tell when you are using a VPN and then look for DNS leaving that location as well. Sure there may not be a 1:1 correlation between a particular DNS request and you (others could be using the VPN server) but given enough data you can probably paint a pretty complete picture.

Malware researchers need access to this data at an ISP level - there are some very important benefits here that help keep the Internet safe. But in order for this data to continue to be shared, we have to police our own community. We can't prevent researchers from leaking privileged data (even NSA and FBI can't seem to stop this). But we can actively dox and shun those who abuse their positions of trust.