In Hacking the main focus is over gathering the information about victim or victim's machine. Which will help to find out which type of exploit will works according to the given circumstances. Gathering the network and host information means to find out by which network, the which victim's machine is connected and communicating over the network. Moreover, scanning is also performed for gathering information about open and closed ports. After that they'll able to find the vulnerabilities in the target system and try to get access to the system.
Types Of Scan
As a CEH you should know the scan types and uses:
SYN
SYN scan doesn't complete the TCP three way handshake that is why it is known as a half-open scan. An attacker send a SYN packet to the victim machine if SYN/ACK packet is received back to attacker, then it clarify that the port is listening due to the acknowledgment by the victim that it has completed the connection. While if the attacker is received the RST/ACK packet then it assumed that the port is closed or open.
XMAS
XMAS scan works only on target system that has the RFC 793 development of TCP/IP and it doesn't works against any version of windows. XMAS scan send a packet with by setting up the FIN, URG and PSH flags of the TCP header. The function of this scan is if the port is active there will be no response but if the port is closed the target responds with a RST/ACK packet.
FIN
A FIN scan send a packet by setting up only the FIN flag of the TCP. This scan is similar to XMAS scan. FIN scan receives no response if the port is active while if the port is closed it receives the RST/ACK packet.
NULL
NULL scan is also similar to the XMAS scan. But the only difference is that it sends a packet without setting up the any flag of TCP header. NULL scan receives no response if the port is open but if the port is closed it receives the RST/ACK packet.
IDLE
It is just like spoofing an IP address by sending a SYN packet to the victim's machine to find out which services are available over the system. This scan is completed with the help of another system called as "Zombie" (that is not receiving or transmitting any information).
Everything over the internet is secured by the passwords. You need a login to do any stuff on any social or banking website. Passwords are the first security measure for these type of websites. So, I brought a tutorial on how to hack such sort of login passwords. This tutorial is based on credential harvester attack method. In which you will know about hacking passwords using credential harvester attack method.
HACKING PASSWORDS USING CREDENTIAL HARVESTER ATTACK
REQUIREMENTS
It's very simple and easy to follow. Before you start, you need the following things to work with.
Kali Linux OS
Target Website
STEPS TO FOLLOW
Run the Kali Linux machine. If you have not Kali Linux installed, you can grab a free copy and install it as a virtual machine. You can learn more about Kali Linux VirtualBox installation.
Sign in to Kali Linux by entering username root and password toor.
As you'll sign in, navigate to the Applications > Social Engineering Tools> Social Engineering as shown in the following screenshot.
Now you will see the different options. You have to choose Social Engineering Attacks by simply entering its number in the terminal. Once you do it, it will show a few options further. Simply choose Website Vector Attack by putting its number.
Website vector attack will show up it's a different type of attacks. We are going to use Credential Harvester Attack.
Choose the Site Clone option. As you do it, it will ask for your public IP address. Just open up a new terminal and type ifconfig. It'll show the public IP. Just copy it and paste in the previous terminal as shown in the following screenshots.
After we do it. Enter the target website of which passwords you want to hack. Make sure to use a website that has username and password on the same page.
All done now. As someone opens up the browser on the public IP we specified, it'll show up the website that we entered in the previous step. Now as someone enters their username or password, it will be captured in the terminal.
That's all. If you're not clear yet. You can watch the following complete video tutorial on how to do it.
AlienSpy Java based cross platform RAT is another reincarnation of ever popular Unrecom/Adwind and Frutas RATs that have been circulating through 2014.
It appears to be used in the same campaigns as was Unrccom/Adwind - see the references. If C2 responds, the java RAT downloads Jar files containing Windows Pony/Ponik loader. The RAT is crossplatform and installs and beacons from OSX and Linux as well. However, it did not download any additional malware while running on OSX and Linux.
The samples, pcaps, and traffic protocol information are available below.
File information
I File: DB46ADCFAE462E7C475C171FBE66DF82_paymentadvice.jar Size: 131178 MD5: DB46ADCFAE462E7C475C171FBE66DF82
Original jar attachment files B2856B11FF23D35DA2C9C906C61781BA_purchaseorder.jar DB46ADCFAE462E7C475C171FBE66DF82_paymentadvice.jar 79e9dd35aef6558461c4b93cd0c55b76_Purchase Order.jar
Alienspy RAT The following RAT config strings are extracted from memory dumps. Alienspy RAT is a reincarnated Unrecom/Adwind << Frutas RAT and is available from https://alienspy.net/ As you see by the config, it is very similar to Unrecom/Adwind File: paymentadvice.jar Size: 131178
%USERPROFILE%\Application Data\evt88IWdHO\CnREgyvLBS.txt <<MD5: abe6ef71e44d2e145033800d0dccea57 << strings are here (by classes) %USERPROFILE%\Application Data\evt88IWdHO\Desktop.ini %USERPROFILE%\Local Settings\Temp\asdqw15727804162199772615555.jar << Strings are here %USERPROFILE%\Local Settings\Temp\iWimMQLgpsT2624529381479181764.png (seen Transfer.jar in the stream) <<MD5: fab8de636d6f1ec93eeecaade8b9bc68 Size: 755017 << Strings are here
The following fields are part of the serialization protocol and are 'benign" and common.
AC ED(¬í) - Java Serialization protocol magic STREAM_MAGIC = (short)0xaced. 00 05 - Serialization Version STREAM_VERSION 75 (u) - Specifies that this is a new array - newArray: TC_ARRAY 72 (r) - Specifies that this is a new class - newClassDesc: TC_CLASSDESC 00 02 - Length of the class name 5B 42 AC F3 17 F8 06 08 54 E0 ([B¬ó.ø..Tà) This is a Serial class name and version identifier section but data appears to be encrypted 02 00 - Is Serializable Flag - SC_SERIALIZABLE 78 70 (xp) - some low-level information identifying serialized fields 1f 8b 08 00 00 00 00 00 00 00 - GZIP header as seen in the serialization stream
As you see, all Windows traffic captures have identical fields following the GZIP stream, while OSX traffic has different data. The jar files that had Pony Downloader payload did not have other OSX malware packaged and I saw no activity on OSX other than calling the C2 and writing to the randomly named timestamp file (e.g VblVc5kEqY.tmp - updating current timestamp in Unix epoch format)
Combination of the Stream Magic exchange, plus all other benign fields in this order will create a usable signature. However, it will be prone to false positives unless you use fields after the GZIP header for OS specific signatures
Another signature can be based on the transfer. jar download as seen below
DB46ADCFAE462E7C475C171FBE66DF82 - downloading fab8de636d6f1ec93eeecaade8b9bc68 iWimMQLgpsT2624529381479181764.png (seen Transfer.jar in the stream) , which contains 15555.jar in Manifest.mf, which contains 15555.exe (Pony loader) in its' Manfest.mf
IHEAKA _000C297 << IHEAKA is the name of the RAT client, it is different in each infection.
000ABBA0 00 09 00 00 00 31 35 35 35 35 2e 6a 61 72 74 97 .....155 55.jart. 000ABBB0 43 70 26 8c a2 44 63 db 9c d8 b6 9d 7c b1 6d db Cp&..Dc. ....|.m. 000ABBC0 c6 c4 b6 6d db b6 6d db 99 d8 76 f2 fe e5 dd bc ...m..m. ..v.....
Pony downloader traffic
HTTP requests URL: http://meetngreetindia.com/scala/gate.php TYPE: POST USER AGENT: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98) URL: http://meetngreetindia.com/scala/gate.php TYPE: GET USER AGENT: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98) DNS requests meetngreetindia.com (50.28.15.25) TCP connections 50.28.15.25:80
IP:50.28.15.25 Decimal:840699673 Hostname:mahanadi3.ewebguru.net ISP:Liquid Web Organization:eWebGuru State/Region:Michigan City:Lansing
II 79E9DD35AEF6558461C4B93CD0C55B76 Purchase order.jar IP:38.89.137.248 Decimal:643402232 Hostname:38.89.137.248 ISP:Cogent Communications Country:United States us flag
III 2856B11FF23D35DA2C9C906C61781BA Purchase order.jar installone.no-ip.biz IP Address: 185.32.221.17 Country: Switzerland Network Name: CH-DATASOURCE-20130812 Owner Name: Datasource AG From IP: 185.32.220.0 To IP: 185.32.223.255 Allocated: Yes Contact Name: Rolf Tschumi Address: mgw online service, Roetihalde 12, CH-8820 Waedenswil Email: rolf.tschumi@mgw.ch Abuse Email: abuse@softplus.net
Virustotal
https://www.virustotal.com/en/file/02d1e6dd2f3eecf809d8cd43b5b49aa76c6f322cf4776d7b190676c5f12d6b45/analysis/SHA256:02d1e6dd2f3eecf809d8cd43b5b49aa76c6f322cf4776d7b190676c5f12d6b45 MD5 db46adcfae462e7c475c171fbe66df82 SHA1 2b43211053d00147b2cb9847843911c771fd3db4 SHA256 02d1e6dd2f3eecf809d8cd43b5b49aa76c6f322cf4776d7b190676c5f12d6b45 ssdeep3072:VR/6ZQvChcDfJNBOFJKMRXcCqfrCUMBpXOg84WoUeonNTFN:LdvCGJN0FJ1RXcgBpXOjOjSNTFN File size 128.1 KB ( 131178 bytes ) File type ZIP Magic literalZip archive data, at least v2.0 to extract TrIDZIP compressed archive (100.0%) File name:Payment Advice.jar Detection ratio:6 / 54 Analysis date:2014-11-16 20:58:08 UTC ( 1 day, 4 hours ago ) IkarusTrojan.Java.Adwind20141116 TrendMicroJAVA_ADWIND.XXO20141116 TrendMicro-HouseCallJAVA_ADWIND.XXO20141116 DrWebJava.Adwind.320141116 KasperskyHEUR:Trojan.Java.Generic20141116 ESET-NOD32a variant of Java/Adwind.T20141116
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:
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: 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:
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.
