The Offensive Honeypot
Trowalts
idea I’d like to share with you does not have all that much to do with
Kippo, I do believe this is the right audience to speak to.
I recently spoke to Leon about a honeypot I would like to create and
he suggested I bring the idea here for some feedback, so just before I
start I’d like to give you a bit of background on the idea.
I’m sure some of you have heard of LaBrea the ‘sticky’ honeypot that
created a tarpit to throttle certain tcp based worms and in some cases
stop them completely. Well, I thought the notion of using a honeypot
for something other than information gathering and analysis was quite
interesting. I think my discovery of LaBrea might have been the first
steps towards realising an offensive honeypot and now I would like to
take things further.
The first time I used a honeypot in an offensive manner was last year
when I combined Dionaea and ettercap to create a service that would
detect worm propagating on your local network and isolate/quarantine
that host using ARP poisoning. This approach has its limitations but
from an academic point of view I thought it was pretty neat, it’s a
new way to use honeypots, it might not be the most efficient but it
opens up new avenues of research and different ways of solving a
problem.
I would now like to propose to you my current project, the offensive
honeypot (still lacking a name at this point). I present this hoping
to start a discussion; I would appreciate your thoughts on the topic,
suggestions, concerns, requests and tips.
The basic idea here is to have an offensive honeypot that is used for
username/password dictionary collection and striking back at the
attacking hosts. I’m going to break the rest of this post into 4
sections to illustrate the functionality of this honeypot.
Services/Protocols
Initially it will only support ssh, this is just for me to get a feel
for how it’s going to work and to sort out logic issues. Then later on
I would like to add support for as many services as possible, if it is
getting brute forced out there, it should be emulated by this
honeypot. The honeypot will be written in python, I am currently busy
with the ssh side of things and using twisted.conch. Further services
emulation I would like to support include; ftp, mysql, mssql,
postgres, vnc, rdp (what else can you think off?).
Dictionary Collection
This is a very important aspect of the honeypot, I would like to
collect the actual dictionaries used by attackers and record the
popularity/frequency of the use of these dictionaries according to the
service being attacked. The honeypot will include logic to check once
a new attack session has started, if the first username/password(u/p)
matches any previously seen starting u/p combinations.
If there was a match it keeps a record of the u/p’s coming in (as
associated with that dictionary) and if they all match the previously
seen dictionary then increment the frequency of that dictionary for
whichever service was being attacked. If the first u/p combination or
subsequent ones don’t match a previously seen dictionary a new
dictionary entry is made. There is a bit more to the logic, but this
should give you an idea of what I’m after.
Strike Back
This is the actual offensive part of the honeypot, it replays the u/p
combination the attacking host used back to that host. There are a
couple of reasons for this, firstly from ethical standpoint the
honeypot is not actively going out and attacking hosts on the
internet, it is merely using a form of offensive self-defence
replaying the attack it received to the host who sent it (I consider
this reasonable and acceptable force) in reference to laws regarding
self-defence in the physical world.
Secondly, this replay attack has a very high probability of working as
the host that is attacking you has most likely been a victim to that
same attack. Meaning the attacker is simply using a host they have
already compromised to pivot attacks from.
Once a legitimate username and password combination has been found it
is left to the discretion of the honeypot owner to what they would
like to do, by default the honeypot will not store this u/p. The
offensive honeypot could however be configured to do so and execute
commands on the remote host if so desired.
Something that might be useful is to view currently logged in users,
bash history, uptime and the IP address the last ssh connection came
from. Once again, the responsibility of ethical and legal behaviour
falls on the owner of the honeypot here. Guns don’t kill people,
people kill people.
Informant Functionality
With this functionality the honeypot may be configured as a semi-
automated warning system to inform compromised hosts of their current
state. Using whois information or crawling a webpage for mailto tags
to retrieve contact information and then compiling an email that would
only require the honeypot owner to verify the details and then send.
Any comments/suggestions or thoughts?
Thanks
Sam (@Trowalts)
Upi Tamminen
Interesting plans!
Now I have personally decided not to do any connections from my
honeypot that could be considered offensive, and will probably never
add any such features to kippo (they are easy for anyone to implement,
however).
Like you said, the offending computers are usually victims themselves
(the ones where the scans originate from).
The computers the actual humans log in from after a successful scan
are mostly windows machines running Putty.
And naturally the reason I don't "strike back" is that I would have
very hard time forming a legitimate explanation to the victim on why
there's a SSH break-in originating from my IP :)
All that said, if you want to connect back to the scanning server, the
password might not be the same they used to brute-force in to your
honeypot, as the attackers like to change the password to their own
using the passwd command.
If they have not changed the password, you'd have to playback every
password of their dictionary attack, essentially brute-force attacking
them yourself. Then, why not just use a scanning tool just like them?
However, if you wait until they use the passwd command on your
honeypot, I believe you are likely to have the password you need. Just
guessing, though :)
> --
> You received this message because you are subscribed to the Google Groups "kippo users" group.
> To post to this group, send email to kippo...@googlegroups.com.
> To unsubscribe from this group, send email to kippousers+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/kippousers?hl=en.
>
Trowalts
Thanks for the reply!
I have considered implementing this into Kippo, but decided as I want to support additional protocols and do not wish
for attackers to be able to successfully login to my honeypot that I would start a new one from scratch, I also think it could
be a fun undertaking.
I understand the controversial side of the strike-back and completely agree with you. Trying to explain to someone why your host is
attacking theirs would be tricky and most probably be met with anger from their side. Although I believe that they should be held responsible
for the lack of security on their host and actually be held liable for choosing a weak password that enabled an attacker to compromise that host
in the first place.
As for connecting back to the attacking host by replaying the attack observed on your own honeypot, this will likely not work if they changed the
password. I am assuming that once a host was compromised the attacker would not change the password of an existing account, in an attempt
to avoid detection and would rather create a new account. This is however an assumption and I don't have data to back it up.
This honeypot would replay every username/password combination received by the honeypot from the attacking host to the attacking host in realtime
as they come in. While I cannot fully justify it, it certainly is easier to justify and eye for an eye, instead of actually attacking the attacker with your
own dictionaries.
If I did allow them to login and observe their use of passwd it is likely like you said to gain their password, that would however mean that I could not
observe their full attack and dictionary which is one of the things I'm after. There has been a lot of work done (and still being done) on password breaches
and common passwords, I would like to do some analysis on the reverse of that. I;d really like to look at the most common dictionaries used by attackers and how they differ
between services that are targeted.
Mohab Ali
I gotta say i've thought about it long time ago but the big question
was:
"So what if it found the right password?"
"Dictionary collection" is great, i hate doing that manually :P
I really love your "Informant Functionality" idea.
My initial thought was:
"shutdown? write a note in home or desktop?"
But there has to be a limit on what you replay.
For example it shouldn't send duplicated passwords.
And limit in tries too, someone hit my kippo with 53K tries back-to-
back, i wouldn't want to send out those tries too.
But i have to disagree with Upi,
If the attacker changed the root password someone will notice.
Just my two cents.
Upi Tamminen
Found 471 unique IP addresses from humans (OpenSSH, PuTTY),
77 (16%) used the passwd command,
35 (7%) issued no commands at all
So around 16% of the users did change the password. It's not a big number, but
it happens, and I suspect many of those passwords would have worked in the
hosts they were scanning from. But still I'm just guessing :)
The query script if someone is interested (my sample size might be a bit
small): http://pastebin.com/s0dHzFDB
Mohab Ali
2 (3%) used the passwd command,
5 (9%) issued no commands at all
Leon v/d Eijk
Found 115 unique IP addresses from humans (OpenSSH, PuTTY),
18 (15%) used the passwd command,
15 (13%) issued no commands at all
Mohab Ali
This video might give you some ideas
(Paul Asadoorian + John Strand: Offensive Countermeasures: Still
trying to bring sexy back)
Chris Teodorski
So I promised Leon that I would contribute to this conversation and
I've been a slacker...so here goes.
First, may I suggest not calling it an "Offensive Honey-pot".
Offensive has connotations that I don't think apply here -- I'd
suggest a "Strike-Back Honeypot" or something similar. In no way
would your idea be the "aggressor" and I think Offensive suggests an
aggressive activity. (enough of semantics)
When I did my honeypot research, I allowed my machines to be fully
compromised so I could see what what going on -- I also spent time in
the IRC channel used for command and control with the fellows who had
compromised my servers. All of my attacks were brute force ssh to
Linux boxes with intentionally poor passwords.
What I learned from my experience was that once the machines were
compromised, the account was sold, for SPAM and for DDOS. Rarely were
root account passwords changed - - however, it seemed that when it did
it might have been competing groups or individuals "re-compromising"
the machine and trying to lock the others out. My machines seemed to
frequently be used as a pawn for the attackers to DDOS each other,
often "playfully".
I guess that I don't conceptually see the point of attacking back.
Notification would be way more useful (assuming your attack back was
followed with some note or the like to the owner) , but even if you
powered the machine off hoping to draw some attention to the
compromise, I think the likelihood that someone who's root password
was "l3tm31n" would understand the implications of a rooted box and
would be able to fix the issue are slim. Unless you want to take the
time to remove the malicious code left behind and clean up the dropped
tools before you powered it off, then notify the user -- all of this
occurring before the box is re-compromised, of course.
Having said all of that, I think the idea is interesting academically,
but I'm not sure that practically it serves much purpose.
Chris
Andrew Smith
I agree, I think there's little to be gained from 'attacking back'.
'You got me so I'm going to get you' seems a little childish.
Perhaps there's some middle ground? 'The obstructive honeypot', aimed at making our attacker waste as much time as possible. I guess this comes along the lines of tarpits.
Kyle Creyts
The 'honeypot responder' or 'entry attempt reflector'
Trowalts
As for the name, I haven't quite settled on one, The Offensive Honeypot was just so I did not have to call it "it", although @cutaway suggested "scutellata" which is the Latin name for the africanised honeybee. I rather like that. Offensively striking back might not hold very much practical value, although I would really like to approach this topic from an academic what if/what are the possibilities. You might not want to shut the compromised hosts down right at that moment, but having the capability to shut them down in the future (not likely all, but some) could be useful. Inversely having a "botnet" could also be useful, bear with for a second (I can see people cringing) it does not have to be used for evil. Performing a DDoS on a C&C server, deploying a tarpit on each of these hosts as the next conficker hits or tunneling your traffic through a relay of these hosts in the case of a sanctioned military strike. Taking that statement with a pinch of salt, I want to push boundaries and see what it can lead to, what ideas, uses and research people can come up with. I'm busy reading through a paper produced by Sensepost on their 2004 Black Hat Asia talk (When the tables turn - A discussion paper on passive strike-back).
Something else I would like to bring up and would be greatful to your insights and opinions is regarding the legal causation of negligence with regard to securing ones property (in this case, your host). Could or should a entity be held liable for having their host become/or from the start be in a state that could be deemed irresponsible insecure. How would a one begin to measure security and responsibility, could existing audit strategies help in this regard? Can self defense come into play here, is it entrapment if its a honeypot, what if this service is running a legitimate host? I have contacted the faculty if law at my university but will only be meeting with someone on the top in a few weeks time.
Today I finally handed off the other work I've been busy with so that I can focus on Scutellata? With that I'm excited to say development is underway.
Leon van der Eijk
Sent from my iPad
Kyle Creyts
idea like this may center much more definitely upon your intentional
actions, namely reflecting what you deemed malicious activity, than
upon those of an unwitting person who was taken advantage of; this
would be akin to hitting someone with your car, because someone stole
their car, and used it to hit you. The fact that they may or may not
have left their keys in it is entirely aside. If you were to argue
that it was their negligence which allowed the car to be stolen, and
that therefore they assaulted you, I believe you would be very
unlikely to prevail.
If you are trying to explore the legal atmosphere with regards to
events of this nature, perhaps understand the odds of winning such a
case, find grounds upon which to pursue it, or protect yourself,
academic experience in the area of pushing cybersecurity legal
envelope indicates that attempting to do so through application of
theory is nearly impossible, and a very large waste of time. The only
way this envelope will truly be pushed is when someone _does_ get sued
or prosecuted for an alleged violation or wrong-doing in the area. Of
course, if you know anyone willing to martyr themselves for the sake
of pushing the legal or ma=oral envelope, by all means, set them to
it.
> --
> You received this message because you are subscribed to the Google Groups
> "kippo users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/kippousers/-/HVFgpeq6ATIJ.
>
> To post to this group, send email to kippo...@googlegroups.com.
> To unsubscribe from this group, send email to
> kippousers+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/kippousers?hl=en.
--
Kyle Creyts
Information Assurance Professional
BSidesDetroit Organizer
Leon v/d Eijk
I respect your point of view Kyle, and I thank you for contributing to
this discussion. Using metafore can make a discusion go the wrong way.
Yes there are legal issues to overcome. I agree with that,
But I stand with the fact that a reaction could be helpfull in a
defensive way. I am not talking about taking out every ip that hits
my HP. Investigations is key of course.
Again, thanks Kyle for your point of view and wisdom
Leon
On 29 mrt, 19:26, Kyle Creyts <kyle.cre...@gmail.com> wrote:U
Kyle Creyts
realm of "law enforcement activity" and construed as vigilantism. I
only say these things to help you guys direct your efforts, and
hopefully keep you out of jail. It is much harder to enact solutions
and advance envelopes from behind bars. I wasn't suggesting that this
idea has no merit, or that it should not be pursued academically.
There are countries that make allowances for academics who know that
what they are doing may be construed as breaking the law, but find it
to rightfully be the only way to advance the state of the art; this
may be one such case. I suggest doing some research, and possibly
locating such jurisdictions.
Leon van der Eijk
Where do we draw the line. Just picking your brains here. I don't have any clear and proven answers. Let alone legally tested.
I hope the infosec people get awake and take this topic seriously.
Again, thanks Kyle for constructive comments
Sent from my iPad
Trowalts
Kyle Creyts
vocabulary for the foreseeable future, if this is something you intend
to pursue. (at least definitely in any written description of the
activity, and certainly public description, because I know the intent
is not malicious, but i would guess that it could go towards
establishing intent, were a case to be brought against you... Make a
conscious effort to describe it as connecting back, or playing back
the login attempts you received. I am not a lawyer, nor do I play one
on TV, and this is not legal advice, just a friendly suggestion.
> --
> You received this message because you are subscribed to the Google Groups
> "kippo users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/kippousers/-/UTPCTzwGEfQJ.
Trowalts
I don't however want to get to caught up in this, there are still other areas of this honeypot that I think will hold great value, the dictionary collection capabilities across multiple services and research avenues that will bring. As @trickynik noted, worm identification through dictionary used is novel. Finding common dictionaries based on service and the correlating them to determine differences could lead to interesting results.
Another friend from twitter informed me that he has asked a lawyer friend who works in this area for advice, I will post once I know more.
Benny Ketelslegers
--
You received this message because you are subscribed to the Google Groups "kippo users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/kippousers/-/fsLezb73SWYJ.
To post to this group, send email to kippo...@googlegroups.com.
To unsubscribe from this group, send email to kippousers+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/kippousers?hl=en.
--
--
PGP Key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3FB8E48B68CF245
Tomasz Miklas
I know it's fun to build system like that - heck, I had active response system back in early 2000-ish - distributed, self managed, with nice kick (firepower) if one of nodes was attacked.
Lesson learned - any offensive action (where you initiate comms) has legal weight, especially these days.
You have to be very careful not to cross the line, and the line moves depending on how much you spend on lawyers. If you are not careful you will quickly see where fun research project leads you - to the nearest police station or court.
I would leave it as theoretical exercise and not do it - too much potential to bite your back.
BTW not to be FUD-tastic but with the new EU legislation, writing this kind of tool can make you a criminal right away. Kippo is for info gathering, doesn't attack but add what we're discussing and you have a tool that some ass-hat lawyer will call illegal and you may be the firs case tried in court over new law... Is it worth it?
IMHO it's not, not now with that volatile legal situation but that's just my view.
Sorry for typos, writing from my phone ;)
--
Tomasz Miklas
Leon v/d Eijk
Thanks for a lively discussion. There is still a lot of ground to
cover regarding this topic. I have read some great comments the past
dew days.
Cheers,
Leon
Tomasz Miklas
The argument of negligence for running insecure system and liability of it's operators - if we go this way we should sue OS vendors because their work (or lack of thereof) is the source of problems :-) and pound for pound, they will win in any court...
... and on legal note (IANAL, but this is what I know), for example in Poland gaining access to a system without authorization is a criminal offence - no matter how you got there and for what reason - no permission = trouble. Modification (leaving note on the actual system not to mention shutting it down) qualifies as unauthorized modification and adds to the list and if you shut down you can get sued for losses incurred by the owner if that was a company or something similar.
Worst case scenarios/legal insanities:
- you are in EU and someone in US gets hit by your 'active response' system - you are screwed... most EU countries will extradite their citizens to be tried in US and for sure last thing you get there will be fair trial...
- you are in EU and hit non-US system in response to their actions - at best avoid this region for holiday or any other travel... at worst you will be extradited
- you are the US citizen - that would limit your holiday/work trip regions as well but US never extradited any of their citizens to be tried outside of the US
Similar issues show up in terms of cloud computing - which laws apply? Of the country where cloud operator is registered (and they are registered in multiple countries usually), the one where cloud user (like me) is located, what the T&C of the service says (mine or cloud provider's??), country where the attacker is located, countries that take part in transit of data (hello BGP, where will you send my packets today?), all of them or none?!
Legal is a minefield. I like the overall idea a lot but I wouldn't like any of us (or security folks overall) to go to jail for exercising our knowledge and passion.
I'm not afraid of "APTs"... I'm way more afraid of lawyers - regulating areas they don't know/understand.
P.S.
I planned to release some tools soon but now with the new EU directive, I'll seriously consider before I release anything because all of it is dual-purpose and law is so vague that any interpretation is possible at this point.
Lemckert Dennis
To add to the difficulty:
In the Netherlands, both laws apply:
1. Breaking and entering without prior authorization is a criminal offense, even without violating any kind of protection. same as in Poland (and basically everywhere mefinks)
2. If a system can be broken into because of negligence of the operator (eg: he doesn't apply patches when policy dictates a patch-regime anyway) the operator can be sued by the owner of the system/service. So, in the Netherlands there IS an incentive for operators to uphold service standards, because they can become a liability.
I've yet to see the first case going to court concerning the second point though. Perhaps the latest KPN-hack qualifies.
The reason OS vendors aren't sued is very simple: Their EULA exempts them from liability. Usually they state things like: "don't use this stuff in mission-critical situations" and "The software is delivers AS IS". For some reason everyone falls for it...
-
Dennis Lemckert
http://www.dlemckert.nl
G+: https://plus.google.com/u/0/100625212602501469190/about
PGP Key: 0xF66585F60DDEC3B6
--
Avid proponent of Netiquette. See: http://www.networketiquette.net
Only two things are Infinite: the Universe and human stupidity.
And I'm not sure about the Universe.
-- Albert Einstein --
Markus
the approach of a 'offensive' honeypot was implemented in honeytrap
some years ago.
The main idea was not being offensive though, the main idea was not
having to implement the protocol the attacker chooses to attack you.
So for every connection you accept on every port, you open a
connection to the same port on the attacking host, and send him what
he sends you.
This mode is called mirror mode, and well, I'd say it works.
A problem of this approach is, you lack protocol details, and if the
protocol chosen was encrypted, you lacked the plaintext, as you lacked
any information about the keys chosen for the encryption and just
relayed traffic from the attacker to the attacker.
Setting aside the legal implications, the key value of this approach
is little maintenance, you don't have to implement a protocol, you use
the attackers protocol stack, which allows to get traces for attacks
you did not expect or even think of.
For the legal implications, they exist, but I won't expect anything to
happen while your mirror mode is not downloading copyrighted content
via torrent where some association got a serve interest to sue you
for. I'm unaware of lawsuits on people which were infected by a botnet
or whatsoever and infected other machines afterwards. Might be a new
field of action for some lawyers though.
And even in case, the attacker pulled first, so you can still argue it
was 'Justified', as seen on the FX Network.
For a certain service, WINS (tcp/42), dionaea does this kind of mirror
mode too, I was hoping to be able to collect some traces with it and
see what needs to be done to implement the path taken by attackers to
implement it, but ... the service is yet to be attacked.
Converting dionaea to run in complete mirror mode is rather trivial,
nfq & mirroring code exists already, the docs on nfq show what needs
to be done, it is basically a configuration thing.
But, as I said, one would loose a significant amount of detail on the
attacks, all you'll get is traces, so you lack any knowledge of whats
going on the wire and every attack requires manual inspection.
Markus