(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 

Millions of people visiting mainstream websites over the past two months have been exposed to a novel form of malicious ads that embed attack code in individual pixels of the banners.

Researchers from antivirus provider Eset said "Stegano," as they've dubbed the campaign, dates back to 2014. Beginning in early October, its unusually stealthy operators scored a major coup by getting the ads displayed on a variety of unnamed reputable news sites, each with millions of daily visitors. Borrowing from the word steganography—the practice of concealing secret messages inside a larger document that dates back to at least 440 BC—Stegano hides parts of its malicious code in parameters controlling the transparency of pixels used to display banner ads. While the attack code alters the tone or color of the images, the changes are almost invisible to the untrained eye.

The malicious script is concealed in the alpha channel that defines the transparency of pixels, making it extremely difficult for even sharp-eyed ad networks to detect. After verifying that the targeted browser isn't running in a virtual machine or connected to other types of security software often used to detect attacks, the script redirects the browser to a site that hosts three exploits for now-patched Adobe Flash vulnerabilities.

Read 6 remaining paragraphs | Comments

 

In last couple of years, the MEAN stack (MongoDB, Express.js, Angular.js and Node.js) became the stack of choice for many web application developers. The main reason for this popularity is the fact that the stack supports both client and server side programs written in JavaScript, allowing easy development.

The core database used by the MEAN stack, MongoDB, is a NoSQL database program that uses JSON-like documents with dynamic schemas allowing huge flexibility.

Although NoSQL databases are not vulnerable to standard SQL injection attacks, they can be exploited with various injection vulnerabilities depending on creation of queries which can even include user-defined JavaScript functions.

This diary is actually based on a real penetration test I did on a MEAN based application that initially looked completely safe. So let">db.products.find( { qty: { $gt: 25 } } )

This is important for us as penetration testers since we can potentially influence how a query will be executed and we all know that as long as we can modify input parameters we can make the database do whatever we want it to do (or close enough).

Notice here that JSON, which is used to format queries, has different dangerous characters than those we know from SQL databases: here we care about characters / { } :

Easy development with MEAN

One of the best things of the MEAN stack is that it is very easy and simple to develop web applications. After setting some basic configuration, it is trivial to create a route to our own JavaScript function that will handle certain requests. Let">app.get(/documents/:id">a9577050-31cf-11e6-957b-43a5e81bf71e) and search for it in MongoDB.
Notice here that, although the URL looks static, it is not static at all the GUID here is a parameter that is later used in a function. A question for you: what will your web scanner of choice try to do with this query? Will it insert a ">db.collection(documents">var searchparam = JSON.parse({ \friendly:\ + param + }">db.collection(documents">id parameter taken from the HTTP body) into a JSON string.
Now, as you can probably presume, this is treated differently by MongoDB.

Exploitation time

In case above we can actually manipulate the query quite a bit. Let">$ curl http://vulnsite/documents/ -d id={ \\$ne\: null }">{ $regex: ^a">{ friendly: { $regex: ^a} }

And this will retrieve the first document whose GUID starts with the character a. Nice! We can now retrieve things character by character and do not have to brute force it any more. And just in case we have some kind of WAF (does your WAF understand">{ friendly: { $in: [ /^a/ ] } }

This will result in the same document.

As we can see, NoSQL databases and applications that use them can also be quite vulnerable to injection attacks, so we should never underestimate what an attacker can do that can manipulate input parameters: we should always properly filter and sanitize them.

MongoDB actually supports quite a bit of search operators that can be used in this example you can read more about them at https://docs.mongodb.com/manual/reference/operator/

As NoSQL databases are becoming more popular, I am sure that we will see new and innovative attacks against them. Interesting time is coming for sure!

--
Bojan
@bojanz
INFIGO IS

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
Sungard eTRAKiT3 CVE-2016-6566 SQL Injection Vulnerability
 
BSD libc CVE-2016-6559 Stack Buffer Overflow Vulnerability
 
Fortinet FortiOS CVE-2016-7542 Local Information Disclosure Vulnerability
 
Google Nexus Qualcomm components Multiple Information Disclosure Vulnerabilities
 
Linux Kernel CVE-2016-8655 Local Race Condition Vulnerability
 
ICU 'uloc_getDisplayName()' Function Stack Based Buffer Overflow Vulnerability
 
Google Android Synaptics Touchscreen Driver Multiple Privilege Escalation Vulnerabilities
 
Google Nexus Qualcomm Sound Driver Multiple Privilege Escalation Vulnerabilities
 
Linux Kernel CVE-2015-8967 Local Privilege Escalation Vulnerability
 
Google Android Multiple Privilege Escalation Vulnerabilities
 
Linux Kernel CVE-2015-8966 Local Privilege Escalation Vulnerability
 
CVE-2015-1730: MSIE jscript9 Java­Script­Stack­Walker memory corruption details and PoC
 
Linux Kernel CVE-2016-9120 Local Use After Free Memory Corruption Vulnerability
 
Google Nexus NVIDIA Video Driver Multiple Local Privilege Escalation Vulnerabilities
 
Re: CVE-2016-3222: MS Edge CBaseScriptable::PrivateQueryInterface memory corruption
 
Joomla! Core CVE-2016-9836 Arbitrary File Upload Vulnerability
 
McAfee Application Control and Endpoint Security CVE-2016-8010 Local Security Bypass Vulnerability
 
NetApp Plug-in for Symantec NetBackup CVE-2016-7171 Security Bypass Vulnerability
 
SPIP CVE-2016-9152 Cross Site Scripting Vulnerability
 
Internet Storm Center Infocon Status