#security on software development security and web security, security best practices and discussions, break-ins and countermeasures. Everything you ever wanted to know about software security but were afraid to ask, for fear of not understanding the answer!
Finally, someone registered a company that is an SQL injection attack. We saw the license plates on cars doctored to execute SQL injection attacks but this is the first time, I think, that an attempt to crash all business SQL databases in a country is made.
The company name is: ; DROP TABLE “COMPANIES”;– LTD
The November 2014 breach of security at Sony Corporation remains the subject of conversation throughout the end of the year. Many interesting details have become known while even more remains hidden. Most claims and discussions only serve to create noise and diversion though.
Take the recent discussion of the antivirus software, for example. Sony Corporation uses antivirus software internally, it’s Norton, TrendMicro or McAfee depending on the model and country (Sony uses Vaio internally). So I would not put much stock into the claims of any of the competitors in the antivirus software market that their software would have stopped the attackers. And it’s irrelevant anyway. The breach was so widespread and the attackers had such totality of control that no single tool would have been enough.
The most interesting question remains unanswered though. Why did the attackers decide to reveal themselves? They were in the Sony networks for a long time, they extracted terabytes of information. What made them go for a wipeout and publicity?
Was publicity a part of a planned operation? Were the attackers detected? Were they accidentally locked out of some systems?
What happened is a very important question because in the former case the publicity is a part of the attack and the whole thing is much bigger than just a network break-in. In the latter cases Sony is lucky and it was then indeed “just” a security problem and an opportunistic break-in.
Any security specialist should be interested to know that bigger picture. Sony should be interested most of all, of course. For them, it’s a matter of survival. Given their miserable track record in security, I doubt they are able to answer this question internally though. So it’s up to the security community, whether represented by specialist companies or by researchers online, to answer this most important question. If they can.
The lot of hype around the so-called “Heartbleed” vulnerability in open-source cryptographic library OpenSSL was not really justified. Yes, many servers were affected but the vulnerability was quickly patched and it was only an information disclosure vulnerability. It could not be used to break into the servers directly.
This security update resolves a privately reported vulnerability in the Microsoft Secure Channel (Schannel) security package in Windows. The vulnerability could allow remote code execution if an attacker sends specially crafted packets to a Windows server.
This vulnerability in Microsoft TLS is much more serious as it allows to take over the control of any vulnerable server remotely by basically simply sending packets with commands. Microsoft admits that there are no mitigating factors and no workarounds, meaning if you did not install the patch, your server is defenseless against the attack. Windows Server 2012, Windows Server 2008 R2 and Windows Server 2003, as well as workstations running Vista, Windows 7 and Windows 8 are all vulnerable.
The attacks on WordPress using xmlrpc.php service are rather common. I already mentioned that you could filter out unwanted user-agents using the redirect capability of Apache. That would, however, take care only of obvious cases, where you see that this particular user-agent could not possibly be your reader. What do we do if the user-agent looks normal?
Well, if you do not need your xmlrpc services, you could block it off completely with mod_rewrite for all access:
This will return a 403 for all requests. It is basically equivalent to what you did with “files” directive where you specify “Deny all” for a file path. This will block all access to xmlrpc completely though, for all purposes, so you will not be able to use the service at all. Which is not always acceptable.
But the good news is that the set of rules is extensible with other conditions and you could block only the requests with particular user-agent again now. For example:
And so this becomes an extensible list of rules. You check your logs, see suspicious requests and add them to the list of rules. Stack the additional rules with [OR] flag at the end of the condition line.
Now we have a set of rules that blocks some of the accesses to the xmlrpc based on the user-agent reported by the attacker. We could also add filtering by referrer or IP ranges and so on. The arms race, you get the picture.
I have attracted attention, apparently. My website is under a Distributed Denial of Service (DDOS) attack by a botnet for the last week. I am flattered, of course, but I could live without a DDOS, frankly.
The requests go to xmlrpc.php every second or two from a different IP address from around the world:
POST /xmlrpc.php HTTP/1.1
At first I could not understand what was going on but it turns out that that request can be really expensive and the database basically gets overloaded with requests bringing the database server to a screeching halt after a while.
After trying to blackhole the IP addresses and finding out that the botnet is fairly large, I simply denied all access to xmlrpc.php. That is a simple and effective solution but it breaks some functionality that is expected of a WordPress site. I don’t like that. So I was looking for a way to block the attackers without crippling the site.
I noticed that all of the requests have a particular HTTP request user agent:
It seems to have mitigated the attacks by that particular botnet software while allowing access from all other browsers and sites. I hope it stays that way. I don’t think my site is really worthy of this kind of attention anyway.
The researches at the University of Cambridge have published a paper titled “PIN Skimmer: Inferring PINs Through The Camera and Microphone” describing a new approach to recovering PIN codes entered on a mobile on-screen keyboard. We had seen applications use the accelerometer and gyroscope before to infer the buttons pressed. This time, they use the camera to figure out where the fingers are touching after the microphone has signalled the start of a PIN entry. The success rate varies between 30% and 60% depending on configuration and number of samples. And that is a lot.
This attack falls into the category of side-channel attacks and it is rather hard to prevent. The paper explains in detail how the attack works and gives recommendations for mitigation to the developers. The paper also refers to several other works that use side-channel attacks using smartphone. For mobile application developers, it would be a wise idea to read through this and referenced publications to find out what the state of the art now is.
The discussion of whether Google should or should not do anything about that is interesting but we are not going to talk about that. Instead, think that this is a prime case of a familiar tool that comes back to your website regularly subverted into doing something evil. You did not expect that to happen and you cannot just block the Google from your website. This is a perfect example of a security attack where your application security is the only way to stop the attacker.
The application must be written in such a way that it does not matter whether it is protected by a firewall – you will not always be able to block the attacks with the firewall. The application must also be written so that it withstands an unanticipated attack, something that you were not able to predict in advance would happen. The application must be prepared to ward off things that are not there yet at the time of writing. Secure design and coding cannot be replaced with firewalls and add-on filtering.
Only such securely designed and implemented applications withstand unexpected attacks.