SoylentNews is people
SoylentNews
Normally, when I make a post on SoylentNews, it's to talk about some exciting new feature, our future, or something similar.
Unfortunately though, on rare occasions, I have to make announcements like this one. Sometime between May 12-13th, one of our email accounts was breached. The account ("test1") was left over from go live, over a year and half ago, and had a very weak password protecting it. We believe that an automated password guesser was able to find and access the account. Once breached, the account was used to send a significant amount of spam until we deleted the affected account on the 14th May 2015.
As a result of the compromise, several spam services have blacklisted our mail server; we're currently working to try and get ourselves cleared whenever we become aware of one of these blocks. We do not believe any user information or sensitive data was compromised; the account in question was simply a virtual dovecot account with no corresponding UNIX account attached to it.
mechanicjay was primarily responsible for handling this and cleaning up the mess, and I wish to personally thank him and the rest of the sysops team for their handling of this issue. We are looking at taking steps to prevent a reoccurence such as using fail2ban and the like. Unfortunately, most IDS systems like fail2ban are incompatible with IPv6 which we use extensively internally within our network.
A sysops meeting is being scheduled to discuss this and other changes we're making to the infrastructure.
I will update this article (or post a new one) with additional information should it become available,
NCommander
(Score: 5, Funny) by GreatAuntAnesthesia on Monday May 18 2015, @10:29AM
I mean, you left a small vulnerability in one of your services, which is fair enough. Plenty of reputable organisations have done the same.
But then you have the audacity to secure everything else so that the attacker can't escalate access, steal user information and payment data and then download all your incriminating emails for subsequent wikileakage. I notice you didn't let the attacker piss unintelligible l33tspeak graffiti all over your site's front page! What is this, are we back in the eighties or something?
Next thing you'll be telling us you didn't even try to cover the whole mess up before being forced to admit what happened. Furthermore I bet you completely failed to threaten some altruistic security researcher with legal action for giving you warning about the security flaw months before it was exploited.
Honestly, I don't know what the web is coming to.
(Score: 5, Interesting) by NCommander on Monday May 18 2015, @10:58AM
We've gone through a *lot* of pain to keep things as isolated as possible from each other. For example, we don't use SSH private keys for server-to-server communication, instead using kerberos keytabs which can easily be nuked from a central location in case of breach. If it wasn't for the fact that kerberos is a pain to use over the open internet, I'd love to remove the use of SSH key all together; *way* too easy to leave an authorized_keys somewhere after a breach and get pwned for it.
We give minimum privileges possible preventing non-sysops from having access to boxes they don't need to reduce our attach service; critical infrastructure runs in AppArmor, with the hope that if someone finds a remote execution exploit in slashcode/rehash, it would prevent breach; access logs in the database are regularly purged. Our firewall rules could probably be tighter though in retrospect though.
No security can be perfect, but we want at least to be a tough enough nut that only a dedicated attack aimed at us would stand a chance at succeeding. If I ever get to the post of rewriting the DBI layer, rehash would only talk to the SQL server via prepared statement and not execute any raw SQL directly. Unfortunately, that's pretty deep down on the TODO list.
Still always moving
(Score: 2) by Gaaark on Monday May 18 2015, @01:30PM
Is this itself not a security leak of info? Or honeypot? Hmmm....onions within onions, swimming pools within TARDIS'S.....
...my Snowden senses are tingling!
--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
(Score: 2) by Yog-Yogguth on Monday May 18 2015, @02:42PM
Nope. SQL stands for Structured Query Language, it's a given that it uses itself i.e. structured queries as defined by SQL. SQL gotcha's are well known and only allowing a small selection of previously prepared statements is going the extra mile, not hard to see why it isn't a top priority (note that it doesn't stop the SQL database from doing anything but it makes it harder for Rehash to send a bad or malicious query to the SQL database).
Bite harder Ouroboros, bite! tails.boum.org/ linux USB CD secure desktop IRC *crypt tor (not endorsements (XKeyScore))
(Score: 3, Informative) by NCommander on Monday May 18 2015, @03:42PM
MySQL prepared statements are something of a joke. You can't do much with them and they don't offer much improvement over raw SQL. To fully replace what Slash does would require T-SQL or similar. The entire database layer is wrapped with insert/select/etc. functions which take various arguments and autoescape on passing through to the MySQL level (see Slash/DB for implementation details). Slash is coded to be resistent to injection attacks, but the sheer amount of SQL is bloody staggering. I have a project on my TODO list to port the mess to PostgreSQL so I can take the entire database wrapper, and move it *into* the database where it becomes.
Still always moving
(Score: 2) by tibman on Monday May 18 2015, @08:45PM
Prepared statements do take the burden of sanitation away from the developers (as far as the DB goes anyways). Since slash has business logic in the DB that could make moving to anything else a bit of a pain : /
SN won't survive on lurkers alone. Write comments.
(Score: 2) by NCommander on Tuesday May 19 2015, @05:43AM
Relatively few FOSS projects seem to use the database layer for business logic. The odds if/when I get to it, I can remove 30k LOC or so from the DB layer into smaller stored procedures ....
Still always moving
(Score: 0) by Anonymous Coward on Monday May 18 2015, @05:39PM
if it suits what you're doing, openssh 6 and authorized key command feature are enough to centralize key credential management. ldap, sql, your grandma's kitchen cupboard, as long as you have or write an executable taking a login id and returning public keys you can store and manage them in a single place, wherever you like.