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

My First Experiences with a Palo Alto Firewall

I've been following Palo Alto as a networking company for a couple of years now.  Their claim is that the days of the port-based firewall are dead and that their application-centric approach is a far better way to enforce your access controls.  Take the HTTP protocol for example.  HTTP typically runs as a service on port 80, but does that mean that everything running on port 80 is HTTP?  As an attacker looking for a way to funnel data out of your organization, why not use the standard HTTP port to send data, since I know you leave it wide open in order for your employees to surf the web.  There's nothing to say that I actually have to be running an HTTP server on the other end and there's nothing on my classic firewall to tell any differently.  At first, I was admittedly a bit skeptical.  I didn't think that you could really tell enough about different applications on the web to be able to separate them out like Palo Alto claims to.  Fortunately, Palo Alto reached out to me and provided me with a brand new PA-200 in an attempt to change my mind.

When the PA-200 arrived, it came with everything that I would need to get it up and running.  That includes the unit itself, a power supply, a D89 to RJ45 console cable, an ethernet cable, and some instructions and warranty information.


On the front of the unit is four ethernet ports for your devices, a management port, a USB port, a console port, and several status indicator LEDs.


By default, the appliance is configured with ethernet ports 1 and 2 paired as a WAN to LAN link as this is the configuration that the majority of the people who buy it will likely use it for.  That said, by following the instructions to connect your computer up to the management port, you can quickly access the user interface that allows you to change this assignment.

Ethernet Configuration

This shows the ethernet 1 and 2 interfaces as both being a "virtual wire" and here we can see the virtual wire that connects the two.

Virtual Wire

From here, we can take a look at the "zones" and see that our two interfaces have been defined as an untrusted (ethernet 1) and trusted (ethernet 2) zone.


To think of this a different way, my cable modem WAN connection (ie. the Internet) goes in my "untrust" zone and my local network (ie. LAN) goes in my "trust" zone.  Now all that's left is to set our policy and for ease of management to start with, I set it to allow everything out with a default deny all inbound.

Security Profile

With this configuration I had done enough to be up and running on the device and I immediately started to see data populate the dashboard on the top applications running on my network.

Top Applications

It's color coded based on risk level and the dashboard also provides me a similar view of Top High Risk Applications.  Any of these boxes can be clicked on in order to provide additional data about the protocol, sources, destinations, countries, and more.

Application Information

Now, let me say that while I'm running this on my home internet connection, this thing is a hoss and can do way more than I can throw at it.  With their App-ID technology enabled you can throw 100 Mbps of throughput at it no problem.  In addition to being an application firewall, it also does standard port-based firewalling, VPN, routing, switching, and so much more.  It's so extremely versatile that this thing could easily be placed in a smaller branch office and replace multiple other devices on their network such as a firewall, router, and VPN concentrator.  More functionality for less money...who wouldn't want that?  In addition to these default capabilities, additional licensing can also be obtained to allow you to do URL filtering, malware detection, and more.  Having just gotten this up and running, I'm still exploring the ins and outs of all of the functionality, but it's pretty exciting to have all of this capability in a box that is smaller than the cable modem my ISP provides me.  More posts to come on this as I get deeper into the guts of running my new Palo Alto PA-200 !


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

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.


Application Security Metrics from the Organization on Down to the Vulnerabilities

This presentation was by Chris Wysopal, the CTO of Veracode.  My notes are below:

"To measure is to know." - James Clerk Maxwell

"Measurement motivates." - John Kenneth Galbraith

Metrics do Matter

  1. Metrics quantify the otherwise unquantifiable
  2. Metrics can show trends and trends matter more than measurements do
  3. Metrics can show if we are doing a good job or bad job
  4. Metrics can show if you have no idea where you are
  5. Metrics establish where "You are here" really is
  6. Metrics build bridges to managers
  7. Metrics allow cross sectional comparisons
  8. Metrics set targets
  9. Metrics benchmark yourself against the opposition
  10. Metrics create curiosity

Metrics Don't Matter (Mike Rothman)

  • It is too easy to count things for no purpose other than to count them
  • You cannot measure security so stop
  • This following is all that matters and you can't map security metrics to them:
    • Maintenance of availability
    • Preservation of wealth
    • Limitation on corporate liability
    • Compliance
    • Shepherding the corporate brand
  • Cost of measurement not worth the benefit

Bad metrics are worse than no metrics

Security Metrics Can Drive Executive Decision Making

  • How secure am I?
  • Am I better off than this time last year?
  • Am I spending the right about of money?
  • How do I compare to my peers?
  • What risk transfer options to I have?

Goals of Application Security Metrics

  • Provide quantifiable information to support enterprise risk management and risk-based decision making
  • Articulate progress towards goals and objectives
  • Provides a repeatable, quantifiable way to assess, compare, and track improvements in assurance
  • Focus activities on risk mitigation in order of priority and exploitability
  • Facilitate adoption and improvement of secure software design and development processes
  • Provide and objective means of comparing and benchmarking projects, divisions, organizations, and vendor products

The ESAPI Web Application Firewall

This presentation was by Arshan Dabirsiaghi and was about the OWASP ESAPI Web Application Firewall (WAF) project.  My notes are below:

WAF Fallacies (at least in regards to OWASP ESAPI WAF)

  • WAFs add attack surface
  • WAFs can create culture problems
  • WAFs can't fix business logic vulnerabilities
  • WAFs are way too expensive
  • WAFs complicate networks

Why fix in ESAPI WAF vs Fix in code?

  • Changing in ESAPI WAF is just a text file
  • Shorter gap between time discovered and WAF fix vs code fix

Advantages of WAF

  • Performance - Only your rules are checked, plus state is already managed by the app server
  • Capability - being closer to the app lets us do more
  • Process - Rules are closer to application owner, shortening discovery-to-patch time, also fix-to-patch-removal time

Principle: Make common tasks easy, uncommon tasks possible

General virtual patching functionality is easy to understand

Ability to write custom script rules as well "bean-shell-rules"
Fixing Injection Flaws is easy

Can fix business logic flaws with the WAF (missing authentication, missing functional access control, missing data layer access control)

Can add "outbound" security as well

  • Add anti-clickjacking header
  • Set uniform content-type
  • Add HttpOnly flag
  • Add secure flag
  • Detect outbound information
  • Replace outbound information

Takes advantage of early failing to make rules as optimized as possible

Now we see the tool demonstrated with several different vulnerabilities in a real-world application (JForum):

  • Cross-Site Scripting Flaw (JForum XSS flaw is unable to be fixed with a WAF because of dynamic URLs)
  • Unchecked Redirect
  • Add HttpOnly
  • Add anti-clickjacking header
  • Privilege escalation

3 Different WAF Modes

  • Log
  • Block
  • Redirect

Latency with all of the rules turned on is about 5%.  With selected rules is closer to 0%.  Basically an order of n magnitude where n is the number of rules enabled.  Comes out to milliseconds.


Enterprise Application Security – GE’s Approach to Solving Root Cause

The first presentation of the day that I went to  was by GE's Darren Challey and was about GE's application security program and how he took a holistic approach to securing the enterprise.  My notes on this presentation are below:

Why is AppSec so hard?

  • AppSec changes rapidly (look at difference between 2004, 2007, and 2010 Top 10)
  • Changing landscape
    • Increase skill and talen t pool of technically proficient individuals willing to break the law
    • Growing volume of financially valuable data online
    • Development of criminal markets (black markets) to facilitate conversion to money
  • "Attackers now have effective skills, something to steal, and a place to sell it"
  • Application Security is a complete one-sided game
  • Need to become an enabler (not a barrier)
  • Must inject application security earlier through Guidance, Education, and Tools
  • Must understand the development and deployment process and integrate rather than mandate
  • NIST study on cost to repair defects when found at different stages of software development (http://www.nist.gov/director/prog-ofc/report02-3.pdf)
  • Solving the problem of the enterprise (Culture Change)
  • Success factors
  • Form a mission and strategy
  • Develop policy (but not corporate "mandate")
  • Gain executive buy-in (cost / benefit / risk)
  • Understand the magnitude of problem (metrics)
  • Asset inventory and vulnerability management
  • Develop standards (what should I do and when?)
  • Establish a formal program (strong leadership)
  • Focus on education and training materials
  • Develop in-house expertise, services and "COE"
  • Continuous improvement, measurement, KPI
  • Communicate!
  • Drive a culture change (shared need, WIIFM)
  • Communicate expectations with vendors
  • Implement incentives (and penalties)
  • Digitize after the process is solid (tools)
  • AppSec program mission & structure
  • AppSec program strategy
  • Policy (guidance) -> Standards (Guidance) -> Training (Education) -> Metrics (tools) -> Security tools (tools) -> Inventory & tracking (tools) -> Monitor & Improve


  • "GE Application Security Working Group" (Talking to the businesses is critical!  Meet every 2 weeks.)
  • Secure Coding Guidelines
  • Vulnerability Remediation Guide
  • Secure Deployment
  • Quick Reference Card
  • Contractual Language
  • Desk Calendars
  • Metrics: AppSec calendars helped increase visitors to key Guidance materials  (track hits to website docs when certain activities take place)


  • CBT1: Intro to AppSec at GE (60 min for any IT person) - why AppSec is important and what happens when you don't do it
  • CBT2: GE Best Practices for Secure Coding (90 min)
  • CBT3: Attack Profiles & Countermeasures (120 min for security people)
  • Developer Awareness Assessment:
    • 100's of internally-developed questions
    • Randomized questions, timed completion
    • Vendors track their own resutls
    • Allows tailoring of training/awareness programs


  • - COE AppSec assessment services
  • Vendor framework & Metrics
  • Compliance handbook
  • Common objects repository
  • GE Enterprise Application Security
  • Scanning and Monitoring tools
  • Automation is the way to go (but the tools are not quite there yet)


  • Measure Vendor AppSec Performance (Avg % Critical/High Vulnerabilities per Assessment vs % Assessments with Zero Critical/High Vulnerabilities)
  • Is it making a difference (map avg of critical/high vulnerabilities per assessment)

Forming a Center of Excellence

  • Combines the best available people, processes and tools
  • Formal training & defined roles (Comprehensive training program for all auditors to ensure skills are kept current and that auditors can provide more than one type of service)
  • COE Team structure (tools, research, operations, stakeholder management, queue management, application security auditors
  • Application Assessment Types (black/grey box vs white box)
  • Application assessment process (map of the workflow with "swim lanes" of who does each step)
  • Measure number of vulnerabilities and severities
  • Measure customer satisfaction (overall, ease of engagement, responsiveness)

Assessing Your Web App Manually Without Hacking It

After giving my presentation on "Using Proxies to Secure Applications and More" at the TRISC 2009 conference, I decided to attend the presentation by Robert "RSnake" Hansen and Rob MacDougal entitled "Assessing Your Web App Manually Without Hacking It".  The gist of this presentation was that with a few simple tools (Web Developer Toolbar, NoScript, you web browser) you can spend about an hour looking at the characteristics of a web application in order to determine what types and how many vulnerabilities it may have.  My notes on the presentation are below:


Cryptography for Penetration Testers – OWASP AppSec NYC 2008

This presentation was on "Cryptography for Penetration Testers" and was by Chris Eng, the Senior Director of Security Research at VeraCode.

The Premise

How much do you really have to know about cryptography in order to detect and exploit crypto weaknesses in web apps.


  • Learn basic techniques for identifying and analyzing cryptographic data
  • Learn black-box heauristics for recorgnizing weak crypto implementation
  • Apply techniques

The Crypto that Matters in 6 Short Slides

Types of Ciphers

  • Block Ciphers: Operates on fixed-length groups of bits, called blocks.  Block sizes vary depending on the algorithm.  Several different modes of operation for encrypting messages longer than the basic block size.  Example ciphers include DES, 3DES, Blowfish, AES
  • Stream Ciphers: Operates on plaintext one bit at a time

Block Ciphers: Electronic Code Book (ECB) Mode

  • Fixed-size blocks of plaintext are encrypted independently
  • Each plaintext block is substituted with ciphertext block, like a codebook
  • Weaknesses: Structure in plaintext is reflected in ciphertext.  Ciphertext blocks can be modified without detection.

Bliock Ciphers: Cipher Block Chaining (CBC) Mode

  • Each block of plaintext is XORed with the previous ciphertext block before being encrypted
  • Change of message affects all following ciphertext blocks
  • Initialization Vector (IV) is used to encrypt first block

Stream Ciphers

  • Plaintext message is processed byte by byte (as a stream)
  • Key scheduler algorithm generates a keystream using a key and an Initialization Vector (IV combined (XOR) with plaintext bit by bit
  • Encrypt by XORing plaintext with the generated keystream

Common Crypto Mistakes

  • Insecure cipher mode (usually ECB)
  • Inappropriate key reuse
  • Poor key selection
  • Insufficient key length
  • Insecure random number generation
  • Proprietary or home-grown encryption algorithms (Don't do this ever!)

Analysis Techniques

Dealing with Gibberish Data

What do you do when you are pen testing a web application and you encounter data that is not easy to interpret?

  • Cookies
  • Hidden fields
  • Query string parameters
  • POST parameters

How random is it?

  • Output of cryptographic algorithms should be evenly distributed, given a sufficiently large sample size.
  • Tools such as ENT (http://www.fourmilab.ch/random) will calculate entropy per byte, chi-square distribution, arithmetic mean, serial correlation, etc

Observe Characteristics

Is the length a multiple of a common block size?

  • Indicates that the application may be using a block cipher

Is the length the same as a known hash algorithm?

  • For example, MD5 is usually represented as 32 hex characters
  • May also indicate the presence of an HMAC
  • Still may be worthwhile to hash various permutations of known data in case a simple unkeyed hash is being used

Stimulus, Response

Does the length of the token change based on the length of some value that you can supply?

For a block cipher, you can determine the block size by incrementing input one byte at a time and observing when the encrypted output length jumps by multiple bytes (ie, the block size)

How does the token change in response to user-supplied data?

  • Figure out how changing different parts of the input affects the output
  • Is more than one block affected by a single character change in the input?

Deeper Block Cipher Inspection

Are there any blocks of data that seem to repeat in the same token or over multiple tokens?

  • Possibly ECB mode, this doesn't just happen by coincidence


Context:  A public-facing web portal for a large ISP.  Used an encrypted cookie to authenticate identity.  A new cookie is issued on each request.  Base64 decoded EE cookies.  Divided by 8 and found 8 byte blocks.  Noticed some repetition in the same position.  The only variable blocks are the last two (possibly a "last accessed" timestamp or similar timeout mechanism).  Register a new account with a username of 'c' x 32, the maximum length permitted, and observe the value of the EE cookie.

'c' x 32 is Perl notation for "cccccccccccccccccccccccccccccccc"

The token is longer, meaning the username is probably stored in the cookie.  Still noticed repition in same position.  Register another account with a username of 'c' x 16 and compare to the EE cookie generated in the previous step.  Didn't see two identical blocks for 'c' x 16 and four identical blocks for 'c' x 32.  Reason is padding.  The username doesn't align perfectly with the block offset.  Want to figure out what position in the cookie the usernaem is located.  Additional user accounts were created with specific usernames in order to determine if there is any initial padding in the first block.  Now you know where the username is in the ciphertext.

Able to successfully subvert the authentication mechanism without any knowledge of the algorithm or the key, based solely on observed patterns in the ciphertext.  The root cause was the insecure cipher mode and the lack of a verification mechanism.  ECB mode shoul dnot be used (use CBC instead).


Token values observed in URLs.  Changed every time we logged on to the application.  Never the same for any two sessions or any two users.  Base64 decoded values for several different "stmt" tokens.  Statement numbers were displayed in the browser.  Looked for correlations between statement number and cipher-text.  Conclusion: It looks like a stream cipher.  Use XOR to calculate 10 bytes of the keystream based on the known plain-text (ie. the statement number).  Now try the same things against one of the other collected tokens, such as the one called "Ctxt".  Get ASCII text that allows you to infer what it would say.  Expand it out more and more to get the keystream.  Repeat over and over until you have enough of the key to figure out anything in the application.

Through this iterative process, we can obtain the entire keystream (or rather, a sufficient amount of the keystream to encrypt and decrypt all of the cipher-text we encounter).  Can replace the statement number with another valid statement number and view the contents.

Able to subvert the encryption mechanism without any knowledge of the algorithm or the key based solely on observed patterns in the ciphertext.  They were using RC4 with a unique key generated for each user session.  Root cause of the vulnerability is the re-use of the keystream.


Practical Advanced Threat Modeling – OWASP AppSec NYC 2008

This presentation was by John Steven who is the Senior Director of Advanced Technology Consulting at Cigital, Inc.

What is a threat?

  • An agent who attacks you?
  • An attack?
  • An attack's consequence?
  • A risk?

What is a threat model?

  • Depiction of the system's attack surface, threats who can attack the system, and assets threats may compromise.
  • Some leverage risk management practices.  Estimate probability of attack.  Weigh impact of successful attack.

Elements of a threat model

  • Structural view
  • Threat actors
  • Assets
  • Attack vectors
  • Privilege/"trust"


  • Capability: Access to the system, able to reverse engineer binaries, able to sniff the network
  • Skill Level: Experienced hacker, script kiddie, insiders
  • Resources and Tools: Simple manual execution, distributed bot army, well-funded organization, access to private information
  • Threats help encourage thorough throught about how intentions for misuse and determine "out of bounds" scenarios.

A Few Words on STRIDE

  • A conceptual checklist backed by data flow diagrams

Attack Trees

  • Aggregate attack possibilites
  • Use OR, AND
  • Allow for decoration (probability, cost, skills required, etc)

Threat Modeling as a Process

  • Use threat modeling to identify where potential threats exist relative to the architecture, how threats escalate privilege, specify vectors of attack, identifies components and assets worth protecting.

Leading Up to Threat Modeling

  • Identify threats
  • Enumerate doomsday scenarios
  • Document misuse/abuse
  • Diagram structure, assets
  • Annotate diagram with threats
  • Enumerate attack vectors
  • Iterate

Input: Goals, Doomsday Scenarios

Misuse/Abuse Cases (use case view and component view)

Inputs: Security Requirements (specified security features - "128 bit encryption", "software security != security software")

Anchor in Software Architecture

Consider where attacks occur:

  • Top-down: enumerate business objects (sensitive data, privileged functionality)
  • Bottom-Up: enumerate application

Output: Security Assessment & Test Design.  Threat models drive assessments, Test design.  Establish rules of engagement.  Prioritize areas of interest.  Manage a team in risk-based fashion.  Establish a single tie between vulnerability and control.

Application Structure: No "One Size Fits All"

Application Structure: Topology - Coloration shows authorization by role.  Arrows indicate resolution of principal/assertion propagation.  Use structure to separate privilege.

Application Structure: Components - Component diagrams show critical choke points for security controls (input validation, authentication, output encoding).

Application Structure: Frameworks - Showing frameworks indicates where important service contracts exist "up" and "down".

Assets: Flow - Assets exist not only in rest, but also flow through the system.  Use different types of flags to represent data flow of assets.

Use different colored arrows to represent each different attack vector.

Target Using Layered Attacks: Bootstrap later attacks with those that "deliver".  Use one layer to exploit another (net, app).  Combine attacks to reach desired target.

Take Homes

  • Base threat model in software architecture
  • When specific use (cases) and high-level architecture are defined: inventory roles, entitlements, if one doesn't exist and inventory assets, sensitive data, privileged components
  • Enumerate initial attack vectors.  Use common low hanging fruit.
  • Elaborate more attacks.  Find opportunities for privilege escalation.  Layer attacks to target or "hop" to assets.  Fill in gaps by "inventing" attacks.
  • Use threat modeling to drive security testing