 |
||
Total Website Security |
||
|
||
|
|
|
|
|
Welcome to the September 2007 edition of the WhiteHat Sentinel Service newsletter, designed to keep you up-to-date on the WhiteHat Sentinel Platform and changes in our website security testing activity. New Site Improvements – Upgrade Scheduled for September 12, 5:00 PM PDT These enhancements to the Sentinel Interface demonstrate our commitment to improving the customer experience and site usability. Please contact the WhiteHat Security Operations Team if you have questions.
WhiteHat Sentinel Update :: July 2007 Second Edition :: Welcome to the second July 2007 edition of the WhiteHat Sentinel Service newsletter, designed to keep you up-to-date on the WhiteHat Sentinel Platform and changes in our website security testing activity. WhiteHat Sentinel Service News WhiteHat Sentinel Service Feature Updates Sentinel will soon have some advanced conditional logic to enable us to identify vulnerabilities like Blind SQL Injection and attribute-based XSS injection much more effectively. Also very soon, WhiteHat will be able to describe inference-based attacks. For example if the timing of this response >= n-milliseconds, do X; else IF timing <= n-milliseconds, do Y then Z. This will greatly increase scanning intelligence and make decisions contextually based upon the current state of the website. New Vulnerability Detection WhiteHat Sentinel implemented our second-generation attribute injections last week. Many of you have seen new XSS attack vectors being pushed on your sites, and for quite a few it is a result of these tests. The example we most often push is sourcing in JavaScript via an injected STYLE tag (attack vector for Internet Explorer). Attribute injection is when user-controlled data lands inside of an HTML tag, or specifically a value inside of an HTML tag, where notorious characters like “<” and “>” may not be required for XSS exploitation. For example: HTTP GET request (not actual Sentinel test - this is an example for exploitation): https://www.domain.site/search/partner/index.cfm? Will result in this example tag in the HTTP Response: <td> This is a perfect example of an XSS vulnerability in which the attacker wouldn't need HTML tags or meta characters like <>. All you need in this case is a double-quote, a colon, and some parenthetics to begin your attack. From here the exploit can be carried out in many ways (e.g.-malicious Javascript). The ability to detect these issues accurately will grow exponentially with the advanced conditional logic currently being implemented into the Sentinel Service. WhiteHat Sentinel New Service Tips WhiteHat Website Vulnerability Management Practice Tips Alternately you could encode any user-supplied data safely on output. This is the safest approach. Barring international-language sites – there are a minimum of four alternate encoding types for all Latin-ASCII code page characters: being Unicode, Decimal, Hexadecimal, and Named. This can jump to 18 variants for something as simple as double-quote, if you factor in international-language code pages. Q. How do I encode my output safely? A nice reference page for more on entity-encoding values can be found here: Q. What is this Unicode craziness you speak of?
WhiteHat Sentinel Update - July 2007 WhiteHat Sentinel Service Feature Updates HTTP Response Splitting is a little known, very complex, and frequently misunderstood website vulnerability. The best way to think about Response Splitting is that it’s executed similarly to Cross-Site Scripting (XSS), but more powerful. Take a loose analogy of a written letter in an envelope. XSS targets the message inside the envelope, while Response Splitting targets not only the message inside the envelope, but the envelope itself. There several different variations of Response Splitting and many emergent behaviors that make accurate vulnerability identification challenging. WhiteHat has been investing a lot of R&D time perfecting the accuracy of our tests and has started pushing the results to Sentinel users last week. WhiteHat Security plans to release a paper on this subject, breaking down the details of various conditions, implications, and how to measure them. In the meantime, the results of our testing contained a few surprises: 1. HTTP Response Splitting issues are far more widespread than expected. 2. HTTP Response Splitting issues are far more severe than expected. 1. One-to-Many: One attack can target many users. These issues only occur in very specific situations. We will actively notify you if we discover that those conditions are true. But, this can be tough to measure and we may not always know if the above worst case scenario conditions are possible. This evaluation may require some investigation on your end. WhiteHat Sentinel New Service Tips Don’t forget to schedule new scans if you temporarily stop your scan schedule. We have noticed some folks pause testing for a week or two to push new code, and then forget to resume scans (thus not testing their new code!). WhiteHat is continually adding new tests and improving old ones in Sentinel. So, you will sometimes find new vulnerabilities in old code. WhiteHat Website Vulnerability Management Practice Tips Q. How do I fix a vulnerability to HTTP Response Splitting? 1. Input Validation: You can try to remove every CRLF (\r \n) from input. The problem you will have is that the CRLF is likely to be encoded in some fashion. It could simply be URI-escaped (%0d%0A) or some other Hex or Decimal encoding variant. If you do not find all the encoded CRLF variants that your application is capable of decoding, you will still be vulnerable. 2. URI-escaping: If you properly escape the URI in every place it is output, like the HTTP Location Header, the CRLF will not be parsed by the browser. The problem with this approach is that there are some conditions, like personalization cookies, that are not URI data but could be a Response-Splitting attack. We could take our personalization cookie that is name=WhiteHat and make that name=WhiteHat%0D%0A and craft our attack after that. When your application goes to set that cookie with our name and subsequent attack, the HTTP Response Splitting attack will occur when it reaches the browser. You would have to try and catch that on input validation, or write a special library to escape \r \n anywhere you found it in output that was potentially user-supplied data. WhiteHat Sentinel Update - August 2007 Edition Welcome to the August 2007 edition of the WhiteHat Sentinel Service newsletter, designed to keep you up-to-date on the WhiteHat Sentinel Platform and changes in our website security testing activity. WhiteHat Sentinel Service News HTTP Response Splitting results are in: http://www.whitehatsec.com/home/resources/newletters/update.html Many customers have asked us which Web servers are vulnerable to HTTP Response Splitting attacks. While we are still assembling aggregate totals, here is an initial list of server types we’ve observed to be vulnerable: 1. Apache/2.x Note that the problem of Response Splitting susceptibility is really with the application code. A common mistake is narrowly focusing on the server itself as the source of the issue, likely because a few servers have controls to strip this attack from HTTP GET requests. However, many of the HTTP RS attack vectors we’ve found use the HTTP POST verb as well. The initial HTTP Response Splitting tests are not yet taking advantage of our more advanced testing engines that perform layered encoding attacks and malformed URI manipulations. Once this is fully incorporated, we expect to find even more variants than we do today. Watch Out For... User ID and Password mishandling: Using the user ID and password after logging the user in, as session or authorization identifiers, is a dangerous practice with many security implications. Not only does the presence of an XSS vulnerability indicate that you are giving up the user’s credentials very easily, but it often indicates weak session handling and leads to a variety of information-leakage issues, like passing the user ID and password off-domain via the HTTP Referer field or non-SSL encrypted parts of the website. So, don’t use the user ID and password as identifiers. While enhancing our authentication and automation tests, we have been observing more and more Web applications that pass the user ID and the password around in things like hidden form fields or cookies. Sometimes credentials are encoded, sometimes encrypted, and sometimes they are en claire (in plain sight). While the actual security implications of this are contextual to the specific application, this design pattern usually indicates the presence of one or more weaknesses. WhiteHat Sentinel Service Feature Enhancements We are excited to announce many Sentinel platform enhancements focused on improving usability and manageability, including: 1. New “Findings” Interface: All columns are now sort-able. You can apply a variety of filter and sort mechanisms to organize your vulnerability data! For those of you with more than 20 sites in Sentinel, especially those of you with 50+ sites or 500+ vulnerabilities, this is a very powerful and more manageable way to review your findings. (ref: https://sentinel.whitehatsec.com/finding/finding.html) Coming Soon Our #1 priority since identifying this has been the restoration of Sentinel's IE performance. A solution should be released within two weeks. New Summary Graphs Page: In a few weeks, the overview graphs on the Summary pages of Sentinel will render faster and will be easier to understand at a glance. The Vulnerabilities by Class Chart has been updated, and the old graphs will be been replaced with three charts that depict the following data: 1. Overall Rating: A bar graph that divides the number of vulnerabilities according to Severity, Threat, and Score. WhiteHat Sentinel Service Tips We will be adding user documentation and guidelines to the Sentinel interface very soon. In the meantime, we thought it would be helpful to share definitions for Sentinel terminology with you, starting with asset and vulnerability value terms: Sentinel Service Terminology: 1. Priority: On a scale of 1 to 10, a customer-determined level of value or importance of a scanned site. WhiteHat Website Vulnerability Management Practice Tips Q. What do I do if I see a user ID and password being passed around one of my applications? A. First off – you need to identify why the credentials are being passed around in the application. If there is no reason, you can simply have your developers remove it. Barring that, a common weakness we observe is the user ID and password being used as a form of session-token to maintain state in the application. This is a really bad idea on many levels. In addition to information leakage issues with the user credentials, this will introduce: 1. Session Fixation Weaknesses: The “session token” is predictable, fixed, and unchanging. This makes it a trivial task for an attacker to reverse-engineer and take over a “session.” (ref: http://www.webappsec.org/projects/threat/classes/session_fixation.shtml) Another common use is when credentials are checked before making security decisions such as verifying whether or not a transaction is really authorized by the user. Unfortunately, if the credentials are not entered by the user, but rather provided automatically via a hidden form field or cookies – the attacker can also force the user to submit these automatically. WhiteHat Wants Your Feedback Your feedback will help us improve WhiteHat’s customer service. Please drop us a line at support@whitehatsec.com and tell us what you think. We’re particularly interested in the following: Q1: Do you currently use or have you ever used a Web Application Firewall (WAF). If so, which one? Q2: If WhiteHat Sentinel could automatically provide custom WAF rules to immediately prevent the exploitation of identified vulnerabilities – would this be of value to you? Q3: If so, how important would this service be to you?
WhiteHat Sentinel Update - July 2007 Second Edition Welcome to the second July 2007 edition of the WhiteHat Sentinel Service newsletter, designed to keep you up-to-date on the WhiteHat Sentinel Platform and changes in our website security testing activity. WhiteHat Sentinel Service News WhiteHat Sentinel Service Feature Updates Sentinel will soon have some advanced conditional logic to enable us to identify vulnerabilities like Blind SQL Injection and attribute-based XSS injection much more effectively. Also very soon, WhiteHat will be able to describe inference-based attacks. For example if the timing of this response >= n-milliseconds, do X; else IF timing <= n-milliseconds, do Y then Z. This will greatly increase scanning intelligence and make decisions contextually based upon the current state of the website. New Vulnerability Detection WhiteHat Sentinel implemented our second-generation attribute injections last week. Many of you have seen new XSS attack vectors being pushed on your sites, and for quite a few it is a result of these tests. The example we most often push is sourcing in JavaScript via an injected STYLE tag (attack vector for Internet Explorer). Attribute injection is when user-controlled data lands inside of an HTML tag, or specifically a value inside of an HTML tag, where notorious characters like “<” and “>” may not be required for XSS exploitation. For example: HTTP GET request (not actual Sentinel test - this is an example for exploitation): https://www.domain.site/search/partner/index.cfm? Will result in this example tag in the HTTP Response:
This is a perfect example of an XSS vulnerability in which the attacker wouldn't need HTML tags or meta characters like <>. All you need in this case is a double-quote, a colon, and some parenthetics to begin your attack. From here the exploit can be carried out in many ways (e.g.-malicious Javascript). The ability to detect these issues accurately will grow exponentially with the advanced conditional logic currently being implemented into the Sentinel Service. WhiteHat Sentinel New Service Tips WhiteHat Website Vulnerability Management Practice Tips Alternately you could encode any user-supplied data safely on output. This is the safest approach. Barring international-language sites – there are a minimum of four alternate encoding types for all Latin-ASCII code page characters: being Unicode, Decimal, Hexadecimal, and Named. This can jump to 18 variants for something as simple as double-quote, if you factor in international-language code pages. Q. How do I encode my output safely? A nice reference page for more on entity-encoding values can be found here: Q. What is this Unicode craziness you speak of?
WhiteHat Sentinel Service Feature Updates HTTP Response Splitting is a little known, very complex, and frequently misunderstood website vulnerability. The best way to think about Response Splitting is that it’s executed similarly to Cross-Site Scripting (XSS), but more powerful. Take a loose analogy of a written letter in an envelope. XSS targets the message inside the envelope, while Response Splitting targets not only the message inside the envelope, but the envelope itself. There several different variations of Response Splitting and many emergent behaviors that make accurate vulnerability identification challenging. WhiteHat has been investing a lot of R&D time perfecting the accuracy of our tests and has started pushing the results to Sentinel users last week. WhiteHat Security plans to release a paper on this subject, breaking down the details of various conditions, implications, and how to measure them. In the meantime, the results of our testing contained a few surprises: 1. HTTP Response Splitting issues are far more widespread than expected. 2. HTTP Response Splitting issues are far more severe than expected. 1. One-to-Many: One attack can target many users. These issues only occur in very specific situations. We will actively notify you if we discover that those conditions are true. But, this can be tough to measure and we may not always know if the above worst case scenario conditions are possible. This evaluation may require some investigation on your end. WhiteHat Sentinel New Service Tips WhiteHat is continually adding new tests and improving old ones in Sentinel. So, you will sometimes find new vulnerabilities in old code. WhiteHat Website Vulnerability Management Practice Tips Q. How do I fix a vulnerability to HTTP Response Splitting? 1. Input Validation: You can try to remove every CRLF (\r \n) from input. The problem you will have is that the CRLF is likely to be encoded in some fashion. It could simply be URI-escaped (%0d%0A) or some other Hex or Decimal encoding variant. If you do not find all the encoded CRLF variants that your application is capable of decoding, you will still be vulnerable. 2. URI-escaping: If you properly escape the URI in every place it is output, like the HTTP Location Header, the CRLF will not be parsed by the browser. The problem with this approach is that there are some conditions, like personalization cookies, that are not URI data but could be a Response-Splitting attack. We could take our personalization cookie that is name=WhiteHat and make that name=WhiteHat%0D%0A and craft our attack after that. When your application goes to set that cookie with our name and subsequent attack, the HTTP Response Splitting attack will occur when it reaches the browser. You would have to try and catch that on input validation, or write a special library to escape \r \n anywhere you found it in output that was potentially user-supplied data. WhiteHat Sentinel Update :: April 2007 :: Welcome to the WhiteHat Sentinel Service update, the first in an ongoing series designed to keep you informed of updates to the WhiteHat Sentinel Platform, as well as changes to our website vulnerability testing activity. New Sentinel Service Alerts While we are continually implementing new tests into the Sentinel framework, these particular tests may find XSS in applications previously thought secure to XSS attacks. So, we wanted to provide advance notice of this possibility. In general, there will be times, as we implement new security tests, that we will find new vulnerabilities in old, stable code in your web applications. WhiteHat Sentinel Service Feature Updates 2. Sentinel 3.1 release is getting closer. This release contains the much-anticipated new “Findings” tab with powerful options to filter and sort vulnerability information to make delegation and remediation of vulnerabilities more granular; this is especially useful for large, highly distributed organizations. There are also more comprehensive messages communicating the status of actions like vulnerability retest requests. 3. The Sentinel PDF report engine is currently being re-written. We have listened to your requests and are adjusting print reporting options to provide better detail on test activities and vulnerability locations. WhiteHat Sentinel New Service Tip Have your authorized organizational contact email support@whitehatsec.com today, and we will create the accounts you need so your developers can work more closely with Sentinel’s security test details and utilize the real-time verification ability. WhiteHat Security Website Vulnerability Management Practice Tips 2. Since there are not many good encoding libraries out there for most common Web application frameworks, we recommend that you create your own. Microsoft’s ACE Team has a great one for reference: http://blogs.msdn.com/ace_team/archive/2006/11/20/microsoft-anti-cross-site- http://www.aisto.com/roeder/dotnet/
|
The data contained within this report is completely different than the reports distributed by Symantec, Mitre (CVE), IBM (ISS) X-Force, and others. These organizations track publicly disclosed vulnerabilities in commercial and open source software products, which often contain Web application flaws as well. WhiteHat’s data is different because it focuses solely on previously unknown vulnerabilities in custom web applications, code unique to that organization, on real-world websites Also, the websites managed under WhiteHat Sentinel are likely represent the most “important” and “secure” websites found on the Web, conducting high-volume transactions and managing sensitive information. This context is helpful when estimating the current global state of website security.
|
|
||
|
||
|
||
|
||
