In September I covered using Bro with Logstash and Kibana as part of my C3CM (identify, interrupt, and counter the
command, control, and communications capabilities of our digital assailants) series in toolsmith. Two very cool developments have since taken place that justify follow-up:
1) In November Jason Smith (@automayt) posted Parsing Bro 2.2 Logs with Logstash on the Applied Network Security Monitoring blog. This post exemplifies exactly how to configure Bro with Logstash and Kibana, and includes reference material regarding how to do so with Doug Burk's (@dougburks) Security Onion (@securityonion).
2) Additionally, please help me in congratulating Chris Sanders (@chrissanders88), lead author, along with contributing authors, the above-mentioned Jason Smith, as well as David Bianco (@DavidJBianco) and Liam Randall (@hectaman), on the very recent publication of the book the Applied NSM blog supports: Applied Network Security Monitoring: Collection, Detection, and Analysis, also available directly from Syngress.
Chris is indeed a packet ninja, a fellow GSE, and is quite honestly a direct contributor to how I passed that extremely challenging certification. His Practical Packet Analysis: Using Wireshark to Solve Real-World Network Problems is an excellent book and was a significant part of my study and practice for the GSE process. As such, while I have not yet read it, I am quite confident that Applied Network Security Monitoring: Collection, Detection, and Analysis will be of great benefit to all who purchase and read it. Let me be more clear, at the risk of coming off as an utter fanboy. I read Chris' Practical Packet Analysis as part of my studies for GSE | passed GSE as part of STI graduate school requirements | finished graduate school. :-)
Congratulations, Chris and team, well done, and thank you.
Merry Christmas all, and cheers.
Friday, December 20, 2013
Sunday, December 01, 2013
toolsmith: Hey Lynis, Audit This
Prerequisites/dependencies
Unix/Linux operating systems
Introduction
Happy holidays to all readers, the ISSA community, and
infosec tool users everywhere. As part of December’s editorial theme for the ISSA Journal, Disaster
Recovery/Disaster Planning, I thought I’d try to connect tooling and
tactics to said theme. I’m going to try and do this more often so you don’t end
up with a web application hacking tool as part of the forensics and analysis
issue. I can hear Tom (editor) and Joel (editorial advisory board chair) now:
“Congratulations Russ, it only took you seven years to catch up with everyone
else, you stubborn git.” :-)
Better late than never I always say, so back to it. As
cited in many resources, including Georgetown University’s System and
Operations Continuity page, “Of companies
that had a major loss of business data, 43% never reopen, 51% close within two
years, and only 6% will survive long-term.” Clearly
then, a sound disaster recovery and planning practice is essential to survival.
The three control measures for effective disaster recovery planning are preventive,
detective, and corrective. This month we’ll discuss Lynis, a security and
system auditing tool to harden Unix/Linux (*nix) systems, as a means to which
facilitate both preventative (intended to prevent an event from occurring) and
detective (intended to detect and/or discover unwanted events) controls. How
better to do so than with a comprehensive and effective tool that performs a
security scan and determines the security posture of your *nix systems while
providing suggestions or warning for any detected security issues? I caught
wind of Lynis via toolswatch, a
great security tools site that provides quick snapshots on tools useful to
infosec practitioners. NJ Ouchn (@ToolsWatch), who runs toolswatch and the
Blackhat Arsenal Tools event during Blackhat conferences, mentioned a new
venture for the Lynis author (CISOfy) so it
seemed like a great time to get the scoop directly from Rootkit.nl’s Michael
Boelen, the Lynis developer and project lead.
According to Michael, there is much to be excited about
as a Lynis Enterprise solution, including plugins for malware detection,
forensics, and heuristics, is under development. This solution will include the
existing Lynis client that we’ll cover here, a management and reporting
interface as well as related plugins. Michael says they’re making great
progress and each day brings them closer to an official first version. Specific
to the plugins, while a work in progress, they create specialized hooks via the
client. As an example, imagine heuristics scanning with correlation at the
central node, to detect security intrusions. Compliance checking for the likes
of Basel II, GLBA, HIPAA, PCI DSS, and SOx is another likely plugin candidate.
The short term roadmap consists of finishing the web interface, followed by the presenting and supporting documents. This will include documentation, checklists, control overviews and materials for system administrators, security professionals and auditors in particular. This will be followed by the plugins and related services. In the meantime CISOfy will heavily support the development of the existing Lynis tool, as it is the basis of the enterprise solution. Michael mentions that Lynis is already being used by thousands of people responsible for keeping their systems secure.
A key tenet for Lynis is proper information gathering and vulnerability determination/analysis in order to provide users with the best advice regarding system hardening. Lynis will ultimately provide both auditing functionality but monitoring and control mechanisms; remember the above mentioned preventative and detective controls? For monitoring, there will be a clear dashboard to review the environment for expected and unexpected changes with light touch for system administrators and integration with existing SIEM or configuration management tools. The goal is to leverage existing solutions and not reinvent the wheel.
The short term roadmap consists of finishing the web interface, followed by the presenting and supporting documents. This will include documentation, checklists, control overviews and materials for system administrators, security professionals and auditors in particular. This will be followed by the plugins and related services. In the meantime CISOfy will heavily support the development of the existing Lynis tool, as it is the basis of the enterprise solution. Michael mentions that Lynis is already being used by thousands of people responsible for keeping their systems secure.
A key tenet for Lynis is proper information gathering and vulnerability determination/analysis in order to provide users with the best advice regarding system hardening. Lynis will ultimately provide both auditing functionality but monitoring and control mechanisms; remember the above mentioned preventative and detective controls? For monitoring, there will be a clear dashboard to review the environment for expected and unexpected changes with light touch for system administrators and integration with existing SIEM or configuration management tools. The goal is to leverage existing solutions and not reinvent the wheel.
Lynis and Lynis Enterprise will ultimately provide
guidance to organizations who can then more easily comply with regulations,
standards and best practices by defining security baselines and ready-to-use
plans for system hardening in a more measurable and action-oriented manner.
One other significant advantage of Lynis is how lightweight it is and easy to implement. The requirements to run the tool are almost non-existent and it is, of course, open source, allowing ready inspection and assurances that it’s not overly intrusive. Michael intends to provide the supporting tools (such as the management interface) as a Software-as-as-Service (SAAS) solution, but he did indicate that, depending on customer feedback and need, CISOfy might consider appliances at a later stage.
One other significant advantage of Lynis is how lightweight it is and easy to implement. The requirements to run the tool are almost non-existent and it is, of course, open source, allowing ready inspection and assurances that it’s not overly intrusive. Michael intends to provide the supporting tools (such as the management interface) as a Software-as-as-Service (SAAS) solution, but he did indicate that, depending on customer feedback and need, CISOfy might consider appliances at a later stage.
I conducted an interesting
little study of three unique security-centric Linux distributions running as
VMWare virtual machines to put Lynis through its paces and compare results,
namely, SIFT 2.1.4, SamuraiWTF2.1, and Kali 1.0. Each of these was assessed as
pristine, new instances, as if they’d just been installed or initialized.
Setting Lynis up for use
Lynis is designed to be
portable and as such is incredibly easy to install. Simply download and unpack
Lynis to a directory of your choosing. You can also create custom packages if
you wish; Lynis has been tested on multiple operating systems including Linux,
all versions of BSD, Mac OS X, and Solaris. It's also been tested with all the
package managers related to these operating systems so deployment and upgrading
is fundamentally simple. To validate its portability I installed it on USB media
as follows.
2)
Copied and unpacked it to /media/LYNIS/lynis-1.3.5
(an ext2-formatted USB stick)
3)
In VMWare menu, selected VM, then Removable
Devices, and checked Toshiba Data Traveler to make my USB stick available to the three virtual
machines mentioned above.
You can opt to make
modifications to the profile configuration (default.prf) file to disable or
enable certain checks, and establish a template for operating system, system
role, and/or security level. I ran my test on the three VMs with the default
profile.
Using Lynis
This won’t be one of those
toolsmith columns with lots of pretty pictures, we’re dealing with a command
prompt and text output when using the Lynis client. Which is to say, change
directories to your USB drive, suxh as cd
/media/LYNIS/lynis-1.3.5 on my first test instance, followed by sh lynis –auditor HolisticInfoSec –c
from a root prompt as seen in Figure 1.
FIGURE 1: Lynis kicking off
|
You can choose to use the –q
switch for quiet mode which prompts only on warnings and doesn’t require you to
step through each prompted phase. Once Lynis is finished you can immediately
review results via /var/log/lynis-report.dat
and grep for suggestions and warnings. You’re ultimately aiming for a hardening
index of 100. Unfortunately our first pass on the Kali system yielded only a
50. Lynis suggested installing auditd and removing unneeded compilers. Please
note, I am not suggesting you
actually do this with your Kali instance, fine if it’s a VM snapshot, this is
just to prove my point re: Lynis findings. Doing so did however increase the
hardening index to a 51. J
Lynis really showed its stuff
while auditing the SANS SIFT 2.1.4 instance. The first pass gave us a hardening
index of 59 and a number of easily rectified warnings. I immediately corrected
the following and ran Lynis again:
- warning[]=AUTH-9216|M|grpck binary found errors in one or more group files|
- warning[]=FIRE-4512|L|iptables module(s) loaded, but no rules active|
- warning[]=SSH-7412|M|Root can directly login via SSH|
- warning[]=PHP-2372|M|PHP option expose_php is possibly turned on, which can reveal useful information for attackers.|
Running grpck told me that 'sansforensics' is a member of the 'ossec'
group in /etc/group but not in /etc/gshadow. Easily fixed by adding ossec:!::sansforensics to /etc/gshadow.
I ran sudo ufw enable to fire up active iptables rules, then
edited /etc/ssh/sshd_config with
PermitRootLogin no to ensure no
direct root login. Always do this as root will be bruteforce attacked and you
can sudo as needed from a regular user account with sudoers permissions.
Finally changing expose_php to Off in /etc/php5/apache2/php.ini
solves the PHP finding.
Running Lynis again after
just these four fixes improved the hardening index from 59 to 69. Sweet!
Last but not least, an
initial Lynis run against SamuraiWTF informed us of a hardening index of 47.
Uh-oh, thank goodness the suggestion list per sudo
cat /var/log/lynis-report.dat | grep suggestion gave us a lot of options
to make some systemic improvements as seen in Figure 2.
FIGURE 2: Lynis suggests how the Samurai might harden his foo |
Updating just a few entries
pushed the hardening index to 50; you can spend as much time and effort as you
believe necessary to increase the system’s security posture along with the
hardening index
The end of a Lynus run, if
you don’t suppress verbosity with the –q switch will result in the like of
Figure 3, including your score, log and report locations, and tips for test
improvement.
FIGURE 3: The end of a verbose Lynis run |
Conclusion
I’m looking forward to the Lynis Enterprise release from
Michael’s CISOfy and believe it will have a lot to offer for organizations
looking for a platform-based, centralized means to audit and harden their *nix
systems. Again, count on reporting and plugins as well as integration with SIEM
systems and configuration management tools such as CFEngine. Remember too what
Lynis can do to help you improve auditability against controls for major
compliance mandates.
Good luck, and wishing you all a very Happy Holidays.
Stay tuned to vote for the 2013 Toolsmith Tool of the Year
starting December 15th.
Ping me via email if you have questions (russ at
holisticinfosec dot org).
Cheers…until next month.
Acknowledgements
Thursday, November 14, 2013
Volatility 2.3 and FireEye's diskless, memory-only Trojan.APT.9002
If you needed more any more evidence as to why your DFIR practice should evolve to a heavy focus on memory analysis, let me offer you some real impetus.
FireEye's Operation Ephemeral Hydra: IE Zero-Day Linked to DeputyDog Uses Diskless Method, posted 10 NOV 2013 is specific to an attack that "loaded the payload directly into memory without first writing to disk." As such, this "will further complicate network defenders’ ability to triage compromised systems, using traditional forensics methods." Again, what is described is a malware sample (payload) that " does not write itself to disk, leaving little to no artifacts that can be used to identify infected endpoints." This FireEye analysis is obviously getting its share of attention, but folks are likely wondering "how the hell are we supposed to detect that on compromised systems?"
Question: Why does Volatility rule?
Answer: Because we don't need no stinking file system artifacts.
In preparation for a Memory Analysis with Volatility presentation I gave at SecureWorld Expo Seattle last evening, I had grabbed the malware sample described in great length by FireEye from VirusShare (MD5 104130d666ab3f640255140007f0b12d), executed it on a Windows 7 32-bit virtual machine, used DumpIt to grab memory, and imported the memory image to my SIFT 2.14 VM running Volatility 2.3 (had to upgrade as 2.2 is native to SIFT 2.14).
I had intended to simply use a very contemporary issue (3 days old) to highlight some of the features new to the just released stable Volatility 2.3, but what resulted was the realization that "hey, this is basically one of the only ways to analyze this sort of malware."
So here's the breakdown.
The FireEye article indicated that "this Trojan.APT.9002 variant connected to a command and control server at 111.68.9.93 over port 443."
Copy that. Ran vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw netscan and quickly spotted 111.68.9.93 as seen in Figure 1.
I was interested in putting timeliner through its paces as it is new to Volatility in 2.3, and was not disappointed. Issued vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw timeliner --output=body --output-file=output.body and spotted 111.68.9.93 in network connections tied closely to a timestamp of 1384212827? Er? That's Unix timestamp. Translated to human readable: Mon, 11 Nov 2013 23:33:47 GMT. Check! See Figure 2.
Clearly PID 3176 is interesting, keep it in mind as we proceed.
The article states that "after an initial XOR decoding of the payload with the key “0x9F”, an instance of rundll32.exe is launched and injected with the payload using CreateProcessA, OpenProcess, VirtualAlloc, WriteProcessMemory, and CreateRemoteThread."
Ok, so what is PID 3176 associated with? vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw pslist | grep 3176 will tell us in Figure 3.
What, what?! It's rundll32.exe. Mmm-hmm.
Strings can help us for the next step to spot CreateProcessA, OpenProcess, VirtualAlloc, WriteProcessMemory, and CreateRemoteThread as associated with PID 3176. The Volatility wiki recommends using Sysinternals strings so we can use –q and –o switches to ensure that the header is not output (-q) and that there is an offset for each line (-o), as in strings -q -o WIN-L905IILDALU-20131111-234404.raw > strings.txt. We then convert strings.txt for Volatility with vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw strings -s strings.txt --output-file=stringsVol.txt. Now we can search for strings that include 3176 and the likes of CreateProcessA, along with offsets to see if there are associations. A search immediately produced:
04cfce5a [3176:701f8e5a] CreateProcessA
abd60bd8 [3176:00191bd8] OpenProcess
abd60ae4 [3176:00191ae4] VirtualAlloc
bedd8384 [3176:10002384] WriteProcessMemory
bedd835a [3176:1000235a] CreateRemoteThread
What we've just validated is that PID 3176 (rundll32.exe) shows indications of the five functions described by FireEye.
Per the article, "inside the in-memory version of the Trojan.APT.9002 payload used in this strategic Web compromise, we identified the following interesting string: “rat_UnInstall”. Gotcha; a quick string search says: bd75bcc0 [3176:0035fcc0] __rat_UnInstall__3176.
The rat_UnInstall IOC is clearly associated with PID 3176.
Just for giggles, I checked one last point made by FireEye. They stated that "we also found the following strings of interest present in these 9002 RAT samples (excluding the in-memory variant): McpRoXy.exe, SoundMax.dll
I was intrigued by the "excluding the in-memory variant claim", so I did I quick check. I could, as always, be wrong (tell me if I am), buy the dlllist module seems to disagree.
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw dlllist -p 3176 | grep SoundMax.dll produced Figure 4.
When I checked the file system for C:\users\malman\SoundMax.dll, it was indeed present.
While I am operating on the belief that my analysis of 104130d666ab3f640255140007f0b12d matches the FireEye IOCs via Volatility memory analysis alone, dlllist does indicate that the malware drops SoundMax.dll on the file system. I attribute this to the possibility that my "delivery system" was different than the IE 0-day FireEye describes; I had to download the sample and execute it to replicate behavior.
Correction 15 NOV 2013: Ned Moran from FireEye contacted me to let me know that my assumption based on interpretation of the FireEye blogpost was incorrect. 104130d666ab3f640255140007f0b12d is not the diskless version of 9002; at this time FireEye is not providing hashes or sharing that sample at this time. I clearly misinterpreted their post to indicate that 104130d666ab3f640255140007f0b12d was that sample, I was incorrect and I apologize. That being said Ned assured me that I was not out of my mind and let me know "yes, my reading of your methodology is that it would have produced very similar results, the only difference being that had you would not have found the 'SoundMax.dll' string in the diskless version. So, your approach was sound you were just looking at a different sample."
Regardless, we wouldn't need any file system artifacts to confirm the presence of the diskless, memory-only version of Trojan.APT.9002 on a victim system.
Confirmed connection to 111.68.9.93 with netscan:
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw netscan
Confirmed timeline for connection to 111.68.9.93 with timeliner:
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw timeliner --output=body --output-file=output.body
Identified rundll32.exe as owner of the suspect PID (3176) with pslist:
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw pslist | grep 3176
Used strings as analysis to further confirm:
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw strings -s strings.txt --output-file=stringsVol.txt
Used dlllist to call out SoundMax.dll:
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw dlllist -p 3176 | grep SoundMax.dll
One more time, with feeling: Why does Volatility rule? Hopefully, I've helped answer that...again.
Cheers!
FireEye's Operation Ephemeral Hydra: IE Zero-Day Linked to DeputyDog Uses Diskless Method, posted 10 NOV 2013 is specific to an attack that "loaded the payload directly into memory without first writing to disk." As such, this "will further complicate network defenders’ ability to triage compromised systems, using traditional forensics methods." Again, what is described is a malware sample (payload) that " does not write itself to disk, leaving little to no artifacts that can be used to identify infected endpoints." This FireEye analysis is obviously getting its share of attention, but folks are likely wondering "how the hell are we supposed to detect that on compromised systems?"
Question: Why does Volatility rule?
Answer: Because we don't need no stinking file system artifacts.
In preparation for a Memory Analysis with Volatility presentation I gave at SecureWorld Expo Seattle last evening, I had grabbed the malware sample described in great length by FireEye from VirusShare (MD5 104130d666ab3f640255140007f0b12d), executed it on a Windows 7 32-bit virtual machine, used DumpIt to grab memory, and imported the memory image to my SIFT 2.14 VM running Volatility 2.3 (had to upgrade as 2.2 is native to SIFT 2.14).
I had intended to simply use a very contemporary issue (3 days old) to highlight some of the features new to the just released stable Volatility 2.3, but what resulted was the realization that "hey, this is basically one of the only ways to analyze this sort of malware."
So here's the breakdown.
The FireEye article indicated that "this Trojan.APT.9002 variant connected to a command and control server at 111.68.9.93 over port 443."
Copy that. Ran vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw netscan and quickly spotted 111.68.9.93 as seen in Figure 1.
Figure 1 |
Figure 2 |
The article states that "after an initial XOR decoding of the payload with the key “0x9F”, an instance of rundll32.exe is launched and injected with the payload using CreateProcessA, OpenProcess, VirtualAlloc, WriteProcessMemory, and CreateRemoteThread."
Ok, so what is PID 3176 associated with? vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw pslist | grep 3176 will tell us in Figure 3.
Figure 3 |
Strings can help us for the next step to spot CreateProcessA, OpenProcess, VirtualAlloc, WriteProcessMemory, and CreateRemoteThread as associated with PID 3176. The Volatility wiki recommends using Sysinternals strings so we can use –q and –o switches to ensure that the header is not output (-q) and that there is an offset for each line (-o), as in strings -q -o WIN-L905IILDALU-20131111-234404.raw > strings.txt. We then convert strings.txt for Volatility with vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw strings -s strings.txt --output-file=stringsVol.txt. Now we can search for strings that include 3176 and the likes of CreateProcessA, along with offsets to see if there are associations. A search immediately produced:
04cfce5a [3176:701f8e5a] CreateProcessA
abd60bd8 [3176:00191bd8] OpenProcess
abd60ae4 [3176:00191ae4] VirtualAlloc
bedd8384 [3176:10002384] WriteProcessMemory
bedd835a [3176:1000235a] CreateRemoteThread
What we've just validated is that PID 3176 (rundll32.exe) shows indications of the five functions described by FireEye.
Per the article, "inside the in-memory version of the Trojan.APT.9002 payload used in this strategic Web compromise, we identified the following interesting string: “rat_UnInstall”. Gotcha; a quick string search says: bd75bcc0 [3176:0035fcc0] __rat_UnInstall__3176.
The rat_UnInstall IOC is clearly associated with PID 3176.
Just for giggles, I checked one last point made by FireEye. They stated that "we also found the following strings of interest present in these 9002 RAT samples (excluding the in-memory variant): McpRoXy.exe, SoundMax.dll
I was intrigued by the "excluding the in-memory variant claim", so I did I quick check. I could, as always, be wrong (tell me if I am), buy the dlllist module seems to disagree.
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw dlllist -p 3176 | grep SoundMax.dll produced Figure 4.
Figure 4 |
While I am operating on the belief that my analysis of 104130d666ab3f640255140007f0b12d matches the FireEye IOCs via Volatility memory analysis alone, dlllist does indicate that the malware drops SoundMax.dll on the file system. I attribute this to the possibility that my "delivery system" was different than the IE 0-day FireEye describes; I had to download the sample and execute it to replicate behavior.
Correction 15 NOV 2013: Ned Moran from FireEye contacted me to let me know that my assumption based on interpretation of the FireEye blogpost was incorrect. 104130d666ab3f640255140007f0b12d is not the diskless version of 9002; at this time FireEye is not providing hashes or sharing that sample at this time. I clearly misinterpreted their post to indicate that 104130d666ab3f640255140007f0b12d was that sample, I was incorrect and I apologize. That being said Ned assured me that I was not out of my mind and let me know "yes, my reading of your methodology is that it would have produced very similar results, the only difference being that had you would not have found the 'SoundMax.dll' string in the diskless version. So, your approach was sound you were just looking at a different sample."
Regardless, we wouldn't need any file system artifacts to confirm the presence of the diskless, memory-only version of Trojan.APT.9002 on a victim system.
Confirmed connection to 111.68.9.93 with netscan:
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw netscan
Confirmed timeline for connection to 111.68.9.93 with timeliner:
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw timeliner --output=body --output-file=output.body
Identified rundll32.exe as owner of the suspect PID (3176) with pslist:
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw pslist | grep 3176
Used strings as analysis to further confirm:
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw strings -s strings.txt --output-file=stringsVol.txt
Used dlllist to call out SoundMax.dll:
vol.py --profile=Win7SP1x86 -f WIN-L905IILDALU-20131111-234404.raw dlllist -p 3176 | grep SoundMax.dll
One more time, with feeling: Why does Volatility rule? Hopefully, I've helped answer that...again.
Cheers!
Friday, November 01, 2013
toolsmith: OWASP Xenotix XSS Exploit Framework
Prerequisites
Again, entirely accurate. The Information
Gathering modules also include WAF
Fingerprinting, as well as Ping,
Port, and Internal Network Scans. Remember that,
as is inherent to its very nature, these scans occur in the context of the
victimized browser’s system as a function of cross-site scripting.
Current Windows operating system
Introduction
Hard to believe this month’s toolsmith marks seven full
years of delivering dynamic content and covering timely topics on the perpetually
changing threat-scape information security practitioners face every day. I’ve
endeavored to aid in that process 94 straight months in a row, still enjoy
writing toolsmith as much as I did day one, and look forward to many more to
come. How better to roll into our eighth year than by zooming back to one of my
favorite topics, cross-site scripting (XSS), with the OWASP Xenotix XSS Exploit
Framework. I’d asked readers and Twitter followers to vote for November’s topic
and Xenotix won by quite a majority. This was timely as I’ve also seen renewed
interest in my Anatomy of an XSS Attack
published in the ISSA Journal more than five years ago in June 2008. Hard to
believe XSS vulnerabilities still prevail but according to WhiteHat Security’s
May 2013 Statistics report:
1) While
no longer the most prevalent vulnerability, XSS is still #2 behind only Content
Spoofing
2) While
50% of XSS vulnerabilities were resolved, up from 48% in 2011, it still took an
average of 227 for sites to deploy repairs
Per the 2013 OWASP Top 10, XSS is
still #3 on the list. As such, good tools for assessing web applications for
XSS vulnerabilities remain essential, and OWASP Xenotix XSS Exploit Framework
fits the bill quite nicely.
Ajin Abraham (@ajinabraham) is Xenotix’s developer and project lead; his
feedback on this project supports the ongoing need for XSS awareness and
enhanced testing capabilities.
According to Ajin, most of the current pool of web application
security tools still don't give XSS the full attention it deserves, an
assertion he supports with their less than optimal detection rates and a high
number of false positive. He has found that most of these tools use a payload
database of about 70-150 payloads to scan for XSS. Most web application scanners,
with the exception of few top notch proxies such as OWASP ZAP and
Portswigger’s Burp Suite, don't provide
much flexibility especially when dealing with headers and cookies. They typically
have a predefined set of protocols or rules to follow and from a penetration
tester’s perspective can be rather primitive. Overcoming some of these shortcomings
is what led to the OWASP Xenotix XSS Exploit Framework.
Xenotix is a penetration testing tool developed
exclusively to detect and exploit XSS vulnerabilities. Ajin claims that Xenotix
is unique in that it is currently the only XSS vulnerability scanner with zero false
positives. He attributes this to the fact that it uses live payload reflection-based
XSS detection via its powerful triple browser rendering engines, including
Trident, WebKit and Gecko. Xenotix apparently has the
world's second largest XSS payload database, allowing effective XSS detection
and WAF bypass. Xenotix is also more than a vulnerability scanner as it also includes
offensive XSS exploitation and information gathering modules useful in
generating proofs of concept.
For feature releases Ajin intends to implement additional
elements such as an automated spider and an intelligent scanner that can choose
payloads based on responses to increase efficiency and reduce overall scan
time. He’s also working on an XSS payload inclusive of OSINT gathering which
targets certain WAF's and web applications with specific payloads, as well as a
better DOM scanner that works within the browser. Ajin welcomes support from
the community. If you’re interested in the project and would like to contribute
or develop, feel free to contact him via @ajinabraham, the OWASP Xenotix site, or the
OpenSecurity site.
Xenotix Configuration
Xenotix installs really easily. Download the latest
package (4.5 as this is written), unpack the RAR file, and execute Xenotix XSS Exploit Framework.exe. Keep in
mind that antimalware/antivirus on Windows systems will detect xdrive.jar as a Trojan Downloader.
Because that’s what it is. ;-) This is an enumeration and exploitation tool
after all. Before you begin, watch Ajin’s YouTube video
regarding Xenotix 4.5 usage. There is no written documentation for this tool so
the video is very helpful. There are additional videos for
older editions that you may find useful as well. After installation, before you
do anything else, click Settings,
then Configure Server, check the
Semi Persistent Hook box, then
click Start. This will allow you
to conduct information gathering and exploitation against victims once you’ve
hooked them.
Xenotix utilizes the Trident engine (Internet Explorer
7), the Webkit engine (Chrome 25), and the Gecko engine (Firefox 18), and
includes three primary module sets: Scanner,
Information Gathering, and XSS Exploitation as seen in Figure 1.
FIGURE 1: The Xenotix user interface |
We’ll walk through examples of each below while taking
advantage of intentional XSS vulnerabilities in the latest release of OWASPMutillidae II: Web Pwn in Mass Production. We
covered Jeremy Druin’s (@webpwnized) Mutillidae in August 2012’s toolsmith and it’s
only gotten better since.
Xenotix Usage
These steps assume you’ve installed Mutillidae II
somewhere, ideally on a virtual machine, and are prepared to experiment as we
walk through Xenotix here.
Let’s begin with the Scanner
modules. Using Mutillidae’s DNS Lookup
under OWASP Top 10 Ã A2 Cross Site Scripting (XSS) Ã Reflected (First Order) Ã DNS Lookup. The vulnerable GET
parameter is page and on POST is
target_host. Keep in mind that as
Xenotix will confirm vulnerabilities across all three engines, you’ll be hard
pressed to manage output, particularly if you run in Auto Mode; there is no real reporting function with this
tool at this time. I therefore suggest testing in Manual Mode.
This allows you to step through each payload and as seen Figure 2, we get our
first hit with payload 7 (of 1530).
FIGURE 2: Xenotix manual XSS scanning |
You can also try the XSS
Fuzzer where you replace parameter values with a marker, [X], and fuzz
in Auto Mode. The XSS Fuzzer allows you to skip ahead to
a specific payload if you know the payload position index. Circling back to the
above mentioned POST parameter, I used the POST
Request Scanner to build a request, establishing http://192.168.40.139/mutillidae/index.php?page=dns-lookup.php
as the URL and setting target_host
in Parameters. Clicking POST
then populated the form as noted in Figure 3 and as with Manual mode, our first
hits came with payload 7.
FIGURE 3: Xenotix POST Request Scanner |
You can also make use of Auto
Mode, as well as DOM, Multiple Parameter, and Header Scanners, as well as a Hidden Parameter Detector.
The Information
Gathering modules are where we can really start to have fun with
Xenotix. You first have to hook a victim browser to make use of this tool set.
I set the Xenotix server to the host IP where Xenotix was running (rather than
the default localhost setting) and checked the Semi
Persistent Hook checkbox. The resulting payload of
was then used with Mutillidae’s Pen Test Tool Lookup to hook a victim browser on a different system running Firefox on Windows 8.1. With the browser at my beck and call, I clicked Information Gathering where the Victim Fingerprinting module produced:
was then used with Mutillidae’s Pen Test Tool Lookup to hook a victim browser on a different system running Firefox on Windows 8.1. With the browser at my beck and call, I clicked Information Gathering where the Victim Fingerprinting module produced:
Saving the most fun for last,
let’s pwn this this thang! A quick click of XSS
Exploitation offers us a plethora of module options. Remember, the
victim browser is still hooked (xooked) via:
I sent my victim browser a message as depicted in Figure 4 where I snapped the Send Message configuration and the result in the hooked browser.
I sent my victim browser a message as depicted in Figure 4 where I snapped the Send Message configuration and the result in the hooked browser.
FIGURE 4: A celebratory XSS message |
Message boxes are cute, Tabnabbing
is pretty darned cool, but what does real exploitation look like? I first fired
up the Phisher module with
Renren (the Chinese Facebook) as my target site, resulting in a Page Fetched and Injected message and
Renren ready for login in the victim browser as evident in Figure 5. Note that
my Xenotix server IP address is the destination IP in the URL window.
FIGURE 5: XSS phishing Renren |
But wait, there’s more. When
the victim user logs in, assuming I’m also running the Keylogger module, yep,
you guessed it. Figure 6 includes keys logged.
FIGURE 6: Ima Owned is keylogged |
Your Renren is my Renren.
What? Credential theft is not enough for you? You want to deliver an executable
binary? Xenotix includes a safe, handy sample.exe
to prove your point during demos for clients and/or decision makers. Still not
convinced? Need shell? You can choose from JavaScript,
Reverse HTTP, and System Shell Access. My favorite, as
shared in Figure 7, is reverse shell via a Firefox bootstrapped add-on as
delivered by XSS Exploitation --> System Shell Access --> Firefox Add-on Reverse Shell. Just Start Listener, then Inject (assumes a hooked browser).
FIGURE 7: Got shell? |
Assuming the victim happily
accepts the add-on installation request (nothing a little social engineering
can’t solve), you’ll have system level access. This makes pentesters very
happy. There are even persistence options via Firefox add-ons, more fun than a
frog in a glass of milk.
In Conclusion
While this tool won’t replace proxy scanning platforms
such as Burp or ZAP, it will enhance them most righteously. Xenotix is GREAT
for enumeration, information gathering, and most of all, exploitation. Without
question add the OWASP Xenotix XSS Exploit Framework to your arsenal and as
always, have fun but be safe. Great work, Ajin, looking forward to more, and
thanks to the voters who selected Xenotix for this month’s topic. If you have
comments, follow me on Twitter via @holisticinfosec or email if you have
questions via russ at holisticinfosec dot org.
Cheers…until next month.
Acknowledgements
Ajin Abraham, Information
Security Enthusiast and Xenotix project lead
Subscribe to:
Posts (Atom)
Moving blog to HolisticInfoSec.io
toolsmith and HolisticInfoSec have moved. I've decided to consolidate all content on one platform, namely an R markdown blogdown sit...
-
Continuing where we left off in The HELK vs APTSimulator - Part 1 , I will focus our attention on additional, useful HELK features to ...
-
As you weigh how best to improve your organization's digital forensics and incident response (DFIR) capabilities heading into 2017, cons...
-
Ladies and gentlemen, for our main attraction, I give you...The HELK vs APTSimulator, in a Death Battle! The late, great Randy "Macho...