During a customer project we identified an issue with the validation of JWT
tokens that allowed us to bypass the authentication by using unsigned tokens
with arbitrary payloads. During analysis we found out that this is caused by a
vulnerability within the library
OpenID Connect Authenticator for Tomcat.
OpenID Connect Authenticator for Tomcat
between versions 2.0.0 and 2.5.0, as well as the current state on branch
master contain a security flaw (introduced with commit 64e9a99) that allows
attackers to bypass JWT signature validation easily.
When you’re analyzing web applications as a pentester or reading pentest reports
about web applications, you will often see findings regarding cookies missing
certain security flags. The Set-Cookie HTTP header and the JavaScript
document.cookie API allow to use, for example, the
flags Secure, Path, and Domain.
Common audit and pentest tools will tell you when your web application does not
or just insecurely implements these cookie flags.
However, they do not provide optimal security even when using these flags
correctly. However, there are mitigations available that partly solve the
issues.
Missing server-side validation consistently scores a place in the
OWASP Top 10. Browsers nowadays offer
a lot of ways to easily implement client-side controls, increasing the usability
by a lot. They automatically detect missing fields or invalid characters in your
input fields and may even validate user input against a regular expressions.
However, these controls should only be considered as usability features. When
sending data to a back-end system the application must always ensure data
integrity by implementing encodings, validations and filters. Even for small
applications this is a painful and tedious process. For each possible input,
developers together with security experts have to carefully identify the context
of each field, how the input is going to be used and what data requirements are
present.
Hey there, for those of you that roll your eyes when writing the nth Information Disclosure Finding in a report, here is a short story of how such information helped compromising a system.
In a recent penetration we found a hidden debug page which disclosed information about internal parameters. Along with database connection strings and key material there was a username and a user home parameter disclosed on said debug page.
The HITBSecConf or “Hack In The Box” in Amsterdam is a well known security conference in Europe. We also attended this year too, and there were quite some interesting talks at the HITBSecConf16 conference. One of the talks was about “New Methods for Exploiting ORM Injections in Java Applications” by the security researchers Mikhail Egorov and Sergey Soldatov.
I. What is Object-Relational Mapping (ORM)?
ORM stands for Object-Relational Mapping, which is a technique that automatically converts data from a relational database management system (RDBMS) into objects. This is often used in business applications of today.
I’ve recently found some sort of classic web vulnerabilities in the Google Search Appliance (GSA) and as they are now fixed [0][1][2], I’d like to share them with you.
First of all, some infrastructure details about the GSA itself. The GSA is used by companies to apply the Google search algorithms to their internal documents without publishing them to cloud providers. To accomplish this task, the GSA provides multiple interfaces including a search interface, an administrative interface and multiple interfaces to index the organization’s data.
First of all: This is not an in-depth Kerberos how-to, nor is this tutorial about the different aspects of web application testing. This tutorial is just to give support in testing Kerberos authenticated web applications. The goal is to hand over the right tools and steps to be able to perform the configuration and be able to test the application.
When to use it?
When there is a 401 server response with the header “WWW-Authenticate: Negotiate”. This can either mean Kerberos or NTLM authentication is needed. It is possible to distinguish them by looking at valid authenticated client traffic. As a simple reminder: The NTLM Authorization header will always start with the value “TlRM…”, the Kerberos Authorization header will always start with “YII…”. For further information this link is recommend.
In this tutorial the term “Kerberos authentication” will be used. There are other terms sometimes used like SPNEGO, SSO or integrated authentication.
You evade web application firewalls as they would be opened doors?
You have successfully exploitated CVE-2015-8769?
Then it’s time for the next challenge! Follow us down the rabbit hole to the not so well known attacks against modern web applications.
At Troopers16 we will be presenting the second iteration of our WebHackingSpecialOps workshop in which more advanced techniques to break current web application technologies will be explained. On the first day there will be an introduction that gives a quick overview on the well-known attacks like SQLi, XSS and XSRF. Then attacks will be shown that build upon these “old” vectors including blind/clientside SQLi, NoSQLi and some specialties on NodeJS, the javascript based server-side runtime. Next to these technical topics several formal subjects like 3rd library handling and a guideline on how to deploy TLS in a secure way will be given. Especially the 3rd party library chapter since they have become more and more relevant, as in the near past several major vulnerabilities in such libraries were found which gave attackers the chance to break web applications that were based on these. This shows that even though developers do a great job and developer companies get familiar with secure development lifecycles, there are still problems depending on the used technologies that cannot be addressed easily. One example of such a vulnerability is the object deserialization flaw in the Apache Commons Collections library, which was discovered at the beginning of 2015 and got attention in November, when two researchers presented their talk on AppSecCali2015 and showed how easy remote code execution can be done through this kind of flaw. The details of all kind of object deserialization (as almost all current scripting/high level programming languages support this feature) will be part of our course. Next to these topics a deep-dive into current crypto algorithms, their usecases concerning webapplications and their flaws will be given. Within every part of this course several demos and hands-on exercises will be done, so every attendee will be able to apply new knowledge directly. Don’t miss this chance to improve, Trooper!
During one of our latest web application code review projects I came across a vulnerability for which I think it is worth to speak about. It is an injection based attack against XML parsers which uses a rarely required feature called external entity expansion. The XML specification allows XML documents to define entities which reference resources external to the document and parsers typically support this feature by default. If an application parses XML input from untrusted sources and the parsing routine is not properly configured this can be exploited by an attacker with a so called XML external entity (XXE) injection. A successful XXE injection attack could allow an attacker to access the file system, cause a DoS attack or inject script code (e.g. Javascript to perform an XSS attack).
In the context of an internal evaluation, we recently had a look at most of the burp plugins available from the BApp store. The following overview represents our personal top 9 plugins, categorized in “Scanner Extensions”, “Manual Testing” and “Misc” in alphabetic order:
