This week's SANS NewsBites (Vol. 12, Num 67) has a story of the potential of security (or lack thereof) in the Spanair air crash that killed 154 people. According to the post, the official cause of the crash was due to pilot error. The investigation also discovered that a warning indicator did not activate. These events would have been logged in the company's maintenance system. It has been alleged that the maintenance system was riddled with malware. Could this be a case where not patching a system could indirectly lead to deaths?
Recently, I've audited systems and applications that reside in medical treatment facilities. One system was responsible for the delivery of radiation to patients. The vendor stated that they are the only authority allowed to administer patches to the system as they need to test out each and every patch before it could be released live in production so as not to endanger a patient. They talked about one particular case where the pushing of patches by a medical treatment facility enabled a system to administer too much radiation. And, if were not due to the diligence of an alert technician, fatal conditions would have been met.
Granted, the day-to-day security decisions and risk analysises we make are not going to be that critical. Heck, just driving to work each day we go through a risk analysis. Sure, there's a risk that we could get in an accident, but it's not that high and we accept it. But when it comes to mission-critical systems, or systems that are deemed of high importance, well thought-out risk analysis could be what causes or averts a dire situation.
Wednesday, August 25, 2010
Friday, August 13, 2010
Vulnerable Web Applications for testing and practice
I'm working on a small presentation for web application testing. In order to get the bullet points across, I want to have an application where the students can actually try the attacks and see the results as I find that this gets the points across more effectively than PowerPoint slides. Knowing only a handful of the more popular applications, I started searching. Google gave me more than I could imagine, and I'm listing a bunch of them here.
This first group are actual applications to be installed:
Vincum
OWASP WebGoat
OWASP Insecure Web App Project
Damn Vulnerable Web App
Hacme Travel
Hacme Bank
Hacme Shipping
Hacme Casino
Hacme Books
Mutillade
The Butterfly Project
Stanford SecuriBench
BadStore
Gruyere
WackoPicko
BodgeIt Store
Live sites (hosted on the internet):
SPI Dynamics
Cenzic
Watchfire
Acunetix (php)
Acunetix (asp)
NT Objectives
If I have missed a good one, please let me know. I haven't picked one yet, I'm still evaluating. But I'll add to the list as I hear of and try more applications.
edit: 4-19-2011 added BodgeIt Store
This first group are actual applications to be installed:
Vincum
OWASP WebGoat
OWASP Insecure Web App Project
Damn Vulnerable Web App
Hacme Travel
Hacme Bank
Hacme Shipping
Hacme Casino
Hacme Books
Mutillade
The Butterfly Project
Stanford SecuriBench
BadStore
Gruyere
WackoPicko
BodgeIt Store
Live sites (hosted on the internet):
SPI Dynamics
Cenzic
Watchfire
Acunetix (php)
Acunetix (asp)
NT Objectives
If I have missed a good one, please let me know. I haven't picked one yet, I'm still evaluating. But I'll add to the list as I hear of and try more applications.
edit: 4-19-2011 added BodgeIt Store
Tuesday, August 10, 2010
Free Monitoring Tools for Systems and Networks
The SANS Internet Storm Center has a great post today, that I'm linking to in order to come back to it as there are some great monitoring tools (free or inexpensive) for various operating systems.
Monitoring Tools
As there are a lot of posts at the Storm Center, I'm sure I'll lose this one if I don't create a link to it. Hopefully it will help out someone else.
Monitoring Tools
As there are a lot of posts at the Storm Center, I'm sure I'll lose this one if I don't create a link to it. Hopefully it will help out someone else.
Sunday, July 11, 2010
Book Review: SQL Injection Attacks and Defense by Justin Clarke
Wow! What a great book. But let me put this in perspective first. As a DoD autditor, I do many audits where the enclave/system has a web server with application(s) residing somewhere on a web/application server. Many times these are GOTS applications that need auditing under the auspices of the Application Security and Development checklist. That checklist is rather large, and covers the whole spectrum of application development. A good portion of the checklist is manual in nature; either looking at configurations, checking documentation, or interviewing the appropriate personnel with regards to the application. There are a few controls for which we run an automated tool looking for some of the major vulnerabilities (command injection, XSS, SQLi, limited buffer overflows, temp files, error messages, etc.)
I bought this book so I could understand the underpinnings of the SQL injection: why it exists, how to make it work, and to some degree, how to fix them. (I don't need to fix them, however, it's nice to be able to help the client mitigate open vulnerabilities.) I have prior SQL experience (coming from the DBA/DBD world) so the concepts of SQL are quite familiar to me. And of course, when most people think of SQLi, they think of the familiar ' or 1=1. I wanted to know more, and I wanted a more advanced knowledge. Sure, we run tools, but I wanted to be able to confirm our tool's output. And, I wanted the ability to perform the analysis manually. One other caveat worth mentioning, many of the systems I audit are CAC-enabled; which the tools we use do not handle too well. It's easy to manually log in, authenticate, and manually exploit/search for vulnerabilities.
I admit it, I bought the book mainly for chapters 2, 4, 5, 6, and 7. These chapters talk about testing for SQL injection, exploiting SQL injection, blind SQL injection, exploiting the operating system and advanced topics, respectively. And those chapters were great. I satisfied my objective to learn how to really accomplish the task of finding and somewhat-exploiting found inection-able fields. (We're not hired to pen-test, just audit....so we can't go nuts with a finding once we find it. The fact that the vulnerability is there is enough.) Chapter 7 discussed advanced topics, and contained a sub-section on finding second-order vulnerabilities. The topic presented made me think of this post, and other uses for SQL injection.
However, I got so much more from the book. Chapter 3 discussed reviewing code for potential SQL injection. What to look for, types of data, frameworks, and static code analysis tools were all discussed. This was extremely beneficial because while we do not do code reviews, I can better speak to the client on how they can make their code reviews better; and what they should be looking out for (at least in a general sense.)
Chapter 8 is a great chapter on how to remediate findings; fixing code, both in the application and in the database. Chapter 9 talked about platform-level defenses and remeditions that can be used to harden the servers and operating systems that house the data, web server or database server. Many of the points mentioned in Chapter 9 are controls found in the Application Security and Development checklist. These are issues that if employed will directly satisfy the requirement in the checklist. Finally, chapter 10 includes a great reference on SQL and SQL injection. As a former DBA/DBD, I could skip the SQL primer. The chapter also included some of the databases that the book did not delve into; namely PostgreSQL, DB2, Informix and Ingres. Finally, there were cheat sheets for the topics discussed throughout the book.
This is certainly one of the best books I've read in a bit. I really could not find much that detracted from the book. Go into the book knowing that the topics are geared towards MS SQL Server, Oracle, and MySQL; as they should be, they are the three widest-used databases. Be prepared to learn a lot. I'm looking for vulnerable web applications that I can install and use to reinforce the concepts so that I am better prepared when I go on audits. I highly recommend the book; whether you are an application/sql developer, an auditor or a pen-tester.
I bought this book so I could understand the underpinnings of the SQL injection: why it exists, how to make it work, and to some degree, how to fix them. (I don't need to fix them, however, it's nice to be able to help the client mitigate open vulnerabilities.) I have prior SQL experience (coming from the DBA/DBD world) so the concepts of SQL are quite familiar to me. And of course, when most people think of SQLi, they think of the familiar ' or 1=1. I wanted to know more, and I wanted a more advanced knowledge. Sure, we run tools, but I wanted to be able to confirm our tool's output. And, I wanted the ability to perform the analysis manually. One other caveat worth mentioning, many of the systems I audit are CAC-enabled; which the tools we use do not handle too well. It's easy to manually log in, authenticate, and manually exploit/search for vulnerabilities.
I admit it, I bought the book mainly for chapters 2, 4, 5, 6, and 7. These chapters talk about testing for SQL injection, exploiting SQL injection, blind SQL injection, exploiting the operating system and advanced topics, respectively. And those chapters were great. I satisfied my objective to learn how to really accomplish the task of finding and somewhat-exploiting found inection-able fields. (We're not hired to pen-test, just audit....so we can't go nuts with a finding once we find it. The fact that the vulnerability is there is enough.) Chapter 7 discussed advanced topics, and contained a sub-section on finding second-order vulnerabilities. The topic presented made me think of this post, and other uses for SQL injection.
However, I got so much more from the book. Chapter 3 discussed reviewing code for potential SQL injection. What to look for, types of data, frameworks, and static code analysis tools were all discussed. This was extremely beneficial because while we do not do code reviews, I can better speak to the client on how they can make their code reviews better; and what they should be looking out for (at least in a general sense.)
Chapter 8 is a great chapter on how to remediate findings; fixing code, both in the application and in the database. Chapter 9 talked about platform-level defenses and remeditions that can be used to harden the servers and operating systems that house the data, web server or database server. Many of the points mentioned in Chapter 9 are controls found in the Application Security and Development checklist. These are issues that if employed will directly satisfy the requirement in the checklist. Finally, chapter 10 includes a great reference on SQL and SQL injection. As a former DBA/DBD, I could skip the SQL primer. The chapter also included some of the databases that the book did not delve into; namely PostgreSQL, DB2, Informix and Ingres. Finally, there were cheat sheets for the topics discussed throughout the book.
This is certainly one of the best books I've read in a bit. I really could not find much that detracted from the book. Go into the book knowing that the topics are geared towards MS SQL Server, Oracle, and MySQL; as they should be, they are the three widest-used databases. Be prepared to learn a lot. I'm looking for vulnerable web applications that I can install and use to reinforce the concepts so that I am better prepared when I go on audits. I highly recommend the book; whether you are an application/sql developer, an auditor or a pen-tester.
Monday, July 5, 2010
Thanks for the iTunes Gift Card, but, no thanks
The other day I received a note with a file attached: Gift_Certificate_641.zip. My email server stripped the payload, and left me with an empty zip file. Before I examined the .zip, I uploaded it to VirusTotal, but because it was empty, nothing came back. I would have liked to have seen what it was, but I'm glad the AV is working on the mail server. I'm sure the headers on the email were spoofed, if the address was even valid in the first place. But, the mail came from: "iTunes Store" . If anyone can tell me what the actual virus/worm was, I'd be curious to know.
Thursday, July 1, 2010
What Works Conference and what to do
With a little more than a week to go, it looks like I won't be able to attend this year's What Works in Forensics and Incident Response conference coming up next week. I really wanted to attend, but it looks like the company is scaling back on conferences (no BlackHat this year, just DefCon.)
Which leads me to thoughts I've been having lately. I've been reading and working a lot on web application auditing and testing; and I'm finding I'm pretty good at it. Yet, I still love the Incident Response and Forensics. While I practice IR and forensics with my own company I can't quite get it into the other company.
Which leads me to thoughts I've been having lately. I've been reading and working a lot on web application auditing and testing; and I'm finding I'm pretty good at it. Yet, I still love the Incident Response and Forensics. While I practice IR and forensics with my own company I can't quite get it into the other company.
Tuesday, June 15, 2010
Time sensitivity of data
SANS Newsbytes had this post in today's email:
So, to see this in the forensics space is interesting. At what point does data become invalid. Certainly, an image of a system should be valid as a point-in-time snapshot for a long time; almost indefinitely.
Granted, given the circumstances around the original story, I think that there is more to it.
Thought-provoking none-the-less.
--Judge Disallows Evidence Gathered From Laptop Six Months After SeizureThis is an interesting concept that I had not considered in the forensics arena. In the government space, the ACA that we work for has said that data we acquire is only valid for six months; after that, we would need to re-test a system up for accreditation. And I agree with that concept fully. Many times we will test a system, come back with data, analyze it, and write it up. We'll get questions up to a year later on what we wrote. And how valid are those questions? Many times, the system has changed so much that the initial report is almost invalid (sometimes it is - hopefully the system owners have made changes.)
(June 10 & 14, 2010)
A US federal judge has ruled that evidence gathered in June 2009 from a
laptop computer seized at a US border crossing in late January 2009 may
be suppressed. Andrew Hanson was randomly selected for secondary
baggage search in January 2009. Hanson is a US citizen who was
returning from South Korea to the US through San Francisco. An image
of child pornography justified seizure of his laptop; a subsequent scan
of the hard drive several weeks later turned up more evidence. However,
the laptop's contents were not viewed again until June 2009. The judge
allowed evidence discovered on the laptop in early February 2009 because
the search was conducted within a reasonable time frame. The judge
determined that evidence obtained during the June search, which was
conducted without a warrant, was inadmissible; a search so long after
the fact requires a warrant.
http://www.theregister.co.uk/2010/06/10/dhs_laptop_search/
http://www.pcmag.com/article2/0,2817,2365030,00.asp
So, to see this in the forensics space is interesting. At what point does data become invalid. Certainly, an image of a system should be valid as a point-in-time snapshot for a long time; almost indefinitely.
Granted, given the circumstances around the original story, I think that there is more to it.
Thought-provoking none-the-less.
Monday, May 31, 2010
MS Access SQL Injection
I have a testing trip coming up that involves a web application built using MS Access on the backend. I've just gotten Jusin Clarke's great book SQL Injection Attacks and Defense. There doesn't seem to be a treatise on SQL injection for MS Access, but there are some good sources. I know that Access doesn't support the ', so I'm working on other methods. Already, I have information on the application, and based on what I've discussed with the developers, the app has to be "injectable," it's just a matter of where. Some of the MS Access SQL Injection resources I've been going through include:
Saturday, May 29, 2010
Online Penetration Testing class
I haven't decided yet how to spend my education budget. I really want to attend the SANS What Works in Forensics and Incident Response summit, but I think it's too much for the company to pay for. Then, the other day, I was reading Darknet, and I saw their posting on the eLearnSecurity Online Penetration class. The price is pretty good, and I would really like to learn the network pen testing segment. As I've been doing a lot of web application auditing lately, I wouldn't mind learning the tips and tricks to web applications as I think it will only help the auditing skills.
If you've taken any of the classes by eLearnSecurity, I'd like to hear your feedback.
If you've taken any of the classes by eLearnSecurity, I'd like to hear your feedback.
Wednesday, May 5, 2010
Hackin9 magazine now free
This post might be a bit late. I originally posted/mused about Hackin9 back in January of 2008. Now, I see it has become a free e-zine. Head to http://hakin9.org and sign up for the newsletter. At the time of this post, you are able to download the current issue in .pdf form.
Subscribe to:
Posts (Atom)