Amritam Putatunda
Technical Product Manager
Blog

How to Convert the Hottest Security News into BreakingPoint Test Scenarios

July 7, 2016 by Amritam Putatunda

Recently, while I was getting ready for my weekend, I got a call from one of my friends who is also an Ixia customer. He had an urgent requirement for understanding his product’s resiliency to a very recent publicized attack where hackers gained access to users’ systems. He was wondering when he could expect to see the attacks as part of the BreakingPoint security component. My answer to him was a simple, “Right now, using BreakingPoint’s application test.” His baffled reply was “How is that possible, it should be part of security.”  Well, for now, I differed my weekend plans to instead help my friend with this very interesting and “not-so-often” touched topic. This conversation made me realize that this is also an excellent blog topic. To make it more interesting, I’ll select a few random recent security news feeds and show you how to emulate them through the BreakingPoint application.  

BreakingPoint Components—There’s More to It Than Meets the Eye.

Normally when we talk about BreakingPoint components, we cover how BitBlaster does more than simply sending Layer 2 traffic, Session Sender does more than measuring UDP/TCP performance, and Stackscrambler does more than just sending malformed traffic. But this time, we’ll cover how AppSim with its Superflows can be an excellent tool to test a vast set of security scenarios. The topic of “Using BreakingPoint Applications to Attack”  has been previously covered in other blogs like this excellent piece from Phil showing techniques to do file fuzzing through a BreakingPoint flow or this from yours truly talking about web DDoS tests. However, it’s a fair assumption that using such features of AppSim isn’t straight forward. But if you can stay until the end of this blog, you will see it’s not that difficult either.  

News Headline 1: Possible TeamViewer Breach

Scenario1

In a recent news, it came to the forefront that some TeamViewer accounts were breached, possibly due to brute force. One request I saw was to emulate TeamViewer requests in bulk to a single TeamViewer account from different source IDs coming from different TeamViewer clients. The customer needed to check if such mass connections to a single open TV-ID leads to a higher success rate of a breach and most importantly, if his security device is able to see such malicious patterns and take appropriate action. [If you aren’t familiar with BreakingPoint basic tests, get a quick review/recap here]

To emulate the same request, I created a network with several different IP addresses in BreakingPoint’s Network Neighbourhood as shown below. The different static IP addresses ensure that the TeamViewer server will be accessed by different IP/TCP ports.

Scenario2

BreakingPoint Network Neighbourhood configuring client and server IP addresses

For the requirement of having different TeamViewer request IDs, I edited the existing TeamViewer Superflows in BreakingPoint and went into the “CMD Request Connect” action. This has the editable destination ID and Connection ID. I can set it up to a value that would denote it’s fixed and saved the flow with a different name. Using a ClientSim profile, I can then run the existing flow.  

Scenario3

Setting up the request to connect to a fixed destination ID

Once the test run is done, we can extract the packet capture and view the connect command (TeamViewer is not available as a protocol in Wireshark and I have used a customized lua downloaded from Optiv). As you can see in the capture, several requests from different IPs go to a single server, with each having a random source ID but a fixed destination ID.

Scenario4

Packet capture of BreakingPoint traffic showing TeamViewer access to a fixed destination ID

News Headline 2: Adobe Flash Zero-Day

Scenario5

Adobe recently provided a patch to the vulnerability that was discovered by Kaspersky . This vulnerability is in .242 and earlier versions of Adobe Flash, and Adobe had published a security advisory about the same and took a few days before publishing a patch on June 14. IT/security administrators don’t like a vulnerability out in a wild with no patch. So for those that decide to write an IPS rule to block any Flash players having versions 21 or lower, there are two things to know: 1) you have my respect and 2) I will try to show some ways to test such rules non-intrusively.

The flash versions of browsers can be found from the HTTP headers; the older versions were sent through the x-flash-version: 10.0.0.18 header and the newer once are through x-Requested-With: ShockwaveFlash/21.0.0.242. Now, if we write a rule that’s too vague then it starts blocking legitimate requests or may start allowing certain affected flash versions.

To test if an IPS detects and blocks any Flash access of older versions, we can create a Get request with Flash versions we can use a BreakingPoint flow. I would edit one of the existing BreakingPoint Flash flows. In the flow, we can use the token feature at the Get commands Header fields to create Get requests with different version values. If we analyze most of the Flash versions, the format seems to be something like XX.X.X.XXX and to represent it in BreakingPoint we can use three types of tokens:

1) “##num_range(seed_sequential_superflow,1,21)##” — will generate the major version of anything from 1 to 21”

2) ##num(1,2)## — will generate random one or two digit numbers

3) ##num(1,3)##  - will generate random one to three digit numbers

Together the token becomes: ##num_range(seed_sequential_superflow,1,21)##.##num(1,2)##.##num(1,2)##.##num(1,3)## that will generate a version that may look like 20.5.1.143

So we need to put two GET requests, one for x-flash-version and other for x-Requested-With, so we have the major types of headers covered in two separate GET commands as shown below.

Scenario6

A BreakingPoint Flow with the Header having customer header names and values using tokens

Once the values are set, save the Superflow with a name and run it through the ClientSim component. Capture the packets and observe the HTTP headers of the Get request. If the Superflow has been configured properly, you would get the following patterns in the packet capture.

Scenario7

Packet capture of test run showcases the Flash and Shockwave versions that need to be blocked

A properly written IPS rule should send a reset to all of these sessions, but at the same time allow any other GET command from any other request coming from any higher Flash version.

News Headline 3: User ID/Password Account Breaches

Scenario8

In recent news, hackers stole 45 million accounts and passwords from different forums. Now, such breaches have become quite common, with Hackers gaining access to certain databases and stealing secured information. Application developers, equipment manufacturers, or IT teams sometimes need to generate such massive lists of user IDs and passwords to create different attack scenarios to a) measure resiliency of the apps to protect from such attacks

b) understand if security devices can detect such access to steel credentials

c) strengthen data loss prevention devices

We can use almost any application in BreakingPoint that has login options to create a login blast with a huge set of usernames and passwords. For this case, to have a larger appeal, I used one of the most common cases, the HTTP Post form. But this doesn’t stop you from performing similar methods on any other app in BreakingPoint. For our purpose, I selected the pre-canned flow “HTTP POST Web Login” from the BreakingPoint Superflow. To create such an attack, we need to introduce two concepts in BreakingPoint,

  1. Split Dictionary: Provides inputs to BreakingPoint to pick up values from a table for each iteration. The following example shows a split dictionary action that takes the input of any file with comma separated values, like email and password in this case.

Scenario9

Technique of providing split dictionary input to a BreakingPoint Flow

  1. Token Substitution: Dictionary elements are called in a flow by a token concept. In this case, we are using the ##dict_flow(seed_sequential_flow,0)## to extract the emails from the dictionary and ##dict_flow(seed_sequential_flow,1)## to extract the passwords where “0” and “1” are the two columns of the dictionary.

Scenario10

 Technique of providing split dictionary input to a BreakingPoint Flows action

Once the flow is configured, you can save it as a different flow and run it through the BreakingPoint ClientSim component. Capturing the packet and extracting the HTML content will show the login attempts from the various emails and passwords that were provided as input from the split dictionary.

Scenario11

Capture showing login requests with username and password taken from an input file

A similar technique can be used for providing inputs from a file to other applications and be used to test data loss prevention, lawful intercept, spam filters, and other such devices. The dictionary is capable of holding and providing as an input to hundreds of thousands of such values (limited by size) and can be employed to do high-scale testing.

Conclusion

The world of Internet security is young, exciting, and dynamic. New breaches or recently discovered vulnerabilities become headlines all the times. Ixia’s Application and Threat Intelligence (ATI) team keeps our customers current by covering most of such high-severity incidents. However, it’s a daunting task to keep up with all the developments in security within a short period of time like the daily news does.

But now that you now know how to use BreakingPoint’s application component to recreate some portion of the attack scenarios or application behaviour to validate your network or security devices—before the ink on today’s news is even dry.

Leverage Subscription Service to Stay Ahead of Attacks

The Ixia BreakingPoint Application and Threat Intelligence (ATI) Subscription provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.