Daniel B. Cid

Daniel is the Founder & CTO of Sucuri and also the founder of the open source project - OSSEC HIDS. His interests range from intrusion detection, log analysis (log-based intrusion detection), web-based malware research and secure development.

Vulnerability Disclosures – A Note To Developers

This post is entirely for developers. Feel free to read, but approach it with that in mind.

There is no such thing as bug-free code. We all make mistakes and every piece of software will have issues that we did not anticipate. We ourselves find weaknesses in our code, and have to work extra hard to stay ahead of the issues. The same applies to every other company out there.

However, some of these bugs may have security implications that can affect the integrity, availability or confidentiality of the users deploying it. They are called software vulnerabilities.

I think it’s fair to assume that we can all relate with this to some level. What seems to be a problem however is how we, using the collective we, handle the disclosure of these vulnerabilities when brought to our attention.

  • What happens when someone identifies a vulnerability in the code we write?
  • What if it can or is being misused to hack websites that employ that same code?
  • How should we as developers respond and handle these situations?

I want to share some thoughts that I hope will provide some insights on a good disclosure and engagement strategy.

Accounting for Vulnerability Disclosures

If you are a builder and are shipping code the first thing you should plan for is a method to allow security researchers to contact you. This is first and foremost; you want to encourage folks to review your work and contact you if anything is found. You don’t have to set up a bug-bounty program or anything too formal, but at least some method to ensure that you get notified immediately of issues. We should all want to know if there is serious problem with our code.

Here are 6 steps we encourage every builder take into consideration when an if a vulnerability disclosure occurs:

1. Do Not Panic

Take a deep breathe. Everyone makes mistakes and this is likely not the end of the world. It may seem like a big deal and you may get worried that you will lose business and the trust from your users. However, if you deal with the disclosure properly, it may actually have the reverse effect and you may actually gain their trust from this experience.

I think as humans we have a predisposition for jumping straight to the negative. I’m going to lose business!! I’m going to go out of business!! We should flip this mindset to one that is more approachable, What can I learn from this? You’re in essence getting a free security review; this is a positive thing and you want to encourage an open dialog with the researchers.

2. Acknowledge.

As soon as you get the notification, let the reporter know that you have received the notification and are looking into it. We sometimes fail to realize how important this small step can be.

In the business of disclosures, it’s not uncommon for organizations to shun researchers away, and over time it’s built a culture of distrust; forcing them to believe the organization doesn’t care. This reduces the tolerance for lack of acknowledgement and can often lead to bad outcomes for everyone involved.

A simple, Thank you so much, we’re looking into this and will get back to you within X hours will pay you huge dividends.

3. Do Your Homework.

Take all the information provided by the researcher and try to confirm the issue. If you can’t reproduce the issue, don’t jump the gun and tell them they are wrong, instead ask for something known as Proof of Concept (PoC). Remember, this researcher is taking time out of their day to report something to you to help you, attacking them or blowing them off will do little in your favour.

Once the PoC is provided, you should work to provide the researcher a timeline. In the world we live in today, with web applications, timelines that extend beyond 2 weeks really aren’t acceptable. If you must extend beyond that, be sure to communicate with the researcher on the reasons behind the delay.

The pressure to release sooner will honestly be determined by its severity, ease of exploitation and impact to the larger audience.

4. Patch It!

Please patch the problem effectively. One common mistake is to patch it where it was identified, but leave it susceptible in other parts of your code. Don’t be lazy.

Take the time to review the rest of your code for similar issues. There is nothing that will hurt you more, than to have a similar vulnerability found a week later, but on another part of your code.

5. Coordinated Disclosure

Before you release the patch, involve the researcher. Send the fixed version to the researcher, ask them to review, engage them in the process and watch it pay you dividends. They will often go above and beyond to help you think through the problem, and will help built a rapport. Once this is done, you have to plan a release – there really isn’t a way around this, especially for severe vulnerabilities.

Let the researcher know when you plan to release. Work a coordinated disclosure release schedule, most researchers love to identify problems but also love to write and share about their findings.

A good email to the researcher would be:

I will be publishing a patch on DAY X at Y time (GTM). I will follow the release with a blog post of my own shortly and will email all my clients. Can you wait 24 hours for your own disclosure? I Want my users to hear from me first.

This is a very acceptable email and most reasonable researchers will understand and respect your request. Please do not do a silent release – a silent release is a release where you avoid any mention of the vulnerability in the hopes that no one will ever find out. The researcher is likely monitoring all patches, and if they see you do this without any proper disclosure they are bound to call you on this act, publicly.

When writing a blog post (and in the release notes), you should explain what happened, the severity, who reported the issue to you and what you did to fix it. Provide links for the patch and a timeline if possible. Your users will appreciate and trust you more when you do this. Again, do not try to hide if it is a security issue. The idea that by not sharing you don’t have to worry about it being exploited is an antiquated way of thinking. An attacker worth their salt, can run a diff and see the issue right away; not saying anything does not solve the problem.

6. The Backlash.

This seems to be the biggest fear most builders have. What will my community think? What will clients think? Will my company survive?

These are normal feelings, we can assure you though this will pass. In many instances, buyers will gain renewed faith in your product once they see how well you responded.

The core of your message should be: Yes, an issue was found, but more importantly this is what we learned and what we’re doing moving forward to make sure it never happens again.

Example of Good Disclosure

Remember, no one is perfect and with time, any product may have a security vulnerability discovered. I want to leave you with a good example from the JetPack team. They recently handled a vulnerability disclosure and did so brilliantly in our eyes: http://jetpack.me/2014/04/10/jetpack-security-update/.

They patched the issue right away and notified everyone, including hosts and partners about the problem. Even provided detection rules that security operators could use to detect and block a possible exploit.

Your Turn

I welcome thought and opinions in the comments, and if something makes sense we’ll address it accordingly. As mentioned before, this was drafted to provide you some thoughts and guidance, not dictate. Yet, we hope you find it helpful.

Zero-day in the Fancybox-for-WordPress Plugin

Update: We posted an analysis of the vulnerability following this post.

Our research team was alerted to a possible malware outbreak affecting many WordPress websites. All the infections had a similar malicious iframe from “203koko” injected into the website. We were also directed to a forum thread where users were sharing their concerns and describing similar issues they were experiencing.

In analyzing the infected websites, we found that all the websites were using the fancybox-for-wordpress plugin.

Zero day in fancybox-for-wordpress

The fancybox-for-wordpress plugin is a popular WordPress plugin with more than 550,000 downloads. There doesn’t appear to be any public vulnerabilities being reported, which piqued our interest. To understand how it was connected, we decided to do our own code / vulnerability review.

After some analysis, we can confirm that this plugin has a serious vulnerability that allows for malware (or any random script/content) to be added to the vulnerable site. Because it is currently unpatched, we will not disclose more information.

What makes things worse, is that it’s being actively exploited in the wild, leading to many compromised websites.

We could confirm via our Website Firewall logs by seeing many exploit attempts blocked.

This is what the attacks looks like:

46.4.76.174 – – [04/Feb/2015:00:25:09 -0500] “POST /wp-admin/admin-post.php?page=fancybox-for-wordpress HTTP/1.1″ 403 4207
INPUTBODY:action=update&mfbfw%5Bext.. malware payload hidden

Remove this plugin Immediately!

The plugin was just removed by the WordPress.org team from their repository and you need to remove it from your site as well! If you require it for specific features you really need to look at deploying alternative security solutions to help protect your website and block exploit attempts.

Users of our Website Firewall are already protected, but if you do not employ a similar service and leverage this plugin consider yourself highly vulnerable and high risk of compromise.

We will post more details about this vulnerability once we have given time for everyone to patch (when it becomes available).

Special thanks to Konstantin Kovshenin and Gennady Kovshenin for notifying and working with us on this issue.

DDoS from China – Facebook, WordPress and Twitter Users Receiving Sucuri Error Pages

Over the past few weeks, our Security Operation Center (SOC) has been seeing some different, and very suspicious requests to some of our servers. At first we thought it was a Distributed Denial of Service (DDoS) attack, mainly due to the high concentration of requests (thousands per second). Looking further however, it actually seemed like some DNS resolver was broken and redirecting all their users traffic to us.

Here are some example requests, see for yourself:

GET /100004020560199/picture HTTP/1.1
Host: graph.facebook.com

or

GET /extstyle.css HTTP/1.1
Host: static.ak.facebook.com
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36

or

GET /wp-content/themes/vip/nesn/images/nesn_favicon_128.png
Host: s0.wp.com

If you do not understand why these requests are interesting, look at the Host: header. It means someone tried to visit static.ak.facebook.com or s0.wp.com and somehow reached our servers. Since we do not host Facebook or WordPress.com, it generates an error on our end.

These were not the only domains that were trying to reach us. Just in the last day, we received requests for: farm4.static.flickr.com, 24.media.tumblr.com, cdn11.optimecdn.com, l.longtailvideo.com, platform.twitter.com, media-cdn.tripadvisor.com, analytics.twitter.com, m.facebook.com, graph.facebook.com, assets.zendesk.com and many other domains.

Why is Facebook, Twitter, WordPress and Zendesk pointing to Sucuri’s Website Firewall (CloudProxy)?

That was a little mystery that took us a bit of time to understand. At first, we thought it was just a new form of DDoS trying to use random domains names to evade our detection.

However, the request headers looked very legitimate. Even via passive fingerprinting, we were able to properly tie the operating system, to the browser and the user agent. It also didn’t look like a DDoS botnet that we could identify. To our surprise, it seemed like real browser requests from valid users.

There was just one catch: all requests were coming from China.

We shared our logs and finding with multiple peers in the security community and the consensus was that these requests were not malicious per se. It seemed as if the Great Chinese Firewall was mis-configured, instead of blocking the requests to certain sites, it was redirecting, to us at that.

So if a specific site was blocked, the requests to graph.facebook.com also got blocked and redirected to us. Same for Twitter, Zendesk or media.tumblr.com.

This explains why most of the requests were actually for CDN, images or API files.

Why is the Chinese Firewall doing that?

That’s a good question and one we do not know the answer to. We can speculate that it is a bug on their end, but can’t be sure. It actually seems similar to the issue that TorrentFreak reported with Pirate bay requests being redirected to random IP addresses.

However, instead of Pirate Bay, it is happening with the most popular platforms and CDNs out there to some of our IP addresses. These “fake” attempts generate thousands of requests per second from thousands of different Chinese IP addresses. It would certainly be enough to DDoS most servers.

Is anyone else seeing something similar?

Full list of domains

If anyone is curious, these are all the domains that reached us just today:


host: “10.media.tumblr.com”,
host: “11.media.tumblr.com”,
host: “12.media.tumblr.com”,
host: “13c3a.http.cdn.softlayer.net”,
host: “15.media.tumblr.com”,
host: “16.media.tumblr.com”,
host: “17.media.tumblr.com”,
host: “18.media.tumblr.com”,
host: “1.media.tumblr.com”,
host: “20.media.tumblr.com”,
host: “22.media.tumblr.com”,
host: “23.media.tumblr.com”,
host: “24.media.tumblr.com”,
host: “26.media.tumblr.com”,
host: “28.media.tumblr.com”,
host: “29.media.tumblr.com”,
host: “2.bp.blogspot.com”,
host: “2-edge-chat.facebook.com”,
host: “2.media.tumblr.com”,
host: “30.media.tumblr.com”,
host: “3-edge-chat.facebook.com”,
host: “3.media.tumblr.com”,
host: “4.media.tumblr.com”,
host: “5.media.tumblr.com”,
host: “6.media.tumblr.com”,
host: “7.media.tumblr.com”,
host: “8.media.tumblr.com”,
host: “987hh.com-www.45878.com”,
host: “9.media.tumblr.com”,
host: “a1.dspnimg.com”,
host: “a248.e.akamai.net”,
host: “a4.ec-images.myspacecdn.com”,
host: “abs.twimg.com”,
host: “accounts.youtube.com”,
host: “ad-audit.tubemogul.com”,
host: “a.deviantart.net”,
host: “adn.6638.edgecastcdn.net”,
host: “ads.exoclick.com”,
host: “ads.gayfriendfinder.com”,
host: “ads.w55c.net”,
host: “am.6park.com”,
host: “analytics.twitter.com”,
host: “api.facebook.com”,
host: “apis.google.com”,
host: “api.twitter.com”,
host: “apps.facebook.com”,
host: “assets1.whicdn.com”,
host: “assets2.whicdn.com”,
host: “assets3.whicdn.com”,
host: “assets.crucial.com”,
host: “assets.mltd.com”,
host: “assets.modelmayhem.com”,
host: “assets.zendesk.com”,
host: “badge.facebook.com”,
host: “banners.videosecrets.com”,
host: “bbc6.global.ssl.fastly.net”,
host: “blogs.ocweekly.com”,
host: “bp0.blogger.com”,
host: “b.s-static.ak.facebook.com”,
host: “cache.armorgames.com”,
host: “cache.blogads.com”,
host: “cdn03.cdn.justjaredjr.com”,
host: “cdn11.optimecdn.com”,
host: “cdn1.barong.inxy-host.com”,
host: “cdn1.editmysite.com”,
host: “cdn1.nudevector.com”,
host: “cdn1.sidhe.co.nz”,
host: “cdn2.editmysite.com”,
host: “cdn2.search.xxx”,
host: “cdn3.aptoide.com”,
host: “cdn3.everyjoe.com”,
host: “cdn3.howtogeek.com”,
host: “cdn5.howtogeek.com”,
host: “cdn.adgear.com”,
host: “cdn.androidcommunity.com”,
host: “cdn.api.twitter.com”,
host: “cdn.collider.com”,
host: “cdn.c.photoshelter.com”,
host: “cdn.easyhotpics.com”,
host: “cdnedge.vinsolutions.com”,
host: “cdn.epom.com”,
host: “cdn.everyjoe.com”,
host: “cdn-frm-sg.wargaming.net”,
host: “cdn.gayboysbox.com”,
host: “cdn.gaycnn.com”,
host: “cdn.gaydudestube.net”,
host: “cdn.gq.com.tw.s3-ap-northeast-1.amazonaws.com”,
host: “cdng.vpnpie.biz”,
host: “cdnimages.gayhits.com”,
host: “cdn-images.mailchimp.com”,
host: “cdn.lfstmedia.com”,
host: “cdn-marketools.plus500.com”,
host: “cdn-mkt.wooga.com”,
host: “cdn.nitrome.com”,
host: “cdn.nudevector.com”,
host: “cdn.porn-lab.com”,
host: “cdn.pornvideospider.com”,
host: “cdn.ps.teenmodels.com”,
host: “cdn.recruitnet.co”,
host: “cdn.sidhe.co.nz”,
host: “cdn.slashgear.com”,
host: “cdn.soundstagedirect.com”,
host: “cdn.tubeporndiet.com”,
host: “cdn.usablenet.com”,
host: “cdn.xgaybox.com”,
host: “cms.myspacecdn.com”,
host: “cn.epochtimes.com”,
host: “cn.wsj.com”,
host: “comps.fotosearch.com”,
host: “content.onhotels.com”,
host: “css.c.photoshelter.com”,
host: “csync.flickr.com”,
host: “cti.w55c.net”,
host: “dc108.4shared.com”,
host: “dc200.4shared.com”,
host: “dc204.4shared.com”,
host: “dc205.4shared.com”,
host: “dc219.4shared.com”,
host: “dc265.4shared.com”,
host: “dc317.4shared.com”,
host: “dc327.4shared.com”,
host: “dc335.4shared.com”,
host: “dc644.4shared.com”,
host: “dc672.4shared.com”,
host: “dc733.4shared.com”,
host: “dingo.care2.com”,
host: “dl6.offercdn.com”,
host: “dl-web.dropbox.com”,
host: “docs.google.com”,
host: “drive.google.com”,
host: “e1.static.hoptopboy.com”,
host: “ecdn.liveclicker.net”,
host: “eg-img.agoda.net”,
host: “eg.img.agoda.net”,
host: “emoneycreater.appspot.com”,
host: “farm1.static.flickr.com”,
host: “farm2.static.flickr.com”,
host: “farm3.static.flickr.com”,
host: “farm4.static.flickr.com”,
host: “farm5.static.flickr.com”,
host: “farm6.static.flickr.com”,
host: “farm7.static.flickr.com”,
host: “farm8.static.flickr.com”,
host: “farm9.static.flickr.com”,
host: “fbstatic-a.akamaihd.net”,
host: “galleries.payserve.com”,
host: “gamemedia.armorgames.com”,
host: “gamerch-static-contents-gz.s3-ap-northeast-1.amazonaws.com”,
host: “graph.facebook.com”,
host: “graphics2.asiafind.com”,
host: “graphics2.asiafriendfinder.com”,
host: “graphics.alt.com”,
host: “graphics.cams.com”,
host: “graphics.outpersonals.com”,
host: “graphics.pop6.com”,
host: “graphics.streamray.com”,
host: “gs1.wpc.edgecastcdn.net”,
host: “i0.wp.com”,
host: “i1.sndcdn.com”,
host: “ia902706.us.archive.org”,
host: “icdn2.digitaltrends.com”,
host: “icdn5.digitaltrends.com”,
host: “icdn6.digitaltrends.com”,
host: “imagena1.lacoste.com”,
host: “imagena2.lacoste.com”,
host: “images.contactmusic.com”,
host: “images.goodsmile.info”,
host: “images.mrskincash.com”,
host: “images.neopets.com”,
host: “images.popin.cc”,
host: “img1.zergnet.com”,
host: “img2.zergnet.com”,
host: “img3.zergnet.com”,
host: “img4.zergnet.com”,
host: “img.docstoccdn.com”,
host: “img.elle.co.jp”,
host: “img.epochtimes.com”,
host: “img.fatxxxtube.com”,
host: “img.kanzhongguo.com”,
host: “img.muji.net”,
host: “img.qz.com”,
host: “img.secretchina.com”,
host: “imgs.ntdtv.com”,
host: “imgx3.dditscdn.com”,
host: “img.youtube.com”,
host: “i.utdstc.com”,
host: “livepassdl.conviva.com”,
host: “l.longtailvideo.com”,
host: “m1.aboluowang.com”,
host: “massmedia-cdn.wistia.com”,
host: “media1.break.com”,
host: “media.247sports.com”,
host: “media-cache-ec0.pinimg.com”,
host: “media-cache-ec2.pinimg.com”,
host: “media-cache-ec4.pinimg.com”,
host: “media.cathkidston.com”,
host: “media-cdn.tripadvisor.com”,
host: “media.dermstore.com”,
host: “media.livepromotools.com”,
host: “media.mademan.com”,
host: “media.sfweekly.com”,
host: “media.skincarerx.com”,
host: “m.facebook.com”,
host: “mobapi.bloomberg.com”,
host: “mobile.twitter.com”,
host: “mzstatic.playhaven.com”,
host: “p1.zdassets.com”,
host: “passets-cdn.pinterest.com”,
host: “pbs.twimg.com”,
host: “photos-a.pe.facebook.com”,
host: “photos.modelmayhem.com”,
host: “photos.pop6.com”,
host: “piclist.pop6.com”,
host: “pic.pimg.tw”,
host: “p.jwpcdn.com”,
host: “platform.twitter.com”,
host: “playstationna.i.lithium.com”,
host: “plus.google.com”,
host: “pmcdn.staticpmrk.com”,
host: “public.oneallcdn.com”,
host: “p.vitalmx.com”,
host: “q-ec.bstatic.com”,
host: “quests.armorgames.com”,
host: “r2—sn-nx57yn7s.googlevideo.com:443″,
host: “r6—sn-5uaeznze.googlevideo.com”,
host: “r6—sn-i3b7rnee.googlevideo.com”,
host: “r7—sn-jc47eu7l.googlevideo.com”,
host: “rc-regkeytool.appspot.com:443″,
host: “realtime.services.disqus.com”,
host: “s0.wp.com”,
host: “s1.dmcdn.net”,
host: “s1.hubimg.com”,
host: “s1.wp.com”,
host: “s2.dmcdn.net”,
host: “s2.wp.com”,
host: “s3-ec.buzzfed.com”,
host: “s3.hubimg.com”,
host: “s3.pimg.tw”,
host: “s7.pimg.tw”,
host: “s9.pimg.tw”,
host: “s9.thisnext.com”,
host: “s.cdn.gaiaonline.com”,
host: “s.gravatar.com”,
host: “s.pimg.tw”,
host: “sr.photos3.fotosearch.com”,
host: “s-static.ak.facebook.com”,
host: “static02-ec-vn.zalora.com”,
host: “static1.businessinsider.com”,
host: “static2.businessinsider.com”,
host: “static2.docstoccdn.com”,
host: “static3.businessinsider.com”,
host: “static4.businessinsider.com”,
host: “static5.businessinsider.com”,
host: “static6.businessinsider.com”,
host: “staticd.cdn.adblade.com”,
host: “static.exoclick.com”,
host: “static.libsyn.com”,
host: “static.linkbucks.com”,
host: “static.miniclipcdn.com”,
host: “static.movideo.com”,
host: “staticna2.lacoste.com”,
host: “static.payserve.com”,
host: “staticx2.dditscdn.com”,
host: “staticx3.dditscdn.com”,
host: “staticx4.dditscdn.com”,
host: “s.utdstc.com”,
host: “s.wordpress.org”,
host: “s.xe.com”,
host: “sync.graph.bluecava.com”,
host: “s.youtube.com”,
host: “t.6park.com”,
host: “tags.crwdcntrl.net”,
host: “th00.deviantart.net”,
host: “th01.deviantart.net”,
host: “th02.deviantart.net”,
host: “th03.deviantart.net”,
host: “th05.deviantart.net”,
host: “th06.deviantart.net”,
host: “th07.deviantart.net”,
host: “th08.deviantart.net”,
host: “th-th.facebook.com”,
host: “thumbs.3jizz.com”,
host: “ukcdn.usablenet.com”,
host: “use.typekit.com”,
host: “vdc-img-0.ig1-cdn.com”,
host: “video.ap.ntdtv.com”,
host: “wac.24ba.edgecastcdn.net”,
host: “wac.450f.edgecastcdn.net”,
host: “wac.76ff.edgecastcdn.net”,
host: “widgets.twimg.com”,
host: “wpc.a818.edgecastcdn.net”,
host: “wprp.zemanta.com”,
host: “www.open.com.hk”,
host: “www.secretchina.com”,
host: “www.stratfor.com”,
host: “www.youtube.com”,
host: “www.youtube-nocookie.com”,
host: “x.myspacecdn.com”,

Serious Vulnerability in VBSEO

The vBulletin team sent an email yesterday to all their clients about a potential security vulnerability on VBSEO. VBSEO is widely used SEO module for vBulletin that was discontinued last year. This makes the problem worse, no patches will be released for it.

If you are using VBSEO, you have 3 options:

  1. Completely remove VBSEO from your site – It is not supported anymore
  2. Apply the patch recommended by the vBulletin team
  3. Put your site behind a Website Firewall, this will prevent the exploitation of this vulnerability and many others.

Our research team is looking at this issue and it seems to be a remote, unauthenticated script (html) injection vulnerability. It might lead to a full remote command execution, but we have not confirmed it yet. That’s as serious as it can be, since an attacker can use that to inject malware, spam or take down the site.

This is the full email from vBulletin:

Dear VB License Holder,

It has come to our attention that there may be a potential security vulnerability in VBSEO affecting the latest version of the software (and potentially other versions as well). We’ve attempted to contact the vendor, but as they have been non-responsive we felt we should alert the community as many of our customers use this add-on software.

If you think you might be running a vulnerable version of the software, there is a simple fix: just comment out the following lines in the file vbseo/includes/functions_vbseo_hook.php:

if(isset($_REQUEST[‘ajax’]) && isset($_SERVER[‘HTTP_REFERER’]))
$permalinkurl = $_SERVER[‘HTTP_REFERER’].$permalinkurl;

should be changed to:

// if(isset($_REQUEST[‘ajax’]) && isset($_SERVER[‘HTTP_REFERER’]))
// $permalinkurl = $_SERVER[‘HTTP_REFERER’].$permalinkurl;

If you are running the “Suspect File Versions” diagnostics tool, you will additionally need to generate a new MD5 sum of the above file and edit upload/includes/md5_sums_crawlability_vbseo.php to use the new MD5 sum on the line:

Please be aware that you are making these changes at your own risk. We don’t know if making this change affects the terms of your VBSEO license and we can’t be responsible if making this change breaks your site.

CVE-2014-9463 has been assigned to this potential vulnerability by cve.mitre.org.

We will post more details as we investigate.

New Malware Campaign – WPcache-Blogger – Affects Thousands more WordPress Websites via RevSlider

If SoakSoak wasn’t enough, we are starting to see a new malware campaign leveraging the RevSlider vulnerability and compromising thousands of WordPress sites in the last few days.

Unlike SoakSoak, it’s comprised of 3 distinct malframes – creating one new campaign. We’re tracking each closely:

1- wpcache-blogger:

This campaign is using the domain wpcache-blogger.com as the main malware distributor and command and control. So far is has been responsible for the Google Blacklist of 12,418 sites:

Has this site hosted malware?
Yes, this site has hosted malicious software over the past 90 days. It infected 12418 domain(s), including bertaltena.com/, polishexpress.co.uk/, maracanafoot.com/.

2- ads.akeemdom.com

This second campaign seems to be done by the same team behind SoakSoak, but at a smaller scale. Google has blacklisted 6,086 sites so far:

Yes, this site has hosted malicious software over the past 90 days. It infected 6086 domain(s), including fitforabrideblog.com/, notjustok.com/, notanotherpoppie.com/.

3- 122.155.168.0

: This campaign has been going for a almost a week and started shortly after SoakSoak. It seems to be slowing down and was responsible for the blacklist of 9,731 domains.

Has this site acted as an intermediary resulting in further distribution of malware?
Over the past 90 days, 122.155.168.0 appeared to function as an intermediary for the infection of 9731 site(s) including kitchenandplumbing.com/, salleurl.edu/, radiorumba.fm/.

WPcache-blogger Malframes

Together, these 3 campaigns have caused 28,235 websites to be blacklisted by Google (according to their safebrowsing stats) in a very short time frame. Our internal analysis has identified more than 50,000 WordPress websites compromised via this new campaign, not all have been blacklisted yet.

However, the WPcache-blogger variation is picking up a lot of traction the past 24 hours; it’s by far the most aggressive in it’s growth trajectory. When it compromises a site, it adds the following code to the footer of the theme:

eval ( base64_decode("ZnVuY..

This payload contacts http://wpcache-blogger.com/getlinks.php, retrieving the malicious iframe to be displayed for the user. What is interesting about this injection is that it is highly conditional and if you try to re-load the page, it will load “google” via an iframe, instead of the malware site.

This is the real malframe:

<iframe src="httx://theme.wpcache-blogger.com/css&quot...

But it will also display an iframe to Google from time to time to make it harder to be detected:

<iframe src="http://google.com"..

If you see an iframe to Google.com on your site, consider yourself hacked.

Cleanup and Protection

As the previous RevSlider issues, you have to update it asap to close the door for new attacks. It won’t clean your site, but will help control the problem.

Once Revslider is updated, you have to do a full clean up of your site. Just reinstalling WordPress won’t fix the problem; as mentioned before, this campaign is similar to #soaksoak in that it’s using a wide range of backdoors, allowing the attackers to regain access to your website, bypassing all existing controls in place.

We are recommending everyone to take security seriously, add your website behind a Website Firewall asap, the scale of these attacks are increasing daily. We’re cleaning thousands of sites all leveraging the latest Security Tips, the coolest security plugins. Yes, we have a product that does it, but you don’t have to use it. Leverage Google and find alternatives, if you’re a sysadmin / DIY type person, try leveraging the open-source project, ModSecurity or any other variation available.

Whatever you do, it’s time you start taking security seriously!

RevSlider Vulnerability Leads To Massive WordPress SoakSoak Compromise

Yesterday we disclosed a large malware campaign targeting and compromising over 100,000 WordPress sites, and growing by the hour. It was named SoakSoak due to the first domain used in the malware redirection path (soaksoak.ru).

After a bit more time investigating this issue, we were able to confirm that the attack vector is the RevSlider plugin. We disclosed a serious vulnerability with this plugin a few months ago, it seems that many webmasters have either not heard of or did not take seriously the vulnerability.

The biggest issue is that the RevSlider plugin is a premium plugin, it’s not something everyone can easily upgrade and that in itself becomes a disaster for website owner. Some website owners don’t even know they have it as it’s been packaged and bundled into their themes. We’re currently remediating thousands of sites and when engaging with our clients many had no idea the plugin was even within their environment.

The Attack Sequence

We have investigated thousands of compromised sites with this injection and based on the logs, we are able to confirm the exact attack vector being targeted.

  1. Discovery: There appears to be an initial reconnaissance scan occurring where the attacker[s] are looking to see if the file exists. Snippet of the code
  2. 94.153.8.126 – – [14/Dec/2014:09:59:35 -0500] “GET /wp-content/plugins/revslider/rs-plugin/font/revicons.eot HTTP/1.1″ 200

    94.190.20.83 – – [14/Dec/2014:00:12:07 -0500] “GET /wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php HTTP/1.0″ 202

    The first entry looks for the revicons.eot files and the second one attempts to use one of the Revslider vulnerabilities to download the wp-config.php file.

  3. Exploit:If the discovery phase is successful and they find a site using Revslider, they use a second vulnerability in Revslider and attempt to upload a malicious theme to the site:

    94.153.8.126 – – [14/Dec/2014:04:31:28 -0500] “POST /wp-admin/admin-ajax.php HTTP/1.1″ 200 4183 “-”
    Content-Disposition: form-data; revslider_ajax_action
    update_plugin; name=”update_file”;…

  4. Take over: If the exploit is successful, they inject the popular Filesman backdoor into the website, which they access directly at /wp-content/plugins/revslider/temp/update_extract/revslider/update.php this provides full access by circumventing existing access controls:

    94.153.8.126 – – [14/Dec/2014:04:31:28 -0500] “GET /wp-content/plugins/revslider/temp/update_extract/revslider/update.php HTTP/1.1″ 200 5287
    “-” “Mozilla/5.0 (Windows NT 5.1; rv:33.0) Gecko/20100101 Firefox/33.0″

From there, they inject a secondary backdoor that modifies the swfobject.js file and injects the malware redirecting site visitors to soaksoak.ru.

This campaign is also making use of a number of new backdoor payloads, some are being injected into images to further assist evasion and others are being used to inject new administrator users into the WordPress installs, giving them even more control long term. Some users are clearing infections and getting reinfected within minutes and the reason is because of the complex nature of the payloads and improper cleaning efforts.

Do not just clean these 2 files!

We are hearing a lot of recommendations online to just replace the swfobject.js and template-loader.php files to remove the infection.

It does remove the infection, but does not address the left over backdoors and initial entry points. The website will be reinfected quickly. If you are affected by this, expect to find yourself riddled with backdoors and infections, you have to not only clean, but also stop all malicious attacks. You can stop malicious attacks through the use of a Website Firewall, ours or someone else, just use a Firewall, a real one preferably.


We have posted a full payload analysis as well as our original release on SoakSoak:

SoakSoak Malware Compromises 100,000+ WordPress Websites

This Sunday has started with a bang. Google has blacklisted over 11,000 domains with this latest malware campaign from SoakSoak.ru:

Google Blacklisting - SoakSoak.ru

Google Blacklisting – SoakSoak.ru

Our analysis is showing impacts in the order of 100’s of thousands of WordPress specific websites. We cannot confirm the exact vector, but preliminary analysis is showing correlation with the Revslider vulnerability we reported a few months back.


Read More

JoomDonation Compromised

We are receiving reports from many users of the popular JoomDonation platform that they received a very scary email from someone that supposedly hacked into JoomDonation. The emails went to the registered accounts and contained the full names, so it looks like JoomDonation did in fact get breached.

This is the full email:

How the hell are you? No need to ask, I’m fine!

I’m the one who has hacked all of your sites, emails, accounts etc. that has been using JoomDonation.com site/components. Scaring? Hell Yea :-)

About 15 months ago, I was able to penetrate into several Joomla sites. One of these luckies was JoomDonation.com After a while I realised that their crappy components were used by other Joomla developers too so I injected my shells into JoomDonation.com components. As per result, I’ve a list of 300000+ Joomla users+emails and you’re just one of them, lucky thing :-)

..

Yea Yea I know you all have scanners, firewalls, admin tools etc installed on your server/site but you what? F*ck em all. They’re just noob tools. Think about, I’ve injected my own shells into 10000+ Joomla sites and none of you or your magic tools have been awared of.

WARNING: You have 5 days to clean up your sites then my bot will start putting your sites down. If your site was not so valuable for me, removing the components would be enough. If so, then I will most probably blackmail you soon :-)

Want an advice from a hacker? Don’t use any script from Thailand/Vietnam developers, their code is so crappy :-) Try Indian quality.

This email was sent to all JoomDonation.com users. We’ll meet again if you have accounts registered to other Joomla developers :-)

Our research team is trying to confirm if any of the downloads from JoomDonation contain a backdoor, and we will post more details soon on what we find.

The JoomDonation developer has confirmed their environment has been compromised, but believes the issues to be specific to their server:

Hi All

I believe this is not security issues in our components/extensions. Someone hacked our server (we are using bluehost VPS server for hosting our website) somehow and uses the email systems to send this spam emails to all of you.

They want to destroy our business (and they mentioned India somehow in the email). Just the quick update from us, we will provide more information when we found something!

We are really sorry for this trouble.

The concern here is two fold:

  1. How did the attackers penetrate JoomDonation? If they leveraged a Zero-Day, then it’s likely the attacker can in fact penetrate other environments configured the same way.
  2. How is the attacker contacting JoomDonation users? This leads you to believe that there has been some level of data breach and user PII information has been compromised.

Currently, the attacker appears to be contacting those that have purchased any of the JoomDonation extensions, which include:

  1. Events Booking
  2. OS Property
  3. EShop
  4. Membership Pro
  5. EDocman
  6. CSV Advanced
  7. OS Services Booking
  8. Joom Donation
  9. Documents Seller

In the meantime, we highly recommend disabling this extension from your website. I would also highly recommend putting it behind a Website Firewall (WAF) with all hardening options enabled to minimize the chances of a compromise in case the extension has a 0-day vulnerability or backdoor.

:::::Update: 20141126 :::::

Tuan provides more details on the compromise, he states:

Dear all,

As you know, today, our hosting account was hacked. The hacker got a small part of our users information (only name and email) and emailed to these users that their sites were hacked. Infact, these sites are not hacked at all.
We have been working hard on this issue. Here are something we found and would like to inform you about them:

1. The security issue is not related to our extensions at all. So all the sites which are using our extensions at the moment will still be safe.

2. The issue came from a security hole in the hosting server which we have used. We have been using a VPS server to secure customers data, unfortunately, there was still security hole and the server has no Firewall software, so the hacker could get into the system and stole these information. We are working to move our website to a more secure server with a better hosting provider. However, it will take us one or two days for doing that.

3. The hacker just got a small part of our users information (contain name, email) and publish some of them. Few hours after the information was published (just name and a part of the email – the domain of the email is hidden), it was deleted and could not be viewable from public. So the information would be secure from now as well

4. We can assure that your sites are still safe. However, we advice that you change super admin account (and FTP account) of your site.

5. We will continue analyzing the server logs and will inform more information about this issue ASAP.

We are really sorry about this issue and hope you will stay with us and do more business with us in the future. Our extensions are good and secure, it is just the hosting server insecure and causes us all these trouble.

Sincerely, JoomDonation

Protecting Against Unknown Software Vulnerabilities

Bugs exist in every piece of code. It is suggested that for every 1,000 lines of code, there are on average 1 to 5 bugs to be found.

Some of these bugs can have security implications. These are known as vulnerabilities, and they can be used to exploit and compromise your server, your site and your users.

As long as there are people involved in the process of writing code and setting up systems, mistakes will happen as it is part of human nature. As such, security problems will always be something we have to deal with.

Impact of Vulnerabilities on Websites

Why does it matter that much? Last week, both WordPress and Drupal released new versions of their Content Management System (CMS) to patch important security vulnerabilities. Other popular WordPress plugins also released updates to fix their vulnerabilities.

Once a vulnerability is found and a patch is available, the solution is simple: Apply the patch (by doing an update) and you are now protected. It is the endless cycle that is known as software development. A bug will be found, a patch will be available, the patch is applied, another bug is found, a new patch is available, the patch is applied. Every time a new feature is introduced, new bugs are also introduced with it.

It seems like a simple process for a webmaster that as long as he is updated, he is safe.

However…

How do you protect against unknown software vulnerabilities?

What if you do not know about a specific vulnerability, how do you patch and protect your website?

What if an update goes out over a long weekend? A 0-day gets disclosed before an update is available? Or what if a vulnerability is discovered by the bad guys and they start using it without telling anyone?

  • The latest SQL injection vulnerability in the Drupal platform was being exploited within 7 hours of it’s disclosure.
  • Websites were being compromised via TimThumb before the public knew about it and a patch was available
  • We have hits in our logs from days before the latest XSS vulnerability in WordPress was disclosed.

So the question is, how do you increase your security so that you can minimize the risk and the chances of being compromised when (not if) someone tries to attack your site misusing an unpatched / unknown vulnerability?

You have options:

  1. Restrict who can access parts of your site to minimize the attack footprint.
  2. Employ prevention solutions that try to block exploit behaviors (generally called WAF’s or IPS’s).
  3. Harden parts of your stack to minimize the effect of an exploit.
  4. Constant network and log monitoring to identify Indicators of Compromise (IoC).

These are just some examples. They may sound hard or too advanced, but they are actually doable and every website owner should look into it.

Think about your desktop / notebook computer for a second. Why does every (or almost every) desktop have a personal firewall, an anti-virus, a spam filter and other similar tools? Yes, even Macs have them as well.

Why do most networks (including home networks) run behind a router with basic / advanced firewalls working to filter and prevent attacks from the Intranet?

The reason is simple: minimize the footprint and options for an attacker.

Now think about your website[s]. Let’s look at a few examples into how that can be applied to your Website security:

WordPress 4.0 Long Password DOS

Both Drupal and WordPress had a vulnerability disclosed last week that allowed an attacker to DoS (Denial of Service) a site by sending many, very long passwords in the login requests.

Prevention: Access Restriction / Reduced Footprint.
Block wp-login and wp-admin access only to authorized IP addresses. If an attacker can’t reach your login page, he won’t be able to exploit this vulnerability.

Simple solution that anyone can do by adding an .htaccess to your wp-admin allowing just a few IPs. We find this feature important enough that we employ it to our stack by default and set it as default for all users of our Website Firewall product.

Paid Memberships Pro Path Traversal

Paid Memberships Pro is a popular WordPress plugin that had a path transversal (arbitrary file download) vulnerability disclosed last week. The exploit is possible by accessing: wp-admin/admin-ajax.php and passing a file to be downloaded via getfile:

wp-admin/admin-ajax.php?action=getfile&/../../wp-config.php

Prevention: Access restriction / reduced footprint.
The same as before, restrict access to only whitelisted IPs.

Prevention 2: WAF/IPS.
Even if the previous restriction was bypassed, an Intrusion Prevention System (IPS) or Web Application Firewall (WAF) would prevent it from being exploited through generic Local File Inclusion / Remote File Inclusion (LFI/RFI) rules.

WordPress 3.9.x stored XSS

WordPress versions 3.9.2 and earlier are affected by a critical cross-site scripting vulnerability, which could enable anonymous users to compromise a site. This was reported and patched last week as well.

This vulnerability abuses the core commenting system, an attacker is able to craft a simple comment to send a malicious payload that when viewed by the administrator, allows the attacker to take over the site. This explains it’s severity.

Prevention: Reduced footprint.
First, if your site does not need or use comments, why leave it open? You can block any access to wp-comments-post via .htaccess and be covered right away. If you do need comments, you can use external commenting systems that keep untrusted (user data) away from your trusted data (posts, pages, etc).

Prevention 2: Prevention technology.
Even if you do allow comments, employing a WAF or IPS would probably have blocked this XSS via generic XSS signatures that most good prevention products have.

WP-Statistics XSS

Our research team found a stored XSS in the very popular wp-statistics plugin.

Prevention: WAF/IPS.
This is where having a good WAF / IPS solution in place becomes a must. A WAF have (or should have) a XSS detection that will block this attack generically, without even knowing about this specific vulnerability. On our own WAF, we were blocking it automatically before even knowing about this bug, in a way that we did not even need to write a virtual patching for it.

Staying ahead of Unknowns

Last weeks releases are growing in number each month, as they do the importance of being able to tackle the problem of unknowns grows. Following some of the steps above would improve your over Security posture allowing you to better recognize and respond to these issues, reducing your overall risk footprint.

We offer a product that can do this all, but many of the recommendations you can employ on your own by leveraging open technologies and .htaccess changes:

  • Restrict access to wp-admin/wp-login (and any other access point) only to authorized IPs.
  • Limit footprint. Do you need comments? Do you use XMLRPC? Blocking everything and only allowing what you really need.
  • Leverage a WAF / IPS and you can do this with products like Modsecurity and OSSEC.

We’ve obviously built a technology that automates all these things for you, allowing you to get back to running your business, but you can see there are various options available to you. If you’re interested in a free trial, ping us at info@sucuri.net.

Drupal Warns – Every Drupal 7 Website was Compromised Unless Patched

The Drupal team released an update to a critical SQL Injection vulnerability a few weeks ago and urged all their users to update or patch their sites as immediately.

Today the the Drupal team released a strong statement via a public service announcement:

You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement.

In case you’re wondering, this is a very strong statement for any origanization, especially an open source project, to make. It’s one we agree with and tried to amplify, without causing alarm in the initial post. Less than 48 hours after their disclosure, we released a post saying that attacks were already in the wild and attempting to compromise every site they could.

The scariest part of this vulnerability is that since Drupal uses PDO, this vulnerability is not only limited to SELECT statements, an attacker is able to able to insert or modify arbitrary data in the database.

Severity, coupled with it’s simplicity is a recipe for disaster. It’s a matter of time before it’s integrated into the latest toolsets and attacks are actively detected.

The first attack started 8 hours after the disclosure. The attackers began hitting our honeypots with the following SQL Injection attempt…

One thing I want to make very clear is that every site behind our website firewall is and has been protected against this attack. We still recommended all our users patch, but our virtual patching (along with our SQL injection protection), kept and will continue to keep our clients sites safe.

Recovery Mode

If you have not patched your site in time and you were not using a Website Firewall with virtual patching enabled, you should assume that your site was indeed hacked. You need to defer to your incident response procedures and assume a compromise has occurred until you can prove otherwise.

The Drupal team provided some steps in their disclosure, but we also want to recommend the following steps:

  1. Check if your site is actively serving malware or spam. Free scanners like SiteCheck and Unmaskparasites exist for this purpose.
  2. Download a filesystem backup from before Oct 15th and compare all file changes since.
  3. Download a database backup from before Oct 15th and compare any changes there. Look for new users and new hooks specially. If you can, restore to that backup to be safe.
  4. Change all passwords.
  5. Look up for any new file added since.

The scary part of this issue is that Drupal, unlike many other of it’s counterparts – Joomla! and WordPress – is heavily employed in larger organizations (enterprises for lack of a better word). This means that it’s highly unlikely that they were able to patch. Unlike consumers and small business, large organizations have processes that dictate the steps that they are allowed to take and what points. Each step has a series of approvals and depending on the size of the organization those approvals can be exhaustive (meaning they can take time).

This is a recipe for disaster, if it’s true and those websites are in fact compromised, they could be leveraged and daisy chained for a massive malware distribution campaign. Take that into consideration with the size and audience of brands and the impact grows exponentially.

If you are one such organization that finds yourself in this type of situation, we highly recommend employing technology solutions that give you more time to follow your steps while still protecting your online property.