I would also assume that spam is probably still being pushed out of the zombies as well, but I haven’t really done any investigations into this, so I can’t say for sure.  From what I have gathered from other security folks is that the global spam trackers haven’t really seen an impact yet.  I guess only time will tell what the next step is for the Waledac authors and how they plan to deal with this beheading.

I applaud their efforts with this take down and now only time will tell if their strategy will have lasting impacts on this menace of a botnet.  Waledac is a peer-to-peer botnet, so simply taking out command and control servers would not have a lasting impact and the botnet would quickly recover.  By taking down the botnet at the domain (“.com”) level the individual peers within the botnet will no longer receive peering list updates, command and control instructions, and spam templates, but Waledac is resilient by design so additional actions have to occur for this take down to be completely successful and/or lasting.

The group and/or groups behind Waledac are most likely still scrambling to understand what occurred and where they went wrong, but with ties to the extinct “Storm Worm” of the past and the Zeus Trojan which has recently made the news headlines it is doubtful this will end their criminal efforts.  Time will only tell us what the groups next move will be and with that I guess I will have to find another botnet to monitor, so I will be on the look out.

KUDOS to Microsoft and the behind the scene folks within the security community that aided in this effort!

This announcement marked the start for what I would call one of the best open to everyone security communities online today.  Soon Emerging Threats picked up the support for the Bleeding Edge rules, Replicating the Bleeding Rulesets, and reopened the mailing lists for the community to participate in Matt’s new vision of a completely grant funded project.  Matt’s vision has lead to numerous other projects being hosted and/or sponsored by Emerging Threats.  These projects capture the creativity of some well known security community contributors such as William Metcalf, David Glosser, Victor Julien, James McQuaid, and many others.  I would definitely recommend anyone reading this post to take a serious look at these projects, as they are always looking for help and input to make them better.  Another great source for information regarding Emerging Threats snort rules and projects is the wiki, which houses a collaborative environment in which anyone that chooses to do so can provide comments and feedback regarding individual snort rules.

The Emerging Threats mailing lists are always active and some of the best community contributing snort signature writers out there participate on a daily basis.  This mailing list is not like several other mailing lists out there where a “n00b” (newbie) has to fear of being flamed by the guru’s on the list.  Instead beginners questions are answered in a professional and helpful manner providing for a very open and friendly collaborative environment.  I have seen situations arise from time to time where someone or some company representative has posted negative remarks regarding certain rulesets and/or specific signatures, but all of these situations were handled with professionalism.  Many times the answers to these complaints contain apologies and responsive corrections to errors or mishaps in a very short time frame.  Other times these posts are answered with requests for suggestions from the poster and community on how they can be corrected.  You really can’t ask for more than that from a project that is offering it’s services free of charge for all of us to benefit from where we see fit.  Warning the following is a rant so skip to the next paragraph if you don’t like to read rants!  I have had the pleasure of working for a very large organization for the last few years and during this time I have also had the pleasure of evaluating and demoing a wide range of IDS/IPS commercial solutions and/or products.  During these evaluations and demos I have heard from several sales guys, and their sales engineers that the Emerging Threats rulesets are terrible and how their in house developed rulesets do a better job of protecting you from malicious code and zero day attacks.  Now being a contributing community member of Emerging Threats this really hits me in the gut, so of course I begin to dive into these so called optimized and efficient rulesets and I bet you can guess what I find.  I find snort rules written with PCRE’s that contain no content anchor, Domain Name content matches, and in some cases reused Emerging Threat rules with a new message of course.  Now, this is not the case for all vendors or commercial products for which I have had the pleasure of evaluating or coming in to contact with, so don’t take this the wrong way.  I just hate hearing how terrible something is when in fact the Emerging Threats rulesets contain some of the best signatures for malicious code and zero day attacks available to the public.  Just a suggestion to any vendor, company, sales guy, and/or sales engineer in the business please stop spreading this non-sense, as it only discredits your professionalism and makes me question your knowledge in the area of IDS/IPS technology.  Ok, the rant has ended!

Matt’s successful leadership, persistence, and expert guidance over his vision at Emerging Threats has also lead to him starting another project that appears to be kicking off with a great start with the help of government sponsorship and funding “Open Information Security Foundation” (OISF).  According to the FAQ’s at OISF: “The OISF was formed primarily to begin the development of this new IDS/IPS engine, but will over time take on new projects and challenges. The OISF can be a home to any interested project in need of funding and long term support” (What is OISF?).  This project really appears to have the beginnings and community participation to reshape what we consider an IDS/IPS engine to be with numerous creative and innovative visions contributed by the community: “Proposed Features for the Engine and the OISF Wiki“.  I would recommend anyone reading this post with an interest in IDS/IPS technology to sign up and participate in this project, as they too just like Emerging Threats are always looking for help and/or feedback that will make the project better.

I would like to personally extend a “THANK YOU” out to Matt and the members of the Emerging Threats community.  Matt, if we are ever in the same place at the same time I owe you a beer!  Thanks again for the hard work, and I wish you and your projects nothing but success.

I do not see any exploit code or iframe re-directions on the current page, but of course this could easily change at anytime.  Without the exploits or iframe re-directions to awaiting exploit packs, a victim of Waledac will have to execute the binary all by themselves.  This new binary comes with no real Antivirus Detection with Virus Total results like this: Result: 4/41 (9.76%).  I am sure once the Antivirus companies realize what is going on this will improve, but until then we must rely on the education of our users and hopefully some good software installation restrictions and policies to prevent this for now.

Don’t be a victim and have a “Happy 4th of July”!

I have personally been forced to take several of Brainbench’s assessment tests during both the interviewing process and continual certification processes that Brainbench offers for a fee to companies looking to evaluate, assess, and/or validate future and current employee’s skill sets.  Here is a direct quote from Brainbench’s website:

Brainbench, a PreVisor company, has served over 5,000 corporate and 6 million individual customers. The company was founded in January 1998 with the same mission it has today: Delivering easy-to-use assessment products that predict success on the job.

Here are some statistics, again copied directly from their website:

Number of Brainbench customers serviced in the US: Over 4,000

Number of countries where Brainbench has tested people: Over 120

Average Small Business Sale: $6000; 2 week sales cycle

Average Mid-Size Business Sale: $20,000; 4 week sales cycle

Average Large Business Sale: $120,000+, 10 week sales cycle

Brainbench customer renewal rate: 85%

Average renewal contract value: 140%

So as you can see they really appear to take pride in their ability to provide corporations and individuals with assessments that can aid in selecting the right candidate for a position or validate a current employee’s skill set.  This is why I could not comprehend their actions or lack of actions when I attempted to contact them in regards to this issue, which defeats their assessment engines validity.  Well I think I have provided enough background details and such, so lets get to the meat and potatoes of the issue at hand.

JavaScript injection is a simple technique that can be utilized to manipulate client side rendering and code, HTML forms, cookies, and/or  just about any parameter on a web page after it has been rendered by the browser.  To perform this type of attack all that is needed is a web browser and the address/location bar built into all web browsers.  To perform this attack all that is done is the clearing of the address/location bar and entering in JavaScript functions and/or code in it’s place.  A sample alert message can be rendered on any page by clearing the address/location bar and adding in this code:

javascript:alert(“Hello World!”);

JavaScript injections conducted in the address/location bar must always be started off with “javascript:”, but several commands and or code segments can be entered into the address/location bar by ending each one with a “;” to terminate each section and/or segment.  A really nice write up on JavaScript injections with some really cool functions can be found here: “How to Use Javascript Injections“.

It is clear that JavaScript executed in the address/location bar isn’t really a bug or security vulnerability by itself, as it can only be seen on the client side, but it can be utilized to perform some interesting things and/or actions such as web form manipulation and parameter modifications.  This is why no one should ever trust inputs from a client and JavaScript validation by itself is just not enough to secure your data.  Server side validation must occur for every single input received from the client to ensure it is valid and safe to process.

Brainbench’s assessment engine relies solely on a JavaScript function to process a test/assessment takers time spent on each question.  This time is normally restricted to 3 minutes or 180 seconds, which sounds like a pretty nifty feature to ensure test/assessment takers are answering questions based off knowledge.  Given more time a test/assessment taker could easily Google the answer or even reference a book for the correct answer, which sort of defeats the purpose of the assessment.  So let us take a little journey into this JavaScript code utilized by Brainbench’s assessment engine, and see if you can’t spot the issue before you get to me just spelling it out for you.  Here is the function in question:

function TimerFunc()
{
if( !doTimer )
return;

tf = window.setTimeout( “TimerFunc();” , 1000 );
tcount++;
timeLeft = 180 – tcount;
minutes = 0;
seconds = 0;

if( timeLeft > 0 )
{
minutes = Math.round( ( timeLeft / 60 ) – 0.5 );
seconds = timeLeft – 60*minutes;
if( minutes > 0 )
{
document.qform.timerbox.value = minutes + ‘ Min. ‘ + seconds + ‘ Sec. Remaining’;
}
else
{
document.qform.timerbox.value = seconds + ” Seconds Remaining”;
}
}
else
document.qform.timerbox.value = “Time Expired”;
// window.status = timeLeft + ” ” + “Seconds Remaining”;
// document.qform.timerbox.value = timeLeft + ” ” + “Seconds Remaining”;

if( timeLeft == 30 )
{
doWarning();
}

if( timeLeft <= 30 )
{
document.qform.timerbox.className = “timertextboxred”;
}

if( timeLeft <= 25 )
{
doWarningOver();
}

if( timeLeft == 0 )
{
window.clearTimeout( tf );
timeUp = 1;
document.qform.nextitem.disabled=true;
document.qform.submit();
}
}

This function is called by another JavaScript function:

function doOnload()
{
if( resetVals )
{
setem();
}

if( doTimer )
{
tf = window.setTimeout( ‘TimerFunc()’ , 1000 );
}
}

This “doOnload()” JavaScript function is called using the HTML event “onload” when the web page is first loaded with this code:

<body topmargin=”15″ leftmargin=”15″ onload=”doOnload(); ” bgcolor=”#ffffff” marginheight=”15″ marginwidth=”15″>

Now is the issue or vulnerability at hand apparent yet?  I can think of a few ways to defeat this code, but I am only going to demonstrate one very simple and straight forward method for “Stopping” and “Starting” the timer at will.  To stop the timer simply copy and paste the following code into the address/location bar of your browser and hit the “enter” or “return” key while you are taking the assessment/test and the timer will stop:

javascript:void(doTimer=false);doOnload();

To start the timer back up simply change the “false” parameter to “true” and hit “enter” or “return” to execute the code once again.  Like magic the timer will start up again where it left off.

Very simple right?  So what harm does something like this do?  Well your not going to get “root” or “own” Brainbench, but now how valid are these assessments and/or exams?  By stopping the timer at will a test/assessment taker can easily go look up the answer to a question he or she has absolutely no knowledge of, and score a perfect score in areas that the test/assessment taker has no knowledge of.  This completely defeats the validity of the assessment, and now these certifications and/or assessment results can no longer be trusted.  Now if I was an organization reading this article and utilizing these assessments I would immediately contact my sales representative and pose the same question, but hey that is just me.  If I took pride in holding these certifications and paid to take these assessments, I would also call or email Brainbench to pose this question to them as well.  This really hurts and/or questions the overall validity of these assessments and certifications.  Maybe if enough people and/or organizations seek out Brainbench’s response and/or support in regards to this matter it can be fixed quickly.

So how can they fix this?  Simply validate or remove the client side “timer” input variable.  Removing it would ensure the timer variable has no impact on the actual exam time and/or timer.  To validate the timer a server side function and/or timer to compare with could be utilized.  The visual timer makes for a good reference for the test/assessment taker, and should not be removed in my opinion, just don’t trust it to be accurate.  Removing the “doTimer” variable would be a good idea as well, since I really can’t come up with a valid reason for having this functionality or variable.  Just start the timer and let it run, no need to check if the timer should be running when a test/assessment taker is actually taking the exam.  I could be wrong here since I didn’t write the code, but then again I could be right too.

Just as a historical reference since I am optimistic that Brainbench will fix this issue in the near future I have recorded a video demonstrating that this vulnerability really did work, and as of today still works.

Thanks Bob for the screen shot and the information!

Interesting enough this theme is very similar to the “Couponizer Theme” we saw in late February, as it is a spoof from a legitimate company’s web site.  The image and theme are based off the SPY-SMS website, which appears to offer mobile phone spy software.

I pulled a few interesting statistics from my database and thought I would share them with everyone.  Over the last 30 days the Waledac Botnet infections appear to be very steady or normalized, as there are very little differences in the number of new infections found by my Waledac Tracker scripts depicted here:

New Infections By IP Count Last 30 Days

In comparison here is a table of the most active days by new IP counts:

Most Active Days By New IP Counts

Another interesting statistic I pulled was the number of unique binary names seen every day for the last 15 days:

Unique Binary Name Counts for Last 15 Days

As you can see these stats look fairly normalized or evenly distributed.  As a comparison here is the top five dates with counts for the number of unique binary names seen in one day:

Top 5 Dates By Unique Binary Name Counts

As you can see the “Couponizer Theme” campaign during the end of February consisted of a larger variation of binary names, when compared to the last two campaigns.

The last statistic I am going to post is the number of IPs that were last seen by my Waledac Tracking scripts in the month of April.

Number of IPs By Last Seen Date Counts for April

For a comparison here are the most active last seen days in my database.

Most Active Last Seen Dates By IP Count

Looking at this last table I would assume that during the end of January and beginning of February the Waledac Binary was well detected by Antivirus Companies, as it looks like a number of systems were cleaned up during that time period.  Now these statistics may or may not show the true depiction of the Waledac Bots, as I am crawling the Bots that have public IP addresses and not the Spamming Bots with NATed IP addresses.

Another interesting touch are the two non malicious web links at the bottom of web page.  One leads to the “Dirty Bomb” wikipedia page and the other leads to Google search results pertaining to “Your GeoIP City” and the key words “Terror Attack”.  The normal iframe hidden link can still be found in all the Waledac web pages I viewed.  The common URL structure for this iframe right now is http://xxxxxx/tds/Sah7 , so some simple URL filtering or logging with your proxies may help to identify users that have visited a Waledac web page and possibly received some malicious exploit attempts passed through this hidden iframe.

If anyone is interested in just how well the Antivirus Companies are doing in keeping up with the Waledac Authors and polymorphic packer here are a few links to VirusTotal’s Static file scan results for some of my recently collected binaries:

• Result: 8/39 (20.51%)
• Result: 6/39 (15.38%)
• Result: 7/39 (17.95%)
• Result: 6/39 (15.38%)
• Result: 6/39 (15.38%)
• Result: 6/39 (15.38%)
• Result: 6/39 (15.38%)
• Result: 6/39 (15.38%)
• Result: 6/39 (15.38%)
• Result: 10/39 (25.64%)
• Result: 6/39 (15.38%)

Not looking all that good, if you ask me.

Anyways let me provide you all with a snapshot of the current web page template, so that we can send out our administrative spam warning our users not to download and install anything from a site that looks like this:

So as we can see the theme is not lacking in professionalism.  The major dead give away for this template and many of the other Waledac Trojan templates is that every item on the page is really an image.  There is really no real text, unless you count the unseen “iframe” lurking behind the scenes hosting several well structured exploits and redirections.  Back to the images, all of the images on the page are hyperlinked to a binary file, so this again is a dead give away.  We should warn our users to never install executable content from websites like this.  Hey better yet, why are we still allowing our users to install binaries anyways?  You know that if we followed the hundreds if not thousands of hardening guides found all over the Internet I am sure one of the first steps found in almost everyone of them is to remove administrator rights  from normal usage accounts and create a software distribution and installation policy.  So why are campaigns like this still so effective?  Most likely because we know what the right thing is to do, but many times there are roadblocks in the way that prevent us from implementing policies like these.  On that note, if the DOD can force you to glue your USB ports with some sort of Epoxy I would venture to say removing administrator rights from your users should be an easy accomplishment.  Now if your part of the DOD don’t go sending missiles to my house as this was just an observation, and no pun intended.

It also looks like the polymorphic generation of the Waledac binaries and the rotation of binary names we have seen since the 6th of February, which may I add was exactly 2 days after I posted that the update cycle for the Waledac binaries appeared to be ~15 hours (shame on me), is still well on it’s way to causing the best of the best Antivirus Companies and Malware detection companies to stay up late at night or just give up all together.  I definitively do not fault the Antivirus industry for this poor detection rate, as how do you create static file signatures on something that is constantly changing?  The fault of successful malware campaigns such as Waledac should lie directly on the shoulders of the system security plan authors, ITSMs, CTOs, and security professionals chartered with securing computers and networks.  Stopping Waledac is almost trivial if you will put into place a good patch management system, and take away administrative rights for general usage accounts.  Teach those that require administrative rights such as system administrators to use the “run as” functionality in Windows, it is there for a reason.  Stop making excuses on why you can’t do these things, and just do it.  I am sure you will feel the pains that all of us that have already removed our users administrator rights have felt in dealing with users that believe they need to run their daily accounts as an administrator.  Nobody said computer and network security was an easy task, so lets just buckle down and fix the fundamental issue here instead of blaming others for our problems such as the Antivirus industry.  Hmm, that sounded like a “rant”…

In the mean time if you can’t pull administrative rights feel free to utilize the Waledac Tracker on my site to put into place content filters, DNS blackholing, Firewall rules, and IDS/IPS signatures to match on content downloads or IP addresses.  I don’t think this is an effective solution, but hey sometimes you just have to make due with what you got.  On that note I have been supplying one of my favorite projects “EmergingThreats.net” IP addresses from my Waledac Tracker for IP addresses that have demonstrated some sort of activity in the last 72 hours.  Matt has put into place a mechanism to update his compromised host ruleset with these IP addresses every 24 hours, so you may want to take advantage of this and start using this projects rulesets if you don’t already.  EmergingThreats.net has come along way over the last few years, and I can say from personal experience in the IDS world their rulesets do a very good job at detecting botnets, and other malicious content that can’t be seen when only running the Snort.org VRT rulesets.  Nothing wrong with the VRT ruleset either, so I would recommend running both of these rulesets and updating constantly.

As always feel free to contact me if you have any questions or comments.

UPDATE: 22 Feb 2009 ~6:00 PM CST (GMT-6)

Much to my surprise there is a legitimate “Couponizer.com” site in which the Waledac Authors stole their latest theme from.  Give it a look-see here: The Couponizer.  I just sent the admin contact for “The Couponizer.com” website a short note letting them know their reputation is being tarnished as we speak.  Not much they can do about it except maybe put out the standard news release stating they have no involvement with the Waledac Trojan.

So how often does the binary change?
I created a new table view into my database just to answer this question (Waledac Update Cycle).  This new view displays only binaries (distinct MD5 sums) that have been seen more than once to eliminate the inclusion of the corrupted binary downloads performed by my Waledac tracking scripts.  Here is a snapshot of the table for reference:

The table is pretty self explanatory, and the key column is the last column.  This Lifetime column shows in Hours:Minutes:Seconds how long a Waledac Binary has been in place.  With the default sort applied to the Last Seen column you can also visually see the approximate time a new binary was pushed out by the Waledac authors.  So back to the original question what is the average update cycle for Waledac binaries?  Averaging the the last column I came up with 15 Hours, 48 Minutes, and 21 Seconds.  Obviously this is not an exact calculation in that I am not retrieving a new Waledac binary every second of the day, but it does provide a fairly decent approximation.

I was also hoping this new view may have been able to identify a pattern in the binary update times as well, but I do not really see a clear pattern other than the authors seem to prefer evening updates over morning updates in the CST timezone.  This isn’t always the case though, as there are several binary updates that occurred during the morning hours as well.  Maybe over a longer period of time a pattern will surface, who knows.  Since there is no apparent pattern or single hour in which the updates occur I would venture to say that the binary updates are being performed manually by the authors.  I venture to say this in that if the authors had a script or cron job scheduled performing these updates for them on a regular bases the updates would most likely occur at the same time everyday.  This is not the case, so I would assume they are performing the updates manually.

As always feel free to comment or suggest new view points into my data, as I am always interested in hearing how this data can be improved upon or viewed in a new an interesting way.

The first relationship I took a look at was IP addresses -> Name Servers -> Domain Names.  The density of red nodes for each clover visually depicts the number of IP addresses associated with a specific Waledac domain name.  The density of red nodes for each leaf in the clovers depicts the number of IP addresses associated to a specific Name Server within that Waledac domain.  As you can see some Waledac Domain names are more popular than others.  Another interesting characteristic demonstrated by this graph is that there are some Name Servers that are a little more popular than others for a few domain name’s being utilized by Waledac, but overall IP addresses within each domain appear to be fairly evenly distributed between Name Servers.  The last characteristic I would like to point out is that the blue rectangles depict the Name Servers within each domain name, and if you count them their are exactly 6 Name Servers for every Waledac domain name.

The next view I looked at was the reverse of the previous view: Domain Name -> Name Server -> IP.  This should result in about the same overall graph, but it reverses the colors and clearly demonstrates that there are in fact 6 Name Servers for every Domain Name.  The Blue rectangles are the Waledac Name Servers and by reversing the colors the IPs are now in a neutral color making the Name Servers easier to count.

The next data set relationship I looked at was IP -> ASN -> Country.  The higher density of red nodes in a clover represents a larger number of IPs seen in a particular country.  If you focus in on the individual clovers the density of red nodes in relation to the density of blue rectangles depicts the number of IPs seen per ASN.  If nothing else, this graph represents another view point into the Waledac botnet IP distribution per ASN and Country.

Now lets take a look inside of some of the more popular Waledac domain names according to my Waledac Tracker data set in the relationship of Domain Name -> Name Server -> IP Addresses.  The next three graphs are ordered by domain names: yourregards.com, yourchristmaslights.com, and newlifeyearsite.com.  When I pulled these data sets they were the top 3 domain names based off IP address counts.  The interesting visual correlation that can be seen within these graphs are the number of IP addresses in relation to each Name Server for that domain.  The larger the red circle the more IP addresses are associated with a name server, which makes it easy to see that it had appeared with the above clover leaf clusters that the IPs were evenly distributed when in fact there are some differences.

yourregards.com

yourchristmaslights.com

newlifeyearsite.com

This last graph I generated really does not mean a whole lot per say, but I think it looked pretty interesting so I went ahead and posted it for your viewing pleasure.  Its relation is based off my binary tracking scripts that retrieve Waledac binaries every 30 minutes: Binary Name -> IP.  Again not real meaningfull, but it sure looks cool.

Well I hope you enjoyed the graphs, and as always if you have any questions or comments feel free to either leave them here via a comment or email me anytime.

Share/Bookmark]]> http://www.sudosecure.net/archives/429/feed 1