Episode: 315
Title: HPR0315: Interview with ChrisJohnRiley
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0315/hpr0315.mp3
Transcribed: 2025-10-07 16:07:41

---

Music
Hello and welcome Hacker Public Radio listeners to another Finix, the Student Hacker's
Guide to Linux.
My name's Aaron Finnan, but as usual you guys can call me Finix.
Well believe it or not guys, this is my first episode of Finix Student Hacker's Guide.
At this year I had some time off before New Year for the birth of my daughter.
So it's good to get back into the throw things and I have some good news.
I recently had a conversation with a pen tester called Chris Riley and I thought I'd
like you guys here at I'll see you all again soon.
Well hello Hacker Public Radio listeners, it's Saturday afternoon and then having a quick
chat with Chris, Chris could you introduce yourself for the HBR listeners?
Yeah sure, happy to.
My name's Chris, I'm a penetration tester, ethical hacker, whatever you choose as your
title of choice.
I work for a large European bank in Austria, but I come from England so what else is there
to say?
My work full-time is a penetration tester, my background is network security and network
management.
I'm kind of moving more into web application testing now as that seems to be the way forward.
So how did you get into it Chris?
It's one of the things that quite a lot of people just fall into it and it's the same
with me.
I mean I spent years working as a server technician and people would just do crazy, crazy
stuff and I was always saying, well why are you doing this?
This is a test box but why aren't we patching it?
People were just saying, well it's a test box, we don't need to patch it and that just
drive me crazy.
It wasn't until I moved to our office in Germany that I really started to work with network
intrusion detection, working with snort, doing vulnerability scanning with Nessus and
working on WSUS, the Windows patching software.
It didn't work with antivirus as well, working with trend and Fsecure and I really wanted
to move that forward because it was only part of my job and it was the real part that
interested me.
It's the bit that I really wanted to go forward with and make a career of my company at
the time.
Won't really be able or happy for me to move more into security so I took the step of
leaving my job in Germany, moving to Austria to live with my girlfriend and just kind of
learning off my own back, reading as many books as I could get, doing as many courses as
I could find.
I actually spent six weeks in India taking some Microsoft exams.
I'd been using Microsoft Windows 2000, 2003 XP for years but I never actually managed
to take the exams.
So I took six months to read all the books, go through it all again and then went to India,
saw a lot of the nice sites, took some exams because it was nice and cheap to take exams
over there and I squeezed in a couple of security related exams, the CompTIA Security Plus,
which is kind of a basic security qualification and it's the best way to describe it and the
EC Council certified ethical hacker, which I have mixed opinions on.
I'm not sure if it was just the teacher or the books or just everything about the exam
itself but halfway through the course I just realised that they had absolutely nothing
at all to teach me.
It was like 75% of it was just old tools that no one would use anymore, basic stuff.
I've heard mixed views on the CH as well and so a lot of people have mixed views and
some people think that it's the best thing since life spread, some people think that it's
a little bit dated.
Yeah, I must admit that the version I took version 5 and then on version 6 now version
5 was like tools from early 2000 and this was in 2007 I was taking the course I think.
And it just annoyed me so much that we're using tools under Linux and you just couldn't
even find them on the internet anymore.
I don't know where they found some of these tools.
They always went back to the same stuff.
They didn't teach you things like end map or necessary or anything like that.
They used odd windows, port scanning tools like angry IP which they just went over three
or four times during the course.
It just seemed to be very repetitive, far too much crammed into a five day course and
very little of it was useful and there was also no basis for it.
It was, okay, you're going to do a scan now, okay, what does this scan do?
Well, I don't know, but it doesn't scan.
So I mean this could just have been the teacher that we were dealing with but there were
certain errors of it as well, SQL injection.
I think we covered SQL injection in one hour and the teacher really didn't know anything
about databases at all.
He was one of those things where I was sitting at the front of the class and every time someone
asked a question, I was the one answering it because the teacher had absolutely no idea
at all.
Pretty much the same when it came to the Linux stuff.
He actually had the nerve when we came to the Linux module to say just read through it
because I don't know anything about Linux and that just really annoyed me.
I think in the end, I think I got a 50% refund for the course because it was so badly handled.
Easy peeps.
I mean, that kind of leads me on a good question.
I mean, what sort of tools do you, you couldn't do without at the moment?
What sort of tools do you do being a pan disaster then?
I guess the top ones, I mean, the usual stuff.
Everyone uses an app, a lot of people use necessary vulnerability scanning.
I mean, I find MetaSplite to be a really great tool for exploitation.
I mean, it's very Windows-centric.
There's some Linux stuff, some Mac OSX stuff, but it's really good on the Windows side.
If there's a new patch coming out, HDMor, who writes quite a lot of the modules for MetaSplite
usually comes out with something pretty quickly, especially with the latest MS08067 SMBRPC problems.
There's usually an exploit out before anything else.
I think the only exploitation tool that I know that comes out with modules as quickly
is probably immunity canvas, and that's a pay for tool.
So I really like the MetaSplite framework.
Really does quite a lot of work for us.
On the website, I tend to use Burp Suite.
I don't know if you've used it.
It's a transparent proxy tool.
The latest version has a limited application scanner, so it finds you typical cross-site scripting
SQL injection kind of problems.
It does what it does.
It's a web application tool that finds the low-hanging fruit in your application, so it's
not the end or an B or but transparent proxies are a must when you're doing web application
testing.
So the suite really does do the job particularly well.
Yeah, I've never actually come across it yet.
We use lots of different tools for web applications, scanning and stuff like that, but yeah, I mean,
what sort of...
I mean, you touched on it earlier on, what sort of operating systems do you use as your
base to test other systems with?
Well, I think it was Ed Skodis who said, he gets the question a lot, should I use Windows
or should I use Linux?
And the answer is always yes.
You should always use both.
I mean, unfortunately, in the company I work for, we have to use Windows as a basis because
we use full disk encryption that only functions on the Windows.
So we tend to use a standard Windows XP fully patched, obviously, base install, and then
everything else runs on the VM.
We have VMs that run Windows, we have VM runs that run Backtrack and a couple of Debian
systems.
It depends what really works best for you.
There's always a boot CD, a boot USB or a VM image that will do the job for you as things
like Samurai, which is a specific web application testing framework from the guys in Guardians.
I find that's all pretty good as well.
It's more focused towards web application testing, whereas Backtrack is more of a generic
kind of VM or USB boot that does a lot of network and a bit of web application testing.
Yeah.
I mean, talking about track, did you know that they've released a new beta Backtrack
4s and beta stage now and out for release at the moment?
Yeah, I've been using that in some of the classes that we're running at university lately.
It's a bit raw, should we say, a few little, little nearly problems that it plays a sound
whenever you log in.
I'm sure you've experienced that, but there's no volume control, so it plays it at full
volume, which can be a little bit embarrassing when you're setting in the middle of a room
and you boot up your USB with Backtrack on it for the first time with your speakers on
full volume.
So, yeah, I learn quickly.
I really like the new version of Backtrack, because you can do apt-get and install whatever
else you need.
It's a lot better than the Slackware version, where you have to download the source.
I've got no problems installing stuff from source, but just being able to do an apt-get
is just so much easier.
Yeah, especially if you're using it in front of classes and that as well, you can't
beat the power of apt-get.
I'm a bit of an apt-get, junkie myself, to be honest with you.
Yeah, I'm not quite sure why, but I think the latest version of Backtrack is still using
an old version of M-map, as well as using 4.62 instead of the latest, which is 4.85
beta 2, I think, which is a bit of a mystery to me.
I thought they'd be at least using the 4.76 version, which is the version that was released
after Defcon, I think.
If you had ordered some work on the standard ports that are scanned, did a lot of scanning
of the internet, and found that the standard ports that were used in M-map needed to be
changed.
The new standard ports in 4.76 seemed to speed up scanning a lot, especially when you're
doing standard port scans and standard synth scans.
Obviously, another thing that you mentioned earlier on, but I just wanted to kind of
have a side note, so to speak, did you catch the HPR so with Ken Fallon talking about
auto-nesses?
It's just you'd be talking about necessarily.
I did, actually.
That was one of those times where, actually, I stopped in the car pulled over and phoned
one of my colleagues and said, auto-nesses, look it up now.
Internally.
Yeah.
I haven't actually had a chance to play with it yet, but it sounds like a really, really
good product.
Internally, we use something very, very similar, but on a proprietary basis.
From my point of view, from what I've heard of auto-nesses, the database stuff in auto-nesses
seems to be a lot better than what we're using at the moment.
But our proprietary stuff kind of fits in with various other things that we do internally,
so.
But auto-nesses is certainly a good project, it's something I'll be keeping an eye on
in the future.
Yeah.
I mean, I heard it, and I was marched the same way I was streamed, the lab telling the
boys, oh, have you heard of this product?
It does this, this, this, and this, and just watch all these ethical hacking students' eyes
light up.
I got something easier for us to use, but not hiding vulnerabilities between those of information.
You know, like, look, it's an Apache server, and, by the way, there is a critical vulnerability,
but you're not going to see it at the moment.
Internally, it doesn't find everything that's the problem, and it's a lot of people just
think that running a nest of scan is going to bring you up a list of every single thing
that's wrong in your web server, or your mail server, and that's it, you're done.
And it doesn't.
I mean, it's a network scan, so if your port is closed, then you're not going to know that
your piece of software that runs on the client side is out of date.
It's not going to do those client side checks unless you enable nest of local scans, where
you give it credentials to log into the machine, and then it can check patches on Windows
and Linux boxes.
But no one does it.
I mean, very few people I know, even know that that kind of feature exists.
They just think you run the scan across the network.
It tells you everything that's wrong with it.
You fix it, and you're finished.
I mean, I'm sure you agree that certainly in pan testing, it's a long process.
You don't just run a couple of quick tools and say, yeah, you secure checks and checks
and more checks.
It sounds sexy almost, pan testing, but there's plenty of times looking at screens and
repeating data that I'm making sure that you can actually guarantee that the results
that you've got are accurate.
Exactly.
You don't want to be writing in a false negative or a false positive into your penetration
test.
I mean, this isn't a vulnerability scan.
If you want to do a vulnerability scan, you do your end map, you take your port, you
do a nest of scan, you print it out, you write it on your company, you let it head, and
you give it to the client, that's a vulnerability scan at the basics.
A penetration test is not a nest of scan.
That's where you start from, maybe, to give you some idea where to move forward.
I've seen a lot of companies that are selling nest of scans and end map scans as penetration
testing.
It just annoys me, especially when we, as a company, we do testing for clients.
We go up against a client who says, we need this and this and this and this scan.
We say, okay, that'll take 15 days to scan, to check, to test, to do a complete penetration
test of this environment.
It'll take 15 days.
They then come back to us two days later and say, well, this other third company XYZ says
they can do it in three days.
Yeah, and then they'll be wondering why they got up to the end of it.
The thing is that they may never even know that they haven't got their money's worth,
because education for clients is very limited.
I saw a blog post on it recently.
I think it was the Snow Dogs blog, I think it was.
They were complaining about lack of standardization in penetration testing quotes.
I agree with it.
People just quote what they think.
I've never had any formal training on how long it takes to do a penetration test.
It's one of those things where you just put your finger in the air and were probably ten
days.
It's a very specific thing.
Quite a lot of the time the customer doesn't give you enough information.
The customer doesn't know what you're going to come back with.
If you come back and say, it'll take three days, they just think it's going to take three
days.
They don't get their money's worth.
Yeah, I think we're both agreeing with pan-tests.
They take as long as they take, there's really no kind of, it depends on what you discover,
isn't it?
Because what you discover opens the doors that you go down and it really does.
It really does.
If you run a scan and you find nothing, then you have nothing.
Having nothing in a penetration test doesn't mean you failed.
It just means you've got nothing.
It's one of the things quite a lot of penetration tests don't understand is that if you can't
write that you got root access on a Linux server, that doesn't mean you failed as a penetration
tester.
It just means that the server was adequately secured at this current moment in time.
You can't get root access on the server.
I find that in order to tie down with timescales better is to set goals for the penetration test.
If you just say I want to do a web app test, there's so many possibilities you've got cross-site
scripting, but if you specifically say, attack our web application and see if you can gain
access to our backend database, that's a goal, and you can specifically target your attacks
on this website to try and gain access to the backend database.
You can specifically say this area and this goal will take us three days.
If we can't gain access in three days, then that's a risk that the company will have to
accept is that the average attacker, it should take more than three days to get access
to the database.
It's one of those things where if I spend five weeks attacking an application, if I find
nothing, then if an attacker comes along and invests six weeks, then maybe they're going
to find something.
The more time you invest, the more you're going to find.
There's no guarantees, I mean, at the end of the day, the reality of what it is is a
scientific process and going through step by step and step, it's not a dark art, it's
a logical step to see what can and can't be done, and I think having set goals is incredibly
important part of actually achieving something, because you could take your lifetime to test
absolutely everything.
By the time you get to the end of it, you don't know, it could still be insecure at the
other end due to new vulnerabilities, and I think you're absolutely right, set goals
is probably an incredibly important thing.
Let's clients at the moment don't seem to understand that this is a test at a set point
in time.
It could be that two weeks after the test, there's a new vulnerability and your systems
are vulnerable.
Quite a lot of the time the client doesn't understand, they say, well, we had a test six months
ago.
It's like, well, okay, so you're only vulnerable to everything that's come out in the
last six months.
A lot of stuff happens in six months, a lot of stuff happens in six hours in this industry,
so you can never say that your website or your application is going to be 100% secure,
even if you've had a penetration test.
It's just going to be a little bit better.
I can't remember who said it, but I think it was in some American, Sonic talk or something
where they basically said, if a week's a long time in politics and six years and eon
and technology, and even two minutes is a long time in our industry, and we're working
in an industry that uses terms like zero days, it's kind of one of these things that you
have to keep your eyes open to everything that's happening around you at the time, but
the reality of it as well, the people that we're, the people that we're almost fighting
against are doing the same thing as we are.
They're looking for vulnerabilities every day, they're looking for new technologies.
In some ways, it's a race to see who can get to the problem first.
It was always going to go that way, I mean, it is a business now.
We work as penetration testers, we get paid to find vulnerabilities, fix them and protect
our systems.
The bad guys are getting paid to find vulnerabilities, exploit systems, you send Trojans, send spam
mail, they're going to earn money from this kind of stuff, and if they're earning money
from it, then they're going to invest time and they're going to invest resources.
The amount of zero days that have been released this year alone is just crazy, you've got
the Excel, you've got the PDF, exploit currently in the wild that's not been patched yet.
You've got a flash zero day, I think, that's just been patched by better, and that's all
within the last couple of weeks.
Zero days are very hard to protect against, I mean, there's no way you can protect against
a zero day, you can put protections in place that are going to scan communications and look
for suspicious activities, suspicious shell scripts, but you're never going to be able
to save yourself 100% from zero days, it's the whole point, no one knows what they are,
but that's how big companies are looking now is to put kind of intrusion detection systems
in place that do anomaly detection and say, well, we've never seen a PDF that comes through
with this kind of JavaScript inserted into it.
This could be an attack, let's quarantine it and have a look at it, but the problem is
they don't have anyone looking, anyone educated enough inside the company to look at these
PDF exploits for a good example and say, this is a zero day, we've never seen this before.
There's very few people who can pick apart a PDF file and say, there's JavaScript in
here that runs shell code, I mean, I couldn't do it, I mean, I know a little bit about how
PDF fits together, thanks to Didier Stevens and I've read a couple of blogs that entries
that he's written on PDF exploits, and I mean, he knows his stuff, but for every one person
who knows their stuff like he does, there's 100,000 people who work in IT, who have absolutely
no idea how a PDF fits together.
Yeah, I mean, I think in the reality for companies, security is always low on the budget, I
think that it's the reality that I think companies that have experienced technological-related
security breaches probably respect the amount of time and finance that actually needs to
go into making a system secure.
I think if you have lots of companies that probably security is the last thing that they
think about, and they just look at the wage for that security test, they're being a drain
on resources, and it's not until something bad happens that they turned around and go,
maybe it was worth having that guy on, that did look at security incidents as follows.
There's two bits to that, I mean, the first part is that if these companies aren't investing
in security at the moment, there's every chance they're never even going to notice that
they've got hacked.
I mean, you're gone other days of, you know, ScriptKiddy's a log onto your website, deface
it, and move on to the next website.
You're going to notice that the guys who are hacking your website for money aren't just
going to log onto your website and deface it, they're going to steal information, they're
going to insert JavaScript into your database so it's served up to your clients, and unless
you notice that that JavaScript is running on your client machines, or even worse, one
of your clients tells you, you may never even notice, or it could be months before you notice,
and that's embarrassing situation, especially when your client calls you up and says,
are you aware that you're serving malicious code?
That's something anyone wants.
And the worst part is forensically going back to look at that, because you've probably
never logged, because you're not thinking in security that way, you've probably never
logged any access or checked any of the log files, and actually tracing it back to the
date that this happened, or, you know, what way they got in it, because they've not taken
security seriously, it's hard to actually find out where the penetration happened.
Yeah, exactly.
I mean, plus, not only are you probably not logging it, but you probably don't have anyone
who's experiencing incident handling, so the first thing these guys are going to do when
they find they've got a problem is wipe it and restore, and that's it, you've just wiped
out all your information, so even if you did want to do a forensic analysis on it, you
don't have anyone who can do it, you don't have anyone who can make sure that the image
that you get is correctly formed, that you get volatile data from memory before you
pull the power cord.
Most of the time, these kind of things go uninvestigated, because the people who do the first
response don't know exactly what they're doing.
How important do you think that the forensic kind of aspect of looking at hacks is for
a pentaster?
I mean, it's something I'm really interested personally, I mean, I have the problem
where I can't do forensic analysis in Austria, because of language issues, kind of the first
question I'm always going to ask you, do you speak fluent German?
The answer's going to be no, and then they're going to throw out the case thinking I've
missed something, but it's still something that interests me from a technical point of
you.
And there's kind of two aspects to forensic analysis.
The question is, are you doing it to get a conviction?
Do you want to find out who infected your machines?
Do you want to find out who hacked your systems?
Have them arrested and put in prison, in which case, you've got to spend a lot of money,
you've got to have the policies in place, you've got to be able to catalog things as evidence
in a legal way.
Or are you just interested in finding where they got into the system, in which case, it's
just the case of looking at the logs, figuring out the entry point, looking at the event logs
on the machine and seeing what happened, who was accessing what through the firewall at
what time.
I think the reality of, you know, if you're having an organization, if you're having an
organization that's going to prosecute someone through the use of forensic technology,
it would certainly indicate that they've actually thought about the issue before it happens.
And I think this is probably a theme that's going to roll through our conversation.
The companies that think about security before a security incident are so much more prepared
when the incident happens than a company that just wakes up one day and finds out that
it's intellectual property has been stolen.
Oh, definitely, but in this day and age, people are not going to be investing money.
If there's a financial crisis going on, they're not going to suddenly sink 100,000 pounds
or 100,000 euros into what could possibly happen in six months' time.
They're just not interested in it.
They're trying to keep their bottom line as low as possible.
And if they start investing in things that could be, then they're going to have more financial
issues.
So that's something that worries me in the future is, is budgets for security going down,
not only that, but the budget for new security innovations, new ideas is new, you know,
incident handling or forensic initiatives inside companies.
The money's just not there at the moment.
And if they can't get the money to set up a new forensics lab or a incident handling policy,
then these companies are going to be lost when it comes to new infections, new Trojans
or new attacks on their systems.
Good security for a company for stop is a good base and a good base means that you have
a good means that you can go and get your business and you're not worrying about it.
I mean, but it just amazes me, I mean, it just amazes me the companies that don't think
about security and the knock on effects.
I mean, in reality, I suppose I'm kind of referring to the TK MAX incident with unsecured
wireless networks and $40 million worth of credit card details being stolen.
And it's...
Well, that's a great example, especially when you consider that they then had an employee
who said internally to their manager, we're still...
This is after the breach, so we're still using blank or weak passwords as administrator
passwords.
And they were just told that the company weren't interested.
So when they went public, when this employee went public with the information, TK MAX
fired them.
Whether or not he was right going public is completely incidental, but even after this
breach, TK MAX still didn't get that they had to be secure.
Yeah, I scary well.
Especially when you think about, they're not going to be the only company that are employing
such poor security.
And there, I say, without stoking the fires here for the flames, how many other companies
are showing complete disregard for the people's data?
It scares me when you think about the amount of data that's flying over the internet,
or the Wi-Fi is that people's personal private data that you've trusted to a company
and they just really don't care.
It's scary to think, but I mean, for every one company that says we've been breached
and we've lost data, how many companies are there that just think it's going to be so
for us not to say anything, and if we get found out, then we'll pay the fine.
I mean, that's even if they have to report.
I mean, I don't know, is the UK got a breach law now?
I haven't been keeping up.
I don't think so.
I mean, if you get your information stolen by a hacker in the UK, then you're probably
never even going to know it, not until your information is used to set up a false identity.
Luckily, we don't, in the UK, we don't use social security numbers, but in the US, there
still isn't data breach law set up all over the country.
As far as I'm aware, it's a region by region thing, so it's very susceptible to companies
just turning around and saying, well, if we don't report it, then maybe we'll get fined.
If we do report it, then we're going to lose $5 million or $10 million or $100 million,
so we're better off just not saying a thing.
Yeah, I mean, I did a lot of root kit research, and what you're talking about is a prime
example in that, that you don't get many out in the wild root kits, because companies
just don't admit to being kitted.
When they finally do discover it, we've been root kit and do you want to continue your
banking with us, I really hope that it's by this disclosure that we can get problems
fixed.
If you've got a security breach, my personal feeling is that you have a duty of care
to pass that information on, but you can also understand that if you're a system admin
who is a wife, two kids at home, and you perspective of doing the right thing and maybe
getting fired or keeping your mouth shut, you can understand why people don't come clean
and don't tell about what's going on.
Equally, you'd expect a company that's had a breach to invest the money in securing
themselves, so they're going to be more secure than their competitors who haven't yet been
breached.
Unfortunately, TK Max is the exception to the rule I hope.
If they're not, then people just don't get in the clue.
Well, you know, it's the phone, you know, phone me once, shame on you, phone me twice,
shame on me.
And I really think if TK Max got hacked again in the same sort of scale, I don't think they
would do a cover from just basically being caught out twice with your parents now.
No, I'm just glad I never used my credit card in TJ Maxx.
I mean, what do you see as like the biggest security threat in the future?
It's hard to say.
I mean, it comes back down to budget.
I mean, the biggest security threat I can see at the moment is budget cuts restricting
new security innovations.
I mean, I've heard of a lot of small companies who have been thinking more about their security,
but suddenly during the financial crisis, they're just not interested in investing the money
anymore.
A lot of companies that are selling security products, security appliances are seeing a downturn
in sales because companies are just not moving forward with security.
The problem with some of these companies don't understand that you don't need to spend
a lot of money in order to be secure.
I mean, you can buy a top-of-the-line intrusion detection, intrusion prevention system for
IBM and be secure, or you can load up a Linux box with snort and be secure.
The problem is it's going to be extra work.
If you're doing it with a snort box, you're going to have to upload the rules, you're
going to have to know what you're doing, you're going to have to tune it yourself, whereas
IBM is going to sell you a box that does it all.
I suppose if you're thinking about a box like snort, I suppose the reality is, you're
probably going to have someone on staff that gave you the idea in the first place, and
probably if they're looking at snort, they've got a certain level of technical expertise.
I'm a big one for the technical expertise that you have within a company actually nurturing
that and pushing that forward.
If you've got a guy coming up to you saying, why are we spending so much on this when
we could be doing it this way?
My view is that the company should nurture that person that's bringing this idea forward,
but does it happen?
No, that's the reality of that.
Well, it sometimes does, but the thing you have to also consider is during the financial
crisis, these staff might not stay at the company.
If you're going to lay off staff and you've got a hundred staff, if you just happen to
lay off the only one who knew about that product, then you could end up with an intrusion
detection system that no one's updating and no one understands.
There's no point in having an IDS if no one looks at the locks, because there we go.
We've proved a point.
Don't fire the security guy in the session.
Keep us on.
When you go into a company to do a security test, what's kind of like the thing that you
see the most, the one that you go, oh my god, not this vulnerability again, I wish people
would learn.
What thing do you keep on seeing that really bites you?
It's sad.
It depends what kind of test you're doing.
From the network side, I can't believe they're still seeing land man hashes.
There's just, for the last X years, land man has been crackable.
You've got rainbow tables that'll crack it in less than a couple of minutes.
If you're still using land man hashes and we can get any kind of hash from the system,
then we're going to get the password.
If you're not using land man, then we can still do pass the hash attacks, but that's limited
in certain aspects.
You can't do pass the hash attacks against things like RDP, but if we can actually get your
physical clear text password, we've got the keys to the kingdom.
You can then use that on other systems.
On the web app side, it's scary to think that the O wasp top 10 that was released on
the latest one was 2007.
It's not that much different now than it was in 2007 and it wasn't that much different
than it was in 2004.
I'm sure there's new stuff like cross site request forgeries popped up.
It's always been there, but people are now starting to see it, but you've still got
cross site scripting in so many web applications and it was there in 2007 and it's still there
in 2009 and people aren't fixing it.
People are looking at the O wasp top 10 and seeing it as a checklist to test, but the
developers aren't looking at it as a checklist to make sure that they're not vulnerable to
these things.
The developers who don't seem to be taking this on board and improving the products.
As penetration testers, I guess we kind of fall down because we go in, we hack the systems,
we write a nice report that communicates exactly what's wrong and then we walk away into
the sunset and that's our job done.
Unless we're brought on board to mitigate the vulnerabilities, we then leave the company
to look through the report and do what they need to do to make things better.
Quite a lot of the time that involves changing their secure development life cycle to incorporate
this kind of testing into the life cycle of a new product and people just don't get
it.
Quite a lot of development teams just don't seem to understand and the ones that do sometimes
take offense when you tell them that their systems are vulnerable.
It's very hard to walk into a meeting room with five developers and tell them that there's
a cross site scripting failure in the site.
The immediate response is okay and you're not validating your inputs or why should we?
It gets very adversarial at certain points.
It's a simple thing to fix.
It should be very, very simple to do.
Why is it so hard for us to take the OOS top 10 and just fix it and just make sure that
the implications aren't vulnerable to these things?
And what we're telling you isn't personal.
A lot of network administrators take things really personal.
When you give them a list of passwords and go, look, these are the passwords that we
could get through rainbow tables and they're passwords there.
That's it.
They're never going to talk to you again.
I've done tests before for clients where you've walked in and you said, I can't just
so you know, 10% of the passwords on your network are one, two, three, four, five.
It's just scary when the manager will look at you and go, I can't believe that.
But you just know you're going to come back next year and the password's going to be
one, two, three, four, five, six, because that's more secure than one, two, three, four,
five.
They just get it.
One of the fantastic companies that I've spoken to, they don't actually run brute forcing
against passwords anymore.
They just have a guy that sits in front of them and goes, I wonder if it's this.
And within two or three hours, he's got an account.
And you know, they don't really need to run through brute forcing or rainbow tables.
You can just literally guess people's passwords.
And it still happens.
I mean, it's been one of my runs in race or age as decent password security.
And I recently did talk some on rainbow tables and landmine hashes and so on and so
forth.
And it is one of my pet hates too.
I mean, what was kind of like the most memorable security incident you've kind of been
drawn to in your career?
It's been varied, really.
I think the biggest point in my career so far was finding a vulnerability in Tipa 3, which
is a contact management system, which is PHP based.
I'd attended a couple of presentations at a local security conference where they were
touting how incredibly secure Tipa 3 was.
And I was doing a penetration test where we had set goals to try and do cross site scripting
or attack users.
And Tipa 3 was pretty good.
And I didn't really want to leave it as it was kind of, you know, we always tested.
It seems pretty secure.
So I kind of started looking at the code and came across a section where they use an encryption
key to prevent you from changing certain details of the URL, basically puts an MD5 value
of the URL at the end so you can't change any of the values.
So I had a quick look at how they use the encryption key to create the MD5 value.
It turns out that it's a 96-bit long encryption key, seems pretty unbrewed forcible.
But if you look closely at the code, you can see that it creates an MD5 of the millisecond
value of when the server was installed, which could only be 1000 possibilities.
It then does an MD5 of that MD5 and sticks it together and then repeats the process so
you get a 96-bit long key.
So even though it looks very impressive, there's still only 1000 possibilities.
So this was kind of shocking to me.
The first time I could actually write into a penetration testing report that there's
a vulnerability in this and that present, there's no patch for it because I've only just
found it.
And it was an interesting moment to wait three months for the tip of three guys to patch
it and release, which they did at the end of January this year.
And that was kind of a defining moment for me.
The first time I've actually found something.
It takes me back to the days before, you know, I'm showing my age here, but the days before
the internet told you how to do everything.
You know, nowadays, if you want to do something, you just search on the web and there's an
instruction sheet that tells you how to do it.
When I started, I was using DOS 6, 2, DOS 5, Windows 3, 11, Windows 3, 1.
There was almost no internet, you know, there was a couple of sites, but you couldn't log
on to the internet and find a description of, you know, how I and I files are configured.
You just had to go in there and break it and see how it works and that kind of took me
back to that day and age where you're flying without an instruction sheet.
There's no one that tells you if you get stuck, what the next step is.
If you don't find what the next step is, then that's it.
There's no next step.
And that, for me, was really exciting.
Am I right in thinking that you've talked a bit about this on your blog as well?
Yeah, I did a release kind of a tool that automates it, but mostly for testing purposes.
I mean, I wanted to write a tool in Python, I haven't written anything in Python.
I thought, well, if I'm going to write my first tool in Python, I don't want it to be
a Hello World program.
No offense to Hello World programs, but I wanted it to be something a bit more impressive
so my first Python program calculates MD5 hashes and grabs the URL from the input and splits
it up.
I'm quite happy with it.
I mean, it's not clean.
It's not beautiful, but it's my first Python program.
I did a short video as well on Vimeo and that's on my blog as well.
So it kind of runs you through on the demo site how you can exploit this encryption key.
It's not one of those major flaws where you think encryption key great.
I can get access to all the background data and attack the server, but it was enough
for me to think it's a vulnerability.
What's the what's the web address for your blog?
It's www.c22.cc
I mean, is there any what sort of plans do you have in the future you're going to keep
on doing what you're doing at the moment or are you looking to get further training
and move forward?
Anything you're fancy doing in the community sort of stuff, I mean, what are your future
plans?
Well, it's been a big year for me.
I've only been working as a penetration tester full time since last March, so it's a year
now for me.
Last year, I've got a full time job as a penetration tester, I've learnt so much.
I've written three articles now for a couple of magazines, hacking nine magazine and one
for Linux magazine.
I finally got over my fear of doing presentations by doing a presentation at a local security
conference, nothing highly technical, but enough for me to be able to say that I can stand
up in front of 50 people and talk about something without fainting.
So that's, I've done a lot in the last year and I'm moving forward now by doing some
small university classes on exploitation, MetaSploitM maps and some simple stuff, moving
more into kind of advanced MetaSploit with MSF payload and things like that.
In the next year, my main project really is to do more training.
I really, I think that I learn more by doing training than I do by actually running a training
class than by reading a book.
I mean, I've learnt more about MetaSploit in the planning for my MetaSploit class than
I had in the last three years of using MetaSploit.
It's one of those things where it really does hold true, if you can't, if you teach it,
you learn it.
Yeah, I mean, I can't, you know, I can't have a number of praise for what you're saying
there.
I mean, I've learnt so much more by doing, you know, talks and presentations on subjects
and didn't HPR episodes as well because, you know, if you've got to go and it's almost
because you have a legitimate reason to invest huge amounts of your own personal time
into learning something inside out.
Well, that's what it's all about in this industry.
If you think that you can, if you're just in standard IT, if you're doing service support
or desktop support, you could spend three or four hours a day learning something new
every day.
If you're doing security, you have to live it.
It sounds cliched, but I've taken a week off once where I haven't read anything.
I haven't read any blogs.
I haven't read any news.
I just haven't kept up today with anything.
You come back and you've got 200 blog entries to read and you're just, you're so far behind
that you have to spend the whole weekend reading up on things that you didn't read before.
It really is a full time job and then another full time job just to keep up today with
these things.
I recently had some time off with my birth and my second daughter and I came back to looking
at emails and blogs and it took me the best part of three days to get through university
emails and learning to say to emails and personal emails and the 600 blog entries that you
know how to go and read and it's sometimes just get about taking the time off.
It really has to be a passion.
My idea of a holiday is flying to the Netherlands to go to a hacking conference.
It's, I find it fun and if you don't find it fun then this isn't a 9 to 5 job.
If you want a 9 to 5 job security is probably not the direction you want to be going in.
So what's your top tips for people wanting to get into ethical hacking then?
I'm curious about what we were talking about earlier is you really have to understand
the underlying stuff.
If you run an M-map scan you really need to know what it's doing.
You don't just need to know what the sand taxes so you can run a ping scan of your local
subnet.
You need to know that if you're running a ping scan of a local subnet that it won't actually
send a ping packet it'll use R because it's on a local subnet and it's quicker.
So if you don't know how to do an attack without a tool then you shouldn't be using the
tool.
I mean the tool is great for automating things, thousands of tools in MetaSploit thousands
of tools online where you can download and quickly launch attacks, do checks and run
tests on systems.
But if you don't know why it works and how it works and the underlying features of the
M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M