Slashdot Mirror
Honeytokens: The Other Honeypot
martyros writes "I just read a fascinating article
by Lance Spitzner securityfocus.com about a concept he calls
honeytokens. The idea is similar to that of a
honeypot, which he defines as "an information system resource whose value lies in unauthorized or illicit use of that resource". Rather than having a computer that's designed to be broken into, however, you have say, a record in a database or a file has no legitimate use; ergo, if anyone uses it, it must be illegitimate. An example he gives: adding a record to the hospital database for a guy named "John F. Kennedy". It doesn't correspond to a real person, so no one has any business looking at the file. If someone does access it, you know that they're abusing their privileges somehow.
The article has several other clever examples, which I found very thought-provoking."
I seed all my pages with special "token" email addresses that will only be found by a spammer using harvesting software (or a really really bored user). Normal people will never find it and never want to use it. It works amazingly well.
What happens if someone does a search for that happens to find "John F. Kennedy" and several other patients. Does that mean the person was in the wrong place?
Phone listings are not proprietary - anyone can publish a phone book. But you can't copy someone else's publication (like the telco's official phone book.)
In order to tell if a third-party phone book is legal or not, the telcos put a bunch of bogus listings in ever one. When third-party books are published, the telco can check to see if the bogus listings are in it. If they are, then they know that the book is an illegal copy of the telco's phone book. A book that doesn't pirate the telco's book (e.g. using listings purchased from the telco or by asking people to contribute contact information) will not have those listings in it.
This sounds like the same concept applied to a new purpose.
I agree, the database example is especially bad.
It's very easy for beginners to write erroneous SQL which will access every record in a table.
There are also lots of situations in SQL in which you legitimately need to access every row in a table, or in which the database does so on your behalf.
For example:
If you have a non-indexed table called Names. and you do select * from names where last_name = 'Smith'. Every row will be looked at. Legitimately.
They who would give up an essential liberty for temporary security, deserve neither liberty nor security
"Or they were poking around bored.
Or you've been hacked in which case you won't have an access record anyway if the hacker did their job right."
Well, for point one, if someone is bored and is poking around a medical database, that's a problem. And someone using a honeytoken credit card number is never okay. It's not something you do because you're bored.
And the hacker might have compromised one system and gotten data, but the point is that you put some fake data in there as well. So then hacker says 'hooray, I've gotten the CFO's password, let me go check out some interesting numbers in their computers' and suddenly they're caught red-handed, because that login doesn't exist in reality, and the computer in question is set up to notify people immediately on a honeytoken login.
These examples are taken from the article. It's a pretty clever idea and is much more versatile than the idea of a honeypot just as a server.
Or they were poking around bored.
Or there's a flaw in your software.
Well, then you'll just end up with a record of an 'intrusion' from localhost. if there is something wrong with your software, you should fix it anyway.
Or they were poking around bored.
The whole point is that they shouldn't be poking around. I certanly wouldn't want hospital employees 'poking around' in medical records. If someone is 'poking around' in sensitive data, then they are a hacker. If it's someone from your organization, you should either bitch at 'em or fire 'em, depending on what kind of work you do.
Or you've been hacked in which case you won't have an access record anyway if the hacker did their job right.
Not if you burn logs straight to a multisession CD...
autopr0n is like, down and stuff.
I first saw it mentioned at Black Hat 2002 in Vegas last year. The idea was that you would create fake session tokens for web applications and then monitor them for access by applications trying to brute force the session token values.
I mentioned it to a web developer who said that the idea has actually been implemented in some of the large e-commerce sites he's worked on.
-- thalakan
Or they made a mistake
Yeah, no employer would want to know about accidental DB access...
Or there's a flaw in your software.
Yeah, I *definitely* would not want to know about that.
Or they were poking around bored.
Once again, no employer would want to know about curious poking-around by employees.
Or you've been hacked in which case you won't have an access record anyway if the hacker did their job right.
Yeah, not worth it to take 30 seconds to make up a false record, since *every* cracker covers their tracks perfectly.
Yes, quite superior to a honeypot, in every way.
Different tools, different uses.
- (c) 2018 Hank Zimmerman
One reason this idea would be especially good for hospitals is because such actions have gotten hospitals sued in the past. Simply put, no hospital employee is supposed to view a patient's information unless required. So, if Nurse Betty is looking up "John F. Kennedan's" file, and also sneaks a peek at "John F. Kennedy's", she just broke federal law, and the hospital is going to want to know about that.
As for false positives in other instances, people seem to be just trolling. For example, every single day at a former employer of mine, a cell phone provider, we'd get false positives on customer who may or may not have been using fraudulent information to sign up for service. As such, we would stop and call the verification services we used, and verify that customer. So sure, out of thirty customers a day, it would generate five warnings, four of which were false. But one of them wasn't, and that makes all the difference.
Theres never going to be some "All seeing Eye of God" security system, but every little bit helps. Especially, as noted, in both banking and hospitals, where customer's information is bound to a need-to-know basis by federal law.
Mod Points: Helping you keep your opinion to yourself.
I can see this might be a problem in the USA though. In mosts countries, the secret services have nothing to do with law enforcement so a spook coming across a record that showed minor suspicous (in a criminal sense) behaviour, as long as it has no national security implications, would just ignore it. Unfortunately, in the USA, the agency likely to be doing the (illegal) snooping is the one and the only FBI, it means that (1) the national security has its hands tied by being constrained by procedures designed for ordinary criminals, and (2) procedures that ought to be use ONLY for serious national security (eg echelon?, unauthorized wiretaps etc) get misappropriated for urban law enforcement.
Je fume. Tu fumes. Nous fûmes!
Here's what I've been doing for years. I have folder on my drive with a very suggestive name. Looks like porn... a few really good videos, some nice pic series, a few porn games, the usual stuff but fairly high quality. This folder is sure as hell not in any area that the webserver or anything else connected to the web should be able to touch, it is in a fake user's directory. The last few .exe files on the list are not porn games, though. At least that's not all they are. They've had some rather nasty viral code (not in the GPL sense) wrapped into them. The only way those files will ever be accessed is if the box has been compromised or I really screw up running as root (which would corrupt my logs, but otherwise do nothing since the box is *nix). Those files have been accessed once. I screwed up and didn't apply a patch I should have. The script kiddie, on the other hand, went off the radar a few minutes after those "special" files were downloaded. Yeah, I had to rebuild the machine to be safe (faster then figuring out how much damage the little fucker did and I really didn't care who he/she/it was), but at least I got some satisfaction out of it :) Now, this part is of course purely hypothetical, but maybe something like this could be used to "poison the well" on those PTP networks the RIAA is trying to monitor. There are .exe compression programs out there that do a GREAT job of convincing antivirus software that a piece of software doesn't REALLY contain something like, say, Chernobyl. If you run MS shit on your box (or have a gaming box running MS like I do), give it a try for your own amusement. Then, when you're done, give the hype about "sandboxes" and "heuristics" some thought. Of course, script kiddies don't always run antivirus software, but why not be thorough? Fuck 'em if they can't take a joke.
my friend works at a GIS place. he corrects map coordinates. commercial map vendors will make fake streets to catch people using their data. so they have a policy. if its a commercial source, they need one more commercial source saying the same thing, else its bogus. government maps are always ok, though.
slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue