Server Security: Import WordPress Events to OSSEC

Ossec WordPress Log Export Update

We leverage OSSEC extensively to help monitor and protect our servers. If you are not familiar with OSSEC, it is an open source Intrusion Detection System (HIDS); it has a powerful correlation and analysis engine that integrates log analysis, file integrity monitoring, centralized policy enforcement, rootkit detection, real-time alerting, and active response.

It provides complete coverage if you are looking for an endpoint (server) security solution. If you have not used OSSEC before, I recommend reading my guide to get started: http://dcid.me/texts/my-ossec-setup-manual.html
Read More

Server Security: OSSEC Integrates Slack and PagerDuty

1292015_Ossec_Blog_Slack (2)

We leverage OSSEC extensively to help monitor and protect our servers. If you are not familiar with OSSEC, it is an open source Intrusion Detection System (HIDS); it has a powerful correlation and analysis engine that integrates log analysis, file integrity monitoring, centralized policy enforcement, rootkit detection, real-time alerting, and active response.

It provides complete coverage if you are looking for an endpoint (server) security solution.

If you have not used OSSEC before, I recommend reading my guide to get started:
http://dcid.me/texts/my-ossec-setup-manual.html
Read More

Critical 0-day Remote Command Execution Vulnerability in Joomla

Disclosure-Image---Joomla!
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.

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.


Read More

Server Security: OSSEC Updated With GeoIP Support

OSSEC HIDS GeoIP
We leverage OSSEC extensively to help monitor and protect our servers. If you are not familiar with OSSEC, it is an open source Host-Based Intrusion Detection System (HIDS); it has a powerful correlation and analysis engine that integrates log analysis, file integrity monitoring, centralized policy enforcement, rootkit detection, real-time alerting, and active response.

It provides a pretty complete coverage if you are looking for endpoint (server) monitoring.

If you have not used OSSEC before, I recommend reading my guide to get started:
http://dcid.me/texts/my-ossec-setup-manual.html

Note that it requires root access to your servers and is meant for network and server administrators with Linux skills.

OSSEC With GeoIP

We recently made an improvement to OSSEC with the integration of the MaxMind GeoIP database (that maps an IP to a country and/or a city). This update was important to us, as it makes it a lot easier to monitor logs and understand what is going inside your network.

Read More

Increased Popularity in DDoS Extortion Campaigns

DDoS BitCoin Ransom

Over the past few months, our security operations group have identified and mitigated an increasing number of DDoS attacks tied to extortion attempts from different cyber crime groups, including DD4BC, Armada Collective and a few more unnamed ones. These DDoS extortion attempts are starting to exploit smaller websites that may be less able to defend themselves.

DDoS Ransom Email

It all starts with an simple email similar to this one:

Subject: Ransom request: DDOS ATTACK!

FORWARD THIS MAIL TO WHOEVER IS IMPORTANT IN YOUR COMPANY AND CAN MAKE DECISION!

We are [Criminal Group].

All your servers will be DDoS-ed starting Friday if you don’t pay 2 Bitcoins @ [BITCOIN ADDR]

When we say all, we mean all – users will not be able to access sites host with you at all.

Right now we will start 30 minutes attack on your site’s IP (victims IP address). It will not be hard, we will not crash it at the moment to try to minimize eventual damage, which we want to avoid at this moment. It’s just to prove that this is not a hoax. Check your logs!

If you don’t pay by Friday , attack will start, price to stop will increase to 4 BTC and will go up 20 BTC for every day of attack.

This is not a joke.

This ransom email is followed by a small scale DDoS attack that can last from 30 to 60 minutes. After 24 hours, if the ransom is not paid, the attacks increase and can last many hours.

DDoS for Bitcoin

This type of extortion activity started last year (around Jun of 2014) and focused mostly on Bitcoin exchange sites and financial institutions. They were a rare occurrence with an attack every couple of months.

The ransom prices were high at around 40 Bitcoins ($14,000 USD) to stop the attacks.

By the beginning of 2015, these DDoS extortion campaigns picked up steam with a group called DD4BC (DDoS for Bitcoins) attacking many properties in a small period of time. They got a lot of media attention and some interesting analysis was done by the Arbor and Akamai teams on their activities and tactics:

It Won’t Happen to Me

Even though the media and security companies were already talking about this DDoS extortion threat, for most webmasters it felt like a foreign threat only affecting very large institutions and financial websites.

However, over the course of the last couple of months, we started to see an increasing number of extortion attempts against more average-sized sites. Everything from forums, small e-commerce and even some online gaming properties started receiving the threats and being DDoS’ed.

The price to stop this new wave of attacks also went down significantly, to just 2 Bitcoins ($700 USD). We are seeing these new DDoS ransom attempts more and more from what seems like an unnamed copy-cat group. They send a similar email threat:

Subject: DDoS

Hello!

All your servers are going under attack unless you pay 2 Bitcoin.

Pay to [BITCOIN]

Please note that it will not be easy to mitigate our attack, because
our current UDP flood power is 200-300 Gbps.

Right now we are running small demonstrative attack on 1 of your IPs: [REMOVED]

Don’t worry, it will not be hard, since we do not want to crash your
server at this moment, and will stop in 60 minutes. It’s just to prove that
we are serious.

We are aware that you probably don’t have 2 BTC at the moment, so we
are giving you 24 hours to get BTC and pay us…

This is followed by a SYN flood and layer 7 attack against the site.

After 24 hours, the attacks generally increase in size and can reach up to:

  • 3-4 million packets per second – Syn Flood
  • 400-500 HTTP requests per second – HTTP Flood
  • 20-25 Gbps – UDP Flood

Most of the time we see all variety of DDoS attack types happening at the same time. That’s generally more than enough to take most sites down and get null-routed by hosting providers.

This increase in DDoS-for-ransom is concerning, as it seems that webmasters are often paying them. These attempts would just fade away if they were not financially lucrative. If you ever get such a threat, do not pay for them!

Fighting Back

Again, do not pay these ransom requests. Instead of sending the money to the criminals you should reach out to your ISP or security provider to see if they can help you. If you have to spend the money, do so to protect yourself, but understand they may still attack you even if you pay the ransom. Like with all ransomware, your best option is to have backups and protection in place before your website is attacked.

You can also contact us and we will help you navigate through this experience. Plus, sites behind our Website Firewall (CloudProxy) are already well protected against these threats.

Sucuri += HTTP/2 — Announcing HTTP/2 Support

HTTP2_Blog_V1r3

We are happy to announce that we are now offering HTTP/2 support to all clients using our Website Firewall (CloudProxy) product.

Our own site already supports HTTP/2 (including this blog) and we will be rolling out HTTP/2 to all account dashboards very soon. We have always supported SPDY (the HTTP/2 predecessor) and decided to upgrade to HTTP/2 now that it is stable and supported by most browsers.
Read More

vBulletin Exploits in the Wild

Disclosure-Image-Vbulletin

**Update: CheckPoint disclosed more details here: Check Point Discovers Critical vBulletin 0-Day.

The vBulletin team patched a serious object injection vulnerability yesterday, that can lead to full command execution on any site running on an out-of-date vBulletin version. The patch supports the latest versions, from 5.1.4 to 5.1.9.

The vulnerability is serious and easy to exploit; it was used to hack and deface the main vBulletin.com website. As a precaution, all passwords were reset; you will have to create a new one before you can access vbulletin.com again and download the patches.

Exploits in the Wild

This vulnerability seems to have been around for a bit. We were able to trace exploit attempts to the end of October, they were targeting a few high profile vBulletin sites protected by our Website Firewall.

The exploit was shared publicly yesterday. It attacks the decodeArguments Ajax API hook. Here is an example of an exploit attempt in the wild:

108.47.xx.yy – – [02/Nov/2015:22:18:21 -0500] “GET /vbforum[/]ajax/api/hook/decodeArguments?
arguments=O%3A12%3A%22vB_dB_Result%22%3A2%3A%7Bs%3A5%3A%22%00%2a%00
db%22%3BO%3A11%3A%22vB_Database%22%3A1%3A%7Bs%3A9%3A%22functions%22
%3Ba%3A1%3A%7Bs%3A11%3A%22free_result%22%3Bs%3A7%3A%22phpinfo%22
%3B%7D%7Ds%3A12%3A%22%00%2a%00recordset%22%3Bi%3A1%3B%7D%22

Once decoded, it executes:

vB_Database”:1:{s:9:”functions”;a:1:{s:11:”free_result”;s:7:”phpinfo”;}}s:12:”

This shows the attacker the result of phpinfo indicating that his exploit succeeded. If this test payload works, the attacker will proceed with a full compromise. We are not seeing widespread exploitation attempts yet, as just a few high profile sites were targeted, but we expect it to change soon as it makes its way into the automation engines.

Patch and Protect

If we have not emphasized before, you have to patch your vBulletin site now! Websites behind our WAF are (and always were) protected against this vulnerability due to our virtual hardening technology. If you can not patch your vBulletin site, we recommend looking at a solution to stop these exploits before they reach you.

Joomla SQL Injection Attacks in the Wild

JoomlaSQL
Last week, the Joomla team released an update to patch a serious vulnerability on Joomla 3.x. This vulnerability is an SQL injection (CVE-2015-7858) that allows for an attacker to take over a vulnerable site with ease. We predicted that the attacks would start in the wild very soon, due to the popularity of the Joomla platform along with how easy the exploitation was.
Read More

Joomla 3.4.5 Released, Fixing a Serious SQL Injection Vulnerability

Disclosure-Image---Joomla!

The Joomla team just released a new Joomla version (3.4.5) to fix some serious security vulnerabilities. The most critical one is a remote and unauthenticated SQL injection on the com_contenthistory module (included by default) that allows for a full take over of the vulnerable site.

Update October 26, 2015: We posted a follow up looking at the prevalence of Joomla SQL injection attacks in the wild less than 24 hours after this disclosure.

Directly from the Joomla announcement:

Read More

Brute Force Amplification Attacks Against WordPress XMLRPC

BruteForce Banner
Brute Force attacks are one of the oldest and most common types of attacks that we still see on the Internet today. If you have a server online, it’s most likely being hit right now. It could be via protocols like SSH or FTP, and if it’s a web server, via web-based brute force attempts against whatever CMS you are using.

These attacks are often not very complex and are theoretically easy to stop and mitigate, but they still happen and are successful; mostly, because people are very bad at choosing good passwords, or employing good access control habits. There is a catch however, while simple, these Brute Force attacks are noisy. Traditionally, to try 500 different passwords, the attackers would need to attempt 500 different login attempts that would be captured in a 1 to 1 relationship with each request to the server. By design, this simplifies the mitigation approach, as every single attempt is logged and can be blocked once a certain limit is reached.


Read More