First, some background on CREST in the form of blatant plagiarism...

CREST — The Council for Registered Ethical Security Testers - exists to serve the needs of a global information security marketplace that increasingly requires the services of a regulated and professional security testing capability. They provide globally recognised, up to date certifications for organisations and individuals providing penetration testing services.

For organisations, CREST provides a provable validation of security testing methodologies and practices, aiding with client engagement and procurement processes, and proving that your company is committed to providing testing services to the highest standard.

For individuals, CREST provides an industry leading qualification and career path for security penetration testers. By gaining a CREST certification you are proving that you are committed to your professional development in security testing.

CREST has been serving the industry as a pivotal player in the Penetration Testing landscape for many years now, and has also recently established a government-approved chapter in Australia.

There have been numerous discussions about CREST in South Africa over the years and we believe now is the time to take the conversation further. Ian Glover - President of CREST - will be in South Africa next week to deliver a presentation at the ITWeb Security Summit in Johannesburg, and this affords interested parties and excellent opportunity to discuss the concept with him.

With the support of ITWeb we're setting up a workshop to be held at the Sandton Convention Center from 10h00 to 12h00 on Thursday 17 May to meet with Ian, understand the process, and discuss a possible path forward.

Interested parties, whether from testing companies or clients, should please RSVP by commenting on this post (we'll keep it private) or mailing us via info <at> sensepost <dot> com.

Be part of the discussion. We look forward to hearing from you!

There has been a healthy reaction to our initial post on our research into the RSA SecureID Software Token. A number of readers had questions about certain aspects of the research, and I thought I'd clear up a number of concerns that people have.

The research pointed out two findings; the first of which is in fact a design vulnerability in RSA software's "Token Binding" mechanism. The second finding is another design issue that affects not only RSA software token but also any other software, which generates pseudo-random numbers from a "secret seed" running on traditional computing devices such as laptops, tablets or mobile phones. The correct way of performing this has been approached with hardware tokens, which are often tamper-resistant.

Let me first explain one of the usual use cases of RSA software token deployments:

1. The user applies for a token via a RSA self-service console or a custom web form
2. The user receives an email which contains the "software token download URL", once the software is installed, they should open the program and then choose Token Storage Devices where they would read the "Device Serial Number" and reply back with this device serial number to complete their token request.
3. The second email will contain an attachment of the user's personal RSA SecurID Token Configuration file, which they will import to the RSA software token. This configuration file is bound to the users' laptop or PC.
4. The third email contains an initial password to activate the token.

An attacker who is able to capture the victim's configuration file and initial password (The security of this initial password is subject to future research at SensePost and will be released in the future) would be able to import it into his token using the described method to bypass the token binding. This attack can be launched remotely and does not require a "fully compromised machine" as RSA have stated.

The second finding, as I mentioned before, is a known issue with all software tokens. Our aim at SensePost was to demonstrate how easy/hard it would be for an attacker, who has already compromised a system, to extract RSA token secrets and clone them on another machine. A number of people commented on the fact that we did not disclose the steps required to update the LSA secrets on the cloned system. Whilst this technique is relatively easy to do, it is not required for this attack to function.

If a piece of malware was written for this attack, it does NOT have to grab the DPAPI blobs and replicate them on the attackers machine. It can simply hook into the CryptUnprotectData and steal the decrypted blobs once the RSA software token starts execution. The sole reason I included the steps to replicate the DPAPI on another machine, was that this research was performed during a real world assessment, which was time-limited. We chose to demonstrate the attack to the client by replicating the DPAPI blobs instead of developing a proof of concept malcode.

A real-world malware targeting RSA software tokens would choose the API hooking method or a similar approach to grab the decrypted seed and post it back to the attacker.

"I'm also curious to know whether software token running on smartphones might be vulnerable."

The "Token Binding" bypass attack would be successful on these devices, but with a different device serial ID calculation formula. However, the application sandboxing model deployed on most modern smartphone operating systems, would make it more difficult for a malicious application, deployed on the device, to extract the software token's secret seeds. Obviously, if an attacker has physical access to a device for a short time, they would be able to extract those secrets. This is in contrast to tamper-proof hardware tokens or smart cards, which by design provide a very good level of protection, even if they are in the hands of an attacker for a long time.

"Are the shortcomings you document particular to RSA or applicable to probably applicable to Windows software tokens from rival vendors too?"

All software tokens found to be executing a pseudo-random number generation algorithm that is based on a "secret value", are vulnerable to this type of cloning attack, not because of algorithms vulnerabilities, but simply because the software is running on an operating system and storage that is not designed to be tamper-resistance like modern smart cards, TPM chips and secure memory cards.

One solution for this might be implementing a "trusted execution" environment into CPUs, which has been done before for desktop and laptops by Intel (Intel TXT) and AMD. ARM's "trustzone" technology is a similar implementation, which targets mobile phone devices and secures mobile software's from logical and a range of physical attacks.

Widespread use of smart phones by employees to perform work related activities has introduced the idea of using these devices as an authentication token. As an example of such attempts, RSA SecureID software tokens are available for iPhone, Nokia and the Windows platforms. Obviously, mobile phones would not be able to provide the level of tamper-resistance that hardware tokens would, but I was interested to know how easy/hard it could be for a potential attacker to clone RSA SecureID software tokens. I used the Windows version of the RSA SecurID Software Token for Microsoft Windows version 4.10 for my analysis and discovered the following issues:

Device serial number of tokens can be calculated by a remote attacker :

Every instance of the installed SecurID software token application contains a hard drive plug-in (implemented in tokenstoreplugin.dll) that has a unique device serial number. This serial number can be used for "Device Binding" and the RSA documentation defines it as follows:

“Before the software token is issued by RSA Authentication Manager, an additional extension attribute (<DeviceSerialNumber/>) can be added to the software token record to bind the software token to a specific devicedevice serial number is used to bind a token to a specific device. If the same user installs the application on a different computer, the user cannot import software tokens into the application because the hard drive plug-in on the second computer has a different device serial number from the one to which the user's tokens are bound”.

Reverse engineering the Hard-Disk plugin (tokenstoreplugin.dll) indicated that the device serial number is dependent on the system's host name and current user's windows security identifier (SID). An attacker, with access to these values, can easily calculate the target token's device serial number and bypass the above mentioned protection. Account SIDs can be enumerated in most of the Microsoft active directory based networks using publicly available tools, if the “enumeration of SAM accounts and shares” security setting was not set to disabled. Host names can be easily resolved using internal DNS or Microsoft RPC. The following figures show the device serial number generation code:

The SecureID device serial number calculation can be represented with the following formula:

device_serial_number=Left(SHA1(host_name+user_SID+“RSA Copyright 2008”),10)

Token's copy protection:

The software token information, including the secret seed value, is stored in a SQLite version 3 database file named RSASecurIDStorage under the “%USERPROFILE%\Local Settings\Application Data\RSA\RSA SecurID Software Token Library” directory. This file can be viewed by any SQLite database browser, but sensitive information such as the checksum and seed values are encrypted. RSA documentation states that this database file is both encrypted and copy protected: “RSA SecurID Software Token for Windows uses the following data protection mechanisms to tie the token database to a specific computer:

• Binding the database to the computer's primary hard disk drive

• Implementing the Windows Data Protection API (DPAPI)

These mechanisms ensure that an intruder cannot move the token database to another computer and access the tokens. Even if you disable copy protection, the database is still protected by DPAPI.”

The RSASecurIDStorage database file has two tables: PROPERTIES and TOKENS. The DatabaseKey and CryptoChecksum rows found in the PROPERTIES tables were found to be used for copy protection purpose as shown in the figure below:

Reverse engineering of the copy protection mechanism indicated that:

• The CryptoChecksum value is encrypted using the machine's master key, which can only be decrypted on the same computer system, unless the attacker can find a way to import the machine key and other supporting data to their machine
• The DatabaseKey is encrypted using the current logged-on user's master key and provides token binding to that user account

Previous research on the Microsoft Windows DPAPI internals has made offline decryption of the DPAPI protected data possible. This means that if the attacker was able to copy the RSA token database file along with the encryption master keys to their system (for instance by infecting a victim's machine with a rootkit), then it would be possible to decrypt the token database file on their machine. The detailed attack steps to clone a SecurID software token by copying the token database file from a victim's system are as follows:

1. Copy the token database file, RSASecurIDStorage, from the user profile directory
2. Copy the user's master key from %PROFILEDIR%\Application Data\Microsoft\Protect\%SID%; the current master key's GUID can be read from Preferred file as shown in the figure below:

3. Copy the machine's master key from the %WINDIR%\system32\Microsoft\Protect\ directory. Microsoft Windows protects machine keys against tampering by using SHA1 hash values, which are stored and handled by the Local Security Authority Subsystem Service (LSASS) process in Microsoft Windows operating systems. The attacker should also dump these hash values from LSA using publicly available tools like lsadump.


4. Having all the required master keys and token database file, install and deploy a windows machine and change the machine and user SIDs to the victim's system SID by using available tools such as newSID.
5. Overwrite the token database file, user and machine master keys with the ones copied from victim's system. You would also need to find a way to update the DPAPI_SYSTEM value in LSA secrets of the Windows machine. Currently, this is the only challenge that I was not able to solve , but it should be possible to write a tool similar to lsadump which updates LSA secrets.
6. When the above has been performed, you should have successfully cloned the victim's software token and if they run the SecurID software token program on your computer, it will generate the exact same random numbers that are displayed on the victim's token.

In order to demonstrate the possibility of the above mentioned attack, I installed and activated token A and token B on two separate windows XP virtual machines and attempted to clone token B on the virtual machine that was running token A. Taking the above steps, token B was successfully cloned on the machine running token A as shown in the following figures:

In order to counter the aforementioned issues, I would recommend the use of "trusted platform module" (TPM) bindings, which associates the software token with the TPM chip on the system (TPM chip for mobiles? there are vendors working on it).

As 44Con 2012 starts to gain momentum (we'll be there again this time around) I was perusing some of the talks from last year's event...

It was a great event with some great presentations, including (if I may say) our own Ian deVilliers' *Security Application Proxy Pwnage*. Another presentation that caught my attention was Haroon Meer's *Penetration Testing considered harmful today*. In this presentation Haroon outlines concerns he has with Penetration Testing and suggests some changes that could be made to the way we test in order to improve the results we get. As you may know a core part of SensePost's business, and my career for almost 13 years, has been security testing, and so I followed this talk quite closely. The raises some interesting ideas and I felt I'd like to comment on some of the points he was making.

As I understood it, the talk's hypothesis could be (over) simplified as follows:

1. Despite all efforts the security problem is growing and we're heading towards a 'security apocalypse';
2. Penetration Testing has been presented as a solution to this problem;
3. Penetration Testing doesn't seem to be working - we're still just one 0-day away from being owned - even for our most valuable assets;
4. One of the reasons for this is that we don't cater for the 0-day, which is a game-changer. 0-day is sometimes overemphasized, but mostly it's underemphasized, making the value of the test spurious at best;
5. There are some ways in which this can be improved, including the use '0-day cards', which allow the tester to emulate the use of a 0-day on a specific system without needing to actually have one. Think of this like a joker in a game of cards.

To begin with, let's consider the term "Penetration Testing", which sits at the core of the hypotheses. This term is widely used to express a number of security testing methodologies and could also be referred to as "attack & penetration", "ethical hacking", "vulnerability testing" or "vulnerability assessment". At SensePost we use the latter term, and the methodology it expresses includes a number of phases of which 'penetration testing' - the attempt to actually leverage the vulnerabilities discovered and practically demonstrate their potential impact to the business - is only one. The talk did not specify which specific definition of Penetration Test he was using. However, given the emphasis later in the talk about the significance of the 0-day and 'owning' things, I'm assuming he was using the most narrow, technical form of the term. It would seem to me that this already impacts much of his assertion: There are cases of course where a customer wants us simply to 'own' something, or somethings, but most often Penetration Testing is performed within the context of some broader assessment within which many of Haroon's concerns may already be being addressed. As the talk pointed out, there are instances where the question is asked "can we breached?", or "can we be breached without detecting it?". In such cases a raw "attack and penetration" test can be exactly what's needed; indeed it's a model that's been used by the military for decades. However for the most part penetration testing should only be used as a specific phase in an assessment and to achieve a specific purpose. I believe many services companies, including our own, have already evolved to the point where this is the case.

Next, I'd like to consider the assertion that penetration testing or even security assessment is presented as the "solution" to the security problem. While it's true that many companies do employ regular testing, amongst our customers it's most often used as a part of a broader strategy, to achieve a specific purpose. Security Assessment is about learning. Through regular testing, the tester, the assessment team and the customer incrementally understand threats and defenses better. Assumptions and assertions are tested and impacts are demonstrated. To me the talk's point is like saying that cholesterol testing is being presented as a solution to heart attacks. This seems untrue. Medical testing for a specific condition helps us gauge the likelihood of someone falling victim to a disease. Having understood this, we can apply treatments, change behavior or accept the odds and carry on. Where we have made changes, further testing helps us gauge whether those changes were successful or not. In the same way, security testing delivers a data point that can be used as part of a general security management process. I don't believe many people are presenting testing as the 'solution' to the security problem.

It is fair to say that the entire process within which security testing functions is not having the desired effect; Hence the talk's reference to a "security apocalypse". The failure of security testers to communicate the severity of the situation in language that business can understand surely plays a role here. However, it's not clear to me that the core of this problem lies with the testing component.

A significant, and interesting component of the talk's thesis has to do with the role of "0-day" in security and testing. He rightly points out that even a single 0-day in the hands of an attacker can completely change the result of the test and therefore the situation for the attacker. He suggests in his talk that the testing teams who do have 0-day are inclined to over-emphasise those that they have, whilst those who don't have tend to underemphasize or ignore their impact completely. Reading a bit into what he was saying, you can see the 0-day as a joker in a game of cards. You can play a great game with a great hand but if your opponent has a joker he's going to smoke you every time. In this the assertion is completely true. The talk goes on to suggest that testers should be granted "0-day cards", which they can "play" from time to time to be granted access to a particular system and thereby to illustrate more realistically the impact a 0-day can have. I like this idea very much and I'd like to investigate incorporating it into the penetration testing phase for some of our own assessments.

What I struggle to understand however, is why the talk emphasizes the particular 'joker' over a number of others that seems apparent to me. For example, why not have a "malicious system administrator card", a "spear phishing card", a "backdoor in OTS software" card or a "compromise of upstream provider" card? As the 'compromise' of major UK sites like the Register and the Daily Telegraph illustrate there are many factors that could significantly alter the result of an attack but that would typically fall outside the scope of a traditional penetration test. These are attack vectors that fall within the victim's threat model but are often outside of their reasonable control. Their existence is typically not dealt with during penetration testing, or even assessment, but also cannot be ignored. This doesn't doesn't invalidate penetration testing itself, it simply illustrates that testing is not equal to risk management and that risk management also needs to consider factors beyond the client's direct control.

The solution to this conundrum was touched on in the presentation, albeit very briefly, and it's "Threat Modeling". For the last five years I've been arguing that system- or enterprise-wide Threat Modeling presents us with the ability to deal with all these unknown factors (and more) and perform technical testing in a manner that's both broader and more efficient.

The core of the approach I'm proposing is roughly based on the Microsoft methodology and looks as follows:

1. Develop a model of your target environment, incorporating all players, locations, and interfaces. This is done in close collaboration between the client and the tester, thus incorporating both the 'insider' and the 'outsider' perspective;
2. Enumerate all potential risks, and map them to the model. This results in a very long and comprehensive list of hypothetical risks, which would naturally include the 0-day, but also all the other 'jokers' that we discussed above;
3. Sort the list into some order of priority and group similar hypothetical risks together;
4. Perform tests in order of priority where appropriate to prove or disprove the hypothetical risks;
5. Remediate, mitigate, insure or inform as appropriate;
6. Rinse and repeat.

This approach provides a reasonable balance between solid theoretical risk management and aggressive technical testing that addresses all the concerns raised in the talk about the way penetration testing is done today. It also provides the customer with a concrete register of tested risks that can easily be updated from time-to-time and makes sense to both technical and business leaders.

Threat Modeling makes our testing smarter, broader, more efficient and more relevant and as such is a vital improvement to our risk assessment methodology.

Solving the security problem in total is sadly still going to take a whole lot more work...

This year, for the fourth time, myself and some others here at SensePost have worked together with the team from ITWeb in the planning of their annual Security Summit. A commercial conference is always (I suspect) a delicate balance between the different drivers from business, technology and 'industry', but this year's event is definitely our best effort thus far. ITWeb has more than ever acknowledged the centrality of good, objective content and has worked closely with us as the Technical Committee and their various sponsors to strike the optimal balance. I don't think we have it 100% right yet, and there are some improvements and initiatives that will unfortunately only manifest at next year's event, but this year's program (here and here) is nevertheless first class and comparable with almost anything else I've seen.

Dominic White was interviewed for a short video that sums it all up quite nicely.

<Shameless plug>If you're in South Africa, and you haven't registered, I highly recommend that you do</Shameless plug>

This year's Summit explores the idea that trust in CyberSpace is "broken" and that, one for one, all the pillars we relied on to tame the Internet and make it a safe place to do business in, have failed. Basically the event poses the question: "What now"?

We've tried hard to get all our speakers to align in some way with this theme. Sadly, as is often he case, we had fewer submissions from local experts then we hoped, but we were able to round up a pretty killer program, including an VIP list of visiting stars.

After the plenaries each day, the program is divided into themed tracks where talks on a topic are grouped together. Where possible we've tried to include as many different perspectives and opinions as possible. Here's a brief summary of my personal highlights:

Plenaries:

• Eddie Schwartz - "A State of Dynamic Risk: Containment and Victory in a World of Advanced Threats
• Moxie Marlinspike - "The demise of SSL & Internet Trust"
• Kenneth Geers - "Cyber War - Beyond Theory"
• Charlie Miller - "Banned in the USA"
• Joshua Corman - "Where do we go from here? Adapting to modern adversaries"
• Haroon Meer - "Information Security: The things we dont say…"

Finally, there's excellent looking full-day workshop titled "Security in an era of BYOD" with Dan Crisp and Lynn Terwoerds.

Its gonna be excellent. See you there!