toolsmith: SamuraiWTF

December's toolsmith covers SamuraiWTF.
I'll repeat myself as stated in the article:
SamuraiWTF rocks, plain and simple.
It’d be my 2010 Toolsmith Tool of the Year but alas, I am letting you, dear reader, make that “Tool of the Year” decision for 2010 (poll details to follow as 2010 draws to a close).

SamuraiWTF is a LiveCD Linux release designed to serve you for your web pen-testing needs. Kevin Johnson of Secure Ideas and Justin Searle of InGuardians included what they believe are the best of the open source and free tools that focus on testing and attacking websites, selections based on the tools they use as part of their job duties. SamuraiWTF includes tools useful in all four steps of a web pen-test:
• Reconnaissance – Fierce domain scanner, Maltego (be sure to check out the Shodan Maltego add-on)
• Mapping – WebScarab, ratproxy
• Discovery – w3af and burp
• Exploitation – BeEF, AJAXShell

The article walks through using SamuraiWTF for each phase, but as always, I had the most fun exemplifying exploit methodology with BeEF.
Browser zombies rule! ;-)



If you seek to learn a ton about web application security testing, or consolidate all the tools you’ll likely need on one system, SamuraiWTF is for you.
As Kevin indicated for the article, you can use SamuraiWTF as your base install, then enhance with Burp Suite Pro if you happen to be a commercial Burp user.
Stay tuned for the SamuraiWTF 1.0 release, and contribute to the project if so motivated.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

CSRF mitigation: 4images Gallery's comprehensive approach

Once in awhile, in my quest to break (and promote fixing of) every web application I encounter, I have email discussions with some excellent people who reach out to me after the initial advisory during a coordinated disclosure.
Such was the case with Kai S. of Dots United GmbH, the team who develops the 4images Gallery.
Just a day or two after he'd been contacted by Secunia, whom I submit my vulnerability findings to for disclosure coordination, I heard directly from Kai. He asked me to provide more detail with regard to the finding indicating that 4images Gallery accepted "HTTP requests without performing any validity checks to verify the request", better known as cross-site request forgery (CSRF).
After replying with my proof of concept and some resource material, Kai replied that he would "forward this to our developers so we can release a fixed version".
On October 27 Dots United released a fix for all versions up to and including 1.7.8.
On November 10, the 4images Gallery team released version 1.7.9 inclusive of global CSRF mitigation.
In addition to a deserved "Well done!" for excellent communication as well as a timely fix turnaround, I'd like to applaud their direct approach to the fix, seemingly based on OWASP recommendations. Should all web application developers take a similar path, we'd likely see a reduction in CSRF vulnerability statistics.

Let me walk you through some of the 4images Gallery CSRF mitgation methods.
The core of the protection is includes/csrf_utils.php; CSRF protection is enabled by default.
As created by csrf_utils.php, generate a random MD5-derived token:



Return said token to the form as follows:



Then when some jerk like me comes along and throws something nasty at an admin...



...the attacker is thwarted by a unique, random token.



Add to the above-mentioned functionality the fact that the 4images devs allow you to take advanced control of CSRF protection via the config.php file. You can manage the default bit or maintain granular control of frontend/backend protection, token expiration, CSRF protection variable naming, and even XHTML vs. HTML.



I appreciate the efforts undertaken by Kai and the Dots United team in response to this vulnerability, and look forward to other development teams/vendors hopefully taking a similar tack.
Happy sailing. ;-)

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

toolsmith: Confessor & Mole for IR & security analysis

As November 2010's toolsmith kicks off the fifth year of the column for the ISSA Journal, I am proud to use it as an opportunity to announce the official release of Bryan Casper's Confessor and Kris Thomas' MOLE.
I discussed these tools at ISSA International in September and again at SecureWorld Expo Seattle, and after a slight delay to clarify licensing (they're released under the Microsoft Public License (Ms-PL), both tools are available for you on CodePlex.
These tools were born of needing better utilities for incident response and security analysis in complex, massive cloud-like environments.
If you'd like a copy of the above-mentioned presentation, please contact me and I'll send it to you.

As described in the article, Bryan's Confessor answers the challenge of collecting system logs and attributes on hundreds or even thousands of systems at the same time, utilizing the same tools as MIR-ROR, but deploying them in an enterprise capable manner.
Note: Since the article's release Confessor has been updated to pass domain credentials via the UI and process host names as well as IP addresses.

Kris' MOLE was spawned improve on a method I’d been utilizing to cull malware from malicious URLs sent across Windows Live Messenger. Where I’d been using a specific wget string at the command-line Kris built MOLE (Malicious Online Link Engine) as a wrapper for wget that includes many additionally useful features.

We find these tools incredibly useful and are very pleased to be able to release them for public consumption as freely available and open source.

The article is here, Confessor is here, and MOLE is here.

Please ping me if you have questions; we look forward to your feedback.
Comments welcome here or via email.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Checking for user-agent header SQL injection vulns

As I analyze various web applications in the name of fun or fortune, I am sometimes treated to those little reminders that result in a "doh!".
Such was the case when I was assessing the latest release of the Avactis Shopping Cart.
I'd just installed the latest free version (1.9.1). Typically, after finding a flaw in an vendor's offering, I sign up for their new release notices, and had recently received one from Avactis.
When last I'd visited said shopping cart I'd spotted a couple of XSS bugs in the checkout.php script for version 1.8.1 and earlier. I admit that at the time I did not do as robust review of the application as I might now; in all likelihood the following bug was present when the XSS bugs were disclosed in September 2008.

With a fresh version installed thanks to the reminder, I fired up Firefox with Tamper Data, and started poking around. With Tamper Data, as we've discussed before, any web form input parameters/variables are subject to your manipulation.
I habitually work from the right side of the Tamper Data UI wherein POST parameters reveal themselves.
There I sat, happily walking through the app, when the bell went off.
"Hey, Russ, don't forget to fuzz the header values too!"
Cross-site scripting and SQL injection specific to cookie values is certainly not unheard of but you may need to refer to a checklist to always remember to probe them for vulnerabilities.
In my case, this was even more true of the user-agent string value.
Not all apps are written to capture the user-agent data, but you can easily understand why shopping cart providers would make use of such information.
What's the point? Remember to investigate the user-agent header for issues too.
It can be a simple as appending a single tic on the end of the user-agent string and submitting it, as seen in Figure 1.


Figure 1

The results were immediate and revealing. In case you wondered what my typical user-agent entry looks like, Figure 2 will enlighten.



You can see that we've caught the query executed by /var/www/avactis/avactis-system/modules/reports/report-collectors/report_data_visitors_stat_collector.php, specifically SELECT_WEB_ROBOT_ID, and the result.
Which, in turn, clearly justifies the rapid and responsive patch provided by the vendor. I submitted the finding to Secunia on October 10th and the vendor posted the patch on October 12th; Secunia Advisory SA41764 was released as q result on October 14th.
A hearty "Well done!" to the Avactis team for that turnaround.

A quick diff of report_data_visitors_stat_collector.php from version 1.9.1 build 8356 as installed on October 9th and the patched version downloaded today is seen in Figure 3.


Figure 3

The tale is quickly told, and it's a good move by the Avactis dev team.
Begone ye damned addslashes()!
Note that the dev yanked use of the addslashes function on lines 49, 157, 238, and 318; addslashes() is a subject to circumvention, mysql_real_escape_string() is recommended.

See how much we can learn when remembering to be more thorough?

I must say, if I hadn't recently renewed my status as a certified Application Security Specialist, I might have missed this vulnerability altogether.
And I definitely would have missed out on the additional benefits such as photo opportunities with app sec glitterati (taken at the recent BlueHat). ;-)



Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

toolsmith: The NirSoft Collection

As I mention in this month's toolsmith, I am often reminded of all the tools I have not yet written about but have used on numerous occasions or even forgotten about. Such is the case with the NirSoft tools, particularly those found on the Windows side of the Helix distribution under IR.
Five NirSoft tools resurfaced for me well worthy of toolsmith mention as well as a place in the jumpkit.

• CurrPorts with IPNetInfo
• OpenedFilesView
• WhatInStartup
• NirCmd
  

Incident handler Kris Thomas used CurrPorts during a PCI DSS-related incident response drill we were conducting and promptly located the fake malicious process I’d seeded on a server as part of the drill.
Light-bulb moment: October's ISSA Journal toolsmith: The Nirsoft Collection is written to help you prevent one of those "doh!" moments. "Oh yeah, I'd forgotten all about that tool."
I'll simply rehash visual results of various tests I conducted for October's article.
Figure 1 is a CurrPorts screen shot taken before infection of the test VM with Backdoor.Win32.Agent.adqt (MD5: 6DBA44B457414593A858A3520A2F2278).


Figure 1

Figure 2 is the same view post-infection with the addition of bonus IPNetInfo results.


Figure 2

OpenedFilesView is exactly what it says it is, open or locked files on a given Windows system.

Figure 3 is an OpenedFilesView snapshot before infection with Backdoor.Win32.Poison.apec (MD5: CB702C3319A27E792B84846D3D6C61AD).


Figure 3

Figure 4 represents OpenedFilesView perspective post-infection where you'll note that the malicious binary has invoked Internet Explorer as we see changes to index.
dat. A quick review of C:\Documents and Settings\...\Cookies\ shows two cookies written to the system dated 9/26/10 for globo.com. Again, a bit of search engine research via site:threatexpert.com globo.com will reveal endless hits on various malicious behavior associated with globo.com, with particular emphasis on Brazilian malware.


Figure 4

Like it's fellow OpenedFilesView, WhatInStartup couldn't be more precise in its naming if it tried. Yep, it identifies what auto-loads when the system starts; always a good place to look for malicious basterds [sic].
Figure 5 is a WhatInStartup baseline screen-shot.


Figure 5

Figure 6 shows WhatInStartup results after a rogua AV (Security Essentials 2010...annoying!) infection; specifically, Trojan.Win32.FraudPack.amgz (MD5: 59C0E80D7F9705D10DA91E01B2763E9A)


Figure 6

Last but not least, NirCmd. This tool is interesting not overtly security-centric but good for pulling up registry entries or killing processes particularly when explorer.exe is hung.
Example: nircmd.exe regedit “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run”

The article is available here, the tools and others are here.
Use these oldies but goodies in good stead.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

CSRF on the increase per two reports

As I've spent almost all of my research time this past year focusing on finding and disclosing (coordinated) CSRF vulnerabilities, it was with some amusement that I read CSRF Vulnerabilities Rise, Overall Vulnerability Disclosures Dip from Kelly Jackson Higgins last week.

Therein she states that "overall, the number of vulnerability disclosures for the year is gradually declining to around 4,500 from nearly 7,000 last year, with the exception of CSRF, which had 155 vulnerabilities as of the first half of the year." This article is ultimately referring to TippingPoint DV Lab's Top Risks report.
Wolfgang Kandek, CTO at Qualys, follows with "CSRF is difficult ... and complex."
I must respectfully disagree, it's really not, but I'll discuss that in a minute.

I was pleased to run into Jeremiah Grossman at the ISSA International Conference last week, and he stated that CSRF has moved up on the imminently pending 10th WhiteHat Security Statistics Report. He was careful to pointy out however that its not because sites are more vulnerable to CSRF; rather, WhiteHat Security customers are more interested in having the issue reported combined with better Sentinel detection.
The point about better detection on WhiteHat's part ties back to my disagreement over the claim that CSRF is difficult and complex.
Exploiting CSRF is really not complicated at all, but it has been historically difficult to discover via automated scanning (sorry, Kevin ;-). There are nuances that require fairly significant manual interaction with a potentially vulnerable application; enumeration and parameter reconnaissance is required, followed by building forms specific to various POST requests. Consider Tamper Data your bff for this effort. Most importantly, noting the lack of a token/formkey/canary is generally the first, best step to determining CSRF vulnerability with targeted manipulation thereafter.

Of the 155 CSRF disclosures mentioned in Kelly's article for the first half of 2010, 14 are advisories I submitted through Secunia and are widely varied in their scope.
You'll note the expected vulnerable CMS platforms, but you'll also find HP printers, server logging agents, system management interfaces, and web mail providers.

My point is this, CSRF is not hard to find, is easy to exploit, and often remains unrepaired in web applications long after the other OWASP Top 10 biggies have been fixed.
Token up, people!

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Everybody Loves REMnux

A quick read of the SANS Forensics blog, courtesy of Gregory Pendergast, and you'll get a feel for all the positive feedback for Lenny Zeltser's REMnux.
Lenny has dedicated himself to furthering the malware reverse engineering cause, both as a teacher and analyst; his SANS courses are popular for good reason.

September's toolsmith covers REMnux and offers some detail specific to its use.

One area I often use REMnux for is malicious Flash analysis.
Evil Flash, distributed in particular via online advertising platforms, is a constant concern for online providers. Suffice it to say that my team has encountered such problem children more than once. ;-)
As an example, an older sample (MD5: 525445764564B34070CF2F9DCC6C2DAA) makes for a great test case. You can grab the sample for your own testing at OffensiveComputing.net.
Imagine you've grabbed the sample via wget from your REMnux VM, after proxy-based analysis of the malicious URL.
A simple check for interesting results might be the likes of
flasm 525445764564b34070cf2f9dcc6c2daa.swf, which would result in a .flm file named identically for SWF file analyzed. Figure 1 shows the concatenated results.


Figure 1

While flasm is convenient, the preferred method would be
swfdump -Ddu 525445764564b34070cf2f9dcc6c2daa.swf
The -D switch provides full (everything) output, the -d switch prints the hex output, and -u shows the Tag IDs.
Figure 2 offers the results.


Figure 2

Note that that the DEFINEBUTTON2 config for Tag ID 4 grabs an URL then issues the ActionScript FSCommand:exec to execute arquivo.scr (never a good thing).
Tag ID 4 was conveniently named "bot" by its creator; why bother hiding, right?

With a modicum of effort, maliciousness confirmed, you're ready to take action: report the malicious SWF to the provider, or remove it you are the provider.

You'll enjoy REMnux; it's an excellent collection of useful tools gathered in a simple but functional distro.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Is Zeus an APT, or v3?

I've given a few presentations this past year regarding security visualization where I have implied for all intents and purposes that Zeus (or Zbot) can be considered part of the advanced persistent threat (APT) picture.
As I prepared for the most recent presentation to the ISSA Puget Sound chapter meeting I contemplated the premise of Zeus-as-APT a bit further, and also found myself amused by the implication that there was now a Zeus v3.

Let me first debunk the v3 claims.
The Zeus hype over the last few weeks has been off the charts given a brilliant marketing campaign from M86 who, in their latest white paper, have gone so far as to refer to certain Zeus variants as Zeus v3.
Quite simply, I disagree.
The M86 white paper states that "Zbot/Zeus v3 version is an evolved mutation of Zbot 2. Unlike the older version, this one focused specifically on online banking."
If this is the basis for declaring the samples analyzed for this white paper as v3 I must cry foul.
As an example, Figure 1 includes content from a Zeus v1 (yes v1, not even v2) config file that clearly targets online banking, specifically Wells Fargo. The MD5 hash for this sample is 3cfc97f88e7b24d3ceecd4ba7054e138 if you wish to confirm for yourself.


Figure 1

The Zeus version transition from v1 to v2 was born of the inclusion of code signing, advanced encryption methods, and licensing (one install per registered user, please). Either way Zeus has long targeted online banking and does not warrant new version nomenclature on this premise alone. I'll grant that mutations and variations are rapid amongst Zeus samples, with particular goal of avoiding detection, but in my opinion it's still the same v2 code-base.

While a bit more difficult to de-obfuscate, a recent Zeus v2 sample showed clear signs of classic Zeus behavior and targeted a mass of online banking offerings.
Figure 2 offers a small subset of targeted institutions pulled directly from the config file.
The MD5 hash for this sample is d86ba734b30c650b091dd39e7707872c and you can pull the sample for your own analysis from ZeuS Tracker.


Figure 2

As per the "Is Zeus an APT?" question, I have mixed feelings here.
I've recently read two excellent discussions on the matter that offer slightly different perspectives.

In Dr. Eric Cole's Advanced Persistent Threat: The Insider Threat, posted to Dark Reading on Aug 16th, he is very precise in his definition of APT:
"The entry point with many attacks is focusing on convincing a user to click on a link. However, once the APT breaks into a system, it is very sophisticated in what it does and how it works. Signature analysis will be ineffective in protecting against it. Advanced attacks are always changing, recompiling on the fly, and utilizing encryption to avoid detection."

Gary Hoglund's The shadowy world of the advanced persistent threat and botnets, posted to SC Magazine on July 15 offers a slightly different take:
"…botnets traditionally were not associated with state-sponsored attacks (sometimes called advanced persistent threats, or APT). While that characterization may have worked five years ago, it is completely outmoded for today's threat landscape.  Botnets have evolved to become generic remote-access frameworks."

Dr. Cole further states that "stealth and being covert are the main goals of today's attacks. APT's goal is to look as close {if not identical} to legitimate traffic. The difference is so minor that many security devices cannot differentiate between them."

Zeus clearly communicates via "legitimate traffic", isn't noisy, and goes to great lengths to disguise itself.

Hoglund also points out that Zeus "has a plugin architecture, so any capability is possible. The base source code of Zeus readily is available, and attackers can easily customize the system for any purpose. There are hundreds of custom variations of Zeus in operation today.”

Following the sound logic from both of these gentlemen, Zeus is a bot used for APT-like attacks. While it may not often be used in very narrow, highly specific attacks (not to say that it isn't), it is certainly used in a very targeted fashion.
Attackers simply drop the C&C mechanism on hacked web server (see Figure 3), target a specific victim set, and collect data until shutdown, where after the move on.



This morning's RSS headlines included a most troubling reference from TrendMicro detailing Zeus being utilized for a deeply nefarious and specific purpose: targeting US military personnel bank accounts.
While this may be a broad victim audience, it's still targeted specifically to Bank of America Military banking users.

So is Zeus an APT? If not, it certainly partially qualifies; call it pseudo-APT.

Let me know what you think, of both the Zeus-as-APT debate as well as the M86-driven Zeus v3 ambiguity. Comments welcome.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Suricata in toolsmith: meet the meerkat

Rather than fan the Suricata versus Snort flames (you're both great kids and I love you equally) I'm opting for Swiss-like neutrality and simply invite you to explore Suricata at length.
See Victor Julien's post on the matter as he sums it up succinctly.
While I've always been a Snort user, I've also long been an ardent supporter of Matt Jonkman's Emerging Threats. Given his logical progression towards the Open Information Security Foundation (OISF), a "non-profit foundation organized to build a next generation IDS/IPS engine", I felt deeply obligated to cover Suricata in toolsmith.

Suricata: An Introduction is my effort to oblige.

While this article is painfully introductory, it should whet your appetite.
Suricata, as the "product" of OISF, is compelling on different fronts.

1) Intent: "OISF’s primary goal is to remain on the leading edge of open source IDS/IPS development, community needs and objectives."
As such, Suricata "is not intended to just replace or emulate the existing tools in the industry, but will bring new ideas and technologies to the field."
Committing to community needs and objectives, much as Emerging Threats has, is noble and valuable.

2) Scale: My testing on a dual core box matches Victor's assessment.
"Is Suricata faster than Snort on a single core cycle for cycle, tick for tick? No. But we scale. We’ve had reports of running on a 32 core box and scaling to use all cores. There Suricata is much faster."
I believe performance at scale is essential/vital/critical to IDS/IPS success in this burgeoning age of all things cloud and virtual (think complexity, and mondo network traffic). Groundbreaking thinking on my part, I know. ;-)
Consider that an unnamed military body has tested Suricata versus Snort on a large scale platform (24 processors and 128GB of RAM) and saw a very clear 6-fold speed increase over a tuned Snort implementation on the same platform.

3) HTP Library: In a context similar to all things cloud (online services), effective HTTP normalization and parsing is mighty important. Ivan Ristic's HTP Library endeavors to provide "very advanced processing of HTTP streams for Suricata."

4) Features: I'll let the comparison chart speak for itself.



Performance geeks will definitely want to explore the use of PF_RING and leveraging CUDA-capable hardware. The article clarifies these a bit more.

5) Same rules (Snort-based): Need I say more?

These should be ample reasons for you to give Suricata a really close look.
Deploy it.
Give it every opportunity to prove itself side by side with your current IDS/IPS solution.
Keep an eye on the project site, and get involved.
Start by downloading 1.0.1 here.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Verizon Data Breach Report & OWASP Top 10's #6

The fact that Computerworld's Jeremy Kirk just reported that data breaches are often caused by configuration errors (as noted in Verizon's latest data breach report) should come as no surprise, yet I'm left shaking my head in continued disbelief at this issue's prevalence.

Per Jeremy, as summarized from the report:
"Verizon said it found that a surprising and "even shocking" trend is continuing: There are fewer attacks that focus on a software vulnerabilities than attacks that focus on configuration weaknesses or sloppy coding of an application."

Now we now why security misconfiguration is new to the OWASP Top 10 as of 2010, holding the #6 position.
Consider Figure 1 as ripped right from the OWASP Top 10 doc.


Figure 1

Can we agree that data breach qualifies as a "business impact"?

A recent example of classic security misconfiguration includes the design flaw in WordPress that, by default, allowed users to set up permissions that let anyone read their blog's wp-config.php configuration file; WordPress stores the bloggers' credentials in plain text (also OWASP Top 10 A9).
An attacker could create a scanner to locate all configuration files containing incorrect permissions, read database credentials, and compromise all found.


Figure 2

So easily avoided.

OWASP's recommendations include:
1. A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Dev, QA, and production environments should all be configured the same. This process should be automated to minimize the effort required to setup a new secure environment.
2. A process for keeping abreast of and deploying all new software updates and patches in a timely manner to each deployed environment.
3. A strong network architecture that provides good separation and security between components. Consider running automated scans periodically to help you detect future misconfiguration or missing patches.

Make it so!

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

ISSA Members: Connect regarding IR in cloud & complex environments

If you're an ISSA member please feel free to join the conversation on ISSA Connect regarding incident response challenges in highly complex, massive network volume, and/or cloud environments.
This discussion sets up a presentation I'll be giving at the ISSA International Conference on September 17, 2010 in Atlanta. Hope to see you there.
I have recommendations regarding tooling and methodology that I'll be sharing at the conference, but I'm really interested in hearing about your experiences under similar circumstances. What's worked for you and what hasn't?
Folks working for sizable online service providers, ISPs, cloud or SaaS providers, and have had some noteworthy technical challenges or experiences, you're the folks I'd like to hear from.
If your not an ISSA member feel free to comment here or email me (russ at holisticinfosec dot org).

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Messenger Abuser Malware Tactics

A common trend I see in both research and job duties is the use of instant messaging services to propagate malware.
"OMG, Russ," you say, "groundbreaking!" I know, I know.
This is all about tactics and trends.
Pushing malware through URLs sent over instant messaging should surprise no one who spends anytime in the infosec space, but once in awhile I spot persistent methods that are, if nothing else, relentless in their pursuit of victims.
You know the vector. A URL pops up in the IM client, victim clicks, off to the races.

With the vast popularity of social networking services, one obvious trait includes Facebook-oriented nomenclature where a URL and attacker domain might include the likes of hxxp://www.facebook.otsima.com/facebook_gallery.php?img=DSC004075208450.JPG.
"Look, Ma! It's from my Facebook friend! It's gotta be safe!" Uh-huh.
What's been interesting lately has been the number of executables that are named as image files; most often JPG as seen above.
Said sample above is Backdoor.Win32.Gootkit.

Another one following this pattern lately was found at hxxp://www.e-egypt.net/watch.php?=FOTO3436812.JPG.
A recent sweep for the string as part of this analysis found it referenced in the following:
hxxp://www.fuckyoutube.org/watch.php?=FOTO3436812.JPG (suspended)
hxxp://www.imagewhat.com/pictures/watch.php?=FOTO3436812.JPG (suspended)
Inevitably, they're served from a hacked server too, as seen on e-egypt.net; when explored at it's root offers Figure 1.


Figure 1

The binary disguised (thinly) as FOTO3436812.JPG is an unspectacular IRC bot with a tenacious master, given the numerous URL variants pointing to the same sample.
A quick run through ye olde sandbox produces a PCAP and behavioral analysis that indicates classic IRC behavior; again, very typical stuff known in some circles as the LolBot. But the bad guy (or so it seems) was nice enough to leave his "Facebook badge" on the server that the initially executed package calls home to for additional downloads. One directory jump up from where said additional download resides and you have Figure 2 (anonymized to protect the miscreant).


Figure 2

Nice, nothing like putting a face with your malware. ;-)

How about the endless VBTrojan malware served up with a bit of Brazilian (calls home to 200.98.197.93) spice via the file name MsnWebcawOnFiles1634.com (see the trend?):
http://msnfiles-webshow.serveftp.com
http://webmsn-fileshowrum.serveftp.com
http://webcawmsn-showrum.serveftp.com
The strings references include "desconhecido" ("unknown" or "strange" in Portuguese) and C:\Arquivos de programas. ;-) Beware the arquivos!

My favorite of late has been this one pushed behind a TinyURL.
This one was pretty good and there's very little detection for the binary yet.
The shortened version:
hxxp://www.tinyurl.com/DSC488398JPG (I love the DSC nomenclature like it just came off a phone or digital camera).
Redirect is to hxxp://03161b8.netsolhost.com/index.html, but the catch here is that index.html is actually the binary.
I have to say, I hadn't seen that one used before in this context. The trickery is improving.
But alas, it's still just an IRC bot:
NICK new[USA|XP]8092826
USER s "" "lol" :s
:001 irc.priv8irc9.com
Remember I mentioned the LolBot above with regard to a different sample?
Give it a few days. Once the detection is up to speed for this variant I'm reasonably certain we'll see it classified as Lol/Buzus/Panadol.
I'll take bets: the hash for index.html is 2B4B55CE4A991DBD9600246C7F9E080D.
We'll see if my neanderthal-like ability to spot trends holds water. ;-)

Like I said, what's old is new again. But maybe, just maybe, you learned something useful reading this far.

Sorry it's been a few weeks...busy, busy.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

CSRF flaws that pack a punch

Note: These findings were responsibly disclosed and vendor updates have been issued.
See the eBbox Platform advisory here and the Snare advisory here.

A year after DEFCON 17, cross-site request forgery (still one of my favorite bugs) continues to present itself in some mighty interesting places.
I've already talked about it in the likes of wireless routers, UPS units, and a variety of web apps.
But it gets more sketchy when the vulnerable application gives up the keys to the castle via CSRF.
I don't mean just admin rights to the app, I mean compromise leading to control of the OS or platform itself.
Before I go into detail please know that both vendors in question responded instantly, provided fix time-lines, and met them precisely with corrective updates.
Two cases in point, keeping in mind that CSRF is often referred to as the one-click attack.
First, eBox Platform.
eBox Platform describes itself as a catchall that can act as a Gateway, Infrastructure Manager, Unified Threat Manager, Office Server, Unified Communication Server or a combination of them. One single, easy-to-use platform to manage all your network services.
Er, or one really broad attack surface.
Give away all that power to one tiny code snippet.


Figure 1

Failure to tokenize requests to the application means successful compromise with one errant victim click. Sending a halt order as seen in Figure is but a pittance as any request submitted via the browser-driven web management interface can be maliciously manipulated.
Preventing this attack clearly should be prioritized by developers; CSRF is number six in the OWASP Top 10 for a reason.

Next on our list: Snare from InterSect Alliance.
From their website: Snare for provides front end filtering, remote control, and remote distribution for audit log and event log data.
One agent to rule them all; one CRSF bug to rule all agents.
Meh.
Even though the web app for the Snare client can be configured with a password and localhost restrictions, an attacker need only convince a victim to click a link; it's simple GET request CSRF to finish the job.
http://192.168.248.231:6161/setremote?str_RestrictIP=192.168.248.235&dw_Password=on&str_Password=password&dw_PortChange=on&dw_WebPort=84
This request resets the password and the port, restricts IP access as well (in case you couldn't tell ;-)) and, as an example, via Snare for Windows, allowing the attacker to dump local users, domain users, registry, etc. On the likes of an AIX system add "remote control, and remote distribution for AIX audit data, interfacing with the underlying AIX audit subsystem as a custom stream object."
Scary.

eBox has issued the following fixes:
The problem can be corrected by upgrading your system to the
following package versions:

eBox Platform 1.4:
ebox 1.4.7-0ubuntu1~ppa1~hardy1
libebox 1.4.5-0ubuntu1~ppa1~hardy1
ebox-remoteservices 1.4.7-0ubuntu1~ppa1~hardy1

Snare has issued the following fixes:
SnareWindows - 3.1.8
SnareWindowsVista - 1.1.5
SnareAIX - 1.5.1
SnareIrix - 1.4.1
SnareSolaris - 3.2.4
EpilogWindows - 1.5.4
EpilogUNIX - 1.3

Typical recommendations apply.
For system owners, be on the lookout for vulnerabilities of this nature as you make use of convenient web-based system management interfaces such as eBox and Snare.

For vendors, make use of SDL or SDLC methods, and mitigate these risks in advance of release.

Convenience and efficiency are critical to success in enterprise computing environments, but with great power comes great responsibility. ;-)
Cheers.

ADMIN Magazine article: Splendid Splunk

Approximately twice a year I write for Linux Magazine; I've covered nUbuntu, Adeona, and Security Visualization in previous articles.
When the editor asked me to participate in a system administration special edition I was intrigued as the edition was to be OS agnostic and include Linux, Windows, OpenSolaris, and others.
I didn't have to think for more than a minute to come up with a good security topic for system administrators.
Any of you readers work in hybrid operating environments where you're inevitably challenged to unify event monitoring and correlation with disparate systems?
I for one can answer that question in teh affirmative and am always seeking ways to answer that challenge.
Merging security and operational mindsets is essential when unifying events in hybrid environments and I have found Splunk to be incredibly useful as part of the effort.
Note: I wrote this article with no influence or feedback from Splunk (they'll learn of it here too) to avoid bias.
Splendid Splunk: Unifying Events with Splunk is the result of much testing and research to prove out methodology I've only implemented in part prior.
For security events, when an enterprise may not have budget for SEM/SIEM, the likes of Splunk fills the gap admirably. Yes, it's a commercial tool, but one can do a great deal with the community version to confirm my findings.

An excerpt:

Systems administrators, security engineers, and analysts share a common challenge in typical enterprise environments. Rare is the data center in which only one operating system is in use, or only one version of the same operating system. Monitoring and managing system events and security events across such hybrid environments is no small feat...choices need to be made when unifying events in a hybrid environment. For example, perhaps you have more of one operating system flavor than another in your environment. Or, perhaps you prefer one operating system over another.
No matter what your system counts, preferences, or comfort zones, Splunk can serve you well...to monitor your systems you can choose to use various channels in concert or exclusively:
• Both host types can also run Splunk as a light-forwarding agent.
• Windows and *nix hosts can also be monitored with Snare agents.
• Windows and *nix hosts can be monitored with OSSEC agents.
• Network devices can send syslog output directly to the Splunk server.
Depending on granularity, performance, and primary business driver, you can opt for some or all of the above. Personally, I tend to favor a combination of the Splunk light-forwarding method in concert with OSSEC agents, and syslog for network devices...

I cover methodology, installation, forwarding, Snare, OSSEC, searches dashboards, and alerting.
While there's a book's worth of Splunk use to write about, the article is intended to help you get a good running start.

ADMIN Magazine is available via subscription (quarterly with DVDs), single issue purchases online, or at magazine stands in the likes Barnes and Noble.

If the article is ever posted to the web by the publisher I'll update this post and let you know.
That said, the publication is well worth the coin as it covers network security, system management, troubleshooting, performance tuning, virtualization, and cloud computing.
Happy reading; let me know if you have questions.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Book Review: ModSecurity Handbook

In January I reviewed Magnus Mischel's ModSecurity 2.5.
While Magnus' work is admirable, I'd be remiss in my duties were I not to review Ivan Ristic's ModSecurity Handbook.
Published as the inaugural offering from Ristic's own Feisty Duck publishing, the ModSecurity Handbook is an important read for ModSecurity fans and new users alike. Need I remind you, Ristic developed ModSecurity, the original web application firewall, in 2002 and remains involved in the project to this day.
This book is a living entity as it is continually updated digitally; your purchase includes 1 year of digital updates. Ristic also wants to know what you think and will incorporate updates and feedback if relevant.

While the ModSecurity Handbook covers v2.5 and beyond, Ristic's is "the only ModSecurity book on the market that provides comprehensive coverage of all features, including those features that are only available in the development repository."
ModSecurity Handbook offers detailed technical guidance and is rules-centric in its approach including configuration, writing, rules sets, and Lua. Your purchase even includes a digital-only ModSecurity Rule Writing Workshop.

Chapter 10 is dedicated to performance as proper tuning is essential to success with ModSecurity without web application performance degradation.
That said, the highlight of this excellent read for your reviewer was Chapter 8, covering Persistent Storage.
ModSecurity persistent storage is, for all intents and purposes, a free-form database that helps you:
• Track IP address and session activity, attack, and anomaly scores
• Track user behavior over a long period of time
• Monitor for session issues including hijacking, inactivity timeouts and absolute life span
• Detect denial of service and brute force attacks
• Implement periodic alerting

Following the applied persistence model, I found periodic alerting most interesting and useful. From pg. 126, "Periodic alerting is a technique useful in the cases when it is enough to see one alert about a particular situation, and when further events would only create clutter. You can implement periodic alerting to work once per IP address, session, URL, or even an entire application."
This is the ModSecurity equivalent of a Snort IDS rule header pass action useful when internal vulnerability scanners might cause an excess of alerts.
ModSecurity rules that perform passive vulnerability scanning might detect traces of vulnerabilities in output, and alert on them. Periodic alerting would thus only alert once when configured accordingly.
As an example, perhaps you are aware of minor issues that are important to be aware of, but do not require an alert on every web server hit.
Making use of the GLOBAL collection, ModSecurity Handbook's example would translate the scenario above by following a chained rule match and defining a variable, thus telling you if an alert has fired in a previously. The presence of the variable indicates that an alert shouldn’t fire again for a rule-defined period of time. In concert with expiration and counter resets it is ensured that a rule will warn you only once in a your preferred period of time but still log as you see fit too.
Useful, right?

ModSecurity Handbook, in concert with Ristic's Apache Security, are must reads for web application security administrators and architects, but will not leave those who need step-by-step instructions at a loss.
Trust me when I say, all you need to harden your web presence with ModSecurity is at your fingertips with the ModSecurity Handbook.

Cheers and happy reading.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Web Security Tools²: skipfish and iScanner

June's toolsmith in the ISSA Journal covers skipfish and iScanner.

Skipfish and iScanner, albeit quite different, are both definite additions for your toolkits.
Reduction of web application security flaws as well as the identification and removal of obfuscated malcode are important ongoing processes as part of your proactive and reactive defensive measures.

Skipfish is an “active web application security reconnaissance tool that prepares an interactive sitemap for the targeted site by carrying out a recursive crawl and dictionary-based probes.”

iScanner is a Ruby-based tool that “detects and removes malicious code and webpages malware from your website with automated ease. iScanner will not only show you the infected files from your server but it’s also able to clean these files by removing the malware code from the infected files.”

The article awaits your review here.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

CSRF: Six Degrees of Kevin Beaver (or at least his printer)

Perhaps you followed the CSRF debate between RSnake and Kevin Beaver last month.
While I fall well on Robert's side of the tracks, Kevin made some interesting points.
I may take issue with some of them (ok, almost all of them) but Robert took him to task, and I'm pretty sure Kevin has done his penance ;-), so no need to beat that dead horse.
Except that scanner comment. Scanners <> CSRF detection; it's a largely manual check, and it actually does exist significantly more often than you might think (pretty much everywhere). Watch your Tamper Data or Burp sessions for requests made without tokens/formkeys/canaries, etc. and you'll soon know what I mean. There is no "high-quality vulnerability scanner" that will solve the CSRF challenge for you.

No matter your view or perspective, CSRF is pervasive, annoying to fix, and still lurking everywhere; it can be used to pwnzor your printer, your APC UPS, your website's shopping cart or CMS, or any other damned thing you expose to the Intarwebs that fails to check "exposure to unintended requests."
What value these targets? Depends on your motive.
Stealing printer resources? Probably not. ;-)
But a CSRF attack against a website operator who's using the likes of osCommerce, Zen Cart, or eclime (15 million+ at last check) and is foolish enough to be using one of them to manage credit card data? Game over.

Heck, CSRF vulns are so widespread that we could rate number 5 on the OWASP Top 10 like a video game...Rated E for Everyone, just like your Mom. Ohhh!

When I popped my new HP Photosmart C4700 on my home network and changed the admin password via CSRF with twenty second's worth of HTML, it all came to a head.
How do you patch that?
Vendors like HP and APC, who are extremely responsive to disclosures, no matter how low hanging the fruit, still can't easily update their software and expect all customers to apply the fix.
Then there all the vendors who do nothing (you know who you are).
Good code and responsible vendors are paramount, but so too is consumer awareness and understanding of risk.
What if a properly targeted "one click" attack turns off the power outlets on a UPS device with a hospital's ICU servers connected to it?
Is life in the balance?
Our "mysterious" web bug changes the nature of that very question.
Overly dramatic, sure, but you get the point.
Who'd be to blame under those circumstances?

So what's the solution (write secure code)?
I recognize that I'm asking more questions than providing answers (write secure code), but I'm at a loss as to how to solve poor coding practices easily (write secure code). Perhaps you, dear reader, have some ideas (write secure code).

Maybe RSnake should just CSRF Kevin Beaver's printer, force it to print a bunch of copies of OWASP's Development Guide, and we'll call it good. ;-)

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Memory forensics with SIFT 2.0, Volatility, and PTK

May's toolsmith takes a close look at SIFT 2.0, the forensics workstation associated with the SANS 508 track.



SIFT 2.0 is best utilized as a VM via your preferred version of VMWare but can also be installed as a permanent standalone workstation.
I spend much of time touting memory analysis as a key component of incident response and forensics, and SIFT 2.0 offers two of the most capable memory analysis offerings available: Volatility and PTK. As I say in the article, I don't do either tool the justice it deserves but it should whet your appetite. I owe both Volatility and PTK their own write-ups, if not the MoonSols Memory Toolkit as well.
Regardless, SIFT 2.0 is extremely practical for forensic processing and case management. Assuming you have a decent storage footprint, you can opt to keep a unique virtual instance of SIFT for each case your handling.
For this article I used SIFT with Volatility and PTK to dig more deeply into a victim memory image of a Banload-infected host.
You'll quickly see how to get right to the bottom of an incident using only memory analysis.
The article is here.

Cheers and and enjoy.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)