Hacker News Reader

Comment by jseifer | Hacker News Reader

Summary: The author of the article has a web app that allows you to administer programming tests to job applicants. The two languages currently supported are C and C++. As part of that process, (I'm guessing) the code needs to go through some sort of compilation process.

The author of the article had left a default whitelist on the production box that whitelisted /dev/random as being readable. The attacker compiled a program (took a test I'm guessing) that included /dev/random. The author found out based on ip and sheer luck that the attacker was a user of the system that he had corresponded with previously.

The reason I summarized this is because I wasn't totally clear on what codeboff.in was from the article. It makes sense how an attack like this could happen. The author seems to really know his stuff and the attack vector really was a small oversight. It's pretty unsettling to me, though, how persistent/insane this attacker seems.

View on HN

From the perspective of an information security researcher with plenty of time spent working on both sides of the issue, I can tell you that any attacker worth their salt will be persistent and use multiple attack vectors to get what they want. This holds true for bored teens, corporate spies and real penetration testers (not just dorks that get paid to run scanning tools on your network) alike.

I've spent the last decade doing mostly IT Security defense work. I don't worry when I see someone port-scan my servers. Those kiddos are almost always benign. I worry when I see that our IDS starts to correlate many subtle attacks over a long period of time from similar places (such as the same school, ISP, etc)

https://wiki.softwink.com/bin/view/Main/SaganFAQ#Why_Sagan http://www.darknet.org.uk/2010/07/sagan-real-time-system-eve...

Pretty good system to correlate different events to get a better picture of a potential intrusion. If you're familiar with Snort I recommend checking it out.

I already have a commercial system (with some homebrew, of course) that correlates, but I absolutely love playing with new things. I'll get this going in a lab soon. Thanks for sharing!

That's interesting. I've never admin'ed a server before so I hadn't thought about this at all.

It'll probably be useful to me to keep more verbose access logs and hash IP addresses to track what individual users (at least those not behind a group firewall) are up to.

Thanks for the tip!

What IDS do you use? Snort? What would you recommend for a home and business environment?

I don't generally talk in public forum about the specific products I use, but if you want to play with an IDS at home: snort or suricata would be good toys to play with.

In the enterprise, there are so many IDS/IDP and SIEM products out there, and they're all different. Some are great for mixed environments of Windows, UNIX and infrastructure. Others are better for specific platforms. Your best bet is to get demo licenses and start playing with them instead of relying on word-of-mouth or shiny pamphlets from marketing-types.

Thanks for the pointers. I hadn't heard of suricata before.

You should be most paranoid when you see/hear nothing

Please. No attack is perfectly stealth.

Keep in mind I've played both sides of this game. People who know how attacks work in the wild can usually spot things that might not raise the ire of average sysadmins.

So you are saying that in 2 minutes that you aren't watching logs somebody can't gain access, clear out the IDS and other logs and reset tripwire?

No, I'm saying an attacker would also have to find and destroy the immutable central logging store that all the stuff goes to. They'd also have to reach through the sands of time to get the stuff that's already been blowing up my phone. Get over yourself.

It's worth mentioning that no one is perfectly secure, either. A sufficiently bored, persistent and motivated attacker WILL find some kind of way in. I'll give you that. I've seen it play out enough times. But with centralized logging, transaction shipping for hot-site replication, and sufficient effort placed on separation of duties, an organization can minimize the impact a successful attacker can have, and can ensure that all audit trails remain intact in some way or another.

I am over myself. Note that everything I replied with was a question, and that I haven't had to proceed anything I have said with something like 'Keep in mind I've played both sides of this game'.

Anyway, to go on (keep in mind that I am genuinely interested in what you have to say). Isn't it true though that your IDS is only as good as your signature db? So if there was sshd or ftpd 0day that wasn't generic (generic shellcode etc.) that in theory you could spawn a shell without it ever being logged?

It's true. You could. But that shell and the activities therein would get logged in places that would make it hard for most attackers to cover their tracks. Mandatory Access Control and privilege separated daemons should also severely limit what that shell can do.

I'm not trying to have a pissing contest, but the reason we have defense in depth isn't to get 100% secure. You and I both know it's impossible. It's also there to preserve evidence if the unthinkable occurs. I do genuinely appreciate the forward thinking, so I'm sorry if I was a tad harsh in my reply above. Your responses (and your HN bio) came off a tad skiddie-ish at first blush. Being in infosec, where "Hacker" has a different meaning and stigma than "Hacker" in HN was originally meant to convey, I'm actually glad there are threads where Infosec "hacking" discussions can occur without getting completely buried by haters.

It's ok and thanks, I know I can also come across as terse/dickish sometimes. My profile is intentionally vague just because I prefer being anonymous (this is my 5th or 6th profile on here).

I worked in infosec (on all 3 sides, if you know what I mean) from the mid to late 90s, and then became disillusioned with the entire industry and left for greener pastures. I still attempt to keep on top of things (and have done the odd contract job here and there) but I am not all that up with everything going on.

Wrt the topic, what you are saying is that even with my /bin/sh running in the context of whoever sshd or ftpd are running as, by the time I figure out a local escalation, by then the activity on that shell has already been sent to another machine and onto your phone etc?

That was, of course, hyperbole (about blowing up my phone) however on certain very sensitive systems I do have a kernel module that provides a wrapper to execve() and that goes directly to a remote logging server and gets replicated. Yes, it's fucking noisy, but storage is cheap and databases are searchable.

As you well know, a careful individual can evade it if they know it's there, but the initial prodding would get logged.

At the moment, I don't hear/see ninjas sneaking up on me, hackers taking down my web app, a terrorist plot, or the shadow government spying on me.

Oh crap.

Thank you, that's a perfect summary.

Yeah, it took reading the entire article to figure out what the site in question is for and what it does that allows regular users to reinstall the kernel on one of his machines.

The first several times I read the term "code evaluator", it never occurred to me that he really meant evaluator as in executing user-supplied code on his server. Holy yikes!

Reading the rest of the article, it does seem that he's at least thinking about how to deal with the ramifications of that decision. It certainly takes some boldness to try this at all. Personally I would have got as far as "executing user-supplied code", thought about it a second, shivered at the implications, and picked a different idea to run with.

That blog post is one in a series of ongoing commentary about the site, so I don't usually explain the idea again. I guess it really is confusing out of context.

The code evaluation runs in a standalone server. I hope to learn what to block over time against a series of successful exploits. Evaluations that failed to compile/run/return-an-expected-result are marked on another server (on which they are not evaluated in any way) so I can study them later.

Yeah, like I say, Hats off to you for even trying. Sounds like it will be a fun site to run, since I bet you'll be battling against would-be hackers full time from here on out.

My sarcasm-o-meter flew off the wall. Well, I'm not deterred yet:

1. It may not be an insurmountable problem; see eru's and ambition's suggestions below.

2. There is a real business need for the application, and anything worthwhile can have unforeseen difficulties.

No sarcasm intended. (wish there was an HTML tag for <nosarc>). Fun as in intellectually challenging with a constant stream of new baddies to battle.

Thanks very much, in that case. Honestly I get no kicks out of dealing with the bad guys. I'm hoping the combination of [virtual machine quarantine] and [being low profile enough to stay out of the scope of most bad guys] will see me through.

Perfect, indeed. And sure, the read was disturbing.

Reply on news.ycombinator.com