Web Admin Blog Real Web Admins. Real World Experience.


Completing the LASCON 2017 Badge Game

For those who don't know, every year I put together a game that starts on the back of the LASCON badge.  It's typically some combination of crypto challenges alongside application security vulnerabilities with the goal of having it take somewhere around 1-3 hours, depending on experience, to complete.  Those who complete the game are rewarded with one of these awesome challenge coins:

LASCON 2017 Challenge Coin

Now, I know that there are people out there who look at one of these things and don't even know where to start so, it is in the spirit of education and learning that I share with you my notes on how to complete the LASCON 2017 Badge Game.

Stage 1

On the back of the LASCON badge it reads as follows:

Another year, another game
Solve the puzzles, write your name
These characters aren’t a work of art
Ask a mason how to start
The key word in the text above is "mason".  If you were to Google the term "mason cipher", you would come across an interesting kind of cipher called a Pigpen/Masonic/Freemason Cipher.  The idea being that they take a geometric pattern and map the letters of the alphabet to the locations on the pattern.  Here's an example that you could use to translate this text:
Freemason Cipher
Once translated, you get the following message:
To start the badge game go to nocsal dot lascon dot org
Stage 2
When you go to nocsal.lascon.org it defaults to having a GET parameter of page=winners.php.  This is a sign that it is vulnerable to directory traversal.  There is also a comment in the page source that says “Get badge game winners from /files/winners.php”.  If you navigate to http://nocsal.lascon.org/files/, it has directory browsing enabled and you can see a test.php page there, in addition to winners.php.  If you go to http://nocsal.lascon.org/?page=test.php, you will see it grabs the test.php code and pulls it into the page source.  If you view source, you can see the text is as follows:
// Test ability to grab winners table from the database
$servername = "localhost";
$username = "lascon";
$password = "e3fmGYHDrc6MNCEMmLWj";
$dbname = "lascon";
$conn = new mysqli($servername, $username, $password, $dbname);
$sql = "SELECT * FROM lascon_winners";
$result = $conn->query($sql);
$array = $result->fetch_array();
We now have a database username and password.

Stage 3

Even though the database connection that we found uses a servername of "localhost", it turns out that mysql is open on the public IP interface of the server as well.  We can use a mysql client to connect to nocsal.lascon.org with username “lascon” and password “e3fmGYHDrc6MNCEMmLWj” (mysql -h nocsal.lascon.org -u lascon -p).  Once in the database, the user has access to read the lascon database and will see a “lascon_winners”, “users”, and “websites" table.  When you try to insert into the lascon_winners table, you quickly realize that you do not have insert permissions, so you cannot insert into the lascon_winners table.  In the users table, you see an entry with username “admin” and password “NFJXaTNuc0pyR2Y2c25iNG9Va1c=“.  In the websites table, you see a bunch of sites and one hiding amongst the others is ttpcteebhz.lascon.org.

Stage 4

When you go to http://ttpcteebhz.lascon.org in your browser, you see a form with a spot for a username and password.  You can base64 decode the string you found int he database (NFJXaTNuc0pyR2Y2c25iNG9Va1c=) to get the value “4RWi3nsJrGf6snb4oUkW”.  Once you have that, you can log in with username “admin” and password “4RWi3nsJrGf6snb4oUkW”.

Stage 5

Once logged in with the username and password, you see a blank page.  Once you view the page source, however, you see that it contains a hidden form and fields:

<form name="submission" method="post" action="">
<input type="hidden" name="first_name" value="" readonly />
<input type="hidden" name="last_name" value="" readonly />
<input type="hidden" name="phone" value="" readonly />
<input type="hidden" name="email" value="" readonly />

The last part of the challenge you could accomplish with a proxy tool, but I just used the Developer Tools in Chrome.  I changed the hidden fields to text fields, removed the readonly values, and then added a form submit button. Once submitted, the game is over and you win!

A Quick Summary of Puzzles Solved / Vulnerabilities in the Badge Game

  • Freemason Cipher
  • Directory Traversal
  • Information Disclosure in Comments
  • Directory Browsing Enabled
  • Hard-Coded Database Credentials
  • MySQL Service Publicly Accessible
  • BASE64 Encoded Passwords
  • Hidden and Read-Only Form Fields
  • Missing Form Submit Button

Completing the BSides Austin 2016 Mini-CTF

The BSides Austin 2016 Mini-CTF began with the back of the badge.  There was a large QR code which took a very long time for me to scan with my phone, and when I finally got it, it was just the numbers “07263584”.  Not very useful.  Below that, however, there was  a string of letters and numbers as follows:


The string very obviously looked like BASE64 so I decoded it to get the following URL:


On that page it reads:

That start was easy! You have shown that you are curious and that is the key. As your reward, you may have this:flag 1: BSides{D3c0d3s_R_3Z}Do you want to play some more? If so, read on...

1. Turn in flags by sending an email to bsidesaustin@gmail.com. The email must contain your name, email address, and the flag you are turning in

2. There are three flags total, each should be submitted via email.

3. Do not scan this server with automated tools. They are not necessary and could cause performance issues. If you scan this server, you could be disqualified.

4. Send in flag 1 then click here to continue...

I submitted the flag and moved on to the next page at:


On that page there was a file named coms.pcap.  With the “pcap” extension, I went ahead and loaded up into Wireshark.  It was a 1113 line packet capture file with encrypted Google traffic, YouTube rick rolls, and more.  Only a handful of the requests were for, the IP address belonging to ctf.bsidesaustin.org.  When I followed the TCP stream, it was for a request to http://ctf.bsidesaustin.org:31337/level3/index.html.  When I went to that URL, however, it was as if nothing was listening.  Eventually, I filtered the pcap by that IP as the destination and found a sequence of requests to that IP at odd ports…1025…2300…1337…1337.  This smelled suspiciously of port knocking so I wrote a quick bash script using nmap to test it out:

for x in 1025 2300 1337; do nmap -Pn --host_timeout 201 --max-retries 0 -p $x; done

Finally, I hit the page on port 31337:


Sure enough, now I get a response that says:

Congratulations, you have completed the second challenge!The second flag is: BSidesAustin{C4rV1NG_UP_PC4Ps}

Click here to continue to the final challenge!

I submitted the flag and moved on to the next page at:


On this page we see a network interface test where you can specify an IP as a ping destination, and when you hit “Enter”, it gives you the results of the ping:

PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=0.026 ms--- ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 0.026/0.026/0.026/0.000 ms

Entering some non-IP address information, I got a message like:

Error running ping -c 1

So, there is some filtering on it, but it also looks like some data is making it through.  I figured out that I could specify the destination as a GET instead of the POST with by adding “?dest=” to the URL and that worked.  I tried a bunch of different combinations of “;”, “&&”, and other OS command functions that would piggyback on the existing function with no luck.  Eventually, I figured out that “%0A”, the ASCII line feed control character, was not filtered and I could use that to run more commands.  For example:


Returned a listing of “index.cgi” and “the” in that directory.  Then:


Showed that “the” actually expanded to “/the/roof/the/roof/the/roof/is/on/fire/flag.txt”.  Sweet!  I found the flag!  Now to open it.


That returned:

PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=0.026 ms--- ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.026/0.026/0.026/0.000 ms
Great job! The third and final flag is:BSidesAustin{F1lt3rs_R_Fun}

Congratulations, you have completed the challenge!

Final flag submitted.  Game over!

Lessons Learned from Participating in my First CTF

Yesterday I finished competing in my first ever Capture The Flag (CTF) tournament.  It was called Kommand and Kontroll Revenge of the Carders and was run by Rod Soto of Prolexic.  I'm going to caveat this post by saying that this was my first ever CTF competition so I have absolutely no baseline of comparison.  It was also pretty thin on competition (only one other team actively pursuing flags for any period of length).  That said, it is what it is and in the end my team ended up with the win which I'm quite proud of.  We got system level privileges on 15 different systems to come away with both the most points as well as accomplishing the primary objective which I'll describe more about below.

The competition consisted of somewhere around 30 virtual machines running as servers and workstations on a completely isolated network.  Each system played a role in the scenario that Rod created around a carding ring that got pwn3d by one of its members using a Zeus botnet.  The primary objective for the CTF was to take over command and control of the botnet.  The secondary objective was to capture flags of various levels of difficulty (and points) in order to score more points than the competing teams.  It took the better part of two days to do it, but once we finally got system privileges on the CnC server, it was only a matter of time before we figured out a way to take ownership of it and win the game.  What follows are some lessons (in no particular order) that I learned throughout the competition that will hopefully serve to better myself and others as they compete in future competitions.

  1. Participate with a team: These CTF competitions are most definitely a team sport.  It's a series of challenges, different types of systems, and different applications.  There's no way that any one person can be an expert in all of them.  Working with one or more partners means that you have a fresh perspective when you need it.  It also helps when there are situations where time is of the essence.  For example, at one point I had system level privileges on a box and found the flag, but needed a way to get it onto my system.  We had a running FTP server to make the transfer, but this risks the other team seeing the file.  With the help of a partner, we had the file on the server, downloaded, and removed in under 5 seconds.
  2. Keep important files on removable media: I constantly found myself transferring files between different environments.  Some were flags, some were exploit code, others were just files with notes on them.  At one point I had my attack VM lock up on me and die to the point where I had to restore it from a snapshot.  Had I not been keeping my important files on removable media, it would have cost us several flags and many points.  Thank goodness for being prepared.
  3. Don't submit all of your flags at once: Believe it or not, there's quite a bit of strategy involved in how you present your team.  Show too little points and people will think you're a chump.  It'll encourage others to join the game because they feel they can make up those points quickly.  Show too many points and now the competition feels the need to work harder and faster to catch up.  My partner and I decided that it was best to start off with a low number of points.  We posted a few flags just to show some progress, but kept a large number in our back pocket for later.  At the end of day one I posted some more, but not all of the remaining flags.  In hindsight, this was a bad move on my part as it seemed to get the other team moving faster.  At the beginning of day 1 they posted enough points to overtake us on the scoreboard, but we still had enough flags in waiting at that point to more than make up the difference.  We decided to hold them until the end to make the other team think they had it in the bag.  I think this proved to be a far smarter strategy.
  4. Have a variety of different environments available: Since the CTF machines were running a wide variety of host operating systems, we ran into a number of challenges where we needed to be able to mimic a similar environment.  Fortunately, I had a fairly diverse system that I was running which had OSX, Windows, and Linux.  I found myself constantly switching between them during the game.  I know that other players were definitely hindered by their lack of diverse environments.
  5. Take snapshots of your environments: As I mentioned in #2 above, at one point I had my attack VM lock up on me.  I tried restarting, but no matter what I did, I couldn't get back into the GUI interface to resume my attacking.  This would have killed my game.  Snapshots to the rescue.  Fortunately, before I started, I took a snapshot of my VMs and was able to quickly and easily roll back to a known good state.
  6. Have Internet access available: Maybe it's via your phone or via another computer attached to a different network, but there were a number of times where we had to query things on the Internet.  Sometimes it was for scripts (like a PHP C99 shell) and sometimes it was for knowledge, but without Internet access, things would have been far more difficult.
  7. Know how to query an exploit database: Assuming that you found a way to get Internet access, you should know how to use an exploit database like the one at http://www.exploit-db.com.  After you do your discovery, you have a list of running applications, sometimes even version numbers, and need to know if they are affected by any vulnerabilities with known exploits.  That's where these guys come in.
  8. Update in advance: In several cases, the needed exploit was provided in the latest version of Metasploit.  Unfortunately, my partner had a version that was a bit outdated.  As in the case of this CTF, Internet access was not available in the game environment.  He ended up taking his system onto the conference wireless network to do the update, but it sidetracked him for a fairly significant amount of time.  It's far easier to update your tools before you walk into the CTF environment so you can spend your time actually hacking all the things.
  9. Be well versed in exploitation tools: The time I spent listening to my friend Raphael Mudge talk about penetration testing with Armitage paid off dividends here as did the many months our study group went through David Kennedy's Metasploit book.  I went into it feeling like I had a pretty good grasp on the concepts with no practical application of the skills.  Now, I feel like the CTF gave me the practical application and then some.  If you don't have at least some knowledge of a tool like Metasploit or Armitage, you're going to struggle.
  10. Explore the system: The system that I mentioned earlier that we used to take over the botnet command and control was one that I had rooted several hours earlier.  I browsed the system, got the flag, and moved on.  It wasn't until I established a VNC connection to the system that I found the CnC console staring right back at me.  It had been there all along and because I didn't give the system enough attention, I moved right on past what could have won us the game far sooner.  Remember, there are many different ways to view the data on the system.  Be somewhat thorough while at the same time remembering that time is of the essence.
  11. Know how to use a directory brute forcer: I think that many of the people who came in, played for an hour, and then left got stuck here.  They ran their scan, found some HTTP servers, and connected to them but saw nothing but a "Hello world!" message.  They knew that something was running, but couldn't figure out what.  Fortunately, I'm familiar with the OWASP ZAP tool and was able to tell it to brute force common directories on the web server.  We found a number of different applications this way that there was really no other way to find.  Your Metasploit exploits will never work if you can't tell it the proper URI to target.

So, there you have it.  My list of lessons learned from participating in (and winning) my first Capture the Flag (CTF) challenge.  Big thanks to my partners Alek and Nate for pwning systems alongside me.  As I said in #1 above, CTF is a team sport and I couldn't have won it without you guys.


Come to CloudCamp Austin 2!

The second CloudCamp in Austin is happening June 10.  It's an unconference about, of course, cloud computing.  Read about it and sign up here!

I missed the first one but loved OpsCamp so I'm going!


Upcoming Free Velocity WebOps Web Conference

O'Reilly's Velocity conference is the only generalized Web ops and performance conference out there.  We really like it; you can go to various other conferences and have 10-20% of the content useful to you as a Web Admin, or you can go here and have most of it be relevant!

They've been doing some interim freebie Web conferences and there's one coming up.  Check it out.  They'll be talking about performance functionality in Google Webmaster Tools, mySQL, Show Slow, provisioning tools, and dynaTrace's new AJAX performance analysis tool.

O'Reilly Velocity Online Conference: "Speed and Stability"
Thursday, March 17; 9:00am PST
Cost: Free


Techniques in Attacking and Defending XML/Web Services

This presentation was by Jason Macy and Mamoon Yunus of Crosscheck Networks - Forum Systems.  It wins the award (the one I just made up) for being the most vendor-oriented presentation at the conference.  Not that it wasn't an interesting presentation, but their solution to defend against most of the attacks was "Use an XML Gateway" (guess what Forum Systems sells?) and the attacks were all presented using the CrossCheck SOAPSonar tool.  I realize that being a vendor they probably have more knowledge than most in the field, but being an Open Source conference, you'd think they would have demonstrated using a free/open tool (SOAPUI?) and talked more about non-hardware solutions to fix the issues.  My notes from the session are below:


  1. Introduction to XML/Web Services Threats
  2. Techniques for Defending XML Threats
  3. XML Attack Examples and Classification
  4. Review sample attacks

Introduction to XML Threats

  • Explicit Attacks
    • Forced Disruption
    • Information Theft
    • Vendor Discovery
  • Implicit Vulnerability
    • Perimeter Breach (embeeded virus, malware)
    • Infrastructure Malfunction (parser and data processing failures)

New Attack Vectors

  • Protocol Firewalls are blind to XML
  • Malware and virus delivered via SOAP attachments
  • WSDL exposes schema and message structure
  • Injection attacks exposed via XML parameters
  • Data replay attacks

Security Testing - Base Requirements

  • Security Framework
    • Sign, ENcrypt, Decrypt, SSL
  • Identity Framework
    • Basic auth, SSL auth, WS-Security token auth
  • Parameter Injection
    • Database or file driven
    • Permutations for security, identity, and SOAP/XML
  • Concurrent Client Simultaneous Loading
    • Denial of Service Testing
  • SOAP with Attachments
    • Malware and Virus testing
  • Dynamic XSD Mutation
    • Derive SOAP vulnerability profile from WSDL schema

The OWASP Security Spending Benchmarks Project

This presentation was by Boaz Belboard, the Executive Director of Information Security for Wireless Generation and the Project Leader for the OWASP Security Spending Benchmarks Project.  My notes are below:

It does cost more to produce a secure product than an insecure product.

Most people will still shop somewhere, go to a hospital, or enroll in a university after they have had a data breach.

Why do we spend on security?  How much should we be spending?

  • Security imposes extra costs on organizations
  • The "security tax" is relatively well knnown for network and IT security - 5 to 10% (years of Gartner, Forrester, and other studies)
  • No comparable data for development or web apps
  • Regualtions and contracts usually require "reasonable measures".  What does that mean?

OWASP Security Spending Benchmarks Project

  • 20 partner organizations, many contributors
  • Open process and participation
  • Raw data available to community

Reasons For Investing in Security

  • Contractual and Regulatory Compliance
  • Incident Prevention, Risk Mitigation
  • Cost of Entry
  • Competitive Advantage

Technical and Procedural Principles

  • Managed and Documented Systems
  • Business-need access
  • Minimization of sensitive data use
  • Security in Design and Development
  • Auditing and Monitoring
  • Defense in Depth

Specific Activities and Projects

  • Security Policy and Training
  • DLP-Type Systems
  • Internal Configurations Management
  • Credential Management
  • Security in Development
  • Locking down internal permissions
  • Secure Data Exchange
  • Network Security
  • Application Security Programs

Building an In-House Application Security Assessment Team

This presentation was by Keith Turpin from The Boeing Company.   About three years ago, all of Boeing's assessments were coming from outsourced service providers.  They realized that they were unable to have control over the people and process and had difficulties integrating the controls into the SDLC and decided to bring these functions in house.  The goal of this presentation is to show some of the issues they ran into and how they addressed those problems.  My notes from the presentation are below:

Contraced Services Considerations

  • Some Advantages:
    • Highly skilled
    • Established tools, processes, and standards
    • Unbiased
    • Available as needed
  • Some Disadvantages:
    • Expensive, especially for an extended engagement
    • Less control and flexibility
    • Not familiar with company processes and culture
    • Rotating staff


  • Considerations for establishing an internal team:
    • Time to staff and train the team
    • Overlap of external and internal teams
    • Development of processes and standards
    • Acquiring necessary tools

Service Model

  • Define the services your team will provide.  This will be greatly influenced by:
    • The team's size and skills
    • The number of applications you have to support
    • The tools available
    • The level of executive support
    • The funding model
      • Who pays for your services
    • The team's role
      • Development support, pre-deployment testing or post deployment auditing and pen testing

The 10 Least-Likely and Most Dangerous People on the Internet

This presentation was by Robert "RSnake" Hansen and was designed to be a fun conversation to have over drinks with security people.  I feel privileged to have been one of those security people who he talked about this with beforehand.  A very interesting topic about the non-obvious threats that may or may not exist.   My notes are below:


  • Because I use the Internet
  • Because I'm a target
  • Because most people don't know
  • Because it's a fun conversation to have over drinks with security guys
  • Maybe/hopefully you'll continue this conversation instead of just arguing!

Ground Rules

  • Must be non-obvious and must be directly related to the Internet.  Not:
    • ...the President or any other gov'ernment official
    • ...or someone involved with SCADA Systems/Brick and mortar
  • Must be in control of some infrastructure or software, etc
  • Must have the largest or widest negative impact possible for the least amount of work and least likelihood of being stopped
  • No magic - must be real and dangerous
  • They can't be "bad" people
  • You can't take this list too seriously

How I Got Started

  • Started thinking about core technologies that everything relies on
  • Made a big list
  • Shopped it around to dozens of security experts
  • Assigned an arbitrary, unscientific, hand-wavy, risk-rating system of my own design
  • Ranked them in order of how scared I am of them personally


  • John Doe at C|Net
  • Job: Network Engineer
  • Why: Controls com.com
  • Impact: Largest collection point of typo traffic both for web adn email.
    • Doesn't require anything overt or even indefensible


  • Giorgio Maone of NoScript
  • Job: Consultant
  • Why: Controls NoScript
  • Impact: Nearly every security researcher on the planet - complete compromise.  In general the most paranoid people on earth would be compromised.
    • Builds arbitrary whitelists (ebay.com)
    • Has changed functionality to subvert Adblock Plus

OWASP Top 10 – 2010

This presentation was by Dave WIchers, COO of Aspect Security and an OWASP Board Member.  My notes are below:

What's Changed?

  • It's about Risks, not just vulnerabilities
    • New title is: "The Top 10 Most Critical Web Application Security Risks"
  • OWASP Top 10 Risk Rating Methodology
    • Based on the OWASP Risk Rating Methodology, used to prioritize Top 10
  • 2 Risks Added, 2 Dropped
    • Added: A6 - Security Misconfiguration
      • Was A10 in 2004 Top 10: Insecure Configuration Management
    • Added: A8 - Unvalidated Redirects and Forwards
      • Relatively common and VERY dangerous flaw that is not well know
    • Removed: A3 - Malicious File Execution
      • Primarily a PHP flaw that is dropping in prevalence
    • Removed: A6 - Information Leakage and Improper Error Handling
      • A very prevalent flaw, that does not introduce much risk (normally)
  1. A1- Injection: Tricking an application into including unintended commands in the data sent to an interpreter. (http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet)
  2. A2 - Cross Site Scripting (XSS): Raw data from attacker is sent to an innocent user's browser.  For large chunks of user supplied HTML, use OWASP's AntiSamy to sanitize this HTML to make it safe.  (http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet)
  3. A3 - Broken Authentication and Session Management: Means credentials have to go with every request.  Should use SSL for everything requiring authentication.
  4. A4 - Insecure Direct Object Reference: This is part of enforcing proper "Authorization", along with A7 - Failure to Restrict URL Access.
  5. A5 - Cross Site Request Forgery (CSRF): An attack where the victim's browser is tricked into issuing a command to a vulnerable web application.  Vulnerability is caused by browsers automatically including user authentication data with each request.  (Check out OWASP CSRFGuard, OWASP CSRFTester, http://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet)
  6. A6 - Security Misconfiguration: All through the network and platform.  Don't forget the development environment.  Think of all the places your source code goes.  All credentials should change in production.
  7. A7 - Failure to Restrict URL Access: This is part of enforcing proper "authorization", along with A4 - Insecure Direct Object References.
  8. A8 - Unvalidated Redirects and Forwards: Web application redirects are very common and frequently include user supplied parameters in the destination URL.  If they aren't validated, attacker can send victim to a site of their choice.
  9. A9 - Insecure Cryptographic Storage: Storing sensitive data insecurely.  Failure to identify all sensitive data.  Failure to identify all the places that this sensitive data gets stored.  Failure to properly protect this data in every location.
  10. A10 - Insufficient Transport Layer Protection

OWASP Top 10 Risk Rating Methodology

  • Attack Vector (How hard for an attacker to use this flaw - 1 (Easy), 2 (Average), 3 (Difficult))
  • Weakness Prevalence (How often is it found - 1 (Widespread), 2 (Common), 3 (Uncommon))
  • Weakness Detectability (How hard is it for an attacker to find the flaw - 1 (Easy),  2 (Average), 3 (Difficult))
  • Technical Impact (1 (Severe), 2 (Moderate), 3 (Minor))

This is generic across the internet, not specific to any organization.

Started a new "Prevention Cheatsheet Series" that the Top 10 references (XSS, SQL Injection, Transport Layer Security, CSRF, Direct Object Reference).

What is actually being released is RC1 of the Top 10 and they are encouraging people to provide comments through the end of the year and then use that feedback to post the final Top 10 in January 2010.