Tag Archives: hacking

Honest review – CSI:Cyber

There seems to be a lot of chatter (at least on my highly biased Twitter and Facebook feeds) about how terrible of a show CSI:Cyber was. People seem to be extremely concerned about the fact that the show did not portray all the hacking related activities (cyber, infosec, whatever you want to call it) precisely as it is in real life. So here’s my take at it.

First – I’m not talking about the overall quality of the show. I’m not a TV critic, and I’m not going to go into the casting choices, the bad acting, the hollow and predictable script or any of the cinematographic elements. Let’s just focus for a second on what irks people the most – cyber.

So let’s talk about some (again some!) of the technical elements that show up there:

1. Hacking into baby cameras. Totally true. http://www.cnet.com/news/hacker-shouts-at-baby-through-baby-monitor/

2. Social media being a major source for intelligence. Been using it for a decade now through red teaming. Actually joined a social risk management company as it’s that big of an issue. (www.zerofox.com)

3. Social engineering – micro expressions, cold reading, etc. Legit. Again – red teaming. We even teach it on our red team classes.

4. The camera ball used to survey a site before entering it. http://bounceimaging.com/

5. Usage of malware (RAT) to spy on people. Welcome to the last 17 years of my professional career. And yes – you can buy this on the “surface web” (WTF – can’t you just say Internet?). Blackshades used to go for about $40-$50 a pop as far as I recall (and no, not going to do the homework for you and link to a live site that sells this. Google it.).

6. Companies that release products with known flaws in them? Yeah, you are probably reading this from one of those. Welcome to reality, where business decisions trump technical purity and security. Companies want to make money. Fast. If fixing all the flaws found in the software or hardware will keep them from making money, guess what – they will prioritize these to a point where they can get $ in the bank.

And yes – there where some highly amusing things where the artistic license was taken very liberally. Malware showing up in the code as red letters (vs. the traditional green on black). Fingerprints taken from a scene of a crime using an “Expensify” like app – quick snap of the phone’s camera, and within seconds you got a match with full profile and mug. Tracking every IP address to a physical location and swatting it within minutes. A teenager that needed help on a console game from a 30-something year old FBI agent. Having an online bidding that consists of basically a conference call conducted in multiple languages (nobody has time for this – it’s all going to be done through IM’ing, and on dedicated forums). And the list goes on… no regard to the judicial process, medical examinations that are beyond absurd, taking an hour to drive from DC to Baltimore, but from Baltimore to upstate New York in minutes just to get to the drowning car so that the baby can be saved.

Am I hearing my lawyer friends going crazy on the lack of judicial process? About the deal that put a convicted felon to work closely with the FBI? (they are having hard time finding good people because they smoked pot FFS)? Nope. You know why? BECAUSE IT’S TELEVISION.

It’s not a documentary.

If it would be, 90% of the show would be someone staring at a debugger on a screen, drinking coffee, eating junk food, and cursing. And then writing a report. I’m sure that’s a blockbuster – call in the writers.

So ease off. Be thankful that this isn’t another Scorpion, and that there are enough elements in the script based on reality, kick back, take a load off and watch your entertainment on TV. If you want more accuracy – feel free to watch the hundreds of videos from conferences like BlackHat, Defcon, Derbycon, etc. You’ll get educated. Can’t promise anything about entertained though 😉

Oh. here’s a bonus for you if you thought that the image above was cool – my desk is much simpler 😛2015-03-05 10.43.43

 

Getting things right goes a long way when you are bleeding

I’m starting to see a trend here with the weekend posts. I can stomach most of the FUD during the work days, but things get to me through the weekend. Oh well. There goes a “mandatory” heartbleed post:

Yes, it’s a bad one. No it’s not the worst one. And no – the sky isn’t falling, and the Internet isn’t about to go away.

Heartbleed was one of the most media driven (and ready) bugs in a few years. Logo, website, clear message, and two XKCD strips. The last of which is probably the best explanation to laypersons of what it’s all about.

And did the media catch up on it. Oh yeah… The usual naysayers, FUD-spreading evangelists had their 3.5 minutes of fame. And everyone started recommending that users immediately change their password.

Or maybe not. No! Wait until the site fixes their SSL implementation. Or yes? Ummm, what to do?… That’s where things get interesting.

The real issue here is this: sites affected by heartbleed could potentially be leaking information. And by leaking I mean that anyone with intimate knowledge of the bug could have been, in the past two years, pulling data from those sites. That includes session information, usernames, passwords, and even the private keys used to secure said SSL connections.

Which means that if you think that you were targeted by someone in the past two years, or that your information could have meant something to someone in the past two years with the capability to snoop on those credentials, yes, you should probably do something about it. BUT, and it’s a bug but (yeah, yeah, yeah), you need to remember that it’s not as simple as checking that the website in question has applied the fix. Not even close. If (and again – IF) you believe you need to change your password, you also need to remember that whoever had the knowledge and capability to syphon all that information, was pretty certainly also stealing the server private keys. Initially pundits were skeptical that private encryption keys would be compromised through heartbleed. But as always – if it’s hackable, it will be hacked, and the proof came in pretty quickly.

So yes, there are online tools that will allow you to check whether a certain site had the issue fixed. But these aren’t enough, as you would need to verify somehow (and that’s not easy) that the site also generated a new private encryption key, and got a new server certificate to go with it in to be used AFTER patching the SSL implementation.

Tricky, isn’t it? Yeah, welcome to security…

Anyways – don’t just blatantly go updating your passwords nilly-nelly. First figure whether you really need to, then consider the entire picture: were you exposed just during the time from when heartbleed was announced until the site was fixed? are you concerned about three-letter-agencies that had knowledge of heartbleed and were dumping gigabytes of server RAM so they can get everyone’s data? Then figure whether that site’s private keys and certificates were updated. Then act.

Good luck with that. I’ll leave you with a bleeding heart punch so you won’t need to see that logo AGAIN on a security blog 😛

On BadBIOS and Bad Behavior

So, unless you are in the security industry and have been living under a rock in the last couple of weeks, you probably know what this #BadBIOS thing refers to.

It started when Dragos Ruiu, a highly respected researcher and the founder and organizer of CanSecWest (and PacSec, and EuSecWest) started posting about his exxperience with what seems to be a targeted attack on some of his computing environment:

It started with this post:

IMHO Copernicus BIOS verification tool, (From John Butterworth / MITRE – presenting at PacSec) is one of the most important new security tools in recent history. We’ve already found some persistent BIOS malware that survives re-flashing with it. And that isn’t even the interesting part, the malware seems to have a hypervisor and some kind of SDR (software defined radio) that bridges air gaps, even in laptops with the wifi and Bluetooth cards physically removed. It’s also OS specific, the one we found targets Windows… Time to recheck the OSX boxes too.

Followed by more specific mention of the audio issues that were related to the malware behavior:

So it turns out that annoying high frequency whine in my soundsystem isn’t crappy electrical noise that has been plaguing my wiring for years. It is actually high frequency ultrasonic transmissions that malware has been using to communicate to airgapped computers… one “ghost” located at least. And now we know how the “hypervisor” functions, its probably stored in the realtek firmware, and thats one of the ways it survives reinstalls and BIOS reflashing. Off to find tools to dump the RealTek audio chips, and to try to find clean firmware to compare it to. Haven’t ruled out video firmware yet, either.

And a more comprehensive post circling back to the USB infection vector, and the TTF font files:

More on my ongoing chase of #badBIOS malware. It’s been difficult to confirm this as I’m down to a precious few reference systems that are clean. I lost another one yesterday confirming that simply plugging in a USB device from an infected system into a clean one is sufficient to infect. This was on a BSD system, so this is definitely not a Windows issue.- and it’s a low level issue, I didn’t even mount the volume and it was infected. Could this be an overflow in the way bios ids the drive?

Infected systems seem to reprogram the flash controllers on USB sticks (and cd drives, more on that later) to attack the system (bios?). There are only like ten different kinds of flash controllers used in all the different brands of memory sticks and all of them are reprogrammable, so writing a generic attack is totally feasible. Coincidentally the only sites I’ve found with flash controller reset software, are .ru sites, and seem to 404 on infected systems.

The tell is still that #badBIOS systems refuse to boot CDs (this is across all oses, including my Macs) there are other more esoteric problems with partition tables and devices on infected systems. Also USB cd drives are affected, I’ve bricked a few plugging and unplugging them too fast (presumably as they were being reflashed) on infected systems. Unsafely ejecting USB memory sticks has also bricked them a few times on #badBIOS systems for clean systems, though mysteriously they are “fixed” and reset by just simply replugging them into an infected system. Extracting data from infected systems is VERY tricky. Yesterday I watched as the malware modified some files on a cd I was burning to extract data from an infected system, don’t know what it was yet, I have to set up a system to analyze that stuff.

On windows my current suspicion is that they use font files to get up to some nastiness, I found 246 extra ttf and 150 fon files on a cleanly installed windows 8 system, and three stand out, meiryo, meiryob, and malgunnb, that are 8mb, instead of the 7 and 4mb sizes one would expect. Unfortunately ttf files are executable and windows “previews” them… These same files are locked by trusted installer and inaccessible to users and administrators on infected systems, and here comes the wierd part, they mysteriously disappeared from the cd I tried to burn on a completely new system (a laptop that hadn’t been used in a few years) that my friend brought over which had just been freshly installed with win 8.1 from msdn, with the install media checksum verified on another system.

I’m still analyzing, but I’m certain we’ll ALL have a large problem here. I have more data and info I can share with folks that are interested.

Up to this point, all that was available were Dragos’ accounts of what he’s going through and the assumptions and forensic efforts made in order to uncover what was going on. Shortly after that an article by Dan Goodin was published on ArsTechnica which went through the incident and also mentioned the different assumptions made so far. It’s important to remember that there weren’t any real insights there yet, as the forensic process was not completed.

Nevertheless, the industry exploded. From more sensible breakdowns of the elements mentioned by Dragos – such as Errata’s Robert Graham’s post, to the more popular reaction which was to simply call bullshit on the whole thing and dub it as a marketing effort.

Then came the naysayers, with more elaborate explanations of why this can’t happen, focusing specifically on the parts they felt they had the most experience with – and while at it, completely ignoring what was reported and the context of that part, for example – a great post by Phillip Jaenke focusing on how it would be impossible to deploy a fully functional malwae of this sort solely through BIOS – especially not while utilizing audio functionality straight from BIOS code (of course…).

Now, don’t get me wrong – I’m still the annoying sarcastic skeptical engineer at heart that I am, but seriously – this is still work in progress. Details are emerging as they become available, and frankly I do think that Dragos is doing the best he can to make these available (it’s his reputation on the line after all). Why can’t we either focus on working with empirical data, or just hold on until the entire picture becomes clear? In an industry that is supposed to be highly scientific (I know – I’m also holding on from bursting out laughing when I think of some of the people that made it into the industry when I mention scientific here…), and analytical, there is no room for too much emotions. Definitely not the school-yard bullying kind that some people show (again – love comments such as “i call bull”, and “it’s a fake”. The rigor of these arguments is just awesome). And no – I don’t expect Anti-Virus companies to be able to deal with this (or talk about it yet – at least not until they have their signatures in place…). They can’t deal with simple tools that are being used for pentesting, do you really think they can handle an actual attack?

1401132_10151680012450588_1416577247_n

And yes – this is especially interesting for me, if not only for one (yes, just one) element of this which involves the use of audio to communicate between machines. As if that is anything new – we’ve been doing this with acoustic couplers since the 60’s. I’ve personally been employing similar techniques in red teaming since 2009-2010 (and also published this) – hence my continued interest in tracking down more examples of such uses.

Bottom line – I’m going to keep waiting for more details and data to work with. My personal familiarity with Dragos’ body of work allows me to speculate, but that’s not for sharing publicly. I’m sure that like myself, there are others with narrower and specific interests in other elements of this who have been working on the assumptions surrounding this (either to approve or disprove), and for the love of science – if you don’t have something intelligent to say, just keep quiet.

update: more data keeps coming in for examination from Drags on his Google+

A trip down cyber memory lane, or from C64 to #FF0000 teaming

Reposting this from the original post I put on the IOActive website for the national cyber security awareness month…

So, it’s National Cyber Security Awareness Month, and here at IOActive we have been lining up some great content for you. Before we get to that, I was asked to put in a short post with some background on how I got to info sec, and what has been keeping me here for almost 20 years now.

Brace yourselves for a trip down memory lane then :-). For me getting into security didn’t start with a particular event or decision. I’ve always been intrigued by how things worked, and I used to take things apart, and sometimes also put them back together. Playing with Meccano, Lego, assorted electrical contraptions, radios, etc. Things got a bit more serious when I was about 6 or 7 when somehow I managed to convince my parents to get me one of those newfangled computers. It was a Commodore 64 (we were late adopters at the Amit residence), but the upside is I had a real floppy drive rather than a tape cassette 😉

That has been my introduction to programming (and hacking). After going through all the available literature I could get my hands on in Hebrew, I switched over to the English one (having to learn the language as I went along), and did a lot of basic programming (yes, BASIC programming). That’s also when I started to deal with basic software protection mechanisms.

Things got more real later on in my PC days, when I was getting back to programming after a long hiatus, and I managed to pick this small project called Linux and tried to get it working on my PC. Later I realized that familiarity with kernel module development and debugging was worth something in the real world in the form of security.

Ever since then, I find myself in a constant learning curve, always running into new technologies and new areas of interest that tangent information security. It’s what has been keeping my ADD satisfied, as I ventured into risk, international law, finances, economic research, psychology, hardware, physical security and other areas that I’m probably forgetting in the edits to this post (have I mentioned ADD?).

I find it hard to define “what I like to research” as my interest range keeps expanding and venturing into different areas. Once it was a deep dive into Voice over IP and how it can be abused to exfiltrate data, another time it was exploring the business side of cyber-crime and how things worked there from an “economy” perspective, other times it was purely defense based when I was trying to switch seats and was dealing with a large customer who needed to up their defenses properly. It even got weird at some point where I was dealing with the legal international implications of conflict in the 5th domain when working with NATO on some new advisories and guidance (law is FUN, and don’t let anyone tell you otherwise!).

I guess that for me it’s the mixture of technical and non-technical elements and how these apply in the real world… It kind of goes back to my alma-mater (The Interdisciplinary Center) where I had a chance to hone some of these research skills.

As for advice on to how to become a pentester/researcher/practitioner of information security? Well, that’s a tough one. I’d say that you would need to have the basics, which for me has always been an academic degree. Any kind of degree. I know that a lot of people feel they are not “learning” anything new in the university because they already mastered Ruby, Python, C++ or whatever. That’s not the point. For me the academia gave tools rather than actual material (yes, I also breezed through the programming portions of college). But that wouldn’t be enough. You’d need something more than just skills to stay in the industry. A keen eye for details, an inquisitive mind, at times I’d call it cunning, to explore things that are out of boundaries. And sometimes a bit of moxie (Chutzpa as it’s called in Hebrew) to try things that you aren’t completely allowed to. But safely of course 😉
Hope this makes sense, and maybe sheds some light on what got me here, and what keeps driving me ahead. Have a safe and enjoyable “Cyber” month! 🙂

Seeing RED in your future? – Recap from DerbyCon 3.0

Yes, I know, It’s been a while since I updated anything here. Work, life, etc…

yin and yang

So here’s a quick update/recap on some of the latest: SecurityZone 2013 was an excellent experience. Always great to get back to Cali to meet who are now friends rather than just colleagues and conference organizers. I delivered the keynote there, where it was fun getting feedback for stating out-loud some of the things that we all (should) realize, which is our reliance on products is hurting us.

And this week was DerbyCon. Can’t stress enough how much fun it is to run the Red Team Training class with my best friend Chris, and the kind of feedback (and learning) we have a chance to get.

Speaking of DerbyCon – OMG what a conference! It’s just amazing what a small crew of dedicated individuals can come up with in such a short period of time. If you’d ask me for how long this con has been running I’d say at least 8-9 years. And this one was just the third iteration. Everything from the volunteer crew, through the hotel staff (major kudos to the Hyatt for taking DerbyCon on, and “working” with us – going well above just accommodating a conference venue).

My talk at DerbyCon focused on the “receiving end” of a red-team, which articulates what an organization should do in order to thoroughly prepare for such an engagement, and maximize the impact from it and the returns in the form of improving the organizational efficiency and security posture. Had a lot of great feedback on it, and some excellent conversations with people who have been struggling to get to that “buy-in” point in their organizations. Really hoped that I managed to help a bit in figuring out how to more accurately convey the advantages and ROI of such an engagement to the different internal groups.

Following are the video and slides. Have fun!