Tag: infosec

INSIGHTS | November 27, 2013

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

By Alejandro Hernandez
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.
USER-LAND: Why is it possible to execute code in the data segment if it doesn’t have the PF_EXEC enabled?
A couple of weeks ago I was reading an article (in Spanish) about shellcodes creation in Linux x64. For demonstration purposes I’ll use this 64-bit execve(“/bin/sh”) shellcode: 

#include <unistd.h>

char shellcode[] =
“x48x31xd2x48x31xf6x48xbf”
“x2fx62x69x6ex2fx73x68x11”
“x48xc1xe7x08x48xc1xefx08”
“x57x48x89xe7x48xb8x3bx11”
“x11x11x11x11x11x11x48xc1”
“xe0x38x48xc1xe8x38x0fx05”;

int main(int argc, char ** argv) {
void (*fp)();
fp = (void(*)())shellcode;
(void)(*fp)();

return 0;
}

The author suggests the following for the proper execution of the shellcodes:
“We compile and with the execstack utility we specify that the stack region used in the binary will be executable…”.

Immediately, I thought it was wrong because of the code to be executed would be placed in the ‘shellcode’ symbol in the .data section within the ELF file, which, in turn, would be in the data memory segment, not in the stack segment at runtime. For some reason, when trying to execute it without enabling the executable stack bit, it failed, and the opposite when it was enabled:

 

According to the execstack’s man-page:

“… ELF binaries and shared libraries now can be marked as requiring executable stack or not requiring it… This marking is done through the p_flags field in the PT_GNU_STACK program header entry… The marking is done automatically by recent GCC versions”.
It only modifies one bit adding the PF_EXEC flag to the PT_GNU_STACK program header. It also can be done by modifying the binary with an ELF editor such as HTEditor or at linking time by passing the argument ‘-z execstack’ to gcc. 
The change can be seen simply observing the flags RWE (Read, Write, Execution) using the readelf utility. In our case, only the ‘E’ flag was added to the stack memory segment:

 
The first loadable segment in both binaries, with the ‘E’ flag enabled, is where the code itself resides (the .text section) and the second one is where all our data resides. It’s also possible to map which bytes from each section correspond to which memory segments (remember, at runtime, the sections are not taken into account, only the program headers) using ‘readelf -l shellcode’.

So far, everything makes sense to me, but, wait a minute, the shellcode, or any other variable declared outside main(), is not supposed to be in the stack right? Instead, it should be placed in the section where the initialized data resides (as far as I know it’s normally in .data or .rodata). Let’s see where exactly it is by showing the symbol table and the corresponding section of each symbol (if it applies):

It’s pretty clear that our shellcode will be located at the memory address 0x00600840 in runtime and that the bytes reside in the .data section. The same result for the other binary, ‘shellcode_execstack’.

By default, the data memory segment doesn’t have the PF_EXEC flag enabled in its program header, that’s why it’s not possible to jump and execute code in that segment at runtime (Segmentation Fault), but: when the stack is executable, why is it also possible to execute code in the data segment if it doesn’t have that flag enabled? 

 
Is it a normal behavior or it’s a bug in the dynamic linker or kernel that doesn’t take into account that flag when loading ELFs? So, to take the dynamic linker out of the game, my fellow Ilja van Sprundel gave me the idea to compile with -static to create a standalone executable. A static binary doesn’t pass through the dynamic linker, instead, it’s loaded directly by the kernel (as far as I know). The same result was obtained with this one, so this result pointed directly to the kernel.

I tested this in a 2.6 kernel (x86_64) and in a 3.2 kernel (i686), and I got the same behavior in both.
KERNEL-LAND: Is that a bug in elf_read_implies_exec()?

Now, for the interesting part, what is really happening in the kernel side? I went straight to load_elf_binary()in linux-2.6.32.61/fs/binfmt_elf.c and found that the program header table is parsed to find the stack segment so as to set the executable_stack variable correctly:

     int executable_stack = EXSTACK_DEFAULT;
…
elf_ppnt = elf_phdata;
for (i = 0; i < loc->elf_ex.e_phnum; i++, elf_ppnt++)
if (elf_ppnt->p_type == PT_GNU_STACK) {
if (elf_ppnt->p_flags & PF_X)
executable_stack = EXSTACK_ENABLE_X;
else
executable_stack = EXSTACK_DISABLE_X;
break;
}

Keep in mind that only those three constants about executable stack are defined in the kernel (linux-2.6.32.61/include/linux/binfmts.h):

/* Stack area protections */
#define EXSTACK_DEFAULT    0  /* Whatever the arch defaults to */
#define EXSTACK_DISABLE_X  1  /* Disable executable stacks */
#define EXSTACK_ENABLE_X   2  /* Enable executable stacks */

Later on, the process’ personality is updated as follows:

     /* Do this immediately, since STACK_TOP as used in setup_arg_pages may depend on the personality.  */
SET_PERSONALITY(loc->elf_ex);
     if (elf_read_implies_exec(loc->elf_ex, executable_stack))
current->personality |= READ_IMPLIES_EXEC;

if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space)
current->flags |= PF_RANDOMIZE;
…

elf_read_implies_exec() is a macro in linux-2.6.32.61/arch/x86/include/asm/elf.h:

/*
* An executable for which elf_read_implies_exec() returns TRUE 
 * will have the READ_IMPLIES_EXEC personality flag set automatically.
*/
#define elf_read_implies_exec(ex, executable_stack)
(executable_stack != EXSTACK_DISABLE_X)

In our case, having an ELF binary with the PF_EXEC flag enabled in the PT_GNU_STACK program header, that macro will return TRUE since EXSTACK_ENABLE_X != EXSTACK_DISABLE_X, thus, our process’ personality will have READ_IMPLIES_EXEC flag. This constant, READ_IMPLIES_EXEC, is checked in some memory related functions such as in mmap.c, mprotect.c and nommu.c (all in linux-2.6.32.61/mm/). For instance, when creating the VMAs (Virtual Memory Areas) by the do_mmap_pgoff() function in mmap.c, it verifies the personality so it can add the PROT_EXEC (execution allowed) to the memory segments [1]:

     /*
* Does the application expect PROT_READ to imply PROT_EXEC?
*
* (the exception is when the underlying filesystem is noexec
*  mounted, in which case we dont add PROT_EXEC.)
*/
if ((prot & PROT_READ) && (current->personality & READ_IMPLIES_EXEC))
if (!(file && (file->f_path.mnt->mnt_flags & MNT_NOEXEC)))
prot |= PROT_EXEC;

And basically, that’s the reason of why code in the data segment can be executed when the stack is executable.

On the other hand, I had an idea: to delete the PT_GNU_STACK program header by changing its corresponding program header type to any other random value. Doing that, executable_stack would remain EXSTACK_DEFAULT when compared in elf_read_implies_exec(), which would return TRUE, right? Let’s see:


The program header type was modified from 0x6474e551 (PT_GNU_STACK) to 0xfee1dead, and note that the second LOAD (data segment, where our code to be executed is) doesn’t have the ‘E’xecutable flag enabled: 

 

The code was executed even when the execution flag is not enabled in the program header that holds it. I think it’s a logic bug in elf_read_implies_exec() because one can simply delete the PT_GNU_STACK header as to set executable_stack = EXSTACK_DEFAULT, making elf_read_implies_exec() to return TRUE. Instead comparing against EXSTACK_DISABLE_X, it should return TRUE only if executable_stack is EXSTACK_ENABLE_X:

#define elf_read_implies_exec(ex, executable_stack)
(executable_stack == EXSTACK_ENABLE_X)

Anyway, perhaps that’s the normal behavior of the Linux kernel for some compatibility issues or something else, but isn’t it weird that making the stack executable or deleting the PT_GNU_STACK header all the memory segments are loaded with execution permissions even when the PF_EXEC flag is not set?

What do you think?
Side notes:
–       Kernel developers pass loc->elf_ex and never use it in:
#define elf_read_implies_exec(ex, executable_stack) (executable_stack != EXSTACK_DISABLE_X)

–       Two constants are defined but never used in the whole kernel code:
#define INTERPRETER_NONE 0
#define INTERPRETER_ELF  2
Finally, I’d like to thank my collegues Ilja van Sprundel and Diego Bauche Madero for giving me some ideas.
Thanks for reading.
References:
[1] “Understanding the Linux Virtual Memory Manager”. Mel Gorman.
Chapter 4 – Process Address Space.

 

INSIGHTS | November 15, 2013

heapLib 2.0

By Chris Valasek
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/). 

The zip file contains: 
  • heapLib2.js => The JavaScript library that needs to be imported to use heapLib2
  • heapLib2_test.html => Example usage of some of the functionality that is available in heapLib2
  • html_spray.py => A Python script to generate static HTML pages that could potentially be used to heap spray (i.e. heap spray w/o JavaScript)
  • html_spray.html => An example of a file created with html_spray.py
  • get_elements.py => An IDA Python script that will retrieve information about each DOM element with regards to memory allocation in Internet Explorer. Use this Python script when reversing mshtml.dll. Yes, this is really bad. I’m no good at IDAPython. Make sure to check the ‘start_addr’ and ‘end_addr’ variables in the .py file. If you are having trouble finding the right address do a text search in IDA for “<APPLET>” and follow the cross reference. You should see  similar data structure listings for HTML tags. The ‘start_addr’ should be the address above the reference to the string “A” (anchor tag). 
  • demangler.py => Certainly the worst C++ name demangler you’ll ever see. 
If anyone would like my IDBs or poorly taken notes, just let me know and I’ll send them off. With all that said, I hope at least one person enjoys the library: http://illmatics.com/heapLib2.zip
 
I’d love feedback, comments, suggestions, etc. If you use this library, feel free to buy me a beer if and when you see me . 
INSIGHTS | October 22, 2013

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

By Lucas Apa

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.

The thin line of legality at that time was blurred by actions not considered illegal. This allowed an explosion of hacking groups, material, and magazines. Many of the hacking techniques that still prevail today started in the early century. At that time I lacked good programming skills and an Internet connection in my homeland, Argentina. I got interested in packers and solved many crackmes because I wondered how commercial games built anti-cracking protections. At that time pirated games were heavily distributed in my country. Having some experience with debuggers allowed me to quickly learn the foundations of programming languages. Many years of self-education and a soon to finish computer engineering degree finally gave me sufficient insight to comprehend how modern software works.

When I was a teenager, I also had the opportunity to explore other areas related to computers, such as 3D modeling (animated short films) and producing psychedelic trance music. All these artistic and creative expressions help me appraise and seize an opportunity, especially when seeing how a new exploitation technique works or providing a new innovative solution or approach to a problem.

There was a moment that I realized the serious effort and true thirst I needed to achieve what could be impossible for other people. The security industry is highly competitive, and it sometimes requires extreme skills to provide a comprehensive response or a novel methodology for doing things. The battle between offensive and defensive security has always been entertaining, pushing the barrier of imagination and creativity every time. This awakens true passion in the people who like being part of this game. Every position is important, and the most interesting part is that both sides are convinced that their decisions are right and accurate.

I like to research everything that could be used to play a better offense in real-world scenarios. Learning about technologies and discovering how to break them is something I do for a living. Defensive security has become stronger in some areas and requires more sophisticated techniques to reliably and precisely defeat. Today, hacking skills in general are more difficult to master because of the vast amount of information that is available out there. Great research demands a conceptual vision and being reckless when facing past experiences that show that something is not achievable. My technical interests involve discovering vulnerabilities, writing exploits, and playing offensive in CTF’s; something close to being inside the quicksand but behind defensive lines. This is one of my favourite feelings, and why I choose to work on security everyday.

My first advice to someone who would like to become a pen tester or researcher is to always maintain patience, dedication, and effort. This is a very satisfying career, but requires a deep and constant learning phase. Having a degree in Computer Science/Engineering will help you get a general overview of how the technology world works, but much of the knowledge and abilities can only be learned and mastered with personal intensive training. Technology changes every year, and future systems could be much different than today’s. The key is to not focus too much on one thing without tasting other fields inside the security world. Fortunately, they can be combined since in this career all the subjects have the same goal. Learn to appreciate other investigative works, blog posts, and publications; every detail is sometimes a result of months or weeks worth of work. Information is relatively available to everyone, you just need to dive in and start your journey with the topics you like most.

INSIGHTS | October 21, 2013

NCSAM – Eireann Leverett on why magic is crucial

By Eireann Leverett & Craig Brophy
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.

IOActive: How did you get into security?
 
Eireann: Actually, I was very slow to get security as an official title for a job, it was only really in the last few years. However, I always knew that’s how my mind was bent.
For example, everything I know about software security I learned from card tricks at 14. I know it seems ridiculous, but it’s true. Predicting session id’s from bad PRNGs is just like shuffle-tracking and card counting. Losing a card in the deck and finding it again is like controlling a pointer. If you understand the difference between a riffle shuffle and an overhand shuffle you understand list manipulation.
Privilege escalation is not unlike using peeks and forces in mentalism to corrupt assumptions about state. Cards led me to light maths and light crypto and zero-knowledge proofs.
From there I studied formally in Artificial Intelligence and Software Engineering in Edinburgh. The latter part took me into 5+ years Quality Assurance and Automated Testing, which I still believe is a very important place to breed security professionalism.
After that I did my Master’s at Cambridge and accepted a great offer from IOActive mixing research and penetration testing. Enough practicality so I’m not irrelevant to real world application, and enough theory & time to look out to the horizon.
IOActive: What do you find most exciting about security?
 
Eireann: The diversity of subjects. I will never know it all, and I love that it continually evolves. It is exciting to pit yourself against the designs of others, and work against malicious and deceptive people.
There are not many jobs in life where you get to pretend to be a bad guy. Deceptionists are not usually well regarded by society. However, in this industry having the mindset is very much rewarded.
There’s a quote from Houdini I once shared with our President and Founder, and we smile about it often. The quote is:
“Magic is the right way to do wrong.”
That’s what being an IOActive pirate is: the right way to do wrong. We make invisible badness visible, and explain it to those who need to understand business and process instead of worrying about the detail of the technology.
IOActive: What do you like to research, and why?
 
Eireann: Anything with a physical consequence. I don’t want to work in banking protecting other people’s money. My blood gets flowing when there are valves to open, current flowing, or bay doors to shut. In this sense, I’m kind of a redneck engineer.
There’s a more academic side to me as well though and my research passions. I like incident response and global co-operation. I took something Team Cymru & Dragon Research said to heart:
“Security is more about protecting your neighbours.”
If you don’t understand that your company can be compromised by the poor security of your support connections you’ve missed the point. That’s why we have dynamic information sharing and great projects like openIOC, BGPranking, honeynets, and organisations like FIRST. It doesn’t do you any good to secure only yourself. We must share to win, as a global society.
IOActive: What advice would you give to someone who would like to become a pentester/researcher?
 
Eireann: Curiosity and autodidacticism is the only way.
The root to hacking is understanding. To hack is to understand something better than it understands itself, and then nudge it to alter outputs. You won’t understand anything you listen to other people tell you about. So go do things, either on your own, or in formal education. Ultimately it doesn’t matter as long as you learn and understand, and can articulate what you learned to others.
INSIGHTS | October 18, 2013

NCSAM – an Interview with Cesar Cerrudo

By Cesar Cerrudo & Craig Brophy
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!

IOActive: How did you get into security?
 
Cesar: I think my first hacks were when I was 10 years old or so. I modified BASIC code on CZ Spectrum games and also cheated games by loading different parts of the code from a cassette (yes not floppy disk at that time and loading games from a cassette took around 5-10mins and if something went wrong you have to try again, I don’t miss that at all ), but after that I was mostly away from computers until I was 19 years old and went to college.
I was always interested on learning to hack but didn’t have enough resources or access to a PC. So while I was at college I started to read books, articles, etc. – anything I could get my hands on. I used to play (and sometimes break) a friend’s PC (hi Flaco ) once in a while when I had the opportunity. I remember learning Assembly language just from reading books and looking at virus code printed in papers. Finding that virus code and learning from it was amazing (not having a PC wasn’t a problem; a PC is just a tool).
Later on, with some internet access (an hour or so a week), it became easier since lots of information became available and I got access to a PC; so I started to try the things I read about and started to build my own tools, etc.
When you’re learning and reading, one topic takes you to another topic and so on, but I focused on things that I was more familiar with – like web apps, database servers, Microsoft Windows, etc.
Luckily in Argentina it wasn’t illegal to hack at that time so I could try things in real life and production systems . A long time ago, I remember walking to the office of the CEO of my local ISP provider handing him hundred thousands of users, passwords and credit card information and telling him that their servers where hackable and that I hacked them. I know this sounds crazy but I was young and in the end they thank me, and I helped them identify and fix the vulnerabilities. I asked for a job but no luck, don’t know why .
I also did other crazy hacks when I was young but better to not talk about that , nothing criminal. I used to report the vulnerabilities but most admins didn’t like it. I recommend not engaging in anything illegal, as nowadays you can easily end up in jail if you try to hack a system. Today it is simpler to build a lab and play safely at home.
Luckily those crazy times ended and soon I started to find vulnerabilities in known and widely used software such as SQL Server, Oracle, Windows, etc., I was then also able to create some new attack and exploitation techniques, etc.
IOActive: What do you find most exciting about security?
 
Cesar: Learning new things, challenges, solving difficult problems, etc. You get to deeply study how some technologies work and can identify security problems on software/hardware massively used worldwide that sometimes have big impact on everyone’s lives since everything has become digital nowadays.
IOActive: What do you like to research, and why?
 
Cesar: This is related to previous answers, but I like challenges, learning and hacking stuff.
IOActive: What advice would you give to someone who would like to become a pentester/researcher?
 
Cesar: My advice would be if you are interested in or like hacking, nothing can stop you. Everything is out there to learn. You just need to try hard and put in a lot of effort without ever giving up. Nothing is impossible it’s just matter of effort and persistence.
INSIGHTS | 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.
What I didn’t know at the time was that the 2.0-2 patch wasn’t as effective as one would have hoped; in most cases bad and predictable credentials were left in place intentionally – as in I was informed that Monroe Electronics were “intentionally not removing the exposed key(s) out of concern for breaking things.”
In addition to not removing the exposed keys, it didn’t appear that anyone even tried to review or audit any other aspect of the DASDEC security before pushing the update out. If someone told you that you had a shared SSH key for root you might say… check the root password wasn’t the same for every box too right? Yeah… you’d think so wouldn’t you!
After discovering that most of the “patched” servers running 2.0-2 were still vulnerable to the exposed SSH key I decided to dig deeper in to the newly issued security patch and discovered another series of flaws which exposed more credentials (allowing unauthenticated alerts) along with a mixed bag of predictable and hardcoded keys and passwords. Oh, and that there are web accessible back-ups containing credentials.
Even new features introduced to the 2.0-2 version since I first looked at the technology appeared to contain a new batch of hardcoded (in their configuration) credentials.
Upon our last contact with CERT we were informed that ‘[t]hese findings are entering the realms of “not terribly serious” and “not something the vendor can practically do much about.”‘
Go team cyber-security!
So… on one hand we’ve had one zombie alert and a good hand-full of responsibly disclosed issues which began back in January 2013… on the other hand I’m not sure anything changed except for a few default passwords and some version numbers.
Let’s not forget that the EAS is a critical national infrastructure component designed to save lives in an emergency. Ten months on and the entire system appears more vulnerable than when we began pointing out the vulnerabilities.
INSIGHTS | October 16, 2013

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

By Ian Amit
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! 🙂
INSIGHTS | October 15, 2013

IOActive supports National Cyber Security Awareness Month

By Craig Brophy
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.

The 10th anniversary of NCSAM looks ahead at the cyber security challenges for the next ten years. So, over the next few days and weeks we will be publishing some short blog posts from our researchers and consultants to show our support for this good cause.

The first round of posts – given that this week is slated to highlight the ‘cyber workforce and the next generation of cyber leaders’ – will be from our international research team giving insight into how they got into the world of cyber security. From getting their first computers, their studies through to what they enjoy most about security and why.

If anything, we hope these posts will help encourage our young generation to pick up their pens and their computers and explore the realm of cyber security.

 

So keep an eye out for these posts over the coming days. And if you have any questions or comments relating to the blog posts, please feel free to let us know. We welcome the discussion.
INSIGHTS | October 3, 2013

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

By Ian Amit
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.

This year I delivered the keynote on the first day, and albeit being a bit harsh on the whole “let’s buy stuff so we can think we are secure” approach, it was very well received. Apparently, stating the “obvious” – which is that a security function in an organization is tasked with risk management of said organization, rather than with dealing purely with the technical IT infrastructure for it.
Next up was DerbyCon. I can’t stress enough how much fun it is to run the Red Teaming Training class with my best friend Chris, and the kind of feedback (and learning) we have a chance to get. The biggest return for us every time we deliver the training is watching the trainees open up and really “get” what red team testing is all about, and the kind of value it brings to the organization being tested. This moment of enlightenment is sheer joy from me still.
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. I 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.
I’m really looking forward to getting more feedback on it, and more discussions on how to communicate the essence of red teaming to organizations – which is always a challenge in internal organization politics.
Following are the slides. Have fun!
INSIGHTS | September 10, 2013

Vulnerability bureaucracy: Unchanged after 12 years

By Cesar Cerrudo

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

It’s really sad to tell that, as of right now, 12 years later, I continue to see most (if not all) of the same problems. Not only that, but some organizations that are supposed to help and coordinate vulnerability reporting and disclosure (CERTs) are starting to fail, being non responsive and not contributing much to the effort.
This shouldn’t be a big problem if you are reporting low impact or unimportant vulnerabilities, but most of the time the team here at IOActive report critical vulnerabilities affecting systems ranging from critical infrastructure to the most popular commercial applications, OS’s, etc. used by millions of people around the world. There is a big responsibility upon us to work with the affected vendors to get the vulnerabilities fixed and thinking about how bad things could be if they are exploited.
It’s also surprising to sometimes see the tardy response from some teams that are supposed to act and respond fast such as Android security team given that Google has some strong vulnerability polices (1, 2):
It would be nice if most vendors, CERTs, etc. are aware of the following:
  • Independent researchers and security consulting companies report vulnerabilities on a voluntary basis.
  • Independent researchers and security consulting companies have no obligation to report security vulnerabilities.
  • Independent researchers and security consulting companies often invest a lot of time, effort and resources finding vulnerabilities and trying to get them fixed.
  • Vendors and CERTs should be more appreciative of the people reporting vulnerabilities and, at the very least, be more responsive than they typically are today.
  • Vendors and CERTs should adhere and comply with their own defined deadlines.
I would like for vendors and CERTs to start improving a little and becoming more responsive; the attack surface grows everyday and vulnerabilities affect our lives more and more. The more we depend on technology the more the vulnerabilities will impact us.
There shouldn’t be vulnerability bureaucracy.
If there’s one thing that vendors and CERTs could do to improve the situation, that would be for them to step-up and be accountable for the vulnerability information entrusted to them.
I hope that in the following 12 years something will change for the better.