Taboola confirms security breach, and has its PayPal account pwned

This weekend, visitors to news articles on the Reuters website found themselves redirected to a page belonging to the Syrian Electronic Army hacking group.

As I wrote at the time, rather than this being a straightforward hack of Reuters' servers, suspicion pointed in the direction of the Taboola recommended content widget that Reuters had embedded on its site.

Example of Taboola recommendd content on Reuters website

Sure enough, yesterday Taboola confirmed that it had been hacked.

Taboola statement

Today, between 7AM - 8AM EDT, an organization called the “Syrian Electronic Army” hacked Taboola’s widget on Reuters.com.

The intruder was redirecting users that accessed article pages on reuters.com to a different landing page.

The breach was detected at approximately 7:25am, and fully-removed at 8am. There is no further suspicious activity across our network since, and the total duration of the event was 60 minutes.

While we use 2-step authentication, our initial investigation shows the attack was enabled through a phishing mechanism. We immediately changed all access passwords, and will continue to investigate this over the next 24 hours.

TaboolaTaboola doesn't really go into much detail as to how the hack took place or what measures it has put in place to prevent it from happening again (perhaps unsurprising for an incident which took place over the weekend) but there will perhaps be concerns that other users of the popular widget could have potentially been put at risk.

After all, Taboola claims to have high traffic sites such as TMZ, Time, The Weather Channel, BBC, and USA Today amongst its customers.

Taboola appears to have made no public statement about a screenshot posted by the Syrian Electronic Army, claiming to have gained access to the company's PayPal account.

Taboola Paypal account

The above image is redacted a little more than the original one shared by the Syrian Electronic Army, primarily to obscure the identity and email address of the Taboola employee who appears to have had their account compromised.

If nothing else, this latest attack underlines three things:

Firstly, the importance for all employees to exercise great caution over the links they click on because of the danger that they might be entering their passwords on a phishing site.

Secondly, the need to follow best password practices (unique, hard-to-crack passwords for each website) and the enabling of two-factor authentication where available to make it harder for hackers to gain access to accounts.

Finally, websites need to think long and hard not only about the security of their own servers but whether the companies who are providing widgets and plugins that power the websites are taking security as seriously themselves.

After all, at the end of the day, the typical user is going to view the incident as Reuters being hacked - not Taboola.

Tags: , , , ,

Smashing Security podcast
Check out "Smashing Security", the new weekly audio podcast, with Graham Cluley, Carole Theriault, and special guests from the world of information security.

"Three people having fun in an industry often focused on bad news" • "It's brilliant!" • "The Top Gear of computer security"

Latest episode:

, , , ,

2 Responses

  1. Coyote

    June 23, 2014 at 10:39 pm #

    Re: "Firstly, the importance for all employees to exercise great caution over the links they click on because of the danger that they might be entering their passwords on a phishing site."

    XSS attacks too! I seem to remember that was one of the mistakes Apache (or a staff member of) made that led to them being compromised. But unlike corporationst hey not only took blame (and admitted it) they also gave a detailed series of steps of what they did wrong and what happened as well as the consequences. That would do companies well: show your integrity! But I don't see that happening.

    Re: "Finally, websites need to think long and hard not only about the security of their own servers but whether the companies who are providing widgets and plugins that power the websites are taking security as seriously themselves."

    Indeed. It drives me crazy how many non-CMS (and admittedly even some that are… if they directly have control and not using a web interface) based websites don't bother to download scripts they use (open source, whatever) and instead refer to a remote location. That's not even the driving me crazy about everything being broken – I much prefer noscript over obnoxious scripts (and I risk some things breaking but it is better that way…). Yes, the idea of the web is hyperlinks (hence hypertext …) but there's a difference here even if it is hard for some to see. Whenever you're loading up content (and ahem, did I forget to write about iframes?! very, very serious one that is) you're also risking your users (even if it is a server side script if it is attacked then you're potentially risking users).

  2. Coyote

    June 23, 2014 at 10:53 pm #

    Here we go:
    https://blogs.apache.org/infra/entry/apache_org_downtime_report
    https://blogs.apache.org/infra/entry/apache_org_04_09_2010

    If corporations did that it would be (as they point out in the first link) a much better Internet.. Alas, no.

    As for Apache… indeed, one of the attacks WAS an XSS attack! Not only do they report what went wrong (including having one configuration overriding – kind of – another so even though they did what they should they neglected another one) they also include what did work. It is a detailed account (pardon the much intended pun). Much credit should go to Apache for these things (they're not the only organisation but they're among the few that do).

    As for the point of your post, something that crossed my mind immediately on reading their message:
    They claim they noticed the breach at 7:25 and removed it at 8:00. I'm calling them out here. Any good administrator would take much more time to install fresh but even if not that then at least tighten up their setup (especially the part that led to the breach but evaluate everything else as well!). Yet here they handled it in 35 minutes? Of course they suggest 60 minutes so either they're poor in math or they made a mistake with the time (or more likely they're hiding information… very likely). Either way, give them the benefit of the doubt on the 35 versus 60 minutes: they only fixed it in fantasy and in an irresponsible manner, but they absolutely did not follow best practice. Even if they looked at logs, I have lost count with how many ways there are to remove (not even talking about gaining complete control so able to remove them) logs… so how are they sure they noticed everything, especially in such a short time? They're lying to themselves or they're naive.

Leave a Reply