Challenges

Johnathan Ham and Sherri Davidoff from SANS Internet Storm Center (ISC) and Raul Siles from InGuardians have created two recent, still open, security challenges. Sherri, co-author with Jonathan of the SANS’ Network Forensics course, has posted “Network Forensics Puzzle Contest!” (8-14-2009). The most elegant solution wins a free SANS On-Demand class (worth up to $3500 depending on the course). Raul wrote a new hacking challenge on the Ethical Hacker Network site, titled “Prison Break – Breaking, Entering & Decoding” (7-27-2009). Three winners will be selected based on: the best technical answer, creativity (while also technically correct), and a random drawing. Winners will receive signed copies of Ed’s book, “Counter Hack Reloaded.”

Ed Skoudis, of Counter Hack Reloaded fame along with various SAN’s hacking and penetration testing courses (see Ed in Virginia Beach teaching “Network Penetration Testing: Planning, Scoping, and Recon” August 30th – September 4th), is the host bringing monthly new challenges created and managed by the fine folks of InGuardians. The great thing about past challenges is that they allow you to try the problems and check your solutions immediately. Check out Ed’s Counter Hack Reloaded site for a few additional, older challenges.

UPDATE: For a challenge in the forensic’s realm, check out the series of posts by Dave Hull (trustedsignal) on the SANS Forensics Blog. This series discusses the FAT file system. Dave provided the following description: “I’ve provided a copy of the disk image used during the series and have ended almost every post with a challenge question and have been giving away a forensics related title from the Syngress Publishing group. We’ve had a great time and the series is in the archives for anyone who wants to check it out.” Dave is working on a series for NTFS, which he should start posting in the next few weeks. The series is very informative and a great hands-on way to learn.

Data Sets

Greg Conti, author of Security Data Visualization, co-authored the paper, “Toward Instrumenting Network Warfare Competitions to Generate Labeled Datasets.” The paper was done for the CSET ‘09 Worksop on Cyber Security Experimentation and Test. The authors demonstrates how the network warfare competitions can be instrumented to generate modern labeled data sets. They have made available the archived data capture and log files from the 2009 Inter-Service Academy Cyber Defense Competition. The annual competition pits the service academies, including West Point, against an actual National Security Agency Red Team. There is a great deal to be learned by examining this data. A blog has been setup to discuss the data. They are hoping to do a few data captures of network warfare games, as well as, data captures of red-on-blue events at the US Military Academy at West Point.

There are a few additional sites where you can obtain data captures. JJC, from the “Security – The Global Perspective” blog, manages the OpenPacket.org site. The site’s mission is to “provide quality network traffic traces to researchers, analysts, and other members of the digital security community.” The site pcapr, powered by Mu Dynamics, calls itself a “social nOtworking site.” Go to the site to learn about networks and protocols from packet captures.

UPDATE: The folks from pcapr wrote in and pointed out that they just made available the “Collaborative Network Forensics” area where they “took the recently published ITOC dataset and the CCTF captures from the Shmoo group, indexed them for real-time browsing and contextual search/extract.” As they point out, “with over 15.0 GBytes and 26.3 million packets, this now represents the largest collection of indexed pcaps online.” Really nice.

The VizSEC site maintains links to various repositories of data sets. SourceForge, as part of the NetworkMiner tool, has links to publically available PCAP files. The wireshark site also has a few links and sample PCAP files.

Practicing

Practice can be done by installing software, using disk images, or by going to sites/training grounds. Installing software will create a vulnerable site. Make sure to do it onto a local machine inside your LAN which is used solely for testing. For ISO images, make sure you set the VM to use the IP addresses that are only available from the local host OS (NAT or Host-only). If you go to a site, take caution and remember the site could be hostile. In other words, be properly paranoid.

Software

In my post “WebGoat, Lua, and ModSecurity verses Password Guessing,” I go through the steps of setting up WebGoat. WebGoat is a deliberately insecure J2EE web application maintained by OWASP and is intended to teach a structured approach to test and exploiting vulnerabilities within an application security assessment. WebGoat is written in Java and installs on any platform with a Java virtual machine. The YGN Ethical Hacker Group has made available a series of video on walking through WebGoat v5.2. There are currently over 30 lessons.

Damn Vulnerable Web App (DVWA) is a PHP/MySQL Web application that is light weight, easy to use and full of vulnerabilities to exploit. Ryan Dewhurst, developer of DVWA, created a video showing the installation process:

If you prefer PHP scripts, Mutillidae is a set that implements the OWASP Top 10 vulnerabilities. Adrian Crenshaw posted the presentation he gave to the Louisville Chapter of OWASP about the Mutillidae project titled “OWASP Top 5 and Mutillidae: Intro to common web vulnerabilities like Cross Site Scripting (XSS), SQL/Command Injection Flaws, Malicious File Execution/RFI, Insecure Direct Object Reference and Cross Site Request Forgery (CSRF/XSRF).”

Owasp Louisville 2nd Meeting from Adrian Crenshaw on Vimeo.

ISO Disk Images

On the ISO disk image side, there are few interesting options. Badstore demo helps in the understanding of Web application vulnerabilities and shows how to reduce exposure.

For full scaled lesson based environment, there is the Linux-based distribution Damn Vulnerable Linux (DVL). Mayank Sharma writes in the article “Securing Linux by breaking it with Damn Vulnerable Linux:”

“Damn Vulnerable Linux (DVL) is everything a good Linux distribution isn’t. Its developers have spent hours stuffing it with broken, ill-configured, outdated, and exploitable software that makes it vulnerable to attacks. DVL isn’t built to run on your desktop — it’s a learning tool for security students.”  “The one thing that sets DVL apart the most,” Josh Sweeney says, “is the focus on buffer overflows and disassembly.” Disassembly, he says, is often talked about in conjunction with buffer overflows and reverse engineering. “Disassembling is when someone breaks down a program into the assembly language for further analysis. By doing this, users can analyze code at a very low level and look for security issues. There have been many excellent papers on the subject over the years, but these generally don’t come with learning tools in a self-contained, easy-to-use environment.”

Thomas Wilhelm is the author of “Professional Penetration Testing: Creating and Operating a Formal Hacking Lab” and the creator of both the Hackerdemia project and the De-ICE.net Pentest LiveCDs project. Hackerdemia is a LiveCD that containing several vulnerabilities, including un-patched software, mis-configured services, default passwords and a few other surprises. Paul Asadoorian posted “Scanning Vulnerable Linux Distributions With Nessus” where he walks through using Nessus to determine the vulnerabilities within Hackerdemia. The De-ICE.net Pentest LiveCDs are disk images that are fully-functioning server. The Security Aegis site has an interview with Thomas where he discusses these projects along with the Heorot.net pentest video training and his recently published book.

One more Linux VM intentionally configured with exploitable services pWnOS. It was created by Brady Bloxham, a.ka bond00. Below is a nice introduction video.

The Web Application Attack and Audit Framework (w3af) project has created a VMware image, called Moth, which is a set of vulnerable Web Applications and scripts. The w3af core and it’s plugins are fully written in Python, has more than 130 plugins checking for SQL injection, cross site scripting (xss), local and remote file inclusion, etc. What is really interesting about Moth is that it allows for testing of web application scanners and learning how web application firewalls work by providing a way access web applications and vulnerable scripts directly, through mod_security, and through PHP-IDS.

On the system side, LAMPSecurity has been creating a series of capture the flag exercise that uses a full Linux virtual machine that is vulnerable to remote root compromise due to a number of vulnerabilities. The most recent exercise is Capture the Flag 6 and was released 7/17/2009. The documentation will take you through the steps of the exercise.

Training Ground

The Mighty Seek Podcast did a Hands On Series and setup the NTO Hackme Test site, which includes the podcasts with the opportunity to test what is discussed out. Dan Kuykendall did two episodes: “Episode #01 – SQL Injection Part 1 [Intro]” and “Episode #02 – Cross Site Scripting (XSS) Part 1 [Intro].”

Hack This Site (HTS) is a website to test and expand one’s hacking skills. You will need to register with the site to access the hacker challenges.  There are various lessons and missions.  User cwade12c has posted the several video tutorial covering missions. Below is “Hack This Site – Basic 1 Tutorial” to give you an feel for the simplest of challenges:

HellBound Hackers (HBH) is another site offering a large resource consisting of challenges, articles, forums, etc. The LifeofaHacker site has published some challenge tutorials/walkthrough guides for both Hack This Site (HTS) and HBH.

Enigma Group is similar to HTS and HBH in terms of tutorials, articles, and hacker challenges. There are some education and humorous short tutorial videos.

The Bright Shadows site also offers challenges on JavaScript, cyptography, cracking, steganography, Flash, Java, various programming exploits, etc. Registration is required. The challenges get voted on by the members in terms of difficulty, creativity, education, and presentation.

Smash The Stack (StS) Wargaming Network has a progression of challenges where each challenge is dependent on the completion of the previous challenge. The challenges are *nix based. To get started you ssh into one one of the wargame servers on port 2224 using password “level1″, at which point you receive a message letting you know how to get started. The password for the next level will be located in different placed, depending on the game. Questions can be asked on their forums area. OverTheWire offer similar wargame challenges.

A Few Final Thoughts

The above list represents a few source I have experience with. Duncan Alderson on his site Webantix has done a great job of listing war games/hacking simulators in his post, “War Games. Current and past hacking simulators and challenges. The New Order site also has a much more comprehensive list.

Just remember, it is good to be paranoid. Even HTS, with a user base of over 1,300,000 can still have problems with disgruntled and past employees. We are talking very skilled, intelligent, and disgruntle employees. In the last major attack, root-level access to the website was gained and HTS was taken down for months.

It is a dangerous world. That is exactly why skilled ethical hackers are needed. One of my college professors would always say, “Repetition is the key to learning.” He repeated it so many time, I finally learned that lesson. The above links help provide a challenging way to practice and learn. Give them a try and have some fun.

To deal with administrative accounts at Twitter, Adam O’Donnell provides some great advices to corporate CSOs in his article, “A roadmap for the Twitter CSO.” Dave Goldsmith post, “My Pentest Secret: Password Guessing,” provides more advice to mitigate risk of password guessing attacks.

Today’s post focuses on Dave’s point:

FAILED LOGIN DELAYS. What to do when someone is grinding passwords on the same account? Account lockout is pretty unpopular as it can lead to a denial of service attack. Doing nothing is pretty unpopular because attackers can grind forever. Enter the exponentially increasing login delay. Every failed login on an account causes the system to delay more and more on that account until a reset on that counter after a reasonable period of time or a valid login.

The Open Web Application Security Project (OWASP) has begun a podcast focused on web application security. The podcast is hosted by Jim Manico, a Web Application Architect and Security Engineer for Aspect Security. In Podcast #2, Stephen Craig Evans, an independent software security consultant, talks about Lua and the OWASP Summer of Code project wiki, Securing WebGoat using ModSecurity. The project goes through the steps involved in securing WebGoat using the combination of ModSecurity and Lua. To quote Ivan Ristic, creator of ModSecurity, the project “stretched the boundaries of what ModSecurity could do.”

To help address the problem of dictionary attacks against your web server, today’s post will be using ModSecurity with the scripting language Lua. First, let’s setup WebGoat for testing purposes.

WebGoat

For those unfamiliar with OWASP WebGoat project, WebGoat is:

WebGoat is a deliberately insecure J2EE web application maintained by OWASP designed to teach web application security lessons. In each lesson, users must demonstrate their understanding of a security issue by exploiting a real vulnerability in the WebGoat application. For example, in one of the lessons the user must use SQL injection to steal fake credit card numbers. The application is a realistic teaching environment, providing users with hints and code to further explain the lesson.

Why the name “WebGoat”? Developers should not feel bad about not knowing security. Even the best programmers make security errors. What they need is a scapegoat, right? Just blame it on the ‘Goat!

WebGoat is intended to teach a structured approach to test and exploiting vulnerabilities within an application security assessment. Also being developed is the OWASP Testing Project, which provides a full application security assessment testing methodology. Through WebGoat, companies have a way to teach web application security lessons to their developers. There are over 30 lessons dealing with such issues as:

The YGN Ethical Hacker Group has made available a series of video on walking through WebGoat v5.2. The videos consist of:

Please recognize that WebGoat is a vulnerable server and therefor you will want to set it up so no one but you can access the WebGoat server. By default WebGoat only listens on the loopback address. Below are the steps to pull down WebGoat and install it on a Linux server. Since this is not a production system, we will be installing the WebGoat developer release.

Installing JDK

WebGoat will require Sun JDK 6 to be installed. Get the Sun JDK 6 from Sun’s website. Sun requires you to agree to terms, so you’ll need to go there and agree. Run the installer which gets downloaded. Agree again to the terms. The installer will install a few rpms and jars.

root# /bin/sh jdk-6u11-linux-i586-rpm.bin
root# ls -la /usr/java
default  jdk1.5.0_17  jdk1.6.0_11  latest
root# declare -x JAVA_HOME="/usr/java/latest"
root# declare -x PATH="${JAVA_HOME}/bin:${PATH}
root# java -version
java version "1.6.0_11"
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) Server VM (build 11.0-b16, mixed mode)

Running WebGoat Standard Release

While the documentation for WebGoat says to install Tomcat, the WebGoat zip file will come with its own version of Tomcat. Running WebGoat in this manner can prove to be the easiest path allowing the avoidence of Java software version problems. We will go through both deployments. First, installing WebGoat with Tomcat.

 root# cd /usr/local/src
/usr/local/src root# wget \

http://webgoat.googlecode.com/files/WebGoat-OWASP_Standard-5.2.zip

/usr/local/src root# /usr/bin/openssl sha1 WebGoat-OWASP_Standard-5.2.zip
SHA1(WebGoat-OWASP_Standard-5.2.zip)=
1e8950d8af0a1726ee1c4509cb64ee4ee6da7584
/usr/local/src root# unzip WebGoat-OWASP_Standard-5.2.zip
/usr/local/src root# cd WebGoat-5.2

At this point, a slight modification needs to be made to webgoat.sh. It checks if the java version is 1.5. This is an odd check, since WebGoat was compiled under 1.6 and will not run under 1.5. Find where webgoat.sh has grep ‘version \”1.5′ and change 1.5 to 1.6. At that point, you are read to start WebGoat.

/usr/local/src/WebGoat-5.2 root# /bin/sh webgoat.sh start8080
Using CATALINA_BASE:   ./tomcat
Using CATALINA_HOME:   ./tomcat
Using CATALINA_TMPDIR: ./tomcat/temp
Using JAVA_HOME:       /usr/java/latest

  Open http://127.0.0.1:8080/WebGoat/attack
  Username: guest
  Password: guest
  Or try http://guest:guest@127.0.0.1:8080/WebGoat/attack

This is running WebGoat accessible only to 127.0.0.1. From your web browser, go to http://127.0.0.1:8080/WebGoat/attack and log in with username guest and password guest. At this point, WebGoat is running and you are set to start going through the lesson plans and exercise.

Installing WebGoat.war

If you have Tomcat on your server, you will want to install only the WebGoat.war file. I am going to make this a little more complicated by going through the steps to install Tomcat. In previous posts, I have stepped through installation of Apache and ModSecurity. Walking through the installation of Tomcat will help get us on the same page as far as configuration and installation.

There is a known issue with the latest stable release of Tomcat, 6.0.18. It requires JDK 5 at the moment, due to incompatibilities introduced by Sun JDK 6. Sun changed the JDBC spec in an incompatible fashion that was discovered after Tomcat 6 went out. There are changes in the trunk to replace the DB connection pooling mechanism with one that isn’t impacted by the 1.6 change. Unfortunately, WebGoat required JDK 6. To get a round this problem, we will use the subversion release of Tomcat.

We first need to install Apache Ant, which is a software tool for automating software build processes. It is similar to make but is implemented using the Java language.

root# cd  /usr/local/src/
/usr/local/src root# wget http://www.uniontransit.com/apache/ant/binaries/apache-ant-1.7.1-bin.tar.gz
/usr/local/src root# md5sum apache-ant-1.7.1-bin.tar.gz
cc5777c57c4e8269be5f3d1dc515301c  apache-ant-1.7.1-bin.tar.gz
/usr/local/src root# tar xzf apache-ant-1.7.1-bin.tar.gz
/usr/local/src root# mv apache-ant-1.7.1 /work/software
/usr/local/src root# cd  /work/software
/work/software root# ln -s apache-ant-1.7.1 ant
/work/software root# declare -x ANT_HOME="/work/software/ant"
/work/software root# declare -x PATH="${PATH}:${ANT_HOME}/bin"
/work/software root# ant
Buildfile: build.xml does not exist!
Build failed

The error above indicate that ant command is recognized by shell but it did not find build.xml file that needed to compile ant projects. So, it’s absolutely normal and the installation was successful.

We are now ready to download and build Tomcat.

root# cd  /usr/local/src/
/usr/local/src root# svn checkout \
http://svn.apache.org/repos/asf/tomcat/trunk tomcat-7
/usr/local/src root# cd tomcat-7
/usr/local/src/tomcat-7 root# ant download
/usr/local/src/tomcat-7 root# ant
/usr/local/src/tomcat-7 root# cd output
/usr/local/src/tomcat-7/output root# mv build \
/work/software/tomcat-7
/usr/local/src/tomcat-7 root# cd /work/software/
/work/software root# ln -s tomcat-7 tomcat
/work/software root# declare -x CATALINA_HOME="/work/software/tomcat"
/work/software root# chmod u+x $CATALINA_HOME/bin/*
/work/software root# mkdir $CATALINA_HOME/logs

Configuring and Using Tomcat

The following modifications can be done to configuration Tomcat files that came down as part of WebGoat or the latest version from the Tomcat site. If you make the modifications to the Tomcat under Webgoat, keep in mind:

1. Set $CATALINA_HOME appropriately
2. Modify webgoat.sh, removing the line “cp -f $CATALINA_HOME/conf/server_8080.xml $CATALINA_HOME/conf/server.xml”.
3. Adjust paths based on where WebGoat is installed.
4. Add to the $CATALINA_HOME/conf/tomcat-users.xml file. Do not replace content.
5. You can use $CATALINA_HOME/bin/shutdown.sh to shutdown Tomcat.
6. You can start with $CATALINA_HOME/bin/startup.sh instead of webgoat.sh, provided you have $PATH, $JAVA_HOME, and $CATALINA_HOME set.

Before starting, create a manager username and password. This is set in the $CATALINA_HOME/conf/tomcat-users.xml file. The following is an example only:

/work/software root# vi $CATALINA_HOME/conf/tomcat-users.xml
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
  <role rolename="tomcat"/>
  <role rolename="manager"/>
  <user username="jerry" password="mousepower" roles="tomcat"/>
  <user username="tom" password="catpower" roles="manager"/>
</tomcat-users>

We can setup secure web authentication through the use of digital certificates using SSL. First step is to use the keytool utility, which is included in the Sun Java Standard Edition JDK, to create a keystore file. Use “changeit” as the password. (If you don’t use “changeit” you will have to state the password in with the keystorePass setting in server.xml). For example:

/work/software root# mkdir /work/software/tomcat/keystore
/work/software root# cd /work/software/tomcat/keystore
/work/software/tomcat/keystore root# keytool -genkey -alias tomcat \
-keyalg RSA -keysize 2048 -keystore /work/software/tomcat/keystore/keystore
Enter keystore password:  changeit
What is your first and last name?
  [Unknown]:  John Gerber
What is the name of your organizational unit?
  [Unknown]:  SecurityMonks
What is the name of your organization?
  [Unknown]:  OrderOfUnix
What is the name of your City or Locality?
  [Unknown]:  Knoxville
What is the name of your State or Province?
  [Unknown]:  TN
What is the two-letter country code for this unit?
  [Unknown]:  US
Is CN=John Gerber, OU=SecurityMonks, O=OrderOfUnix, L=Knoxville, ST=TN, C=US correct?
  [no]:  yes

Enter key password for 
        (RETURN if same as keystore password):
/work/software/tomcat/keystore root# ls  /work/software/tomcat/keystore
/work/software/tomcat/keystore root# keytool -list -keystore keystore

The keystore created will not be trusted by JVM until the certificate is imported into JVM’s trusted certificate keystore. We will export the SSL certificate we just generated and import it into the JVM’s keystore.

/work/software/tomcat/keystore root# keytool -export \
-alias tomcat -keystore keystore -file tomcat.cer
/work/software/tomcat/keystore root# keytool -import \
-trustcacerts -keystore /usr/java/jdk1.5.0_17/jre/lib/security/cacerts  \
-alias tomcat -file /work/software/tomcat/keystore/tomcat.cer
/work/software/tomcat/keystore root# keytool -list -alias tomcat \
-keystore /usr/java/jdk1.5.0_17/jre/lib/security/cacerts

Modify the $CATALINA_HOME/conf/server.xml section which defines a SSL HTTP/1.1 Connector on port 8443. It should go with the other connectors in the Service section and looks something like this:

    <Connector port="8443" minSpareThreads="5" maxSpareThreads="75"
           enableLookups="true" disableUploadTimeout="true"
           acceptCount="100"  maxThreads="200"
           scheme="https" secure="true" SSLEnabled="true"
           keystore="/work/software/tomcat/keystore/keystore"  keypass="changeit"
           clientAuth="false" sslProtocol="TLS" />

In order to require SSL on a specific site configure a security constrant for that app. Do this by editing the $CATALINA_HOME/conf/web.xml file and adding the following section just before the ending </web-app> tag:

    <security-constraint>
    <web-resource-collection>
    <web-resource-name>Automatic SSL Forwarding</web-resource-name>
    <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <user-data-constraint>
    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
    </security-constraint>

Now startup Tomcat.

/work/software root# $CATALINA_HOME/bin/startup.sh
Using CATALINA_BASE:   /work/software/tomcat
Using CATALINA_HOME:   /work/software/tomcat
Using CATALINA_TMPDIR: /work/software/tomcat/temp
Using JRE_HOME:       /usr/java/jdk1.5.0_17
/work/software root# ps awx | grep tomcat
  783 pts/14   Sl     0:04 /usr/java/jdk1.5.0_17/bin/java
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=/work/software/tomcat/conf/logging.properties
-Djava.endorsed.dirs=/work/software/tomcat/endorsed
-classpath :/work/software/tomcat/bin/bootstrap.jar
-Dcatalina.base=/work/software/tomcat
-Dcatalina.home=/work/software/tomcat
-Djava.io.tmpdir=/work/software/tomcat/temp org.apache.catalina.startup.Bootstrap start
/work/software root# /usr/sbin/lsof -iTCP -n -P | grep java
java      6175   root   10u  IPv6 327556       TCP *:8080 (LISTEN)
java      6175   root   12u  IPv6 327557       TCP *:8443 (LISTEN)
java      6175   root   21u  IPv6 327562       TCP *:8009 (LISTEN)
java      6175   root   22u  IPv6 327565       TCP 127.0.0.1:8005 (LISTEN)

Tomcat is now built and running. You can access it by going to:

http://localhost:8080

which will redirect you to:

https://localhost:8443

When you goto https://localhost:8443 you will be asked to accept the certificate. If you have problems, make sure to clear you browser’s cache. Now that we have Tomcat server running, we are ready to download and setup our WebGoat server.

 root# $CATALINA_HOME/bin/shutdown.sh
 root# cd /usr/local/src
/usr/local/src root# wget http://webgoat.googlecode.com/files/WebGoat-5.2.war
/usr/local/src root# /usr/bin/openssl sha1 WebGoat-5.2.war
SHA1(WebGoat-5.2.war)= c5aab7c5496625777a3b9e21b9888cddee5b649c
/usr/local/src root# mv WebGoat-5.2.war /work/software/tomcat/webapps/WebGoat.war
/usr/local/src root# $CATALINA_HOME/bin/startup.sh
/usr/local/src root# ls -la /work/software/tomcat/webapps/WebGoat
/usr/local/src root# ls -la /work/software/tomcat/conf/tomcat-users.xml

Add WebGoat users and roles to $CATALINA_HOME/conf/tomcat-users.xml file. Start Tomcat back up.

 root# $CATALINA_HOME/bin/shutdown.sh
 root# vi $CATALINA_HOME/conf/tomcat-users.xml
    <tomcat-users>
      <role rolename="webgoat_basic"/>
      <role rolename="webgoat_admin"/>
      <role rolename="webgoat_user"/>
      <role rolename="tomcat"/>
      <user password="webgoat" roles="webgoat_admin" username="webgoat"/>
      <user password="basic" roles="webgoat_user,webgoat_basic" username="basic"/>
      <user password="tomcat" roles="tomcat" username="tomcat"/>
      <user password="guest" roles="webgoat_user" username="guest"/>
    </tomcat-users>
 root# $CATALINA_HOME/bin/startup.sh

At this point, WebGoat should be running. Pretend you are an 18-year hacker, and use your penetration skills to break into one of the accounts. Check out the Access Control Flaws material and the Remote Admin Access section. Being aware of what is possible, and that the threats are real, helps motivate a person to defend against them.

Now it is time to examine the work of OWASP Summer of Code project wiki, Securing WebGoat using ModSecurity. With a vulnerable server to test out the vulnerabilities against, we will move on to the required software that will help defend against brute force password attacks. First step, install Lua to use with ModSecurity.

Lua

The Lua language combines “simple procedural syntax with powerful data description constructs based on associative arrays and extensible semantics. Lua is dynamically typed, runs by interpreting bytecode for a register-based virtual machine, and has automatic memory management with incremental garbage collection, making it ideal for configuration, scripting, and rapid prototyping.”

For a complete discussion of the benefits of Lua, Soumya has written an article “10 Reasons Why You Should Make Lua (A New Programming Language) Your Coding Friend – A Detailed Review.” Erik Wrenholt has also done an interesting benchmark again popular languages to compute the Mandelbrot. We are focusing on Lua is because it can be used with ModSecurity. Plus, we want to take advantage of the work done by Stephen Craig Evans and others who worked on securing web applications.

To install Lua on a linux server by source:

root# cd /usr/local/src/ /usr/local/src root# wget http://www.lua.org/ftp/lua-5.1.4.tar.gz /usr/local/src root# md5sum lua-5.1.4.tar.gz d0870f2de55d59c1c8419f36e8fac150 lua-5.1.4.tar.gz /usr/local/src root#tar xzf lua-5.1.4.tar.gz /usr/local/src root# cd lua-5.1.4 /usr/local/src/lua-5.1.4 root# make linux /usr/local/src/lua-5.1.4 root# make install /usr/local/src/lua-5.1.4 root# cd /usr/local/lib /usr/local/lib root# gcc -shared -o liblua.5.1.4.so /usr/local/lib/liblua.a /usr/local/lib root# ln -s liblua.5.1.4.so liblua.so

ModSecurity

If you are running a version of ModSecurity older than version 2.5, you will need to upgrade. As of ModSecurity 2.5, Lua can be used:

The new SecRuleScript directive allows for the execution of Lua scripts which provide an even more flexible and powerful interface into ModSecurity. When is Lua needed? ModSecurity chained rules can easily implement AND logic to create complex rules that evaluate that specific variables are present and have certain data, however they can not easily create proper OR logic. This is where Lua can help.

A previous blog post, “Implementing a Web Application Firewall with ModSecurity,” goes through the step of installing ModSecurity with an Apache Web Server. Following that post, your Apache httpd.conf configuration files should load the mod_security2.so module and include the modsecurity.conf file. It is the modsecurity.conf file where the additional rules will be added.

Problem with Usernames and Passwords

WebGoat demonstrates a few security issues that need to be addressed. From OWASP’s “OWASP ModSecurity Securing WebGoat Section4 Sublesson 04.2” Forgot Password section, the following points are made:

• Attackers who are attempting to enumerate valid usernames. If you submit an invalid one the html response text includes info stating as such. We can track this.
• Once a specific valid username is identified, the attacker then starts a targeted attack to guess answers to the password hint (favorite color).
• Attackers can initiate reverse brute force attacks – this is when an attacker cycles through different valid user accounts and submits the same common answer to the question (submitting Blue as the answer to different usernames).

The OWASP ModSecurity Securing WebGoat document does such a good job outlining the security issues along with possible solutions, I am going to leave it to the reader to decide what solutions are appropriate for their systems. If I continued stepping through to a more secure implementation, I would end up copying everything in the document. Playing around with the rules, testing the results, is great fun in a geeky security kind of way. Do drop down and read the reviewer’s comments. A very good job by Stephen Craig Evans and all who worked on OWASP Summer of Code project. Of course, a special thank to Ivan Ristic, who gave us ModSecurity.

Recently, I listened to a IT Conversation podcast, from the O’Reilly Media Emerging Technology Conference. Tim O’Reilly spoke about hackers. Not the black hatters, but those folks who work tirelessly to bring about the kind of software and services that make the Internet possible. While the Internet may be at times a dangerous place, thanks to the efforts of these hackers who work out of love for the challenge, often with little regard to financial factors, we have these great tools that go a long way towards helping people secure their applications.

Final Thoughts

In today’s post we examined a security breach that occurred involving a major player in the Internet community. To help understand that problem, and others, we setup WebGoat. Sun Tzu wrote in The Art of War, “So it is said that if you know your enemies and know yourself, you will fight without danger in battles. If you only know yourself, but not your opponent, you may win or may lose. If you know neither yourself nor your enemy, you will always endanger yourself.” WebGoat helps us understand the attack vectors against web applications a little better. Once identifying a possible problems, we walked through a solution that can help reduce the risk.

It is easy to find humor in an employee with administrative access using the password “happiness.” The reaction from the Internet community to Twitter’s problems might be a little schadenfreude at play. Theodor Adorno, philosopher and sociologist, defined schadenfreude as largely unanticipated delight in the suffering of another which is cognized as trivial and/or appropriate. Or, maybe it is more like whistling past the graveyard, where folks are a bit cheerful or joyful in the face of a situation that doesn’t warrant it.

When very public security incidents occur, companies need to take a little stock. Not all employees will take training seriously nor follow all policies. That includes people with important roles. Employees make mistakes and it is difficult to guard against every possible mistake that could occur. That is why a layered approach to security is constantly preached. While each layer cost money, security groups at organizations are in a constant battle to monitor and prevent intrusions in a cost effective way. Fortunately, we have the work of many hackers (the good kind), helping us develop solutions to deal with daily new challenges. There are no guarantees. As Albert Einstein once said, “Anyone who has never made a mistake has never tried anything new.” Wisdom comes when we learn from these mistakes. CIOs need to ask themselves, “how safe is my company from being next week’s security headline?” Security groups within an organization must be able to learn and adapt. At the end of the day, the question is how different is your company from Twitter? Insanity is doing the same thing and expecting different results. I’ll close this post with the wise words of Sam Levenson, “You must learn from the mistakes of others. You can’t possibly live long enough to make them all yourself.”