Arkeia Network Backup Agent Remote Access

hdm writes "The Metasploit Project has published a security analysis of the Arkeia Network Backup Client. Anyone able to connect to TCP port 617 can gain read/write access to the filesystem of any host running the Arkeia agent software. This appears to be an intentional design decision on the part of the Arkeia developers. A long-winded description of this issue, complete with screen shots, demonstration code, and packet captures can be found in the research article. Arkeia has been credited with being the first commercial backup product for the Linux platform."

Comments

got root?

[cgranade]

Seems to me that the only way to get r/w access to the entire filesystem is if either a) the backup daemon is running as root, or b) if the backup daemon's user or group has r/w access equal to root's. In either case, the sysadmin would have to be on crack to do that. Not that read-only access is OK by any stretch, but just making the point. Oh, and before idiots start saying "see, open source isn't secure," let me remind them that this is a commercial product that was comprimised. If anything, I'd take this as further evidence of the virtues of open source.

Re:got root?

[pmsr]

I hate to spoil your party, but how are you going to backup user files if you don't have access to them? It is obvious the backup client has to run as root.

/Pedro

Re:got root?

[Zocalo]

It's a piece of backup software, at the very least it needs to have read access to everything it is going to be used to backup. If you are planning on doing a full system backup, that means it needs read access to the whole filesystem or it can't do it's job. That doesn't mean it needs to be running as "root" of course; ideally such a tool would be running with a dedicated user and group. On a Windows box however it's not uncommon to see backup utilities running with higher priviledges than the "administrator" account because that's the only way to sidestep things like system file protection and other tricks Microsoft uses to protect the system from abuse.

Re:got root?

[cgranade]

Why not give the daemon read-only access to the source for backups? Seems like it's be a straight-forward enough thing to do.

Re:got root?

[FLAGGR]

To the second point..

but thats the whole point of the /etc/shadow... passwords... everything else is in the public readable /etc/passwd. In a network with more than 10 users you want to keep a backup of the /etc/shadow somehow.

Re:Somebody has to say it

[badfish99]

No it wouldn't, because people would have spotted the decision at an early stage and told the developers that it was stupid.

With a commercial product, it took someone with a network sniffer to discover this. So it's just a lucky fluke that someone other than the bad guys knows about it.

Specifications

[Fox_1]

It's very frustrating when you find previously unknown and undocumented features in software that you have purchased. I remember having to provide clients with full copies of the specifications and code for software so that they would be able update/repair/modify if I was hit by a bus or something. Security through obscurity is not safety, that should be validated by now simply by the sheer number of stories similar to this Arkeia one. Open Source Software at least has the beauty of the source code being readily accessible so that the user/admin/owner can see what they are installing on their system. This poor guy in the article ended up having to reverse engineer his software to find out the security dangers. Which may be against a law somewhere, ha - putting a backdoor into software you give me not illegal, finding that backdoor - may be me in trouble. I love it.

Re:Specifications

[TheRaven64]

I think your post is probably the best one I've read on Slashdot explaining the benefits of open source, or free, software. It's not about giving the code away to everyone free of charge, it's about ensuring that those people who rely on the code have the ability to modify it.

Re:Specifications

[hunterx11]

Obscurity would be hiding the fact that your safety is reliant on a number between 2^0 and 2^69 (as opposed to say, a word). If you do use such a number and don't feel the need to hide this fact, then your security is not through obscurity, it's through hardness.

Re:Specifications

[Fox_1]

Exactly - choosing a number that is hard to guess is security through hardness
not telling me that number even exists would add security through obscurity
The point is though that this software relied on obscurity to protect the built in backdoor, once that obscurity is gone the software doesn't even have something as brillant as a hard to guess number protecting the backdoor.
I call it the jerk arguement
- I can call you a jerk behind your back - security - obscurity
if you hear about it though - i'm hosed
- I can call you a jerk to your face, while holding my louisville slugger
security - Hardness (maple in this case)
(no offense I don't even know you and of course don't mean to suggest anything negative about you, just creating an example)

The oldest excuse in the book

[HeghmoH]

"It's not a bug, it's a feature!"

What a bunch of morons. It's one thing to accidentally write a security hole in your software. It's another thing entirely to claim that you deliberately make it so your software leaves your users' systems wide open to anybody who feels like taking advantage.

A good saying

[Capt'n Hector]

Never attribute to malice what is explainable by stupidity. (though the Bush admin. has stretched my imagination...) Though it appears intentional, there is probably a very good explanation for all of this. Needless to say, we'd better be hearing soon from Arkeia as to exactly WHAT that explanation is.

Re:Not a bug; it's a feature?

[Zocalo]

Even if they were making the somewhat idiotic assumption that all of their users were behind a properly configured firewall, so what? That makes absolutely zero provision for a potential cracker having already circumvented the firewall by other means or even the possibility that they might be an employee. Or haven't they seen any of the reports that a significant amount of computer crime is committed by aggrieved employees?

I don't think it's so much improper usage of the word "intentional" as an incorrect synonym for the term "brain dead".

Security available, just not enabled by default

[Anonymous Coward]

Arkeia provides both authentication and encryption of the connections - if you enable it. There is a part of the manual that covers how to enable security.

It is indeed bad that it is not enabled by default. On the other hand, enabling authentication of the backup server on the backup clients means that it is slightly harder to set up a backup client.

The problem is not much worse than, say, nfs. (Where impersonating a host can get you everywhere unless authenticated rpc is used.

Re:from the arkeia site

[DingerX]

I'd say the worse thing here would be being a published user of a system with an "interesting" security hole like that; all of a sudden, a friendly testimonial becomes an advertisement of a vulnerability.

Unless, of course, they've got everything firewalled to tuesday.

Zzzzapp

Nope, metal.

Hum off topic'ish.

[zijus]

Hi there.

Well I just dealt recently "simple" backups via rsync + ssh. If you can rsync something from remote onto target with no special protection regarding rsync... If target is compromised, a malicious user can run arbitrary commands through rsync. And rsync server provides full read access to FS. (Well, within user permissions though.) Isn't it a bit the same problem that this software has? I would not be surprised to hear that you can customize the backup server to limit access/actions for better sefety. Which is exactly what you have to do with ssh on remote server: filter commands passed through ssh before running them. I mean: each remote you want to back up will have to be worked on a little.

It's off topic but FYI: Rsync server can take as a file list an arbitrary unix command.

rsync user@remote:'`\rm -rf /`' .

Pretty efficient isn't it ? (unix file perm will limit the damage though).

Bye bye.

Z.

Re:Hum off topic'ish.

[Anonymous Coward]

Well I just dealt recently "simple" backups via rsync + ssh.

I'm assuming you are doing really simple backups...how do you handle complicated tape library management (ie: tape robots, backup aging, onsite/offsite backups) automatically without having to use software more complicated than the basic Unix command line utilities? I'm not targeting you in particular, but there seems to be a lack of realization in general in this thread that backup systems are usually more complicated than just sticking an 'rsync' or 'dd' command into your cron files.

Uh...

[warrax_666]

... if the software doesn't need the port to be open on the internal network then why is it open?

Firewalling the port on each indivudual system behind the main firewall would then imply that the software couldn't actually function (for any reasonable definition of the word "function").

Re:Uh...

[prefect42]

Have you never used a firewall? Think filtered not blocked. Configure it such that it'll only allow packets from the backup server to that port. Bingo, job's a goodun.

Re:Somebody has to say it

[Rich0]

Hmm - doesn't look like it fits my bill (a shame - I'be been looking for a better backup solution and have yet to find it).

Here are my requirements:

1. Backups are encrypted.
2. Backup data can be split across media.
3. Backups can use include/exclude criteria.
4. Corrupted backup files are recoverable.
5. Backups are compressed.

I've yet to find anything free which does all of this. Instead I'm using a short shell script combo of tar/bzip/gpg/split which gets the job done, but not elegantly. I'm not 100% sure how successful #4 would be with this setup. I think gpg has some support for corrupted files.

Honestly, I don't care that much about ECC and all that. My main concern with #4 is that if one byte in the backup file is messed up, I don't lose the ability to read everything else in the file. I can tolerate having one file on my system which gets lost in a disaster...

Re:Easy: Use QuickPar or some form of PAR2

[Fweeky]

"Much like RAID5 however, there is a space sacrifice for this extra parity layer."

But it's settable; so if you want to be able to recover fully from losing/corrupting 20% of your backup you just set it to 20% of your backup size, and if you only care about a few minor bit errors or so, you can drop it to a couple of percent or less.

Be nice if vendors provided PAR2's for their ISO/DVD images/anything else big; it sucks when you find the MD5 of your download doesn't match the one they provide (or that 400MB setup.exe throws a checksum mismatch and refuses to run), and you know it's probably just a single bit flipped somewhere but can't do much beyond redownloading the entire thing. rsync helps, of course, but that's a *lot* heavier on the server both in resource use and administration cost.