Phishers compromise LAMP-based websites for days at a time and hit the same victims over and over again, according to an Anti-Phishing Working Group survey. Sites built on Linux, Apache, MySQL and PHP are the favoured targets of phishing attackers, the APWG report found, with between 76 and 82 per cent of respondents using one …
Er, no wonder they kept getting in
If you just restore things to exactly how they were, then that doesn't really count as locking the attackers out to me - unless they're using something which is difficult to pull off, they can just compromise you the exact same way again.
I must admit I have been one of these clueless victims, although with a WAMP stack rather than LAMP.
Hackers were running a uTorrent client on my Windows VPS and had also replaced some PHP pages on my sites. I restored my sites from a backup, upgraded all my software versions (both AMP and PHP-based) and changed all my passwords, but I have no idea how they got in to this day.
I'm not deluding myself that the reason it hasn't happened since is because of my new security regime though... fail because, well, it's obvious.
Read the logs of your router.
There will be an endless list of attempts to connect/start a raft of applications like Apache, Webmin, PHP, MySQL, etc. These attempts usually try combinations of default username and password, often appearing to originate from IP addresses owned by companies like Microsoft, PCWorld, Argos, BBC. Which then end up being blocked by my router's IP blacklist, with the expected result.
Sooner or later these attempts find a mark in the "low hanging fruit" department and they are in with privileges.
I've been running Apache on Win2K for years now, and as far as I know, none of the site pages have been compromised, ..... so far. However, I'm no expert and I half expect a proper "expert" to get in touch with me to tell me the awful news.
I stayed away from LAMP precisely 'cos I could not be certain that all the apps were sufficiently tied down so as not to be a liability, or be a vulnerability. My lack of LINUX knowledge saved me ?
However, if Microsoft et al, are having these difficulties when they have all those highly trained IT staff, what chances do the rest of us have of staying sharp and our servers germ free ?
I hope those loony Linux fanciers are reading this article.
"I restored my sites from a backup, upgraded all my software versions (both AMP and PHP-based) and changed all my passwords, "
The terrible truth is I suspect that is *much* more than a lot of other victims.
This article is broadly nonsense.
Phishing is using social engineering (most often via junk email) to solicit login details from punters, right?
So what does it matter what web stack the servers of the sites they attack run? A phishing attack is not an attack on any vulnerability in the website, it's a social engineering attack on the website's users.
It's like saying that of people who get their house burgled, 70% of them shop in Tesco at least once a year (that's a made up statistic, in case there was any doubt). So what?! How is that relevant? All it shows is that Tesco (or LAMP) is fairly popular.
Or am I really missing something?
I think you may be missing something
As I understood it, they're saying that people are targeting the LAMP systems in order to launch phishing attacks against 3rd parties.
Except phishers need somewhere to host their fake bank sites.
Fair play, though, I had the same thought to begin with. Not sure why the Reg went with "phishers" when I'm sure this applies to any script-kiddie-based activity.
I think the point is...
the mark has to enter login credentials somewhere for them to be phished. That somewhere is usually a compromised web server. It's cheaper and less likely to be tracked back to the perpetrators than if said perpetrators rent web space. You are right it doesn't matter which stack the server runs, but as the majority of web servers run the LAMP stack...
I think you missed a line or two. They're not compromising the sites by phishing, they're doing it by normal methods and then using the servers as a platform for launching phishing attacks at other targets.
<form action="<?php echo $_SERVER['PHP_SELF']; ?>"
It's a standard piece of code that you'll actually find recommended in textbooks on PHP programming, from the last decade. So many websites that are poorly maintained, or largely forgotten about will have just this kind of code in them.
Reload the page as /my.shonkywebsite.me.uk/form.php"><script>alert('Squeel, piggy! Squeel!');</script>
Part of the problem is that the $_SERVER super-globals sounds like something programmers might realistically think wold contain things the server had any strong opinions about, whereas, in this case, PHP_SELF is just whatever the user had in their address bar when the page loaded. All languages have these vulnerabilities, but for almost a decade, PHP programming universally endorsed, and tacitly recommended, this usage.
Phishers hosted on compromised machines, not compromising via phishing
The phishers are hosting their pages on somebody else's web pages. The article states that there are a LAMP stack with the pages added without the owners permission or knowledge.
considering it is a lot easier to mis-configure and fail to update the LAMP stack than it is to secure it.
Then there are all those GUI's, themes, admin interfaces etc. that web admins install to make administration easier. What's more it is far easier to write insecure php code than it is to write secure php code.
I get several attacks a day on my LAMP server, usually they are scripted attacks looking for admin interfaces and directory traversal exploits.
My advice is install the bear minimum, use Vi and the sql command line tool to configure the stack and avoid using third party tools unless you know php and understand exactly how the code behaves and can fix any bugs or flawed validation routines. Using a simple text editor to configure a LAMP server forces one to learn how the components interact and leads to a greater understanding of the system.
I would recommend removing all the system commands that are not required to configure the server and make those that remain available to one user only (not necessarily root) and not every user of the system. I accept that this may not be possible in some deployment scenarios.
You touch on something there without mentioning it explicitly:
A lot of these attacks are pre-scripted and assume many things like directory names and user names.
Simple tasks such as using unusual usernames for admin tasks and not using the pre-supplied directory names can foil scripts enough that the majority of attacks won't even bother following up.
I see enough 404 attacks to things like "phpMyAdmin" (all case variants) to know never to have that as a root directory.
Publishing Apache or webapp version numbers publicly doesn't help, either.
I'm not saying this is the answer to security, but it's a simple fix to a lot of attack attempts.
Not really due to any technical failing with the platform, though...
This has very little to do with the LAMP platform though, really. The vast majority of exploits are your common-or-garden SQL injections. LAMP applications are no more or less prone to these vulnerabilities than any other, it's simply a question of whether the programmers have bothered to institute sound programming practices such as parametrised queries and input validation/escaping.
As I see it, there are three reasons for the prevalence on LAMP platforms:
1. As noted, LAMP is much more widespread than any other platform, e.g. IIS. So, in the same way Windows gets most of the virus 'heat' due to being the most widely used desktop, LAMP gets the most attention from script kiddies and cybercrooks due to being the most widely used web application hosting platform.
2. LAMP web applications are much more likely to be open source. Consequently, it's easier for the aforementioned script kiddies and crooks to identify vulnerabilities in frameworks or out-of-the-box applications which can then be used for defacements, phishing attacks, or whatever.
3. Finally, LAMP is the cheap option. As such it is by far the platform which is most likely to be used by smaller organisations which may not be able to afford in-house security expertise which would assist them in keeping on top of updates or performing code reviews to prevent these pretty basic security failings.
That's a bit broad...
"between 76 and 82 per cent of respondents using one or more components of the LAMP architecture."
What, so 76 percent of websites use either Linux, Apache, MySQL or PHP within their system? Well duh! By that definition (unless I'm misunderstanding or the phrasing is bad) half these attacks could be Windows-based apps connecting to MySQL in the background, and that would count as an attack against the LAMP stack.
Maybe I'm misreading that, but something in there seems dodgy.
script kiddie attacks in my server access logs all the time and they're always looking for the same things, phpmyadmin and mysqladmin. The problem here is that a lot of people who set these sites up don't have a damn clue about how to secure a webserver. Also allowing any kind of remote access to your server other than via ssh is just asking for trouble also php is the devil and only of use to amateurs who don't know how to write good cgi.
They are coming to take me away, away ...
If only I could continue writing even indifferent CGI ...
I've run my own servers for a decade with no break ins. That's obviously due to a bit of luck but mostly because all the server-side stuff was mine and i knew the vulnerabilities and could deal with it at different levels - the code itself, the naming of the interfaces (so many are so obvious) and building in a honeytrap to divert and contain any attack.
Sadly with all this AJAX stuff, a proliferation of browsers and increasing expectations by clients for flashy functionality I can no longer code fast enough or into the increasing number of disciplines necessary to satisfy clients.
So an increasing number of my websites are Joomla or Wordpress driven. PHP scares deeply. Other people's PHP even more. Its not difficult to spot a Joomla or Wordpress site so any known vulnerability in that software can expose all my servers. Yes I try to get all the security upgrades in fast but they always come at difficult times.
So while I felt reasonably safe - now its just a matter of time. But which one will get me first?
What's that got to do with PHP?
"Its not difficult to spot a Joomla or Wordpress site so any known vulnerability in that software can expose all my servers."
See title. Surely that's just the fact that "known flaws in software can be exploited."?
where life is beautiful all the time.
Love it, Napoleon XIV.
flawed survey methodology
"Filter: YES RESPONSES ONLY"
Of those surveyed and knew they had been hacked and knew what OS they were running on, 270 gave a positive results. What was the percentage of non-respondents not running on LAMP that didn't know they had been hacked?
I love it, in the middle of the report is a hotlink to a PDF file :) If you need to be informed by some third party that your web server is hacked, then maybe you are in the wrong career ..
"(If you cannot rebuild or restore offline, do so online but behind a firewall)"
Not very telling at all
Ok...so between 76 and 82 percent of the respondants who got pwned were running at least one part of the LAMP stack....If Apache alone has a better than 60% market share and MySQL also has a pretty significant market share (which it did last time I checked, but that was several years back), isn't it fairly likely that around that percentage of ALL web servers have at least one component of the LAMP stack? PHP is fairly popular as well. Besides, one component of the stack does not make a LAMP server.
Hosted environments used by amateurs shocker!
"with between 76 and 82 per cent of respondents using one or more components of the LAMP architecture."
That's a bit different to "LAMP-based websites".
PHP is the bind and sendmail of our times.
PHP is the Bind and Sendmail of our times.
There are tons of badly written apps coded in PHP that ignore basic security considerations. Quite often it is these that provide the way in for such phishers. This article doesn't do enough to highlight the crux of the problem. It seems more about generating hysteria than the public service aspect of proper journalism or research.
PHP apps are quite often the "bad userland" sitting on a robust core similar to what Windows often suffers from.
Not surprised the same sites are repeatedly compromised.
If you got through once, why not try it again? They probably haven't replaced the clueless programmers so you're likely to find the same or similar flaws again. Who needs to reinvent the wheel for every phishing expedition?
Careful what you have on LAMP
A lot of LAMP stacks include as standard things like munin, phpmyadmin etc. You can tie down your own code, but these 'user-friendly' tools are so common and you're relying on a third party to get their security right... Be very careful on the tools you offer.
This is what directory authentication is for. Force SSL and setup basic authentication on each directory for the "user-friendly tools" you use. You should do this on any /admin directories in WordPress, Joomla etc.
Now attackers have to brute force the Apache authentication before they can exploit any vulnerability in the web apps themselves.
Yes, you'll have to login twice, security vs convenience, say hello.
It would be nice if the report broke down "Other" so that readers can make up their minds. What about vulnerabilities with nginx or lighttpd (other web servers not mentioned), or Django or Ruby on Rails (other platforms not mentioned). But that's not my biggest problem.
The report stated "Attack victims reported that they used ... PHP/Java as their application platform in 82 percent of responses." So is it PHP or Java or both? If so, why not break down the figures so that people can make up their minds?
Fucking hell - that's just incompetence to mix two different languages and present it as one to the user.
Re: Report Fail
The vulnerability lies with the application written in php, not with the operating system itself. If you have a web application that is programmed to allow remote access to the system, it will allow remote access to the system no matter how secure the operating system, web server, database server etc is.
Similarly if you configure the system so the root or administrator account has no password, or the password is something obvious like "administrator", "root", "password", or the name of the company, and allow remote desktop or ssh access to the system, then people are likely to log in and do things.
It's the economy, stupid!
As pointed out by others, the article is disingenuous: the problem is not the Stack, but the apps running on the stack. One of my sites also got broken into, which really p*ssed me off ... it was one of those popular media wiki things, which I immediately killed and the problem went away. Now I'm just worried about all the Wordpress sites, which are a favourite attack vendor. I can't upgrade Wordpress because the new versions require a more recent MySql, and I can't upgrade MySql because it requires a whole new version of BSD, and that is not a trivial exercise .... :-)
Have to build a new server from scratch. I'm sure there are many sites with similar problems. When you have mission-critical sites running 24x7, you can't just upgrade software while they're running....
How many of these sysadmins are *paid* to do this job?
If they are not then maybe they are doing the best they can given the amount of time they have to devote to maintenance.
But if they are...
You don't realize your site could be useful to attack others? You can't detect intrusion attempts through router logs? You can't re-configure servers and directory trees with non obvious/standard names?
You're employer is wasting their money paying you. You're not really a sysadmin. You're an IT gimp.
Note the measure of *any* environments popularity is how often it's attacked. Despite shedloads of cash on MS's part that is still *not* Windows.
This can be fixed by setting register_globals to off...?
Surely a lot of the problems can be fixed by turning off the variable REGISTER_GLOBALS in the php.ini?
host provided tools
The hosting providers who offer lamp often bundle in a shed load of applications to manage it, phpmyadmin etc. And they put them in the default directories with default passwords.
How many people go in and change this?
Also theres the scenario you often find (or I have anyway) when I rip out all the extra bits of "value added extras" from the web root, change the server to log in only with keys etc, then their tech support power cycles the box, and issues a passwd at runlevel 1 to change the root password back to their own even though I have reported no faults and I don't have support in my service plan, as "a audit has revealed the password did not match records",l I encrypted some partitions that mount after boot and put my data in there after that one...
With joomala etc, script kiddies mine google for affected versions and just go and compromise everything that returns a version string matching from google with a script. If you edit the version displayed to something non standard, the bots and scripts cruise on by. Your just making life too easy for them...
So, amp = good, how its implemented in the real world by people with no clue, turd.
1st rule of effective bullying.
Why *bother* going looking for a new victim (who might fight back better) when you come back and stomp the old one.again.
I think some of the posters on this thread have given out some *very* valuable advice to people who are not (but perhaps need to be) better informed about this threat.
Weather it *changes* anything about how they handle their problems (assuming they can work out what to do) is another matter.
- Product round-up Too 4K-ing expensive? Five full HD laptops for work and play
- Review We have a winner! Fresh Linux Mint 17.1 – hands down the best
- Vid Antarctic ice THICKER than first feared – penguin-bot boffins
- 'Regin': The 'New Stuxnet' spook-grade SOFTWARE WEAPON described
- You stupid BRICK! PCs running Avast AV can't handle Windows fixes