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.
I've used the same concept before on my work computer. I plant suspiciously named files on my desktop or (usually) less obvious places so if someone tries to search my computer and comes across this file, reports its contents, and I hear about it, I know it's time to change my password ;)
KappaStone
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?
Yahoo (and presumably other search engines follow suit) keeps some bogus entries in the DB so they can detect someone stealing their whole DB.
Some print newspapers run bogus classified ads so they can detect a competitor trying to bulk up their own classified section.
Some anti-spam companies post to newsgroups specifically to get addresses harvested; any email to those addresses is the sign of a spammer.
Handy, but hardly breaking news. Might as well run an article about a researcher discovering the usefulness of packet switched networks.
Cheers
-b
Another good example would be the RIAA putting bogus music files on P2P networks. For example, if you query and download a file that is named "Metallica - Enter Sandman.mp3" then chances are you have other files that are of dubious lineage.
The sword here cuts both ways, unfortunately.
----
Like listening to music? Then use Fission, the MP3 player with a brain!
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 personally don't want the system administrator at my Doctor's office browsing my health records or random people at my bank browsing my financial information.
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.
"Yes, quite superior to a honeypot, in every way."
Nitpick nitpick nitpick.
All this negativity because the intentionally vague yet illustrative example didn't pass the "can I poke a hole in it?" test.
The concept is sound. It just requires a little creative thinking to make it work in your own specialized case. Try putting energy into making the concept work instead of pointing out the flaws in the illustrative example.
You generally work around it. It's not as simple as "was this account accessed". I mean, you can track that on legitimate accounts.. you don't need fake ones..
but inserting fake addresses into the customer database, with fake credit cards and whatever so that you can tell when your database has been compromised, or otherwise, is a good idea, and has been done by many smart people for ages.
If the secretarial staff sends a message to that user, you'll know where it came from, and won't have a problem with it. If your competitor sends a message to it, you KNOW your database was stolen.
Nothing new here. The idea isn't necessarily to detect intrusion, but to track dissemination of data.
Say you have a soldier who you don't mind having a copy of your secret plans, but you'd still be willing to execute him if those secret plans ever appear anywhere else, say, in the possession of an enemy soldier you've captured.
So you put an intentional artifact into the plans, some subtle flaw or detail that is unique to that copy of the message.
The secret getting out is one thing. The trail needed to punish the individual responsible is another.
One place I worked at had 'root' as a honeytoken on all their production servers, there was a separate administrator account [they never would tell me what its name was...] and if anyone logged in as root it set off all sorts of alarms. I thought that was cool.
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.
Honeytokens sounds similar to the map publisher's trick of adding fake towns to maps. If a competitor copies the map, the original author/copyright holder can catch the copier by looking for the fake town.
Two wrongs don't make a right, but three lefts do.
Well, I don't know about the rest of the world, but in Australia I don't think hospital staff in general know SQL! Besides, if someone can use SQL to access the hospital database you have a problem anyway. If you think about it, a hospital would have some kind of built interface to the database, wouldn't it?
It's very easy for beginners to write erroneous SQL which will access every record in a table.
Not just beginners. Half of the reporting and maintenance querries are likely to hit their trick records. They'd be constantly responding to false positives.
Je fume. Tu fumes. Nous fûmes!
If employees are poking around in files which are designed to trap them
;)
this is vaguely reminiscent of the trivial pursuit case. basically a guy wrote lots of trivia books and was worried about ppl "stealing" his trivia facts for their own competing trivia books. so he planted a false bit of trivia (that columbo's first name was philip) and waited for someone to copy it. and trivial pursuit were the ones who did and they promptly got sued. of course the case got thrown out of court (you copy one person it's plagarism, you copy hundreds, it's research) but it's still an interesting point I think...
and of course, proof of my own vast store of trivia
dave
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
This reminds me of the cddb being stolen by Gracenote. Last time I checked, they were still claiming to own the database of audio discs (they may have changed their tune by now), despite the fact that it was built mostly from submissions by people like me. Gracenote basically took our diligent work, and started restricting access to it in order to make money. How do we know that they didn't build their own database? Because it contains entries for unpublished CDs that don't exist outside the homes of a few specific people; effectively honeytokens.
(Fortunately, an alternative now exists.)
Thanks for the links, very interesting.
Wise din't exactly live up to it's name...
Q.
Insert Signature Here
So, whenever a careless engineer trips something, he merely writes in the log "deliberately tripped such and such safety to demonstrate it to so-and-so", and no one is the wiser...
When I got my ATM card, I wrote three 4-digit numbers on the back of the card, and showed it to my friends.
Friend: "Oh, I see! You hid the pass code among some fake passcodes!"
Me: "No, ALL of them are fake. I keep the real one in my head. I figure that a thief will think what you are thinking, and try all three numbers. Then the machine will eat the card."
Well, I know for sure that at least some government maps have interesting "mistakes" near military installations.