Grumpy Security Guy

5 Security Predictions for 2018

July 16, 2017 Web Site SecurityBill PenningtonLeave a comment

1. We will see the first multi-website XSS worm.

I think we will finally get a true cross site XSS work in 2008. Combining XSRFand XSS to propagate a worm across multiple sites and multiple domains. The first one will be benign but the others will be much more malicious in nature. Leading victim candidate are social network sites that are becoming increasingly open.

2. More consolidation in the security industry.

There is still a great difference between the small security players and the giant ones in terms of cash flow. As the old guard (McaFee, Symantec, etc) see dwindling revenue on various fronts they will begin to convert some of that pesky cash into acquisitions. Could this be the year Qualys gets gobbled up?

3. PCI will clarify section 6.6

This is more of a hope really. Since it goes into full effect mid-2008 I hope to see some clearer definitions around what companies are expected to do.

4. 2008 will set another record for breaches

Yeah big shocker! The trend will continue with more smaller breaches this year as opposed to a few massive ones.

5. RBN will disappear again. Someone related to them will get busted.

With the light too bright they will morph again and change tactics. Money will still flow in to them by the millions though. However with increasing public knowledge of the group someone will get busted and connected to them. No one high up in the group, but some poor sucker at the wrong place at the wrong time. Law Enforcement will trump it as a “significant” blow to the group. RBN won’t notice.

The Big Announcement

June 21, 2017 Web Site SecurityBill PenningtonLeave a comment

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

April 2, 2017 Web Site SecurityBill PenningtonLeave a comment

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…

Bots + Web Vulnerabilites – An Approaching Storm

March 12, 2017 Web Site SecurityBill PenningtonLeave a comment

I called this one the day after the first wave of mass SQL Injection attacks came out. I told Jeremiah that we would see botnets doing this attack shortly as it was much more efficient.  A few weeks later and boom, Botnets performing mass SQL Injection.

The interesting things about these attacks so far is what they are actually doing. They are not attempting to steal data out of these databases directly, they are populating the pages with links that attempt to do drive by malware installs by exploiting browser vulnerabilities. It was pretty successful but SQL Injection is a  vulnerability  that is on the decline (and will decline even more after this attack). I begin thinking about vulnerabilities that would do the same thing but have a much broader reach.

Our good friends XSS and CSRF.

So here is the attack.

  1. Find a few permanent XSS vulnerabilities in some high traffic sites.
  2. Find some CRSF vulns in popular blog and forum software.
  3. Craft your payload.
  4. Profit!

So the bot software basically sits back and waits until the computer it is on visits a vulnerable site and then places it payload in the vulnerable spot. It could of course do this without you visiting a site with a little more coding to check if you are permanently logged in.

Considering the number of sites with XSS and CSRF this attack would dwarf the current SQL Injection attack happening today.

When ISPs Attack!

February 5, 2017 Web Site SecurityBill PenningtonLeave a comment

Here is a scary story about a company, Nebuad (no link juice for you!) that performs a MITM attack all in the name of better ads. Now sniffing to get better data on your customers has been around for a while. In fact I worked at a company that did this as part of our offering. Where NebuAd goes over the line is they manipulate the traffic to get their ad code in the mix.

But Free Press and Public Knowledge found that sometimes when a WOW subscriber visited Yahoo or Google, NebuAd faked an additional packet of data that appears to be the last part of the downloaded Google webpage. The extra packet included NebuAd-written JavaScript that directs users’ browsers to a NebuAd-owned domain named faireagle.com, where the company drops tracking cookies from other domains and companies on the user’s computer. These can be used later to deliver customized ads based off analysis of where people have gone on the web or what search terms they have used.

Cool so not only are they sniffing traffic they are now inject JavaScript and making it appear to originate from Google. This technique is the same one used by the ever popular and super fun Airpwn. Now what would happen if NebuAds servers where compromised? The ultimate JS malware distrubution platform would be born!

Link

Free Dr. Pepper Overloads Site, Exposes Captcha Key

January 12, 2017 Web Site SecurityBill PenningtonLeave a comment

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? ‘
SWITCH
‘:’
NO SWITCH
‘; 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!!