Abriendo caminos

jueves, 23 de abril de 2020

How To Secure Your Home Against "Internet Of Things" And FUD

TL;DR, most of the security news about IoT is full of FUD. Always put the risks in context - who can exploit this and what can the attacker do with it. Most story only covers the latter.

Introduction

There is rarely a day without news that another "Internet of Things" got hacked. "Smart" safes, "smart" rifles, "smart" cars, "smart" fridges, "smart" TVs, "smart" alarm systems, "smart" meters, "smart" bulbs, NAS devices, routers. These devices are getting hacked every day. Because most of these devices were never designed with security as a goal, and some of them have been never tested by security professionals, it is no surprise that these things are full of vulnerabilities.

Independent security researchers find these vulnerabilities, write a cool blog post or give a presentation about the vulnerability and the exploit, and the media forgets the constraints just for the sake of more clicks. "We are all doomed" we can read in the news, but sometimes the risks are buried deeply in technical jargon. Please note I blame the news sites here, not the researchers.

http://www.slideshare.net/danielmiessler/iot-attack-surfaces-defcon-2015

There are huge differences between the following risks:

Attackers can directly communicate with the router (or camera) from the Internet without authentication and exploit the vulnerability. This is the worst-case scenario. For example, an automated ransomware attack against your NAS is pretty bad.
Attackers have to position themselves in the same WAN network (e.g. Sprint mobile network in the case of Jeep hacking) to exploit the vulnerability. This is still pretty bad.
The vulnerable code can not be triggered directly from the Internet, but tricks like CSRF can be used to exploit it (details later in this post).
The vulnerable code can not be triggered directly from the Internet, and it uses a protocol/port which prevents Cross Protocol Scripting. Attackers have to access the local network before exploiting this vulnerability.

As it is the case with the worst scenario, one can find a lot of devices connected to the internet. You can always find funny stuff at http://explorer.shodanhq.com/#/explore , or use the nmap screenshot script to find your own stuff :)

Network exposure

Most devices are behind an IPv4 NAT device (e.g. home router), thus can not be reached from the Internet side by default. Except when the device configures the firewall via UPNP. Or the device has a persistence cloud connection, and the cloud can send commands to the device. Or the device uses IPv6 tunneling (e.g. Teredo), thus it is reachable from the Internet. But not every vulnerability on your home network is accessible directly from the Internet. As more and more devices and networks will support IPv6, this scenario might change, but I hope most home routers will come with a default deny configuration in their IPv6 firewall module. On the other hand, scanning for IPv6 devices blindly is not feasible due to the large number of IPv6 addresses, but some tricks might work.

If attackers can not access the device directly, there is a way to hack it through the user's browser. Just convince the victim user to visit a website, and via CSRF (Cross Site Request Forgery) and brute-forcing the device IP, it is possible to hack some devices (mostly through HTTP - if the exploit can fit into simple GET or POST commands.

If attackers can not attack the device vulnerability through the Internet directly, or via CSRF, but have connected to the same network - the network exposure shrinks significantly. And when attackers are on the same network as you, I bet you have bigger problems than the security of the IoT devices ...

Recommendations for home users

Don't buy **** you don't need

Disconnect from the power cord the IoT devices you don't need to operate 7*24.

Disable cloud connectivity if it is not necessary. For example, I have a NAS device that can be reached through the "cloud", but I have disabled it by not configuring any default gateway for the device. I prefer connecting to my network via VPN and reach all my stuff through that.

Prevent CSRF attacks. I use two tricks. Don't use the 192.168.0.x - 192.168.10.x network at-home - use an uncommon IP range instead (e.g. 192.168.156.x is better). The second trick is I configured my Adblock plugin in my primary browser to block access to my internal network. And I use another browser whenever I want to access my internal devices. Update: On Firefox you can use NoScript ABE to block access to internal resources.

Check your router configuration:

disable UPnP
check the firewall settings and disable unnecessary port forwards
check for IPv6 settings, and configure the firewall as default deny for incoming IPv6 TCP/UDP.

Change default passwords, especially for services connected to the Internet. Follow password best practices.

Run Nmap to locate new IoT in your home network :)

Run a WiFi scan to locate new WiFi access points. Let me share a personal experience with you. I moved to a new house and brought my own WiFi router with me. I plugged it in, and forget about WiFi. Months later it turned out I had two other WiFi devices in my house - the cable modem had its own integrated WiFi with default passwords printed on the bottom, and the Set-top-box was the same - default WiFi passwords printed on the bottom. And don't forget to scan for ZigBee, Bluetooth, IrDA, FM, ...

Update your devices - in case you have a lot of free time in your hand.

Don't allow your guests to connect to your home network. Set up a separated AP for them. Imagine your nephew stealing your private photos or videos from your NAS or DNLA server.

With great power, comes great responsibility. The less device you own in your house, the less time you need to maintain those.

Read the manuals of your devices. Be aware of the different interfaces. Configure it in a secure way.

Disable Teredo protocol in case you don't need IPv6.

Stop being amazed by junk hacking.

Update: Disable WebRTC: https://www.browserleaks.com/webrtc , in Chrome you can use this extension: https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia

Update: Prevent against DNS rebind attacks via configuring a DNS server which can block internal IP addresses. OpenDNS can block internal IP, but this is not a default option, you have to configure it.

Recommendations for vendors

For vendors, I recommend at least the followings:

Implement security during Software Development LifeCycle
Continuous security testing and bug bounties
Seamless auto-update
Opt-in cloud connectivity

Recommendations for journalists

Stop FUD. Pretty please.

The questions to ask before losing your head

who can exploit the vulnerability?
what prerequisites do we have about the attack to successfully exploit the vulnerability? Is the attacker already in your home network? If yes, you have probably bigger problems.
what can the attacker do when the exploit is successful?

And last but not least, don't forget that in the case of IoT devices, sometimes users are the product, not the customer. IoT is about collecting data for marketing purposes.

http://blog.open-xchange.com/2015/02/09/iot/

miércoles, 22 de abril de 2020

COVID-Themed Lures Target SCADA Sectors With Data Stealing Malware

A new malware campaign has been found using coronavirus-themed lures to strike government and energy sectors in Azerbaijan with remote access trojans (RAT) capable of exfiltrating sensitive documents, keystrokes, passwords, and even images from the webcam. The targeted attacks employ Microsoft Word documents as droppers to deploy a previously unknown Python-based RAT dubbed "PoetRAT" due to

via The Hacker News

OpenVAS

"OpenVAS stands for Open Vulnerability Assessment System and is a network security scanner with associated tools like a graphical user front-end. The core is a server component with a set of network vulnerability tests (NVTs) to detect security problems in remote systems and applications." read more...

Website: http://www.openvas.org

Related word

martes, 21 de abril de 2020

CEH Practical: Gathering Target Information: Reconnaissance And Competitive Intelligence

CEH Exam Objectives:

Describe Reconnaissance.

Describe aggressive/competitive intelligence.

Reconnaissance

Reconnaissance is the process of gathering informative data about a particular target of a malicious hack by exploring the targeted system. Basically two types of Reconnaissance exist i.e. Active and Passive. Active reconnaissance typically related to port scanning and observing the vulnerabilities about the targeted system (i.e., which ports are left vulnerable and/or if there are ways around the firewall and routers). Passive reconnaissance typically you will not be directly connected to a computer system. This process is used to gather essential information without ever interacting with the target systems.

Understand Aggressive Intelligence

Competitive intelligence means information gathering about competitors' products, marketing, and technologies. Most competitive intelligence is non intrusive to the company being investigated and is benign in nature. It's used for product comparison or as a sales and marketing tactic to better understand how competitors are positioning their products or services.

Online tools to gather competitive intelligence

Exercise 1.1

Using KeywordSpy

To use the KeywordSpy online tool to gather competitive intelligence information:

Go to the www.keywordspy.com website and enter the website address of the target in the search field

Review the report and determine valuable keywords, links, or other information.

Exercise 1.2

Using spyfu

Go to your browser and type www.spyfu.com and enter the website address of the target in the search field.

Exercise 1.3

Using the EDGAR Database to Gather Information

1. Determine the company's stock symbol using Google.

2. Open a web browser to www.sec.gov.

3. On the right side of the page, click the link EDGAR Filers.

4. Click the Search For Filings menu and enter the company name or stock symbol to search the filings for information. You can learn, for example, where the company is registered and who reported the filing.

5. Use the Yahoo! yellow pages ( http://yp.yahoo.com ) to see if an address or phone number is listed for any of the employee names you have located.

More info

lunes, 20 de abril de 2020

HOW TO HACK WHATSAPP ACCOUNT? – WHATSAPP HACK

In the last article, I have discussed a method on WhatsApp hack using SpyStealth Premium App. Today I am gonna show you an advanced method to hack WhatsApp account by mac spoofing. It's a bit more complicated than the last method discussed and requires proper attention. It involves the spoofing of the mac address of the target device. Let's move on how to perform the attack.

SO, HOW TO HACK WHATSAPP ACCOUNT?

STEP TO FOLLOW FOR WHATSAPP HACK

Here I will show you complete tutorial step by step of hacking WhatsApp account. Just understand each step carefully so this WhatsApp hack could work great.

Find out the victim's phone and note down it's Mac address. To get the mac address in Android devices, go to Settings > About Phone > Status > Wifi Mac address. And here you'll see the mac address. Just write it somewhere. We'll use it in the upcoming steps.
As you get the target's mac address, you have to change your phone's mac address with the target's mac address. Perform the steps mentioned in this article on how to spoof mac address in android phones.
Now install WhatsApp on your phone and use victim's number while you're creating an account. It'll send a verification code to victim's phone. Just grab the code and enter it here.
Once you do that, it'll set all and you'll get all chats and messages which victims sends or receives.

This method is really a good one but a little difficult for the non-technical users. Only use this method if you're technical skills and have time to perform every step carefully. Otherwise, you can hack WhatsApp account using Spying app.

If you want to know how to be on the safer edge from WhatsApp hack, you can follow this article how to protect WhatsApp from being hacked.

CISA Warns Patched Pulse Secure VPNs Could Still Expose Organizations To Hackers

The United States Cybersecurity and Infrastructure Security Agency (CISA) yesterday issued a fresh advisory alerting organizations to change all their Active Directory credentials as a defense against cyberattacks trying to leverage a known remote code execution (RCE) vulnerability in Pulse Secure VPN servers—even if they have already patched it. The warning comes three months after another

via The Hacker News

Save Your Cloud: Gain Root Access To VMs In OpenNebula 4.6.1

In this post, we show a proof-of-concept attack that gives us root access to a victim's VM in the Cloud Management Platform OpenNebula, which means that we can read and write all its data, install software, etc. The interesting thing about the attack is, that it allows an attacker to bridge the gap between the cloud's high-level web interface and the low-level shell-access to a virtual machine.

Like the latest blogpost of this series, this is a post about an old CSRF- and XSS-vulnerability that dates back to 2014. However, the interesting part is not the vulnerability itself but rather the exploit that we were able to develop for it.

An attacker needs the following information for a successful attack.

ID of the VM to attack
OpenNebula's VM ID is a simple global integer that is increased whenever a VM is instantiated. The attacker may simply guess the ID. Once the attacker can execute JavaScript code in the scope of Sunstone, it is possible to use OpenNebula's API and data structures to retrieve this ID based on the name of the desired VM or its IP address.
Operating system & bootloader
There are various ways to get to know a VMs OS, apart from simply guessing. For example, if the VM runs a publicly accessible web server, the OS of the VM could be leaked in the HTTP-Header Server (see RFC 2616). Another option would be to check the images or the template the VM was created from. Usually, the name and description of an image contains information about the installed OS, especially if the image was imported from a marketplace.
Since most operating systems are shipped with a default bootloader, making a correct guess about a VMs bootloader is feasible. Even if this is not possible, other approaches can be used (see below).
Keyboard layout of the VM's operating system
As with the VMs bootloader, making an educated guess about a VM's keyboard layout is not difficult. For example, it is highly likely that VMs in a company's cloud will use the keyboard layout of the country the company is located in.

Overview of the Attack

The key idea of this attack is that neither Sunstone nor noVNC check whether keyboard related events were caused by human input or if they were generated by a script. This can be exploited so that gaining root access to a VM in OpenNebula requires five steps:

Using CSRF, a persistent XSS payload is deployed.
The XSS payload controls Sunstone's API.
The noVNC window of the VM to attack is loaded into an iFrame.
The VM is restarted using Sunstone's API.
Keystroke-events are simulated in the iFrame to let the bootloader open a root shell.

Figure 1: OpenNebula's Sunstone Interface displaying the terminal of a VM in a noVNC window.

The following sections give detailed information about each step.

Executing Remote Code in Sunstone

In Sunstone, every account can choose a display language. This choice is stored as an account parameter (e.g. for English LANG=en_US). In Sunstone, the value of the LANG parameter is used to construct a <script> tag that loads the corresponding localization script. For English, this creates the following tag:

<script src="locale/en_US/en_US.js?v=4.6.1" type="text/javascript"></script>

Setting the LANG parameter to a different string directly manipulates the path in the script tag. This poses an XSS vulnerability. By setting the LANG parameter to LANG="onerror=alert(1)//, the resulting script tag looks as follows:

<script src="locale/"onerror=alert(1)///"onerror=alert(1)//.js?v=4.6.1" type="text/javascript"></script>

For the web browser, this is a command to fetch the script locale/ from the server. However, this URL points to a folder, not a script. Therefore, what the server returns is no JavaScript. For the browser, this is an error, so the browser executes the JavaScript in the onerror statement: alert(1). The rest of the line (including the second alert(1)) is treated as comment due to the forward slashes.

When a user updates the language setting, the browser sends an XMLHttpRequest of the form

{ "action" : { "perform" : "update", "params" : { "template_raw" : "LANG=\"en_US\"" } }}

to the server (The original request contains more parameters. Since these parameters are irrelevant for the technique, we omitted them for readability.). Forging a request to Sunstone from some other web page via the victim's browser requires a trick since one cannot use an XMLHttpRequest due to restrictions enforced by the browser's Same-Origin-Policy. Nevertheless, using a self-submitting HTML form, the attacker can let the victim's browser issue a POST request that is similar enough to an XMLHttpRequest so that the server accepts it.

An HTML form field like

<input name='deliver' value='attacker' />

is translated to a request in the form of deliver=attacker. To create a request changing the user's language setting to en_US, the HTML form has to look like

<input name='{"action":{"perform":"update","params":{"template_raw":"LANG' value='\"en_US\""}}}' />

Notice that the equals sign in LANG=\"en_US\" is inserted by the browser because of the name=value format.

Figure 2: OpenNebula's Sunstone Interface displaying a user's attributes with the malicious payload in the LANG attribute.

Using this trick, the attacker sets the LANG parameter for the victim's account to "onerror=[remote code]//, where [remote code] is the attacker's exploit code. The attacker can either insert the complete exploit code into this parameter (there is no length limitation) or include code from a server under the attacker's control. Once the user reloads Sunstone, the server delivers HTML code to the client that executes the attacker's exploit.

Prepare Attack on VM

Due to the overwritten language parameter, the victim's browser does not load the localization script that is required for Sunstone to work. Therefore, the attacker achieved code execution, but Sunstone breaks and does not work anymore. For this reason, the attacker needs to set the language back to a working value (e.g. en_US) and reload the page in an iFrame. This way Sunstone is working again in the iFrame, but the attacker can control the iFrame from the outside. In addition, the attack code needs to disable a watchdog timer outside the iFrame that checks whether Sunstone is correctly initialized.

From this point on, the attacker can use the Sunstone API with the privileges of the victim. This way, the attacker can gather all required information like OpenNebula's internal VM ID and the keyboard layout of the VM's operating system from Sunstone's data-structures based on the name or the IP address of the desired VM.

Compromising a VM

Using the Sunstone API the attacker can issue a command to open a VNC connection. However, this command calls window.open, which opens a new browser window that the attacker cannot control. To circumvent this restriction, the attacker can overwrite window.open with a function that creates an iFrame under the attacker's control.

Once the noVNC-iFrame has loaded, the attacker can send keystrokes to the VM using the dispatchEvent function. Keystrokes on character keys can be simulated using keypress events. Keystrokes on special keys (Enter, Tab, etc.) have to be simulated using pairs of keydown and keyup events since noVNC filters keypress events on special keys.

Getting Root Access to VM

To get root access to a VM the attacker can reboot a victim's VM using the Sunstone API and then control the VM's bootloader by interrupting it with keystrokes. Once the attacker can inject commands into the bootloader, it is possible to use recovery options or the single user mode of Linux based operating systems to get a shell with root privileges. The hardest part with this attack is to get the timing right. Usually, one only has a few seconds to interrupt a bootloader. However, if the attacker uses the hard reboot feature, which instantly resets the VM without shutting it down gracefully, the time between the reboot command and the interrupting keystroke can be roughly estimated.

Even if the bootloader is unknown, it is possible to use a try-and-error approach. Since the variety of bootloaders is small, one can try for one particular bootloader and reset the machine if the attack was unsuccessful. Alternatively, one can capture a screenshot of the noVNC canvas of the VM a few seconds after resetting the VM and determine the bootloader.

A video of the attack can be seen here. The browser on the right hand side shows the victim's actions. A second browser on the left hand side shows what is happening in OpenNebula. The console window on the bottom right shows that there is no user-made keyboard input while the attack is happening.