PenTest Regular 10/2012

02/2012 (10) February

https://pen-testing.sans.org/contest/feb-2012

A Network breach...Could cost your Job!

��

��

��

��

��

��

��

IS YOUR NETWORK SECURE?

��

��

Global I.T. Security Training & Consulting

��

��

��

��

INFORMATIONASSURANCESERVICES

mile2 Boot Camps

www.mile2.com��

��

Available Training Formats

Other New Courses!!��

��

(ISC)2 & CISSP are service marks of the IISSCC. Inc. Security+ is a trade mark of CompTIA. ITIL is a trade mark of OGC.GSLC & GCIH are trademarks of GIAC.

11928 Sheldon Rd Tampa, FL 33626


��

��

��

��

��

��

��


��

��


��

��

��

��


mile2 Boot Camps

www.mile2.com��

��



��




��

��

��

��

��

��

��


��

��


��

��

��

��


mile2 Boot Camps

www.mile2.com��

��



��




� � ��

� � ��

� � ��

� � ��

��

��

� � ��

IS Y

OUR

NETW

ORK

SECU

RE?

��

��


��

��

��

��

INFORMATION ASSURANCESERVICES

mile2 Boot Camps

www.mile2.com��

��



��




� � ��

� � ��

� � ��

� � ��

��

��

� � ��

IS Y

OUR

NETW

ORK

SECU

RE?

��

��


��

��

��

��


mile2 Boot Camps

www.mile2.com��

��



��




� � ��

� � ��

� � ��

� � ��

��

��

� � ��

IS Y

OUR

NETW

ORK

SECU

RE?

��

��


��

��

��

��


mile2 Boot Camps

www.mile2.com��

��



��



http://www.mile2.com

Page 4 http://pentestmag.com02/2012 (10) February Page 5 http://pentestmag.com02/2012 (10) February

EDITOR’S NOTE02/2012 (10)

TEAMManaging Editor: Malgorzata [email protected]

Associate Editor: Shane [email protected]

2nd Associate Editor: Aby [email protected]

Betatesters / Proofreaders: Jeff Weaver, Johan Snyman, Dennis Distler, Massimo Buso, Juan Bidini, Edward Werzyn

Senior Consultant/Publisher: Paweł Marciniak

CEO: Ewa [email protected]

Art Director: Ireneusz Pogroszewski [email protected]: Ireneusz Pogroszewski

Production Director: Andrzej Kuca [email protected]

Publisher: Software Press Sp. z o.o. SK02-682 Warszawa, ul. Bokserska 1Phone: 1 917 338 3631www.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

Mathematical formulas created by Design Science MathType™

DISCLAIMER!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.

Welcome to February!As the English proverb states, “a good beginning makes a good ending.” Therefore, we have done our best to begin the month with a valuable and stimulating set of interesting articles. This issue features articles for both pen testers, and pen tester’s clients. You will find pieces from various fields such as, cryptography, mobile and web application pentesting. You will meet Raymond Friedman, who knows everything, or almost everything, about pentesting and you will have something to read on those long, chilly February evenings. In other words: something for everyone.

The issue opens with the Link section that is composed of two articles. Wardell Motley, author of the article Tool Jockeys in Disguise: Defeating the Push Button Penetration Testers, endeavors to prepare the readers for their meeting with a pen tester. Tools are demythologized and an individual approach is rightly praised. A gripping piece of writing for anyone who does not want to feel lost as a goose in a hail storm, grinning and bearing it, in front of a pen testing sensei. The second article Penetration Testing Strategy: Beyond Discrete Vulnerabilities, by Shohn Trojacek, strives to bring together customers with penetration testing experts. The author with natural sense of irony encourages the reader to change perspectives and to improve by this “the state of their profession and the quality of their products.”

In the section Close-Up, in the article entitled, Adopting Secure Software Development Processes, Michel Chamberland, not only presents the most popular techniques that help create secure software but, above all, he argues that investing in security is profitable, reduces risk and increases the quality of a product. Close-up is completed with Tor E. Bjorstad’s article Use and Abuse of Cryptographic Hashes. Apart from the guide into the hash world, you will be grasped by the real-life security flaws.

In the Basics section you will find Bartłomiej Wypych’s first article devoted to Choosing a Safe Password. It may seem trivial and unimportant, however we all tend to forget about the basics. The author reminds us about the types of passwords, ways of their protection and cracking. This article is reminder for pros and a lesson for amateurs. The second article in this section entitled Virtualization: Pills and Other Threats by Dariusz Wierzbicki deals with the significance of virtualization as far as IT security is concerned.

We present to you two articles devoted to web application penetration testing. Jatin Jain shows the readers the world of session management and Aleksandar Bratic discusses the importance of securing layer 2 in order to protect applications.

We also would like to present to you a pioneer book by Christopher Hadnagy, Social Engineering: The Art of Human Hacking, unveiling trickeries and explaining details of the widely celebrated terms of social engineering.

Last, but not least, an interview with Raymond Friedman, the gentleman on our cover, who is the CEO and President of mile2 and talks about his company, hot topics on the market, and the good and bad sides of a penetration tester’s life.We hope you will find this issue of PenTest worthwhile and absorbing.

Thank you all for your great support and invaluable help.

Enjoy reading!Malgorzata Skora& PenTest Team

http://www.scribbletime.com


CONTENTS

LINKTool Jockeys in Disguise: Defeating the Push Button Penetration Testersby Wardell Motley

What drives your search for a penetration tester? Was a recent security breach, or a compliance requirement, or maybe just a conversation over a round of golf with someone that recently underwent an assessment? No matter what the reason you will need someone who is not only competent and familiar with the latest threats and technologies, but also someone that can associate the vulnerabilities you may have to the business risk to your organization.

Penetration Testing Strategy: Beyond Discrete Vulnerabilities by Shohn Trojacek

Who really cares about a Penetration Test? It can be reasonably determined that by virtue of reading an article such as this, the reader already cares to some degree, about a penetration test. However, the reader is undoubtedly aware that many outside the field of IT Security, and ostensibly in the business world, may not care.

CLOSE-UPAdopting Secure Software Development Processes by Michel Chamberland

If you could tell your customers that you can help them secure their custom built software, significantly reduce the number of bugs and save them money in the process, do you think they would heed your advice?

Use and Abuse of Cryptographic Hashesby Tor E. Bjørstad

Some of the most devastating security flaws appear when there a logical error in the deployment or use of a security component. Cryptographic hash functions are among the most widely used security algorithms, yet they are often poorly understood by developers and security practitioners alike. The devil is the details, and when comes to custom cryptographic mechanisms, it is deceptively simple to take a wrong step.

BASICSChoosing a Safe Passwordby Bartłomej Wypych

Passwords have become an integral part of our computer lives to the point, where we no longer pay any special attention to using them. Everyday we use one to log on a computer, access a social network account, or a discussion board, check e-mails and pay bills. All this the

comfort of our homes. We tend to forget that passwords are used to verify the of a person trying to access something. Be for any of the aforementioned reasons, passwords are applied to ensure that the person trying to gain access, the person they claims to be and access to the stored data.

Virtualization: Pills and Other Threatsby Dariusz Wierzbicki

Virtualization addition to many advantages also raises security. Virtual environment are very different from physical; it requires a different approach to security matters. Administrators often are not aware of safety issues specific to virtual environments or realize the dangers after deployment.

WEB APPSession log-in-outby Jatin Jain

Web applications are not able to recognize whether a request somehow related to the previous requests, Session Management is the technique used by the web developer to make the stateless HTTP protocol support session state.

How is Second Becoming First?by Aleksandar Bratic

Very often IT personnel in attempt to protect their applications, forget to secure layer 2, relay to much on anti-virus and firewall solution. The main problem is that when layer 2 is compromised, upper layers are not aware of problem, so every upper layer protection is useless.

VIEWReview of Christopher Hadnagy’s Social Engineering: The Art of Human Hackingby A Rao

Social Engineering is not a technical book, at least not in the traditional sense. You will not see extensive discussion about ports, firewalls or encryption. If you were hoping for any of those topics, then you are in for a disappointment.

INTERVIEWInterview with Raymond Friedmanby A Rao

Raymond Friedman is the CEO and President of mile2, and has been in the IT Security Space, since 2002. While in this industry, he has been actively engaged in consulting for global financial and government institutions; performing security audits, penetration tests and digital forensics services.

06

08

30

14

36

40

20

26

46

48

LINK


This message is meant for you, all of you. The CISO and the IT Director the decision maker and the network administrator’s the people that

man the front lines of the information security trenches. If there was ever a time for you to take stock in your information security capital it’s now!

What’s your security strategy? When was the last time it was tested and by whom? Was the individual or entity qualified? How did the results of that engagement positively impact the security strategy within your organization? If you can’t honestly answer those questions then you may want to take a second look at the vendor and your choice of penetration tester.

Do you know what to expect from your vendor and penetration tester? Unfortunately many companies do not know what to look for when engaging an information security vendor for a penetration test or vulnerability assessment and can only smile and thank the vendor when handed a report with lots of vulnerabilities marked with highs, mediums and lows. As the customer you need to understand how those vulnerabilities affect your bottom line and your business.

The Wrong QuestionsDuring a recent engagement meeting we were asked by the client, what tools do you use and how long does it normally take you to break in during a penetration test? Well in answer to that I have to say that it really depends

on the engagement and the client. There have been times where no tools were used at all during an engagement to exploit a site while other times a custom built script will be the most efficient way to go. You should pay less attention to tools and timing and more attention to what your end goal should be for the engagement. I know a lot of people have the check list mentality and want to see a set list of things to do or a certain toolset that should be used during an engagement but if your pen tester’s sticks to one particular method or toolset I guarantee you he will miss things. Penetrating testing tools are useful during an engagement and they can be used to perform trivial tasks but they should not be the crux of a penetration testers skill set.

The Right Questions?Defining what you need to test is as important to your security strategy as having the proper policies and procedures in place to govern the security of your organization. If your development team just built a web facing application for your sales division and you want to

Tool Jockeys in DisguiseDefeating the Push Button Penetration Testers

Figure 1. Push button for PenTest

What drives your search for a penetration tester? Was it a recent security breach or a compliance requirement or maybe just a conversation over a round of golf with someone that recently underwent an assessment? No matter what is the reason you will need someone who is not only competent and familiar with the latest threats and technologies but also someone that can associate the vulnerability you have with the business risk to your organization.

LINK


Consider this article as a form of social engineering with the goal of raising the reader’s awareness of perspectives beyond

the world of IT security, ways of connecting with those audiences, and some ideas for enhancing the life cycle of a penetration test. If reading this in electronic form, the reader is advised that it contains at least one PDF based 0day (a previously unpublicized vulnerability that can be used to gain control of a computer), used as a proof of concept, that most virus scanners do not detect as of this writing.

Definition and PerspectiveWhile no doubt, an experienced Penetration Tester might quickly detect absurdity in the announcement of a 0-day in a reputable magazine, instead recognizing it for what it is, a literary device designed to shock and awe, through its absurdity it may for a moment provide insight into the perspective of those with limited understanding of what a penetration test is or its purpose, in that, such persons may not immediately dismiss such a claim. Depending upon which camp the reader falls into, penetration testing may sound like some pseudo-Freudian excuse to talk about the polarity differences between the male and female anatomy, at least that is what the author’s mother’s first impression was after telling her what he did for a living. Based on some of the penetration testing reports the author has read, perhaps she was not that far off.

There is often a stigma within industry of what constitutes a penetration. For purpose of this article it does not mean pressing a red button on a hacking tool, rather much greater intelligence is required. Penetration testing is defined as attempting to simulate unauthorized access to key computing resources within an organization’s networks and controls for purposes of discovering where it is possible to bypass the organization’s security controls. For the non-technical mothers reading this article, a penetration test is like hiring someone to break into your house and tell you where your security system has blind spots.

Drawing ParallelsBypassing a security system is one thing, but with whole organizations the process is more complex. It

Penetration Testing StrategyWho really cares about a Penetration Test? It can be reasonably determined that by virtue of reading an article such as this, the reader already cares to some degree, about a penetration test. However, the reader is undoubtedly aware that many outside the field of IT Security, and ostensibly in the business world – may not care.

Beyond Discrete Vulnerabilities

Figure 1. Automatic Hacking Tool

CLOSE-UP


Penetration testing is an effective technique in finding vulnerabilities and demonstrating the impact and severity of these issues. Typically, a penetration test

report will recommend security mitigations such as patches, firewalls, IDS/IPS, NAC, anti-malware, etc. In this article I’d like to focus on putting in place long term mitigation for custom built software and encourage you to suggest secure development practices in your penetration test reports. We’ll show how research suggests that organizations should invest in secure software development processes because they reduce the overall number of bugs in software, total expenditures and overall risk to organizations. In this article, we will first start by discussing what secure software development processes are and explain the most popular techniques used: threat modeling, code analysis, code reviews, penetration testing and fuzz testing. We’ll then talk about how these processes can improve software quality and reduce bugs by drawing a link between software quality and application security. Next we’ll discover how these processes can reduce costs to organizations and have a positive ROI impact. Finally, we’ll explain how secure software development processes are one of the most effective ways to reduce risk for organizations.

Common Secure Software Development ProcessesWhat are secure software development processes? Many techniques are known to help create secure

software solutions. Different secure application development methodologies exist such as the Microsoft SDL and the OWASP Clasp project. They all use different techniques to meet their end goals but the most commonly used techniques are: threat modeling, code analysis, code reviews, penetration testing and fuzz testing. Therefore, this article will focus on these most popular techniques but a mature program should not limit itself to them. All these techniques are used at different stages of the software development lifecycle (SDLC) and help create more secure software every step of the way.

Threat modeling is a process that involves creating data flow diagrams (DFD) which are then systematically reviewed with an eye and mindset for security threats. The security threats that are being searched for in the design fall under the STRIDE model. STRIDE represents the first letters of: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. All of which are ways to circumvent confidentially, integrity and availability of software systems. Threat modeling is an activity that occurs very early in the SDLC and tends to catch significant design issues with the software. These issues are usually the most difficult and expensive ones to fix if found late because they involve re-architecting pieces of a solution.

The second practice is called code analysis. This practice involves using tools (also called code scanners),

Adopting Secure Software If you could tell your customers that you can help them secure their custom built software, significantly reduce the number of bugs and save them money in the process, do you think they would heed to your advice?

Development Processes

http://accretivesolutions.com/

CLOSE-UP


Having a high-level understanding of secure hashing can be quite useful for a security or penetration tester, because it makes it easier

to look for, and discover, these kinds of flaws. The goal of this article is to give a quick introduction to what cryptographic hashing is all about, and some high-profile examples illustrating how things can go wrong in practice.

A Quick Guide to Cryptographic HashingA hash function is, to quote the textbook definition, a computer algorithm that maps a large input data set to short outputs. For our purposes, hash functions take arbitrarily long bitstreams as input, and return short, fixed-length hash values (also referred to as message digests).

A cryptographic hash function is a hash that is supposed to be secure in some way. The terms cryptographic and secure are often used interchangeably, to denote an algorithm that satisfies a number of important security requirements.

Closely related to hash functions are so-called Message Authentication Codes (MACs). Conceptually, a MAC is quite similar to a regular hash function, but takes a symmetric key as an additional input, which is used to provide authenticity for the message. This serves a similar purpose as a digital signature, in

the sense that only someone who knows the secret key should be able to generate or validate correct MAC values corresponding to that key. The functional difference lies in the key management needed, since the same key is used for MAC generation and validation. MAC algorithms can be constructed in a variety of ways, but are commonly made using a hash-function as an underlying building block.

Cryptographic hash functions are surprisingly versatile, and because of this they can be found literally everywhere in security. Consider a simple one-way SSL handshake, occurring every time a new HTTPS connection starts. A secure hash is being used at three different steps in the exchange:

• When the server sends its Certificate message, the client should validate the digital signatures on the certificate chain, using a cryptographic hash at every validation step.

• After the client sends the encrypted ClientKeyExchange message to the server, a master _ secret is computed by both sides using a pseudo-random function (PRF), which is defined using a cryptographic hash internally.

• As the final step of the handshake, the Finished message is exchanged, using both the PRF mentioned above, as well as individual hash functions used as part of the data encoding.

Use and Abuse of Cryptographic HashesSome of the most devastating security flaws appear when there is a logical error in the deployment or use of a security component. Cryptographic hash functions are among the most widely used security algorithms, yet they are often poorly understood by developers and security practitioners alike. The devil is in the details, and when it comes to custom cryptographic mechanisms, it is deceptively simple to make a wrong step.

CLOSE-UP


can be implemented using an idealized model of a hash function (although the end result may not even be practical in theory). Due to this extreme versatility, it is quite hard to give a formal definition of a secure hash that captures all the useful qualities that might be relevant.

On the OWASP wiki, there are several vulnerabilities tagged as cryptographic. Using weak or homegrown algorithms, using the wrong algorithm for a task (e.g. hashing instead of encrypting or vice versa), cryptographic implementation errors, various key management problems and flaws in random number generation, to name a few. Secure hashing can be relevant for all of these scenarios, and the security in each setting may depend on very different properties of the algorithm used.

We will look more closely at three essential usage patterns, that are important to understand from a penetration testing perspective.

Collision ResistancePerhaps the most common application of a secure hash is to provide a short and unique tag that identifies the input data. For instance, this is commonly used to uniquely identify a file, and quickly detect whether it has changed. The hash values of the files are computed when files are initially created, and it is simple to verify whether a local copy is identical to the original file, by hashing and comparing the digests. For any hash function there will exist a huge number of inputs that actually map to the same hash values – however, a key requirement is that it must be impractical to find two such inputs, whether by random chance or through targeted search.

Another important use-case is in digital signatures schemes. All digital signatures are made on the hash value of the original data, rather than the data itself. While there are good technical reasons for doing so, it means that the veracity of the signature depends not only on the security of the public-key algorithm (such as RSA) being used, but also on the security of the hash against collisions. The security requirement illustrated by these examples is generally referred to as collision resistance: it should be infeasible for an attacker to find two hash inputs that hash to the same value.

How can this requirement fail? Since a secure hash is collision-resistant by definition, trouble arises when such functionality has been realized using something else. This can be due to use of an insecure hash (such as MD5), by an incorrect instantiation of an algorithm or a MAC primitive, or by the use of an algorithm that is not intended to provide security, such as an error-

The best known example of a cryptographic hash is probably MD5, which produces a 128-bit output. However, there have been found a number of serious security flaws in MD5. For some applications, MD5 is actively exploitable, and while in other cases there are no known practical attacks, it is generally considered harmful today. As a replacement, the SHA (Secure Hash Algorithm) family of hash algorithms is the preferred choice, usually in the form of SHA-1, which produces 160-bit outputs.

While there are no practical attacks as of yet on systems using SHA-1, researchers have found theoretical cryptographic weaknesses. There are also concerns about the long-term security of any 160-bit algorithm, due to the limited output size. For long-term security, using the SHA-2 algorithm (offering the choice of 224, 256, 384 and 512-bit output modes) may be preferable. Yet another algorithm called SHA-3, offering the same output sizes as SHA-2, but a different internal design, is being standardized by National Institute of Standards and Technology (NIST), with a final standard expected to be published in 2012.

While MACs can be made in several different ways, the most common construction is a hash-based algorithm called HMAC, which uses two invocations of an underlying hash function. Another common algorithm is CBC-MAC, which uses a block cipher in cipher block chaining (CBC) mode as its basic building block.

Use-Cases and Security RequirementsSo, what precisely are secure hash functions used for? In theory, just about any cryptographic functionality

Figure 1. HMAC Algorithm

CLOSE-UP


correcting code. If the security of a system assumes that a collision-resistant hash is used at a certain point, it may be possible to mount an attack if the assumption fails.

One-WaynessAnother common requirement is that a secure hash should work as a one-way function. In other words, it shouldn’t be possible to learn anything about an input to a hash function, based on the output alone. A very common situation where this requirement is needed is password hashing. Given a strong password or passphrase, a secure hash function, and proper use of salt, it should not be possible to recover passwords from a stored list of password hashes.

One well-known case where one-wayness failed for passwords was with the original LanMan hash used for network authentication by early versions of Microsoft Windows (prior to Windows NT). Another common error is to forget the salt, which makes it simple to crack most short passwords by simply looking up the hashes in a precomputed table. Unsalted MD5, in particular, is still quite common in the field, despite the additional risks it creates when there is a leak. In practice, of course, weak passwords (and password recovery schemes) are also a major source of vulnerabilities, even when the hash algorithms are used properly.

Another area where one-wayness is essential is in MAC algorithms. Recall that a MAC uses a shared secret key to produce a MAC value, which is used to prove that the accompanying message is authentic and has not been modified. If a MAC is not one-way with respect to the secret key, an attacker can recover the key and use it to forge MACs on arbitrary messages.

RandomnessA third application of cryptographic hashes is simply to produce random-looking output. In the SSL handshake example, a pseudo-random function based on MD5 and SHA-1 is used to compute a shared master_secret in the ClientKeyExchange step, and to derive further session keys based on that value. More generally, cryptographic session keys are commonly produced by hashing some initial session data, such as a shared random seed, time stamps, and possibly other shared information. While this initial information will tend to contain non-random patterns, there must not be any detectable patterns or statistical biases present in the session key.

For this to work, it is vital that the resulting key does in fact appear truly random. This can typically fail in two ways. One is that the system may have been built using something insecure instead of a secure hash, producing an output that is statistically biased in some way. The

other occurs when the inputs to the hash are guessable in some way – whether caused by a weak password, a poor random seed, or simply poor protocol design.

Real-World Security FailuresIn the remainder of this article, we will look more closely at three well-publicised security flaws involving the use of secure hashing. In all three cases, correct use of a secure hash or MAC in the proper context would most likely have prevented the vulnerability.

These examples are hardly exhaustive. However, they illustrate a few of the myriad ways in which security can fail – whether due to the lack of a logical security mechanism, implementation error, or use of an insecure hash – as well as in highly different applications.

As a penetration tester, looking at the use of hashing (as well as the handling of randomness) in any custom security component can often be a fruitful approach. Moreover, the same goes for logical safeguards – to see if the proper integrity mechanisms are applied where they should be.

Case Study: Stuxnet Task Scheduler ExploitThe Stuxnet worm made a major splash when it first became known to the public in the summer of 2010. While the feature that first caught attention of the security community was probably the fact that its device drivers were signed with a stolen code-signing certificate from a hardware vendor, it gained world-wide notoriety when its scale, sophistication, and role as a targeted attack on the Iranian nuclear program became apparent.

Stuxnet contained no less than four zero-day exploits for various versions of Windows, which it used to ensure that it would be able to escalate its privileges and spread on a variety of different OS versions and configurations. The exploits were all chosen to succeed with high probability, and without making the host system unstable. Three of the attacks relied on logical flaws, whereas only one of them used a buffer overflow. In our case, we shall have a closer look at the Task Scheduler vulnerability (CVE-2010-3888 / MS10-092), which was used to obtain LocalSystem privilege on Windows Vista, Windows 7, and Windows Server 2008 systems.

In short, the Windows task scheduler is used to execute regular tasks by the OS. For Windows Vista and above, the scheduler uses an XML file, which is read- and writable from userland. The XML file contains the list of tasks to be executed, and which user privilege to execute under. To prevent tampering, the file is hashed before execution, with the hash value being compared with one stored in the system registry.

CLOSE-UP


However, as Microsoft’s internal investigation showed, instead of using a proper hash function, the Windows task scheduler used an error-detecting code, CRC-32. While CRC-32 is a reasonable precaution to use to detect random transmission noise, and is used among other places by Ethernet and SATA, it offers no cryptographic security, and it is trivial to compute intentional collisions by only slight alterations to the source file.

This is precisely what Stuxnet does: it computes the CRC-32 value of the existing task scheduler list, appends a task to be executed with system privileges, makes the necessary adjustments to the file to maintain the same CRC-32 value as before, and waits for the task scheduler to fire. The fix that Microsoft used to plug this hole is even simpler: Use SHA-2 to verify the file integrity instead of CRC-32.

Case Study: Xbox Security HolesThe original Xbox console was released by Microsoft in 2001, and for a variety of reasons quickly became a popular target for modding and customization, as well as piracy. Microsoft took several steps to lock down the Xbox platform and disallow execution of unsigned code. However, in 2001 the state of the art for secure computing was still quite primitive, with few known successes in locking down a consumer platform in this way. In hindsight, it is perhaps not unsurprising that enterprising hackers were able to find a number of interesting flaws in the security architecture and design of the Xbox. The same, after all, has happened to many other consumer products, such as the iPhone. Of particular interest to us are two mistakes that were made in the Xbox design regarding the use of secure hashing.

In brief, to maintain the integrity of the secure platform, the Xbox needed to boot automatically into a secure state. It does this by performing the initial boot from a very small and secret embedded ROM on the motherboard, which is used to decrypt verify the integrity of a second bootloader in flash memory, which is again used to verify and boot the Windows kernel. The kernel will then enforce relevant security properties, as to prevent users from running unsigned code or unauthorized media. For the system to remain secure, this entire chain of trust has to remain unbroken.

To verify the second bootloader, the ROM reuses its encryption algorithm as a rudimentary hash, in order to get as compact an implementation as possible. The initial ROM is thus supposed to decrypt the bootloader and hash value from flash memory under its secret key, then compute the hash of the bootloader and verify that it matches the stored value.

While this may sound slightly dodgy, the concept is still reasonably sound, as there are chaining modes that can be used to turn a secure block cipher into a secure (albeit rudimentary) hash function, under certain extra conditions. The encryption algorithm used during development was RC5, which would have been a sound choice. However, for unclear reasons (possibly lack of space in the ROM), the original Xbox that shipped in 2001 used the RC4 encryption algorithm instead.

As it turns out, the RC4 algorithm is not a block cipher, and thus it cannot be used to create a secure hash in this way. When this was discovered, the hacking community quickly found that it was quite straightforward to patch the second bootloader, ignoring the RC4-based hash altogether, and still break the chain of trust to boot into an insecure state.

A new version of the Xbox was later released by Microsoft to fix this flaw. The updated version had a new secret ROM image, which replaced RC4 with the Tiny Encryption Algorithm (TEA). As the name suggests, TEA is an extremely compact algorithm, and thus it was straightforward to fit it in the limited space available in the ROM. As TEA is a block encryption algorithm, it was assumed to solve the problem caused by RC4.

However, TEA has a cryptographic flaw of its own, namely that all of its keys occur in 4 equivalent forms. While this is not much of a problem when used for encryption (it speeds up brute-force attacks by a factor 4, which is fairly insignificant), it proves fatal when using it as a hash. After the use of TEA was discovered by hackers through reverse-engineering, they once again found ways to patch the second bootloader, and take control over the boot process from there.

This pair of related flaws clearly illustrate how security can fail as part of a complex and non-standard security system. While the design of the boot process was clearly dictated by technical requirements (such as the limited size of the secret ROM), the end result proved insecure, partly due to unfortunate choices of algorithms.

Case Study: MD5 AttacksThe MD5 algorithm was invented by Ronald Rivest in 1991, and for the next 15 years it was easily the most widely used cryptographic hash function. While there was made some theoretical progress in attacking it during the 1990s, it remained unbroken until 2004, when the first collisions were found in a groundbreaking effort by a Chinese team of researchers, led by Wang Xiaoyun.

While the colliding inputs themselves were random and meaningless, it is possible to use random collisions to create attack more meaningful data formats, such as postscript and PDF. Notably, a colliding pair of X.509

CLOSE-UP

Page 24 http://pentestmag.com02/2012 (10) February 02/2012 (10) February

certificates was created in early 2005, although the collision was purely located in the random data making up the RSA public key embedded in the certificate. As the weaknesses of MD5 became apparent throughout 2004 and 2005, we saw a gradual shift away from MD5 in most security-critical applications. Yet, due to the widespread deployment and usage of the algorithm in numerous standards, migration took time. Meanwhile, attack techniques kept on quietly improving.

In December 2008, an international team of researchers demonstrated how they had been able to create a rogue intermediate X.509 certificate authority certificate. The certificate had been created with an expiration date set to the past, to prevent abuse, but by adjusting one’s system clock it was easily demonstrated that it would have been considered valid by all major browsers. Such a certificate would have any number of nefarious uses, since the CA-flag meant it could have been used to issue fraudulent site certificates for any site.

The attack had been carried out using the fact that there were still a few root CAs that would issue new certificates using MD5. Since the CA’s signature is computed on the MD5 hash of the certificate, the challenge became to produce a certificate collision where one of the certificates looked innocent, and the other evil. To perform the attack, the researchers created a regular certificate on a very particular format, guessed the parameters that were not under their control, and got it issued and signed by the commercial certificate authority. Meanwhile, a large cluster of Playstation 3 consoles were used to compute the colliding certificate.

As the two resulting certificates had the same MD5 hash value, it was a simple matter to copy the (valid) CA signature from the real certificate, to the rogue certificate. At the time the research was made public, there were 6 public CAs that were still issuing MD5-signed certificates, and all support for MD5 was quickly discontinued after the attack was announced. However, in the period between the first theoretical proofs of concept in 2005, and the highly practical demonstration carried out in 2008, it is impossible to tell whether anyone else carried out something similar.

The gradual improvement in the area of MD5 attacks, demonstrates the maxim that attacks never get worse. It also illustrates the need to review security choices regularly, and the importance of having a timely upgrade path for security. Most of all, though, the series of attacks on MD5 show the sheer power of hash function collisions. The techniques used to obtain random collisions in 2004, while useful enough, led directly to the point where it was possible 4 years later, in the words of the authors, to attack a critical piece of Internet infrastructure.

Some Things to Look For When Penetration TestingOne might well ask how the above case studies apply to one’s daily tasks as a penetration tester. Indeed, they do not have much directly in common with each other, demonstrating instead some of the different ways that security may fail.

When looking for logical flaws in the use of hash functions, there is indeed no simple recipe to determine whether there exists a bug. Yet there are several common patterns that may indicate that something is amiss with a cryptographic solution. Some of these patterns may only be apparent in a white-box scenario, while others can show up under reverse-engineering or even by interacting with a system in a completely black box manner.

Understanding how hash functions are used, and their security properties, can be a powerful tool to analyze such situations. While it is hard to give an exhaustive list of patterns that smell trouble, the following list gives some examples of hash-related issues that the author would try to explore in a test.

• Is the security system custom, or does it use common libraries and protocols? If a system is using SSL, it is pretty easy to test for common SSL mistakes. A custom component may be harder to test, but the chance of finding something really wrong may be greater.

• Is the security functionality simple or complex? High functional complexity often means trouble, particularly in custom components.

Further reading• A four day dive into Stuxnet’s heart: http://www.wired.com/threatlevel/2010/12/a-four-day-dive-into-stuxnets-heart/• W32.Stuxnet Dossier: http://www.symantec.com/connect/blogs/w32stuxnet-dossier• 17 mistakes Microsoft made in the Xbox security system: http://events.ccc.de/congress/2005/fahrplan/attachments/591-paper_

xbox.pdf• MD5 considered harmful today: http://www.win.tue.nl/hashclash/rogue-ca/• The story of Alice and her boss: http://th.informatik.uni-mannheim.de/people/lucks/HashCollisions/rump_ec05.pdf• Cryptographic hash algorithm competition: http://csrc.nist.gov/groups/ST/hash/sha-3/index.html

http://www.wired.com/threatlevel/2010/12/a-four-day-dive-into-stuxnets-heart/

http://www.symantec.com/connect/blogs/w32stuxnet-dossier

http://events.ccc.de/congress/2005/fahrplan/attachments/591-paper_xbox.pdf

http://events.ccc.de/congress/2005/fahrplan/attachments/591-paper_xbox.pdf

http://www.win.tue.nl/hashclash/rogue-ca/

http://th.informatik.uni-mannheim.de/people/lucks/HashCollisions/rump_ec05.pdf

http://csrc.nist.gov/groups/ST/hash/sha-3/index.html

CLOSE-UP

Page 24 http://pentestmag.com02/2012 (10) February 02/2012 (10) February

• Is it possible to tell which algorithms are being used? Are they sufficiently secure, given the intended lifetime of the system? Use of an old or insecure algorithm is a classic error.

• Does the choice of algorithms make sense in context? Is the system using an encryption algorithm instead of a hash? Is it hashing instead of encrypting, or using an error correcting code such as CRC32 when it needs tamper resistance?

• Does the system encrypt, but leave out integrity checking (whether by hashing, MACing or digital signatures)? Encryption-only systems will often permit interactive attacks.

• Does the output of random functions really appear random when you vary the inputs? Do the inputs contain sufficient randomness, or can they be guessed by brute force? In the former case, it is not using a good hash. In the latter case, the hash may be irrelevant.

• Have the security assumptions and threat model been analyzed recently, or are they old and potentially out of date?

ConclusionAlthough several of these points apply squarely to other vulnerabilities as well, the ubiquity of systems that depend on secure hashing, as well as the relative obscurity of the topic, makes hash functions a surprisingly fertile area for exploitation in the wild. One may hope that the dust will gradually settle in the wake of SHA-3’s standardization, and that the next few years will prove less cryptographically eventful than the last eight. Yet, even with SHA-2 and SHA-3 established as (hopefully) secure default algorithm choices, there will be plenty of other things that can and will go wrong.

TOR E. BJØRSTADTor E. Bjørstad ([email protected]) is a researcher and computer security consultant at Accenture, based in Oslo, Norway. He holds a Ph.D. degree in computer science from the University of Bergen, having worked there as a researcher between 2006 and 2010. Tor has worked extensively on a variety of security topics, among them cryptanalysis, security architecture, penetration testing, and security testing methodology. A central theme of Tor’s research has been in-depth security analysis of cryptographic algorithms and protocols, among them a number of experimental stream ciphers and hash functions proposals.

mailto:[email protected]

BASICS


We tend to forget that passwords are used to verify the identity of a person trying to access something. Be it for any of the aforementioned

reasons, passwords are applied to ensure that the person trying to gain access, is the person he, or she, claims to be and is allowed to use the stored data.

As users, we often underestimate the power of passwords and think too little of the potential consequences of their breach. It may seem, that not much would really happen if someone managed to access our account on some discussion board. Because what can the person possibly do? At worst s/he will offend some of our friends, nothing a few explanatory e-mails cannot repair. The truth is, however, that what we at first consider a mere nuisance, may turn into a disaster. We often forget how many details about ourselves we leave behind in places such as forums. In a very short time, skilled hackers can obtain a lot of information about us.

The worst thing is, one such a breach may lead to another. Unfortunately, when it comes to passwords we are not very creative. We often use a very limited number of them. Also, for various websites we use their different variants. Sometimes we add a number (usually 1,2 or 0), an exclamation, or a question mark, or change a lower-case letter into an upper-case letter one. But this is usually not enough. This is why it is important to know how to create a safe password. But before we will

be able to do it, first, we must understand how they work and how they are cracked.

How Passwords WorkPasswords are segments of signs of at least one symbol. These might be digits, like PIN codes, letters and other characters we are able to type on a keyboard. We can easily estimate how many combinations can be created. To do so, we take the number of symbols that can be used to create a password, let us say we use only 5 digits (1-5 symbols), and try to estimate how many four-digit combinations can be made. This is how we do it:

• We need to establish entropy value of each symbol in bits. It expresses the variable within a password. The assumption here is that all symbols are generated at random and follow one another without any pattern. To establish entropy, we must find out to which power number 2 must be raised (as we are using the binary system) to give us 5 (the number of symbols from which we can choose elements of our password): 2√5 = 2.24 bits.

• we multiply the number of symbols of which our password consists by their entropy value in bits: 4*2.24 bits = 8.96 bits

• We raise number 2 to the power we from the previous equation: 28.96 = 498 passwords.

Choosing a Safe PasswordPasswords have become a part of our computer lives to a point, where we no longer pay any special attention to using them. Everyday, we use one to log on a computer, access a social network account or a discussion board, check e-mails and pay bills. All this in the comfort of our houses.

BASICS


They see the advantages of virtualization, and do not realize the complexity of the virtual environment. The statistics show that

vulnerability disclosures in this matter have grown, as interest in virtualization has grown.

Essentially virtual machines are not more susceptible to attacks than physical systems. In the virtual environment, there are common security threats, but virtualization adds a new layer, which also requires protection. In essence, you now have to worry about two layers: the virtual machine and the physical machine on which it runs. And when you have multiple virtual machines running on a hypervisor (also called VMM – Virtual Machine Monitor), a failing of the hypervisor could compromise all virtual machines. Moreover, the consequences of security breaches in virtualization solutions are much more serious, because it gives access many resources. It is therefore a very attractive target for attackers. It is necessary to expand outside the host computer. We have to take into account the many possibilities of attacks that appear in the security context of the virtual environment. Vulnerabilities can be classified by what they affect. Essentially, there is the host hardware, host operating system, hard disk files of virtual machines, virtual machine configuration files, remote management tools, operating system, virtual machine and of course virtual network, in which it all works.

HyperjackingThe main concern is the hypervisor, the software controlling the operation of virtual machines. Breaking the security allows hackers to perform a successful attack (hyperjacking) and get access to all virtual machines running on a physical server. A rootkit infecting the supervisor is a real nightmare for administrators. Until 2006 most rootkits were detectable by programs to defend against this type of threat, then the rootkit boom began to wane. Naturally, this led the researchers to test new techniques that would be undetectable. Most researchers focused on the concept of the use of hardware virtualization to take control of the operating system. This method allows you to create rootkits that cannot be detected by modern tools to scan for this type of risk. In 2006 there were two published proof-of-concept rootkits: Blue Pill and Sub Virt. The first one was presented by security researcher from Poland – Joanna Rutkowska, at the Black Hat Briefings in Singapore.

Anyone who have seen the movie Matrix, remembers the first conversation between Morpheus and Neo about blue pill. The blue pill washes away all desire to know the truth and would have allowed Neo (Keanu Reeves) living inside the virtual world. The red pill was the antidote to wake someone up from the Matrix and escape slavery. The idea of rootkit developed by Joanna Rutkowska is the same: Our operating system

Virtualization: Pills and Other ThreatsVirtualization in addition to many advantages also raises security issues. Virtual environment are very different from physical; it requires a different approach to security matters. Administrators often are not aware of safety issues specific to virtual environments or realize the dangers after deployment.

www.p2sol.com securityservices @ p2sol dot com

:

Apologies for the above marketing gimmick, but it was necessary tograb your attention. We could tell you that we offer superior informationsecurity services followed by a highly biased list of reasons, quotes ofindustry sources, and facts to support our assertions. However, weboth know that you know that game, so let’s change the rules and letthe truth in our advertisement speak for our work, and maybe you’llgive us the opportunity to let our work speak instead. For the samereasons that clever marketing can sell an inferior product; your entirenetwork can be hacked, starting with one little email. Interested, orshall you skip to the next page?

As a proof in concept, the soft copy version of this document containscustom embedded software control codes designed to gain controlover your computer, then masquerading as you, manipulate stockprices using information contained on your system. Buy buy! Sell Sell!.Sound farfetched? Maybe 5 years ago, but that is today’s newparadigm. Forgive the fear tactics, but the point is that skillful socialmanipulation in conjunction with “embedded software control codes”are the methods used by malicious parties to compromise (gain controlof) modern networks. This challenge can only be met with intelligence.

We combine software engineering, security know how, and dataanalysis to offer real world peer based metrics of your security issuesas well as deep dive technical assessments ranging from penetration /technical assessments to strategic reviews.

Contact:Shohn Trojacek - [email protected] 120 N. MAIN BRYAN, TX 77803Tel 939.393.9081

Security Services

$50,000 Firewall ruined by a lack of cents!

A UDI T S U P P O R TStrategic and Technicalassessments for audit firms,audit, and IT departments:

� Penetration Testing� Security Assessments� Disaster Recovery� Special Projects

PE E R B A SE D E VA LU A TI O N

Ongoing comparison againstpeers of key IT securitymetrics and controls. Periodicreporting of key metrics.

S TA TI S TI C A LPE N E TR A TI O N

Periodic rotation ofprofessional penetrationtesters against your networkvia a custom portal completewith the ability to limit thescope and depth of testingaccording to client needs.

U SE R E D UC A TI O N

Custom security trainingexercises for your organizationincluding use of penetrationtests as a way of providingusers an unforgettableexperience.

S E R V I C E S A V A I L A B L E� $250,000 Intrusion Detection System� $50,000 Redundant Firewalls� $300,000 Salaries for IT Security Personnel� $400,000 Gee Whiz Computer Defense Shield

Hacked because someone used password123 as a “temporary”password…….

Sleep better with our D3tangler™ technology!Our new patent pending D3tangler technology helps you win the evolvinggame of IT security. The technology solves all your security problems bypressing a button! Don’t be fooled by cheap competitor’s products!

http://www.p2sol.com

WEB APP


Sessions are the way of saving the state and user specific variables across subsequent page requests. The session information is stored on

the web server using the session identifier (session ID) generated as a result of the first (sometimes the first authenticated) request from the end user running a web browser The basic Idea behind web session management is that the server generates a session identifier (ID) at some early point in user interaction, sends this ID to the user’s browser and makes sure that this same ID will be sent back by the browser along with

each subsequent request. The session is alive as long as the browser keeps sending the id with every new request. The ability to restrict and maintain user actions within unique sessions is critical to web security.

There are three widely used methods for maintaining sessions in web environment: URL arguments, hidden form fields and cookies. The best way to maintain session through cookies its most convenient and also the least insecure of the three.

This article reveals a 3 types of attacks against session IDs: Figure 2.

Session log-in-out

Web application is not able to recognize whether this request is somehow related to previous requests or not, Session Management is the technique used by the web developer to make the stateless HTTP protocol support session state.

Figure 1. Session management Figure 2. Three types of attacks against session

WEB APP


In practice layter 2 attack is very difficult to execute from outside network, local attackers, distinguished employees and social engineering must be consider

when we speak about risks in layer 2 attacks, and they are common starting point for layer 2 attacks

In modern corporate network designs ips/ids systems are not in place in internal networks which are considered as secure, that fact make layer 2 attacks and vulnerabilities more attractive for attacker.

Usually attackers use several attack type on layer 2 Macspoofing (ARP attack), VLAN hopping, Mac flooding, DHCP attacks, Spanning Tree Protocol (STP) manipulation of HSRP MiTM attack.

VLAN “Hopping”VLAN’s are used to simplify network segmentation and maintenance and improve performance. Each VLAN consists of a single broadcast domain. VLANs work by tagging packets with an identification header. Ports on switch are restricted to receiving only packets that are part of the VLAN. Trunk ports have access to all VLANs by default. They route traffic for multiple VLANs across the same physical link. VLAN hopping is type of network attack where attacker change VLAN ID with motivation to deliver packets to destined system on a different VLAN which normally cannot be reached. We can identify two types of attacks in Switch spoofing and Double tagging.

How Is Second Becoming First?Very often IT personnel in attempt to protect their application forget to secure layer 2, relay to much on antivirus and firewall solution. Main problem is that when layer 2 is compromised upper layer are not aware of problem so every upper layer protection is useless.

Figure 1. Double tagging

http://www.certping.com/

INTERVIEW

Page 48 http://pentestmag.com02/2012 (10) February

Raymond Friedman is the CEO and President of mile2 and has been in the IT Security Space since 2002. While in this industry, he has been actively engaged in consulting for global financial and government institutions; performing security audits, penetration tests and digital forensics services. During his tenure at mile2, Raymond has spearheaded the development of the present series of mile2 certifications which have become globally recognized by Militaries worldwide. Presently, Raymond carries several certifications and advanced degrees such as the Master of Science in Accounting – Forensics & Controllership, the Certified Information Systems Security Officer, Certified Penetration Testing Engineer and Certified Digital Forensics Examiner.

When was Mile2 founded and what is your philosophy? Mile2 was developed in response to the threat of corporate and national information security attacks in the aftermath of 9/11. Our philosophy is to provide an excellent and effective education, certification and consulting to individuals and organizations that will provide the answers to their security challenges. We pride ourselves in delivering a high quality program that is unmatched in the information security arena, combining theoretical and practical education with extensive labs that give each student the opportunity to understand and apply their knowledge and have the skills needed to provide exceptional value to their clients, employers and nation.

Please tell us about your professional experience in Information Security. I have been in the IT Security Space since 2002. During that time, I have actively been engaged in consulting, instructing, developing material and as well as new pen testing methodologies.

Can you tell us some of Mile2’s accomplishments since its inception?Since mile2’s inception, we have become the de facto standard for education and certification for organizations and militaries worldwide. We have accomplished this feat by developing a series of high level security certifications

that focus on industry standards and leading technical policies. In addition to this, mile2 is in the process of developing the most cutting edge distro (presently called Ghost), which should surpass Backtrack inadequacies. The distro is lighter, more effective, robust and will have instructional videos, as well as, labs to help aid the student perform some complex penetration testing functions. Ghost is unique because it’s a powerful tactical tool that focuses strictly on educational purposes as opposed to blackhat methodologies which tend to bring down what we are trying to bring up in a secure fashion. Ghost is currently in Beta form and should be out in the market space in Q2 as an open project.

Tell us more about the instructors at Mile2 and some of the courses offered.Mile2 instructors are highly experienced consultants and globally recognized authors such as Kevin Henry and James Michael Stewart who were converted to instructional services. They understand what it means to be in the field and are not simply academics.

What are some of the mile2 certifications that are in high demand what are the major differences between the certifications verses those in the market space? Our highest Demand is our flagship certifications that include the following:

Interview with

Raymond Friedman

https://pen-testing.sans.org/contest/feb-2012

In the Upcoming Issue of

If you would like to contact PenTest team, just send an email to [email protected] or [email protected]. We will reply a.s.a.p.PenTest Magazine has a rights to change the content of the next Magazine Edition.

Cross Frame Scripting

Available to download on March 1st

http://pwnieexpress.com/

��

��

��

��

��

��

��

��

��

ABOUT MILE2

��

��

ABOUT BOSON SOFTWARE, LLC

��

��

http://www.mile2.com

Documents

PenTest Regular 10/2012