Thursday, July 29, 2010

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. | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Wednesday, July 28, 2010

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. | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Monday, July 19, 2010

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://
"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://
A recent sweep for the string as part of this analysis found it referenced in the following:
hxxp:// (suspended)
hxxp:// (suspended)
Inevitably, they're served from a hacked server too, as seen on; 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 spice via the file name (see the trend?):
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:// (I love the DSC nomenclature like it just came off a phone or digital camera).
Redirect is to hxxp://, 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

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. | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)