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:
