Malware Attack Infected 25,000 Linux/UNIX Servers 220
wiredmikey writes "Security researchers from ESET have uncovered a widespread attack campaign that has infected more than 25,000 Linux and UNIX servers around the world. The servers are being hijacked by a backdoor Trojan as part of a campaign the researchers are calling 'Operation Windigo.' Once infected, victimized systems are leveraged to steal credentials, redirected web traffic to malicious sites and send as many as 35 million spam messages a day. 'Windigo has been gathering strength, largely unnoticed by the security community, for more than two and a half years and currently has 10,000 servers under its control,' said Pierre-Marc Bureau, security intelligence program manager at ESET, in a statement.
There are many misconceptions around Linux security, and attacks are not something only Windows users need to worry about. The main threats facing Linux systems aren't zero-day vulnerabilities or malware, but things such as Trojanized applications, PHP backdoors, and malicious login attempts over SSH. ESET recommends webmasters and system administrators check their systems to see if they are compromised, and has published a detailed report presenting the findings and instructions on how to remove the malicious code if it is present."
There are many misconceptions around Linux security, and attacks are not something only Windows users need to worry about. The main threats facing Linux systems aren't zero-day vulnerabilities or malware, but things such as Trojanized applications, PHP backdoors, and malicious login attempts over SSH. ESET recommends webmasters and system administrators check their systems to see if they are compromised, and has published a detailed report presenting the findings and instructions on how to remove the malicious code if it is present."
next they will say Mac's get viruses (Score:5, Funny)
April fools is here early
From the Article (Score:5, Informative)
From the Article
No vulnerabilities were exploited on the Linux servers; only stolen credentials were leveraged.
We conclude that password-authentication on servers should be a thing of the past
http://www.welivesecurity.com/wp-content/uploads/2014/03/operation_windigo.pdf
Nuff said.
Re: (Score:2)
Maybe those credentials were posted on github [forbes.com] by devels and then scraped from there. Or from google, there is a bunch of id_rsa that pop up with trivial searchs.
Anyway, 25.000 linux/unix servers looks like a very low number, considering the 500.000.000 servers running apache or nginx [netcraft.com], even with multiple domain hosted in a lot of them.
Re: (Score:2)
Plus of course those servers compromised servers maintained a suspiciously low profile not doing anything naughty other than trying to compromise other servers. This really stinks of a government agency at work, setting up 'long term' espionage routes. I wonder which one?
Re: (Score:2)
Maybe those credentials were posted on github [forbes.com] by devels and then scraped from there. Or from google, there is a bunch of id_rsa that pop up with trivial searchs.
Anyway, 25.000 linux/unix servers looks like a very low number, considering the 500.000.000 servers running apache or nginx [netcraft.com], even with multiple domain hosted in a lot of them.
Is that "better" [zone-h.org]? That were over a million Linux servers defaced in 2010, most of them actually rooted.
Re: (Score:2)
Well, with only 25k infected, these may well just be really bad passwords.
I conclude that password authentication on servers is alive and well, as long as done right.
Re: (Score:2)
Depends on the service and whether it does rate-limiting of attack attempts.
For SSH-based services? There's really no excuse not to use a password-protected SSH public key pair, and turn off password-authentication for SSH. Plus disallowing the ability for "root" to login over SSH. It raises the bar by an order of magnitude. Unless the attackers can get a copy of your private key file, and the password to de
Re:From the Article (Score:5, Informative)
What other fucking form of authentication is there? Certs? Those are just strings - like a password. Encrypted certs? What are you encrypting them with?
It all comes down to a secret someone has too know. Call it a key, a cert, a token, whatever, it's a fucking password at the end of the day.
If your auth'ing with a username / password on an infected server you're actually *sending* your credentials to the server. This is not he case wih a cert auth, especially when you use ssh-agent to hop to other servers.
Re: (Score:2)
DoD uses SmartCard certs + password for login. It is a little different to set up, but works perfectly fine. And getting in requires you to get the card AND the password. the card will lock itself permanently after 3 failed attempts, BTW.
Down side: multiple physical logins are impossible. however, remote access does the trick nicely.
Re: (Score:2)
Could you please come meet me first thing in the morning?
-your field supersivor
Re: (Score:2)
The thing is that smart card is really just a second password. If used on windows you can even fake it with the old pass the hash.
Re:From the Article (Score:5, Informative)
Probably more accurate to say that you mathematically prove that you have your credentials, but you never actually send them to the server.
Re: (Score:3)
Maybe. But don't forget certs are only used to authenticate you. The authorization is made on the server and the authorization part is what is really meant by credentials:
"A credential is an attestation of qualification, competence, or authority issued to an individual by a third party with a relevant or de facto authority or assumed competence to do so."
https://en.wikipedia.org/wiki/... [wikipedia.org]
Certs only authenticate you, making sure who you are. Perhaps wrongly, we sometime use "credentials" in a more permissive
Re:From the Article (Score:5, Informative)
The cert provides the server with your public key and an attestation from a third party that the public key belongs to a particular party. Once the server is satisfied with the validity of the cert for this particular account, it does this:
Most notably, at no time did your actual credential, the private key, exist in any place except in your machine. For bonus points, you can password-protect that private key, which will involve using your password as a key to a symmetric cipher to encrypt your private key.
You know *nothing* about security (Score:5, Informative)
Um, no, You're *FULL* of bullshit if you talk about certs that way. You obviously don't have a clue.
Key differences between public key auth ("certs") and password auth (no particular order): /. users I know...).
1) You can re-use your public key with multiple sites and even if one of them is actively malicious, it doesn't help them break into the others. Not so with passwords.
2) Passwords, or at least verifiers for them, must be stored by all sites you use the password with. Public keys don't do an attacker any good at all even if they compromise a service on which you used the same credentials as their real target.
3) Public/Private keypairs are automatically generated by programs that filter the results for security. Passwords are often generated by people who don't know a thing about security (like some
4) Passwords are short, intended to be remembered and typed. Asymmetric keys are long, meant to be transported as files (or certificate blobs). The former is vastly easier to brute force (an extremely strong password might take weeks on typical commodity hardware but most would only take minutes) than the latter (factoring some sub-1024-bit RSA public keys - weaker than any in serious use today - has been an open challenge for *years* and the best we've managed before required the resources of a university supercomputer working for weeks).
5) Public Key Infrastructure certificates include mechanisms like expiration and revocation. Passwords have no such protection and must be manually changed or reset in the event of a potential compromise.
6) Private keys can (and should be) protected with passwords, making them in effect a form of two-factor authentication (you HAVE the key, you KNOW its password). Passwords are a single factor.
7) A password gets much harder to use as its length increases, and the strength doesn't always increase as a factor of length because long passphrases are more likely to be generated with predictable rules to aid memorization. Public keys can be made thousands of times as strong without making them any less convenient for the user (aside from an increase in the one-time generation time, a slight increase in authentication time, and a bit more bandwidth used).
8) A password is, almost by definition, short enough to memorize or at least write down in a reasonable time. Very few humans could ever manage to memorize even a 1024-bit key pair; anything much stronger is right out. Calling it "a secret someone has too[sic] know" is simple idiocy.
9) Certificates can be used over unsecured connections (in fact, they're how we establish secure connections). Passwords sort-of can (SRP) but the typical usage of them requires a protected channel as an eavesdropper otherwise can steal your credentials, and SRP requires that the password be communicated to the server out-of-band (typically over a connection secured with public key crypto...)
Don't get me wrong, passwords have advantages (mostly in matters of convenience at a cost to security, but a secure system that is so inconvenient to use that nobody ever does so isn't any better than no system at all). I'm not saying we should do away with them. It was just painful to read the complete nonsense in your post, and I felt I had to set the record straight lest some other ignorant fool mistakenly believe you to know what you're talking about.
Re: (Score:2)
>8) A password is, almost by definition, short enough to memorize or at least write down in a reasonable time. Very few humans could ever
>manage to memorize even a 1024-bit key pair; anything much stronger is right out. Calling it "a secret someone has too[sic] know" is
>simple idiocy.
I think you are overestimating this a bit; a 1024 bit RSA key is worth about 80 bits of password strength.
an 80 bit password is really not to hard to memorize.
Here is an example: "held boat upon toward fish party long
Re: (Score:2)
Well I guess this is obligatory:
https://xkcd.com/936/ [xkcd.com]
Re: (Score:2)
True, but 1024 bit keys are on their way out as insecure. Your argument would have been better made about a my points #3 or #4. Just because there's only about 2^80th values you need to search for a 1024-bit key doesn't mean you can memorize a kilobit of seemingly-random data (I was refuting the argument that a cert is just "something you have to know").
Still, you have a good point about there being good passphrase-generation options available. I see somebody already posted the obligatory XKCD...
Re: (Score:2)
I think you are overestimating this a bit; a 1024 bit RSA key is worth about 80 bits of password strength.
How do you know this? Is there some equation or strength tester I can use to calculate the strength of my keys vs. my passwords? (I know about, for example, the strength meter in KeePass, which I love; an equivalent for my keys would be interesting. And yes I do realize they aren't directly comparable due to the differences between how PKI and passwords work; I just found the statement of equivalency intriguing.)
Re: (Score:2)
Re: (Score:2)
the longer one, i guarantee that.
special chars are pretty useless.
Re: (Score:2)
"g}x6I13t-ubO{" worth ~40 bits of entropy
"held boat upon toward fish party long trade" is worth ~85 with a perfect knowledge of the rules and dictionary, ~170 without.
Re: (Score:2)
6) Private keys can (and should be) protected with passwords, making them in effect a form of two-factor authentication (you HAVE the key, you KNOW its password). Passwords are a single factor.
The authentication tokens in "two-factor" authentication should be independent, and both should be required for access. Encrypting a key does not increase the number of tokens required for authentication.
No vulnerabilities (Score:3)
Having said that, your users will surely allow some clown on board because THEY lost THEIR creds; so watch your permissions, etc., and back u
Re:You know *nothing* about security (Score:4, Insightful)
4) Passwords are short, intended to be remembered and typed. Asymmetric keys are long, meant to be transported as files (or certificate blobs). The former is vastly easier to brute force (an extremely strong password might take weeks on typical commodity hardware but most would only take minutes)
This bit is false, an extremely strong password still cannot be brute forced (once you get over ~10 characters long, even an Amazon E3 instance [arstechnica.com] starts taking unrealistic times to brute force it). Most password cracking, even GPU powered, relies on passwords being either short or sufficiently non-random.
Re: (Score:3)
Markov chaining and some clever guesses about rule generation bring that down immensely, but it is true that a *comprehensive* brute force rapidly becomes infeasible... except practically nobody uses completely random passwords at all (save for those generated and stored by tools) and the handful of people who do use them (in the sense that a normal password is used, i.e. memorized and entered without outside aid) will generally use ones shorter than 10 characters.
Still, you are right (although it's worth n
Good advice that should be repeated (Score:3)
Private keys can (and should be) protected with passwords
Far too many of the people that think security only means "use keys not passwords" forget that it's a damn good idea to have a password on the key. Having the password on the key means that is someone steals a laptop or USB stick with the key on it they still can't get in.
Re: (Score:2)
Sigh... At account setup time, the server generates the verifier using the password. The password can then be safely discarded, the server need never (and should never) see it again post-setup. However, that initial process - getting the verifier stored in the server's database - does require an out-of-band communication of password-equivalent material (if you want to be really pedantic about it). Unless that communication is secured in some way - probably public-key auth, if done over the Internet - an att
Re: (Score:2)
Not all are created equal. For example, an SSH key will be a lot harder to crack than a regular password.
Re: From the Article (Score:2)
Re: (Score:2)
I guess his point was that you usually need a passphrase to make a private key usable. Unless the private key is not password protected. At the end of the day, private key + password protected key is most often recommended.
Re:next they will say Mac's get viruses (Score:4, Informative)
Back in the late 90s, Macs had over a 1000 viruses, linux, less than 10. (It's been a few years, I forget the exact numbers.)
Did those infections occur a lot? No, but it did happen sometimes.
After all, there's a huge benefit to NOT being the most common user OS. Those scum writing the malware usually want to hit as many victims as possible, and if there's an OS that has 70% or more of the desktops out there, it's pretty obvious what they will aim for.
If you want to continue to believe marketing and fanboys, that's up to you, but don't be surprised when you get infected by some kind of malware for not taking the proper precautions because you believe in computing myths and the protective power of obscurity is magically unbeatable.
By the way, I've done the tech support, and have seen the reality, this isn't just some random opinion. If you don't believe me, that's your problem.
Re:next they will say Mac's get viruses (Score:4, Informative)
Re:next they will say Mac's get viruses (Score:4, Informative)
While OS X is based heavily on NeXTSTEP (and most developer API class names on the Mac are prefixed "NS"), I wouldn't go so far as to say there is no relationship between the "classic" Mac OS and OS X. OS X's standard filesystem is HFS+, which was released in 1998 with Mac OS 8.1, and which shares the same format as its predecessor, HFS. And decisions and limitations from those days still unfortunately put their marks on OS X. For instance, the Labels feature from Mac OS which was bolted back onto OS X (after much public outcry) are still stored in the same place on the filesystem, and in the same format (bit fields), as they were in 1988! And the new tagging feature introduced in Mavericks, for the sake of backwards compatibility with Labels, uses this same area and format [arstechnica.com] to record Tag information! And of that, only three bits are available for storing color information on HFS+. This is why Labels-cum-Tags are limited to the same seven damn colors Mac OS had when Ronald Reagan was still president of the USA.
Re: (Score:2, Informative)
God Damn people!
XNU operating system is not FreeBSD based! It use parts of the FreeBSD but is not based to that!
Parts from FreeBSD are filesystems and network stack. Everything else in XNU operating system is Mach microkernel and I/O Kit.
The FreeBSD filesystem and network stack is just 1/5 of the XNU operating system and not even the most important part the microkernel (or as lazy would call, kernel).
In other hand, can we call Android is Linux based? Sure. Can we call Android is Linux based OS? No. Why not?
Re: (Score:2)
They do, no joke, and they have for many years.
Back in the late 90s, Macs had over a 1000 viruses, linux, less than 10. (It's been a few years, I forget the exact numbers.)
Oh yea, it was awful for them. It was you purchased a Mac, learned to program and wrote virus's; or sure seemed the path of a Mac user.
If I had to have a favorite virus it would of been the Mac Energizer Bunny, while the Bunny banged a drum, and rolled across the bottom of your screen, your hard drive was being formatted.
One friend mentioned that one at a time the letters on his display would just fall down and into a pile at the bottom of the display.
It wasn't the OS to run.
Re:next they will say Mac's get viruses (Score:5, Informative)
That's assuming the malware is targeting end user workstations... The malware discussed in this article explicitly targets servers, and linux is far from an obscure platform when it comes to servers.
There are many other reasons than lack of desktop users why there is less malware for linux... Linux users are far less likely to be running with admin privileges, linux users have to take extra steps to execute a random binary, linux users are less likely to want to execute random binaries due to the prevalent use of repositories, linux users are generally more savvy than windows users, linux users are more likely to have updated their applications (again due to repositories)...
Also the idea of "security through obscurity" is usually promoted by proponents of closed source, who somehow think that restricted distribution of the sourcecode will prevent people from finding exploitable holes.
misconceptions about any type of security (Score:2)
Who'da thunk (Score:5, Insightful)
A weak root password and public facing root SSH access is bad?
Managing a Linux box with a publicly facing web based interface bad?
Installing untested web based applications released as freeware with no idea what the code does is bad?
Re: (Score:2)
A weak root password and public facing root SSH access is bad?
Managing a Linux box with a publicly facing web based interface bad?
Installing untested web based applications released as freeware with no idea what the code does is bad?
The analysis in the PDF suggests that the majority of passwords used in this were not weak.
Re:Who'da thunk (Score:4, Interesting)
It's something to watch out for with IPv6 and all of us getting internet facing machines again - a firewall on the router is not enough to protect us from traffic on ports we want to pass through (unless we want to stop all incoming ssh or redirect it to the router - good in some circumstances but what if someone wants to log directly into their box while travelling?)
The state of Linux (Score:5, Informative)
Linux is now big enough with all the Android deployments on top of the server infrastructure that there is going to be increasing amounts of effort aimed at exploits. Unfortunately there is a lot of pressure to hurry applications to market and make upgrades to the OS. That means more pressure and opportunities to create exploitable errors. Unless both the Linux community and the application developers up their game we're going to be in the era of owned Linux handhelds and boxes.
Re:The state of Linux (Score:5, Funny)
I work as a consultant for several fortune 500 companies, and I think I can shed a little light on the climate of the open source community at the moment. I believe that part of the reason that open source based startups are failing left and right is not an issue of marketing as it's commonly believed but more of an issue of the underlying technology.
I know that that's a strong statement to make, but I have evidence to back it up! At one of the major corps(5000+ employees) that I consult for, we wanted to integrate Linux into our server pool. The allure of not having to pay any restrictive licensing fees was too great to ignore. I reccomended the installation of several boxes running the new 2.4.9 kernel, and my hopes were high that it would perform up to snuff with the Windows 2k boxes which were(and still are!) doing an AMAZING job at their respective tasks of serving HTTP requests, DNS, and fileserving.
I consider myself to be very technically inclined having programmed in VB for the last 8 years doing kernel level programming. I don't believe in C programming because contrary to popular belief, VB can go just as low level as C and the newest VB compiler generates code that's every bit as fast. I took it upon myself to configure the system from scratch and even used an optimised version of gcc 3.1 to increase the execution speed of the binaries. I integrated the 3 machines I had configured into the server pool, and I'd have to say the results were less than impressive... We all know that linux isn't even close to being ready for the desktop, but I had heard that it was supposed to perform decently as a "server" based operating system. The 3 machines all went into swap immediately, and it was obvious that they weren't going to be able to handle the load in this "enterprise" environment. After running for less than 24 hours, 2 of them had experienced kernel panics caused by Bind and Apache crashing! Granted, Apache is a volunteer based project written by weekend hackers in their spare time while Microsft's IIS has an actual professional full fledged development team devoted to it. Not to mention the fact that the Linux kernel itself lacks any support for any type of journaled filesystem, memory protection, SMP support, etc, but I thought that since Linux is based on such "old" technology that it would run with some level of stability. After several days of this type of behaviour, we decided to reinstall windows 2k on the boxes to make sure it wasn't a hardware problem that was causing things to go wrong. The machines instantly shaped up and were seamlessly reintegrated into the server pool with just one Win2K machine doing more work than all 3 of the Linux boxes.
Needless to say, I won't be reccomending Linux/FSF to anymore of my clients. I'm dissappointed that they won't be able to leverege the free cost of Linux to their advantage, but in this case I suppose the old adage stands true that, "you get what you pay for." I would have also liked to have access to the source code of the applications that we're running on our mission critical systems; however, from the looks of it, the Microsoft "shared source" program seems to offer all of the same freedoms as the GPL.
As things stand now, I can understand using Linux in academia to compile simple "Hello World" style programs and learn C programming, but I'm afraid that for anything more than a hobby OS, Windows 98/NT/2K are your only choices.
thank you.
Re:The state of Linux (Score:4, Funny)
Thank you for that delightful trip back to the year 2000. Tell me, did you warn them?
Obvious cluelessness is obvious (Score:3, Insightful)
Obvious red flag showing no clue about the topic - it's just buzzword bingo throwing impressive sounding verbage around with a lack of understanding.
If it was a fanboy they really need to lift their game if they want to avoid other fanboys laughing at them.
If it was some "media studies" person acting as a paid social media shill then whoever paid them got ripped off.
Re: (Score:2)
Obvious red flag showing no clue about the topic - it's just buzzword bingo throwing impressive sounding verbage around with a lack of understanding.
"VB" is impressive sounding verbiage?
Re: (Score:2)
To be an obvious joke it needs to be funny (Score:2)
Re: (Score:2)
Re: (Score:2)
Your UID suggests you should have seen this style of troll back when it first came around - a quick google [google.co.uk] returns dozens of hits for slashdot alone. It's intended as a joke, and is mocking the mindset (less present now than it was then) about UNIX/linux being seen by people who never got fired for buying IBM/Microsoft/Oracle as both too basic for business but yet still somehow intractably complicated.
So... whoosh. You might not find it funny but it's certainly not deadly serious and certainly isn't going "
It needs to be funny (Score:2)
Re: (Score:2)
You sound like you're a lot of fun, and I would like to subscribe to your newsletter.
Obvious "nerds suck" troll is not a joke (Score:2)
Re: (Score:2)
Of course it was - clearly some little cowardly shit playing troll games and then trying to pretend it was a joke.
Re: (Score:2)
An Englishman, an Irishman and a Scotsman walk into a bar. They see dbIII sitting inside with a pint of bitter and a baleful look in his eyes and immediately decide to leave and have fun elsewhere.
Re: (Score:2)
Re: (Score:2)
This has become incredibly meta. Your histrionics at the perceived personal slight from a 15-year old troll post has become more trollish than the original post itself, only without any perceivable sense of humour or irony. You are Nathan Poe and I claim my five pounds.
Re: (Score:2)
Re: (Score:2)
I'll stop "whining" as you call it once your mum starts giving better head.
Re: (Score:2)
it might take some recent history knowledge and whatnot, but this is a really great troll post. some sentences are pure fun on their own :)
Re: (Score:2)
My experience has been the exact opposite. We started way back in the day with all Windoz servers. These were a constant source of headache. They would crash and need reboots weekly. Sometimes things would fail for no apparent reason without any means of fixing them short of reinstalling Windows. We started installing a few Linux servers for radius, DNS, HTTP. These didn't fail and one by one we replaced the Windoz boxes with Linux boxes.
Life is much better now and I spent very little time with server maint
Re: (Score:2)
The truly typical Linux installations - that is, the ones found in TVs, set-top boxes, cable modems, routers, "smart" appliances, and so on - are configured extremely insecurely. There are typically remote management backdoors and such, but even if there aren't, the systems usually use horribly outdated software, have exposed (vulnerable) servers, and run everything as root. Serious exploit mitigations like SELinux are almost unheard-of.
Linux servers, assuming a competent admin, are generally very secure. O
Re: (Score:2)
Re: (Score:2)
Mostly because they are made by companies that do not hire engineers for thier OS but use one of the janitors or an IT guy that knows linux.
NEC Tv's you can easily get into Root from the serial port if you are fast enough when the TV boots. from there it's trivial to have some fun.
Re:The state of Linux (Score:4, Informative)
Except if you had read the report, you would realize that this is not about a security exploit, this is about stolen administrative credentials. No one is using new vulnerabilities in the Linux operating system. This is malware that works on *nix specifically, but what it ends up doing is not *nix specific - it simply steals passwords and uses them to manually propagate the infection.
In the end, the blame lies with server administrators running networks porous enough to be infected at deployment time, and who are not using two-factor auth to guard the keys to the castle. This isn't about the "Linux community" so much as it is about organizations and their admin practices.
Re: (Score:2)
This is nitpicking, but if your admin credentials get stolen, somebody is exploting a security weakness. Not a design weakness, maybe, but an operating weakness. It's still a security weakness.
Re: (Score:2)
There you go bring in truth and reality into the whole FUD story.
This is Wednesday, we are all supposed to wave our arms in the air and scream how insecure linux is and Windows is the future.
Tomorrow is dog on QNX day, bring your own lunch.
Re: (Score:3)
The sort of blind trust you seem to have due to "Linux changing at an unprecedented rate" is probably the greatest security threat.
Interest in Linux malware is also increasing at unprecedented rates due to Android. For now, most efforts are focused on Android's JRE and trojanized hacked apps/games but it may only be a matter of time until they start seriously pursuing more difficult targets.
...and, btw, we sell anti-virus software for linux (Score:4, Funny)
Re: (Score:2)
Perhaps I deserve to lose my Geek Card, but I don't get it.
Ah, then no need to run the scans, just purchase and install the AV in that case.
Misconceptions My Ass (Score:2)
Re: (Score:2)
Re: (Score:2)
The big problem with Linux security. (Score:4, Insightful)
The best locks in world, which Linux does come with, do not help if the door is left unlocked.
Microsoft OTOH has no doors.
The biggest threat to linux in the last five years has not been the architecture of linux, but the willingness of programmers, in particular weak programmers from the WIndows world coming over and applying the same philiosophies to linux development.
Re: (Score:2)
You don't pay attention much do you?
Re:The big problem with Linux security. (Score:5, Informative)
Not sure where the "proper ACLs had to be bolted on" comes from, as ACLs predate even Unix, much less Linux. The Unix-style ACLs were well established when Linux, or even it's inpiration Minix, was first created. I'll readily grant the clumsiness of the 12-bit ACL system, though.
On *nix systems, file system objects *are* how processes, sockets, and so on are represented. Not sure about synch objects, but in general, Linux does in fact have access controls on most of the same types of things as NT, because those things are accessed using the file system, and are protected by the file system access controls. NT took a different route, making the entire file system be children of the common root (which also has devices, registry hivs, and so on) instead of using the unified root of the file system as the common root of all securable objects the way *nix does it.
These days, though things like SELinux, Linux actually has better support for the PoLP than NT does. That's not to say it's widely used to its full effect, but that's true on both platforms.
Don't get me wrong, I like the NT model. But I don't like it so much I'm going to just ignore the flaws in what you say.
Re: (Score:3)
Please correct me if I'm wrong, but I think you may be confusing file permissions with ACLs; the two are not the same thing. ACLs only started appearing in common filesystems in the 90's and to use them in the early days of linux you'd frequently have to force the enabling of xattr (if your filesystem supported it); the first reference I can find to POSIX 1E ACLs in either FreeBSD or Linux is round about 2000 and I started using them myself in 2002, they're still far from common.
Re: (Score:2)
Re: (Score:3)
Is that why Windows and IIS got hacked all the time while Linux and Apache/PHP very rarely ? Because it had better security ?
There was a project for Linux kernel that gives advanced ACL capabilities to Linux systems. I forgot the name of it now, but basically.. whatever was possible to do, you could do it. You don't seem to understand that Linux kernel is not finite like Windows is.
There are hundreds of projects that you can add and use.. (stable, tested projects).
The problem with security is an admin that
Re: (Score:2)
Is that why Windows and IIS got hacked all the time while Linux and Apache/PHP very rarely ?
Citation needed.
Because it had better security ?
Yes, Windows servers are compromised less because it is far easier to set those up securely. Especially IIS+ASP.NET is way more secure than Apache+PHP in almost any way; not least the programming model where PHP almost encourages SQL injections and XSS where with .NET/MVC it is hard to create SQL injections and XSS vulnerabilities.
There was a project for Linux kernel that gives advanced ACL capabilities to Linux systems. I forgot the name of it now, but basically.. whatever was possible to do, you could do it.
ACLs are available with most distros nowadays. However, the point is they are bolted on. They represent a MAC model which competes with simplistic linux file syste
Summary -- root can do anything! (Score:5, Interesting)
The summary states:
but I think this is an inaccurate summary since the Trojan is being installed on machines where the attackers already have root credentials.
Perhaps some unknown vulnerability is also being used to gain root access, but the report does not claim this.
I have admin'ed such a server... (Score:5, Insightful)
As TFS points out, the attackers didn't use a zero-day exploit. They didn't use an unpatched old exploit. They didn't even use the fact that huge "trusted" swaths of the filesystem, including standard executable paths (such as
This system ran a fairly popular POS software suite, and absolutely depended on all its serious security flaws. The vendor had even installed what amount to pre-compromised binaries for "convenience" in diagnosing end-user problems (connect to the right port, bam, you can monitor any user's session). But even that egregious level of incompetence didn't cause the breach.
No, the breach came from the fact that the vendor had their own company name as the root password (and had it hard-coded in literally dozens of (world-readable) scripts, so I couldn't just change it). And did I mention, the vendor required this box have a publicly facing IP or they'd refuse to honor their SLA?
Needless to say, my first action on learning all this, I blocked it at the firewall and told the vendor that we'd let them in when, and only when, we needed assistance. That, amazingly, enough kept the box safe for about a year (and floored me that we hadn't gone down long before I got stuck with that albatross)...
Until an upgrade. Took a total of half an hour. Didn't matter, because we had someone in as root in a tenth that time.
But, distant past. Couldn't happen again, and no other vendor would ever have such an extreme level of cluelessness, right?
So, currently, I work with (but thank Zeus, don't have to administer) a CRM system by an entirely different vendor, running on an outdated Linux distro. Pretty much everything I just said applies to this box. But hey the firewall keeps it safe, except the once-a-year the vendor demands access to audit our license compliance...
So yeah, Linux systems get hacked - For reasons that wouldn't protect the otherwise-most-secure system on the planet. You want to make it stop? Tell your vendors to go fuck themselves when they rationalize having a weak root password, and piss-poor system-wide security, and ban patching known vulnerabilities because it "might" break something the vendor used. Really that simple.
Re: (Score:2)
I saw that one a few years back but that had Win2k under their POS system and it was dialup connectivity (literally phoning home), which at least reduced the attack surface a bit. Management was incredibly disfunctional, knew about the problem, and were sick of IT consultants telling them it was a bad idea. It was a wakeup call for me that for anything you can say about management problems in government there'
Re: (Score:3)
So, currently, I work with (but thank Zeus, don't have to administer) a CRM system by an entirely different vendor, running on an outdated Linux distro. Pretty much everything I just said applies to this box. But hey the firewall keeps it safe, except the once-a-year the vendor demands access to audit our license compliance...
You should set it up so their only ingress is through a reverse ssh tunnel outward. Preferably secured with a key you send to them so their reused passwords aren't the only thing keeping people out. You should also restrict it by IP range to whatever machine they're coming from.
If the vendor refused any of my security stipulations for their audit I'd invite them to come to me and do the audit onsite. Of course they might threaten to shutdown your CRM but then you can always sue for breach, or better yet
Re: (Score:2)
I like to think I would do better today than I did back then - My primary role involves coding, not network hardening. I just tend to get ownership of Linux boxes because, surprisingly, not many folks in the business world (even
Re: (Score:2)
um, vendor names ?
Re: (Score:2)
Vendor name, please? You are not doing anyone any favors by not mentioning who they are.
Re: (Score:2)
But more, because I sadly no longer consider this behavior unusual (it floored me the first time I saw it, as I said - I consider it almost standard procedure, now). Vendors look at Linux as an exploitable free resource, a base platform they don't need to license, complete with an impressive collection of development tools. Except Linux has all these pesky permissions, heck, it doesn't even like l
So is it 10,000 or 25,000? (Score:3)
So is it 10,000 or 25,000? I can't be arsed to read the article, because as another poster succinctly observed "oh no, thousands of infected unpatched Wordpress installations", but it sounds like the ESET people trying to make a quick buck off of some FUD can't even get their FUD straight. As if tripwire hasn't been available for a couple of decades...
Re: (Score:3, Informative)
Read, or don't read the article, your choice. But the level of sophistication will blow your mind.
No, no it really won't.
That article read like the opening page of a third-rate techno-thriller. Once you get past the alarmist dross, you see that people are busy pwning servers just as they always have. Only today - shock, horror - there are more servers around, and some of them are really badly maintained.
25,000 servers is a pretty useful resource for someone with malice in mind. And admittedly, it takes a certain amount of cleverness to amass that many. So yes, these guys aren't completely useless. But i
Re:FreeBSD 9.1 (Score:5, Informative)
Here's the complete check from http://www.welivesecurity.com/... [welivesecurity.com]
The command ssh -G has a different behaviour on a system with Linux/Ebury. A clean server will print
ssh: illegal option -- G
to stderr but an infected server will only print the typical “usage” message. One can use the following command to determine if the server he is on is compromised:
$ ssh -G 2>&1 | grep -e illegal -e unknown > /dev/null && echo "System clean" || echo "System infected"
Re: (Score:2)
Hmm... mine prints "unknown option" (no use of the word "illegal") and then prints usage info.
Re:FreeBSD 9.1 (Score:4, Informative)
Re: (Score:2)
it would be mighty sneaky if there was some sleeper code in openssh that would activate a backdoor on "ssh -G"
Re: (Score:3)
I presume you are using csh or tcsh? The shell that should have been burned and the ashes scattered the day Bill Joy finished it.
You can do this: /dev/null && echo "System clean" || echo "System infectrf"'
sh -c 'ssh -G 2>&1 | grep -e illegal -e unknown >
Re: (Score:2)
Re: (Score:2)
Pretty hard to say, the way you butchered the command.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)