FBI Warns of ISIL Defacement Attacks on WordPress Sites

photo credit: Lock - (license)
photo credit: Lock(license)

The FBI issued a public service announcement today, warning concerning WordPress website attacks being carried out by individuals sympathetic to the Islamic State in the Levant (ISIL) a.k.a. Islamic State of Iraq and al-Shams (ISIS). The perpetrators of these attacks are defacing sites across various platforms such as news organizations, businesses, government sites, and religious institutions.

Last month the would-be terrorists gained infamy by hijacking the Fancybox Plugin vulnerability in order to deface sites with ISIS propaganda. This particular vulnerability allows malware (or any random script/content) to be added to the vulnerable site and was most recently identified as the entry point for the hackers who injected iframes with ISIS messages.

A patch exists for the vulnerability and those affected can easily remove the plugin as an alternative. However, many WordPress users are either ignorant of the security issue or indifferent. The FBI’s announcement serves to warn users of the cost and inconvenience associated with this kind of attack:

Although the defacements demonstrate low-level hacking sophistication, they are disruptive and often costly in terms of lost business revenue and expenditures on technical services to repair infected computer systems.

The announcement cited multiple plugin vulnerabilities as a security risk to WordPress users but did not identify the plugins for which patches are currently available. Technical details of the brief are limited to a generalized list of consequences should a vulnerable site get hacked:

Successful exploitation of the vulnerabilities could result in an attacker gaining unauthorized access, bypassing security restrictions, injecting scripts, and stealing cookies from computer systems or network servers. An attacker could install malicious software; manipulate data; or create new accounts with full user privileges for future Web site exploitation.

Since these are low level hackers exploiting the most basic types of vulnerabilities, they are not targeting specific sites but rather knocking down any open door they can find. The announcement notes that all of the victims of the defacements share common WordPress plugin vulnerabilities.

The FBI does not believe that these attacks are actually coming from members of ISIL but instead are coming from hackers using the organization’s name as a vehicle for greater exposure.

The FBI assesses that the perpetrators are not members of the ISIL terrorist organization. These individuals are hackers using relatively unsophisticated methods to exploit technical vulnerabilities and are utilizing the ISIL name to gain more notoriety than the underlying attack would have otherwise garnered.

The announcement concludes with a list of general resources for hardening WordPress and identifying vulnerabilities, but the recommendations are vague and non-specific. The best thing that you can do to keep your site safe from these continuing attacks is to make sure you are running the latest version of WordPress. Log in to your sites and update all of your themes and plugins. If you’re using any commercial plugins or themes, make sure to check for updates in case you are not automatically notified.

All of the vulnerabilities referenced in the FBI warning already have patches, and all you need to do is update your plugins. If you have multiple WordPress sites, consider adding them to a centralized dashboard service such as Jetpack Manage, MangeWP, WP Remote, InfiniteWP, or another service of your choosing.

19

19 responses to “FBI Warns of ISIL Defacement Attacks on WordPress Sites”

  1. WordPress as a project and the WordPress community has to do more to make sure users keep their WordPress install, plugins and themes up to date. This issue isn’t going to go away and will only get worse as the WordPress install base grows larger and larger. Developers will whine about automatic updates but that is the direction WordPress needs to go in for more than just WordPress core updates. I discussed this in more detail on my blog here: http://carlhancock.com/wordpress-has-an-update-problem/

  2. WordPress itself is not the issue…it is the people who own the websites.

    1) People have weak usernames/passwords. There shouldn’t be admin as username, the domain, the author’s name (wptavern, jeffchandler, sarahgooding and so forth)
    2) Weak passwords, go to a password generator and pick an 18 character password
    3) Bad coding practices for themes/plugins from sources outside WP directory. Like Googling FREE THEMES.
    4) Not updating. People should spend 15 minutes a day, or on a weekly basis and log in into their site(s) and check if any updates.

    I am against auto-updates, One of JetPack’s modules broke my site, yes I put a thread on the forums at WP.

    WordPress should at the core make it easy to change /wp-admin and /wp-login.php to something else. I know I can download a security plugin (I used it, I can’t remember the name of it right now)

    That security plugin I can change the login url and the wp_ prefix. That and changing /wp-admin should be part of WP Core.

    • 1) People have weak usernames/passwords. There shouldn’t be admin as username, the domain, the author’s name (wptavern, jeffchandler, sarahgooding and so forth)

      Knowing usernames is not an attack vector. usernames are intended to be public (or at least to be safe to be available to the public). Poor passwords is the problem.

    • Agreed @ Miroslav, rename wp-admin and wp-login.php should be part of the core for increase security. Right now, with some security plugins, I saw quite a number of mousing from wp-admin/wp-login.php from my site and since it was hidden, the hackers were trying another moves I presumed.

    • There are more potential vectors of attack than just the front door. In this case, they exploited a vulnerability in an outdated plugin to deface a site.

      Having a solid password is great first step, but keeping everything up-to-date should always be the next step.

    • Hackers dont attempt go through passwords. They go after signatures in the codebase. That is to say if a widget has a security issue, sites using said widget are located via automation. Pulling down pages looking for that unique signature. It might be Javascript code, comments in javascript code, stylesheet information, comments in the HTML etc.

      The Web Browser object for example that is “MSIE” can be used in any Windows application. The controls in MSIE are basically a wrapper around it. That was source of litigation many moons back with Windows. The integration of MSIE to Windows. Your desktop on your PC showing you your icons is MSIE.

      It takes about 6 lines of code to pull a page down from the web as source code. Again, not the PHP code, thats not exposed. But everything going to the client (Web Browser is). Firefox has this same ability, can grab its DLLs (dynamic link libraries) and use it in Windows projects, can write your own web browser.

      Traversing a site is simple. Just a recursive deal like traversing a directory on your PC or Binary Tree.

      Its sorta funny in a way. Alot of codebases that are open sourced for example say, “You must keep this commentary with the codebase” and the commentary is often in the form of comments. If those comments are exposed in the rendering then there sits a signature.

      Hackers dont just hop around guessing. They use automation.

      I dont even pretend to understand them, the thrill or whatall they get off it. Satan’s work if you ask me. But understanding how its done is not difficult for any Windows or Mac or Linux programmer or perhaps I should say any programmer who has a base skill set in any of the above.

      So how might they find security holes? Now that we understand how they locate the sites using perhaps some widget. But how do they find the widget?

      Well… It might already be known to have a security matter. Heck, these days I wouldnt be surprised if some coders dont intentionally make a gizmo to later target. Makes ya wonder doesnt it?

      But… again using automation an application, even a PHP app on some server someplace can be a client scouring websites throwing SQL at input forms, trying to perform Cross site scripting etc.

      Anything can and does happen.

      What is unfortunate is that real security audit software is a business as well and the good stuff is expensive.

      Whats expensive? Ball park figure for HP Fortify for Web/Mobile is $45,000.

      • Incidentally there are some free audit applications I remember one called like Wapiti or something along those lines. Perhaps some searches might result in others that someone could post up here at WP Tavern and get word “spread” that vulnerability scanners should be run against code and indeed sites making for a better world!

  3. Perhaps,

    Weird this article/news pops up as yesterday I was going to write an article on another thread about security. It was a thread about standards. WP Standards and Theme’s review.

    Some years back we did political webs, campaign sites and elected officials. We used Joomla. We coded an entire framework allowing for workflows. Aka: A news area having editor(s), Publisher(s), Writer(s), Layout, Artist(s) etc. Real workflows, like say CNN has (lesser scale). In regional campaigns there are regional events organizers, support organizations etc. So their workflows quite different as are roles and what they can/cant do. All into one component with several plugins and modules.

    This framework to be part of a completely different project, we were going to use Joomla as the CMS and we have a C# MVC ASP.NET enterprise application that the CMS need support for content management. Rather than code one, use one already versatile. In fact, the only reason I am here is we dropped Joomla and are now porting code to WP so we can unit test and see if we can get WP to have enough performance to suit the expectant traffic load.

    Anyways… So everything is cool. We even got a call from the then Governor of the state (NY) just floored with our work. We’d integrated ACT! and all sorts of nifty things via C#.

    One day we get this call, campaign. FLIPPING OUT!!! Their site was brought down, defaced overnight. They tell us, “Need be back up NOW and we have 24 hours to figure out and close whatever breach occurred or expect about 2 million in lawsuits”. Nice! Talk about crappin’ ones knickers.

    So look at the obvious, logins, the people with access etc. Nuthin’. I went over our codebase, didnt see anything. One of the programmers (of this larger project that the CMS is to support) calls me completely unrelated reasons. I tell him, “Cant talk now, got a emergency”. So he asks whats up. I tell him. He says, let me call you back in 10 minutes. I reiterate, “Cant talk now!”. Tells me “I will make a call, Xerox will locate the breach”. Ooo… OK!

    Xerox and HP are pals. Phone rings. They found it. They ran HP’s security audit software against the site. But more bad news, there are 5 other insecure areas. EVERY SINGLE SITE we’d made. Every single security flaw due to third party components. The Calendar component being the culprit in this particular breach and its the #1 event component at the time for Joomla and one of the third party display modules made by someone else completely in support of said component. Also breaches in the forms component.

    So… I go through that code base. Fix the holes. Next day they run the audit again. We’re good. Fixed all the sites (quietly).

    Few days later I go speak to council. Ask him, “Hey… we have this limited liability disclaimer signed, dated, notarized etc. that you wrote up for us. Yet, here comes this threat we had”, and when talking those figures, believe me, the heart jumps some beats.

    He refers me to a friend of his, deals with nothing but IT law.

    Two days later I am in his office. He reads over the disclaimer. Asks me what platform we built on. Asks me about any third party codebases. Gives me a “uh huh. Hmmm… Ok… Uh huh”. Puts the disclaimer back down in front of me and says, “This is worthless”.

    “Huh? What?”

    Tells me unless ALL third party extensions were mentioned and all signed off on in respect to liability the entire document is useless. WHAT?!?!

    He said, “You agreed to xxx component or in WP terms widget, plugin, theme) disclaimer that holds them to no liability from YOU”. That DOES NOT mean that your customer or client cannot hold YOU responsible via its usage in your works for them UNLESS they are informed of it IN WRITING and sign off liability or limited liability to it. He also said it does not stop the client or customer from attempting sue the entity who made the codebase.

    WHAT?!??! What if the code is free?

    He continued, “This does not matter at all. Client and Customer are the same in as far as the USA goes. If someone downloads something for free they are still the customer or if they buy it.” Ok. I get that. So he gives me an example. Keurig makes coffee makers. The components in the coffee maker are made by many otehr manufacturers. The heating element in this certain edition of the coffee maker is faulty. It causes a fire. The consumer(s) sue Keurig. Keurig claims its not their fault but that of the heating element. The consumer can sue both or either. If Keurig had a no liability or limited liability agreement with the heating element manufacturer that can still be litigated. But that agreement does hold weight in a court of law. Ultimately however it is up to a judge”. He continued, “Your software by NOT disclosing to the customer be that paid, free or not means that any half competent attorney will get your disclaimer null and void in court.”.

    I am like, “Oh my…. I mean. WT — F”

    He says, “Rick. I’d not even have met with you about this matter had it not be for the referral from my friend and I’d not met with you even if you called me directly as a paid appointment.”

    Again, I am in the dark. “Why?”

    He says, “Because this firm does not represent business entities in regards to defense. He said I am the attorney that goes after businesses as irresponsible as yours who engage in putting out websites and applications resulting in damages to those that entrust them.”

    Oh my.

    He says, “Do you understand?”. I said, “Yes I do” and he showed me out.

    Now notice. OUR codebase, really complex workflows no breach. Why? Its coded to commercial standards. What ARE commercial standards? It means a closed code base for starters with API and proper API security of access to it.

    For example. Lets say we port the workflow codebase to WP. I slap it out there Open Source. Someone goes in and makes changes or additions. They may be opening up holes in it. That simple. If you were to look at the code, you would be looking at it at least 3-4 days to get the gist of its basic (note : BASIC) function. Yet, if I hand you the UML, the class diagrams, the action diagrams etc. in an hour you will know more about how to modify it, add to it, keep it secure than you would ever learn in those days upon days of going through the code.

    Thats standard in industry. If I handed the codebase to eBay engineers the FIRST thing they will be asking for are all those details and specifications. If they are not there and I were trying peddle it upon them they’d not budge an inch until they are supplied.

    NOW we run EVERYTHING against HP’s security audit and every client gets the full hoe down on the codebases used in a blanket agreement.

    It is even more complex I found after the fact via yet another party (RIT Professor). Told me that when it comes to say widgets developed overseas, they’re areas of litigation and liabilities can vary quite widely as well and most of the time such instances of threats of litigation results in two council’s running to and fro from rooms where the client (customer) and web business reps sit working to “cut the deal”. He said it reminds him of when someone makes an offer on a house.

    He also told me HOW many of the WP/Joomla/DruPal/Portal/Forum sites get hit. And this is even a kicker.

    Signatures. A signature can be a comment. So a insecure widget has a comment in the HTML and thus a page can be pulled down by an application (its like 6 lines of code for example to download page source to Visual Studio in C#) searched against and… There it is.

    Javascript as again, its coming down to the browser. Its not like some hacker sits there and goes, “Oh here’s another one”. They have part of an application search for sites that have some form of unique WP in this example signature, then it searches for the signature of the security problem. Bam.

    So when I read the “Theme Standards” I was sorta like… Exactly WHAT standards? Of course, I get it, the coding conventions, style perhaps, files for this and that. Real standards do exist but they come with the accompaniment of supporting information(s). Which do you think is better? Being handed a codebase and going through it trying to understand it or having the proper support diagrams and overviews so you DO understand the codebase and thus when looking at modifying it you already have a great understanding of how it works?

    But, even with that said, the professor told me happens all the time. Big companies dont like litigate things public as it can distress the brand and little ones cant afford litigate it so it gets settled in this back and forth fray behind closed doors.

  4. Usually in web arenas staying with the most mature latest stable is best as core code security is usually the first of issues that appear. So WP 4.2 comes along if a site is critical dont update for 4-6 weeks.

    Run security audits against the site(s) with something. Lastly hosting providers can also make a difference depending on what security they have in place. While more than likely not able to pick up on this particular cache plugin flaw there are some really great host providers with hardware firewalls. It depends on how important security is to your needs. Some defaced blogs can readily be restored. A breach however in say a commerce venue where peoples information gets exposed can be a kiss of death.

  5. These attacks are mainly happening to sites that are affiliated with the opposition or are broadcasting views and news about the current situation, if I’m not mistaken.

    Even though this opens discussion about how vulnerable WordPress and in particular some sites are in terms of their security, it isn’t a very widespread thing and people surely shouldn’t worry too much.

    I run a Kurdish news site and we report on the fighting out there a lot through WordPress and to be honest this has got me a little worried, but will be trying to keep everything on the site updated.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Discover more from WP Tavern

Subscribe now to keep reading and get access to the full archive.

Continue reading