Saturday, November 19, 2016

The Mirai Bot PlayGround

The IoT (Internet of Things) have been very hot topic in recent times. This has led to invasion of electronics into our daily life at a massive level. More and more innovations are being made every day for IoT. It has also encouraged many Startups and even big players to jump into this Era of creativity to make IoT very flexible for end users. It’s good news that most of the users are adapting to these new products and taking a step into future.
But the real question is, How Secure these products are? How they make you Vulnerable? What extent of your Privacy is Breached? What did Mirai Bot use? .... and many more such questions.

Understanding Mirai Attack Surface:
As per Arbor Networks, the original Mirai botnet (henceforth referred to as ‘the Mirai botnet’, or ‘Mirai’, unless otherwise indicated) currently consists of a floating population of approximately 500,000 compromised IoT devices worldwide; relatively high concentrations of Mirai nodes have been observed in China, Hong Kong, Macau, Vietnam, Taiwan, South Korea, Thailand, Indonesia, Brazil, and Spain.  Additional Mirai concentrations have been also been observed in multiple countries located in North America, Europe, and Oceania.
Mirai is capable of launching multiple types of DDoS attacks, including SYN-flooding, UDP flooding, Valve Source Engine (VSE) query-flooding, GRE-flooding, ACK-flooding (including a variant intended to defeat intelligent DDoS mitigation systems, or IDMSes), pseudo-random DNS label-prepending attacks (also known as DNS ‘Water Torture’ attacks), HTTP GET attacks, HTTP POST attacks, and HTTP HEAD attacks.  While none of the DDoS attack capabilities of Mirai observed to date are new or unique, it is a flexible DDoS attack generation system and can launch high-volume, non-trivial DDoS attacks when wielded by a capable attacker.  Mirai features segmented command-and-control, which allows the botnet to launch simultaneous DDoS attacks against multiple, unrelated targets.

Mitigating Factors: The DDoS attack capabilities of Mirai which have been observed to date are well-known and can be successfully mitigated by implementing industry-standard Best Current Practices (BCPs) and by utilizing intelligent DDoS mitigation systems (IDMSes) such as Arbor SP/TMS and APS to defend the targets of these attacks.
It is possible (and recommended) for network operators to actively scan for both vulnerable and compromised IoT devices on their networks and the networks of their customers, and then take steps to isolate those devices, notify their legitimate owners of the problem, and urge them to take corrective action.

It is possible (and recommended) for network operators to identify likely compromised IoT devices by detecting and classifying outbound/crossbound TCP/23 and/or TCP/2323 activity originating from these devices, and then take steps to isolate those devices, notify their legitimate owners of the problem, and urge them to take corrective action.
In order to inhibit scanning for vulnerable IoT devices, it is possible for broadband access network operators to implement access-control lists (ACLs) at a situationally-appropriate point in the network topology to prohibit high-port TCP traffic destined for TCP/23 and TCP/2323 on their customer access networks.  Such policies wold typically be implemented as ingress ACLs on the coreward interfaces of broadband customer aggregation gateways.  Operators should gauge the benefits of enforcing a network access policy of this nature vs. potential negative effects, if any, and should thoroughly test any proposed anti-scanning ACLs prior to deployment.

Recommended Actions: All relevant network infrastructure, host/application/service, and DNS Best Current Practices (BCPs) should be implemented by network operators with public-facing network infrastructure and/or Internet properties.
Network operators should export flow telemetry (e.g., NetFlow, IPFIX, s/Flow, cflowd/jflow, Netstream, et. al.) from their peering/transit/customer aggregation edges and Internet data center (IDC) distribution edges to anomaly-detection/traffic visibility systems Arbor SP, which provide the ability to detect, classify, and traceback DDoS attack traffic.
Network operators should make use of DDoS mitigation mechanisms such as source-based remotely-triggered blackholes (S/RTBH), flowspec, and/or intelligent DDoS mitigation systems (IDMSes) such as Arbor TMS and APS in order to mitigate DDoS traffic sourced from Mirai-based botnets.

Also check below URL for Mirai Bot Scanner:
Source Code for Mirai Bot

Wednesday, June 29, 2016

Google Vulnerable to Open Redirect

Open Redirect via GET URL

Relative Risk Medium
Vulnerability Class User Input Handling Trusted redirect
CVSS 6.3

The value of this “url” parameter is not validated by the application which allows an attacker to specify any arbitrary URL as a value to “url” parameter. This leads to open redirect.
URL redirection vulnerability with which an attacker can redirect victim users to the malicious url.
The Below 31 Links of Google is Vulnerable to Open Redirect. #10 (User Must beLogged Out) (User Must beLogged Out)

Business Impact:
An attacker can send a URL containing payload which will redirect victim to the attacker’s controlled malicious website. The end user may be subjected to a phishing attack by being redirected to an untrusted page. The later attack is more convincing than the traditional phishing attack because the generated URL will point to and not to look-alike domain name.

Application must validate the user controlled parameter “url” to ensure that it do not contain any third party domain URL. Additionally, the application should append the value of “url” parameter to static string or any of the Google sub-domain so that the resultant URL will always point to the same website irrespective of user input.

NOTE: This is not a false positive by bug; an attacker may generate this bug/vulnerability again and again. In this case it is not necessary that user must be logged in, an attacker can send this link to the respective user and may subject Open Redirect. No Automated Tools were Run to Harm the Server.

Crredits: Dhiraj Mishra, Security Researcher

Monday, May 30, 2016

Hangout iOS – Insecure Local Storage

Here is another example of Insecure Local Storage in Hangout iOS application. We have seen in 2015 that most of the mobile app developers have poor coding practices, but this was not expected from Google. A security giant with poor coding practices and moreover irrelevant response to Responsible Bug disclosed by security researcher Saurabh Mishra.
What went wrong with the Hangout iOS app?
Saurabh was testing the hangout app and during local storage check he came across few interesting findings. The details are as follows:
Vulnerability type: Insecure Data Storage

While pen testing the "Hangout" iOS app, Saurabh was digging out the local storage; sqlite files. There it was observed that to make the app more faster, the developer had created a local dbase of conversations, but think they fail to properly encrypt the messages leaving the privacy of users at risk.
Under GBMChatDataStore.sqlite there were 2 tables:
  • Conversations
  • Events

So the researcher was trying to find out the messages and found it in table "events" there was a column named "events_event_data". Guess what, it contained cleartext messages,  along with the information of sender's & recipient user's id. 

Fig 1: Shows UserID of Sender and Receiver
Fig 2: Shows Cleartext User Conversations

When the researcher did responsible bug disclosure to Google Security Team, the response was more interesting showing ignorance. Stephan from Google Security Team says, “First of all, jail broken devices are out of the scope of our vulnerability reward program - if any permission checks of the OS can be bypassed then there's not much we can do.
So is there some way to read this file on a non-jailbroken device? I assume that file/folder won't be accessible by other apps on the device, so there's no way an attacker could get access to it.”

Seems Google Team is not aware/updated about the Malware which infects iOS device without Jailbreak.
In March 2016, “AceDeceiver is the first iOS malware we’ve seen that abuses certain design flaws in Apple’s DRM protection mechanism – namely FairPlay – to install malicious apps on iOS devices regardless of whether they are jailbroken,” Palo Alto Networks explained.

Well Google Security Team needs to stay updated J
Research Credits: Saurabh Mishra, iOS Researcher/Bug Hunter/Speaker/Pentester