CAPTCHA Re-Riding Attack

By Gursev Kalra.

The CAPTCHA re-riding attack bypasses the CAPTCHA protections built into the web application. The attack exploits the fact that the code which verifies a CAPTCHA solutions sent by the user does not clear the CAPTCHA solution from the HTTP session. A typical scenario to demonstrate the vulnerability is explained below:

1. A user visits the registration page of a website.
2. The website creates an HTTP session, assigns it a SESSIONID, and returns the registration page to the user along with the SESSIONID cookie. The registration page also contains one image tag which directs the browser to retrieve a CAPTCHA and display it on screen.
3. Upon parsing the image tag, the browser sends out request for the CAPTCHA.
4. The server side code creates a new CAPTCHA with random text and CAPTCHA solution is stored in the HTTP session
5. The CAPTCHA image is then sent to the client and is then displayed by the browser.
6. Browser sends the CAPTCHA solution along with form fields for verification.
7. Server side code retrieves the CAPTCHA solution from the HTTP Session and verifies it against the solution provided by the client.
8. If verification is successful, client is sent to next logical step in the registration process. If not, client is redirected to the start registration page (step 1 above).

Figure 1: Image shows an example Register page that supports CAPTCHA

Analysis of the CAPTCHA generation and verification process reveals the following:

1. The captcha.php is the only page responsible for updating the HTTP session with correct CAPCHA solution. The first ingredient.
2. CAPTCHA solution inside the HTTP session is not explicitly cleared during the verification process. Yes, you guess it right. This is the second and the most important ingredient for CAPTCHA re-riding attacks.
3. When registration fails (for any reason), the web applications continue to use the same HTTP session and SESSIONID. We will not look into this further.
4. When registration succeeds, the user is redirected to next step and the CAPTCHA generation page (/captcha.php) is not likely to be called for current SESSION again. This allows the CAPTCHA solution to stay in the HTTP store for as long as SESSION is valid. Following are the likely scenarios to be seen when CAPTCHA verification is successful:
   
   
   1. The web application generates a new SESSIONID for the same HTTP session for known security reasons. This implementation is most likely to be seen. Combine this behavior with first and second ingredients above and you have a successful CAPTCHA Re-Riding attack.
   2. The web application continues to use the same SESSIONID for the same HTTP session. Here we have more things to worry than just the CAPTCHA. For now, combine this behavior with first and second ingredients above and you have a successful CAPTCHA Re-Riding attack again.
   3. The web application generates a completely new HTTP session with new or same SESSIONID. For CAPTCHA Re-riding Attack, this scenario is not exploitable.

For scenarios 4.a and 4.b, the HTTP Session continues to hold the CAPTCHA solution as it is not explicitly cleared by the CAPTCHA verification code. Since /captcha.php is not going to be called again (and we will not let the call happen anyway), the same CAPTCHA solution continues to exist in HTTP session. Let us now see how 4.a & 4.b scenarios above can be exploited to make multiple successful submissions using a CAPTCHA solution.

Exploiting Scenario 4.b

1. Load the register page of the target website in a web browser.
2. Solve the CAPTCHA manually, and submit the form.
3. Record this form submission using a web proxy. This request contains a valid SESSIONID, valid form fields and a valid CAPTCHA solution.
4. Create a custom script or use any tool like Burp intruder that can repeatedly send this request to server. With each request change the unique values (like User ID) to create multiple new accounts with a single CAPTCHA solution.

Exploiting Scenario 4.a

1. Load the register page of the target website in a web browser.
2. Solve the CAPTCHA manually, and submit the form.
3. To make things easy, trap this request in a web proxy and do not allow it to reach the web server. This request contains a valid SESSIONID, valid form fields and a valid CAPTCHA solution.
4. Create a custom script or use any tool like Burp intruder that can repeatedly send this request to server.
5. Submit one request.
6. Upon successful submission, the web application will reset the current SESSIONID and send new SESSIONID back in response headers.
7. Change the value of SESSIONID in recorded request (step 3) to the value copied from response in Step 6 above.
8. Go to step 5.
9. We will be able to make multiple successful submissions with single CAPTCHA solution.

Using one time tokens along with CAPTCHAs on the registration pages may still be exploitable with a few additional lines of attack code. The best defense is to reset CAPTCHA solution inside the HTTP session during the CAPTCHA verification stage.

Deconstructing a Credit Card's Data

By Brad Antoniewicz.

Modern credit cards in the United States have three interfaces:

1. Physical
2. MagStripe Data
3. RFID/NFC Data

This obviously varies from bank to bank and card manufacturer to card manufacturer. The purpose of this post is to evaluate all three interfaces of the card and see how they differ. Note that some data has been changed to protect the card holder's (my) information.

Physical Attributes

This interface is probably the most widely known and understood because its been around the longest and its the easiest to inspect. It's sort of good to understand the components of this interface because they're present in to the other interfaces (but a little different).

From a physical perspective, your card should have four main attributes:

1. Name
2. Expiration Date
3. Credit Card Number
4. Card Verification Value

Names and Expiration dates are pretty straightforward and don't need much explaining.

Credit Card Number - Also known as "Primary Account Number" (PAN). The one thing to point out is that credit card numbers have some unique properties. For instance, the first number of the card number will vary depending on the type of card.

Card	Starting Number
Visa	4
MasterCard	5
Discover	6

A great article about credit card numbers is "Anatomy of Credit Card Numbers".

Another notable thing about the card number is it is actually created using a particular algorithm and thus there is a check, called the Luhn 10 check that verifies that the card number was generated in accordance with this algorithm. More info can be found here - http://www.visacemea.com/ac/ais/uploads/ais_guide_stepspcicompliant.pdf [PDF]

Card Verification Value (CVV2) - Note the version number. This is a three (MasterCard, Visa, Discover) or four (American Express, called the "CID") code printed on the card to help prevent against fraud. The idea behind it, is it proves possession of the card and is required when the card is not present. On American Express cards, this value is printed on the front, while MasterCard, Visa, and Discover cards have it printed on the back, usually in the signature box.

MagStripe Data

The magnetic stripe on the back of the card is broken up horizontally into three "tracks", the tracks often contain duplicate data and most times track 3 doesn't really contain any data.

ISO/IEC 7813 Defines the attributes of this data, and these sites describe the data available on each track in detail:

• http://en.wikipedia.org/wiki/ISO/IEC_7813
• http://www.gae.ucm.es/~padilla/extrawork/tracks.html
• http://www.tech-faq.com/layout-of-data-on-magnetic-stripe-cards.html

To read the data, you'll need a magstripe reader that will support reading all three tracks. Most magstripe readers emulate a HID (human input device), so its surprisingly easy to read from them - just open a text capturing program and swipe a card.

The reader I'm using is the MagTek SureSwipe 21040145.

So lets see what data we'll get from the magstripe:

 %B5XXXXXXXXXXXXXX2^ANTONIEWICZ/BRAD^1103101000000001000000003000000?;5XXXXXXXXXXXXXX2=1103101000000300001?  

Lets break down this data:

Track 1 Data
Track Data	Value
%	Start
B	Format Code (B=Bank)
5XXXXXXXXXXXXXX2	Primary Account Number (PAN)
^	Separator
ANTONIEWICZ	Last Name
/	Name Separator
BRAD	First Name
^	Separator
11	Expiration Year
03	Expiration Month
101	Service Code
000000001000000003000000	Discretionary Data
?	End
Track 2 Data
;	Start Track 2 Data
5XXXXXXXXXXXXXX2	Primary Account Number (PAN)
=	Separator
11	Expiration Year
03	Expiration Month
101	Service Code
000000300001	Discretionary Data
?	End

So you can see that Track 2 actually contains much data already present in track 1. You'll also notice that there is a difference in the discretionary data between track 1 and 2.

But where the heck is that Track 3 data? Well.. it doesn't appear that any data is written to it, or at least my reader isn't picking it up.

RFID Interface (EMV Chip)

In the last couple of years, the RFID Interface has been most talked about. Something about the idea of an attacker reading your credit card out of your pocket, seems to bother people :)

The RFID Interface specifications were designed by a group of representatives from Europay, MasterCard, and Visa (EMV) and is thus often referenced as the "EMV Chip" or just "EMV". The three things that differentiate this interface from the others are:

1. Card Holder Name - On most cards the cardholder name is not stored within the chip, instead its replaced by something like "VALUED CUSTOMER" or "NOT SUPPLIED"
2. Service Code - The service code that permits where the card is used (and for what) changes on the contactless interface.
3. iCVV or Dynamic CVV - Rather then using the same CVV that is stored on the MagStripe, the smartcard capabilities allows for extended functionality, and so the designers created something called a Dynamic CVV. This CVV changes which each read of the card.

The RFID Interface is defined mostly in ISO/IEC 7816 and the EMV Specifications.

VivoPay 4500

Probably the easiest way to read the RFID interface of a credit card is to buy an equipped point of sale (POS) reader and connect it up to your computer. The VivoPay 4500 will handle all of the RFID communication and output the data on the RFID interface in plaintext over it's serial connection.

Prolific PL-2303

The Prolific PL-2303 is a USB to Serial adapter which helps when connecting to the VivoPay's Serial output. If you want to make this all work on Mac OS X 10.7.3 (like i am) you have to do a little bit of work:

First download the 64-bit open source PL2303 driver:
http://sourceforge.net/tracker/download.php?group_id=157692&atid=804837&file_id=363913&aid=2952982

Then decompress and install:

 unzip osx-pl2303.kext.zip  
 sudo cp -R osx-pl2303.kext /System/Library/Extensions/  
 cd /System/Library/Extensions/  
 sudo kextload osx-pl2303.kext  

Insert your USB adapter then check to make sure the driver created a device interface (your interface might be named differently):

 system:Extensions user$ ls /dev/tty.PL*  
 /dev/tty.PL2303-000013FA  

pwnpass.py

pwnpass.py is a python script created by Eric Johnson (and others) which allows you to interact with VivoPay Devices. To use it, you may have to first install py-serial to get it running. I'm using mac ports to manage all of the python packages.

 sudo port install python26 py26-serial

Next edit line 103 of pwnpass.py so that your device is appropriately defined. The default timeout for the open source driver is 1 second, I've changed it to 0.3 which seems to work better.

return serial.Serial('/dev/tty.PL2303-000011FD', 19200, timeout=0.3)

So if we run it on the same card we used before, we see the following raw data:

 %B5XXXXXXXXXXXXXX2^SUPPLIED/NOT^1103502000000001000000637291901?;5XXXXXXXXXXXXXX2=11035020000072029191?I  

OmniKey CardMan 5321 Config

If you want to be a little more conventional, you can use a standard, off the shelf RFID reader, like the OmniKey CardMan 5321.

BackTrack Setup

In BackTrack 5, you'll have to manually install the drivers to make it all work. I explained the process here but the post needs a little updating:

1. As of today, you can download the HID driver from http://www.hidglobal.com/drivers/omnikey/ifdokrfid_lnx_i686-2.9.1.tar.gz. If they ever update it again, you'll have to go here and select the appropriate drop downs.
2. It looks like the script in the post got a little messed up by the code formatter i used. I made it directly downloadable from http://www.opensecurityresearch.com/files/cardman_fix.sh

Mac OSX 10.7.3 Setup

Making it all work on Mac OS X 10.7.3 can be a bit of a pain to figure out, but I should have most of the difficulties worked out here. First off, you'll need to install Python 2.6, and the Crypto modules.

 sudo port install python26 py26-crypto  

Next select and download the Mac OSX drivers from HID. Initially, the driver version that was available to download was ifdokrfid_mac_10.6_i386-2.4.0.1.pkg, which didn't work with 10.7.3. I had to modify the installer so that it worked for 10.7:

 vi ifdokrfid_mac_10.6_i386-2.4.0.1.pkg/Contents/Resources/InstallationCheck   

and change line 31 from this:

 if [ ${MACOS_VER_MAJOR} -ne 10 -o ${MACOS_VER_MINOR} -ne 6 ]; then   

to this:

 if [ ${MACOS_VER_MAJOR} -ne 10 -o ${MACOS_VER_MINOR} -ne 7 ]; then  

then everything should install fine.

As it turns out, HID has since released a newer version of the driver that "just works" (ifdokrfid_mac_universal-2.5.0.2.pkg). I did notice some problems with connecting the reader before running pcscd, so keep that in mind.

You can just launch pcscd from the command line:

 sudo pcscd  

If something isn't working, you can enable debugging and tell it to run in the foreground with:

 sudo pcscd -f -d

With the driver installed, pcscd running, and the reader connected, you can use RFIDiot to check if the reader was properly detected:

 RFIDIOt-1.0a user$ python2.6 cardselect.py -L  
 PCSC devices:  
 No: 0 OMNIKEY CardMan 5x21 00 00  
 No: 1 OMNIKEY CardMan 5x21 00 01  

TouchaTag (ACR122U) Reader Config

The Touchatag reader is another commercial off the shelf reader like the Omnikey Cardman 5321. It's popular because of its libNFC support, however with the tasks we're doing using RFIDiot, it doesn't really matter. I'm providing configuration information here for diversity. Once you connect the reader to your system, you'll likely notice its light seems to blink rather then staying lit. To fix this, it will require a quick little driver configuration change:

 sudo vi /usr/libexec/SmartCardServices/drivers/ifd-acsccid.bundle/Contents/Info.plist  

On line 53 (under ifdDriverOptions) change

      <string>0x00C0</string>    

to this:

      <string>0x0005</string>  

Then to make sure its working properly:

 ~ user$ nfc-list   
 nfc-list use libnfc 1.4.0 (r833)  
 Connected to NFC device: ACS ACR38U-CCID 00 00 / ACR122U102 - PN532 v1.4 (0x07)  

Once that's all set up, just start pcscd if its not already running:

 sudo pcscd  

and then check RFIDiot's cardselect.py:

 RFIDIOt-1.0a user$ python2.6 cardselect.py -L  
 PCSC devices:  
   No: 0          ACS ACR38U-CCID 00 00  

Using RFIDiot to Read Card Data

In most situations, RFIDiot's ChAP.py should be able to query the card's data. On an RFID level, the card is first queried with a generic "tell me your file structure" method, and if the card doesn't respond, the reader sends requests for specific application ID's (AIDs) that are known structures for different vendors (Mastercard, Visa, etc...). In the rare case that ChAP.py doesn't work well, you may have to define your own specific AID in ChAP.py or write your own parser like I did for the Chase Visa PayPass cards.

By default ChAP.py will attempt to parse the data from the card and translate it so we can make sense out of each byte. Instead, I'll tell ChAP.py not do that and just display the raw data (-r).

 RFIDIOt-1.0a user$ python2.6 ChAP.py -r  
 insert a card within 10s  
  Found AID: MASTERCARD - a0 00 00 00 04 10 10  
 6f 17 84 07 a0 00 00 00 04 10 10 a5 0c 50 0a 4d 61 73 74 65 72 43 61 72 64  
 o............P.MasterCard  
  Processing Options: 77 0a 82 02 00 00 94 04 08 01 01 00  
 w...........  
   SFI 01: starting record 01, ending record 01; 00 offline data authentication records  
    record 01: 70 81 90 9f 6c 02 00 01 9f 62 06 00 00 00 00 01 c0 9f 63 06 00 00 00 00 00 3c 56 3e 42 35 34 36 35 30 33 32 30 36 38 39 39 38 30 31 32 5e 53 55 50 50 4c 49 45 44 2f 4e 4f 54 5e 31 31 30 33 35 30 32 30 30 30 30 30 30 30 30 31 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 9f 64 01 03 9f 65 02 00 e0 9f 66 02 00 1e 9f 6b 13 5X XX XX XX XX XX X2 d1 10 35 02 00 00 00 00 00 00 0f 9f 67 01 03 9f 68 0e 00 00 00 00 00 00 00 00 5e 03 42 03 1f 03  
 p...l....b........c......<V>B5XXXXXXXXXXXXXX2^SUPPLIED/NOT^1103502000000001000000000000000.d...e....f....k.Te. h.....5.........g...h.........^.B...  

An important thing to note here is the ChAP.py isn't pulling the track two data by default.

RFID vs MagStripe

Lets look at the differences between the raw data obtained from the RFID interface with the VivoPay and that from the MagStripe. Here's the VivoPay data:

 %B5XXXXXXXXXXXXXX2^SUPPLIED/NOT^1103502000000001000000637291901?;5XXXXXXXXXXXXXX2=11035020000072029191?I  

The following table breaks out the raw data from the magstripe and RFID interface to make it a little easier when comparing the two.

Track 1 Data
MagStripe	RFID	Value
%	%	Start
B	B	Format Code (B=Bank)
5XXXXXXXXXXXXXX2	5XXXXXXXXXXXXXX2	Primary Account Number (PAN)
^	^	Separator
ANTONIEWICZ	SUPPLIED	Last Name
/	/	Name Separator
BRAD	NOT	First Name
^	^	Separator
11	11	Expiration Year
03	03	Expiration Month
101	502	Service Code
000000001000000003000000	000000001000000637291901	Discretionary Data
?	?	End
Track 2 Data
;	;	Start Track 2 Data
5XXXXXXXXXXXXXX2	5XXXXXXXXXXXXXX2	Primary Account Number (PAN)
=	=	Separator
11	11	Expiration Year
03	03	Expiration Month
101	502	Service Code
000000300001	0000072029191	Discretionary Data
?	?	End
N/A	I	Trailing Data (Unknown)

Service Code - One interesting thing to note is the Service code differs. According to ISO/IEC 7813:2006(E), page 6, the service codes break down to:

• 101 - Can be used internationally with normal authorization, for any goods, with no PIN requirements
• 502 - Can be used nationally with normal authorization, for goods and services with no PIN requirements

So there are clearly some restrictions for where and how you can use the card.

You'll notice that the discretionary data on both track 1 and track 2 differ from that of the magstripe. Although the contents of the data stored within the discretionary data field are particular to the card manufacturer, we know that in here is where the CVV is stored. On the magstripe, CVV1 is used, while the RFID interface uses iCVV or Dynamic CVV.

Look what happens if we query the RFID interface a couple more times:

 %B5XXXXXXXXXXXXXX2^SUPPLIED/NOT^1103502000000001000000294292801?;5XXXXXXXXXXXXXX2=11035020000018129281?E  
 %B5XXXXXXXXXXXXXX2^SUPPLIED/NOT^1103502000000001000000939293101?;5XXXXXXXXXXXXXX2=11035020000054629311?;?  
 %B5XXXXXXXXXXXXXX2^SUPPLIED/NOT^1103502000000001000000191297701?;5XXXXXXXXXXXXXX2=11035020000099829771???  

You'll notice that the discretionary data changes on both tracks. That's the "dynamic" part of dynamic CVV.

Kristen Paget just gave a talk a Shmoocon and said that "check digits" (I believe the dynamic CVV is the only check that this applies to) can only be used once and if it is used a second time, the card is immediately frozen and the RFID chip can no longer be used.

Overall, there isn't much explanation of exactly how the iCVV or the dynamic CVV is actually generated, so if feel free to use the comments below to let me know what you know!

Here are some more useful links about the different CVVs and how they're generated:

• http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-711.pdf [PDF]
• http://answers.google.com/answers/threadview/id/402632.html
• iCVV Patent Application? - http://www.google.com/patents/US7922082

Building a Better Castle: Hardening the Squishy Center of your Network

by Rob Bathurst.

For several years, companies and consultants pushed very heavily on enhancing perimeter security through the use of firewalls and other network defense technologies intended to prevent unwanted traffic from entering the network. While this hardened outer wall is a great piece of the defense-in-depth model, it should not be considered the be-all-end-all in preventing malicious attackers from gaining access to your network.

Introduction

When architecting your network security, ask yourself three questions:

1. What does the company care about (what is my treasure)?
2. Can a compromise be contained (how strong is my castle)?
3. Who are the threats (identify the dragons and hordes)?

This post will focus on the first two of these questions. Dragons and Hordes will be covered in depth in a later posting. Keep in mind that the goal of this approach is to offer a new way of thinking about the complex problem of data-centric design and layered network defenses. Using this document as a blueprint- for actual castles, for company networks, or for repelling invading hordes- is not recommended.

Critical Assets: What is my treasure?

When attempting to protect your pile of gold from the hordes seeking to sack your keep it is important to first know what we need to put in the keep. A king would not store farm equipment, dirty clothes, and empty tankards with the Crown Jewels and nor should you. To figure out what are your Crown Jewels you need to ask yourself about your organization and what your organization does to make money. Even after characterizing the company’s business critical data, it’s important to realize that just as no two diamonds have the same value, no two documents do, either- even documents about the same subject.

A good example of identifying critical assets can be found in a post from earlier this month, “Just That Easy: Real World Pen Testing Attack Vectors [Part 2]:”

Sensitivity Matrix: Treasure Room, Strongbox, or Nightstand?

Establishing a matrix to determine the sensitivity of a business document is essential for data-centric security. The sample matrix below is simplistic, but shows the thought process you should use to determine the value of the diamond and where you should store that diamond (In a safe in the keep or on the night stand).

The document owner is responsible for using the data classification matrix to determine the sensitivity of their document, based upon the data it contains. The overall result of the document (a classification rating) places the document in a particular zone of the protected IT infrastructure (which room in the castle), and mandates certain controls (guards, patrols, locks, strongboxes).

Example: Mega Widgets, Ltd.

Mega Widgets Limited manufactures widgets in a very competitive widget market, and has determined they would like to classify their data to determine what level of protection to assign to a document.

Through a series of meetings with data stakeholders, Mega Widget Ltd. has determined that they will use three data classifications (Confidential, Restricted, and Mega Secret) based upon the content of the documents:

• Confidential: Release of Confidential data may cause harm to the company. Confidential documents should be password-protected, but may remain on the creator’s or user’s system (the castle’s throne room).
• Restricted: Release of Restricted data will cause harm to the company. Restricted documents must be password-protected; must be moved off the creator’s system to secured file storage; and the creator must delete the original copy from the creator’s system. Restricted documents can only be accessed by explicitly authorized users on the file server using a “special company document viewer widget” (the castle’s treasure room).
• Mega Secret: Release of Mega Secret data may result in a substantial loss for the company. Mega Secret documents must be password-protected; must be moved off the creator’s system to secured file storage; the creator must delete the original copy from the creator’s system; and access to this document must be explicitly approved by management through a “special company document viewer widget” (the castle’s strongbox).

Mega Widgets Ltd.’s data architects, further, produced the following classification matrix to classify documents:

	Business Critical Process	Business Financial Data	Competitive Edge Data
Business Critical Process	Confidential	Restricted	Mega Secret
Business Financial Data	Restricted	Confidential	Restricted
Competitive Edge Data	Mega Secret	Mega Secret	Confidential

Mega Widget Limited’s classification matrix shows that, for example, they have determined any document containing a combination of Business Data and Competitive Edge Data results in a document of great importance to the company, worthy of the utmost protection (placed under guard in the Keep).

Identifying which data to protect and how much effort to put forward doing so is only the first step, however- Mega Widget Limited still needs to build their castle, reinforce the treasure room, and acquire the best strongbox they can to place in the Keep.

So how does the Mega Widget Limited protect their Mega Secrets? I’m glad you asked.

Secure Data Network: The Keep

In a data-centric security model, the greatest amount of effort, time, and money is focused on critical business assets. The first step is to gather the treasure and determine where it will need to be stored (see above), prior to attempting to protect it. This ensures that money is not wasted buying extra treasure chests for dirty clothes and farm equipment.

Once all of the treasure is classified, it comes time to build the Keep. The Keep is the last line of defense before the hordes and dragons can get to the jewels. This must be the most restrictive area of a company network, generally following at a minimum the guidelines below:

• Not all business users should have access to the data in this area (I cannot overstate the importance of this principle)
• User should be given access to the least amount of data needed to complete their job
• User access should be closely monitored and logged
• Servers within this secure zone should use multi-factor authentication with verbose logging.
• Data transfer in and out of the Keep should be monitored at all times (Why is Bob moving a document at 2am?)
• Data transfer should be encrypted end-to-end.
• Network should be segmented via technological controls (ACL, Packet-Filtering firewalls, etc), not just policies and procedures.

Much like the castle (our perimeter firewall) is only a foundation; the Keep is only an intermediate step. Further defensive structures exist in and around the keep to contain perimeter breaches and further secure the treasure.

User LAN: The Killing Grounds

As bad as the name sounds, this area is the best for containing attackers who have made it past your front door, but have not yet advanced to the Keep. This part of the Castle is designed for damage control- and the same principle applies when designing a network.

The Killing Zone of a castle is design to be ceded to the besieging attackers, but only in such a way that the critical assets- the King and the crown jewels- remain defended, still secure within the Keep.

Maximizing security means working under the assumption that everything in the Killing Ground- the User LAN- will be compromised or has already been compromised. Accepting this as a working premise heightens awareness of suspicious activity and lessens the time between breach and response. When a user’s machine has been compromised via 0-day, social engineering, or simple bad luck, the security team must be able to detect this activity and dispatch guards to eject the usurpers.

• Wanted Posters – These let your citizens know to watch out for the bad guys. This is your user awareness and security training programs. Social Engineering is a very popular attack vector and is almost always lethal with unaware users. A user spotting abnormal activity and notifying the proper personnel can save your business time, money, and headache.
• Tower Guards – They watch over your whole castle and allow you to correlate your attack events. These represent edge sensors, event correlation databases, etc. They span the enterprise and are critical for monitoring the health of your Castle.
• Castle Scouts – They let you know someone is inside your walls. These will be your IDS sensor monitoring for non-standard traffic such as, “Why is your user machine suddenly attempting to connect to multiple shares the user does not need.” Scouts rely on understanding their environment and must be trained to recognize “abnormal” traffic.
• Castle Guards – They let you isolate your attacker preventing them from doing more damage. These will be your firewall isolating your network segments in critical places such as the DMZ, Server LAN, User LAN, accounting systems, etc. When your scouts notice a compromise your guards spring into action blocking network traffic from the compromised machine.
• Executioners - They let you identify the threat signature and remove it from your Castle. These represent your enterprise security department and their tools, such as Enterprise AV, incident response tools, and training.

Perimeter Defense: The Walls

Walls are easy to conceive but hard to implement. The Wall is ironically the weakest part of the Castle, because it necessarily contains a gate. Perimeter protection devices are used to repel attackers- or at least force them into the open- acting as your first line of defense for attackers attempting to remove the castle’s treasure.

• Archers and Border Guards – They stop the attackers before the reach the door. These are firewalls and intrusion prevention systems. By blocking known bad IP address, bad port numbers, and bogus addresses inbound from the internet you lessen the work on your guards inside. Archers and Guards require constant training to keep their skills honed just as your firewalls require constant attention and tuning to ensure you gain the most benefit from them.
• Advanced Scouts – They are your eyes warning you of an inbound attack. This is your in-line or tapped IDS carefully inspecting packets coming into your Castle both before and after passing through the firewalls.
• Chief Inspector Guy – While there is no direct analogy for this person in a castle, they are of utmost importance. This is your outbound proxy protecting your users and making sure no one is running off with the treasure. But what about encrypted streams you cannot inspect you say? Block them, institute a site white-listing policy and only allow encrypted connections to sites with a business need that have been approved by management.

Outside Resources: Allied Armies

What‘s a King without friends? In the case of a denial-of-service attack the traffic can be offloaded to another company to help filter the requests and provide bandwidth before the requests are passed to the web servers. In the case of a compromise, a company specializing in Incident Response ready to help clean up and prevent further damage. And an important point to remember, not all attackers are people; a service provider that provides secure offsite backup facilities to protect against natural or accidental destruction of data is a critical alliance.

Conclusion

So now we’ve built our Castle, but are we done? No, not at all. Bricks require mortar, people require training, and someone always is building a better mouse trap. Ensure you are constantly evaluating what is critical data and what isn’t and devote your efforts to protecting what your company values most.

JSON CSRF with Parameter Padding

by Gursev Kalra.

The JavaScript Object Notation (JSON) format is one of the prominent data exchange formats of the contemporary web applications. When a web application implements JSON, Cross Site Request Forgery (CSRF) payload delivery gets bit tricky because of query string and JSON format mismatch. With couple of tricks however, we can successfully execute CSRF attacks with JSON payloads.

Let’s assume that the browser sends the following JSON to the web server.

{"a":1,"b":{"c":3}}

Scenario 1

One of the mechanisms to execute JSON CSRF is to use the entire JSON payload as parameter name in a self submitting form. For example, loading the HTML code below and clicking the submit button sends malicious JSON to the web server:

1:  <html>  
2:  <form action=http://192.168.1.41:3000 method=post enctype="text/plain" >  
3:  <input name='{"a":1,"b":{"c":3}}' type='hidden'>  
4:  <input type=submit>  
5:  </form>  
6:  </html>  

At line# 2, the enctype form attribute is set to text/plain so that the JSON gets delivered as is. The enctype attribute may not be required, but is good to have. At line# 3, entire JSON payload is provided as a parameter name. When the form gets posted, the payload is delivered and CSRF executes.

Image below shows JSON payload delivery with the technique described above.

This technique may fail in some cases when the server side JSON parsers reject the incoming JSON because of the trailing ‘=’ character.

Scenario 2 (JSON Parameter Padding to the rescue)

In scenario 1, the trailing ‘=’ character may ruin the party when server side JSON parsers enforce strict parsing rules. To overcome this, an additional parameter can be padded towards the end of JSON payload to send a well formed JSON. As with regular GET & POST parameters, JSON parsers will successfully parse the JSON, pick the required parameters and ignore the extraneous ones. This allows a successful CSRF attack against vulnerable web applications.

Below, the HTML code in scenario 1 is modified to add an extraneous parameter to the JSON payload:

1:  <html>  
2:  <form action=http://192.168.1.41:3000 method=post enctype="text/plain" >  
3:  <input name='{"a":1,"b":{"c":3}, "ignore_me":"' value='test"}'type='hidden'>  
4:  <input type=submit>  
5:  </form>  
6:  </html>  

At line# 3, the component in red is the original JSON and the blue component helps add the extraneous parameter to the JSON payload. The screenshot below shows the JSON payload delivered when the above HTML is executed. The ignore_me parameter absorbs the trailing ‘=’ character and has a value “=test”.

The end result, successful JSON Parsing and CSRF goodness :)

Image shows a well formed JSON sent using parameter padding

It is important to note that the discussed attack vectors may not work if the server validates the “Content-Type” request header to represent a JSON payload.