There's an article on slashdot about the Duqu team wiping all their
intermediary c&c servers on 20 Oct. Interestingly, the report says that
they were all (?) not only linux, but CentOS. There's a suggestion of a
zero-day exploit in openssh-4.3, but both the original article, and
Kaspersky labs (who have a *very* interesting post of the story) consider
that highly unlikely, and the evidence points to brute-force attacks
against the root password. Then they update openssh and openssh-server.
And then, at some point, they apparently take an ubuntu/debian openssh
5.9p1 (then p2) source package, and install *that*
My manager suggest updating openssh to block other attackers (who actually
might screw their attack). It still seems odd to me to yum update, then
build the software from source.
Are your root passwords strong?
mark
PS: Oh, yes:
<http://it.slashdot.org/story/11/11/30/1610228/duqu-attackers-managed-to-wipe-cc-servers>
On Wed, Nov 30, 2011 at 12:05 PM, <m.roth at 5-cent.us> wrote:> > Are your root passwords strong?I've always wondered why something as complex as sshd doesn't do anything to protect you from the simplest form of attack - like rate-limiting failed attempts. -- Les Mikesell lesmikesell at gmail.com
On 11/30/2011 12:05 PM, m.roth at 5-cent.us wrote:> There's an article on slashdot about the Duqu team wiping all their > intermediary c&c servers on 20 Oct. Interestingly, the report says that > they were all (?) not only linux, but CentOS. There's a suggestion of a > zero-day exploit in openssh-4.3, but both the original article, and > Kaspersky labs (who have a *very* interesting post of the story) consider > that highly unlikely, and the evidence points to brute-force attacks > against the root password. Then they update openssh and openssh-server. > And then, at some point, they apparently take an ubuntu/debian openssh > 5.9p1 (then p2) source package, and install *that* > > My manager suggest updating openssh to block other attackers (who actually > might screw their attack). It still seems odd to me to yum update, then > build the software from source. > > Are your root passwords strong? > > mark > > PS: Oh, yes: > <http://it.slashdot.org/story/11/11/30/1610228/duqu-attackers-managed-to-wipe-cc-servers>The problem with that theory is that Red Hat has backported patches for all know exploits. I am going to specifically research which exploit they think is being used ... Now, note that people were running 5.2 or 5.3, etc and not 5.7 like they should have been, so there might well have been an openssh exploit available ... just not a zero day one from 4.3. I am very interested and will be researching this thoroughly. My initial gut reaction is that they got in via a password though. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20111130/f6b98404/attachment-0003.sig>
On Wed, Nov 30, 2011 at 12:40 PM, Johnny Hughes <johnny at centos.org> wrote:> On 11/30/2011 12:05 PM, m.roth at 5-cent.us wrote: >> There's an article on slashdot about the Duqu team wiping all their >> intermediary c&c servers on 20 Oct. Interestingly, the report says that >> they were all (?) not only linux, but CentOS. There's a suggestion of a >> zero-day exploit in openssh-4.3, but both the original article, and >> Kaspersky labs (who have a *very* interesting post of the story) consider >> that highly unlikely, and the evidence points to brute-force attacks >> against the root password. Then they update openssh and openssh-server. >> And then, at some point, they apparently take an ubuntu/debian openssh >> 5.9p1 (then p2) source package, and install *that* >> >> My manager suggest updating openssh to block other attackers (who actually >> might screw their attack). It still seems odd to me to yum update, then >> build the software from source. >> >> Are your root passwords strong? >> >> ? ? ? ? ? ?mark >> >> PS: Oh, yes: >> <http://it.slashdot.org/story/11/11/30/1610228/duqu-attackers-managed-to-wipe-cc-servers> > > The problem with that theory is that Red Hat has backported patches for > all know exploits. > > I am going to specifically research which exploit they think is being > used ... > > Now, note that people were running 5.2 or 5.3, etc and not 5.7 like they > should have been, so there might well have been an openssh exploit > available ... just not a zero day one from 4.3. > > I am very interested and will be researching this thoroughly. > > My initial gut reaction is that they got in via a password though.Any luck on the specific attack path yet? The linked article suggests Centos up to 5.5 was vulnerable. -- Les Mikesell lesmikesell at gmail.com
On Tuesday, December 06, 2011 04:45:04 PM Johnny Hughes wrote:> If I had to guess, I would say that the attackers probably developed > their code on CentOS, so they were looking for a CentOS machine to > deploy their code on in the wild. That would be why I would say CentOS > was the OS used.I read the Kaspersky article and the comments, and the use of 'up2date' in the transcript could possibly point to someone used to upstream EL. But it does illustrate three major points: 1.) Keep up to date as much as possible (and a 24 hour window is quite short, honestly, compared to the timeframes this attack appears to have occupied); 2.) Keep up with your servers and have tripwires for modifications; 3.) Keep good passwords. This can't be stressed enough: if your password was successfully brute-forced it is now in the brute-forcer's *dictionary* of passwords to try in the future and should never be used again, regardless of how secure it might seem. I happen to have a copy of an older brute-forcer dictionary here (somewhere) and it's very large and has lots of very secure-seeming passwords in it. Of course, this points to a fourth (and fifth) item: don't run services you don't need, and have multiple layers of security.
On Tuesday, December 06, 2011 04:58:42 PM Lamar Owen wrote:> I happen to have a copy of an older brute-forcer dictionary here (somewhere) and it's very large and has lots of very secure-seeming passwords in it.I ran down the copy I have; here's an excerpt of one of the dictionaries: ++++++++ root:P7zkJTma root:5D8DY22 root:mc99ZR34Z root:IVEUFc root:JJc9DicA root:zzzzzzz root:4m3ric4n root:3nglish root:g0v3rm3nt root:4zur3 root:bl4ck root:blu3 root:br0wn root:cy4n root:crims0n root:d4rkblu3 root:d4rk root:g0ld ++++++++ Yeah, some of those would ordinarily be relatively secure-seeming passwords. In the copy I have, there are 5 dictionaries, totalling 68,915 username/password pairs. The brute-forcer this was taken from does not require root, it can run on any user. Look for a directory named '.joker' on your filesystems; you might find the one I found.....
On Tuesday, December 06, 2011 05:31:58 PM Fajar Priyanto wrote:> Dec 7, 2011 5:58 AM Lamar Owen <lowen at pari.edu> ??: > >I happen to have a copy of an older brute-forcer dictionary here (somewhere) and it's very large and has lots of very secure-seeming passwords in it.> Why not don't allow root login from ssh? That's basic yet effective.This particular brute-forcer didn't require root access to spread. It can work under a normal user without any problem.
On Wed, 2011-11-30 at 13:05 -0500, m.roth at 5-cent.us wrote:> There's an article on slashdot about the Duqu team wiping all their > intermediary c&c servers on 20 Oct. Interestingly, the report says that > they were all (?) not only linux, but CentOS. There's a suggestion of a > zero-day exploit in openssh-4.3, but both the original article, and > Kaspersky labs (who have a *very* interesting post of the story) consider > that highly unlikely, and the evidence points to brute-force attacks > against the root password.*DISABLE* password authentication on public-facing [and preferably all] servers. Isn't that securing a server rule#1? Use shared-key authentication.
On Wednesday, December 07, 2011 05:48:24 AM Adam Tauno Williams wrote:> *DISABLE* password authentication on public-facing [and preferably all] > servers. Isn't that securing a server rule#1?Interestingly enough, there are vulnerability scanning tools out there that will flag the lack of a password prompt as indicating that no password is required.... one such tool, which I can't name, is very popular in the PCI-DSS compliance industry. In my particular case, I was able to convince the person running the scan that ssh with key-based security was better than passwords; but I could see where others would not be swayed, and would insist that having a password prompt is more secure..... (of course, that somewhat ignores how key-based auth works, but when you are just reading the scan tool's output and taking it as fact......)
On Wednesday, December 07, 2011 04:59:52 AM Nicolas Thierry-Mieg wrote:> alphanumeric only isn't so secure-seeming is it? Is this for admins who > log in with a cell phone instead of a real keyboard? ;-) > seriously: I thought the consensus was that a secure password should > contain at least one or more non-alphanumeric characters.Further down in the password files some 'patterned' symbol passwords are to be found, for more than the root user. Things like the obvious: p at ssw0rd !@#$% let!ME!in T!m0+#y (Timothy, if you haven't figured it out, and it just so happened that it was paired with the username 'timothy' ala slashdot). And there were various iterations of those, with differing lengths and such. But I'll emphasize that the one I found was very rudimentary, and I found it several years ago. Algorithmic brute-forcers can be much more sophisticated than that. I also found in the searches that I made that there have been numerous instances of the first password tried working and getting in. I have to wonder if the chosen user is based on a leak of information from something like a web forum, or a hotmail account, or something else that has gotten hacked. Don't reuse passwords, in other words. (easier said than done, unfortunately). Basically, if any account you have is ever compromised through password login, assume that password has made it into someone's dictionary. And I'm not talking just ssh accounts here. I'm thinking about the large e-mail/password lists recently released by lulzsec, for instance. The blackhats I'm sure have many more such lists that haven't been exposed yet. And I agree with Johnny (and others) that disabling password auth and using keys for SSH access is a way to go; the fly in that ointment is mitigating private key loss and having a mechanism in place to rapidly revoke keys in a secure manner. That and other avenues of access are used that involve web applications, etc, that bypass SSH-oriented controls. Two-factor auth is better; but even that is foolable (biometrics, even; Mythbusters defeated simple fingerprint scanners several years ago.....). Layered security works best; but 'working best' doesn't mean '100% effective.'
On Wednesday, December 07, 2011 05:32:00 AM Ljubomir Ljubojevic wrote:> There is also use of denyhosts and fail2ban. They allow only few > attempts from one IP, and all users can share attacking IP's (default is > every 30 min) so you are automatically protected from known attacking > IP's. Any downside on this protection?Botnets. If a 100,000 host botnet hits you with a coordinated brute-force attack, fail2ban and other similar tools won't help you, as every attempt will come from a different host. This may be one way the brute-forcers appear to get in on the first or second try. And some brute-forcers are the so-called 'slow' brute-forcers that try things very slowly and never trigger some of these protections. And don't let your guard down just because you have disabled password login and have key-based auth; if a remote exec breach is found in a different daemon that can write (or can execute a local root exploit that can then write) to /etc/ssh/sshd_config, it's game over. This is where SELinux in enforcing mode with properly configured contexts and no unconfined users can save the day. Attach access rights to sshd_config to a local console user or similar (that's one thing ConsoleKit and PolicyKit are for) and make certain other files are not writeable remotely as well. Don't let your guard down because you have things firewalled, either. As RSA found out the hard way, all it takes is one employee opening one excel attachment with an embedded flash exploit, and 'blammo' you're pwned. And if you think these sorts of contrivances aren't out in the wild, think again. I have an example from the 'wild' that, once I have all the data in hand and permission to release it, will blow your mind.
On Wednesday, December 07, 2011 12:30:27 PM Rui Miguel Silva Seabra wrote:> The fact that they immediately (first thing, actually) did was to > upgrade OpenSSH does suggest that there is a Zero Day bug around.While at first blush that would appear to be so, it may be that the openssh was upgraded to get a valuable tunneling feature not present in the CentOS5 openssh (reading through the comments on the Kaspersky item).
On Wednesday, December 07, 2011 10:44:10 AM Michael Simpson wrote:> SELinux is great but didn't save Russell Coker from having his play > machine owned with the vmsplice exploit.> http://etbe.coker.com.au/2008/04/03/trust-and-play-machine/ > http://www.coker.com.au/selinux/play.htmlIn this particular instance, the 2.6.23 kernel introduced a setting that is a workaround for the general NULL dereference to page zero case, and it requires SELinux to be in enforcing mode to work. Whether upstream backported that to 2.6.18 (in EL5) or not, I don't know. That fix is assuredly in the EL6 2.6.32+patches kernel. April 2008 is a long time ago in terms of SELinux. Russell is quite the brave soul for doing this sort of thing. Nothing is 100%, of course. That is a given.> RSA also showed that social engineering is still an excellent vector.Social engineering is the biggest problem, bar none.> Rigorous patching, non-default ports, key based authentication, > fail2ban/denyhosts, port knocking, SELinux &c are useful in increasing > the cost of breaking into boxen above the (drive-by/skiddie) > breakpoint of almost free but from that point onwards you need to > balance potential cost of break-in against cost of prevention.You cannot prevent an intrusion; you can only slow it down. If you make it too slow to be useful, then you can have a chance at being relatively secure. Make it cost the attacker, too, as they are also looking at a cost/benefit balance sheet.