Hackers Buy Ads to Install Malware

Last month, I was contacted by a client to help resolve some security issues on her website (brabbly.com) When I visited the site, there did not seem to be any underlying issues, except for multiple pop ups, which I thought were legitimate ads from the site.

However, I was wrong. On talking to the owner, I found out that the site does not have any ads enabled on the backend. Therefore, I though of the usual culprit; using a nulled theme.

But then again, she swore that she was using a clean them from MyThemeshop.

With the possibility of using a nulled theme out of the way, I set up to investigate. I randomly looked at the code of about 10 sample pages.  The pages did not seem to have anything. The content was okay, just discussing things such as no bounce sports bras, big boob problems, best bra for neck and shoulder pain, and other related topics. It’s a blog about women lingerie.

Well, since the theme wasn’t nulled and the site didn’t appear to be hacked, what could be the problem?

Read on to find out.

I have been waiting for this is happen for a while now. Jeremiah and I discussed this about a year ago while thinking about the fastest way to deploy malware across the web. Our idea was slightly different but the same principles apply, buy your way on to the big sites with ads or convince a site to install a widget/JS snippet.

In this attack the malware distributors purchased ad space on the doubleclick network, uploaded encrypted flash ads that then did drive by malware installs. Here is a video that shows what happens when one of these banners is displayed and attempts to install malware.

This is a very interesting attack but here is what a lot of people fail to realize. Ads, widgets, flash etc are all programs that execute in your browser. Once I source code from another source (like the youtube movie above) I have given up control of my webpage to a third party. Youtube could change that code to do something completely different tomorrow and the only recourse I have is to notice it and remove the code from my site. While removing the code that calls the YouTube video will remove the attack vector from my site, I (really my users) where exposed for the time it was available.The malware people are already thinking about this as well. As demonstrated in the video above, they are not attempting to infect everyone all the time but do it to some people some of the time. Pretty tricky eh?I fear this is only going to get worse. Hold on to your seats, it is going to get bumpy.

The Business Case for WAFs + Testing

Who’s up for another IT security story? I’m was sitting on my Xrocker wondering whether I should get back on Call of Duty or type something quick for this week. I opted for the latter and this is why you are reading this post.

Here is a real world story about a customer of ours, this was a few years ago and was one of the key points in bringing the F5/Mod_security/WhiteHat integrated solution to market.

This customer had a massive application written in ASP classic. Since it was in ASP classic it had massive numbers of SQLi vulnerabilities. Everything from Blind SQLi to the always fun SQL statements in the URL. The customer said this application was roughly 250,000 lines of code with SQL hardcoded throughout. The reason the customer had called WhiteHat is because they where working on a big deal with a potential client and this client was asking for a security report on the application. They where also in the early phases of rewriting the application in .NET (yeah) with an estimated completion date 1.5 years out.

After seeing our report (100+ SQLi and 300+ XSS) and after a protracted developer battle(yes XSS is not good) they where left with two not good options.

  1. Lose the customer.
  2. Stop the rewrite and spend a few months digging through old code to fix these issues

Now from a business point of view neither of those makes sense. At the time we where in the WAF hater camp but we saw that in this case it made total sense. The customer deployed a WAF, configured it using our vulnerability data, and was able to mitigate the risk in about 3 weeks.

Bottom line and what people continually fail it understand is that every current solution on the market today has its short comings. In security everything does. Is there one magic network solution that will prevent all network attacks? No. You have spent a ton of money protecting your network infrastructure. Let’s take a quick look at the list of things you probably have spent money on today:

  1. Firewalls
  2. IDS/IPS
  3. Network Vulnerability Scanning
  4. AntiVirus
  5. Configuration and Patch Management
  6. Database Scanning
  7. Database Encryption

Guess what, none of that protects you from the rush of SQLi, XSS, and other web based attacks. All that money and you still have big gaping holes.

To properly attack the Web Application Security problem you should be doing all of these things:

  1. Secure coding practices
  2. Source code review
  3. Black box testing
  4. Web Application Firewalls
  5. Developer Training
  6. Configuration and change management

The reality today is that people underestimate the size of the problem and therefore do not have the budget to do all these things. You can stretch those budget dollars pretty far with an open source scanner and mod_security (software cost $0). WhiteHat is not that cheap but we are very cost effective, combined with mod_security you can go a long way. Need a more robust solution, WhiteHat + F5 can scale to 1000 of web sites in a very cost effective manner. WhiteHat and our WAF partners can knock items 3-5 off your list while you go work on getting your coding practices in place. Even after you get those practices in place you are still going to find vulnerabilities and having that “instant” mitigation ability is very comforting.

Robert over at cgisec sees the light as well. He has managed and is currently managing web site security for some of the largest most frequently attacked web sites on the planet.

These are the crazy people in your security neighborhood – Part 2 Private Pyle

When you have been around the IT/Security space as long as I have you run into to a lot of whacky people. After a while you begin sorting and classifying them into nice convenient stereotypes. Over the next few weeks I will post my own stereotypes that I have discovered. Hope you get a laugh and figure out where you fit in. The Professional Conclusion is what to do if you are another security professional, the Vendor Conclusion is how you should deal with them if you are trying to sell them something.

Private Pyle started out in some backwater town in eastern Oklahoma before he joined the military to get the heck out of there.

private pyle

Once in the military someone figured out that this dude could add and plug in cables and they put him in the IT group. There he plugged in routers in places like Dubai and Kuwait. If it was in 2016, I’d bet he’d also have plugged in his a 3D printer like Dremel (check Dremel 3d40 review).

One time he saw a Pix firewall and that landed on his resume. He then gets sucked into AFCERT at some point and proceeds to write approximately 9000 proceed and policy manuals. Kicks out of .mil land and finds out that TS clearance he has is worth $$$$$ with all the private .gov contractors out there. Usually then will embed themselves into the belly of a contracting firm and never leave. Every once in a while the smart ones escape and end up in the private sector. Once they do they are generally mellow and easy going. They love building stuff. Got a firewall with extra blinky lights? Sold! IDS with a neural network learning computer? He will take 12! Got services? Unless you are part of the military industrial complex, you have the chips stacked against you.

Professional Conclusion: Typically laid back and mellow. Most are pretty sedate. Think Al Gore but they might actually know what TCP/IP is.

Vendor Conclusion: See above, blinky lights, outrageous promises sold!

Part 3 – The Techno Weenie

Source Mentioned: https://www.3dtechvalley.com

Alumnus hacks Texas A&M system

My dad is a Aggie, sorry to see his school can’t secure their systems. If anyone is from Texas they know that the Aggie’s are the butt of many jokes. (Think Polish jokes, Texas style). One of my favorites:

How do you confuse an Aggie?

Put him in a round room and tell him to pee in the corner.

Bu dum bump, I am here all week folks!

I have grown somewhat numb to yet another college getting broken into. Sadly I think the security teams at these places are in a no-win situation. A culture of openness + lots of kids + lots of juicy PII and CC data = many places to fall over and leak data. Maybe RIAA can’t stop wasting time with P2P witch hunts and let the security people at these institutes of higher learning get back to securing the information of the students and faculty. Oh I can dream…

I recently dug my archives and found a story that was fascinating more than a decade ago. Below is an excerpt:

Alumnus hacks Texas A&M system: “A recent graduate of Texas A&M University is charged with hacking into the school’s computer system and illegally accessing information on 88,000 current and former students, faculty and staff members.

Luis Castillo must appear before a magistrate judge Wednesday.”

By the way, if you wondering what happened to the student, let’s just say your guess is as good as mine. Nowadays, rather than chase these small kids trying to hack into school systems, I spend my time restoring websites that have been hacked. Like this one of a client who writes MDF stethoscope review articles. It’s a funny world; how much 10 years can bring a difference in someone’s career.

Sources Mentioned: https://www.nurselly.com/mdf-stethoscope-reviews/

SANS says the #1 Server Security Issue is Your Web Application

The latest SANS Top 20 has been released and according to SANS the #1 issue impacting the security of your servers is the web application code that lives on top of it.

I agree with them (in a totally biased way of course) but the data they cite leaves me with an uneasy feeling. SANS likes to go by reported vulnerabilities. Reporting of web application vulnerabilities is basically non-existent outside of open source PHP applications. Every once in a while you will see a reported vulnerability in something like PeopleSoft or MS Sharepoint but a large percentage of the reported web application vulnerabilities are in things like Jim Bob’s PHP Guestbook 0.00001alpha and really who cares about that.

PHP include issues are most certainly bad but they are far from the most prevalent issue found in large enterprises. In our customer base we only have 22 PHP sites we scan out of around 650 sites today. There is just not a lot of PHP adoption in the enterprise, at least in our customer base.

So while I agree with the conclusion I feel leary about how it was reached.

The Big Announcement

I’ve not been this pumped about something in a long time. Jeremiah actually has been pulling me into liking this idea for a very long time. I hated it at first. I mean WAFs, bleh. Plus I mean didn’t we already try scanners + WAFs before? Oh yeah the total trainwreck that was AVDL. So one thing I failed to realize was that Jeremiah’s approach is a bit different and when combined with WhiteHat Sentinel (aka NOT a scanner) it is a no brainer.

WAFs generally struggle in a few different areas, the people running them are not web app. security experts and trying to apply a default deny policy, while a great idea in theory, is pretty hard in the real world . There is just way to much movement in most applications to pin it down. Even if the app does not change frequently, WAF admins are very hesitant to even come close to blocking legitimate traffic. This is what was happening on this site that covers EMT stethoscopes, nursing stethoscopes, nursing student stethoscopes and general stethoscope reviews.

What really sold me though is when I saw it in action for the first time. From the Sentinel UI we clicked a button that updated the F5 with a rule to block a vulnerability. The rule is automatically generated based on the vulnerability. We then clicked the retest button and the vulnerability was no longer exploitable . Note my careful choice of words, exploitable VS. “not there anymore”. The vulnerability certainly still exist in the code but now that the attack is blocked the business can decide if this is a good enough solution or they need to go fix the actual flaw.

The geek in me is screaming that it still needs to be fixed, the business side is saying that the rule is good enough and I am not going to commit resources to fixing it until that code is worked on again. From the PCI Section 6.6 perspective this gives the business some great options. As our customers are becoming aware of the PCI requirements and the PCI auditors are becoming tougher on web application vulnerabilities we run into a difficult situation. PCI audit is coming up and the app. is riddled with vulnerabilities.  I now have to dedicate precious development resources to fix these vulnerabilities ASAP. With this solution I can apply this rules and effectively mitigate the issue.

I am pretty excited to be part of this. I think we have moved the industry forward today, even if it was just a small step. People now have some more options to mitigate risk besides running to the development team with yet another fire.

Source Mentioned: Best Stethoscope

FBI CSRF and Jail How to Get Someone Raided

This seems pretty scary. Apparently the FBI posted a link on some online forum that claimed to display kiddy porn. The story is here.

Upon reading this the first thing that popped into my mind was CSRF(Cross Site Request Forgery) Now this is not classic CSRF since CSRF generally implies I am exercising some functionality on the target site. I am using CSRF as a handy term for “if you visit a page I control content on I can make you request any other link I want”. Now remeber this is not only pages like this blog where I clearly control the content, but any other place I can provide links, usually to images. Social networking sites, forums, image hosting sites and even in email signatures.

This is an even better scam than the now famous 911 swatting scams. Now instead of SWAT busting in to rescue you the FBI bust in to arrest you. What great fun! It will be interesting to see how many of these stick. It seems to be based on some pretty flimsy evidenc. The article above points out that open wireless networks are just one way someone could fool the system. CSRF is better because your browser will actually go to the page and a forensics examination of your machine will show that you went there. Not a good position to be in in court with a jury and often times judge with no technical background at all.

Update from my buddy Zeno: The file that keeps track of places IE has been, index.dat, does not log refers and apparently that file and it’s contents have held up in court…

Free Dr. Pepper Overloads Site, Exposes Captcha Key

I love Dr. Pepper. So when then announced they where giving it away for free I was all over it.

Sadly though the site was not up to the task and was continually failing in new and wonderful ways. Everything from Service Unavailable to this piece of code poo:

Start ‘, gmdate(”F j, Y, g:i:s a T”, $start_time), ‘
Now ‘, gmdate(”F j, Y, g:i:s a T”, time()), ‘
End ‘, gmdate(”F j, Y, g:i:s a T”, $end_time), ‘
Time From Start ‘, $g_nTimeToStart, ‘ (H:’,$g_nHoursFromStart,’ M:’,$g_nMinutesFromStart,’ S:’,$g_nSecondsFromStart,’)’, ‘
Time Until End ‘, $g_nTimeToEnd, ‘ (H:’,$g_nHoursToEnd,’ M:’,$g_nMinutesToEnd,’ S:’,$g_nSecondsToEnd,’)’, $g_bSwitch? ‘
‘; exit(); } require_once(’recaptchalib.php’); include “account/process_user.php”; // Get a key from http://recaptcha.net/api/getkey $publickey = “6Lcp6AMAAAAAACdUl5_X5cbuQLzgWMMRHlb3MbwV”; $privatekey = “6Lcp6AMAAAAAAGR1pjoXN2dLHg9sVIKmBR-XXXX”; ?>

Hey cool a private key (I changed it above)! It looks like to goes to ReCaptcha so I hop on over to the ReCaptcha site to find out how bad this is. I found this;

Signing up for a reCAPTCHA Key

In order to use reCAPTCHA, you need a public/private API key pair. This key pair helps to prevent an attack where somebody hosts a reCAPTCHA on their website, collects answers from their visitors and submits the answers to your site. You can sign up for a key on the reCAPTCHA Administration Portal.

So if you where paying attention you can now crack Dr. Peppers ReCaptcha all day long. This is not the end of the world but I am sure some spammer somewhere is already on in and doing something not good.

This is a great example of the type of things missed when you are only looking one piece of the app. sec. problem.  This could have been prevented with an egress filter of some sort or better load a failure testing in QA. It looks like the folks at Dr Pepper are doing neither.

And I never did get my free Dr. Pepper!!