Feed on
Posts
Comments

Happiness abandoned Twitter this week as it was revealed that an 18-year-old was able to use an automated password-guesser to break into an account. Twitter allowed for an unlimited number of log-in attempts. The hacker used a simple dictionary attack that revealed at 11:00am Monday the password of “happiness.” Once the hacker had the Twitter staffer’s password, through the administrative panel it was possible to change the email address of any Twitter account and reset the holder’s password. See Tom’s post “Summary of the Twitter Security Incidents” for more details on the incident.

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.”

Trackbacks/Pingbacks

  1. [...] System Advancements at the Monastery » Blog Archive » WebGoat, Lua, and ModSecurity verses Passwor… (tags: webgoat lua modsecurity password guessing) [...]

  2. [...] 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 [...]

Leave a Reply

Bad Behavior has blocked 418 access attempts in the last 7 days.