Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Fedora Infrastructure Compromised

CmdrTaco posted more than 2 years ago | from the hate-when-that-happens dept.

Open Source 115

Trailrunner7 writes "The infrastructure of the Fedora Project was compromised over the weekend and an account belonging to a Fedora contributor was taken over by an attacker. However, Fedora officials said they don't believe that the attacker was able to push any changes to the Fedora package system or make any actual changes to the infrastructure. The attack appears to have targeted one specific user account, which had some high-value privileges. The attacker was able to compromise the account externally, and then had the ability to connect remotely to some Fedora systems. The attacker also changed the account's SSH key, Fedora officials said."

cancel ×

115 comments

Believe? (2)

amicusNYCL (1538833) | more than 2 years ago | (#34997172)

However, Fedora officials said they don't believe that the attacker was able to push any changes to the Fedora package system or make any actual changes to the infrastructure.

What do you mean you "don't believe"? You don't have logs?

Re:Believe? (4, Insightful)

syntap (242090) | more than 2 years ago | (#34997240)

Logs can be faked. How about a bitwise comparison to the known-good package system?

Re:Believe? (1)

h00manist (800926) | more than 2 years ago | (#34997874)

Logs can be faked. How about a bitwise comparison to the known-good package system?

Fake information can be even more useful, if you detect it's fake of course.

Re:Believe? (2)

timeOday (582209) | more than 2 years ago | (#34997934)

A compromised server could store the packages unchanged but modify them on the way out.

The critical piece as I see it is the distribution of the checksums. If package maintainers and end users agree on the checksums (and neither of their systems is initially compromised), then everything should be fine. Or am I overlooking something?

Re:Believe? (1)

jd (1658) | more than 2 years ago | (#34997940)

If you're using Nulfs2 for the filesystem the logs are on, then you can determine if data within the logs have been altered.

Alternatively, if the logging daemon writes events to a logger on another machine, then logs could only ever be appended to and never altered.

In this day and age, it seems pitiful that anyone would use a setup where the logs could be faked.

Re:Believe? (2)

arth1 (260657) | more than 2 years ago | (#34998624)

Alternatively, if the logging daemon writes events to a logger on another machine, then logs could only ever be appended to and never altered.

This is why there's still a market for dot matrix printers, especially those with a dip switch that disables reverse paper feed.
Good luck erasing or modifying that audit trail remotely.

Re:Believe? (1)

jd (1658) | more than 2 years ago | (#34999076)

I accidentally set fire to a dot matrix once - the paper somehow wrapped itself from the output back in, causing the motor to jam and ignite.

Re:Believe? (1)

Coren22 (1625475) | more than 2 years ago | (#34999784)

Did you get the printer on fire error?

http://en.wikipedia.org/wiki/Lp0_on_fire [wikipedia.org]

Re:Believe? (1)

eyrieowl (881195) | more than 2 years ago | (#35000350)

nicely done.

Re:Believe? (1)

emocomputerjock (1099941) | more than 2 years ago | (#35001074)

Look at his UID, he probably wrote that error.

Re:Believe? (1)

David Greene (463) | more than 2 years ago | (#35001112)

Pshaw!

Re:Believe? (1)

Darinbob (1142669) | more than 2 years ago | (#34998278)

This is why you should periodically save your game.

Re:Believe? (1)

davester666 (731373) | more than 2 years ago | (#34998474)

Is there a 'known-good' Fedora system?

Re:Believe? (0)

Anonymous Coward | more than 2 years ago | (#34998488)

Logs can be faked. How about a bitwise comparison to the known-good package system?

Aren't independent checksums available? The various BSD ports have checksums that are compared to the downloaded source files before the package build occurs.

Every upload should be announced (in a semi-parsable format) to a listserv with the filename, file size, and checksum (with the maintainer/uploader BCC'd). If you get an alert, and you didn't upload anything, it's a problem. Then, if there's a compromise, you can compare the various file/s to the mail archives (which are on different machines than the files themselves).

You can sign the update e-mails with DKIM for extra checking (so if the archived messages are not the same as the DKIM-Signature header value, you know your mail archives are also compromised). So you'd need to compromise three sets of machines before something unknown could slip through. None of the above would be manual on generation, so it should be a minimal of fuss to users. Automating the checking may be a more challenging, but once automated, it could be done on a semi-regular basis.

Re:Believe? (5, Informative)

Anonymous Coward | more than 2 years ago | (#34998602)

Logs can be faked. How about a bitwise comparison to the known-good package system?

As a fedora dev account holder, I got the notification email. The filesystem was compared with a previous 'good' snapshot to determine what changes were made.

Re:Believe? (1)

BitwiseX (300405) | more than 2 years ago | (#34999064)

Logs can be faked. How about a bitwise comparison to the known-good package system?

Sorry, I'm busy remodeling my house..

Re:Believe? (0)

Anonymous Coward | more than 2 years ago | (#35000174)

"How about a bitwise comparison to the known-good package system?"

I don't see what use it would be to compare a fedora server to apt ;)

Re:Believe? (2)

0racle (667029) | more than 2 years ago | (#34997254)

Perhaps this is an early release of the information and given the amount of time they have spent in researching the issue they don't believe anything was actually done, but a more thorough investigation is still needed.

Re:Believe? (1)

0racle (667029) | more than 2 years ago | (#34997280)

And yep, that's pretty much what the article says.

Re:Believe? (2)

new death barbie (240326) | more than 2 years ago | (#34997314)

would you trust the logs if you had them?

Re:Believe? (1)

amicusNYCL (1538833) | more than 2 years ago | (#34997706)

Well, I would update my local repository, and then check the change logs to see what's different. So yeah, I would trust that.

Re:Believe? (1)

Beardo the Bearded (321478) | more than 2 years ago | (#34998198)

That was my first thought as well: "Uh, didn't they do a diff and look for the parts that changed?"

integrity of logs (0)

Anonymous Coward | more than 2 years ago | (#34998894)

would you trust the logs if you had them?

RFC 5848 defines how to sign log messages to help with integrity (and replays, etc.).

There's also "msyslog", where you can initialize the system with a key (stored offline) to sign logs. For every log entry after initialize, you take the hash of the previous entry, concatenate the new entry, and generate a new hash (redacting the old one). If you think you've been compromised, you run a checking program whereby you "walk" the logs after entering the passphrase (or reading it from a file). If the logs have been tampered with, the checksums will start failing.

So:

H(passphrase) = h0
H(h0, log entry 1) = h1
H(h1, entry 2) = h2
H(h2, entry 3) = h3

...
H(hN-1, entryN) = hN

An intruder can certainly delete local log entries, but it'd be quite the challenge to alter them such that the hash chain would still be valid. Of course all values are questionable after any compromise, as any message can then generated, but at least you've probably got decent data up to that point for analysis.

Msyslog (supposedly) uses the L-PEO and PEO-1 algorithms for integrity checking. Personally I haven't heard of them.

If the initialization is done via the KickStart process before even the first 'real' boot of the system, then you can automate the initialization without the initial key being exposed to the system.

Re:Believe? (0)

Anonymous Coward | more than 2 years ago | (#34997386)

Logs aren't exactly reliable on compromised systems... It takes time to figure out the full extent of a breach and they probably don't want to say anything conclusive yet.

Re:Believe? (5, Informative)

0123456 (636235) | more than 2 years ago | (#34997496)

That's why any secure system should be sending logs to a remote machine as well as /var/log.

Re:Believe? (0)

Anonymous Coward | more than 2 years ago | (#34997750)

The logs sent to the other machine wouldn't be trustworthy either...

Re:Believe? (2)

WetCat (558132) | more than 2 years ago | (#34997864)

Excluding logs before and in the exact time of break-in, while attacker hasn't put his stealth instruments to the victim machine yet.

Re:Believe? (1)

0123456 (636235) | more than 2 years ago | (#34998386)

The logs sent to the other machine wouldn't be trustworthy either...

Only after the attacker has rooted the box and been able to block further logging of his activities. You can easily edit the log files on a machine and remove old entries showing you doing bad things, but you can't do that wih a remote machine that you have no access to.

Developing story (1)

h00manist (800926) | more than 2 years ago | (#34997442)

These things take time to analyze. Surely they will be finding out more things.

Re:Believe? (1)

sleepy_weasel (839947) | more than 2 years ago | (#34998382)

Yep... Make the devs change all passwords, wipe the affected system, and re-install. Or, they can do that thing were you put important data on a non-volatile media and put it somewhere in case you lose a system...

Fedora infrastructure intrusion (2)

doperative (1958782) | more than 2 years ago | (#34998392)

"The Infrastructure Team took the following actions after being notified of the issue:

1. Lock down access to the compromised account

2. Take filesystem snapshots of all systems the account had access to

      (pkgs.fedoraproject.org, fedorapeople.org)

3. Audit SSH, FAS, Git, and Koji logs from the time of compromise to the present

Here, we found that the attacker did:

        * Change the account's SSH key in FAS

        * Login to fedorapeople.org

      The attacker did not:

        * Push any changes to the Fedora SCM or access pkgs.fedoraproject.org in any way

        * Generate a koji cert or perform any builds

        * Push any package updates .."

Re:Fedora infrastructure intrusion (0)

Anonymous Coward | more than 2 years ago | (#34999836)

The attacker did not:

* Push any changes to the Fedora SCM or access pkgs.fedoraproject.org in any way

* Generate a koji cert or perform any builds

* Push any package updates .."

Fedora uses a build system called Koji that requires some form of Maintainer specific certificate to allow uploads/builds. Ubuntu has a similar system whereby each upload must have a valid GPG signature from an Ubuntu Developer or it will be rejected. So it doesn't really seem that the package archive was in any sort of danger here, unless somehow using the compromised account they could have revoked the certificate, created a new one and wreaked havoc. I think the same issue would occur if a malicious hacker got into the Launchpad account of an Ubuntu dev, where you could add a new GPG key, though there may need to be an extra stage where the keyrings on LP and the build-servers are synced, it's been too long since I set up my upload key to remember.

Re:Believe? (5, Funny)

Chapter80 (926879) | more than 2 years ago | (#34998610)

However, Fedora officials said they don't believe that the attacker was able to push any changes to the Fedora package system or make any actual changes to the infrastructure.

What do you mean you "don't believe"? You don't have logs?

Thankfully, I am on Windows, so I don't have to wonder whether hackers are conducting malicious activity.

Re:Believe? (0)

Anonymous Coward | more than 2 years ago | (#34999730)

yeah, you just know it as a fact :P

Re:Believe? (1)

mcneely.mike (927221) | more than 2 years ago | (#35000420)

Too bad there's not a (Score:10, Hilarious).

oops... (0)

buzzsawddog (1980902) | more than 2 years ago | (#34997178)

Oops...

Here's a subject (0)

Anonymous Coward | more than 2 years ago | (#34997180)

Surprised? No I am not.

I need to hand in my geek card... (0)

tool462 (677306) | more than 2 years ago | (#34997190)

...because I thought this was about shoddy hats.

Re:I need to hand in my geek card... (1)

h00manist (800926) | more than 2 years ago | (#34997472)

I only recently discovered what the hell does "fedora" mean apart from a Linux distro.

Re:I need to hand in my geek card... (1)

foobsr (693224) | more than 2 years ago | (#34998454)

I only recently discovered what the hell does "fedora" mean apart from a Linux distro.

You encountered a red fedora?

CC.

Re:I need to hand in my geek card... (1)

Chapter80 (926879) | more than 2 years ago | (#35000216)

I only recently discovered what the hell does "fedora" mean apart from a Linux distro.

Red Hat Fedora
Apple MacIntosh (McIntosh Apples)
Sun SOLARis

There are a lot of plays on words out there in the tech field.

Re:I need to hand in my geek card... (1)

angus77 (1520151) | more than 2 years ago | (#35001156)

Apple MacIntosh (McIntosh Apples)

Bonus points for noticing the difference in the spelling!

Re:I need to hand in my geek card... (1)

VGPowerlord (621254) | more than 2 years ago | (#34997800)

You can't have my Fancy Fedora [teamfortress.com] . :|

Re:I need to hand in my geek card... (1)

jd (1658) | more than 2 years ago | (#34997954)

Yeah, turns out the mercury used was driving the hatters mad.

Re:I need to hand in my geek card... (1)

MoriaOrc (822758) | more than 2 years ago | (#34998324)

My first thought was "How will Bogart cope with a compromised fedora infrastructure?!"
Then I remembered Bogart was dead.
Then I remembered Fedora is a Linux distro.

again? (1)

russlar (1122455) | more than 2 years ago | (#34997204)

didn't something very similar happen last year, too?

Re:again? (1)

bsDaemon (87307) | more than 2 years ago | (#34997326)

I think last year it was CentOS that got hit, not Fedora. Also, the nature of the attack was different and I believe some packages were compromised, or at least the repo signing keys.

Re:again? (1)

0123456 (636235) | more than 2 years ago | (#34997464)

I think last year it was CentOS that got hit, not Fedora. Also, the nature of the attack was different and I believe some packages were compromised, or at least the repo signing keys.

It was Red Hat, wasn't it?

http://www.redhat.com/security/data/openssh-blacklist.html [redhat.com]

Re:again? (1)

just_another_sean (919159) | more than 2 years ago | (#34997584)

That little gem can be blamed on Debian [debian.org] actually.

I love Debian so this one came as a real blow; but they did a good job disclosing it and worked with any and all who wanted to participate to develop the blacklist package.

Yay, Open Source! (-1)

Anonymous Coward | more than 2 years ago | (#34997222)

Makes you wonder if anyone SSHs into Microsoft's code repository to make some "changes."

Re:Yay, Open Source! (3, Insightful)

wagnerrp (1305589) | more than 2 years ago | (#34997266)

No, they have to Virtual Desktop in.

Re:Yay, Open Source! (2, Interesting)

Anonymous Coward | more than 2 years ago | (#34997384)

Actually, even Microsoft employees working remotely have to jump through so many hoops for a flaky VPN connection that there is no way anyone could get in for long enough to do significant damages. A Microsoft employee recruiting in colleges on the East coast showed me their system. You can't use a standard VPN client - even the built-in Windows one. It uses SmartCards and multiple passwords for authentication and disconnects if the card even shifts a bit in the card reader.

It would probably be easier to steal a physical device than to get into their network from outside a Microsoft office.

Re:Yay, Open Source! (2, Insightful)

oodaloop (1229816) | more than 2 years ago | (#34997322)

And what, interject some bad code? How would anyone know?

Re:Yay, Open Source! (0)

Anonymous Coward | more than 2 years ago | (#34998062)

Many Eyes...

Re:Yay, Open Source! (0)

Anonymous Coward | more than 2 years ago | (#34997364)

Makes you wonder if anyone RDP's into Microsoft's code repository to make some "changes."

FTFY

Re:Yay, Open Source! (1)

buzzsawddog (1980902) | more than 2 years ago | (#34997382)

Well we know that thing can't get to much worse... What would they do? Improve the system?

Re:Yay, Open Source! (2)

Mitchell314 (1576581) | more than 2 years ago | (#34997938)

Careful what you wish for. They could permanently fuse that damn paperclip to the desktop.

Re:Yay, Open Source! (4, Funny)

undecim (1237470) | more than 2 years ago | (#34997682)

IIRC, something like that has happened before. The attacker managed to get RDP access to one of Microsoft's servers where they keep source code. However, when authorities were able to trace the connection back to his house, they entered to find he had died of a simultaneous heart attack, aneurysm, and stroke, with the Windows kernel source code open on his screen.

Re:Yay, Open Source! (1)

suomynonAyletamitlU (1618513) | more than 2 years ago | (#34999942)

to find he had died of a simultaneous heart attack, aneurysm, and stroke, with the Windows kernel source code open on his screen.

And people say that it's selfish of MS to keep it to themselves...

Re:Yay, Open Source! (1)

jd2112 (1535857) | more than 2 years ago | (#35000202)

Are you sure he didn't die laughing?

Re:Yay, Open Source! (1)

undecim (1237470) | more than 2 years ago | (#35000586)

Are you sure he didn't die laughing?

That's an excellent alternative ending.

Nah, Security by obscure VC software (2)

The O Rly Factor (1977536) | more than 2 years ago | (#34999034)

Nah, MS uses Team Foundation Server for all of their version control. I have not ever met another single person or company that also uses TFS, nor have I really seen any good documentation on how to use it.

Rivalry (-1, Troll)

padraic_93 (1706636) | more than 2 years ago | (#34997252)

What are the odds this was an Ubuntu developer ordered by Shuttleworth to take down the enemy?

Re:Rivalry (1)

Anonymous Coward | more than 2 years ago | (#34997306)

really low

Re:Rivalry (2)

oodaloop (1229816) | more than 2 years ago | (#34997338)

1 in 7. As long we're just making up wild accusations, let's just make up some wild numbers.

Re:Rivalry (1)

shadowknot (853491) | more than 2 years ago | (#34997418)

I flashed on that thought but then looking at the numbers on Distrowatch [distrowatch.com] the top 2 are Ubuntu and Mint (a, IMHO, crappy Ubuntu derivative) then Fedora. Unless they want to bump Fedora below OpenSUSE what would be the point?

Re:Rivalry (1)

cronius (813431) | more than 2 years ago | (#34997424)

What are the odds that you are just trolling?

Re:Rivalry (0)

Anonymous Coward | more than 2 years ago | (#34998060)

1 in 7.

Re:Rivalry (0)

Anonymous Coward | more than 2 years ago | (#34997508)

This is about Red Hat, not the tin foil hats.

Not a professional job (2)

Mathinker (909784) | more than 2 years ago | (#34997402)

The first action the intruder took, changing the SSH password, set off an automatic email notification, which is how the compromise was detected. Pretty stupid.

A pity that the clueless black hats eventually learn, tho. Not that this means that open-source is totally helpless. In the past, malevolent software updates have been caught. If this becomes widespread, it just means that the development is slowed by the necessity for peer review.

Re:Not a professional job (1)

localman57 (1340533) | more than 2 years ago | (#34997546)

slowed by the necessity for peer review.

What credible software organization feels that peer review isn't necessary? Automated testing only gets you so far...

Re:Not a professional job (0)

Anonymous Coward | more than 2 years ago | (#34997832)

What credible software organization feels that peer review isn't necessary? Automated testing only gets you so far...

You cannot peer review all software you package. You have to rely on external entities to keep their stuff together.

Now if you want to mark this as a troll or whatever go ahead. But please, name me ONE SINGLE entity that has ever done a complete security audit on Linux or Gnome or KDE? Oh right.. they don't exist. Heck, peer review of Linux is exclusively upstream, not packagers...

As to packages, peer review is not necessary in most distributions. It is always welcome, but it is not necessary as it is assumed that software package people will not be introducing security holes into software.

And as in all OSS software, anyone is welcome to review any package. All sources are available!

Re:Not a professional job (1)

Mathinker (909784) | more than 2 years ago | (#34998208)

> it is not necessary as it is assumed that software package people will not
> be introducing security holes into software

And we've seen how one can be bitten by this assumption, badly (Debian SSH patch-of-entropy-death).

Re:Not a professional job (1)

Mathinker (909784) | more than 2 years ago | (#34998496)

I'd guess that most open-source projects are one- or two-developer deals, max (actually, if you look at SourceForge, you'd end up saying that most projects are zero-developer deals!). However, the most-used projects are much better "staffed", which might mean that there is more of a chance that the people in charge of vetting the commits have some specialized training to catch malevolent changes (and also that more than one set of eyeballs might be looking at every commit).

In the end, it comes down to a matter of trust. Once a developer has gained a reputation for being trustworthy via having made significant contributions, my guess is that it becomes easier for him to slip bad code into a project. So I suppose the black hats might eventually be a net gain for the open-source movement. On the other hand, I'd guess that organized crime might find it expedient to pay key developers a personal visit, to deliver the famous "offer you cannot resist" --- and once that happens, people might be scared off from contributing.

Article and headline are completely wrong (5, Informative)

MSG (12810) | more than 2 years ago | (#34997458)

The infrastructure was not compromised. One user's password appears to have been compromised and changed. That account did not have "high value privileges".

Re:Article and headline are completely wrong (0, Redundant)

v1 (525388) | more than 2 years ago | (#34997654)

The infrastructure was not compromised. One user's password appears to have been compromised and changed. That account did not have "high value privileges".

>> The attack appears to have targeted one specific user account, which had some high-value privileges.

Re:Article and headline are completely wrong (0)

Anonymous Coward | more than 2 years ago | (#34997992)

Quoting a badly written article is nice, quoting the actual source is better:

The account in question was not a member of any sysadmin or Release Engineering groups.

Re:Article and headline are completely wrong (2)

timepilot (116247) | more than 2 years ago | (#34998302)

Or digging further:

# Push access to packages in the Fedora SCM.
# Ability to perform builds and make updates to Fedora packages.

Which I would qualify as high-value.

Re:Article and headline are completely wrong (1)

MSG (12810) | more than 2 years ago | (#34999626)

As far as I know, everyone gets those rights, subject to ACLs on each package that govern who can make changes.

Re:Article and headline are completely wrong (0)

Anonymous Coward | more than 2 years ago | (#35001078)

It's also easy to audit. That account performed no builds and pushed no commits.

Re:Article and headline are completely wrong (0)

Anonymous Coward | more than 2 years ago | (#34998398)

not a member of any sysadmin or Release Engineering groups. != no high-value privileges.

Re:Article and headline are completely wrong (2)

I8TheWorm (645702) | more than 2 years ago | (#34998718)

Being able to change source code and that code getting pushed into builds which the RE group releases would suggest that it's a bit of a high value account.

I argued for some time at a previous company that they were out of compliance with Sarbanes-Oxley and segregation of duty rules. The reason was the network admins had access to source code repositories (VSS, StarTeam, and TFS). Since network admins did pushes to QAS and PRD, they could feasably alter source code and push it to production.

The reality, though, is a developer can put in malicious code and, as long as the rest of the dev team doesn't catch it, it can make it to production regardless. Network admins don't typically have any way of knowing anything about the code that's being pushed.

All of that makes SOX pretty weak from an IT standpoint. But the end result is this: anyone who can push code to a repository has access to do terrible things.

Re:Article and headline are completely wrong (0)

Anonymous Coward | more than 2 years ago | (#34999556)

You can buy a computer without an OS, and you can buy a computer with any and all of the modern OSs preloaded. You cannot buy an Android handset without the Android OS; Android refers to a (virtual) hardware platform as well. Your analogy is saved by the looseness of the word 'akin', but it seems quite valid to refer to Android phones in a manner that suggests they're substantially similar.

Saying Android is a family of phones is akin to saying Unix is a family of OSs.

Re:Article and headline are completely wrong (0)

Anonymous Coward | more than 2 years ago | (#34997884)

You must be new here..

Whoops (0)

Anonymous Coward | more than 2 years ago | (#34997560)

They should have been running a BSD.

*bsd is dying (0)

Anonymous Coward | more than 2 years ago | (#34997834)

It is official; Netcraft now confirms: *BSD is dying

One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming close on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.

FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.

Let's keep to the facts and look at the numbers.

OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.

All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a cockeyed miracle could save *BSD from its fate at this point in time. For all practical purposes, *BSD is dead.

Fact: *BSD is dying

This never would have happened... (0, Flamebait)

localman57 (1340533) | more than 2 years ago | (#34997568)

This never would have happened if they were running Lin...

Oh. Right. Never mind.

Microsoft fanboys, begin your modding up now! Linux fanboys, begin your modding down now!

Re:This never would have happened... (1)

0123456 (636235) | more than 2 years ago | (#34997666)

This never would have happened if they were running Lin...

Most likely it's a weak SSH password: SSH and VNC with crappy passwords seem to be the two most common ways to get into Linux machines these days... just open port 22 and watch a million Chinese hackers testing out a bazillion ssh passwords on your machine.

If Windows actually supported SSH then it would be just as vulnerable.

Re:This never would have happened... (3, Insightful)

0123456 (636235) | more than 2 years ago | (#34997714)

P.S. Of course if they were serious about security in the first place they wouldn't even allow logins with passwords and would require public key authentication instead.

Re:This never would have happened... (2)

mlts (1038732) | more than 2 years ago | (#34997922)

Exactly. For example, any machines I have which have to have an Internet facing ssh port are definitely not going to be accepting passwords. Tools like ssh-guard are nice, but it isn't hard for a determined attacker to just keep coming from different IP ranges. To add a little bit of security, port knocking is a nice ability to have, just so an attacker doesn't see an open port to start having fun with.

What would be ideal is if OATH support would advance to the point where I can just enter my username, then my password and then the random key from a SecurID or other token. This way, an attacker would have to go from passively looking at passwords as they float by to actively MITM-ing the connection.

Re:This never would have happened... (1)

dAzED1 (33635) | more than 2 years ago | (#34999776)

or someone made the social-engineering mistake of registering at another site with an email address, and then using the same password at that site as the login for their email address (and in this case, the rest of their fedora resources) uses....ie, could have been an extremely good password. If I have a random 400 character password and then post it on a public internet page, it's not the password that is weak.

Re:This never would have happened... (0)

Anonymous Coward | more than 2 years ago | (#35001204)

They already prohibit password-based logins on shell servers. The web UI where one uploads SSH public keys, however, uses a password. It was that password that the attacker changed.

Re:This never would have happened... (0)

Anonymous Coward | more than 2 years ago | (#34997812)

That's pretty much how it goes. Either Fedora switches to key based authentication only, or they install denyhosts (or similar). I get several e-mails from my servers every day, alerting my of Chinese bots trying to brute force various accounts. denyhosts blocks them forever after 5 failed attempts. (and directly for root@...)

Don't leave home with SSH brute-force protection!

Some history (2)

snookiex (1814614) | more than 2 years ago | (#34997638)

  • Debian: [1 [debian.org] ], [2 [slashdot.org] ]
  • Ubuntu: [1 [slashdot.org] ]
  • Gentoo: [1 [gentoo.org] ]

Re:Some history (0)

pseudorand (603231) | more than 2 years ago | (#35000042)

So am I to infer from this that I should switch to SuSE (/spits foul taste from mouth) or slackware? Or are those distros just too insignificant to make the news when compromised?

Re:Some history (1)

snookiex (1814614) | more than 2 years ago | (#35001042)

I could swear I read something about Slackware some years ago, but I've never heard about SuSE/OpenSUSE servers compromised. It's not that they're insignificant, but they simply kept themselves secured or no one ever realized they were compromised. Besides OpenSUSE is among the top five Linux distros I can't get your point.

The actual email in case anyone wants the facts (5, Informative)

seifried (12921) | more than 2 years ago | (#34997740)

http://lists.fedoraproject.org/pipermail/devel-announce/2011-January/000746.html [fedoraproject.org]

Summary: Fedora infrastructure intrusion but no impact on product integrity

On January 22, 2011 a Fedora contributor received an email from the Fedora Accounts System indicating that his account details had been changed. He contacted the Fedora Infrastructure Team indicating that he had received the email, but had not made changes to his FAS account. The Infrastructure Team immediately began investigating, and confirmed that the account had indeed been compromised.

At this time, the Infrastructure Team has evidence that indicates the account credentials were compromised externally, and that the Fedora Infrastructure was not subject to any code vulnerability or exploit.

The account in question was not a member of any sysadmin or Release Engineering groups. The following is a complete list of privileges on the account:

  • SSH to fedorapeople.org (user permissions are very limited on this machine).
  • Push access to packages in the Fedora SCM.
  • Ability to perform builds and make updates to Fedora packages.

The Infrastructure Team took the following actions after being notified of the issue:

  • 1. Lock down access to the compromised account
  • 2. Take filesystem snapshots of all systems the account had access to (pkgs.fedoraproject.org, fedorapeople.org)
  • 3. Audit SSH, FAS, Git, and Koji logs from the time of compromise to the present. Here, we found that the attacker did:
    • Change the account's SSH key in FAS
    • Login to fedorapeople.org

    The attacker did not:

    • Push any changes to the Fedora SCM or access pkgs.fedoraproject.org in any way
    • Generate a koji cert or perform any builds
    • Push any package updates

Based on the results of our investigation so far, we do not believe that any Fedora packages or other Fedora contributor accounts were affected by this compromise.

While the user in question had the ability to commit to Fedora SCM, the Infrastructure Team does not believe that the compromised account was used to do this, or cause any builds or updates in the Fedora build system. The Infrastructure Team believes that Fedora users are in no way threatened by this security breach and we have found no evidence that the compromise extended beyond this single account.

As always, Fedora packagers are recommended to regularly review commits to their packages and report any suspicious activity that they notice.

Fedora contributors are strongly encouraged to choose a strong FAS password. Contributors should *NOT* use their FAS password on any other websites or user accounts. If you receive an email from FAS notifying you of changes to your account that you did not make, please contact the Fedora Infrastructure team immediately via admin@fedoraproject.org.

We are still performing a more in-depth investigation and security audit and we will post again if there are any material changes to our understanding.

--

Jared Smith

Fedora Project Leader

Re:The actual email in case anyone wants the facts (0)

Anonymous Coward | more than 2 years ago | (#34999170)

hey, if I wanted facts, I would have gone to that chuck norris site

The good news is... (1)

Anonymous Coward | more than 2 years ago | (#34998722)

I will be releasing Fedora 15 Desktop Edition next week. Standby for download links.

Why would he change the key? (1)

pseudorand (603231) | more than 2 years ago | (#35000058)

If you compromised an account, why would you change the key, an action that would quite likely trigger some sort of alert (as it did). Wouldn't you just silently look around until you knew what you wanted to do with it and then do all your damage at once before they could cut you off?
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...