Secure backup of untrusted remote hosts

I didn't blog for a long time, so it will be a long post caused by some nightmares I had about not doing proper backups on some of my hosts.

Servers - all those small and big machines most of the geeks own, run or operate. As VPS pricing drops, we see more and more of those low-end, resource strapped servers. Organic growth usually means you start with empty server, some kind of definition what it will be doing and... from there it just goes downhill. How do you backup such VPS? Here is something I use myself.

My backup requirements

• Automated - it has to run without supervision in roughly regular time intervals, if it's not automated it will never be done (read no backup)
• Off-site - in case I loose the whole machine for some reason (because RAID is not backup and what fire doesn't destroy, water poured by firemen will)
• No Cross-Backups - because they require trust relationship between machines and if you think about using cheap VPS'es for cross-backups, remember that you get what you pay for!
• Automatically delete old backups - to save space, (my) time and money
• Append only - machine can only write data to its own, designated backup volume but can not delete or modify other volumes (accidents and rogue users do happen)
• Confidentiality - no unauthorized access backed up data
• Availability - storage volume has to be highly available so I can not only write to it knowing it's there, but also access backups when I need them
• Access controls - ability to define granular access rules and enforce append-only usage
• Economy - it has to have reasonable cost

How To Outrun A Lion?

You don't have to outrun a lion - it's enough you outrun the guy running next to you.

Funny enough, the same stands for securing your IT infrastructure - if you are in the "low hanging fruit" category, you get owned for sure - possibly before you even notice anything shady going on behind your shiny website. When you raise the bar a bit and step out of the damned circle, most of the attackers will give up on you and move to find some other target that is easier to compromise.Of course that doesn't work for determined attackers that want YOU and nobody else, but that's a story for another time.

What's that smell?

It's a smell of FAIL my friend...

Just recently I was helping two of my friends and doing some forensics on their servers (or rather on what was left out of them) after they noticed something strange was going on.  Long story short, the key part is that the attackers owned those boxes for months before they were discovered. They got in via path of the least resistance - badly written PHP web apps (there's so many of them!), dropped c99 or similar shell and owned the box to their liking.

In general, we suck really bad if it takes us months to detect such hacks.

Here come the benefits of scale

Wherever and whenever I look at any shared hosting providers, dedicated servers and alike, their default configuration is wide open by default. As long as the box is on-line and Nagios doesn't report issues, nobody is actually checking what's going on that box. Basically operators don't care - they provide functionality and they charge you for it. Oh yes, that's exactly what they do - charge you first and then provide a ton of stuff you don't need and don't use - unless you are an attacker that is :-)


Plenty of dangerous PHP functions enabled, dumb/bad configuration of network services and often the networks itself, total lack of monitoring (except for Nagios)... and all of that provided by default, just in case a customer comes back and says 'oh, that breaks functionality I need'; all because that would mean they (operators) have to go back and spend some time on enabling it later. Sure, it's easier to blame it on the "bad hackers in my interwebz" - great business model guys! I believe, that if you build the security into your system from the start, your TCO will be lower than going with defaults (loss of clients due to compromise, cos of bringing system back in service, etc) but that's a business decision of course.

Default configs are similar to default passwords.

Improving security posture

If you are on a shared hosting platform, there's not much you can do really. It's a shared host, so you (or rather the operator) has to find the common denominator - something that will satisfy everybody using this particular host. It's about finding the weakest link and bringing everybody else down to the same level - not good.

If you go with VPS or dedicated server, you can change a lot and it won't cost you a lot of money. Simple things can improve your posture and make it much harder for the attackers to run loose on your servers. Here are just three things you can do for free...

Egress filtering

Do you have an outbound firewall policy set to DROP by default? Can you imagine that in datacenter environment? Can it work well or will be a huge PITA?

Yup, easily doable and not that painful if you think about it. If we consider Linux, you can use iptables for that and I guess you already do have an iptables firewall of some sort that filters inbound packets. Let's extend it a bit - example below is for a simple web server:

# fail close - just in case
/sbin/iptables -P OUTPUT DROP
/sbin/iptables -F OUTPUT
# allow responses - majority of traffic comes here so it's a first rule
/sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# allow from self to self
/sbin/iptables -A OUTPUT -d 127.0.0.1 -j ACCEPT
# allow DNS servers listed in /etc/resolv.conf
for DNS in `grep "^nameserver" /etc/resolv.conf`; do
        if [ $DNS != "nameserver" ]; then
                /sbin/iptables -A OUTPUT -p udp --dport 53 -d $DNS -j ACCEPT
        fi
done
# allow SMTP out to email admins
/sbin/iptables -A OUTPUT -p tcp --dport 25 -d $DOMAIN_MX -j ACCEPT
# allow NTP outbound, local NTP is nice to have!
/sbin/iptables -A OUTPUT -p udp --dport 123 -d $LOCAL_NTP -j ACCEPT
# allow connections to our Linux repository mirror for updates
/sbin/iptables -A OUTPUT -p tcp -d $LINUX_REPO -j ACCEPT
# generic log and drop all
# /etc/syslog.conf => kern.=debug     /var/log/firewall
/sbin/iptables -A OUTPUT -j LOG --log-level 7  --log-prefix "FW-DROP: "
/sbin/iptables -A OUTPUT -j REJECT --reject-with icmp-host-prohibited

Simple? Yes!
Does it raise the bar? Yes!
Do I have to write IP addresses everywhere? No - iptables will resolve hostnames used in rules and I've noticed that for example if my $LINUX_REPO has several IP addresses, iptables actually created an entry for each of them.
But I can't do anything else! That's exactly the point - you shouldn't do anything else on a web server, unless there is a justified need for that (say access SQL database on another host, etc).

Wrapping up - all your web traffic (responses from web server and other services hosted here) will go into state matching rule, then you care for DNS, access to your own MX (only this one unless you have very good reason to do otherwise), NTP and distro updates are really nice to have, then drop all the other traffic. You could add rules for remote (off-site) logging, so you know when something tries to call out/pops your box.

Now, when an attacker drops his php shell he is pretty much very limited (no call back home, no portscans, no IRC bots, etc), unless he escalates access to root, but hey - how about a network based firewall implementing above?

Server hardening

Wow, you could write a book on that, but let's stick to the basics:
Install only the software you really really need (do you need that gcc and all dev libraries to run your web server) - remove what was installed and is not needed - you can always put it back if you need it later!
Turn off all services that shouldn't be running - my rule of thumb is to bring the system to the point, where I can run it entirely without any firewall, because there is no services to hide.
Keep your software updated - cron is your friend (to see what updates are available)
Kernel hardening - SELinux and Grsecurity (+RBAC) seem to be the key candidates here. Yes, that can take a lot of time to set up, but in most cases it's well worth it.

Just try to imagine how annoying it has to be for an attacker to own the box via web app, get root via local privilege escalation and not be able to install his rootkit (and hide) because kernel is monolithic (no loadable modules support) and has grsecurty baked in, with IP logging on resource overstep and other nice features it offers.

BTW here's the funny note left in one of the toolkits I lifted from one of friend's servers - what you make out of it is up to you. Oh... and credit to Ingo Molnár for his exploits and awesome comments in their source code ;-)

Logging and monitoring

Best things are free right? How about using syslog that comes with the system to send the logs off-site? Make a small box somewhere and simply pump it all out, so you have an off-site record in case of unwanted guests showing up.
Not enough bandwidth you say? There's an app for that - pump logs out via OpenVPN using LZO compression with or without encryption (hint: you can set the cipher to none) and as my test show, this can drop your logging bandwidth by around 80% and on top of that you can do traffic shaping in OpenVPN itself.

Now, having logs and not looking at them is a waste of resources, unless you are "checkbox security" organization and need it for compliance on paper... Depending on your pocket condition, you can use simple scripts to get what you need or get some free tools that sift through and visualize large amounts of data. For example Splunk has a free edition (up to 500MB raw log input per day) and there is many other (mostly paid for) products that you could use. Even "cloud based" services like Loggly (also offers free developer account) are available these days - simply pick something that works for you.


It is not a rocket science - it's really about common sense, so calm down and carry on.

UPDATE:
As @denishowe pointed out "it seems we need a checklist for dumb providers with the list of things to disable and another checklist for dumb users, so they can enable what they really need" - yes, that might just work :-)

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 ;-)

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 :-)

The Hex Factor at SANS London 2009

The competition is now officially over and I have to say it was AWESOME!

Those that made it to BruCON had a chance to play it, those that came to SANS London 2009 also had their fun, all the rest of you - bad luck :-/ maybe next time.

The Hex Factor was run for four evenings/nights at The Fox Bar and Restaurant located literally next to the Excel center where SANS courses were hosted. What can be better than beer, hacking and a spirit of competition?!

Tasks set by the authors were varied in difficulty and topics they covered. One category was about history and culture of hacking with a bit of general teaser tasks and was called Once Upon A Time, like finding a name of candy shop at <street name>, so that was a soft introduction.

My favorite category was Out Of The Box category (also known as Pure Leetness), where questions were really 'out of the box' and solving them was the best fun I had for a long time! First 100 points for finding a number 'hidden' in the message was really simple and here's how I did it:



I didn't have time to do the one for 200 points, but finally after some time I managed to solve the 300 points one - finding a secret number hidden in the PDF file - hats off to Didier Stevens for this task - it was amazing! Didier's blog was a great guide and help in the process.


Third category was Pwned and consisted of physical box with
sensors you had to trigger in the right order to get the code and two
systems to be penetrated. As I said, the difficulty was varied and so
were the nominal point values for each task, from 100 to 300, but you
could also get the partial points if you did only part of the task
properly. Of course during competition like this one you are never alone... Hello brotha!

Anyway, it was all very very friendly competition - beer infused with brains hurting after the classes (typical for 'SANS Fire Hose Syndrome').

Third category of tasks was Binary fu where you had to work your way through programs delivered as .exe files and get the secret codes out of them. First one was easy, but again I had no time to go through the remaining two. That is the reason why our team (I was working with Chris Riley, better known as @ChrisJohnRiley) was called Drunk and going home.

At the end we were #4 at the leader board but as it turned out, two teams of the first three were the same people, so kind of we are #3, so here we are - two of three winning teams, already in The Hex Factor t-shirts!

I'd like to say THANK YOU to all the people behind The Hex Factor - it was really awesome experience and great fun, so I hope it's not the last time we see The Hex Factor. See you next time!

CONFidence09.02 - post mortem

Well... my plan to blog live from the CONFidence was good but still remained to be more of a plan than a reality. Twitting went much better (possibly because you can twitt between chats with people, drinks, etc) so I'll wrap up what happened and how it went.

The conference was great - I really liked the lectures (those I actually made to), loved the chat with speakers and it was awesome to meet some old friends and make some new contacts. Overall, if you didn't come to Warsaw for CONFidence09.02 you missed quite a lot.

Day 1 summary
There was very nice presentation by Felix "FX" Lindner on how 'awesome' Cisco IOS is, Claudio Criscone (@paradoxengine) talked about security in virtualization environments, Frank Breedijk renamed hist AutoNessus to Seccubus (new twitter feed at @seccubus), Leonardo NVE Egea showed us how you can use the satellites to work as your downlink (and it seemed much easier than actually you would think), Pavol Luptak pretty much owned the RFID there (yes, the basic cloning kit is just €30), Elisa dropped the pressure a bit with Power Point Karaoke where Felix "FX" Lindner was presenting about detecting unknown alcohols, Raoul Chiesa gave great presentation about knitting (yes, knitting) and I was rolled into a presentation about IT slang/acronyms and there was something about insulting someone :-) and that was just the first day.

Day 2 summary
For those that survived the 'afterparty' on the evening/night/morning you had a chance to see nice explanation of the cold boot attack given by Nadia Heninger, Nick DePetrillo discussed 'what could go wrong' with intelligent power grids and believe me... there's a lot! Jacob Applebaum (@ioerror) gave us some TOR love and a lot of TOR laptop stickers. Alessio "mayhem" Penasilico (@mayhemspp) and Raoul Chiesa gave nice presentation on history of hacking telcos - there was some good info there... just before Raoul killed it all with final presentation dissecting the underground economy (with some slides show just after the cameras and other recording equipment was turned off). That was a really good one...

Finishing off, Frank has posted a bunch of posts about presentations we saw in Warsaw. They are:

• Fusing 3rd party threat feeds to obtain better threat intelligence - Eddie Schwartz
• Router Exploitation - Felix "FX" Lindner
• My Seccubus slide deck (slides from Frank's presentation)
• My TLS renegotiation vulnerability slides (Frank's lightning talk during one of the breaks)
• Mifare Classic anaysis - Pavol Luptak
• Power Hungy People - Nick DePetrillo
• The Tor Project - Jacob Appelbaum
• Underground economy - Raoul Chiesa
  

That's it for now - just make sure you get there next time :P

CONFidence09.02 - day 1 kicked off

Almost half of the day at CONFidence09.02 has already passed. Some interesting stuff of course...

Starting with Dragorn's and RenderMan's "Wireless threats; They're not dead yet!" we've heard once again how bad and how dead WEP really is. Good refresher for some people I guess. Best part was discussing client side attacks via wifi - airpwn style but without goats this time, using malicious JS with such a nice feature like browser side caching, defeating SSL, hiding all of that in plain sight with call-home feature that will be very hard to notice in most of environments.

Then I skipped several presentations - I really needed a reboot :-)

Next one I made to was Felix "FX"Lindner talking about how sweet hacking Cisco IOS can be. Frank (@autonessus) has already blogged about this one so I'll just put a few notes here.

• Cisco's HTTP admin interface runs off their understanding of HTTP and not Apache.
• IOS doesn't have recovery procedure for software crashes due to it's monolithic structure - the only remedy is to reboot the whole box (quite easy to spot even by untrained admin - the networkz are down!) which takes time (even several minutes).
• Cisco has added TCL scripting in some versions of IOS :-)

More to follow... and yes, we use #confidence0902 as hashtag.

Twitter, SPAM and zombie hookers

Came out of a blue - no context, nothing... BTW - we've got new URL shortening service.
All would be almost 'fine' but WTF is that? Not that I wouldn't guess but I'm just curious how owned you can get :-)

As a matter of fact, you can get owned pretty bad and what I've seen I would expect to be just a starter... the main course is coming soon!

WARNING: All the information provided in this post is available on the Internet. Links presented on screen shots should be considered malicious - do not visit them unless you really know what you are doing. You have been warned.

Just as your mother told you...

The best way IMHO to check stuff like that is the old school way...

Looks broken, right... redirect ok - that's what I've expected, but then... hold on - Client-Peer IP is not mine in any way... so who owns this one?

Isn't that just sweet? You go to a website and the traffic goes via proxy somewhere in China. Well - that's not all in fact. Let's grab a clean VM, make snapshot just in case, connect - let's see what a sexy girl has to offer, right?

NSFW

Don't to that at work or you may get strange looks from people around (at best) ;-)

The Bait

Page loads and looks like a blog - that's what the URL would suggest, but if you look in the source... I said THE SOURCE, not the boobs on the page!

Right... in the source you find the gems. First of all the page is using GeoIP JavaScript include from Maxmind - we all know it works well - to give the reader more personalized experience when you read the story (don't even tell me you are still looking at the photos - lol). As an effect the page resolves that I connect from IP address in London and that the poor girl comes from 'a small town near London , H9' and has to work as a stripper to pay her college fees...

London, H9... hold on - London doesn't have H9 post code (although on the page it looks like it was a part of address). GeoIP information is used in several places and looks quite... convincing... as long as you focus on the boobies... oh and forget about the fact that the bottom of the page says 'She is single boys!!!! She lives in my hometown of London' - right, somebody doesn't even have a spell check :-]

The Shot

Let's look at the gems on the top shelf... I don't have a lot of time to look at it properly, so just quick bullet points:

1. We have a JavaScript that contains two functions 'encoding' their input. Well kind of encoding because it uses ord() to do it and it seems the author is not very skilled, but anyway - he/she managed to produce working code
2. Call to encode function with referrer URL given as parameter - why someone is trying to steal my referrer info?
3. JavaScript print out an IFRAME linking to HTML file and passes encoded string as a parameter. The file came back empty, but GET string is left in their logs :-)

Getting the referrer string doesn't look that bad... right? Anyway, why do they want to know where am I coming from? Is that like SEO and affiliate tracking for malware? Interesting!

Post Mortem

Not much of it... As I said I don't have time to play with it properly and see if for example I actually get something from this 'empty' html file. It would be trivial to provide further payload if the victim provides properly encoded referrer string that is of attacker's interest.
How effective it would be if the bad guys used this just to check via which channel the victim came to them (they can also find out which channels are the most successful - it's just like marketing campaigns)? The next logical step would be to provide customized exploit - if victim came from Twitter do bad stuff to a Twitter user, Facebook - get them owned on Facebook, etc.

Surely the guys are learning and their intentions are not good. Keep an eye out and don't get yourself fooled!

wykop.pl owned - data stolen

The news of the day in Poland is that wykop.pl - polish site doing the same stuff as digg.com - got owned in a pretty bad way - database with user's login credentials and e-mail addresses was stolen. This post is a result of gathering info from public sites (in Polish - mostly off Dziennik Internautow which gave nice coverage) so all of it is already in public domain - otherwise I wouldn't quote any fragments or call on any information given here.

Info about breach goes public

Following what Dziennik Internautow wrote in their post, on 5 Sep 2009 a person using nickname Gimbus1xD has informed administrators of wykop.pl about the breach (no link - original post taken down) and about the fact, that some of the information stolen was already used to compromise account held with other websites, including allegro.pl (auction system like eBay). To prove his revelations, Gimbus1xD posted also screen shots of compromised Allegro account with transactions that happened two days earlier and another one with PHPMyAdmin browsing 'users' table.

The scary part here is that as Gimbus1xD wrote, about 40% of those passwords have been broken (despite being hashed) with simple dictionary and brute-force attacks because passwords were up to 7 characters long.

Allegedly the database is in the hands of vichan.net admins, which again allegedly shared 'unhashed' database with their moderators - including Gimbus1xD, who broke the news. So far it's not clear what made Gimbus1xD change his mind and make this information public.

That's not yet the end...

Are TFL top-up machines secure?

Another day, another FAIL.This becomes my daily routine it seems, but that's another story.
This time TFL - operating London's public transport network that covers undergound, overground, DLR, buses and whatever else comes.

During one of the Security Now! podcasts (#193 was about Conficker so it was somewhere between #194 and #196) one of the main discussion topics was (to no surprise) why Windows shouldn't be used in places like ATMs, hospital equipment (MRI scanners, heart monitors, etc) and most of other control
systems we have and use today.

In fact it's really hard not to agree with that. The arguments were very clear and sound:

• Most if not all of those systems are "consumer grade", not any kind of "industry type" things
• They are connected to the network
• They are not patched in general (it works so don't touch it)
• Most don't run any antivirus/firewall (not related to business function?)
• Many were not planned to be put on-line in any way (but we know they are)

The machine above takes cash or card - can we trust it then? Does it run anti-virus software and firewall (it's networked - it should)? How can I be sure it won't do what some ATMs in eastern Europe did? We can't be sure of anything if they end up like above, so feel free to add those to a 'Windows no-go list' if you wish and do top-ups on-line at the TFL website - I think it will be safer than at those machines - in general they don't reinforce any trust I might have had for them some time ago.

EC-Council courses certified by NSA

Chris Riley brought up a good post on his blog...something I totally missed in the news :-o

Following (literally) the press release from EC-Council we read "EC-Council Courseware certified to have met the CNSS Standards by the
United States National Security Agency (NSA) and the Committee on
National Security Systems (CNSS)". Shocked? I am!

What does it change or prove?
From my point of view it says that EC-Council knows how to do marketing, which obviously they do a lot. My impression when meeting EC-Council people at different expos and conferences were like, uhmmm... security? WTF? Business is business, most important part is to keep it going. Create a business model (hey - I don't blame you for that, good you succeeded!), build brand, loyal user base, make some media stir and here you go. It's simple - if I see someone talking about security with $$$ signs in his eyes, that's a sign for me to back off and go elsewhere. That's my personal impression regarding EC-Council as an organization - full stop.

My thoughts on standards and compliance
Chris has raised in his post some really good points about material quality. I would add, that conforming to standards and requirements (be it well known old friend ISO 9001 or any other ISO-based, PCI-DSS, etc - you name it) is just a matter of proper wording in the marketing materials and in some internal paperwork. I used to work in this area for some time (ie. standards, certification, implementation, paperwork - I've been on both sides of the process, from the bottom to quite high in the chain) and I can tell you that there are two ways to achieve so called "compliance" with any "standard" I came across so far - make damn sure you do what you say you do and do it very well and that conforms to requirements... or make sure auditors don't bother reading :-) and "OK" what they got. First impression method, social engineering, etc - great place to apply those!

Paper will accept anything you want, but this doesn't change in a bit what people know, what they do, how they work, use their knowledge (how much are they worth), etc.

Nothing has changed... exactly nothing!

The good, the bad and the ugly - Infosecurity Europe

Quick summary of Infosecurity Europe 2009, based on a bit more than a day I've spent there...

THE GOOD

There is always some good stuff at the conferences like Infosecurity. This one is no exception!

• Infoguard had a fibre taps (photo by Chris)

• EDR was more than happy to show us how their data destruction really works

... and after that you are left with a disk... almost like new :-) Thanks for the demo!

• ACUMIN had a full-scale proper, hardware simulator of Robinson R22 helicopter - great stuff, I got through 2 gates and won a RC helicopter :-)
• Information Security Awareness Forum together with SANS offer a free course that ends up with a GIAC STAR (Skills Test and Report) - this is very time limited offer!

This would be all good so far... so let's move on...

SANS Security 504 - 19 Feb - 23 Apr, Mentor Session, London, UK

December has just passed by and left very nice memories of SANS London 2008 conference - very extensive training, new friends and more than anything else - great fun all week long!

To stay in the good mood - I have the pleasure to announce, that I will be mentoring Security 504: Hacker Techniques, Exploits and Incident Handling during Mentor Sessions in London, UK. We will start on Thursday, 23 Feb 2009 and will meet weekly, every Thursday evening, till 23 Apr 2009. We will of course finish with Capture the Flag game (wohooo - that will be fun!) at the end of the course. If you would be interested in participating in the course, please contact me or SANS Institute directly.

You can find more information about my mentor SEC 504 session, it's content and requirements at the SANS website.