Arkeia Network Backup Agent Remote Access 168
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."
got root? (Score:2, Insightful)
Re:got root? (Score:1, Insightful)
Re:got root? (Score:5, Insightful)
Re:Somebody has to say it (Score:5, Insightful)
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 (Score:5, Insightful)
Re:got root? (Score:3, Insightful)
The oldest excuse in the book (Score:5, Insightful)
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 (Score:3, Insightful)
Re:Not a bug; it's a feature? (Score:5, Insightful)
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 (Score:5, Insightful)
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:Specifications (Score:5, Insightful)
Re:from the arkeia site (Score:5, Insightful)
Unless, of course, they've got everything firewalled to tuesday.
Zzzzapp
Nope, metal.
Hum off topic'ish. (Score:5, Insightful)
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.
Pretty efficient isn't it ? (unix file perm will limit the damage though).
Bye bye.
Z.
Re:Specifications (Score:4, Insightful)
Uh... (Score:3, Insightful)
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... (Score:2, Insightful)
Re:Hum off topic'ish. (Score:2, Insightful)
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.
Re:got root? (Score:3, Insightful)
but thats the whole point of the
Re:Specifications (Score:2, Insightful)
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)
Re:Somebody has to say it (Score:3, Insightful)
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 (Score:3, Insightful)
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.