ethicalhack3r

It is very easy for some one to find an XSS vulnerability within a web application and write a report about it. According to WhiteHat Security (2007) there is a 73% chance that you will find an XSS vulnerability within a web application. Does finding one of these mean you have assessed the security of the web application? Let’s take a web application vulnerability that is ’seen’ to be more critical. Again, according to WhiteHat Security you have a 18% likelihood to find an SQL Injection vulnerability within a web application. So during the web application security assessment you have found an SQL injection vulnerability, the back end DBMS is a version of Microsoft SQL Server which has ‘xp_cmdshell‘ enabled by default. You manage to get a reverse shell and acquire a copy of the database. Great! By gaining shell access to the server does that mean you have properly assessed the security of the web application? No!

So let’s say that the person who found the SQL injection vulnerability left it at that and wrote his report and got a pat on the back. What happens to the other possible vulnerabilities which may affect the web application, including further SQL injection?! As you can see by just finding one or two or ten vulnerabilities within a web application does not mean it has been a thorough assessment. It’s not about how many, it’s about the quality of the test. That’s where methodologies come in.

Methodologies are peer reviewed industry guidelines on how a test should be carried out. There is no silver bullet when it comes to security, every web application is different. However these guidelines can help us to ensure that we have done a thorough test, as always, thinking out side of the box is encouraged. There is a danger when using methodologies and check lists that you stick to them word for word and do not sway from them. As long as your aware of this danger you should be fine.

What is the OWASP Testing Methodology?
The OWASP testing methodology is defined in the OWASP Testing Guide v.3.0.

Penetration testing will never be an exact science where a complete list of all possible issues that should be tested can be defined. Indeed, penetration testing is only an appropriate technique for testing the security of web applications under certain circumstances. The goal is to collect all the possible testing techniques, explain them and keep the guide updated. The OWASP Web Application Penetration Testing method is based on the black box approach.

The OWASP Testing Methodology divides the test into two parts, passive mode and active mode.

Passive mode: in the passive mode, the tester tries to understand the application’s logic, and plays with the application. Tools can be used for information gathering, for example, an HTTP proxy to observe all the HTTP requests and responses. At the end of this phase, the tester should understand all the access points (gates) of the application (e.g., HTTP headers, parameters, and cookies).

The active mode is split in to 9 sub-categories for a total of 66 controls:

Configuration Management Testing
Business Logic Testing
Authentication Testing
Authorization testing
Session Management Testing
Data Validation Testing
Denial of Service Testing
Web Services Testing
Ajax Testing

Each control is a particular test that should be carried out and has a unique reference number. The OWASP Testing Guide v3.0 lists all 66 controls which should be tested and how to test for them. Of course, all of these tests can not always be carried out. Some times they are just not applicable because that particular functionality is not present within the web application or you may not want to try some of the DoS tests on a live environment.

So in my opinion to carry out a thorough and quality web application security assessment, you need a methodology, the ability to think outside of the box, automated and manual techniques, persistence and a love for the job.

The OWASP Testing Guide v.3.0 is one of my favourite books when it comes to web application assessments. You can download the free PDF version or buy the very reasonable priced paper back from lulu.com. For further details on the guide visit the projects home page:
http://www.owasp.org/index.php/Category:OWASP_Testing_Project

1. *Advisory Information*

Title: WordPress >= 2.9 Failure to Restrict URL Access
Date published: 13/02/2010

2. *Vulnerability Information*

Class: Failure to Restrict URL Access
Remotely Exploitable: Yes
Locally Exploitable: Yes

3. *Software Description*

WordPress is a state-of-the-art publishing platform with a
focus on aesthetics, web standards, and usability. WordPress
is both free and priceless at the same time. [0]

4. *Vulnerability Description*

Frequently, the only protection for a URL is that links to that page
are not presented to unauthorized users. Security by obscurity is
not sufficient to protect sensitive functions and data in an application.
Access control checks must be performed before a request to a sensitive
function is granted, which ensures that the user is authorized to access
that function. [1]

5. *Vulnerable packages*

Versions >= 2.9

6. *Non-vulnerable packages*

Versions < 2.9

7. *Vulnerability Overview*

Since version 2.9 a new feature was implemented so that users
were able to retrieve posts that they may have deleted by accident.
This new feature was labelled ‘trash’. Any posts that are placed within
the trash are only viewable by authenticated and privileged users.

8. *Technical Description*

When WordPress implemented the new feature they failed to change the
permissions granted when the post is in the trash. This means that
an unauthenticated user cannot see the post, however an authenticated
user can, no matter what privileges they have, even ’subcriber’.

“Subscriber [User Level 0] – Somebody who can read comments/comment/receive news letters, etc.” [2]

9. *PoC*

http://codeviewer.org/view/code:c03

10. *Credits*

Thomas Mackenzie (tmacuk) – http://www.thomasmackenzie.co.uk/
Original finder and tester.

Ryan Dewhurst (ethicalhack3r) – http://www.ryandewhurst.co.uk/
PoC creation and analysis.

Arron Finnon (f1nux) – http://www.finux.co.co.uk/
Helped with documentation.

Matthew Hughes – http://www.matthewhughes.co.uk/
Helped with documentation.

Robin Wood (digininja) – http://www.digininja.org/
Helped identify the vulnerability type.

11. *References*

[0] http://wordpress.org/
[1] http://www.owasp.org/index.php/Top_10_2007-Failure_to_Restrict_URL_Access
[2] http://codex.wordpress.org/Roles_and_Capabilities

UPDATE 13/02/2010 –

WP unofficial patch released:
http://www.2shared.com/file/11360976/9b00062c/diff_wp.html

UPDATE 15/02/2010 –

Wordpress 2.9.2 released which fixes the Failure to Restrict URL Access vulnerability.

Report writing has a bad reputation, every one seems to hate writing them and believe it to be the anticlimax of the assessment process. I haven’t been writing reports for very long, the reports that I have written I have enjoyed, no doubt in time the novelty will wear off and I will grow to hate them too. There are however lessons that I have learnt in my short report writing experience which I believe could have made my report writing that little bit easier and less time consuming. Those lessons I am going to share with you and if your just starting out in your report writing duties hopefully these can help you too. Or if your a report writing guru share your tips with me! The reports I have written are mainly web application assessments so I will concentrate on those.

During the testing phase of the assessment, document as much information as possible! There’s nothing worse than getting half way through your report and realising you forgot to document the affected vulnerable variable, you didn’t take a screenshot or you don’t know why you took the screenshot in the first place! This wastes a hell of a lot of time having to retrace your steps or having to revisit the vulnerability to gather more information. All this information should be documented and well organised. What I have done to help keep me keep organised is to create a spreadsheet template for the documentation of anything I find. Make sure you gather all the information necessary when you have found something and don’t move along until you have all the information you need for that particular finding.

Take screenshots of everything but remember what you took them for! Find a suitable screenshot application, most OSs come with their default screenshot applications however there are also others out there that may make your life easier. When taking the screenshots ensure that you don’t have any other tabs running or any other applications which are not related to the assessment it self. Save your screenshots in an adequate location and use an intelligent naming system. i.e. clientname-xss-1.png If possible time stamp every screenshot to keep a time log of your work.

OWASP

The Open Web Application Security Project (OWASP) is a 501c3 not-for-profit worldwide charitable organization focused on improving the security of application software.

OWASP have tons of information on their website about all kinds of web application security topics. This information is very useful when writing reports to help you better explain the finding or to find the accepted term for the vulnerability you have found. OWASP also have some great books which can be bought in paper back form from lulu.com or downloaded for free in PDF format. If your not a member of OWASP become one now! (If you do use any direct quotes from OWASP reference them)

PAGE BREAKS! Use page breaks when writing your report, these help with the formatting and stop you having to keep reformatting the document as you add more information.

Be thorough! Explain as much as possible about the finding this will help the client in understanding the problem and hopefully save you some time at a later date in answering those questions. As well as being through and technical, explain your findings in laymen’s terms. You don’t know the technical expertise of the person who may be reading your report. In most cases managers and directors will read the report and they haven’t got a clue what a variable is or what Session Fixation is.

Proof read and re proof read. Your clients are paying good money for your professional expertise, they are expecting a professional report. Spell checkers don’t find all of the spelling errors! (Don’t forget to use the appropriate dictionary US/UK) Have some one within your company (who is authorised) to proof read the report for you. You’ve been looking at the report for the past 3 days, it’s always good to have a fresh pair of eyes have a look over it.

Keep a blank report template, this will save you time when writing future reports with not having to organise and format everything.

I’m sure there’s plenty of other things out there that I should be doing in my report writing to make my life easier, these I’m sure I will learn in time. If you have any tips/hints let me know!

Some resources and other helpful links:
Introduction_to_Security_Assessments.ppt
Security_Assessment_Template.doc
ORG (OWASP Report Generator)
The WASC Threat Classification v2.0
The Web Application Hackers Handbook – Checklist of tasks

One of the most popular posts on my blog is the Guest post: Current Available UK Degrees by 1337speak in April last year. I have decided to update the list as to keep the information up to date.

You who know me will know that I my self am enrolled on one of these University courses. I believe that if your starting out in security and want to make a career out of it this may be the best place to start. For me the course has done wonders, not only in what I have learnt however the people I’ve met and the drive it has given me to succeed in my chosen career.

BSc Security/Ethical Hacking Degrees in the UK:
Ethical Hacking for Computer Security – Northumbria University
Ethical Hacking and Network Security – Coventry University
Ethical Hacking & Countermeasures – University of Abertay
Computer Security & Ethical Hacking – Leeds Metropolitan University
Ethical Hacking and Security Systems Design – University of Sunderland
IT Security – University of Central Lancashire
Computer Security – De Montfort University
Computer Security – Staffordshire University
IT Security – University of Wolverhampton

More courses:
UCAS G550

I have surprised myself at how many courses are actually out there! Most of the courses have started in the past 3 years and will be starting in the next 2. It looks like there will be a lot more job competition in the next 5-10 years in the security industry. That’s OK, it will keep me on my toes. It seems information security in the UK is starting to become widespread and this can only be a good thing in the long run.

The listed courses above are for BSc university degrees, there are also MSc security courses and others out there which I have not listed.

What is Boxee?

Boxee is the best way to enjoy entertainment from the Internet and computer on your TV

http://www.boxee.tv/

Boxee allows you to develop ‘Apps’ which are basically XML files which grab RSS feeds. These Apps can be installed through remote repositorys. To truncate and combine all the security podcasts I used Yahoo! Pipes.

At the time of writting the SecurityPodcasts Boxee App includes PaulDotCom, Exotic Liability, TRACSec, EuroTrashSec, Security Justice and SecuraBit.

How to add the SecurityPodcasts App:

1. Run Boxee.
2. Click on ‘Apps’.
3. Click on ‘Repositorys’ under ‘Extras’.
4. Click ‘Add Repository’.
5. Enter my repository URL – http://www.ethicalhack3r.co.uk/repository
6. Click on ‘ethicalhack3r’.
7. Click on ‘SecurityPodcasts’.
8. Click on ‘Add to my Apps’.

SecurityPodcasts will now be in your Apps screen.

Currently SecurityPodcasts truncates the podcasts to the last 3 released. If you think this should be increased/decreased, let me know.