Aspect Security's AppSec Blog

Developer Answers: What Does Security Want When They Ask about Authentication?

Your developers are plugging away, churning out code and checking off backlog items. Everything is going great and the project is surprisingly on time. But just when you thought you were approaching the finish line, you get that message from the security team you’ve been dreading:

Using an Application Security Pipeline to Achieve Continuous Security in DevOps (Q&A)


Last week, we discussed the concept of an AppSec Pipeline in our blog post, Secure DevOps with aApplication Security Pipeline.

This week, we ask Automation & Integration Specialist James Hobbs some questions about Application Security Pipelines and achieving Continuous Security in DevOps.

Secure DevOps with an Application Security Pipeline

Does your application release cadence leave time for security? For many organizations, the answer is simply – “NO”. 

Organizations face challenges when using the traditional “bolt-on” approach to application security. Security teams are unable to keep pace with the demand of application delivery and deployment so that application security becomes a roadblock – expensive and requiring too many resources. Development teams resist security requirements, knowing that it will slow them down.

How can organizations bypass these issues? By using an Application Security Pipeline to achieve their security goals.

Introducing ASKD: A Controls Based Approach to Security with Application Security Knowledge Domains

Aspect’s engineers have assessed thousands of applications and complex systems – and year after year we find the same design flaws and implementation vulnerabilities. Organizations continue to be breached via the same vulnerabilities that have exposed so many others.

There’s plenty of blame to go around for the problem. But with thousands of vulnerabilities, threats and attack vectors, application developers and security teams face an astoundingly complex problem.

Training helps developers recognize and avoid the most common vulnerabilities; it can help prevent some breaches. But what organizations really need is a framework that facilitates laser-like focus on what matters most in application security – something that cuts through the clutter and gives developers and security teams a clear roadmap to secure the most vulnerable elements of their applications.

Combining Traditional AppSec Training with Active Learning and Gamification

Getting developers to care about security is tough. They are inundated with security best practices to implement in their applications. Most of the time, they have a checklist mentality – a list of items to complete.  Less often is there a genuine understanding of the desired outcome or the spirit behind each security control. 

The result? Production applications comply with company policy, but still contain dangerous vulnerabilities that hackers can exploit.

At Aspect, we think a lot about how to help application architects, developers and security professionals understand – really understand – the root causes of the most serious vulnerabilities used by hackers today.  How do we move past rote memorization and checklists?

Stream Ciphers and Message Integrity

Find me on:

LinkedIn

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.

Insecure HTTP Header Removal

 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.

DAST Tool Not Working? How to Optimize Dynamic Analysis (Part 2)

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? 

DAST Tool Not Working? How to Optimize Dynamic Analysis (Part 1)

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.

Shadow Bank pwn: Cheating a Hackathon for Fun and Profit

Find me on:

LinkedIn

Introduction

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.