Analyzing Keychain Contents with iOSKeychain Analyzer

By Neelay Shah.

iOS exposes a secure storage "Keychain" which can be used by applications to securely store critical and security sensitive data such as symmetric keys, asymmetric private keys, certificates, username, passwords etc. As part of penetration testing iOS applications it is often necessary to be able to inspect the contents of this keychain to identify what the application is storing in the keychain and how it is potentially using the same. A common example is to use "Keychain" to store the login username and password so that the user is logged in seamlessly when the application is launched. The iOS simulator simulates this "Keychain" as a SQLite database. However, this SQLite database is encrypted and as such opening it does not help much.

iOSKeychain Analyzer extracts and exports the contents of the keychain (on the iOS simulator) along with the associated attributes/properties. The types of keychain items range from passwords, certificates to keys. The attributes for these keychain items include details such as clear text values, accessibility details, description/comments, creation/modification etc. Additionally, the tool also analyzes the iOS simulator keychain contents from a security standpoint.

Download

You can find the Binary here:

• http://www.mcafee.com/us/downloads/free-tools/ios-keychain-analyzer.aspx

and the Source code here:

• https://github.com/Foundstone/ios-keychain-analyzer

Installation / Pre-Requisites

The source code should compile successfully on Mac OS X 10.7.4/Xcode 4.4.1/iOS SDK 5.0. Once compiled, you can run it on an iOS 5.0/5.1 simulator. Though not tested, the code should compile and run fine on a more recent platform/environment than this.

A compiled binary is provided for the iPhone 5.1 Simulator. To use this binary as is - copy the "01EFB1DB-4A47-45A1-B692-F88996FAC4F8" to "/Users//Library/Application Support/iPhone Simulator/5.1/Applications". Then launch iOS Simulator. Set the device to iPhone and version 5.1 and the application should appear installed on the simulator. You can then launch from there.

The data export/report files should open fine in Safari 6.0+, Firefox 17.0+ and Chrome 23.0.1271.101+

Usage

First install and configure the application that you are testing within the iOS simulator. If iOS Keychain Analyzer is not installed within the simulator then install it. See the "Installation / Pre-Requisites" section for instructions on how to install the tool.

Next Launch the iOS Keychain Analyzer, you'll be presented with the following page:

First export the data:

Then analyze it:

It'll create the Library/Caches/DataAndAnalysisReports (e.g. /Users/[Username]/Library/Application Support/iPhone Simulator/5.1/Applications/01EFB1DB-4A47-45A1-B692-F88996FAC4F8/Library/Caches/DataAndAnalysisReports/) folder to store the results.

Within the folder are two reports:

1. iOSKeychainDataViewer.htm - This report displays the entire contents of the keychain in a readable format. The raw keychain contents are stored in JSONP format in the "KeychainDataExport.jsonp" file
   
2. iOSKeychainAnalysisReportViewer.htm - This report displays the keychain data analysis report in a readable format. The raw analysis report can be found in the "KeychainAnalysisReport.jsonp"
   

Analyzing Keychain Contents

iOSKeychain Analyzer runs the following checks:

1. Weak Password Check - All password items that have a length less than 8 characters, or is not alphanumeric or does not contain a special character is flagged
2. Weak Authentication Method Check - All password items that are configured to be used with weak authentication methods such as HTTP Basic and HTTP Digest are flagged
3. Weak Protocol Check - All passwords that are configured to use insecure protocols such as HTTP, FTP etc. are flagged
4. Weak Key Length Check - All symmetric keys with key length less than 128 bits and all asymmetric keys with key length less than 1024 bits are flagged
5. Insecure Accessibility Check - All items that can be accessed insecurely (irrespective of whether the device is locked or not) are flagged

Known Issues

The tool does not export the clear text public key or private key. The reason being the API exposes the opaque public/private key structure but not the actual bytes.

Accurate CVSS Scoring in PCI ASV Scans

By Vijay Agarwal.

Payment Card Industry (PCI) vulnerability scanning involves having an Approved Scanning Vendor (ASV) perform a vulnerability scan as per PCI DSS requirement 11.2 on all IP addresses/devices etc. which store, process or transmit credit card data. The scan aims to identify both network and web application vulnerabilities. The PCI guidelines detail the process in which these scans should be conducted so we won’t go into detail of that. Instead, we’ll discuss how risk is analyzed and rated once the vulnerability is identified.

Risk Ratings

In PCI ASV reports, risks are calculated based on the Common Vulnerability Scoring System (CVSS2) which is the de-facto scoring standard adopted and well accepted throughout the security industry for calculating the security risk.

The basic rule of thumb for calculating the risk is If CVSS2 score is > = 4.0 then that particular vulnerability will result in non-compliance to PCI and the affected device/IP will be marked as FAILED. CVSS2 scores <=3.9 will result in vulnerability as compliant to PCI.

We have mapped the various risk levels and the CVSS2 scores to help you understand how vulnerabilities are rated.

CVSS2 Score	Risk	Compliance Status
<4.0	LOW	PASS
>=4.0 and <=6.9	MEDIUM	FAIL
>=7.0 and <=10	HIGH	FAIL

References:

• http://www.first.org/cvss/cvss-guide
• http://nvd.nist.gov/cvss.cfm?calculator&version=2
• https://www.pcisecuritystandards.org/documents/ASV_Program_Guide_v2.pdf

Now it should be clear from the above table how the vulnerabilities are classified based on CVSS2 score as per PCI ASV Council, but there is lot of calculation, analysis and verification needed to be done, there are various scenarios/cases where we efficiently need to calculate the CVSS2 score based on the scenario.

In the next few sections let’s analyze few scenarios I have come across when conducting the PCI ASV scans.

Case 1 - Self-Signed Certificate

Let’s calculate the CVSS2 score for a vulnerability where scanner has flagged an application using Self-Signed Certificate as medium risk issue, Following are the valid CVSS2 parameter to be used and reflect the score for it and based on which risk will be calculated and PCI compliance status will be analyzed.

Exploitability Metrics

Metric	Value	Justification
Access Vector	Adjacent Network	The system can be accessed from any remote network by any system
Access Complexity	Medium	Requires little skill or additional information gathering
Authentication	None	No authentication is required to exploit this flaw or get access to the authentication environment

Impact Metrics

Metric	Value	Justification
Confidentiality Impact	Partial	There is considerable informational disclosure but attacker has no control
Integrity Impact	Partial	User can alter the traffic or once exploited
Availability Impact	None	No impact to the availability of the system

Risk will be rated as Medium and this vulnerability will result in PCI Compliance status as FAIL

Case 2 - Special Case Self-Signed Certificate

Now let’s assume if there is slight change in the environment of the above same vulnerability and following information was provided by the PCI Scan client. The Affected system has restricted access and not available publicly, access is controlled using IPS/IDS and user IPs is whitelisted. Following will be the change in input parameter while calculating the CVSS2 score under above specified condition.

Exploitability Metrics

Metric	Value	Justification
Access Vector	Adjacent Network	Requires local network access - which accounts for the white-listed IP address
Access Complexity	High	Specialized access conditions exist
Authentication	None	No authentication is required to exploit this flaw or get access to the authentication environment

Impact Metrics

Metric	Value	Justification
Confidentiality Impact	Partial	There is considerable informational disclosure but attacker has no control
Integrity Impact	Partial	User can alter the traffic or once exploited
Availability Impact	None	No impact to the availability of the system

Risk will be rated as Low and this vulnerability will result in PCI Compliance status as PASS. So a slight change in the environment and accessibility has changed the risk for the issue.

Case 3 - Multiple Server Vulnerabilities

Let’s calculate the CVSS2 score for a vulnerability where scanner has flagged a server affected by multiple vulnerabilities which is a High risk issue, Following are the valid CVSS2 parameter to be used and reflect the score for it and based on which risk will be calculated and PCI compliance status will be analyzed.

Exploitability Metrics

Metric	Value	Justification
Access Vector	Network	The system can be accessed from any remote network
Access Complexity	Medium	Requires little skill and information gathering
Authentication	None	No authentication is required to exploit this flaw or get access to the authentication environment

Impact Metrics

Metric	Value	Justification
Confidentiality Impact	Partial	There is considerable informational disclosure but the attacker has no control
Integrity Impact	Partial	User can alter the traffic or once exploited
Availability Impact	Partial	Reduced performance or interruptions in resource availability

Risk will be rated as High and this vulnerability will result in PCI Compliance status as FAIL

Case 4 - Special Case Multiple Server Vulnerabilities

Now let’s assume if there is slight change in the environment of the above same vulnerability and following information was provided by the PCI Scan client. The Affected system has restricted access and not available publicly, access is controlled using IPS/IDS and user IPs is whitelisted. We'll change the following while calculating the CVSS2 score under above specified condition.

Exploitability Metrics

Metric	Value	Justification
Access Vector	Network	Requires network access - which accounts for the white-listed IP address
Access Complexity	High	Specialized access conditions exist
Authentication	None	Authentication may not be required.

Impact Metrics

Metric	Value	Justification
Confidentiality Impact	Partial	There is considerable informational disclosure but attacker has no control
Integrity Impact	Partial	Modification of some system files or information is possible
Availability Impact	Partial	Reduced performance or interruptions in resource availability

Risk will be rated as a Medium based on the new CVSS2 score but this vulnerability will still result in PCI Compliant status as FAIL.

Case 5 - Multiple Server Vulnerabilities in Unused Functionality

Now let’s assume if there is more information about the above same vulnerability provided to us by the client saying:

The affected server modules on which the vulnerabilities have been reported are not being used by the application or the server and the system is not publicly accessible

This is a special case where client confirms that affected server module are not being used, this indicates that the vulnerability cannot be exploited since the modules have not been used, so the vulnerability risk can be moved to low from medium with below specified note with default CVSS2 score.

Note: This issue is moved to low since the affected vulnerable modules of the server are not being used and it is advised that reported un-used module should be removed from the server as incase if they are implemented or used in future and result in high risk vulnerability.

Risk can now be rated as Low based on the note and information provided by client and this vulnerability will result in PCI Compliant status as PASS.

Additional Tips and Suggestions

1. Most of the vulnerability scanning tools provide CVSS2 score with vulnerabilities. Sometimes these scores may be wrong, so it’s best to review and validate them before finalizing the risk.
2. The CVSS2 score, if not present for vulnerability, should be calculated manually using the CVSS2 calculator and appropriate risk should be finalized.
3. The right parameters should be used while calculating the risk, wrong parameters may result in wrong score and wrong compliance status.
4. To reduce the risk if the vendor has a compensatory control for vulnerability, a new CVSS2 score should be calculated considering the compensatory control.
5. As per PCI ASV, DoS vulnerabilities will be rated as per below rule:
   
   In case of denial-of-service vulnerabilities, where the vulnerability has both a CVSS2 Confidentiality Impact=none and a CVSS2 Integrity Impact=none, the vulnerability must be marked as pass and must be rated as low risk.

Hope this helps!

Remote Code Execution on Wired-side Servers over Unauthenticated Wireless

By Brad Antoniewicz.

Update 8/28/2013: Cisco has confirmed that the vulnerability is in all current versions of Cisco ACS for Windows (4.x). There is a 5.x ACS version, which is not vulnerable - but I believe that does not run on Windows. CVE-2013-3466 was assigned to this issue.

TL;DR - There's a remote code execution vulnerability that can be exploited via 802.11 wireless to compromise a wired side server. The attacker needs no prior knowledge of the wireless network or authenticated access in order to exploit. This is in an older version of Cisco ACS; Cisco is investigating it and will determine if its present in newer versions as well. Check out the video below to see the exploit in action over a wireless network:

Some Background Info

IEEE 802.1x is a standard that describes a way to authenticate users before they "connect" to a network. This happens at layer 2, before the system is assigned an IP address. Basically, the connecting system (supplicant) communicates via a switch or access point (authenticator) to a back end RADIUS server (authentication server). The supplicant and authentication server communicate using EAP to exchange authentication messages. If all goes well and the user is properly authenticated, the Authentication server sends an "EAP-Success" which prompts the authenticator to allow the user onto the network.

In wired networks, this all happens after the user plugs in their Ethernet cable, while in wireless networks implementing WPA Enterprise, this happens after the standard 802.11 session establishment.

The bottom line is that in both wired and wireless networks the unauthenticated user communicates with the authentication server.

Vulnerability Details

Probably the most important thing to point out is that the remote code execution vulnerability I discovered is in an older version of Cisco Secure Access Control Server (ACS). It's possible that it may be present in newer versions which Cisco is investigating under case PSIRT-1771844416 and bugID CSCui57636.

The vulnerability can be triggered before the user is authenticated, which means that in the case of a wireless network running WPA Enterprise, an attacker just needs to be in the physical proximity of the wireless network to fully compromise the ACS server.

Although there is a communication channel between the attacker and the authentication server when the vulnerability is triggered, it's very difficult to leverage this channel as part of post-exploitation activities. It's more realistic that an attacker would use this vulnerability to establish an reverse shell back via the internet. It may also be possible to redirect the execution flow to result in an "EAP-Success" message (or countless other functions). The video above simply demonstrates code execution. Note that in the video the presence of the wired connection between the authentication server and the attacker is there to show the observer path (how the video was recorded) and the potential reverse shell path; in the case of WPA Enterprise, no wired access is required by the attacker to exploit the vulnerability.

Impact

Besides the obvious impact concerns (e.g. system compromise), authentication servers are particularly sensitive systems. They're usually on privileged network segments, integrated with Active Directory, and can be responsible for VPN authentication. ACS in particular also supports TACACS which could allow an attacker to compromise network devices such as routers, switches and firewalls. For an attacker, compromising the authentication server is a very strong foothold into the environment.

Further Information

As mentioned, Cisco is currently investigating this vulnerability. They've been provided a full working exploit and have been extremely responsive and accommodating thus far. The exploit or any further details will not be publicly released until Cisco has had enough time to determine the full extent of the vulnerability. Stay tuned!

Follow me on twitter - @brad_anton

FSFlow - A Social Engineering Call Flow Application

By Brad Antoniewicz.

A few months ago I was thinking about ways to improve and standardize social engineering calls. It's a difficult thing to do, conversations can go almost anywhere over the span of a phone call which makes defining a specific process hard, if not impossible. As I explored the idea, I was reminded of a high school friend who had a telemarketer job one summer. He told me how nearly everything they said was presented to them on a screen in front of them, and they would navigate through a process flow as the call progressed. I decided to use this model and apply it to social engineering in a tool called "FSFlow". Now this is mostly a proof of concept tool but it's fully functional so I encourage you to try it out. Here's what its all about.

Judging User Responses

One of the major pains with designing an application like this is judging the response of a user. You can never predict the user's exact response so the measure of the response needs to be somewhat abstracted. Our approach here is to identify if the user's response is positive or negative. For instance, if you say "Hi, How are you?" and they say "Great!" - that's a clearly positive response, while "What do you want." is a bit more negative. Similarly, if you ask someone "What is your password?" and they provide it to you, that would be positive, while anything else is likely to be negative.

The difficult thing here is that many user responses aren't easily categorized as negative or positive; perhaps a sliding scale would be more appropriate - but that would create tons of possible branches, making a complete call flow impractical.

Another really interesting option that was suggested to me is using voice analysis to identify how the user feels. The person who suggested the idea used to work for a company that would try to identify if a person was happy, sad, felt helped, etc... after a customer service call. It would be interesting to implement this in the future .

Logging

Another hugely important thing we wanted to do with FSFlow is capture how the call progressed. The call log records how the call progresses and what information is obtained at what points in the call flow. You could potentially use this information to determine where users need more security awareness training - e.g. every user was willing to disclose their IP address, but only some gave their password or even when asking this specific question, users got suspicious and ended the call.

While we don't do this now, another suggestion we received was to record the conversation or integrate it with Skype - so that the calls can be reviewed later on.

The Interface

FSFlow's interface is meant to be as simple and straightforward as possible so that the caller is not overwhelmed or distracted during the call. During the planning phase of the application, I created a sketch to outline what the interface should look like:

For the first release, we slimmed things a bit, resulting in 4 major areas: the statement pane, response pane, objectives and call variables:

Statement Pane

The statement pane is the actual wording the caller says during the call. This is your social engineering attack. The important thing about this pane is that the wording is clear and easy to read aloud. You'll notice in the screenshot above that there are placeholders, e.g. "[TARGETNAME]", this are call specific variables that are populated once you populate the Call Variables pane (described below).

Response Pane

Directly under the statement pane is the response pane compromised of the "Negative Response", "Positive Response", Busted" and "Recovery Mode" buttons. Each of these buttons progress the call to the next flow state. The "Recovery Mode" button is meant to gently direct the call to an end without aggravating the callee. The "Busted" button is more of an "Ok, you got me" response where you let the callee know that this is a social engineering call, they should contact the point of contact for the company (the person that hired the caller), and to please not tell the coworkers of the test :)

Objectives

The Objectives pane is where the caller can log what elements of information they're able to obtain during the call.

Call Variables

Call Variables customize the flow to each individual call. Before the call starts, the caller populates these variables so that the placeholders in the statement pane are replaced with pertinent information. It also serves as a reminder to the caller to who they are pretending to be!

The Call Flow

The most important component of FSFlow is its XML based call flows. The idea behind the call flow is that they could be easily shared to be improved and make standardized attacks. Let's look at sample.xml that's included with the application.

The entire call flow is included within a <CallFlow> block which takes one attribute, name. Within the CallFlow block, you have Objective, CallBlock, and FlowBlocks

Objectives

Defining objectives is pretty straightforward:

 <Objective>Login Username</Objective>
<Objective>Login Password</Objective>
<Objective>PIN</Objective>

CallBlocks

A CallBlock is effectively a container for an individual statement. These statements are then linked together within the FlowBlock below. Place holders can be anything you'd like, as long as they're wrapped in brackets. FSFlow analyzes the flow on start up to populate the "Call Variables" pane.

 <CallBlock name="Introduction">
  <statement value="Hello [TARGETNAME], *PAUSE* My name is [CNAME] from [CROLE]"/>
 </CallBlock>
 <CallBlock name="Website Problems">
  <statement value="I'm having trouble logging into the [WEBSITE] application.  Can you help me?  *PAUSE* [POC] told me to go to [URL] and login, but I get a strange error. *PAUSE* Can you login?"/>
 </CallBlock>

The "Busted" Call block is a static value used throughout the call:

 <CallBlock name="Busted">
  <statement value="I'm sorry to bother you. Actually I work for Foundstone, a Division of McAfee. We were hired by your company to perform 'Social Engineering' testing. You can contact [POC] if you need to confirm this. Since I'm conducting this testing, I'd ask that you don't tell your coworkers"/>
 </CallBlock> 

FlowBlocks

The FlowBlock links together individual CallBlock and ties them to buttons.

  <FlowBlock name="FlowBlock1">
  <CallBlockFlow value="Caller Pickup">
   <PositiveResponse value="Introduction"/>
   <NegativeResponse value="No Answer"/>
   <RecoveryResponse value="Recovery Response"/>
  </CallBlockFlow>
    </FlowBlock>

Todo

The biggest thing that we need to do now is develop solid CallFlows, without them, it's really hard to judge exactly how successful this will be! If you have an idea for a flow, let me know!

Download

You can download FSFlow now!

• https://github.com/OpenSecurityResearch/fsflow/releases/

Have any other ideas? Let us know in the comments below!

Note: Image above is from here