Software Integrity Blog

Author Archive

David Bohannon

dbohannon

David Bohannon is a senior security consultant at Synopsys. His work is heavily focused on web applications, frameworks, and middleware technologies. In addition to client-facing engagements, David also conducts internal software development and vulnerability research for Synopsys. He holds a Bachelor of Science in Computer Science from University of Georgia.


Posts by David Bohannon:

 

What you should know about the recent Atlanta ransomware attack

The city of Atlanta has become one of the latest victims of a ransomware attack. The attack is believed to be the result of the SamSam malware that has compromised various healthcare, government, and educational systems over the past several years. Is SamSam malware responsible? This malware initially targeted a remote code execution vulnerability in JBoss web servers, but it has also been known to target exposed RDP and FTP services. If we continue with the assumption that the SamSam malware is responsible for locking down Atlanta’s IT systems, what could have been done to prevent such an attack, and what are some of the hurdles an organization may encounter? Is a simple patch the solution? If the ransomware attack originated from the original flavor of SamSam, which targets vulnerable JBoss servers, the first solution is to patch to a nonvulnerable version of JBoss. While this may sound easy in theory, it often becomes difficult in practice.

Continue Reading...

Posted in Data Breach | Comments Off on What you should know about the recent Atlanta ransomware attack

 

Node.js: Preventing common vulnerabilities in the MEAN stack

Before jumping into the final post within our discussion on vulnerabilities in the MEAN stack, look back at the other four posts within this series discussing MongoDB, Express.js (Core), Express.js (Sessions and CSRF), and AngularJS. Development mode (Node.js/Express.js) By default, Express applications run in development mode unless the NODE_ENV environmental variable is set to another value. In development mode, Express returns more verbose errors which can result in information leakage. For example, the error message below returns the full path to the requested file. This also provides an attacker with information about the host system.

Continue Reading...

Posted in Open Source Security, Software Architecture and Design, Web Application Security | Comments Off on Node.js: Preventing common vulnerabilities in the MEAN stack

 

AngularJS: Preventing common vulnerabilities in the MEAN stack

Before jumping into the latest post within our discussion on vulnerabilities in the MEAN stack, look back at the first three posts discussing MongoDB, ExpressJS (Core), and ExpressJS (Sessions and CSRF). AngularJS disabled SCE service Angular 1.2 and greater include the built-in Strict Contextual Escaping service ($sce) by default. This service strips malicious HTML tags (e.g., <script>, etc.), attributes (e.g., onmouseover, onerror, etc.), and URI protocols (e.g., javascript) from data rendered as HTML with the ng-bind-html directive. This service can be disabled globally with the $sceProvider.enabled() method in the controller’s config block or per-instance with the $sce.trustAs methods. Thus, leaving the application vulnerable to cross-site scripting (XSS) attacks when binding untrusted data as HTML.

Continue Reading...

Posted in Software Architecture and Design, Web Application Security | Comments Off on AngularJS: Preventing common vulnerabilities in the MEAN stack

 

ExpressJS: Preventing common vulnerabilities in the MEAN stack (Part 2)

Before diving into the latest post within our discussion on vulnerabilities in the MEAN stack, look back at the first two posts discussing MongoDB and ExpressJS (Part 1). Client-side session storage (ExpressJS) With MEAN stack applications, it is fairly common to store the session state client-side in either a JSON Web Token (JWT) or custom cookie object where the value is signed and/or encrypted. This eliminates the need to persist session data server-side and makes the application very scalable, especially among clustered servers. However, this convenience comes at a cost, specifically the inability to invalidate a user’s session. Setting the expiresIn or maxAge attribute on the session cookie only requests that the browser purge the cookie once it expires. However, if the cookie is replayed it will still be accepted by the server.

Continue Reading...

Posted in Open Source Security, Web Application Security | Comments Off on ExpressJS: Preventing common vulnerabilities in the MEAN stack (Part 2)

 

ExpressJS: Preventing common vulnerabilities in the MEAN stack (Part 1)

Before jumping into the Express framework, get up to speed with Part 1 of this series which explores MongoDB. Stack precedence (ExpressJS) The Express framework allows developers to easily add multiple middleware plugins globally to all routes via app.use(). However, middleware order is important because it will only be applied to routes defined further down the stack. Consider the code block below where the isLoggedIn authentication middleware is applied after the /secure/removeInvoice route. The authentication check will be applied to requests for /secure/addInvoice but not /secure/removeInvoice.

Continue Reading...

Posted in Open Source Security, Web Application Security | Comments Off on ExpressJS: Preventing common vulnerabilities in the MEAN stack (Part 1)

 

MongoDB: Preventing common vulnerabilities in the MEAN stack

MEAN stack applications (MongoDB, Express.js, AngularJS, and Node.js) are becoming increasingly popular as lightweight, easily deployable frameworks due to a vast ecosystem of middleware plugins and dependencies. But just how secure are these technologies?

Continue Reading...

Posted in Open Source Security, Web Application Security | Comments Off on MongoDB: Preventing common vulnerabilities in the MEAN stack

 

How to mitigate the Java deserialization vulnerability in JBoss application servers

Multiple versions of JBoss contain a vulnerability that can allow remote users to execute arbitrary code on the server running JBoss; mitigating this issue is not always as simple as upgrading JBoss to the latest version. The Java deserialization vulnerability (CVE 2015-7501 and CWE-502, disclosed in January 2015) affects specific classes within the Apache Commons-Collections library prior to versions 3.2.2 and 4.1; this vulnerability allows remote code execution by an unauthenticated attacker. The Apache Commons-Collections library is included in multiple middleware technologies, including JBoss application servers. JBoss is of particular interest because the invoker servlets which pass serialized objects to the vulnerable Commons-Collections classes are made available over the HTTP web listener (i.e., port 80, 8080, etc.), increasing the likelihood that they are externally accessible beyond corporate firewalls and available to an attacker. Default configurations of JBoss versions 4.3.x, 5.x, and 6.x contain the vulnerable Commons-Collections library and have the invoker servlets enabled; however, the invoker servlets are not enabled by default in JBoss version 7.x.

Continue Reading...

Posted in Software Architecture and Design | Comments Off on How to mitigate the Java deserialization vulnerability in JBoss application servers