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.
Posted in Data Breach | Comments Off on What you should know about the recent Atlanta ransomware attack
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.
Posted in Open Source Security, Software Architecture and Design, Web Application Security | Comments Off on Node.js: 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
Posted in Software Architecture and Design, Web Application Security | Comments Off on AngularJS: Preventing common vulnerabilities in the MEAN stack
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.
Posted in Open Source Security, Web Application Security | Comments Off on ExpressJS: Preventing common vulnerabilities in the MEAN stack (Part 2)
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.
Posted in Open Source Security, Web Application Security | Comments Off on ExpressJS: Preventing common vulnerabilities in the MEAN stack (Part 1)
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?
Posted in Open Source Security, Web Application Security | Comments Off on MongoDB: Preventing common vulnerabilities in the MEAN stack
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.
Posted in Software Architecture and Design | Comments Off on How to mitigate the Java deserialization vulnerability in JBoss application servers