INSIGHTS, NEWS & DISCOVERIES
FROM IOACTIVE RESEARCHERS

Tuesday, December 3, 2013

Practical and cheap cyberwar (cyber-warfare): Part II

By Cesar Cerrudo @cesarcer

Disclaimer: I did not perform any illegal attacks on the mentioned websites in order to get the information I present here. No vulnerability was exploited on the websites, and they are not known to be vulnerable.

Given that we live in an age of information leakage where government surveillance and espionage abound, I decided in this second part to focus on a simple technique for information gathering on human targets. If an attacker is targeting a specific country, members of the military and defense contractors would make good human targets. When targeting members of the military, an attacker would probably focus on high ranking officers and for defense contractors, an attacker would focus on key decision makers, C-level executives, etc. Why? Because if an attacker compromises these people, they could gain access to valuable information related to their work, their personal life, and family. Data related to their work could help an attacker strategically by enabling them to build better defenses, steal intellectual property, and craft specific attacks. Data related to a target’s personal life could help attackers for blackmailing or attacking the target’s families.

Wednesday, November 27, 2013

A Short Tale About executable_stack in elf_read_implies_exec() in the Linux Kernel

by Alejandro Hernández @nitr0usmx 

This is a short and basic analysis I did when I was uncertain about code execution in the data memory segment. Later on, I describe what’s happening in the kernel side as well as what seems to be a small logic bug.

I’m not a kernel hacker/developer/ninja; I’m just a Linux user trying to figure out the reason of this behavior by looking in key places such as the ELF loader and other related functions. So, if you see any mistakes or you realize that I approached this in a wrong way, please let me know, I’d really appreciate that.

This article also could be useful for anyone starting in shellcoding since they might think their code is wrong when, in reality, there are other things around to take care of in order to test the functionality of their shellcodes or any other kind of code.

Friday, November 15, 2013

heapLib 2.0

By Chris Valasek @nudehaberdasher

Hi everyone, as promised I’m releasing my code for heapLib2. For those of you not familiar, I introduced methods to perform predictable and controllable allocations/deallocations of strings in IE9-IE11 using JavaScript and the DOM. Much of this work is based on Alex Sotirov’s research from quite a few years ago (http://www.phreedom.org/research/heap-feng-shui/). 

Thursday, November 14, 2013

Change of guard at Infineon

We have come across samples of the über-secure & über-hyped SLE78/97. 
It would appear new engineers are at the core of these design series.
It's a shame they have sacrificed physical security replacing it with
over-hyped so called "secure core" designs.This whole scenario makes
an person miss the good old trustable SLE66P.

Monday, November 11, 2013

Practical and cheap cyberwar (cyber-warfare): Part I

By Cesar Cerrudo @cesarcer

Every day we hear about a new vulnerability or a new attack technique, but most of the time it’s difficult to imagine the real impact. The current emphasis on cyberwar (cyber-warfare if you prefer) leads to myths and nonsense being discussed. I wanted to show real life examples of large scale attacks with big impacts on critical infrastructure, people, companies, etc.

The idea of this post is to raise awareness. I want to show how vulnerable some industrial, oil, and gas installations currently are and how easy it is to attack them. Another goal is to pressure vendors to produce more secure devices and to speed up the patching process once vulnerabilities are reported.

Monday, October 28, 2013

Hacking a counterfeit money detector for fun and non-profit

By Ruben Santamarta @reversemode


In Spain we have a saying "Hecha la ley, hecha la trampa" which basically means there will always be a way to circumvent a restriction. In fact, that is pretty much what hacking is all about.

It seems the idea of 'counterfeiting' appeared at the same time as legitimate money. The Wikipedia page for Counterfeit money  is a fascinating read that helps explain its effects.

Tuesday, October 22, 2013

NCSAM - Lucas Apa explains the effects of games cheating, 3D modeling, and psychedelic trance music on IT security

By Lucas Apa @lucasapa

I got involved with computers in 1994 when I was six years old. I played games for some years without even thinking about working in the security field. My first contact with the security field was when I started to create "trainers" to cheat on games by manipulating their memory. This led me to find many tutorials related to assembly and cracking in 2001, when my security research began.

Monday, October 21, 2013

NCSAM – Eireann Leverett on why magic is crucial

By Eireann Leverett @blackswanburst and Craig Brophy @CraigBrophy

Late last week I had the pleasure of interviewing IOActive Labs CTO – Cesar Cerrudo on how he got into IT security. Today I am fortunate enough to have the pleasure of interviewing Eireann Leverett, a senior researcher for IOActive on this field and how magic played a part.

Friday, October 18, 2013

NCSAM – an Interview with Cesar Cerrudo

By Cesar Cerrudo @cesarcer and Craig Brophy @craigbrophy


Today we continue our support for National Cyber Security Awareness Month, by interviewing Cesar Cerrudo, Chief Technology Officer for IOActive Labs. Cesar provides us with some insight of how he got into IT security and why it's important to be persistent!

Thursday, October 17, 2013

Strike Two for the Emergency Alerting System and Vendor Openness

By Mike Davis


Back in July I posted a rant about my experiences reporting the DASDEC issues and the problems I had getting things fixed. Some months have passed and I thought it would be a good time to take a look at how the vulnerable systems have progressed since then.

Well, back then my biggest complaint was the lack of forthrightness in Monroe Electronics' public reporting of the issues; they were treated as a marketing problem rather than a security one. The end result (at the time) was that there were more vulnerable systems available on the internet - not fewer - even though many of the deployed appliances had adopted the 2.0-2 patch.

Wednesday, October 16, 2013

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

By Ian Amit @iiamit


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.

Tuesday, October 15, 2013

IOActive supports National Cyber Security Awareness Month

By Craig Brophy @CraigBrophy


The month of October has officially been deemed National Cyber Security Awareness Month (NCSAM). Ten years ago the US Department of Homeland Security and the National Cyber Security Alliance got together and began this commendable online security awareness initiative.  Why? Well, according to the Department of Homeland Security the NCSAM is seen as an opportunity to engage with businesses and the general public to create a ‘safe, secure and resilient cyber environment.’  This is something that resonates with the team here at IOActive

Thursday, October 3, 2013

Seeing red - recap of SecurityZone, DerbyCon, and red teaming goodness

By Ian Amit @iiamit

I was fortunate enough to have a chance to participate in a couple of conferences that I consider close to my heart in the past couple of weeks. First - SecurityZone in beautiful Cali ,Colombia. This is the third year that SecurityZone has been running, and is slowly making its way into the latin american security scene.

Tuesday, September 10, 2013

Vulnerability bureaucracy: Unchanged after 12 years

By Cesar Cerrudo @cesarcer



One of my tasks at IOActive Labs is to deal with vulnerabilities; report them, try to get them fixed, publish advisories, etc. This isn't new to me. I started to report vulnerabilities something like 12 years ago and over that time I have reported hundreds of vulnerabilities - many of them found by me and by other people too.

Since the early 2000's I have encountered several problems when reporting vulnerabilities:
  • Vendor not responding
  • Vendor responding aggressively
  • Vendor responding but choosing not to fix the vulnerability
  • Vendor releasing flawed patches or didn't patch some vulnerabilities at all
  • Vendor failing to meet deadlines agreed by themselves

Tuesday, September 3, 2013

Emulating binaries to discover vulnerabilities in industrial devices

By Ruben Santamarta @Reversemode


Emulating an industrial device in a controlled environment is a really helpful security tool. You can gain a better knowledge of how it works, identify potential attack vectors, and verify the vulnerabilities you discovered using static methods.

This post provides step-by-step instructions on how to emulate an industrial router with publicly available firmware. This is a pretty common case, so you should be able to apply this methodology to other scenarios.

Friday, August 23, 2013

IE heaps at Nordic Security Conference

By Chris Valasek @nudehaberdasher

Remember when I used to be the Windows Heap guy? Yeah, me neither ;). I just wanted to give everyone a heads up regarding my upcoming presentation “An Examination of String Allocations: IE-9 Edition” at Nordic Security Conference (www.nsc.is). The presentation title is a bit vague so I figured I would give a quick overview.

Tuesday, August 20, 2013

FDA Medical Device Guidance

Gunter Ollmann - @gollmann

Last week the US Food and Drug Administration (FDA) finally released a couple of important documents. The first being their guidance on using radio frequency wireless technology in medical devices (replacing a draft from January 3,2007), and a second being their new (draft) guidance on premarket submission for management of cybersecurity in medical devices.

The wireless technology guidance document seeks to address many of the risks and vulnerabilities that have been disclosed in medical devices (embedded or otherwise) in recent years - in particular those with embedded RF wireless functionality...

Monday, August 5, 2013

Car Hacking: The Content

By  Chris Valasek @nudehaberdasher  and Charlie Miller @0xcharlie

Hi Everyone, 
As promised, Charlie and I are releasing all of our tools and data, along with our white paper. We hope that these items will help others get involved in automotive security research. The paper is pretty refined but the tools are a snapshot of what we had. There are probably some things that are deprecated or do not work, but things like ECOMCat and ecomcat_api should really be all you need to start with your projects. Thanks again for all the support! 


Thursday, July 25, 2013

Las Vegas 2013


Again, that time of the year is approaching; thousands of people from the security community are preparing to head to Las Vegas for the most important hacking events: Black Hat USA and DefCon. IOActive will (as we do every year) have an important presence at these conferences.

Wednesday, July 24, 2013

DefCon 21 Preview

By Chris Valasek @nudehaberdasher


Hi Internet! 

You may have heard that Charlie Miller (@0xcharlie) and I (@nudehaberdasher) will present a car hacking presentation at DefCon 21 on Friday, August 2 at 10:00am.
“Adventures in Automotive Networks and Control Units” (Track 3)
(https://www.defcon.org/html/defcon-21/dc-21-schedule.html

I wanted to put up a blog explaining what exactly we’ll be talking about in a bit more detail than was provided in the abstract. Our abstract was purposefully vague because we weren’t really sure what we were going to release at the time of submission, but obviously have a much more concrete set of items now. 

Tuesday, July 16, 2013

2013 ISS Conference, Prague

By Lucas Lundgren @Acidgen

I had the opportunity to attend the 2013 ISS conference in Prague a few weeks ago. The conference is a place where company representatives and law enforcement (and other government agency) officials can meet to share ideas and products information (such as appliances). Even though I had a sore throat, I still found it quite interesting; although not necessarily in terms of the products and presentations - which I felt was overall a bit flat. 

It was easy to differentiate between company representatives and government officials. Government officials wore yellow ID tags, while company representatives wore purple ID tags. These tags stated the individual’s first and last name and the company or government agency they represented. 

Thursday, July 11, 2013

Why Vendor Openness Still Matters

By Mike Davis

When the zombies began rising from their graves in Montana it had already been over 30 days since IOActive had reported issues with Monroe Electronics DASDECS.

And while it turned out in the end that the actual attacks which caused the false EAS messages to be transmitted relied on the default password never having been changed, this would have been the ideal point to publicize that there was a known issue and that there was a firmware update available, or would soon be to address this and other problems… maybe a mitigation or two in the mean time right?

Thursday, July 4, 2013

Why sanitize excessed equipment

By Reid Wightman @ReverseICS


My passion for cybersecurity centers on industrial controllers–PLCs, RTUs, and the other “field devices.” These devices are the interface between the integrator (e.g., HMI systems, historians, and databases) and the process (e.g., sensors and actuators). Researching this equipment can be costly because PLCs and RTUs cost thousands of dollars. Fortunately, I have an ally: surplus resellers that sell used equipment.

Thursday, June 20, 2013

FDA Safety Communication for Medical Devices

By Gunter Ollmann  @gollmann

The US Food and Drug Agency (FDA) released an important safety communication targeted at medical device manufacturers, hospitals, medical device user facilities, health care IT and procurements staff, along with biomedical engineers in which they warn of risk of failure due to cyberattack - such as through malware or unauthorized access to configuration settings in medical devices and hospital networks.

Have you ever been to view a much anticipated movie based upon an exciting book you happened to have read when you were younger, only to be sorely disappointed by what the director finally pulled together on the big screen? Well that’s how I feel when I read this newest alert from the FDA. Actually it's not even called an alert… it's a "Safety Communication"… it's analogous to Peter Jackson deciding that his own interpretation of JRR Tolkien's 'The Hobbit' wasn't really worthy of the title so to forestall criticism he named the movie 'Some Dwarves and a Hobbit do Stuff'.

Friday, June 14, 2013

Red Team Testing: Debunking Myths and Setting Expectations

By Ian Amit @iiamit


The term "cyber" seems to be overused in every corner of the information security industry. Now there is a new buzz phrase in computer security, "red team engagements.” Supposedly (to get "cyber" on you), you can have a red team test, and it will help move your organization in the correct “cyber direction.”

But what is red team testing really? And what is it not? In this post I’ll try to make some sense of this potent term.

Tuesday, June 11, 2013

Tools of the Trade – Incident Response, Part 1: Log Analysis

By Wim Remes @wimremes

There was a time when I imagined I was James Bond zip lining into a compromised environment, equipped with all kinds of top-secret tools. I would wave my hands over the boxes needing investigation, use my forensics glasses to extract all malware samples, and beam them over to Miss Moneypenny (or “Q” for APT concerns) for analysis. I would produce the report from my top-notch armpit laser printer in minutes. I was a hero.

As wonderful as it sounds, this doesn’t ever happen in real life. Instead of sporting a classy tuxedo, we are usually knee deep in data… often without boots! I have recently given a few presentations(1) on Incident Response (IR). The question I am most often asked concerns the tool chain that would enable an individual or a team to perform the basic actions one would expect from an Incident Responder.

Tuesday, June 4, 2013

Industrial Device Firmware Can Reveal FTP Treasures!


By Sofiane Talmat @_Sud0

Security professionals are becoming more aware of backdoors, security bugs, certificates, and similar bugs within ICS device firmware. I want to highlight another bug that is common in the firmware for critical industrial devices: the remote access provided by some vendors between their devices and ftp servers for troubleshooting or testing. In many cases this remote access could allow an attacker to compromise the device itself, the company the device belongs to, or even the entire vendor organization.

I discovered this vulnerability while tracking connectivity test functions within the firmware for an industrial device gateway. During my research I landed on a script with ftp server information that is transmitted in the clear:

Wednesday, May 29, 2013

Security 101: Machine Learning and Big Data


By Gunter Ollmann, @gollmann

The other week I was invited to keynote at the ISSA CISO Forum on Incident Response in Dallas and in the weeks prior to it I was struggling to decide upon what angle I should take. Should I be funny, irreverent, diplomatic, or analytical? Should I plaster slides with the last quarter's worth of threat statistics, breach metrics, and headline news? Should I quip some anecdote and hope the attending CISO's would have an epiphany that'll fundamentally change the way they secure their organizations?

In the end I did none of that... instead I decided to pull apart the latest batch of security buzzwords - "Big Data" and "Machine Learning".

Thursday, May 23, 2013

Identify Backdoors in Firmware By Using Automatic String Analysis

By Ruben Santamarta @reversemode

The Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) this Friday published an advisory about some backdoors I found in two programmable gateways from TURCK, a leading German manufacturer of industrial automation products. 


Using hard-coded account credentials in industrial devices is a bad idea. I can understand the temptation among manufacturers to include a backdoor “support” mechanism in the firmware for a product such as this. This backdoor allows them to troubleshoot problems remotely with minimal inconvenience to the customer.

On the other hand, it is only a matter of time before somebody discovers these 'secret' backdoors. In many cases, it takes very little time.

The TURCK backdoor is similar to other backdoors that I discussed at Black Hat and in previous blog posts. The common denominator is this: you do not need physical access to an actual device to find its backdoor. All you have to do is download device firmware from the vendor's website. Once you download the firmware, you can reverse engineer it and learn some interesting secrets.

Tuesday, May 7, 2013

Bypassing Geo-locked BYOD Applications


By Gunter Ollmann, @gollmann

In the wake of increasingly lenient BYOD policies within large corporations, there’s been a growing emphasis upon restricting access to business applications (and data) to specific geographic locations. Over the last 18 months more than a dozen start-ups in North America alone have sprung up seeking to offer novel security solutions in this space – essentially looking to provide mechanisms for locking application usage to a specific location or distance from an office, and ensuring that key data or functionality becomes inaccessible outside these prescribed zones.

These “Geo-locking” technologies are in hot demand as organizations try desperately to regain control of their networks, applications and data.

Tuesday, April 30, 2013

Fact or Fiction: Is Huawei a Risk to Critical Infrastructure?


By Gunter Ollmann - @gollmann

How much of a risk does a company like Huawei or ZTE pose to U.S. national security? It’s a question that’s been on many peoples lips for a good year now. Last year the U.S. House of Representatives Permanent Select Committee on Intelligence warned American companies to “use another vendor”, and earlier in that year the French senator and former defense secretary Jean-Marie Bockel recommended a “total prohibition in Europe of core routers and other sensitive IT equipment coming from China.” In parallel discussions, the United Kingdom, Australia and New Zealand (to name a few) have restricted how Huawei operates within their borders.

Last week Eric Xu – executive vice-president and one of the triumvirate jointly running Huawei – stunned analysts when he told them that Huawei was “not interested in the U.S. market any more.”

Much of the analysis has previously focused upon Huawei's sizable and influential position as the world’s second largest manufacturer of network routers and switching technology – a critical ingredient for making the Internet and modern telecommunications work – and the fact that it is unclear as to how much influence (or penetration) the Chinese government has in the company and its products. The fear is that at any point now or in the future, Chinese military leaders could intercept or disrupt critical telecommunications infrastructure – either as a means of aggressive statecraft or as a component of cyber warfare.

As someone who's spent many years working with the majority of the world's largest telecommunication companies, ISP's, and cable providers, I've been able to observe firsthand the pressure being placed upon these critical infrastructure organizations to seek alternative vendors and/or replace any existing Huawei equipment they may already have deployed. In response, many of the senior technical management and engineers at these organizations have reached out to me and to IOActive to find out how true these rumors are. I use the term “rumor” because, while reports have been published by various government agencies, they’re woefully lacking in technical details. You may have also seen François Quentin (chairman of the board of Huawei France) claiming that the company is a victim of “rumors”.

In the public technical arena, there are relatively few bugs and vulnerabilities being disclosed in Huawei equipment. For example, if you search for CVE indexed vulnerabilities you’ll uncover very few. Compared to the likes of Cisco, Juniper, Nokia, and most of the other major players in routing and switching technology, the number of public disclosures is miniscule. But this is likely due to a few of the following reasons:
  • The important Huawei equipment isn't generally the kind of stuff that security researchers can purchase off Ebay and poke around with at home for a few hours in a quest to uncover new bugs. They're generally big-ticket items. (This is the same reason why you’ll see very few bugs publicly disclosed in Cisco’s or Nokia’s big ISP-level routers and switches).
  • Up until recently, despite Huawei being such a big player internationally, they haven't been perceived as such to the English-speaking security researcher community – so have traditionally garnered little interest from bug hunters.
  • Most of the time when bugs are found and exploitable vulnerabilities are discovered, they occur during a paid-for penetration test or security assessment, and therefore those findings belong to the organization that commissioned the consulting work – and are unlikely to be publicly disclosed.
  • Remotely exploitable vulnerabilities that are found in Huawei equipment by independent security researchers are extremely valuable to various (international) government agencies. Any vulnerability that could allow someone to penetrate or eavesdrop at an international telecommunications carrier-level is worth big bucks and will be quickly gobbled up. And of course any vulnerability sold to such a government agency most certainly isn't going to be disclosed to the vulnerable vendor – whether that be Huawei, Cisco, Juniper, Nokia, or whatever.

What does IOActive know of bugs and exploitable vulnerabilities within Huawei’s range of equipment? Quite a bit obviously – since we've been working to secure many of the telecommunications companies around the world that have Huawei’s top-end equipment deployed. It’s obviously not for me to disclose vulnerabilities that were uncovered on the dime of an IOActive client, however many of the vulnerabilities we've uncovered during tests have given great pause to our clients as remedies are sought.

Interesting enough, the majority of those vulnerabilities were encountered using standard network discovery techniques - which to my mind is just scratching the surface of things. However, based upon what’s been disclosed in these afore mentioned government reports over the last year, that was probably their level of scrutinization too. Digging deeper in to the systems reveals more interesting security woes.

Given IOActive’s expertise history and proven capability of hardware hacking, I’m certain that we’d be able to uncover a whole host of different and more significant security weaknesses in these critical infrastructure components for clients that needed that level of work done. To date IOActive the focus has be on in-situ analysis – typically assessing the security and integrity of core infrastructure components within live telco environments.

I've heard several senior folks talk of their fears that even with full access to the source code that that wouldn't be enough to verify the integrity of Chinese network infrastructure devices. For a skillful opponent, that is probably so, because they could simply hide the backdoors and secret keys in the microcode of the devices semiconductor chips.

Unfortunately for organizations that think they can hide such critical flaws or backdoors at the silicon layer, I've got a surprise for you. IOActive already has the capability strip away the layers of logic within even the most advanced and secure microprocessor technologies out there and recover the code and secrets that have been embedded within the silicon itself.

So, I’d offer a challenge out there to the various critical infrastructure providers, government agencies, and to manufacturers such as Huawei themselves – let IOActive sort out the facts from the multitude of rumors. Everything you've probably been reading is hearsay.

Who else but IOActive can assess the security and integrity of a technology down through the layers – from the application, to the drivers, to the OS, to the firmware, to the hardware and finally down to the silicon of the microprocessors themselves? Exciting times!

-- Gunter Ollmann, CTO IOActive Inc.

Thursday, April 18, 2013

InfoSec Europe 2013 - Security on Tap

By Gunter Ollmann, @gollmann

It's that time of the year again as Europe's largest and most prestigious information security conference "Infosecurity Europe" gets ready to kick off next week at Earls Court, London, UK.

This year's 18th annual security gathering features over 350 exhibitors, but you won't find IOActive on the floor of the conference center. Oh no, we're pulling out all the stops and have picked a quieter and more exclusive location to conduct our business just around the corner. After all, why would you want to discuss confidential security issues on a floor with 12,500 other folks?

We all know what these conferences are like. We psych ourselves up for a couple of days for shuffling from one booth to the next, avoiding eye contact with the glammed-up booth-babes working their magic on blah-blah's vendor booth - who's only mission in life is to scan your badge so that a far-off marketing team can spam you for the next 6 months with updates about a product you had no interest in - who you unfortunately allowed to scan your badge because they were giving away an interesting  foam boomerang (that probably cost 20 pence) which you thought one of your kids might like as recompense for the guilt you're feeling at having to be away from home one evening so you could see all of what the conference had to offer.

Well fret no more, IOActive have come to save the day!

After you've grown tired and wary of the endless shuffling, avoided eye-contact for as long as possible, grabbed enough swag to keep the neighbors grandchildren happy for a decade's worth of birthdays, and the imminent prospect of standing in queues for over priced tasteless coffee and tea has made your eyes roll further in to the back of your skull one last time, come visit IOActive down the street at the pub we've taken over! Yes, that's right, IOActive crew have taken hostage a pub and we're inviting you and a select bunch of our VIP's to come join us in a more relaxed and conducive business environment.

I hear tell that the "Security on Tap" will include a range of fine ales, food and other refreshments, and that the decibel level should be a good 50dB lower than Earls Court Conference Center. A little birdy also mentioned that there may be a whisky tasting going on at some point too. Oh, and there'll be a bunch of us IOActive folks there too. Chris Valasek and I, along with some of our top UK-based consultants will be there talk about the latest security threats and evil hackers. I think there'll be some sales folks there too - but don't worry, we'll make sure that their badge readers don't work.

If you'd like to join us for drinks, refreshments and intelligent conversation in a venue that's comfortable and won't have you going hoarse (apparently "horse" is bad these days) - you're cordially invited to join us at the Courtfield Pub (187 Earls Court Road, Earls Court, London, SW5 9AN). We'll be there Tuesday and Wednesday (April 23rd & 24th) between 10:00 and 17:00.

To prevent the prospect of having to queue to get in, I'd ask you to quickly RSVP on the page we've crafted specifically for the Infosec event. Go on, RSVP HERE!


-- Gunter Ollmann, CTO IOActive

Tuesday, April 16, 2013

Can GDB's List Source Code Be Used for Evil Purposes?


By Alejandro Hernández @nitr0usmx


One day while debugging an ELF executable with the GNU Debugger (GDB), I asked myself, "How does GDB know which file to read when you use the list command?" (For the uninformed, the list command prints a specified number of lines from a source code file -— ten lines is the default.)
Source code filenames are contained in the metadata of an ELF executable (in the .debug_line section, to be exact). When you use the list command, GDB will open(), read(), and display the file contents if and only if GDB has the permissions needed to read the source file. 
The following is a simple trick where you can use GDB as a trampoline to read a file which originally you don’t have enough permission to read. This trick could also be helpful in a binary capture-the-flag (CTF) or reverse engineering challenge.
Here are the steps:


1. Compile 'foo.c' with the GNU Compiler (GCC) using the -ggdb flag.

2. Open the resulting ELF executable with GDB and the list command to read its source code as shown in the following screen shot:

3. Make a copy of ‘foo.c’ and call it ‘_etc_shadow.c’, so that this name is hardcoded within the internal metadata structures of the compiled ELF executable as in the following screen shot.

4. Open the executable with your preferred hex editor (I used HT Editor because it supports the ELF file format) and replace ‘_etc_shadow.c’ with ‘/etc/shadow’ (don't forget the NULL character at the end of the string) the first two times it appears.

5. Evidently, it won't work unless you have sufficient user privileges, otherwise GDB won’t be able to read /etc/shadow.

6. If you trace the open() syscall calls executed by GBD:
 ($strace -e open gdb ./_etc_shadow) 
you can see that it returns -1 (EACCES) because of insufficient permissions.

7. Now imagine that for some reason GDB is a privileged command (the SUID (Set User ID) bit in the permissions is enabled). Opening our modified ELF file with GDB, it would be possible to read the contents of ‘/etc/shadow’ because the gdb command would be executed with root privileges.

8. Imagine another hypothetical scenario: a hardened development (or CTF) server that has been configured with granular privileges using a tool such as Sudo to allow certain commands to be executed. (To be honest I have never seen a scenario like this before, but it’s an example worth considering to illustrate how this attack might evolve).

9. You cannot display the contents of ‘/etc/shadow’ by using the cat command because /bin/cat is an unauthorized command in our configuration. However, the gdb command has been authorized and therefore has the rights needed to display the source file (/etc/shadow):

Voilà! 

Taking advantage of this GDB feature and mixing it with other techniques could make a more sophisticated attack possible. Use your imagination.

Do you have other ideas how this could be used as an attack vector, either by itself or if combined with other techniques? Let me know.

Wednesday, April 10, 2013

What Would MacGyver Do?


By Sofiane Talmat @_Sud0

"The great thing about a map: it gets you in and out of places in a lot different ways." - MacGyver 

When I was young I was a big fan of the American TV show, MacGyver. Every week I tuned in to see how MacGyver would build some truly incredible things with very basic and unexpected materials — even if some of his solutions were hard to believe. For example, in one episode MacGyver built a futuristic motorized heat-seeking gun using only a set of batteries, an electric mixer, a rubber band, a serving cart, and half a suit of armor.


From that time I always kept the “What would MacGyver do?” spirit in my thinking. On the other hand I think I was “destined” to be an IT guy, and particularly in the security field, where we don’t have quite the same variety of materials to craft our solutions. 

But the “What would MacGyver do?” frame of mind helped me figure out a simple way to completely “own” a network environment in a MacGyver sort of way using just a small set of steps, including:

  • Exploiting a bad use of tools.
  • A small piece of social engineering.
  • Some creativity.
  • A small number of manual configuration changes..

Tuesday, April 2, 2013

Spotting Fake Chips in the Supply Chain


By Christopher Tarnovsky @semiconduktor & Gunter Ollmann @gollmann


In the information security world we tend to focus upon vulnerabilities that affect the application and network architecture layers of the enterprise and, every so often, some notable physical devices. Through various interrogatory methods we can typically uncover any vulnerabilities that may be present and, through discussion with the affected business units, derive a relative statement of risk to the business as a whole.

An area of business rarely dissected from an information security perspective however is the supply chain. For manufacturing companies and industrial suppliers, nothing is more critical to their continued business success than maintaining the integrity and reliability of their supply chain. For some industries – such as computer assembly or truck fabrication facilities – even the smallest hiccup in their just-in-time ordering system can result in entire assembly lines being gummed up and product not being rolled out the front door.

Thursday, March 28, 2013

Behind ADSL Lines: How to Bankrupt ISPs While Making Money


By Ehab Hussein @__obzy__ & Sofiane Talmat @_Sud0

Disclaimer: No businesses or even the Internet were harmed while researching this post. We will explore how an attacker can control the Internet access of one or more ISPs or countries through ordinary routers and Internet modems.
Cyber-attacks are hardly new in 2013. But what if an attack is both incredibly easy to construct and yet persistent enough to shut Internet services down for a few hours or even days? In this blog post we will talk about how easy it would be to enlist ordinary home Internet connections in this kind of attack, and then we suggest some potentially straightforward solutions to this problem.

Monday, March 25, 2013

SQL Injection in the Wild


By Gunter Ollmann, @gollmann

As attack vectors go, very few are as significant as obtaining the ability to insert bespoke code in to an application and have it automatically execute upon “inaccessible” backend systems. In the Web application arena, SQL Injection vulnerabilities are often the scariest threat that developers and system administrators come face to face with (albeit way too regularly).  In fact the OWASP Top-10 list of Web threats lists SQL Injection in first place.

More often than not, when security professionals discuss SQL Injection threats and attack vectors, they focus upon the Web application context. So it was with a bit of fun last week when I came across a photo of a slightly unorthodox SQL Injection attempt – that of someone attempting to subvert a traffic monitoring system by crafting a rather novel vehicle license plate.

My original tweet got retweeted a couple of thousand of times – which just goes to show how many security nerds there are out there in the twitterverse.

This “in the wild” SQL Injection attempt was based upon the premise that video cameras are actively monitoring traffic on a road, reading license plates, and issuing driver warnings, tickets or fines as deemed appropriate by local law enforcement.

At some point the video captures of the passing vehicle’s license plate must be converted to text and stored – almost certainly in some kind of backend database. The hope of the hacker that devised this attack was that the process would be vulnerable to SQL Injection – and crafted a simple SQL statement that could potentially cause the backend database to drop (i.e. “delete”) the table containing all of the license plate information.

Whether or not this particular attempt worked, I have no idea (probably not if I have to guess an outcome); but it does help nicely to raise attention to this category of vulnerability.

As surveillance systems become more capable – digitally storing information, distilling meta-data from image captures, and sharing observation data between systems – it opens many new doors for mischievous and malicious attack.

The physical nature of these systems, coupled with the complexities of integration with legacy monitoring and reporting systems, often makes them open to attacks that would be classed as fairly simple in the world of Web application security.

A common failure of system developers is to assume that the physical constraints of the data acquisition process are less flexible than they are. For example, if you’re developing a traffic monitoring system it’s easy to assume that license plates are a fixed size and shape, and can only contain 10 alphanumeric characters. Meanwhile, the developers of the third-party image processing code had no such assumptions and will digitize any image. It reminds me a little of the story in which reuse of some object-oriented code a decade ago resulted in Kangaroos firing Stinger missiles during a military training simulation.

While the image above is amusing, I’ve encountered similar problems before when physical tracking systems integrate with digital backend processes – opening the door to embarrassing and fraudulent events. For example, in the past I’ve encountered similar SQL Injection vulnerabilities within systems such as:
  • Toll booths reading RFID tags mounted on vehicle windshields – where the tag readers would accept up to 2k of data from each tag (even though the system was only expecting a 16 digit number).
  • Credit card readers that would accept pre-paid cards with negative balances – which resulted in the backend database crediting the wrong accounts.
  • RFID inventory tracking systems – where a specially crafted RFID token could automatically remove all record of the previous hours’ worth of inventory logging information from the database allowing criminals to “disappear” with entire truckloads of goods.
  • Luggage barcode scanners within an airport – where specially crafted barcodes placed upon the baggage would be automatically conferred the status of “manually checked by security personnel” within the backend tracking database.
  • Shipping container RFID inventory trackers – where SQL statements could be embedded to adjust fields within the backend database to alter Custom and Excise tracking information.

Unlike the process of hunting for SQL Injection vulnerabilities within Internet accessible Web applications, you can’t just point an automated vulnerability scanner at the application and have at it. Assessing the security of complex physical monitoring systems is generally not a trivial task and requires some innovative approaches. Experience goes a long way.

-- Gunter Ollmann, CTO IOActive Inc.

Thursday, March 14, 2013

Credit Bureau Data Breaches


By Gunter Ollmann, @gollmann

This week saw some considerable surprise over how easy it is to acquire personal credit report information.  On Tuesday Bloomberg News led with a story of how “Top Credit Agencies Say Hackers Stole Celebrity Reports”, and yesterday there were many follow-up stories examining the hack. In one story I spoke with Rob Westervelt over at CRN regarding the problems credit reporting agencies face when authenticating the person for which the credit information applies and the additional problems they face securing the data in general (you can read the article “Equifax, Other Credit Bureaus Acknowledge Data Breach”).

Many stories have focused on one of two areas – the celebrities, or the ease of acquiring credit reports – but I wanted to touch upon some of the problems credit monitoring agencies face in verifying who has access to the data and how that fits in to the bigger problem of Internet-based authentication and the prevalence of personal-enough information.

The repeated failure of Internet portals tasked with providing access to personal credit report information stems from the data they have available that can be used for authentication, and the legislated requirement to make the data available in the first place.

Credit monitoring agencies are required to make the data accessible to all the individuals they hold reports on, however access to the credit report information is achieved through a wide variety of free and subscription portals – most of which are not associated with the credit monitoring bureaus in the first place.
In order to provide access to a particular individual’s credit report, the user must answer a few questions about themselves via one such portal. These questions, by necessity, are restricted to the kinds of data held (and tracked) by the credit reporting agencies – based off information garnered from other financial institutions. This information includes name, date of birth (or age), social security number, account numbers, account balances, account addresses, financial institutes that manages the accounts, and past requests for access to credit report information. While it sounds like a lot of information, it’s actually not a very rich source for authentication purposes – especially when some of the most important information that can uniquely identify the individual is relatively easy to acquire through other external and Internet-based sources.

Time Magazine’s article “Hackers Now Aiming For Your Credit Reports” of a year ago describes many of these limitations and where some of this information can be acquired. In essence though, the data is easy to mine from social media sites and household tax records; and a little bruteforce guessing can overcome the hurdle of it not already being in the public domain.

The question then becomes “what can the credit monitoring agencies do to protect the privacy of credit reports?”  Some commentators have recommended that individuals should provide a copy of state-issued identification documents – such as a drivers license or passport.

The submission of such a scanned document poses new problems for the credit monitoring agencies. First of all, this probably isn't automatable on a large scale and they’ll need trained staff to review each of these documents. Secondly, there are plenty of tools and websites that allow you to generate a fake ID within seconds (e.g. here) – and spotting the fakes will be extremely difficult without tying the authentication process to an external government authentication system (e.g. checking to see if the drivers license or passport number is legitimate). Thirdly, do you want the credit reporting agencies holding even more personal information about you?

This entire problem is getting worse – not just for the credit monitoring agencies, but for all online services. Authentication – especially “first time” authentication – is difficult at the best of times, but if you’re trying to do this using only data an organization has collected and holds themselves, it’s neigh on impossible given current hacking techniques.

I hate to say it, but there’s a very strong (and growing) requirement for governments to play a larger role in identity management. Someone somewhere needs to act as a trusted Internet passport authority – with “trusted” being the critical piece. I've seen the arguments that have been made for Facebook, Google, etc. being that identity management platform, but I respectively disagree. These commercial services aren't identity management platforms, they’re authentication gateways. What is needed is the cyber-equivalent of a government-issued passport, with all the checks and balances that entails.

Even that is not perfect, but it would certainly be better than the crumby vendor-specific authentication systems and password recovery processes that currently plague the Internet.

In the meantime, don’t be surprised if you find your credit report and other personal information splattered over the Internet as part of some juvenile doxing attack.

-- Gunter Ollmann, CTO IOActive Inc.

Monday, February 25, 2013

"Broken Hearts": How plausible was the Homeland pacemaker hack?


by Barnaby Jack @barnaby_jack

    [1]


I watched the TV show Homeland for the first time a few months ago. This particular episode had a plot twist that involved a terrorist remotely hacking into the pacemaker of the Vice President of the United States.

People follow this show religiously, and there were articles questioning the plausibility of the pacemaker hack. Physicians were questioned as to the validity of the hack and were quoted saying that this is not possible in the real world [2].

In my professional opinion, the episode was not too far off the mark.

IOAsis at RSA 2013


By Jennifer Steffens @securesun

RSA has grown significantly in the 10 years I've been attending, and this year’s edition looks to be another great event. With many great talks and networking events, tradeshows can be a whirlwind of quick hellos, forgotten names, and aching feet. For years I would return home from RSA feeling as if I hadn't sat down in a week and lamenting all the conversations I started but never had the chance to finish. So a few years ago during my annual pre-RSA Vitamin D-boosting trip to a warm beach an idea came to me: Just as the beach served as my oasis before RSA, wouldn't it be great to give our VIPs an oasis to escape to during RSA? And thus the first IOAsis was born.


Tuesday, February 12, 2013

Do as I say, not as I do. RSA, Bit9 and others...

by Ian Amit - @iiamit

You thought you had everything nailed down. Perhaps you even bypassed the "best practice" (which would have driven you to compliance and your security to the gutter) and focused on protecting your assets by applying the right controls in a risk-focused manner.

You had your processes, technologies, and logs all figured out. However, you still got “owned”. Do you know why? You are still a little naive.

You placed your trust in big-name vendors. You listened to them, you were convinced by their pitch, and maybe you even placed their products through rigorous testing to make sure they actually delivered. However, you forgot one thing. The big-name vendors do not always have your best interest at heart.

Such companies will preach and guide you through to the righteous passage. However, when you look behind the curtain, the truth is revealed.



Monday, February 11, 2013

Your network may not be what it SIEMs


by Wim Remes - @wimremes

The number of reports of networks that are rampaged by adversaries is staggering. In the past few weeks alone we've seen reports from The New York Times, The Washington Post and Twitter. I would argue that the public reports are just the tip of the iceberg. What about the hacks that never were? What about the companies that absorbed the blow and just kept on trucking or … perhaps even those companies that never recovered?

When there's an uptick in media attention over security breaches, the question most often asked - but rarely answered - is "What if this happens to me?"

Today you don't want to ask that question too loudly - else you'll find product vendors selling turn-key solutions and their partners on your doorstep, closely followed by 'Managed Security Services' providers. All ready to solve your problems once you send back their signed purchase order... if you want to believe that.

Most recently they've been joined by the "let's hack the villains back" start-ups. That last one is an interesting evolution but not important for this post today.

Wednesday, February 6, 2013

The Anatomy of Unsecure Configuration: Reality Bites


By Aditya K. Sood @AdityaKSood

As a penetration tester, I encounter interesting problems with network devices and software. The most common problems that I notice in my work are configuration issues. In today’s security environment, we can accept that a zero-day exploit results in system compromise because details of the vulnerability were unknown earlier. But, what about security issues and problems that have been around for a long time and can’t seem to be eradicated completely? I believe the existence of these types of issues shows that too many administrators and developers are not paying serious attention to the general principles of computer security. I am not saying everyone is at fault, but many people continue to make common security mistakes. There are many reasons for this, but the major ones are:


Hackers Unmasked: Detecting, Analyzing, And Taking Action Against Current Threats

By Gunter Ollmann -- @gollmann

Tomorrow morning I'll be delivering the opening keynote to InformationWeek & Dark Reading's virtual security event - Hackers Unmasked -- Detecting, Analyzing, And Taking Action Against Current Threats.

You can catch my live session at 11:00am Eastern discussing the "Portrait of a Malware Author" where I'll be discussing how today's malware is more sophisticated - and more targeted - than ever before. Who are the people who write these next-generation attacks, and what are their motivations? What are their methods, and how do they chose their targets? Along with how they execute their craft, and what you can do to protect your organization.

The day's event will have a bunch of additional interesting speakers too - including Dave Aitel and our very own Iftach Ian Amit.

Please come and join the event. I promise not to stumble over my lines too many times, and you'll learn new things.

You'll need to quickly subscribe in order to get all the virtual event connection information, so visit the InformationWeek & DarkReading event subscription page HERE.


-- Gunter Ollmann, CTO -- IOActive, Inc.

Monday, February 4, 2013

2012 Vulnerability Disclosure Retrospective


By Gunter Ollmann @gollmann

Vulnerabilities, the bugbear of system administrators and security analysts alike, keep on piling up – ruining Friday nights and weekends around the world as those tasked with fixing them work against ever shortening patch deadlines.

In recent years the burden of patching vulnerable software may have felt to be lessening; and it was, if you were to go by the annual number of vulnerabilities publicly disclosed. However, if you thought 2012 was a little more intense than the previous half-decade, you’ll probably not be surprised to learn that last year bucked the downward trend and saw a rather big jump – 26% over 2011 – all according to the latest analyst brief from NSS Labs, “Vulnerability Threat Trends: A Decade in Review, Transition on the Way”.

Rather than summarize the fascinating brief from NSS Labs with a list of recycled bullet points, I’d encourage you to read it yourself and to view the fascinating video they constructed that depicts the rate and diversity of vulnerability disclosures throughout 2012 (see the video - “The Evolution of 2012 Vulnerability Disclosures by Vendor”).

Wednesday, January 30, 2013

Energy Security 2013: Less Say, More Do

By Trevor Niblock @izTheOcho


Due to recent attacks on many forms of energy management technology ranging from supervisory control and data acquisition (SCADA) networks and automation hardware devices to smart meters and grid network management systems, companies in the energy industry are increasing significantly the amount they spend on security. However, I believe these organizations are still spending money in the wrong areas of security.  Why? The illusion of security, driven by over-engineered and over-funded policy and control frameworks and the mindset that security must be regulated before making a start is preventing, not driving, real world progress.


Friday, January 25, 2013

S4x13 Conference

By Reid Wightman @ReverseICS

 

S4 is my favorite conference. This is mainly because it concentrates on industrial control systems security, which I am passionate about. I also enjoy the fact that the presentations cover mostly advanced topics and spend very little time covering novice topics.

 

Over the past four years, S4 has become more of a bits and bytes conference with presentations that explain, for example, how to upload Trojan firmwares to industrial controllers and exposés that cover vulnerabilities (in the “insecure by design” and “ICS-CERT” sense of the word).

 
This year’s conference was packed with top talent from the ICS and SCADA worlds and offered a huge amount of technical information. I tended to follow the “red team” track, as these talks broke varying levels of control systems networks.


Tuesday, January 22, 2013

You cannot trust social media to keep your private data safe: Story of a Twitter vulnerability


by Cesar Cerrudo @cesarcer



I‘m always worried about the private information I have online. Maybe this is because I have been hacking for a long time, and I know everything can be hacked. This makes me a bit paranoid. I have never trusted web sites to keep my private information safe, and nowadays it is impossible to not have private information published on the web, such as a social media web site. Sooner or later you could get hacked, this is a fact.

Currently, many web and mobile applications give users the option to sign in using their Twitter or Facebook account. Keeping in mind the fact that Twitter currently has 200 million active monthly users (http://en.wikipedia.org/wiki/Twitter), it makes a lot of sense for third-party applications to offer users an easy way to log in. Also, since applications can obtain a wealth of information from your Twitter or Facebook account, most of the time you do not even need to register. This is convenient, and it saves time signing into third-party applications using Twitter or Facebook.


Every time I’m asked to sign in using Twitter or Facebook, my first thought is, “No way!”  I don’t want to give access to my Twitter and Facebook accounts regardless of whether I have important information there or not. I always have an uneasy feeling about giving a third-party application access to my accounts due to the security implications.

Last week I had a very interesting experience.

Monday, January 21, 2013

When a Choice is a Fingerprint

By Matthew Eble @iaimtomisbehav3

We frequently hear the phrase "Attribution is hard." And yes, if the adversary exercises perfect tradecraft, attribution can be hard to the point of impossible. But we rarely mention the opposite side of that coin, how hard it is to maintain that level of tradecraft over the lifetime of an extended operation. How many times out of muscle memory have you absent-mindedly entered one of your passwords in the wrong application? The consequences of this are typically nonexistent if you're entering your personal email address into your work client, but they can matter much more if you're entering your personal password while trying to log into the pwned mail server of Country X's Ministry of Foreign Affairs. People make mistakes, and the longer the timeframe, the more opportunities they have to do so.

Thursday, January 17, 2013

Offensive Defense

By Stephan Chenette @StephanChenette

I presented before the holiday break at Seattle B-Sides on a topic I called "Offensive Defense." This blog will summarize the talk. I feel it's relevant to share due to the recent discussions on desktop antivirus software   (AV) [1], [2],[4], [3]

The Slides

 Note: Some of these slides were also used in my talk at EkoParty, but the goal of the Offensive Defense talk was different, as I hope you will see:



Monday, January 7, 2013

The Demise of Desktop Antivirus

By Gunter Ollmann - @GOLLMANN

Are you old enough to remember the demise of the ubiquitous CompuServe and AOL CD’s that used to be attached to every computer magazine you ever brought between the mid-80’s and mid-90’s? If you missed that annoying period of Internet history, maybe you’ll be able to watch the death of desktop antivirus instead.

65,000 AOL CD's as art
Just as dial-up subscription portals and proprietary "web browsers" represent a yester-year view of the Internet, desktop antivirus is similarly being confined to the annuls of Internet history. It may still be flapping vigorously like a freshly landed fish, but we all know how those last gasps end.

To be perfectly honest, it's amazing that desktop antivirus has lasted this long. To be fair though, the product you may have installed on your computer (desktop or laptop) bears little resemblance to the antivirus products of just 3 years ago. Most vendors have even done away from using the "antivirus" term – instead they've tried renaming them as "protection suites" and "prevention technology" and throwing in a bunch of additional threat detection engines for good measure.

I have a vision of a hunchbacked Igor working behind the scenes stitching on some new appendage or bolting on an iron plate for reinforcement to the Frankenstein corpse of each antivirus product as he tries to keep it alive for just a little bit longer…

That’s not to say that a lot of effort doesn't go in to maintaining an antivirus product. However, with the millions upon millions of new threats each month it’s hardly surprising that the technology (and approach) falls further and further behind. Despite that, the researchers and engineers that maintain these products try their best to keep the technology as relevant as possible… and certainly don’t like it when anyone points out the gap between the threat and the capability of desktop antivirus to deal with it.

For example, the New York Times ran a piece on the last day of 2012 titled "Outmaneuvered at Their Own Game, Antivirus Makers Struggle to Adapt" that managed to get many of the antivirus vendors riled up – interestingly enough not because of the claims of the antivirus industry falling behind, but because some of the statistics came from unfair and unscientific tests. In particular there was great annoyance that a security vendor (representing an alternative technology) used VirusTotal coverage as their basis for whether or not new malware could be detected – claiming that initial detection was only 5%.

I've discussed the topic of declining desktop antivirus detection rates (and evasion) many, many times in the past. From my own experience, within corporate/enterprise networks, desktop antivirus detection typically hovers at 1-2% for the threats that make it through the various network defenses. For newly minted malware that is designed to target corporate victims, the rate is pretty much 0% and can remain that way for hundreds of days after the malware has been released in to the wild.

You’ll note that I typically differentiate between desktop and network antivirus. The reason for this is because I’m a firm advocate that the battle is already over if the malware makes it down to the host. If you’re going to do anything on the malware prevention side of things, then you need to do it before it gets to the desktop – ideally filtering the threat at the network level, but gateway prevention (e.g. at the mail gateway or proxy server) will be good enough for the bulk of non-targeted Internet threats. Antivirus operations at the desktop are best confined to cleanup, and even then I wouldn't trust any of the products to be particularly good at that… all too often reimaging of the computer isn't even enough in the face of malware threats such as TDL.

So, does an antivirus product still have what it takes to earn the real estate it take up on your computer? As a standalone security technology – No, I don’t believe so. If it’s free, never ever bothers me with popups, and I never need to know it’s there, then it’s not worth the effort uninstalling it and I guess it can stay… other than that, I’m inclined to look at other technologies that operate at the network layer or within the cloud; stop what you can before it gets to the desktop. Many of the bloated “improvements” to desktop antivirus products over recent years seem to be analogous to improving the hearing of a soldier so he can more clearly hear the ‘click’ of the mine he’s just stood on as it arms itself.

I’m all in favor of retraining any hunchbacked Igor we may come across. Perhaps he can make artwork out of discarded antivirus DVDs - just as kids did in the 1990’s with AOL CD’s?

-- Gunter Ollmann, CTO -- IOActive, Inc.