Mobile Hacking Part 3: Intro to USB Rubber Ducky for Keystroke Injection
Welcome back hackers! Today we’re going to be continuing our mobile hacking series with the introduction of some special equipment. We’re going to be setting up and making a payload for the USB rubber ducky.
The USB rubber ducky is a small USB device that will act as a keyboard when plugged into a PC. This allows us to inject whatever keystrokes we want into the victim PC in a matter of seconds. As a starter, since it’s our first time using the USB rubber ducky here, we’ll be making a payload that will write a fork bomb in Python and execute it. So, let’s get started!
Step 1: Unpacking and Setting up
Once you have your rubber ducky unboxed and ready to go, it should look something like this:
That micro SD card comes pre-formatted in FAT16 with a single file named inject.bin. It’s important that you take the micro SD card out of the rubber ducky and mount it using a micro SD to USB adapter, so we can write our own payload to it instead of using the default one. We can make sure its detected by the system using fdisk:
Alright, our micro SD card is good to go, now it’s time to make our payload.
Step 2: Writing and Encoding the Payload
The USB rubber ducky has a simple syntax format for writing payloads. This syntax includes the ability to type strings, delay for a given time, and use special keys (like CTRL, ALT, or the Windows key). Let’s take a look at our payload (note that REM is for making comments):
This payload will open xterm (a terminal program) and write a Python script that will forever call os.fork(), eventually crashing the system (this is a fork bomb). After the payload is written, it will be executed. Now that we have our payload, we need to encode it into the binary format that the rubber ducky understands. For this we’ll need to use the encoder provided by Hak5. We’ll start by downloading the encoder using git clone, when we’ll move into the encoder’s directory:
Now that we have the encoder downloaded, we can use it to create the binary we need. After browsing the help page, we can compile our payload:
We now have the binary payload we need. We just need to delete the one that comes on the micro SD card by default and copy ours to it, once that’s complete our rubber ducky should be ready:
Our USB rubber ducky should be ready now. I was unable to capture a screenshot of it in action though, as it crashed my PC. But, test it out for yourself! We’ll be seeing much more of both the USB rubber ducky and the Bash Bunny in later articles, but this was just an introduction to the concepts. Next time we’ll do something a bit more useful, such as downloading and executing a payload.
FREAK Vulnerability : SSL/TLS Vulnerability to Exploit Apple and Android
FREAK Vulnerability : Android Penetration Testing a Must now .
The Freak Vulnerability leave Android and Apple users Unsecured . This is a Vulnerability in SSL/TLS that is not new and has left the Android and Apple users open to exploitation via MITM(Man in the middle attack) . The Freak Vulnerability leaves the Apple and Android users exposed to MITM and any secure traffic is completely to the exposure of the Hacker .
Freak Vulnerability is widespread and disastrous SSL/TLS vulnerability and has been uncovered for over a decade left Millions of users of Apple and Android devices vulnerable to man-in-the-middle attacks on encrypted traffic when they visited supposedly ‘secured’ websites, including the official websites of the White House, FBI and National Security Agency.
CVE-2015-0204
Dubbed the “FREAK” vulnerability (CVE-2015-0204) – also known as Factoring Attack on RSA-EXPORT Keys – enables hackers or intelligence agencies to force clients to use older, weaker encryption i.e. also known as the export-grade key or 512-bit RSA keys.
The FREAK vulnerability discovered by security researchers of French Institute for Research in Computer Science and Automation (Inria) and Microsoft, resides in OpenSSL versions 1.01k and earlier, and Apple’s Secure Transport.
Freak Vulnerability : From Penetration Testers View
How Freak Vulnerability Works ! (The very technical Description of the Freak Vulnerability)
- In the client’s Hello message, it asks for a standard ‘RSA’ ciphersuite.
- The MITM attacker changes this message to ask for ‘export RSA’.
- The server responds with a 512-bit export RSA key, signed with its long-term key.
- The client accepts this weak key due to the OpenSSL/Secure Transport bug.
- The attacker factors the RSA modulus to recover the corresponding RSA decryption key.
- When the client encrypts the ‘pre-master secret’ to the server, the attacker can now decrypt it to recover the TLS ‘master secret’.
- From here on out, the attacker sees plain text and can inject anything it wants.
Who is Vulnerable to Freak ?
The FREAK attack is possible when a vulnerable browser connects to a susceptible web server—a server that accepts “export-grade” encryption.
Servers
Servers that accept RSA_EXPORT cipher suites put their users at risk from the FREAK attack. Using Internet-wide scanning, we have been performing daily tests of all HTTPS servers at public IP addresses to determine whether they allow this weakened encryption. More than a third of all servers with browser-trusted certificates are at risk.
Clients
Browsers are vulnerable to the FREAK attack because of bugs that allow an attacker to force them to use weak, export-grade encryption. Far more browsers are vulnerable to the FREAK attack than was initially thought when the attack was announced. The client side bugs can also be identified via the penetration testing of the clients browser for Freak Vulnerability.
Remediation from Freak Vulnerability
On the Server Side
You should immediately disable support for TLS export cipher suites. While you’re at it, you should also disable other cipher suites that are known to be insecure and enable forward secrecy. For instructions on how to secure popular HTTPS server software, we recommend Mozilla’s security configuration guide and their SSL configuration generator.
On the Client Side (Browser)
Make sure you have the most recent version of your browser installed, and check for updates frequently. Updates that fix the FREAK attack should be available for all major browsers soon.
For SysAdmins and Developers
TLS libraries must be up to date. Unpatched OpenSSL , Microsoft Schannel , and Apple SecureTransport all suffer from the vulnerability. Note that these libraries are used internally by many other programs, such as wget and curl. You also need to ensure that your software does not offer export cipher suites, even as a last resort, since they can be exploited even if the TLS library is patched.
Secret Hack Codes for Apple Iphone 5, 5C, 5S, 6, 6 Plus
Hello Friends, today i am going to share several secret hack codes for Apple Iphone 5, 5C, 5S, 6 and 6 Plus. These iphone hack codes will help you to hack iphone mobiles and help you to explore more about your apple iPhone.
Secret Hack codes are those codes which are usually hidden from users for any misuse and exploit. As we all know Apple Iphone is very secured platform and thus very few hack codes of apple iphone are there on internet. Today i am sharing all the hack codes of apple iphone cellphones that i am aware of. And i surely hope you can’t find codes better than that. So friends let’s hack and explore our apple Iphone and tabs. I have tested these codes on my Apple Iphone 5S and friends iphone 6 plus. I am sure these will work on all previous apple iphones too.
Secret Hacking codes for Apple IPhone Mobile Phones:
1. Entering into Field Mode : Field mode contains lots of iPhone inner settings, especially newest network and cell information.
*3001#12345#* and tap Call
2. IMEI Number : Shows your IMEI. No need to tap Call. IMEI is the unique identifier for your mobile phone hardware.
*#06#
3. Call Forward Settings and Insights : Set interrogation for call forwards. Discover the settings for your call forwarding. You’ll see whether you have voice, data, fax, SMS, sync, async, packet access, and pad access call forwarding enabled or disabled.
*#21# and tap Call
4. Calling Line Presentation : This shows whether you have enabled or disabled the presentation of the calling line, presumably the number of the party placing the call.
*#30# and tap Call
5. Call Waiting Settings : Determine if call waiting is enabled. Shows call waiting status for voice, data, fax, SMS, sync data, async data, packet access and pad access. Each item is either enabled or disabled.
*#43# and tap Call
6. Check all Unanswered Calls : Check the number for unanswered calls. Show the number for voice call forwarding when a call is unanswered. Also show the options for data, fax, SMS, sync, async, packet access and pad access.
*#61# and tap Call
7. Check the number for call forwarding if no service is available. Just like the previous, except for no-service rather than no-answer situations.
*#62# and tap Call
8. Check the number for call forwarding when the iPhone is busy. And again, but for when the iPhone is busy.
*#67# and tap Call
9. Call Control Bars : Check all the usual suspects ( voice, data, fax,SMS, etc ) to see whether barring is enabled or disabled for outgoing.
*#33# and tap Call
10. Disable Call Forwarding : This code disable all call Forwading.
##002#
11. Code to Hide your Number :
*#31#
That’s all guys. Some of them might be operator specific i.e. works for prepaid phones only. But all codes deserves and try. Check these codes and let us know what all works for you. Hope you guys enjoyed new set of secret hack codes.
Apple releases patched versions of iOS and OS X
Apple releases patched versions of iOS and OS X , both of which include a significant number of security patches, several for bugs that can lead to remote code execution and other serious issues.
Version 8.4 of iOS contains fixes for more than 30 security vulnerabilities, including bugs in the iOS kernel, WebKit, and CoreText. Apple also patched the vulnerability that leads to the Logjam attack, an issue with servers that support weak Diffie-Hellman cryptography. To fix that issue in iOS, Apple released a patch for the coreTLS component of the operating system.
“coreTLS accepted short ephemeral Diffie-Hellman (DH) keys, as used in export-strength ephemeral DH cipher suites. This issue, also known as Logjam, allowed an attacker with a privileged network position to downgrade security to 512-bit DH if the server supported an export-strength ephemeral DH cipher suite. The issue was addressed by increasing the default minimum size allowed for DH ephemeral keys to 768 bits,” the Apple advisory says.
Apple also patched an interesting bug that involved the way that iOS handles payloads from SIM cards. The vulnerability could allow an attacker to craft a malicious SIM card that could give him code execution on a target device.
Among the other vulnerabilities addressed in iOS 8.4 are a number of WebKit bugs, some of which could lead to arbitrary code execution. The code execution flaws include a pair of memory corruption vulnerabilities in WebKit, and an issue with the way the framework handled some SQL functions.
“An insufficient comparison issue existed in SQLite authorizer which allowed invocation of arbitrary SQL functions. This issue was addressed with improved authorization checks,” the Apple advisory says.
There is a patch in the new version of iOS for a bug that could lead to an attacker being able to replace a legitimate app with a malicious one under some conditions. The vulnerability is in the way the OS handles universal provisioning profiles, and could be used to replace system apps such as Apple Pay. Researchers at FireEye discovered the vulnerability and reported it to Apple almost a year ago.
“Manifest Masque Attack leverages the CVE-2015-3722/3725 vulnerability to demolish an existing app on iOS when a victim installs an in-house iOS app wirelessly using enterprise provisioning from a website. The demolished app (the attack target) can be either a regular app downloaded from official App Store or even an important system app, such as Apple Watch, Apple Pay, App Store, Safari, Settings, etc. This vulnerability affects all iOS 7.x and iOS 8.x versions prior to iOS 8.4. We first notified Apple of this vulnerability in August 2014,” FireEye’s researchers wrote in an explanation of the bug and its consequences.
As for OS X, Apple patched many of the same bugs that were present in iOS, along with dozens of others, for a total of more than 75 flaws in all. OS X 10.10.4 includes patches for several buffer overflow vulnerabilities in the Intel graphics driver, some of which could lead to code execution. Apple also fixed a number of memory corruption bugs in QuickTime that could be used for code execution.
In both iOS and OS X Apple updated the certificate trust policy to address the CNNIC certificate issue, among other problems.
0 Comments
Thanks for comment.