Indian Education

Thursday, May 21, 2020

Group Instant Messaging: Why Blaming Developers Is Not Fair But Enhancing The Protocols Would Be Appropriate

After presenting our work at Real World Crypto 2018 [1] and seeing the enormous press coverage, we want to get two things straight: 1. Most described weaknesses are only exploitable by the malicious server or by knowing a large secret number and thereby the protocols are still very secure (what we wrote in the paper but some newspapers did not adopt) and 2. we see ways to enhance the WhatsApp protocol without breaking its features.

We are of course very happy that our research reached so many people and even though IT security and cryptography are often hard to understand for outsiders, Andy Greenberg [2], Patrick Beuth [3] and other journalists [4,5,6,7,8] wrote articles that were understandable on the one hand and very accurate and precise on the other hand. In contrast to this, we also saw some inaccurate articles [9,10] that fanned fear and greatly diverged in their description from what we wrote in our paper. We expected this from the boulevard press in Germany and therefore asked them to stick to the facts when they were contacting us. But none of the worst two articles' [9,10] authors contacted us in advance. Since our aim was never to blame any application or protocol but rather we wanted to encourage the developers to enhance the protocols, it contradicts our aim that WhatsApp and Signal are partially declared attackable by "anyone" "easily" [9,10].

Against this background, we understand Moxie's vexation about certain headlines that were on the Internet in the last days [11]. However, we believe that the ones who understand the weaknesses, comprehend that only the malicious server can detectably make use of them (in WhatsApp) or the secret group ID needs to be obtained from a member (in Signal). As such, we want to make clear that our paper does not primarily focus on the description of weaknesses but presents a new approach for analyzing and evaluating the security of group instant messaging protocols. Further we propose measures to enhance the analyzed protocols. The description of the protocols' weaknesses is only one part of the evaluation of our analysis approach and thereby of the investigation of real world protocols. This is the scientific contribution of our paper. The practical contribution of the analyzed messengers, which is the communication confidentiality for billion users (in most cases), is great and should be noted. Therefore we believe that being Signal, WhatsApp, or Threema by applying encryption to all messages and consequently risking research with negative results is much better than being a messenger that does not encrypt group messages end-to-end at all. We do not want to blame messengers that are far less secure (read Moxie's post [11] if you are interested).

Finally we want note that applying security measures according to the ticket approach (as we call it in the paper [12]) to the invitation links would solve the issues that Facebook's security head mentioned in his reply [13] on our findings. To our knowledge, adding authenticity to group update messages would not affect invitation links: If no invitation link was generated for a group, group members should only accept joining users if they were added by an authentic group update message. As soon as a group invitation link was generated, all joining users would need to be accepted as new group members with the current design. However there are plenty ways how WhatsApp could use invitation links without endowing the server with the power to manage groups without the group admins' permission:
One approach would be generating the invitation links secretly and sharing them without the knowledge of the server. An invitation link could then contain a secret ticket for the group and the ID of the group. As soon as a user, who received the link, wants to join the group, she can request the server with the group ID to obtain all current group members. The secret ticket can now be sent to all existing group members encrypted such that the legitimate join can be verified.

Of course this would require engineering but the capability of WhatsApp, shipping drastic protocol updates, can be assumed since they applied end-to-end encryption in the first place.

[1] https://www.youtube.com/watch?v=i5i38WlHfds
[2] https://www.wired.com/story/whatsapp-security-flaws-encryption-group-chats/
[3] http://www.spiegel.de/netzwelt/apps/whatsapp-gruppenchats-schwachstelle-im-verschluesselungs-protokoll-a-1187338.html
[4] http://www.sueddeutsche.de/digital/it-sicherheit-wie-fremde-sich-in-whatsapp-gruppenchats-einladen-koennen-1.3821656
[5] https://techcrunch.com/2018/01/10/security-researchers-flag-invite-bug-in-whatsapp-group-chats/
[6] http://www.telegraph.co.uk/technology/2018/01/10/whatsapp-bug-raises-questions-group-message-privacy/
[7] http://www.handelsblatt.com/technik/it-internet/verschluesselung-umgangen-forscher-finden-sicherheitsluecke-bei-whatsapp/20836518.html
[8] https://www.heise.de/security/meldung/WhatsApp-und-Signal-Forscher-beschreiben-Schwaechen-verschluesselter-Gruppenchats-3942046.html
[9] https://www.theinquirer.net/inquirer/news/3024215/whatsapp-bug-lets-anyone-easily-infiltrate-private-group-chats
[10] http://www.dailymail.co.uk/sciencetech/article-5257713/WhatsApp-security-flaw-lets-spy-private-chats.html
[11] https://news.ycombinator.com/item?id=16117487
[12] https://eprint.iacr.org/2017/713.pdf
[13] https://twitter.com/alexstamos/status/951169036947107840

Further articles:
- Matthew Green's blog post: https://blog.cryptographyengineering.com/2018/01/10/attack-of-the-week-group-messaging-in-whatsapp-and-signal/
- Schneier on Security: https://www.schneier.com/blog/archives/2018/01/whatsapp_vulner.html
- Bild: http://www.bild.de/digital/smartphone-und-tablet/whatsapp/whatsapp-sicherheitsluecke-in-gruppenchats-54452080.bild.html
- Sun: https://www.thesun.co.uk/tech/5316110/new-whatsapp-bug-how-to-stay-safe/

Continue reading

Wednesday, May 20, 2020

Voodoo-Kali - Kali Linux Desktop On Windows 10

How it works?
* Kali Linux with XFCE Desktop Environment in Windows Subsystem for Linux (WSL)
* VcXsrv X Server for Windows is doing the hard GUI lifting
* XFCE is started natively in WSL and displayed by VcXsrv

Install Voodoo-Kali:
1, Enable WSL and install Kali Linux from the Microsoft Store. Read Install Kali Linux desktop on Windows 10 from Microsoft Store

2, To start Kali Linux in Windows 10, open Command Prompt and enter the command: kali

3, Enter this commands:
  apt install wget -y
  wget https://raw.githubusercontent.com/Re4son/WSL-Kali-X/master/install-WSL-Kali-X
  bash ./install-WSL-Kali-X

4, Download and install VcXsrv Windows X Server from SourceForge

5, Start VcXsrv, accept change in firewall rules, exit VcXsrv

Run Voodoo-Kali:
Start kali in Windows as normal user (that's default), and launch Voodoo-Kali:
* as normal user: ./start-xfce
* as root: sudo /root/xtart-xfce

Run Kali Desktop in an RDP session:
In Kali Linux WSL, type: sudo /etc/init.d/xrdp start
In Windows 10, open Run and enter mstsc.exe and connect to "127.0.0.1:3390"

Status: Voodoo-Kali is in its infancy and it is far from being elegant. I'm working on it though and step by step I'll push out improvements. Below a snippet of the To-Do list:
* Clean up and comment the scripts
* Make for a cleaner exit
* Better error handling and dependency checking (get rid of sleep, etc.)
* Improve stability of Java programs
* Improve the looks??
* …

Any help is truly appreciated, in any shape or form – from tips to pull requests.
Why don't you join the forums to discuss?

Further Information:
* Offsec – Kali Linux in the Windows App Store
* MSDN – Windows Subsystem for Linux Overview

Download Voodoo-Kali

Blockchain Exploitation Labs - Part 3 Exploiting Integer Overflows And Underflows

In part 1 and 2 we covered re-entrancy and authorization attack scenarios within the Ethereum smart contract environment. In this blog we will cover integer attacks against blockchain decentralized applications (DAPs) coded in Solidity.

Integer Attack Explanation:

An integer overflow and underflow happens when a check on a value is used with an unsigned integer, which either adds or subtracts beyond the limits the variable can hold. If you remember back to your computer science class each variable type can hold up to a certain value length. You will also remember some variable types only hold positive numbers while others hold positive and negative numbers.

If you go outside of the constraints of the number type you are using it may handle things in different ways such as an error condition or perhaps cutting the number off at the maximum or minimum value.

In the Solidity language for Ethereum when we reach values past what our variable can hold it in turn wraps back around to a number it understands. So for example if we have a variable that can only hold a 2 digit number when we hit 99 and go past it, we will end up with 00. Inversely if we had 00 and we subtracted 1 we would end up with 99.

Normally in your math class the following would be true:

99 + 1 = 100
00 - 1 = -1

In solidity with unsigned numbers the following is true:

99 + 1 = 00
00 - 1 = 99

So the issue lies with the assumption that a number will fail or provide a correct value in mathematical calculations when indeed it does not. So comparing a variable with a require statement is not sufficiently accurate after performing a mathematical operation that does not check for safe values.

That comparison may very well be comparing the output of an over/under flowed value and be completely meaningless. The Require statement may return true, but not based on the actual intended mathematical value. This in turn will lead to an action performed which is beneficial to the attacker for example checking a low value required for a funds validation but then receiving a very high value sent to the attacker after the initial check. Lets go through a few examples.

Simple Example:

Lets say we have the following Require check as an example:
require(balance - withdraw_amount > 0) ;

Now the above statement seems reasonable, if the users balance minus the withdrawal amount is less than 0 then obviously they don't have the money for this transaction correct?

This transaction should fail and produce an error because not enough funds are held within the account for the transaction. But what if we have 5 dollars and we withdraw 6 dollars using the scenario above where we can hold 2 digits with an unsigned integer?

Let's do some math.
5 - 6 = 99

Last I checked 99 is greater than 0 which poses an interesting problem. Our check says we are good to go, but our account balance isn't large enough to cover the transaction. The check will pass because the underflow creates the wrong value which is greater than 0 and more funds then the user has will be transferred out of the account.

Because the following math returns true:
require(99 > 0)

Withdraw Function Vulnerable to an UnderFlow:

The below example snippet of code illustrates a withdraw function with an underflow vulnerability:

function withdraw(uint _amount){

    require(balances[msg.sender] - _amount > 0);
    msg.sender.transfer(_amount);
    balances[msg.sender] -= _amount;

}

In this example the require line checks that the balance is greater then 0 after subtracting the _amount but if the _amount is greater than the balance it will underflow to a value above 0 even though it should fail with a negative number as its true value.

require(balances[msg.sender] - _amount > 0);

It will then send the value of the _amount variable to the recipient without any further checks:

msg.sender.transfer(_amount);

Followed by possibly increasing the value of the senders account with an underflow condition even though it should have been reduced:

balances[msg.sender] -= _amount;

Depending how the Require check and transfer functions are coded the attacker may not lose any funds at all but be able to transfer out large sums of money to other accounts under his control simply by underflowing the require statements which checks the account balance before transferring funds each time.

Transfer Function Vulnerable to a Batch Overflow:

Overflow conditions often happen in situations where you are sending a batched amount of values to recipients. If you are doing an airdrop and have 200 users who are each receiving a large sum of tokens but you check the total sum of all users tokens against the total funds it may trigger an overflow. The logic would compare a smaller value to the total tokens and think you have enough to cover the transaction for example if your integer can only hold 5 digits in length or 00,000 what would happen in the below scenario?

You have 10,000 tokens in your account
You are sending 200 users 499 tokens each
Your total sent is 200*499 or 99,800

The above scenario would fail as it should since we have 10,000 tokens and want to send a total of 99,800. But what if we send 500 tokens each? Lets do some more math and see how that changes the outcome.

You have 10,000 tokens in your account
You are sending 200 users 500 tokens each
Your total sent is 200*500 or 100,000
New total is actually 0

This new scenario produces a total that is actually 0 even though each users amount is 500 tokens which may cause issues if a require statement is not handled with safe functions which stop an overflow of a require statement.

Lets take our new numbers and plug them into the below code and see what happens:

1. uint total = _users.length * _tokens;
2. require(balances[msg.sender] >= total);
3. balances[msg.sender] = balances[msg.sender] -total;

4. for(uint i=0; i < users.length; i++){
5. balances[_users[i]] = balances[_users[i]] + _value;

Same statements substituting the variables for our scenarios values:

1. uint total = _200 * 500;
2. require(10,000 >= 0);
3. balances[msg.sender] = 10,000 - 0;

4. for(uint i=0; i < 500; i++){
5. balances[_recievers[i]] = balances[_recievers[i]] + 500;

Batch Overflow Code Explanation:

1: The total variable is 100,000 which becomes 0 due to the 5 digit limit overflow when a 6th digit is hit at 99,999 + 1 = 0. So total now becomes 0.

2: This line checks if the users balance is high enough to cover the total value to be sent which in this case is 0 so 10,000 is more then enough to cover a 0 total and this check passes due to the overflow.

3: This line deducts the total from the senders balance which does nothing since the total of 10,000 - 0 is 10,000. The sender has lost no funds.

4-5: This loop iterates over the 200 users who each get 500 tokens and updates the balances of each user individually using the real value of 500 as this does not trigger an overflow condition. Thus sending out 100,000 tokens without reducing the senders balance or triggering an error due to lack of funds. Essentially creating tokens out of thin air.

In this scenario the user retained all of their tokens but was able to distribute 100k tokens across 200 users regardless if they had the proper funds to do so.

Lab Follow Along Time:

We went through what might have been an overwhelming amount of concepts in this chapter regarding over/underflow scenarios now lets do an example lab in the video below to illustrate this point and get a little hands on experience reviewing, writing and exploiting smart contracts. Also note in the blockchain youtube playlist we cover the same concepts from above if you need to hear them rather then read them.

For this lab we will use the Remix browser environment with the current solidity version as of this writing 0.5.12. You can easily adjust the compiler version on Remix to this version as versions update and change frequently.
https://remix.ethereum.org/

Below is a video going through coding your own vulnerable smart contract, the video following that goes through exploiting the code you create and the videos prior to that cover the concepts we covered above:

Download Video Lab Example Code:

Download Sample Code:

CC Labs GitHub

//Underflow Example Code:

//Can you bypass the restriction?

//--------------------------------------------

pragma solidity ^0.5.12;

contract Underflow{
   mapping (address =>uint) balances;

   function contribute() public payable{
        balances[msg.sender] = msg.value;
   }

   function getBalance() view public returns (uint){
return balances[msg.sender];
   }

   function transfer(address _reciever, uint _value) public payable{
   require(balances[msg.sender] - _value >= 5);
   balances[msg.sender] = balances[msg.sender] - _value;

       balances[_reciever] = balances[_reciever] + _value;
   }

}

This next video walks through exploiting the code above, preferably hand coded by you into the remix environment. As the best way to learn is to code it yourself and understand each piece:

Conclusion:

We covered a lot of information at this point and the video series playlist associated with this blog series has additional information and walk throughs. Also other videos as always will be added to this playlist including fixing integer overflows in the code and attacking an actual live Decentralized Blockchain Application. So check out those videos as they are dropped and the current ones, sit back and watch and re-enforce the concepts you learned in this blog and in the previous lab. This is an example from a full set of labs as part of a more comprehensive exploitation course we have been working on.

Related word

CertCrunchy - Just A Silly Recon Tool That Uses Data From SSL Certificates To Find Potential Host Names

It just a silly python script that either retrieves SSL Certificate based data from online sources, currently https://crt.sh/, https://certdb.com/, https://sslmate.com/certspotter/, and https://censys.io or given an IP range it will attempt to extract host information from SSL Certificates. If you want to use Censys.io you need to register for an API key.

How to install

git clone https://github.com/joda32/CertCrunchy.git
cd CertCrunchy
sudo pip3 install -r requirements.txt

How to use it?
Very simply -d to get hostnames for a specific domain
-D to get hostnames for a list of domains (just stuff it in a line-delimited text file)
-I to retrieve and parse certificates from hosts in a netblock / IP range (e.g. 192.168.0.0/24)
-T the thread count makes stuff faster, but don't over do it
-o Output file name
-f Output format CSV or JSON, CSV is the default
for the rest, I'm still working on those :)

API keys and configs
All API keys are stored in the api_keys.py file below is a list of supported APIs requiring API keys.

Censys.oi https://censys.io
VirusTotal https://www.virustotal.com/en/documentation/public-api/

Download CertCrunchy

Tuesday, May 19, 2020

A Quick Guide To Selection Sorting

In this Article I'll tell you about Selection Sort
Selection sort is that type of sorting in which smallest element of a list is searched and then this number is swapped with the first element of the list and then second smallest element is searched in the list and is swapped with the second element of the list and so on i,e this "thingy" thing continues on till n-1 times (where 'n' is the number of terms).
COMPLEXITY:-
Complexity of Selection sort is O(n^2) in best case as well as in worst case.
Well selection sort is not a good sorting algorithm which you can see even from the complexity of selection sort because selection sort performs same number of comparisons even in the best case as in the worst case. Which makes it very slow.
Pseudo-code:-
sort(Arr)
for i = 0 to n-1
smallest = location of smallest number from Arr[i] to Arr[n-1]
swap Arr[i] with Arr[smallest]

/*C Program: Implementation of Selection Sort*/
#include<stdio.h>
void swap(int a[], int i, int j){
    int tmp = a[i];
    a[i] = a[j];
    a[j] = tmp;
}
void selectionSort(int a[], int l, int h){
   for(int i=l; i<h; i++){
     int small = i;
     for(int j=i+1; j<=h; j++){
       if(a[j] < a[i]) small = j;
     }
     swap(a,i,small);
   }
}
int main(void) {
   int arr[10], n;
   printf("Enter Size of Array: ");
   scanf("%d", &n);
   printf("Enter %d elements:\n", n);
   for(int i=0; i<n; i++) scanf("%d", &arr[i]);
   selectionSort(arr, 0, n-1);
   printf("Sorted Array is as:\n");
   for(int i=0; i<n; i++) printf("%d ", arr[i]);
   printf("\n");
   return 0;
}

Ransomware.OSX.KeRanger Samples

Research: New OS X Ransomware KeRanger Infected Transmission BitTorrent Client Installer by Claud Xiao

Sample credit: Claud Xiao

File information

d1ac55a4e610380f0ab239fcc1c5f5a42722e8ee1554cba8074bbae4a5f6dbe1
1d6297e2427f1d00a5b355d6d50809cb
Transmission-2.90.dmg

e3ad733cea9eba29e86610050c1a15592e6c77820927b9edeb77310975393574
56b1d956112b0b7bd3e44f20cf1f2c19
Transmission

31b6adb633cff2a0f34cefd2a218097f3a9a8176c9363cc70fe41fe02af810b9
14a4df1df622562b3bf5bc9a94e6a783
General.rtf

d7d765b1ddd235a57a2d13bd065f293a7469594c7e13ea7700e55501206a09b5
24a8f01cfdc4228b4fc9bb87fedf6eb7
Transmission2.90.dmg

ddc3dbee2a8ea9d8ed93f0843400653a89350612f2914868485476a847c6484a
3151d9a085d14508fa9f10d48afc7016
Transmission

6061a554f5997a43c91f49f8aaf40c80a3f547fc6187bee57cd5573641fcf153
861c3da2bbce6c09eda2709c8994f34c
General.rtf

Download

Download. Email me if you need the password (New link)

Read more

Monday, May 18, 2020

CEH: System Hacking, Cracking A Password, Understanding The LAN Manager Hash, NetBIOS DoS Attacks

Passwords are the key element of information require to access the system. Similarly, the first step is to access the system is that you should know how to crack the password of the target system. There is a fact that users selects passwords that are easy to guess. Once a password is guessed or cracked, it can be the launching point for escalating privileges, executing applications, hiding files, and covering tracks. If guessing a password fails, then passwords may be cracked manually or with automated tools such as a dictionary or brute-force method.

Cracking a Password

Passwords are stored in the Security Accounts Manager (SAM) file on a Windows system and in a password shadow file on a Linux system.

Manual password cracking involves attempting to log on with different passwords. The hacker follows these steps:

Find a valid user account (such as Administrator or Guest).
Create a list of possible passwords.
Rank the passwords from high to low probability.
Key in each password.
Try again until a successful password is found.

A hacker can also create a script file that tries each password in a list. This is still considered manual cracking, but it's time consuming and not usually effective.

A more efficient way of cracking a password is to gain access to the password file on a system. Most systems hash (one-way encrypt) a password for storage on a system. During the logon process, the password entered by the user is hashed using the same algorithm and then compared to the hashed passwords stored in the file. A hacker can attempt to gain access to the hashing algorithm stored on the server instead of trying to guess or otherwise identify the password. If the hacker is successful, they can decrypt the passwords stored on the server.

Understanding the LAN Manager Hash

Windows 2000 uses NT LAN Manager (NTLM) hashing to secure passwords in transit on the network. Depending on the password, NTLM hashing can be weak and easy to break. For example, let's say that the password is 123456abcdef . When this password is encrypted with the NTLM algorithm, it's first converted to all uppercase: 123456ABCDEF . The password is padded with null (blank) characters to make it 14 characters long: 123456ABCDEF__ . Before the password is encrypted, the 14-character string is split in half: 123456A and
BCDEF__ . Each string is individually encrypted, and the results are concatenated:

123456A = 6BF11E04AFAB197F
BCDEF__ = F1E9FFDCC75575B15

The hash is 6BF11E04AFAB197FF1E9FFDCC75575B15 .

Cracking Windows 2000 Passwords

The SAM file in Windows contains the usernames and hashed passwords. It's located in the Windows\system32\config directory. The file is locked when the operating system is running so that a hacker can't attempt to copy the file while the machine is booted to Windows.

One option for copying the SAM file is to boot to an alternate operating system such as DOS or Linux with a boot CD. Alternately, the file can be copied from the repair directory. If a system administrator uses the RDISK feature of Windows to back up the system, then a compressed copy of the SAM file called SAM._ is created in C:\windows\repair . To expand this file, use the following command at the command prompt:

C:\>expand sam._ sam

After the file is uncompressed, a dictionary, hybrid, or brute-force attack can be run against the SAM file using a tool like L0phtCrack. A similar tool to L0phtcrack is Ophcrack.

Download and install ophcrack from http://ophcrack.sourceforge.net/

Redirecting the SMB Logon to the Attacker

Another way to discover passwords on a network is to redirect the Server Message Block (SMB) logon to an attacker's computer so that the passwords are sent to the hacker. In order to do this, the hacker must sniff the NTLM responses from the authentication server and trick the victim into attempting Windows authentication with the attacker's computer.

A common technique is to send the victim an email message with an embedded link to a fraudulent SMB server. When the link is clicked, the user unwittingly sends their credentials over the network.

SMBRelay

An SMB server that captures usernames and password hashes from incoming
SMB traffic. SMBRelay can also perform man-in-the-middle (MITM) attacks.

SMBRelay2

Similar to SMBRelay but uses NetBIOS names instead of IP addresses to capture usernames and passwords.

pwdump2

A program that extracts the password hashes from a SAM file on a Windows system. The extracted password hashes can then be run through L0phtCrack to break the passwords.

Samdump

Another program that extracts NTLM hashed passwords from a SAM file.

C2MYAZZ

A spyware program that makes Windows clients send their passwords as clear text. It displays usernames and their passwords as users attach to server resources.

NetBIOS DoS Attacks

A NetBIOS denial-of-service (DoS) attack sends a NetBIOS Name Release message to the NetBIOS Name Service on a target Windows systems and forces the system to place its name in conflict so that the name can no longer be used. This essentially blocks the client from participating in the NetBIOS network and creates a network DoS for that system.

Start with a memorable phrase, such as "Maryhadalittlelamb"
Change every other character to uppercase, resulting in "MaRyHaDaLiTtLeLaMb"
Change a to @ and i to 1 to yield "M@RyH@D@L1TtLeL@Mb"
Drop every other pair to result in a secure repeatable password or "M@H@L1LeMb"

Now you have a password that meets all the requirements, yet can be "remade" if necessary.