Over the past several months there has been an uptick in the number of web sites running Content Management Systems that have been compromised. Systems like WordPress, Joomla or Drupal have all been targeted. Site administrators struggle to keep their CMS’s patched and almost never remember to include all the plugins that are used. In many cases the plugin vulnerabilities can do just as much evil as the core CMS vulnerabilities. Due to the breadth and quality of maintenance and support for plugins vulnerabilities and updates are often not monitored or reported.
A couple of very popular plugins announced serious vulnerabilities recently that allow them to execute arbitary PHP on the server, WP Super Cache and W3 Total Cache. So take care of the plugins that you deploy and if you no longer need them then uninstall them.
Here are some examples of phishing emails, and how to detect them.
I’ve put up some basic information about detecting phishing emails. The outlook is not bleak, as some would expect. Based on internal data, over 98% of recipients do not respond to phishing emails.
In a few days I’ll put up some examples of actual phishing emails, and point how the features that betray their malicious intent. There will also be an article on more technical methods of analyzing suspicious emails.
With the Christmas just around the corner many people will be ordering from overseas. As part of the online ordering process many companies use email to confirm orders and provide updates. The spammers know this and take advantage of the increase in this type of email by sending out their “ware” hoping to catch people. Most anti-spam systems do a very good job of blocking these, but some still gets through.
The common thread among phishing emails to watch out for include:
unfamiliar transaction report from a familiar business
an attachment with no explanation in the message body
“phishing” or asking for your email password
asking you to “log in” to obtain something
Looking into the messages’ headers can prove helpful but this is a little more technical and is best covered elsewhere. So enjoy the festive season and remember not to respond to emails from companies that you didn’t ordered from.
Here, this looks like a good joke … downornot.com is down!
Except of course, it isn’t down …
Or perhaps it is …
So, is DownorNot.com down, or not?
The problem here is that the meaning of “it” in the phrase “is it up or down?” is different each time. For the human, “it” is the service provided by the website, and that service is certainly non-functional (it looks like the website’s usage of the Google AppEngine service has gone over quota; and the developer who wrote their website didn’t anticipate this error. In this case, we would also anticipate that the service behind the website is also broken at the moment, whereas often a service and a website are separate). For isitup.org, “it” seems to be the initial contact with the site’s webserver, which is responsible for handling the HTTP conversation. For downforeveryoneorjustforme.com, “it” is the same thing, the webserver and not the application, but they are going a couple of steps further, following the redirections and noticing that the final page is delivered with an error status … and in this case, the failure of the application is reflected in the webserver status code. It doesn’t have to be.
Let’s ask isitup.org again, but this time go straight to www.downornot.com instead of just downornot.com …
So, if you are monitoring or testing a service, make very very sure that you understand what the question “Is it up?” is supposed to mean — and this depends on who is asking. Then, make very sure that you understand how your monitoring tools work, what you are asking them to do, and how to interpret them. Obviously, this isn’t as easy as it sounds …
If you are not careful, this is what you end up with :-
Dan Geer is a voice in the IT Security world that should be listened to, and he has co-authored a short but intense article in the IEEE S&P Cleartext column that addresses the reality of the rapidly-changing threats that we all face.
“Stand Your Ground” has a few key messages, which I’ll try to summarise :-
- Minimise the number of targets; stop adding new services without effective defences, remove old services. Use the savings to fund better security for what remains.
- Distrust the internal network; distrust any service that is not continually verified. Defend against outbound traffic as well as inbound traffic.
- Do not assume perfection is possible; plan for failure modes that reduce services sensibly. Reduce the time-to-repair with automation instead of extending the mean-time-between-failure.
For more reading and a less technical take on these ideas, here’s another article about Dan’s thoughts from Ben Tomhave, a GRC (Governance, Risk & Compliance) consultant.
In an article from Wired thieves allegedly stole half a million Australian credit card numbers. The raid on an unnamed business in Australia used keystroke logging software on POS terminals then transferred the information back to Eastern Europe. The POS terminals had default passwords and stored transaction data insecurely. They were accessed using an unsecured Microsoft Remote Desktop connection. But the notable quote is
“The network was setup by some local suppliers who didn’t understand IT security,” Det. Sup. Marden told the magazine. “It was a disaster waiting to happen.”
As is often the case in many incidents, most of the layers of defence were turned off, left with default values, or just were not considered necessary. Had any one of the following been in place this particular incident could have been averted: changed the vendors default password, forced access to the terminals via a VPN, AV software on the workstations, IDS on outward network traffic, logging and monitoring of authentication services. Lastly, had the Aussie business performed an independent information security audit these would have been identified and the costly compromise could have been avoided.
On August 1 2012, the New York Stock Exchange started to record significantly unusual levels of activity at 0930, as the markets opened. Trade rates were running at 30% above normal. By the end of the day one trader alone, Knight Capital Group Inc, had burnt over $440 million. The trades damaged market values for the whole day and almost destroyed Knight completely.
Technical analysts Nanex have posted a great analysis of the pattern of trades that enabled them to identify the likely origin of the trades, and to present a reasonable theory that seems to fix the facts: Knight seem to have released an internal trade testing application onto their production servers. It tested the live NYSE market. It lost money, because making money was not a requirement for testing.
It is hard to come up with a test environment for software that acts in a realistic manner, especially when you do not want to let the software itself be aware that it is being tested (because that will change its behaviour, and then it isn’t a proper test, is it?). It is also hard to construct tests that have to change the system state, when testing things that write to databases for example. And if you do accidentally run the test in a live environment, you can always recover from backups, right?
No, not always. Not $440 million’s worth of real-world money …
I’ve posted before about external hard drives with built-in encryption. These devices have their own keypad to enter the password/decryption key. If you should happen to connect it to a computer infected with a keystroke logger, the key will not be revealed (although such a computer may have other malware installed on it!)
Wired have a four-way comparison of:
- Apricorn Aegis Padlock 3
- Rocstor Rocsafe MX
- Lenovo ThinkPad USB 3.0 Secure Drive
- DataLocker DL3