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.
We recently identified a security issue in FireEye AX 5400, that also affected
other products. We responsibly disclosed the bug to FireEye and a fix that
addresses the issue has been released with version 7.7.7. The fix was also
merged into the common core and is available as 8.0.1 for other products (i.e.
FireEye EX).
I recently had the pleasure to attend two events organized by the
Digital Society Institute,
one was a
workshop on software vulnerabilities and one
was their annual
conference.
For both events I delivered input on the security of security products and their
evaluation (slides can be found
here).
The DSI did a great job of assembling people from various areas (e.g. industry,
academia, politics, and research) so there was a lot of input which is not
covered by conferences I usually attend. The workshop I attended also resulted
in a short policy recommendation when it comes to the security of security
products which can be found
here.
Usually I’m not the kind of guy who talks about such economic topics. Because
I’m an engineer / security researcher who is exclusively concerned with
understanding technical problems and if possible, solving them accordingly. My
whole education is based on this and contains predominantly technical aspects of
information security. This sometimes makes it difficult to understand what the
market cares about (and why some products are being developed / exist on the
market 😉 ). Nevertheless, a current engagement for one of our customers made me
stumble upon such a product.
This is a guest post from Vladimir Wolstencroft, to provide some details of his
upcoming
#TR15 talk.
What do you get when you combine a security appliance vendor, a bug bounty
program, readily available virtualised machines, a lack of understanding of best
security practices and broken crypto?
Ownage, a good story and maybe even that bounty…
Focusing on Barracuda’s numerous security appliances, this talk will detail bug
hunting methods and the principles used to examine these machines:
Starting with a black box test and the challenges that this approach poses, to
decrypting the firmware, getting system root, bricking the box, fighting the
(de)activation methods, getting system root again, DOS’ing the VM host and
finally using Barracuda’s own source code to find those vulnerabilities that
otherwise would be invisible or impossible to find! There were also some
unexpected outcomes that followed…