1ND14N H4X0R5 T34M (IHT) JAI HIND JAI BHARAT

We are :- DeadManINDIA,Null_Port_Govind,Haxor Rahul,EagleShadow,Karate-Katrina,Spy-Hunter,Grey-Noob,Mr.R@66!T.

A big Slute to Our Indian Armies

Freedom is not free Our Soldiers Donates theirs lifes for us

We are Indians and We are Proud to be Indians

India is great.Because their is one place in the world where Peoples Recpect all Religious.

Kali is good OS for Hacking

Peoples Says this OS is best This OS is best but no one OS like Kali Linux .

MOM and DAD

I can't saw God but When i see my MOM and DAD then i think God in there they are My Gods Love You MOM DAD.

Tuesday, 25 March 2014

Sim-Cloning tut

09:34    No comments

1. Buy a Sim card Reader
2.Need a Blank sim card or super sim card
3.Download Magicsim at http://www.magicsim.com/en/multi-sim.asp? new_id=6
4. Download http://www.filecart.com/Windows/System-Utilities/Backup-Restore/USB-SIM-Card-Reader- Software_1711_1.html
5. Install programs.
6. go in phone tools, select sim card, then select unlock sim, it will promt for a code.
7 call network provider, they will ask for your phone number, your account info, name and security code,
then they will ask why you want to unlock your simcard, just tell them you need to unlock your sim to get it
to work with your overseas phone or something.
8. Once they give you the sim unlock code, enter it, and it will say sim unlocked.
9. remove the sim from your phone, place it in the cardreader, click read from card in magic sim program.
10. once it says connected, select crack sim in the toolbar. click strong ki and clink all of the other find options and then click start.
11. Once your ki is found and the crack is finished, click file, save as and save your cracked sim info to a that file.
12. IMPORTANT!!! you must click disconnect from the file menu or you will ruin your simcard. once it says
disconnected, remove the sim. put it in your phone and see if it still works, it should. if not, you either did not unlock your sim, or you tried to copy it instead of crack and save.
13. insert black 3g card Use other program, not magic sim at this point.
14. click connect
15. it will say no info found if it is truly blank.
16. select write to sim, it will promt you to select a dat file, select the one you saved before, now click start, it will take about 10 minutes to write it, once it is complete, it will ask for a security code, enter the security code network provider gave you, then click finish.
17. your card is cloned. if you try to make 2 calls at the same time, one will go through, the other will say call failed, and both phones will get the same messages, text and voice, and both will recieve the same calls, but only one can talk at a time.

Read More

Remote Code Execution (RCE)

08:50    No comments

Remote Code Execution (RCE)
I'm going to demonstrate you the Remote Code Execution vulnerability.

The main reason of this vulnerability is taking the un-filtered user input as a part of the command that will be executed.
Injection vulnerabilities (SQL, XPath, LDAP etc.) can be classified as RCE Vulnerabilities.

For example our source code will be like this;

PHP Code:
<?php <html>
<a href="?cmd=echo %TIME%">View Time</a><br>
<? if(isset($_GET['cmd'])) print "<b>Current Time: </b> " . shell_exec($_GET['cmd']); ?></html> 
[Image: puuwl.png]

As you can see, our page is executing a MS-DOS command to view the current time.
Note: This is not necessary actually. We can simply use the date() function of Php to view the current time.

Back to our subject. There is a parameter named "cmd" that takes its value via GET method. As you can guess, we can manipulate that parameter and execute any MS-DOS command we like.
Image has been scaled down 16% (676x202). Click this bar to view original image (799x238). Click image to open in new window.
[Image: puvcz.png]


We just gathered information about BIOS. Imagine how many you can do with this vulnerability if the user had full access.

(07-05-2013 02:32 AM)The Alchemist Wrote:  Another form of this vulnerability can be :
Code:
<form action="add.php" method="post">
<textarea rows="20" cols="30" name="text"></textarea>
<input type="submit" value="Submit" name="sub"/>
</form>

add.php :
PHP Code:
<?phpif(!empty($_POST['text']))
{
    $hand = fopen("some.php","a");
    fwrite($hand,$_POST['text']);
    fclose($hand);
}?>

And when someone executes some.php.....

Another example:
Code:
<form action="#" method="POST">
<b>Enter your name:</b><br>
<input type="text" name="name"><br>
<input type="submit" value="Send"><br>
<br>
</form>
<?php
if(!empty($_POST['name'])){
$filename = "some.shtml";
$file = fopen($filename, 'w') or die ("File couldn't opened!");
$text = "Hello ".$_POST['name']."!";
fwrite($file, $text);
fclose($file);
print '<a href="some.shtml">Click Here To Go!</a>';
}
?>

If you put in name field a SSI command, It'll be saved to some.shtml and will be executed when you open it.

More example;
(07-05-2013 08:54 PM)shp0ngl3 Wrote:  This is a nifty little vuln with possible severe outcome if in wrong hands. I've seen several ping services that's vulnerable to this.

I've seen code similar to this
Code:
<?php
$target = $_POST['target'];
exec("ping {$target}", $output);
foreach ($output as $line) {
    echo "{$line}<br />\n";
}

So, executing commands is as easy as in your own terminal
Code:
-c 0 google.com;ls -la /
or
Code:
-c 1 google.com && ls -la /

This is the logic of Remote Code Execution. To avoid this vulnerability, dont use the user input in your commands that will be execute. If you have to use, check and filter them properly.

I hope you'll like this tutorial Smile

Read More

Monday, 24 March 2014

Bypassing AirWatch Root Restriction

11:59    2 comments

Mobile devices are becoming more common in corporate environments. As a result, mobile device management solutions (MDM) have cropped up so that employers can remotely manage and wipe devices if necessary along with setting certain requirements that employees must comply with, such as setting a passcode, encrypting the device, and not jailbreaking or rooting the device. It’s certainly not a bad idea to enforce restrictions on devices that may contain sensitive information. However, bypassing some of the restrictions that an employer may put in place it not difficult. This is especially true if someone wants to keep their device rooted.  There are many contenders in the sphere of MDM software. For this blog I will be looking at AirWatch for Android. The device I will be using is a rooted Nexus 4 running Android 4.2.2.
[Note Update at End of Post - 09.13.13]

Background

AirWatch is an MDM solution that provides employers with the ability to manage mobile devices and enforce policies. An agent is installed on the device and monitors whether the device is compliant or not for specific policies. If a device is found to be non-compliant, the agent phones home to a server, notifying the employer of a non-compliant device.

Here is the default web interface for an AirWatch enrolled device. As you can see, my Nexus 4 is enrolled, is encrypted, and requires a passcode. However, it is still not compliant because my device has been “compromised,” i.e. rooted by myself. A poor word choice in my opinion. The same can be seen on the AirWatch agent.


If we navigate to the compliance section, we can see why we are not compliant.

Again, the agent shows that we are encrypted, but our device is “compromised.”

Digging Deeper

At this point I want to know how AirWatch is detecting that my phone is rooted. I tried removing the su binary and any superuser applications, but that didn’t seem to work. As a rooted phone, we can certainly grab the apk of the agent and tear it apart. That only revealed obfuscated java classes that would take a while to decipher. Next, I tried running strace against the agent process to get an idea of the calls that it is making, hoping that there would be something there that reveals what it is doing to detect root. Again, there weren’t any answers that I could find.

I decided to shelve looking for how AirWatch was detecting root for another day and instead I started focusing on the HTTP request and responses that the agent was sending and receiving. I started burp and setup a proxy on my Nexus 4. There is a fair amount of traffic that goes between the AirWatch agent and the server it’s talking to. One request in particular caught my eye.

This AirWatchBeacon checkin request. I omitted some of the more sensitive information in the request. As you can see there is an “IsCompromised” field in the request that is set as true. So I change that to false and sent the request off. After refreshing the web interface, my device is no longer compromised.

The agent also shows that my device is no longer compromised.

So now we know how the agent is checking into the server and whether or not your device is compromised. By changing a simple flag, we now control that. Furthermore, there doesn't seem to be any type of session information related with the request. We can replay the same request hours, even days later, and the server will accept it. The only downside now is that the agent will periodically do a check-in request with the server and report that the device is compromised. It’s a hassle to send a non-compromised request every time we want to be compliant. The first step I took in resolving this issue was to look at the AirWatch configuration options in its SQLite database.

Using the SQLite Editor app from the Android market, I open up the AirWatch database with root access.

Selecting the AirWatch database reveals a number of interesting tables.

The profileGroupSetting table is where most of the AirWatch configurations are stored.

There are a few rows that look interesting. The ones that contain interval in the name seem to set how often the AirWatch requests are sent. I tried changing the BeaconInterval to large values to see if it would take longer for the check in requests to be sent. That didn't seem to work. Neither did setting the value to zero or a negative value. For the most part, setting the interval values do not seem to do anything in my testing.

There is, however, another way to stop AirWatch from sending out request. Modifying the Android hosts file to block the host that the requests are being sent to. The Android hosts file is located in /system/etc/. Again, you have to be root to be able to modify the hosts file. I modified the hosts file to redirect the requested host to my localhost. The requested host is going to be different for every company, so I won’t be showing that. It’s been well over a week and my device has still not checked in and still shows that I’m compliant.

The only downside to not checking in often is that your device will show as not being seen for sometime. You employer may have a policy in place to remove devices that AirWatch shows as being inactive. One way to mitigate this is to periodically send out the checkin request yourself. Simply setting up a cronjob with curl to send out the checkin request work very well.
#!/bin/bash
 
curl -X POST -d @request https://host/DeviceServices/AirWatchBeacon.svc/checkin -H "Content-Type: application/json" -H "User-Agent: AirWatch Agent/4.0.401/Android/4.2.2" -H "Host: host"


Here is the json POST request data the curl command uses for –d @request:

{"payLoad":{"FriendlyName":"Android_sdNexus 4_353918050698915","Model":"Nexus 4","CustomerLocationGroupRef":"YourGroup","PhoneNumber":"1111111111","DeviceType":5,"C2dmToken":"APA91bHcoJnegJy23fPaa2Fg2miP0vJEuC9aVcAw9iuwKb8AQcnzr7OyiXShrJSGD_AajBPUwuSm4Y_gcuz3ibnnjfbfpkLnAnoF599IM2yZhTVaUq0XWLKFfNP11oYzIavq4OjTO5DH4y3XpkvWmQBD16qkFJEg1BFFuOA2y1SJo6aE2yILIIo","IsCompromised":"false","OsVersion":"4.2.2","SerialNumber":"1111111111","Name":"Google occam","MacAddress":"ff:ff:ff:ff:ff:ff","DeviceIdentifier":"11111111111111","AWVersion":"4.0.401","TransactionIdentifier":"a8098ea5-a54e-412f-a911-a58920a24dc7"}}

Finally add the bash script to your crontab by running “crontab –e” to edit the crontab and add the following at the end of the file:

0 */2 * * * /root/command.sh

This will cause the script to run every two hours.  Conclusion
MDM solutions are great for employers to manage mobile devices. However, they are not without their problems. Not only was I able to bypass compliance for having a rooted device, but I was also able to bypass the need to encrypt my device from the profileGroupSetting table. Bypassing compliance restrictions for AirWatch is relatively trivial after a few hours and I’m sure it is probably similar with many others MDM solutions.

Read More
Subscribe to: Posts (Atom)