#cigital

[sirrv]

The only way is UP! 📈⬆#AppSec #FirstBlogPost #Cigital https://t.co/nzky2Nu8rW (at Atlanta, Georgia)

[humor4fun]

Communication: Providing Low-Level Details

​Background:

Here's a scenario for you to ponder:

·         App Team has their app tested in March.

·         Scan found 100,000 test cases and is 100% complete after 8 days.

·         App Team has their app tested in August.

·         Scan found 700,000 test cases and is only 9% complete after 8 days.

·         We told the App Team that the report will be delayed by at least another month.

·         App Team asks what is the reason for the delay.

·         As the tester, you respond with "The delay is due to large number of test cases. Since April/May (when the last scan was performed), the testing tools have been updated. The updated tools include new attack vectors and payloads, causing increase in the number of test elements, and hence providing a more thorough scan of the application."

  Knowledge:

More often than not, people like to draw their own conclusions (even when you know they will be wrong). The first attempt at communicating issues like this should always be as fact-based as possible without leaving any room for question, or guiding the reader to a specific question or suggested conclusion. When Client Managers and Client VPs asks me questions or I end up needing to find out what happened with a test, the first thing I do is get as many facts as I can and present them. VPs/Clients like to be involved in creating the conclusions that are agreed upon. If you simply present conclusions, they will ask a million questions. App Teams function in a similar fashion: they assume that if you give conclusions that you are trying to place blame somewhere else because you don't know what happened. By not giving conclusions, but presenting facts we avoid the possibility of this strongly aggressive and negative reaction.

  A good exercise to do this is to write your email and save it – don't send it. Get some coffee, talk to your neighbor, watch a music video and come back to the email 30/60/90 minutes later. Re-read your email and make note of any questions that pop into your head. Use these questions to further add information to your email. Understanding the thought process of the folks who would be reading this email, you may decide to simply list the questions yourself and answer them (in the same email), or to rephrase the message that you want to convey. Another good strategy is to reply saying that you will look into the issue and get back to them. This does two things: 1. Buys you time to gather your thoughts, talk to others and generally calm down. 2. Lets them know that you saw their message and are working on a response so they do not begin to feel neglected. Saying that you will review the issue with another person usually gives a positive feeling to the asker because they understand that you are just human, and humans make mistakes but being able to accept help shows that you are aware that it may have been your mistake to begin with (even if there is in fact no fault with you at all).

  Application:

Your statement about "testing tools have been updated. The updated tools include new attack vectors and payloads" is a clear statement that will lead to more questions. While this is a factually accurate statement, you need to be careful when including this kind of low-level technical information about process to Application Teams or other people. If you want to include information like this, then it should be followed by further information that answers the questions that may come to mind from reading the statement. In this case, my questions would be:

·         Why was the tool updated?

·         What are test elements?

·         If this is more thorough now, why was it not as thorough before?

·         What kind of new attack vectors are being included that weren't tested before?

·         Are all of the apps that you scan this slow?

  Solution:

Here is what I would suggest have been written here:

"The delay is due to a large number of test cases. We are looking into the root cause as to why there are so many test cases, but some possible causes may be: New versions of scanning software have a broader set of tests since your previous scan; improper configuration of the scan for your application; purely a large number of pages/forms/parameters that need to be tested; multiple pieces of (similar) data are being viewed as separate parameters. I'll have an additional set of eyes from my team help me look into the causes here and once we determine the base of the issue we will be able to come back to you with further details of the issue and potential solutions."

  -cholt-

[humor4fun]

Communication: Sending "Testing On Hold" Type Emails

Scenario

​Everyone has been there: you are working on a test (scan, manual, ara, it doesnt matter) and something blocks your progress. Usually its the accounts getting locked or the environment goes down for a deployment -- and you need to send a message to the App/Dev team asking what went wrong, and how it can get fixed. 

How often are these kinds of emails just the beginning of a 4-day back and forth, back and forth email thread that just sucks away your time? Well, here's a little bit of advice to help you shorten those threads. 

By directing the original email, including extra information, and creating a sense of urgency you may be surprised by how few additional emails you need to send if you take the extra time to do the first one better.

Tips

Always include a screenshot of what you are asking a question about.

We put borders around screenshots in reports; Do the same thing with emails.

If you use multiple screenshots, it helps to add captions.

Most of the time that people read an email with large pictures in them, they will not continue reading past the picture, so it helps to ask all of your questions above the image.

Identify one specific person to direct your question at

{Jason, Please unlock the SSO accounts "x", "y", and "Z"}.  

Tasking a specific person causes direction, so if that person is not able to perform the task, they will pass the task to the next person who can and you will generally see a quicker resolution to issues.

Sometimes you can even include extra incentives

Incentives help to create a sense of urgency to finishing any task.

{Tests  A and B will be on hold until these accounts become unlocked}.

This puts full control into their hands saying, "we can't continue until you fix this".

{The sooner this gets resolved, the sooner we will be able to finish testing and get the report out to you}

I wouldn't recommend this exact until you are near the end of a test, as it usually results in high expectancy.​

-cholt-

[humor4fun]

Updating SSLScan to the New Decade

SSLScan-win is a tool that we have been using for nearly every test over the past 6-18 months within the Cigital Assessment Center. Thanks to the recent Heartbleed fiasco, it came to my attention that the version of the sslscan codebase which we have been using was compiled in April of 2010. Since  that time, TLSv1.1 and TLSv1.2 have grown in popularity and support and other vulnerabilities such as TLS Renegotiation (DoS) and Heartbleed have come about and been released publicly. It is our duty as a leader in the Security industry to be leaders with our tools, so it was time that we update our toolset.

  There have been a few groups on Github who have kept the sslcsan codebase up to date over the pase 4 years; the most recent being rbsec who updated the codebase to include testing support for Heartbleed as well as TLSv1.2 (TLSv1.1 had already been implemented). But alas, the code existed in an un-compiled state. Looking into the code it had not even been kept up to date for Windows compilation. All of the code was built for POSIX libraries and needed to be translated for WinSOCK libraries to run on Windows (since all of our clients have Windows environments that we do testing in).

  I gave it my best go, but being unfamiliar with POSIX vs WinSOCK programming, I was not able to finish the job (though I did come very close). After many people telling me it couldn't or shouldn't be done, I was able to find a guy (within Cigital) – Larry Trowell – who was interested in finishing the job. Here is the result thanks to him.

  We have 32-bit (x86) and 64-bit (x64) binaries compiled for use within the zip file. The actual usage has changed slightly "sslscan_x86.exe www.google.com" will give you only the accepted list, and automatically run the additional tests (such as TLS Renegotiation and Heartbleed). Play around with it and run some tests. You will also notice that there are some fancy text colors to help users identify good vs bad ciphers.

NOTE: green text color does not mean acceptable, it simply is a color.  Please refer to the CAC policy for reporting SSL Ciphers as that has not changed.

  Download Link: http://www.mediafire.com/download/1m0gfylrfr3sz33/sslscan-win.zip

Video: (none) I was going to post a video, but to be honest – this tool shouldn't need a video.

  Here's a sample output of the tool running against google.com:

(added based on emails sent to clients)

Summary of Key Changes

This compilation is based off of the rbsec-sslscan fork from github and includes 4 notable changes over the previous version of sslscan-win which we have been using (compiled April 2010).

  Changes:

Support for Heartbleed -- While the tool does include Heartbleed support, Symantec installations (and potentially other Virus Scanning tools) block the Heartbleed payload so we may not be able to fully test this vulnerability. AppScan 9.0.0 iFix 001 adds the Heartbleed payload to AppScan's test suite. I have not yet seen it successfully reported, so I cannot verify if it is also being blocked by Symantec as of yet. In order to properly test for Heartbleed, Virus Scanning tools should be disabled.

Support for TLS Renegotiation testing -- This represents an attack vector for Denial of Service and is either turned On or Off in the SSL/TLS configuration on the application server. Because this is a Denial of Service attack vector it will most often come out with a CVSSv2 rating of High and can be fixed by simply disabling the setting on the application server. 

More expansive support for testing SSLv2 -- This support won't make much of a difference in testing or vulnerabilities reported, but it will potentially have a longer list of "Low Strength SSL Ciphers Supported" when we report them. This won't change the need/recommendation to disable SSLv2, only provide a more extensive list of SSLv2 cases.

Support for TLSv1.1 and TLSv1.2 -- All modern desktop browsers now support TLSv1.2 (as of March 2014), the only exception to the list  is mobile device browsers. Our recommendation advice for SSL Cipher settings includes TLSv1.2 support and we can now differentiate between versions of TLS (the old version of sslscan was only able to identify TLS and not v1.0 vs v1.1 vs v1.2). As such my team will be adding TLSv1.1 and TLSv1.0 to the "Medium Strength SSL Ciphers Supported" vulnerability categorization.​​

-cholt-

[humor4fun]

Virtual Machine Connections: Logging Off vs Disconnecting

Logging Off of a VM means that you click Start > Log Off.  Logging Off means that you are fully closing your connection, force-quitting any running applications, and most importantly: releasing system resources. ​

Disconnecting from a VM means that you closed the window with the "X" button. Disconnecting allows you to continue to run your applications while not maintaining an active connection. 

These are two very different things.

-cholt-

[humor4fun]

Determining Token Entropy (Randomness)

The current topic is Session Token Entropy. This is cobbled together from pieces of the email chain and hopefully is coherent enough.

  Session Token Entropy Testing

Entropy (definition): Entropy is the measure of unpredictability in a piece of information. High entropy means a high level of uncertainty in the outcome of an event, and based on the situation may or may not be desired. Entropy is said to be maximized if the length of the information (in bits) is the same as the amount of entropy (a quantity in bits).

  For example, in a fair coin toss there are two possible outcomes each with 50% odds and no way to accurately predict the outcome; we would say the information is 1 bit (heads or tails) and the entropy is 1 bit because both outcomes have 0 predictability.

  Another example: in a political poll which is taken because the outcome (who is the current favorite) is unknown and not predictable, this would be said to have a large amount of entropy. In a second poll taken after the first, the outcome is likely very similar to the first poll which we know the outcome of, so we would say this has a small amount of entropy.

  The testing that we perform to identify Low Entropy on session tokens requires us to gather a large amount of session tokens. This can be significantly time consuming in some cases.  For this application we ran the tests at 1,000, 5,000, 10,000 and 20,000 session tokens. The first two tests (1k,5k) showed good entropy but testing at 10k showed a decrease in entropy and our final test of 20,000 showed low entropy (as reported).  Many of our testers run into time problems and are only able to test 10,000 tokens for entropy, but as with any data set that you are looking for patterns in: more cases is always better.

  Reasons why Low Entropy may not be reported:

High entropy exists

Number of test cases is too low to identify low entropy

Time required to receive tokens exceeds available time allotment (causing #2)

Entropy is not tested

Faulty calculation

  Testing session token entropy is part of our checklist that is performed with all of our Standard, Advanced, and Custom scans so #4 is not the case. Speaking with some other assessors who have worked on [this one family of] applications recently I found that  one scan tested 18,000 session tokens and found high enough entropy. This is not an exact science because our tool can only test 20,000 tokens at a time and our standard behavior is to run the tool once per scan. So because there is an element of randomness (entropy) to the token generation process, some data sets may appear random while others may not.

  [file attached includes list of tokens]. If you would like a demonstration of how we test this data set, please let me know. The file is a text file with one token per line (you can import this into Burp to calculate token entropy).

  Entropy Calculation

The amount of entropy is determined through a number of tests some of which include:

Observing single bit or character changes (how often is the second character of one token an 'A' and then the next token it is a 'D')

Observing frequency of bit or characters per position (how often does the character 'F' appear in the 9th position)

Observing patterns in frequency of bits or characters per position ('F' appears as often as 'Q' in position 3, but 'F' appears in every 39th token)

Observing patterns in frequency of bits or characters overall ('2' appeared in every token, while 'R' appeared in 1/3 tokens)

Length of the tokens

Variety of characters at each position

Observing frequency sequential bits that are similar (6 '0's in a row occurs in 30% of the tokens)

Observing patterns in bits or characters (the sequence '0Fed73' occurs in 5% of the tokens)

Concatenating all bits at a single position to test compression using zlib (higher compression means data is less likely to be random, similar to test #2)

  Factors that can contribute to different conclusions per execution of the testing:

Run the tokens through a Base64 Decode sequence prior to analysis

Run the tokens through a Base64 Encode sequence prior to analysis

Pad the tokens with a single bit or character to match the maximum token length – padding at the front

Pad the tokens with a single bit or character to match the maximum token length – padding at the end

Number of tokens used in the analysis (Burp can handle a maximum of 20,000)

Actual sequentiality of the tokens being tested (for best results use sequentially generated tokens, ie. prevent other sources from receiving tokens during the gathering phase)

Actual existence of entropy

The session management system has changed

System variables that affect the token management have shifted significantly (small frequent shifts like clock time should have a positive effect on entropy because they are constantly evolving. However larger shifts such as OS version, patch count, or other environment items that do not change very often and have shifted between tests)

The testing tools have gained additional methods of detecting low entropy

Use a different version of the tool, or an alternate tool. Burp Suite, Web Scarab, and NIST all have token review tools.​

Here's a sample write-up Details: The application session identifier has low entropy which makes it extremely predictable. This could be because the session identifier is based on a sequential value, a time-stamp, the userid, or other factors which are not cryptographically random and are therefore predictable over time. This could allow an attacker who figured out the pattern to guess or brute-force a valid session token, and thereby take over the session and masquerade as the user. Important Note: For this application when we tested the entropy of the session token, it was evident that many pieces of the token are predictable. Normally this would indicate a low amount of entropy, but in this case our tools have failed to properly calculate the actual entropy of the test data set. Cigital cannot confirm or deny the existence of low entropy within the token in question based on the tests performed. The information provided here should be used to further investigate the randomness used in token generation procedures within the application code. Instance(s): • <URL> Cookie: <COOKIE> Steps to Reproduce (Using Burp Suite’s Sequencer): 1. Configure your web browser to use Burp proxy as a proxy and log into the application. 2. Within “Burp Proxy” select the HTTP/POST response from the login page. 3. Right-click on the response and select "Send to Sequencer" from the menu. 4. In the sequencer, select the response and select the session cookie. 5. Click on "Start live capture” in the sequencer. 6. Observe that when it is done sampling (20,000 tokens) the results it will show the “extremely poor” entropy finding with 0 bits of entropy. Screenshot(s): Figure 1: Burp Sequencer shows “...effective entropy is estimated to be: 0 bits” after analyzing. Remedy Suggestions: Generate session identifiers using a cryptographically  random pseudo-random number generator (PRNG) which has an entropy  of at least 64-128 bits. CVSS v2 Scoring Details: N/A

 -cholt-

[humor4fun]

TLS/SSL Client/Secure Renegotiation MitM

TLS has two modes of renegotiation that can be misused for Man in the Middle attacks which completely compromise the confidentiality provided by TLS.

Cigital reports multiple vulnerabilities (at the time of this writing) that all pretty much describe the same thing.  One of them specifies that we report this issue (SSL/TLS Insecure Renegotiation) if and only if Client Renegotiation is Enabled and Secure Renegotiation is Disabled. Great, but what about the other 3 situations?

  Before we answer that question, let's dive into what we are actually talking about here, and how does the man in the middle attack actually work in as a result of this misconfiguration.

  What is SSL Client Renegotiation? – Client Renegotiation is a setting that (if turned on) allows the client (browser, thick client, tool, etc) to decide at any moment that it is unhappy with the currently agreed upon SSL connection settings and begin a new connection with a new set of requested settings. Additionally, this allows session resuming – picking up an old session that was previously negotiated, but has become stale after a period of inactivity.

  A typical SSL Handshake (aka negotiation) would look like this (Sender – Message):

Client – Hello (highest TLS/SSL version supported, random number, suggested ciphers, suggested compression methods and, if the client is attempting renegotiation, previous session ID)

Server – Hello (TLS/SSL version, random number, cipher suite and compression chosen and, if server is attempting renegotiation, previous session ID)

Server – TLS/SSL Certificate

Server – Hello Done

Client – Key Exchange (preMasterSecret exchange and MasterSecret calculation)

Client – Change Cipher Spec

Client – Finished (hash and MAC of previous handshake messages)

Server – Change Cipher Spec

Server – Finished

(connection is now secured)

Client – GET  /secure HTTP/1.1 ….

​

The Man In The Middle attack comes in a few different forms:

An attacker can form a TLS connection to the server before the client does

Attacker can use session renegotiation on behalf of the client

Attacker can perform mutual certificate client authentication (send the client a cert acting as the server, and send the server a cert acting as the client)

  What is SSL Secure Renegotiation? – Secure Renegotiation is a patch to  SSL/TLS that specifies additional instructions for the client and server (as defined in RFC 5746 https://tools.ietf.org/html/rfc5746) that allows extra information to be passed during the negotiation handshake to securely renegotiate an SSL Session, or resume an old session and prevent the Man In The Middle attack described above. This must be implemented by both the client and the server in order for it to operate properly. The information added to the renegotiation helps the client/server to identify the TLS connection that is being renegotiated by adding extra cryptographic data, thus making the MITM attack impossible.

    So! Back to our previous question about how to report the different scenarios:

  Client Renegotiation | Secure Renegotiation | | What do I do?Enabled | Enabled || Report as Client Renegotiation

Enabled | Disabled || Report as Insecure Renegotiation; Report as Client Renegotiation Disabled | Enabled || Report as Renegotiation Misconfiguration​ Disabled | Disabled || No vulnerability; Do not report

 (sorry for the poor formatting, Tumblr doesn't allow tables)

Report as Client Renegotiation – Medium-​High Severity

                Allowing the client to renegotiation their SSL connection forces the server to interact with that client using memory, CPU cycles and network bandwidth. This can be expanded through automated tools to create a DDoS attack against a server. If the client is not allowed to renegotiate, then their negotiation attempts will be ignored by the server Additionally, client renegotiation allows the client to initiate a new session that could be specified to use less secure ciphers than the original connection: imagine the case where a user's computer is compromised through another means (malware) and the attacker is able to force renegotiation of the client to use a less secure cipher, or use the forced renegotiation period to inject themselves as a MITM attack.

  Report as Insecure Renegotiation – Low Severity

                Allowing Client renegotiation may be a business requirement in some situations. Regardless of the reason, if Secure Renegotiation is disabled then the server is vulnerable to the MITM attack vectors described above.

  Report as Renegotiation Misconfiguration – Informational Severity

                ​This was widely publicized since 2011, and was identified in 2009 so we should be holding our clients up to the latest standards in security.  This is not supported in <SSLv3.0, but our recommendation is to move to TLS1.2, or TLS1.1 at a minimum. Upgrading to the newest available version of TLS should resolve this as an issue.

  As always, feel free to come talk to me about this topic if this doesn't make sense or you want more clarification.

  Sources:

http://www.digicert.com/news/2011-06-03-ssl-renego.htm

https://tools.ietf.org/html/rfc5746

http://inet.cigital.com/cvd/view.php?vulnId=104

 ​-cholt-

[humor4fun]

How to Triage "Cacheable SSL Pages"

A reminder to everyone who is triaging scan results, writing reports and reviewing reports. Please review the information below regarding the "Cacheable SSL Page" finding that we report (manually and automated).

  Cigital's practice regarding judgment of "Cacheable SSL Pages" is as follows:

  All pages served over an SSL (HTTPS) connection should not be capable of being cached except where the page in question belongs to one of the following groups:

Client-side artifacts that do not contain sensitive information.

Unauthenticated pages that do not contain sensitive information.

  Examples of these often include such things as:

Client-side artifacts

.css - Cascading Style Sheets

.eot – Fonts

.axd – ASP Controls

.js – JavaScript libraries

.jpg/.png – Images (including other formats)

Standard Responses

301 Redirect responses

Error messages (Generic or Verbose)

Unauthenticated Pages

Frequently Asked Questions pages

Contact Us/About Us pages

  This being stated, there are occasions where items that would fall within this list of standard exceptions may be reported as a true positive. If, for example, a page loaded an image of a digitally submitted check, this would fall under the "sensitive information" category and should not be cached (checks include routing numbers, account numbers, name and address information as well as sample signatures/writing styles and financial spending habits).

-cholt-​