Hacker News Reader

Comment by lincolnq | Hacker News Reader

Huh? I don't see how this person is a "blackhat". Just because they are playing with your server and trying to find holes doesn't mean they are intending to maliciously exploit them.

I also don't see how it is social engineering. What did the attacker convince you of?

View on HN

They didn't mention it on the emails at all. It was the contrast between 'my son is named x' and 'i kill u' that scared me. What I should have mentioned in the blog post was that there were other messages they left as comments in the code they submitted.

So at the moment you have to leave an email address to take an open test. (This will change soon to no address required). The guy consistently signed in with a fake email address, email to which was bouncing. I blocked that email address, which amounts to not accepting it to let someone sign in for an open test. This is just a soft warning, of course. So the guy appended a character to the address, and left me the message: "Why have you blocked test@example.com? Too bad codeboffin!" I just don't see why they couldn't have discussed it on email on which they were already in mid-conversation with me.

I presume the social engineering was coming. I would probably have told the person anything he wanted to know about my security setup by then. I don't think I would have been as open to anyone else off the bat.

Totally off topic but I love the concept of code boffin and wish you the best of luck with it.

Thank you very much!

no discredit to your post then- but your title couldn't be more misleading

(cross-posted to the blog): If all the "attacker" did was a #include /dev/random, how is that not something someone in your own QA team would do? Heck, if this was my company, that would be one of the first things I'd do (albeit only on my laptop or my staging environment)...

There may be other details that he hasn't shared, but if this is the "attack," it's pretty benign.

The #include /dev/random hosed the code evaluation task queue and everyone else's code evals started piling up behind it. This behaviour has been fixed now; every submission is tried just once and then the evaluator moves on. The attacker might not have known they could break my system in this way, but they threw in some system("rm -rf /")'s in there which is fairly malicious.

I'd yell at my QA team if I had one...

Reply on news.ycombinator.com