Category Archives: Security Onion

toolsmith #114: WireEdit and Deep Packet Modification

Posted on by


PCAPs or it didn’t happen, right? 


Introduction
Packet heads, this toolsmith is for you. Social media to the rescue. Packet Watcher (jinq102030) Tweeted using the #toolsmith hashtag to say that WireEdit would make a great toolsmith topic. Right you are, sir! Thank you. Many consider Wireshark the eponymous tool for packet analysis; it was only my second toolsmith topic almost ten years ago in November 2006. I wouldn’t dream of conducting network forensic analysis without NetworkMiner (August 2008) or CapLoader (October 2015). Then there’s Xplico, Security Onion, NST, Hex, the list goes on and on…
Time to add a new one. Ever want to more easily edit those packets? Me too. Enter WireEdit, a comparatively new player in the space. Michael Sukhar (@wirefloss) wrote and maintains WireEdit, the first universal WYSIWYG (what you see is what you get) packet editor. Michael identifies WireEdit as a huge productivity booster for anybody working with network packets, in a manner similar to other industry groundbreaking WYSIWIG tools.

In Michael’s own words: “Network packets are complex data structures built and manipulated by applying complex but, in most cases, well known rules. Manipulating packets with C/C++, or even Python, requires programming skills not everyone possesses and often lots of time, even if one has to change a single bit value. The other existing packet editors support editing of low stack layers like IPv4, TCP/UDP, etc, because the offsets of specific fields from the beginning of the packet are either fixed or easily calculated. The application stack layers supported by those pre-WireEdit tools are usually the text based ones, like SIP, HTTP, etc. This is because no magic is required to edit text. WireEdit’s main innovation is that it allows editing binary encoded application layers in a WYSIWYG mode.“

I’ve typically needed to edit packets to anonymize or reduce captures, but why else would one want to edit packets?
1) Sanitization: Often, PCAPs contain sensitive data. To date, there has been no easy mechanism to “sanitize” a PCAP, which, in turn, makes traces hard to share.
2) Security testing: Engineers often want to vary or manipulate packets to see how the network stack reacts to it. To date, that task is often accomplished via programmatic means.
WireEdit allows you to do so in just a few clicks.

Michael describes a demo video he published in April 2015, where he edits the application layer of the SS7 stack (GSM MAP packets). GSM MAP is the protocol responsible for much of the application logic in “classic” mobile networks, and is still widely deployed. The packet he edits carries an SMS text message, and the layer he edits is way up the stack and binary encoded. Michael describes the message displayed as a text, but notes that if looking at the binary of the packet, you wouldn’t find it there due to complex encoding. If you choose to decode in order to edit the text, your only option is to look up the offset of the appropriate bytes in Wireshark or a similar tool, and try to edit the bytes directly.
This often completely breaks the packet and Michael proudly points out that he’s not aware of any tool allowing to such editing in WYSIWYG mode. Nor am I, and I enjoyed putting WireEdit through a quick validation of my own.

Test Plan

I conceived a test plan to modify a PCAP of normal web browsing traffic with web application attacks written in to the capture with WireEdit. Before editing the capture, I’d run it through a test harness to validate that no rules were triggered resulting in any alerts, thus indicating that the capture was clean. The test harness was a Snort 2.9.8.0 instance I’d implemented on a new Ubuntu 14.04 LTS, configured with Snort VRT and Emerging Threats emerging-web_server and emerging-web_specific_apps rules enabled. To keep our analysis all in the family I took a capture while properly browsing the OpenBSD entry for tcpdump.
A known good request for such a query would, in text, as a URL, look like:
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/tcpdump.8?query=tcpdump&sec=8
Conversely, if I were to pass a cross-site scripting attack (I did not, you do not) via this same URL and one of the available parameters, in text, it might look something like:
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/tcpdump.8?query=tcpdump&sec=8%22onmouseover%3Dalert(1337)%2F%2F
Again though, my test plan was one where I wasn’t conducting any actual attacks against any website, and instead used WireEdit to “maliciously” modify the packet capture from a normal browsing session. I would then parsed it with Snort to validate that the related web application security rules fired correctly.
This in turn would validate WireEdit’s capabilities as a WYSIWYG PCAP editor as you’ll see in the walk-though. Such a testing scenario is a very real method for testing the efficacy of your IDS for web application attack detection, assuming it utilized a Snort-based rule set.

Testing

On my Ubuntu Snort server VM I ran sudo tcpdump -i eth0 -w toolsmith.pcap while browsing http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/tcpdump.8?query=tcpdump&sec=8.
Next, I ran sudo snort -c /etc/snort/snort.conf -r toolsmith.pcap against the clean, unmodified PCAP to validate that no alerts were received, results noted in Figure 1.

Figure 1: No alerts triggered via initial OpenBSD browsing PCAP

I then dragged the capture (407 packets) over to my Windows host running WireEdit.
Now wait for it, because this is a lot to grasp in short period of time regarding using WireEdit.
In the WireEdit UI, click the Open icon, then select the PCAP you wish to edit, and…that’s it, you’re ready to edit. 🙂 WireEdit tagged packet #9 with the pre-requisite GET request marker I was interest in so expanded that packet, and drilled down to the HTTP: GET descriptor and the Request-URI under Request-Line. More massive complexity, here take notes because it’s gonna be rough. I right-clicked the Request-URI, selected Edit PDU, and edited the PDU with a cross-site scripting (JavaScript) payload (URL encoded) as part of the GET request. I told you, really difficult right? Figure 2 shows just how easy it really is.

Figure 2: Using WireEdit to modify Request-URI with XSS payload

I then saved the edited PCAP as toolsmithXSS.pcap and dragged it back over to my Snort server and re-ran it through Snort. The once clean, pristine PCAP elicited an entirely different response from Snort this time. Figure 3 tells no lies.

Figure 3: XSS ET Snort alert fires

Perfect, in what was literally a :30 second edit with WireEdit, I validated that my ten minute Snort setup catches cross-site scripting attempts with at least one rule. And no websites were actually harmed in the making of this test scenario, just a quick tweak with WireEdit.
That was fun, let’s do it again, this time with a SQL injection payload. Continuing with toolsmithXSS.pcap I jumped to the GET request in frame 203 as it included a request for a different query and again edited the Request-URI with an attack specific for MySQL as seen in Figure 4.

I saved this PCAP modification as toolsmithXSS_SQLi.pcap and returned to the Snort server for yet another happy trip Snort Rule Lane. As Figure 5 represents, we had an even better result this time.  

Figure 5: WireEdited PCAP trigger multiple SQL injection alerts

In addition to the initial XSS alert firing again, this time we collected four alerts for:

  • ET WEB_SERVER MYSQL SELECT CONCAT SQL Injection Attempt
  • ET WEB_SERVER SELECT USER SQL Injection Attempt in URI
  • ET WEB_SERVER Possible SQL Injection Attempt UNION SELECT
  • ET WEB_SERVER Possible SQL Injection Attempt SELECT FROM

That’s a big fat “hell, yes” for WireEdit.
Still with me that I never actually executed these attacks? I just edited the PCAP with WireEdit and fed it back to the Snort beast. Imagine a PCAP like being optimized for the OWASP Top 10 and being added to your security test library, and you didn’t need to conduct any actual web application attacks. Thanks WireEdit!

Conclusion

WireEdit is beautifully documented, with a great Quickstart. Peruse the WireEdit website and FAQ, and watch the available videos. The next time you need to edit packets, you’ll be well armed and ready to do so with WireEdit, and you won’t be pulling your hair out trying to accomplish it quickly, effectively, and correctly. WireEdit my a huge leap from not known to me to the top five on my favorite tools list. WireEdit is everything it is claimed to be. Outstanding.
Ping me via email or Twitter if you have questions: russ at holisticinfosec dot org or @holisticinfosec.

ACK

Thanks to Michael Sukhar for WireEdit and Packet Watcher for the great suggestion. Continue reading toolsmith #114: WireEdit and Deep Packet Modification→

toolsmith #114: WireEdit and Deep Packet Modification

Posted on by


PCAPs or it didn’t happen, right? 


Introduction
Packet heads, this toolsmith is for you. Social media to the rescue. Packet Watcher (jinq102030) Tweeted using the #toolsmith hashtag to say that WireEdit would make a great toolsmith topic. Right you are, sir! Thank you. Many consider Wireshark the eponymous tool for packet analysis; it was only my second toolsmith topic almost ten years ago in November 2006. I wouldn’t dream of conducting network forensic analysis without NetworkMiner (August 2008) or CapLoader (October 2015). Then there’s Xplico, Security Onion, NST, Hex, the list goes on and on…
Time to add a new one. Ever want to more easily edit those packets? Me too. Enter WireEdit, a comparatively new player in the space. Michael Sukhar (@wirefloss) wrote and maintains WireEdit, the first universal WYSIWYG (what you see is what you get) packet editor. Michael identifies WireEdit as a huge productivity booster for anybody working with network packets, in a manner similar to other industry groundbreaking WYSIWIG tools.

In Michael’s own words: “Network packets are complex data structures built and manipulated by applying complex but, in most cases, well known rules. Manipulating packets with C/C++, or even Python, requires programming skills not everyone possesses and often lots of time, even if one has to change a single bit value. The other existing packet editors support editing of low stack layers like IPv4, TCP/UDP, etc, because the offsets of specific fields from the beginning of the packet are either fixed or easily calculated. The application stack layers supported by those pre-WireEdit tools are usually the text based ones, like SIP, HTTP, etc. This is because no magic is required to edit text. WireEdit’s main innovation is that it allows editing binary encoded application layers in a WYSIWYG mode.“

I’ve typically needed to edit packets to anonymize or reduce captures, but why else would one want to edit packets?
1) Sanitization: Often, PCAPs contain sensitive data. To date, there has been no easy mechanism to “sanitize” a PCAP, which, in turn, makes traces hard to share.
2) Security testing: Engineers often want to vary or manipulate packets to see how the network stack reacts to it. To date, that task is often accomplished via programmatic means.
WireEdit allows you to do so in just a few clicks.

Michael describes a demo video he published in April 2015, where he edits the application layer of the SS7 stack (GSM MAP packets). GSM MAP is the protocol responsible for much of the application logic in “classic” mobile networks, and is still widely deployed. The packet he edits carries an SMS text message, and the layer he edits is way up the stack and binary encoded. Michael describes the message displayed as a text, but notes that if looking at the binary of the packet, you wouldn’t find it there due to complex encoding. If you choose to decode in order to edit the text, your only option is to look up the offset of the appropriate bytes in Wireshark or a similar tool, and try to edit the bytes directly.
This often completely breaks the packet and Michael proudly points out that he’s not aware of any tool allowing to such editing in WYSIWYG mode. Nor am I, and I enjoyed putting WireEdit through a quick validation of my own.

Test Plan

I conceived a test plan to modify a PCAP of normal web browsing traffic with web application attacks written in to the capture with WireEdit. Before editing the capture, I’d run it through a test harness to validate that no rules were triggered resulting in any alerts, thus indicating that the capture was clean. The test harness was a Snort 2.9.8.0 instance I’d implemented on a new Ubuntu 14.04 LTS, configured with Snort VRT and Emerging Threats emerging-web_server and emerging-web_specific_apps rules enabled. To keep our analysis all in the family I took a capture while properly browsing the OpenBSD entry for tcpdump.
A known good request for such a query would, in text, as a URL, look like:
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/tcpdump.8?query=tcpdump&sec=8
Conversely, if I were to pass a cross-site scripting attack (I did not, you do not) via this same URL and one of the available parameters, in text, it might look something like:
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/tcpdump.8?query=tcpdump&sec=8%22onmouseover%3Dalert(1337)%2F%2F
Again though, my test plan was one where I wasn’t conducting any actual attacks against any website, and instead used WireEdit to “maliciously” modify the packet capture from a normal browsing session. I would then parsed it with Snort to validate that the related web application security rules fired correctly.
This in turn would validate WireEdit’s capabilities as a WYSIWYG PCAP editor as you’ll see in the walk-though. Such a testing scenario is a very real method for testing the efficacy of your IDS for web application attack detection, assuming it utilized a Snort-based rule set.

Testing

On my Ubuntu Snort server VM I ran sudo tcpdump -i eth0 -w toolsmith.pcap while browsing http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/tcpdump.8?query=tcpdump&sec=8.
Next, I ran sudo snort -c /etc/snort/snort.conf -r toolsmith.pcap against the clean, unmodified PCAP to validate that no alerts were received, results noted in Figure 1.

Figure 1: No alerts triggered via initial OpenBSD browsing PCAP

I then dragged the capture (407 packets) over to my Windows host running WireEdit.
Now wait for it, because this is a lot to grasp in short period of time regarding using WireEdit.
In the WireEdit UI, click the Open icon, then select the PCAP you wish to edit, and…that’s it, you’re ready to edit. 🙂 WireEdit tagged packet #9 with the pre-requisite GET request marker I was interest in so expanded that packet, and drilled down to the HTTP: GET descriptor and the Request-URI under Request-Line. More massive complexity, here take notes because it’s gonna be rough. I right-clicked the Request-URI, selected Edit PDU, and edited the PDU with a cross-site scripting (JavaScript) payload (URL encoded) as part of the GET request. I told you, really difficult right? Figure 2 shows just how easy it really is.

Figure 2: Using WireEdit to modify Request-URI with XSS payload

I then saved the edited PCAP as toolsmithXSS.pcap and dragged it back over to my Snort server and re-ran it through Snort. The once clean, pristine PCAP elicited an entirely different response from Snort this time. Figure 3 tells no lies.

Figure 3: XSS ET Snort alert fires

Perfect, in what was literally a :30 second edit with WireEdit, I validated that my ten minute Snort setup catches cross-site scripting attempts with at least one rule. And no websites were actually harmed in the making of this test scenario, just a quick tweak with WireEdit.
That was fun, let’s do it again, this time with a SQL injection payload. Continuing with toolsmithXSS.pcap I jumped to the GET request in frame 203 as it included a request for a different query and again edited the Request-URI with an attack specific for MySQL as seen in Figure 4.

I saved this PCAP modification as toolsmithXSS_SQLi.pcap and returned to the Snort server for yet another happy trip Snort Rule Lane. As Figure 5 represents, we had an even better result this time.  

Figure 5: WireEdited PCAP trigger multiple SQL injection alerts

In addition to the initial XSS alert firing again, this time we collected four alerts for:

  • ET WEB_SERVER MYSQL SELECT CONCAT SQL Injection Attempt
  • ET WEB_SERVER SELECT USER SQL Injection Attempt in URI
  • ET WEB_SERVER Possible SQL Injection Attempt UNION SELECT
  • ET WEB_SERVER Possible SQL Injection Attempt SELECT FROM

That’s a big fat “hell, yes” for WireEdit.
Still with me that I never actually executed these attacks? I just edited the PCAP with WireEdit and fed it back to the Snort beast. Imagine a PCAP like being optimized for the OWASP Top 10 and being added to your security test library, and you didn’t need to conduct any actual web application attacks. Thanks WireEdit!

Conclusion

WireEdit is beautifully documented, with a great Quickstart. Peruse the WireEdit website and FAQ, and watch the available videos. The next time you need to edit packets, you’ll be well armed and ready to do so with WireEdit, and you won’t be pulling your hair out trying to accomplish it quickly, effectively, and correctly. WireEdit my a huge leap from not known to me to the top five on my favorite tools list. WireEdit is everything it is claimed to be. Outstanding.
Ping me via email or Twitter if you have questions: russ at holisticinfosec dot org or @holisticinfosec.

ACK

Thanks to Michael Sukhar for WireEdit and Packet Watcher for the great suggestion. Continue reading toolsmith #114: WireEdit and Deep Packet Modification→

toolsmith: Artillery

Posted on by

Prerequisites
Linux or Windows system with a Python interpreter
Introduction
I was reminded of Dave Kennedy’s Artillery while attending and presenting at DerbyCon 4.0 in September given that Dave is a DerbyCon founder. Artillery has recently benefitted from a major update and formal development support as part of Dave’s Binary Defense Systems (BDS) company. The BDS blogannounced version 1.3 on November 11, which further prompted our discussion here. Artillery first surfaced for me as part of the ADHD project I covered during my C3CM discussion in October 2013’s toolsmith. While Dave’s investments in the security community have grown, Artillery was initially maintained by Dave’s TrustedSec organization then transitioned to BDS, given that group’s “defend, protect, secure” approach to managed security solutions. Artillery is an open source project created to provide early warning indicators for various attacks. Artillery was included in ADHD, the Active Defense Harbinger Distribution, because it spawns multiple ports on a system, a honeypot-like activity that creates “exposures” for attackers to go after. Dave described the fact that it also made blue teaming a bit easier for folks. Additional Artillery features include active file system change monitoring, detection of brute force attacks, and generation of other indicators of compromise. Artillery protects both Linux and Windows systems against attacks and can integrate with threat intelligence feeds allowing correlation and notification when an attacker IP address has previously been identified. Artillery supports multiple configurations, different versions of Linux, and can be deployed across multiple systems with centralized event collection. With a ton of support, and additions coming in from all over the world to make Artillery better, Dave mentioned that plans for Artillery include much better support for Windows, and expansion to allow a server/client model, moving away from purely standalone implementations. BSD’s plan is to continue significant development for Artillery while ensuring it maintains its open source origins allowing continued contribution back to the community Dave so readily embraces.
Laying In Artillery
Artillery installation is well documented on the Binary Defense Systems site and is remarkably straightforward. Note that I only installed and tested Artillery on a Linux system.
On the Linux system you wish to install Artillery, simply execute git clone https://github.com/trustedsec/artillery, change directory to the artillerydirectory just created, run sudo ./setup.py, then edit to the configfile to suit your preferences. I’ll walk you through my configuration as a reference.
1)      I created a directory called holisticinfosec, and added “/holisticinfosec/” to MONITOR_FOLDERS
2)      I enabled HONEYPOT_BAN=ON, you’ll want to consider your implementation before you do this or you may inadvertently block legitimate traffic. You could also use WHITELIST_IP to prevent this issue and allow specific hosts but, as good as they are, whitelists can quickly become arduous to maintain. Bans and IPS-like blocks suffer from ye olde false positive issues when left unchecked.
3)      I used Yahoo for my SMTP settings (USERNAME, PASSWORD, ADDRESS) and set ALERT_USER_EMAILto my holistincinfosec.org address for alert receipt. Caution here as well as you can quickly SPAM yourself or your Security Operations Center (SOC) monitored mail, and even cause an inbox DoS if your Artillery server(s) is busy. You can control frequency with EMAIL_TIMER and EMAIL_FREQUENCY, I suggest default settings initially (email alerts off) until you fine tune and optimize your Artillery implementation.
4)      Brute force attempts monitoring is cool and worthwhile, I enabled both SSH and FTP via SSH_BRUTE_MONITOR and FTP_BRUTE_MONITOR. Experiment with “attempts before you ban” as, again, you may not ban initially.
5)      The THREAT_INTELLIGENCE_FEED and THREAT_FEED allow you to consume the BDS Artillery Threat Intelligence Feed (ATIF). It’s represented as banlist.txt. You can pull from the BDS site or establish your own ATIF server for all you Artillery nodes to pull from. As with any blacklist, again, ensure that you want to block them all as there are more than 86,000 entries in this list. You can also add other lists if you wish as well.
6)      One of the most important settings are for your syslog preferences, you can log locally or write to a remote collector. This speaks to my defender’s sensibilities and we’ll discuss this further later as such.
The South Base Camp blog (@johnjakem) also has a nice writeup on Artillery nuances; it’s a quick read and worth your time.
Indirect Artillery Fire
I conducted basic tests of Artillery functionality with email alerts and banning enabled.
For the folder monitoring feature I wrote a file called test to the /holisticinfosec directory including the sentence “Monkey with me” and restarted Artillery. When I monkeyed with test by adding snarky commentary, I was alerted via email and a log entry in the local syslog file. Figure 1 is the email alert indicating the change to the test file.
Figure 1 – Artillery alert for change to test file
To blast the honeypot functionality, a nice Nmap scan sufficed with nmap -p 1-65535 -T4 -A -v -PE -PS22,25,80 -PA21,23,80,3389 192.168.220.130.
The result was an alert flood stating that [!] Artillery has detected an attack from the IP Address: 192.168.220.131 with example content as seen in Figure 2.
Figure 2 – Blocked and banned! Artillery stops attack traffic cold
I used Bruter to try and pound the FTP and SSH services but because the Artillery configuration was set to only four attempts before banning, my dictionary attacks were almost immediately kicked to the curb. Darn you, Artillery! For this experiment I enabled SYSLOG_TYPE=FILE in my Artillery configuration, which writes event to /var/artillery/logs/alerts.log instead of syslog.
Remember, if you find yourself unable to connect to your Artillery server on a specific port or aren’t writing test events, check your configuration file as you may have banned yourself. I did so more than once. Instantly solve this problem as follows: sudo ./remove_ban.py 192.168.220.1 where the IP address is that which you want to free from the bonds of iptables purgatory.
Direct Artillery Fire
Artillery represents a golden opportunity to harken back to my C3CM guidance, particularly Part 2, wherein I discussed use of the ELK stack, or Elasticsearch, Logstash, and Kibana. You can quickly set up the ELK stack up using numerous guides found via search engine and customize it for Artillery analysis.
Rather than repeat what I’ve already documented, I took a slightly different tack and utilized my trusty and beloved Security Onion VM. Doug Burks’ (@dougburks) Security Onion includes ELSA (enterprise log search and analysis) which is a “centralized syslogframework built on Syslog-NG, MySQL, and Sphinx full-text search.” I could and should do a toolsmith on ELSA alone, but it’s so well documented by project developers and Doug, you’d do well just to read their content. To make use of ELSA I needed only point Artillery syslog to my Security Onion server by changing the /var/artillery/config file as follows:
1)      Changed SYSLOG_TYPE=LOCAL to SYSLOG_TYPE=REMOTE
2)      Set the IP address for my Security Onion server with SYSLOG_REMOTE_HOST=”192.168.220.131″
3)      Restarted Artillery from /var/artillerywith sudo ./restart_server.py
“That’s it?” you ask. Indeed. I logged into ELSA on my SO server after hammering the Artillery node with varied malfeasance, queried with host=192.168.220.130, you can see the results in Figure 3.
Figure 3 –Artillery events written to a remote Security Onion ELSA instance
ELSA provides you with a number of query options and filters so even if you have multiple Artillery servers you can zoom in on specific instances, dates, or attack types. A query such as host=192.168.220.130 groupby:program led me to program=”unknown” which, in turn, alerted me that I ended up being banned from Yahoo for spamming my account with alerts as seen in Figure 4.
Figure 4 – Artillery alerts me that I am a spammer
It’s always good to check your logs from a variety of perspectives. 🙂
I intend to write some additional scripts for Artillery analysis and parsing, and devise additional means for incorporating threat intelligence to and from my Artillery instance. Let me know via the blog comment or Twitter how you’ve done the same.
In Conclusion
Artillery, on many levels, is the epitome of simplicity, which is part of why I love it. If you possess even the slightest modicum of Python understanding, the Artillery source files should make complete sense to you. Properly tuned, I can’t really think of a reason not to run Artillery on Linux servers for sure, and maybe Windows boxes where you have Python installed. Just remember to practice safe banning, you don’t want to drop production traffic. I’m really glad Dave’s Binary Defense Systems interest has taken over care and feeding for Artillery and can’t wait to see what’s next for this fine little defender’s delight.
It’s that time of year again! Be ready to vote for your favorite tool of 2014, I’ll soon post the survey to my website or blog and Tweet it out by mid-December. We’ll conclude voting by January 15, 2015 and announce a winner soon thereafter. Please vote and tell your friends and coworkers to do the same.
Ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec).
Cheers…until next month.
Acknowledgements

Dave Kennedy (@HackingDave), TrustedSec, Binary Defense Systems, and DerbyCon

Continue reading toolsmith: Artillery→