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…