One of my favorite things to do around Christmas is to participate in SANS Holiday Hack Challenges. These challenges are a fun way to learn and practice hacking skills. They are released once a year around Christmas and cover a broad range of technologies, tools and hacking techniques. Aside from the high quality of the exercises in an extremely gamified environment, these challenges are: 1) absolutely free; 2) available indefinitely, so folks can play year-round, going back to past challenges as they wish.
The 2016 challenge included many tasks such as reverse engineering a mobile application, Linux hacking, password cracking, network dump analysis and, of course, web application hacking. One of the web sites had a vulnerability allowing an attacker to modify their session cookie to escalate privileges from guest to administrator. This was trivial to accomplish after getting possession of the application’s source code along with the hardcoded encryption key. But what if the key was not known?
This article will demonstrate a practical attack on RC4 ciphertext to make controlled changes in the decrypted plaintext without knowing the encryption key. The technique relies on certain properties of stream ciphers.
This page is a collection of instructions to remove unnecessary server headers which may be reported as part of a Penetration Test performed by a security engineer or reported via automated tools. I have cataloged these remediation instructions for many technologies in one place to save the vast amounts of searching required for some of the more obscure technologies.
Each section below is be divided into a short solution and along with a longer one. The “Short Answer” gives the quick means to remove the offending header while the “Long Answer” gives more details along with alternate and (perhaps) more thorough solutions.
Why bother? In general, excessive headers are bad:
- They expose what version of software is running on the server, reducing the work an attacker needs to do before trying to attack the system.
- Headers are the same for a normal user or an attacker. So, a known long string of characters in an encrypted data stream might aid an attacker in cracking open the encrypted TLS connection of another user.
- It’s a general waste of bandwidth and processing power.
As we discussed in Part 1 of this post, Dynamic Application Security Testing (DAST) is often the first step that many organizations take when embracing application security.
Yet we learned that most DAST tools do not provide reliable results without being tuned for the specific application being tested. What does that mean for most organizations?
Dynamic Application Security Testing (DAST) is often the first step that many organizations take when embracing application security.
Dynamic analysis (often referred to as black-box testing) is categorized by testing a running web application (as opposed to static, non-running source code). A DAST tool is usually a scanner that is designed to send malformed and malicious HTTP requests to your application, then interpret the responses and detect potential vulnerabilities.
However, despite how they may be sold, most DAST tools will not provide reliable results without being tuned for the specific application being tested.
A few weeks ago my friend (1) and I attended a hackathon sponsored by a local ISSA chapter (2). The hackathon was a hands-on event where participants learned about common web application vulnerabilities in a fun, gamified environment. The technical platform for this hackathon was provided by Security Innovation (3).
At the end of the event, the two of us finished first and second, with nearly half of the available points each. Security Innovation, however, graciously kept the game open for a few more days to give the participants an opportunity to continue to play and learn.
We used this opportunity to find and exploit more vulnerabilities in the application, and ultimately discover the one that allowed us to completely own the application server.
During a project working with Hydra, a Network Login Auditor, we discovered and corrected a buffer overrun issue with possible security implications that might include the auditor being attacked by the auditee.
TL;DR Attacker using Hydra or Medusa can get pwn'd by the victim website responding with remote code execution via buffer overrun exploit.
For those who weren't able to attend GrrCon 2016, here's Aspect's Tony Miller, Principal Application Security Engineer, speaking about intelligent AppSec prioritization at the conference.
On November 6, Stephen Breen of Foxglove Security (@breenmachine) published a blog post outlining vulnerabilities in components of several Java Web Application Servers (WebSphere, JBoss, and WebLogic) as well as a popular development automation framework (Jenkins).
All of these vulnerabilities follow a similar pattern. And as worrying as that is, it's only the tip of the iceberg (as Foxglove’s post articulates).
So what can you do? This blog post will provide background and information on how to defend against vulnerabilities in Java serialization introduced by Apache Commons Collections affecting common Web App Servers such as WebSphere, JBoss, and Web Logic, as well as common applications like Jenkins.
For those who weren't able to attend AppSec USA, OWASP has kindly been posting session recording on their YouTube channel. Here's Aspect's CEO, John Pavone, speaking at AppSec USA 2015!
I am very excited about the Women in AppSec (WIA) program at the AppSec USA 2015 conference. This year, WIA is hosting a panel of speakers who will be talking about how to encourage gender diversity in information security. Additionally, WIA is sponsoring a series of Birds of a Feather sessions during the day on Thursday where anyone (you too!) can suggest meet-up topics in real-time at the conference.
As part of our panel, WIA was able to raise enough funds to bring two speakers based in India to the conference, Apoorva Giri and Shruthi Kamath, to discuss their organization, InfoSec Girls.