Cyber National Guard

May 6th, 2013

I’ve spent my almost my entire career working with Federal agencies to write and secure software. The bad guys are increasing in number and getting more sophisticated, so the problem is very difficult to control. The industry needs trained professionals to combat this problem, but there’s just not enough people. Specifically for the government, you’re not going to find top talent working there (unless it’s intel and it’s offensive…that’s enticing). I’m sure there are many patriotic white hats, myself included. Why not let them volunteer? The National Guard provides plus-up capabilities for the armed forces…why not do the same for cyber operations?

The Cyber National Guard is an interested idea in my mind. Do a certain level of training per month as a member of the armed forces. If a cyber problem pops up, a cyber group gets activated to help combat the problem. There will have to be a few changes to the traditional National Guard model in order to attract good white hats:

  • No PT (physical training) – We’re computer geeks. Some of us are physically fit, but that’s their choice. We’re not going to be running into battle, so no PT. Ever.
  • Do Exercises Remotely – In today’s National Guard, you train on-site with your group. This won’t work for techies. Since the work is all online, keep it online. We might be okay for a yearly on-site for intense training, but keep it low

There you go, problem solved. Ask for volunteers, let them get some of the benefits of being in the National Guard, and you’ll get a cyber force. There will still be some work on getting the level of expertise you want, but at least then you can train them up to the desired capability level.

This idea is probably really bad and will never happen, but it sounds cool in theory.

IT Security

Did I Say Something?

March 26th, 2013

A couple of weeks ago I was a speaker at a seminar hosted by the ISSA Colorado Springs chapter. The idea was to talk to some federal guidance coming down the pipe, the 2013 National Defense Authorization Act if you haven’t heard. The rest of the talk was some basic steps to start a Software Assurance process.

In the beginning of the talk I had a timeline of some breaches and also important legislation. I mad e a comment about 2008 being an important year because of the Heartland breach. I mentioned the amount of records breached and, in passing, said that they had just passed a PCI inspection.

Boom. A hand shoots up and it’s a guy from the PCI Council. As he informed me, there are only 26 people on the Council responsible for forming the PCI-DSS. First of all, I should have left the seminar and bought a lottery ticket. He goes into a long comment about his frustration with speakers pinging PCI when it is just a security baseline. He was clearly upset with my comment, but it opened a good opportunity for my presentation.

I agreed with him that PCI does not equal security, but that’s the problem with legislation and standards. Once an organization achieves compliance, they feel like they’ve done enough. To the bean counters in Finance, it can be difficult to justify more spending that what is “necessary”. We as security people wage that battle every day, and it will continue.

At the time of the Heartland breach, there was zero in PCI-DSS focused on applications. Later revisions would change that, but only a little. The major point of presentation was that the latest NDAA has provisions requiring the Department of Defense to start securing their applications. That’s one small step for mankind, but one huge step for the DoD.

After getting off the stage, I was talking with a colleague about the PCI comment. He mentioned that is the exact reason he doesn’t use absolutes when speaking in front of groups. I can see the logic in that viewpoint, but if you use passive voice all the time your not authoritative. If you can’t say something authoritatively, you probably shouldn’t be on stage talking about it. Even though there was some tension for a second, it made people pay attention because it was interesting.

I had to catch a flight after the talk, so I didn’t get a chance to talk with the PCI guy. I would have liked to thank him for his comment and for helping me make my point. I probably could have explained my comment more to show I wasn’t attacking PCI-DSS directly…I was showing our reliance on compliance is completely dependent on the level of security provided by the standard.

Software Security

It’s Amazing How Far Templates Have Come

January 4th, 2013

While I was in college me and some friends starting writing a web app for student organizations. It wouldn’t have been Facebook, but it was fun nonetheless. We spent a considerable amount of time working on the interface and trying to take our ideas to actual code. We never finished it. There was just too much coding to be done by inexperienced coders.

I’m not a designer. I know enough about graphic design tools to be dangerous, but it’s just not my strong point. At anytime that I’ve wanted to build an app, building the interface was always the most frustrating.

Today, getting the interface part done is much easier. Recently I had an idea for an app and I started sketching out the design. I headed over to ThemeForrest to see if I can find a template to fit what I want. Sure enough, I found a web app template that did 90% of what I wanted in a very appealing design. I also got a template for the public facing site. After getting a logo designed on Elance for $50, I’ve spent $90 to move past most of the interface design and go directly to coding the app. Awesome sauce. It’s amazing to me how low the cost of entry is for developing web applications now. Why are you reading this…go create an app!


Resetting/Fixing the Root Password in Ubuntu 12.10

October 31st, 2012

Recently I was building a VM box using VirtualBox. I needed to add myself to the vboxusers group so I could get access to the USB devices. I left off a flag to usermod and accidentally removed myself from the “sudo” group, leaving me without root access. Crap. In the past, I would reboot and then drop into a root shell to add myself back to the “sudo” group. I tried that and I found that in a recent release, Ubuntu started requiring a password to get access to the root shell. Because of this, I needed another way to add myself to the “sudo” group. After much Googling, I found this:

The first answer has some good stuff, but the only incorrect command is that at the end it says to add yourself to the “admin” group. That should be the “sudo” group. To make sure the steps are saved for myself and whoever wants to use them:

1. Grab an Ubuntu live disk and boot in “try ubuntu” mode
2. Mount the drive (in my case, sda1)
3. chroot to the mounted drive.
4. We now have a root shell, execute “ usermod -a -G sudo username”

Voila. Then unmount the drive and restart.


Security Vulnerabilities in Sample Code

May 27th, 2012

When I first started learning .NET back in 2005, I bought an ASP.NET 2.0 in 24 Hours type book to get the ball rolling. .NET was my first managed language, so it all was pretty new to me. I had spent plenty of time writing in C/C++ and PHP. I didn’t care about security, I just wanted it to work. Fast forward a few years and I’m now a security guy. When I read how-to books now, I’m always looking for security vulnerabilities in sample code. This is a common problem and really starts new programmers on the wrong foot. I completely understand wanting to make sample code very easy to understand, but if we keep security an advanced topic, it never gets read. I’m guilty of reading 2/3rd of a programming book and then not finishing it because I want to go code. We need to build security into every step of our curricula just as we do our SDLCs.

This weekend I was looking at a Microsoft tutorial on MVC 3. They have a basic example of a HelloWorld app that echoes out a name from the GET request. When I saw them setting up the example, I quickly thought cross-site scripting.

I was surprised to see the HtmlEncode method there, well done Microsoft! While this function only partially fixes the problem (HtmlEncode from the HttpUtility class only HTML encodes certain characters, so XSS is still possible but difficult). Using the AntiXss library would have been better. They also don’t explain why they HTML encoded the output. A simple paragraph stating we do this to fight XSS and here’s a link for more info would have been good. Nevertheless, I was happy to see this. My hat’s off to you Microsoft.



Software Security

We Got Hacked? How Did That Happen?

March 23rd, 2012

There’s an interesting article on Threatpost’s Tumblr showing a graphic of 2011 attacks, their impact, and the attack type.

The data was taken from the latest Verizon Data Breach report for 2011, which if you haven’t read you should. Great stuff. There are a few observations to take away from this graphic regarding Application Security:

  • SQL Injection is still popular
  • Where are the other AppSec attacks?
  • In many of the breaches, the attack vector is “Unknown”

SQL Injection is Still Popular

SQL Injection has been the long running king of many top vulnerability lists and there doesn’t seem to be any threats to the thrown. SQL Injection is no doubt one of the nastiest appsec vulnerabilities, but it’s sad that SQL Injection is still such an issue. SQL Injection isn’t new, it’s been around for a long time. Why can’t we kill this one bad vulnerability? Focus. Critical vulnerabilities do get the main focus, but our software assurance programs focus on holistic approaches. I think we may need to change that. Don’t stop the holistic approach, but as the AppSec community we should make 2012 the year that SQL Injection got it’s face stomped in. All AppSec people put a special emphasis on identifying and fixing just SQL Injection. If you’re reading this and you have influence over AppSec, let’s focus just on SQL Injection.

Where are the other AppSec attacks?

SQL Injection is the only pure AppSec attack vector mentioned in this graph. URL Tampering and “3rd Party Software” might have some AppSec context, but it’s hard to tell. We all know that there are a significant amount of application attacks. I’m curious to know if XSS was used in any of the phishing attempts. Phishing gets interesting when you can include a link to their company web site. Are we just missing those parts of the attacks? That leads me into:

In many of the breaches, the attack vector is “Unknown”

The amount of “Unknown” attack vectors here is a little troublesome. Of course, we have to assume some of the unknowns are because the attack vector hasn’t been announced. Some of them though are because our ability to monitor our infrastructure and applications is pretty low. Organizations have spent tons of money and time implementing firewalls, IDS, IPS, SIEM, etc yet we still don’t always know how the attackers get in. From the application security standpoint, I can honestly say our understanding of what’s going on inside of applications is very limited. Most developers think that log files are places to stick stack traces when something breaks. Log files should be so much more. They should log sensitive user activities, access to data, errors, and security events. After an attack, looking through error logs might tell us a little about how the attacker got access to data. It usually doesn’t tell us what data was compromised. We need more visibility into our applications so we can tell normal traffic from abnormal traffic, attack activity, and what data is being accessed.

Software Security

Software Security Education

March 8th, 2012

Most of my time is spent talking with customers about using technology to help fix software vulnerabilities. Technology is a very small piece of a software assurance program. Buying static analysis or dynamic analysis products just shows you your problems. The more human elements around fixing and preventing vulnerabilities can’t be bought via a technology buy.

The root cause of software security vulnerabilities typically start with developers (minus issues created by poorly configured production environments and such), but it’s really not their fault. We train software developers to think functionally. If I click this button, this action occurs. What we don’t teach developers is what if a user clicks the button repeatedly? How could an attacker misuse/abuse an application to make it do things outside of the intended design? Most universities are not teaching secure coding. If they are, it’s usually graduate level. Have you looked at one of those “Lean x Language in 24 Hours” books? Some of the examples have security vulnerabilities. I can fully appreciate not wanting to overwhelm a new developer, but the security education has to come at some point. As usual, security is something that gets bolted on later.

Educating developers on software security is an interesting topic because not many people are trying to solve the problem. The focus is more on buying software or consulting services. Today if you want software security training you’re limited to consultant lead classes, CBTs, or self study through the handful of books available. Consultant lead classes tend to be Death by PowerPoint and CBTs are really just another form of Death by PowerPoint. Early in my training career, I delivered mostly PowerPoint training with some hands-on exercises. What I found was that developers didn’t retain enough information to fix their code. I added more hands-on exercises and retention got much better. I already knew that developers learn best by doing, but I didn’t realize just how much a difference it would make.

I haven’t tested this theory, but I believe the absolute best way to train developers would be through a software security project over a few weeks. Start with an idea for an application and move through each step of the software development life cycle with the current security activities. Include security in the requirements phase and architecture design. Do threat analysis and feed the results into the architecture design. Write code and perform code reviews. Test code functionally, but also include misuse/abuse cases. Grab some vulnerability analysis tools and run scans. Write deployment documentation including security and harden production environment. Application development with security from soup to nuts. After going through the exercise, developers will be much better equipped to replicate the experience.


IT Security

SQL Injection and Persistent Cross Site Scripting

January 5th, 2012

A news article came through my twitter feed this morning about a new SQL Injection attack that has affected over 1M web sites:

The attack inserts a malicious JavaScript tag into your page redirecting your users to the attacker’s site. This is probably just semantics, but they are missing another vulnerability here: persistent cross site scripting.

For those not aware of what SQL Injection is, this vulnerability occurs when unvalidated data is mixed with SQL logic to change the nature of a SQL query. That may be a little confusing, so here’s an example. Let’s say you have a login page that has two text boxes: one for a username and one for a password. When the user clicks submit, the information is put into a SQL query to see if the user is exists:

SELECT username FROM users WHERE username=’username’ AND password=’password’;

That looks pretty simple. If I put “eric” as the username and “1234″ as the password, the query looks like:

SELECT username FROM users WHERE username=’eric’ AND password=’1234′;

But what if I put “1234′ or ’1′=’1″ in the password field?

SELECT username FROM users WHERE username=’username’ AND password=’1234′ or ’1′=’1′;

For the non-SQL folks, that will retrieve all records in user table, because it’s asking “give me all rows where username=x and password=x or when 1=1″. 1 will always equal 1, so every row will be returned. In the case of this attack, attackers were able to insert a script tag into the database that eventually gets inserted into the HTML of the site. That is where persistent cross site scripting comes in.

Cross site scripting (or XSS for short) is where untrusted/unvalidated data is inserted into the page. There are three main types of XSS. but let’s focus on the persistent flavor. Persistent XSS occurs when data is retrieved from the database and inserted into the page without being validated and encoded. What’s the problem with that? This is always a hard pill for developers to swallow, but your database is not a trusted store for data. See the above example for why! 

To demonstrate persistent XSS, let’s say that the content of a blog article is stored in your application’s database. You want to post that article on your blog, so that data is pulled out of the database and inserted into the page. The article content looks like this:

The Auburn Tigers successfully routed the University of Virginia in the Chick-fil-a bowl! The Tigers will graduate very few seniors, so let’s hope for a better season next year.

Inserting that directly into a page doesn’t look bad, but if I use the SQL Injection attack above to edit the content of this article I could attack your users:

The Auburn Tigers successfully routed the University of Virginia in the Chick-fil-a bowl! The Tigers will graduate very few seniors, so let’s hope for a better season next year. <script src=””>

When any user visits the page with the article, the JavaScript from will execute. This could do many things, but the most popular is redirecting to a malicious site where the attacker has control over the entire session. 

So the SQL Injection sets up the attack, but the persistent XSS is actually the vulnerability being exploited here. If the persistent XSS was fixed, then no redirect. SQL Injection is still a serious vulnerability (#1 on OWASP Top 10) that should be fixed immediately.

So how do you fix these vulnerabilities? I can write entire blog posts for these attacks…but here’s a quick explanation.

First, a word about input validation. NEVER trust data that comes from a source you don’t control. Data from a user, web service, database, external system, are outside the sphere of influence of the application, so VALIDATE the data. 

The best way to fix SQL Injection is to use parameterized queries. Parameterization is basically putting place holders into your SQL query, and the letting your platform insert the data for you. This will fix the vast majority of SQL Injection issues. Every platform is a little different, so try googling “parameterizing SQL queries” for your specific language to get an example.

For cross site scripting, the best fix is using encoding. If the data is being inserted into HTML, use HTML encoding. This will encode all of the malicious characters, not allowing them to be executed. Not all encoding libraries are good enough. Check out the OWASP ESAPI or the Anti-XSS Library from Microsoft if you’re using .NET.

IT Security

Regulation and Competativeness

October 8th, 2011

I recently read an article quoting some “cyber security experts” discussing off-shoring and cyber security. Part of the article says that the government should not regulate software security because this will increase the cost of software and push more development over seas. There is some logic to this argument, but it’s the same excuses I hear from software developers who don’t want to fix their code. The argument being made is “I can give you crappy software at a price that is competative with off shored labor, or we can give you good code for a price that’s so large it will make you be okay with off shoring”. 

I’m not a fan of government regulation, but something has to give. For decades the general public has been acting as beta testers while software vendors work the kinks out of their software. The obvious downside is weekly security updates from Microsoft, malware that can take over a computer in a single click, and the building of zombie computer armies. While we are seeing some companies get better about writie secure code, it’s not industry wide. Security remains as a obstacle to getting to market quickly and an afterthought once in the market. This mentality will continue until something changes.

The Payment Card Industry Data Security Standard (PCI DSS) is a great example of self regulation. PCI DSS is not perfect by any means, ask Heartland Payment System, but it forced some companies to make security a priority. Even if the priority is just to pass an audit, this is still possitive yardage for their customers. The private and public sectors need something like PCI DSS. 

The answer could be self regulation. A consortium of software vendors agreeing to a security standard and then being able to put the groups logo on their software. Will this happen? Probably not. Humans usually don’t change until there is a large enough event to make the change happen. I would rather not wait around for that event, so government regulation (or the threat of government regulation) is the next best thing. 

A part of whatever regulation that comes about should include stipulations for supply chain risk management. Code coming from off shored development shops is sub par functionally speaking and even worse for security. If we are going to make software secure, it has to start at the requirements and be a part of design, coding, testing, and production. Who writes the code or where it is written should not matter. Developing software without security is writing crappy code plain and simple.

If this makes the cost of software rise, so be it. I would much rather pay more for software and not have to worry about clicking a link that will take over my computer, steal my bank password, and then make me spend hours on the phone trying to get my money back.


Some Light on False Positives and Static Analysis

July 9th, 2011

I’ve noticed my blog has been getting a lot of traffic lately regarding false positives and custom rules for Fortify. Full disclosure: I am a Fortify consultant. The number one complaint I hear about Fortify’s static analysis product (Fortify SCA) is that it produces too many false positives. To understand why this happens, some context is needed on Fortify’s design and purpose.

caveman_airportWhen the cavemen wrote code, they would use manual code review to look for bugs and security holes. There is a place for manual code review, but its costly and the effectiveness depends on the security education level of the reviewers. Manual code review usually leads to a high false negative rate, especially in complex applications. To make sure everyone is on the same page here, a false positive is where an issue is found that is really not an issue. A false negative is where an issue is missed, leaving a vulnerability in the code.

Fortify SCA was created to help automate the manual code review process. SCA looks through your source code and finds possible vulnerabilities…emphasis on possible. SCA errs on the side of reducing false negatives. The corollary to that is we produce more false positives. We do that because we would rather produce some false positives to avoid missing real issues. We do our best to understand the application, but let’s face it: static analysis is just one algorithm scanning another. There’s no way for ANY static analysis software to not produce false positives.

I also encounter many developers calling real vulnerabilities false positives because they don’t fully understand the finding. I recently received an email from a developer saying SCA found hundreds of persistent cross site scripting issues and that they were all false positives. He was convinced that since they do input validation, trusting the database was not a problem. We talked some about why the database is not a trusted source and he got the big picture.

For the most part, SCA does a decent job of reducing false positives. Many times the reviewers don’t understand the vulnerability or SCA’s criticality is too high for the given scenario. When it comes down to it, SCA is just a way of identifying potential issues. Its up to the reviewers to decide how they want to handle the output.

If you’re having problems with Fortify, send an email to Our support group is fantastic, so give that a go first. If you need help integrating Fortify into your SDLC, contact your Fortify rep to get a consultant on site.

Software , ,