Wednesday 24 November 2010

Building cheap console server

This time from the department of almost wasted time...

We all know that serial ports come very handy when you need to (re)configure something like a switch/server/firewall or similar device. In theory you can do that over TCP/IP nowadays with one hint - you need to have connectivity. All would be ok if not the fact that those very switches/firewalls you want to reconfigure actually provide the connectivity you need :-)

The Idea


Now... why spend hundreds of pounds/dollars on off-the shelf kit? Sure, it's cool, properly built and works unless you mess it up, but where's the fun part?! Today I needed a very very quick and cheap solution, so:

  1. SheevaPlug - £114.00
  2. 13-port USB hub - £19.99
  3. USB-serial dongles (pl2303) - £14.99 each
This way I have fully networked console server with 4 ports just under £200 - acceptable, especially when the whole thing is running off DHCP and calls home via OpenVPN - very easy to deploy!

Tricky bits

Generic Sheeva has one USB host port and hub has 13 of them - I want to send it off to remote location and have somebody plug it in and not mess up what's where. Trick is to write appropriate udev rules to detect adapters and give them ttyUSBn names according to physical port on the hub.


All would be fine and easy if it worked as documented - sadly it doesn't. First problem was that ATTRS{devpath} (as returned by udevadm info --attribute-walk -n /dev/ttyUSBn that allows to distinguish usb ports) was used by rule in tests but wasn't propagated properly on none of my Debian or Ubuntu boxes. Then I tried to match KERNELS for parent devices - nope... if you go too far up the tree it doesn't see s**t :-/


The Solution

Finally I got the working rule set - long story short, here it is:

KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.1:1.0",   NAME="ttyUSB0"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.4.1:1.0", NAME="ttyUSB1"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.4.2:1.0", NAME="ttyUSB2"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.4.3:1.0", NAME="ttyUSB3"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.4.4:1.0", NAME="ttyUSB4"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.3.4:1.0", NAME="ttyUSB5"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.3.3:1.0", NAME="ttyUSB6"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.3.2:1.0", NAME="ttyUSB7"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.3.1:1.0", NAME="ttyUSB8"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.2.4:1.0", NAME="ttyUSB9"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.2.3:1.0", NAME="ttyUSB10"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.2.2:1.0", NAME="ttyUSB11"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.2.1:1.0", NAME="ttyUSB12"


I had to use KERNELS match as above to have variables seen by the rule. I still don't know (and at this moment don't care any more) why it didn't work as documented...

The bottom line is that it works, it can be done way cheaper than commercial solutions, literally at the fraction of cost - if you don't mind the spider-ish look of it :-)


Update:
Hat tip to @herkii for pointing out another approach.

Saturday 31 July 2010

Making new friends with kippo

Less than two weeks ago I've sent a tweet asking for honeypot recommendations. I wanted to play a bit with something new, something I never did before, mostly because I never had time for it (right, like I have it now). Anyway, thanks to all the great people that replied to my tweet I've learned a lot and found some great software. Now it's time to give something back to the community.

Kippo - simply amazing

First honeypot I've reached for was kippo. It is a medium interaction SSH honeypot designed to log brute force attacks and log the whole session as it goes - including timings, typos, etc. The magic sauce is that you can play the session back (with typos!) and see what the attackers are made of. Believe me - playing back those session is totally amazing! Some samples are available on project's page.
There are also other features to like, like trapping sessions and not disconnecting them even if bad guys do logout, logging ssh client used (very easy to tell scanning bots apart from real people), quite nice interaction and most of all easy way to extend your honeypot it with your own commands.


Installing kippo



For the base platform I used one of my Debian hosts and started with
kippo 0.4. It was good to see how to run it, but options are limited,
so go full steam ahead and get SVN version - it is well worth it!


By default kippo runs on port 2222 but I wanted it on port 22 as normal
SSH would be (running as unprivileged user), so I've set it up on one
of my unused IP addresses - the setup was very easy.



Before you grab the latest version from SVN repo, you should install
required python packages (dependencies will be pulled in
automagically):



apt-get install python-twisted

svn checkout http://kippo.googlecode.com/svn/trunk/ kippo-read-only




Main benefit of SVN version is that it can use MySQL to log events
(alongside the regular log file) and that it can actually bind to given
IP address - version 0.4 binds to all available addresses which is a
bummer for me when I want to spawn totally fake host and have normal
ssh working as well.



Honeypots - rule #1



DO NOT run honeypot as root!



Remember that honeypots are software components, they may (and most
likely do) have their own bugs. Of course you have to be root
to bind to port <1024, or do you?



Configuration



Couldn't be easier... create unprivileged, regular user  account to run
your honeypot (I called it honeytrap), create your own kippo.cfg using
kippo.cfg.dist as template, set MySQL parameters, honeypot hostname
(attackers will see it after they log in), IP address to bind to and
port. If you don't want to use MySQL - your call... it may come very
handy for reporting. That's it - you are ready to go.



Now the trick is to get it running on port 22. There is obviously more
than one way to do it. If you have only one IP address available, you
should most likely go to kippo's Wiki page that describes how to make
kippo reachable through port 22
but if you
have spare IP address... =B-]



Now, how do I bind to port 22 as regular user? Somebody must have solved that problem before, right?
Sure, and they even created a package that solves this issue! It's called authbind and it's amazingly easy to use.



apt-get  install authbind

touch /etc/authbind/byport/22


chown honeytrap:honeytrap /etc/authbind/byport/22


chmod +x /etc/authbind/byport/22




Authbind works almost like sudo, except for the ports - not the
commands. In kippo's directory you will find start.sh script - add
authbind in front of the startup command and you are good to go.



Ready, set, go!



Ok - don't do my mistake... test your install - ssh into the honeypit and
see if you can log in. The root password is in kippo.cfg. Testing setup
is important - if sql database is gone, then you won't log in and in
kippo.log it will say that the root password was incorrect, when in
fact the problem is disconnected sql log backend.



Observations



Kippo is really great tool to learn what the bad guys are up to. If
they add user, they can log in as that user later. If they change root
password, it will be there for them when they return. The best part is
that of course you can see those passwords and suddenly you will have
new 'accounts' added and new, correct and active at the same time root
passwords (yes, more than one correct password!).

I've spent some time
watching the sessions recorded so far - there's so much to see, laugh
and cry, but I'll leave that for another post...

BTW, I blame Andrew (@Infosanity) for all of that - he got me back to honeypots topic, then other great tweeps came back with advice (much appreciated), so make sure to visit his blog ;-)

Tuesday 25 May 2010

Coder vs Security - friend or foe?

Certainly 140 characters is not enough to express all the thoughts around recent CSRF flaw in OpenCart and how it was handled (in my humble opinion it even deserves nomination for Pwnie Awards), although some people had a good go at Daniel Kerr.


Above is just a selection of comments that you can find on Twitter and in all of this negative karma there is some good thing going on. This incident got quite a lot of people to write some really good posts about the incident. Some of my favorite posts are Humble Helps and Psychology of "Secure Code" - definitely worth reading.

Although I'm not an expert in either coding or security (but I did quite a lot of both) I think there is also a bit more to it.


I used to work with many coders (people that write code) - some
extremely good and some extremely bad. When I look back I would happily
say that I was at some point doing a bit of both - at least in my own
opinion.

Developers vs code-slingers

There
is a significant distinction between those two groups at least as far
as I can tell. Developers do their job and write apps the best way they
can, they are proud of their job because they know they did the best
they could. Code-slingers, well... get it done, whatever... Usability is
something they may or may not understand (if it works, it's usable,
right?), quality and elegance rings the bell somewhere but that's not
in their church so nothing to worry about... and security is often
totally unheard of. Sad, isn't it?

I think we've all been there
and done more or less of that - it takes time to learn and even more
time to understand. That requires patience and a lot of energy, and
more than anything it requires a person to say "I want to do it right, I want to understand".

Recently in one of the emails I've found an anonymous quote by a person that was training newly hired staff - he said "I can teach them just about anything, but I can't give them a basic
sense of curiosity
". I couldn't describe it better!

Developers vs Infosec

In
my opinion the real virtue of a good developer is aiming for perfection
and taking criticism as a chance to improve. It is sometime painful (I
know from my own experience) but we all make mistakes and no matter how
good we are, there will be someone better that will prove we are wrong.
Real developers know how to deal with it because they want their code
to be beautiful in all possible aspects and they are curious people.
Some of those can be real inspiration and you enjoy every second you
spend with them.

Code-slingers vs Infosec

Mostly
not as skilled as developers, often with bad habits, etc - you can say
'developers in training' and that is ok. The first shock of getting
something that actually does the job is hopefully passing by and they
want more - or they don't...  they are so happy that their code works
that nothing else matters - that's where the problems come from.

It's
not a problem of skill, it's a problem of attitude. You can spend a lot
of time with them trying to explain, demonstrate or even send to some
training that deals with secure coding... still they couldn't care less -
oblivious, ignorant, often arrogant and portraying you (the infosec
person) as their biggest enemy because you prevent them from doing
their job. Yes, I've been there and worked with such people.

Free vs 'for money'

Your
options vary depending on environment. In 'for money' space you have
tools to deal with that - you can and should mentor such people to help
them understand. Sometimes a cup of coffee, friendly chat at the
whiteboard going through the requirements and proposed solutions or
ideas can really make huge difference. If you are not so friendly then
get your company to pay for some good training that will give those
people some good base to do their work (get rid of bad habits, don't
post code snippets on forum with URL to the product, etc) so they get
the carrot.
If that doesn't help, go for the stick - at the end of
the day, that code-slinger or his/her supervisor or their supervisor
will have to face a dilemma of signing off a code for production - it's
a business decision. If you can't block it and don't communicate your
security concerns it will be your fault if things go wrong and your
head on the chopping block. Brutal but simple - isn't it?

In the
free software world, where coder does something for little money (let's
say donations) or no money at all, what is the carrot and what is the
stick? If people care, they get good ratings, maybe more donations,
good publicity and are praised for their work, but if they don't give a
s**t... Oh, hi Daniel!

Free software users will complain, do a lot
of bad PR and a lot of them will go away migrating to other products,
but hold on... in this particular case THERE IS a commercial support
for OpenCart. What will the paid customers do with such response like
we've seen? How do they feel? They pay for support that they clearly
don't get :-(

Lessons to take away

If you are so called code-slinger
try to understand that writing code that works is not all you have to
do. You should create solutions - not problems. Don't behave like a
little kid, put your pride aside for a few minutes and listen to what
people have to say about your work - it really helps, even if it will
ruin your day.

If you are developer, please, be a mentor to the
code-slingers so they understand the beauty of the code and what it is
all about. Be a role model - calm, patient, their best friend and
inspiration - that's how miracles happen.

If you are the infosec
person please remember that saying 'no, you do it wrong' doesn't get
you anywhere. You have to be patient more than ever, explain why you
said 'no' and help find a solution - otherwise you have just created
another problem.

Whoever you are - remember that people
sometimes get frustrated, they have a bad day, they say things they
later regret - it's a design flaw we all have.  Daniel had just
demonstrated it and it got public. Simple 'sorry' can clear the
atmosphere and create a place to work together and solve the problem.


At the end of the day, we should all be friends, not foes... so I'll better shut up before I say something I will regret :-)