Do you know what is happening in the background when you buy something in an online shop using PayPal?
In this post we will tackle the following problems:
How can PayPal's API be tested?
How does PayPal's Express Checkout work? You can find the detailed report here.
How can we debit more money than authorized?
How PayPal's API can be tested?
PayPal's Sandbox API
PayPal offers a feature called PayPal Sandbox Accounts, which mimics the production API. The basic idea is that a normal user/shop can test the API and make transactions without actually transferring money. This is the perfect tool for developers to test their API integration.
Access to all messages
The next question is how to get access to all messages. All browser-related messages can be inspected, intercepted, and modified via BurpSuite. The main problem here is how to get access to the server-to-server exchanged messages: the messages exchanged between PayPal and a shop. In order to solve this problem, we deployed our own shop. For this purpose we used Magento, which already has a PayPal integration. Once we have our own controlled shop, we can enforce Magento to send all request through a proxy. In the following picture you can see our setup.
Test suite for analyzing PayPal's API [1]
In order to capture the traffic between our Magento hhop and PayPal we proceeded as follows:
We configured Magento to use a proxy running on localhost:8081.
We connected the proxy port on the virtual machine with our local machine via SSH remote port forwarding by issuing the following command
ssh -N -R 8081: localhost :8081 <IP of Magento shop>
Weconfigured BurpSuite running on our local machine to listen on Port 8081 for incoming requests.
Now, we were able to see the entire traffic. Please note that we uses our own, custom Magento shop in order to be able to test Paypal's API.
PayPal's Express Checkout
An overview of the checkout procedure is depicted in the following:
PayPal's Express Checkout [2]
Step 1: Magento tells the PayPal API where to redirect the user after authorizing the transaction via the parameter RETURNURL and requests a token for this transaction. Step 2: The PayPal API provides Magento with the token. Step 3: Magento redirects the user to PayPal's website. The redirect contains the token from the previous step. Step 4: The user authorizes the transaction. As a result, he will be redirected back to Magento (RETURNURL) with the token. Step 5: Magento issues a request to the PayPal API to get the transaction details.
Step 6: Magento signals the PayPal API to execute the transaction.
Step 7: Magento serves the success page.
A more detailed view of the protocol and all parameters is shown on page 16 in the full version. We will concentrate only on step 6 and the parameters relevant for the attack.
The Attack
The goal of the attack is to let a shop (in our case Magento) debit more money than authorized by the PayPal user. The core of the attack is Step 6 -- DoExpressCheckoutPayment. Let's get a deeper look at this message:
Magento can raise the authorizedamount and debit more moneyfrom the user's account
The shop sends the token, which was issued in the first step of the protocol and identifies uniquely the transaction through all steps.
The PayerID referring to the user that authorized the payment.
The AMT defining the amount, which will be transferred.
The API Credentials authenticating Magento on PayPal.
The Version pointing to the release number of the API.
As one can imagine, the core problem we found was the change of the AMT parameter. This value can be freely chosen by the shop, despite the fact that the user has authorized a different amount.
We tested only the SandBox API, but refused to test the production API in order to avoid problems. We promptly contacted PayPal's security team and described the problem hoping that PayPal can and will test the production API against the attack.
The response of PayPal can be summarized as follows:
We don't get any BugBounty since we only tested the Sanbox API. (Fair enough)
In the Production API PayPal this flexibility is a wanted feature. Thus, PayPal allows a merchant to charge for shipping and/or other expenses different amounts. Any malicious behavior can be detected by PayPal. In case of fraudulent charges the consumer are protected by the Buyer Protection policy.
Saw that a lot of people were looking for a pcap with WannaCry spreading Using EthernalBlue.
I have put together a little "petri dish" test environment and started looking for a sample that has the exploit. Some samples out there simply do not have the exploit code, and even tough they will encrypt the files locally, sometimes the mounted shares too, they would not spread.
Once I got the sample from the VxStream Sandbox site, dropped it in the test environment, and monitored it with Security Onion. I was super happy to see it spreading, despite the fact that for the first run my Windows 7 x64 VM went to BSOD as the EthernalBlue exploit failed.
In this blog series we will analyze blockchain vulnerabilities and exploit them ourselves in various lab and development environments. If you would like to stay up to date on new posts follow and subscribe to the following: Twitter: @ficti0n
As of late I have been un-naturally obsessed with blockchains and crypto currency. With that obsession comes the normal curiosity of "How do I hack this and steal all the monies?"
However, as usual I could not find any actual walk thorough or solid examples of actually exploiting real code live. Just theory and half way explained examples.
That question with labs is exactly what we are going to cover in this series, starting with the topic title above of Re-Entrancy attacks which allow an attacker to siphon out all of the money held within a smart contract, far beyond that of their own contribution to the contract.
This will be a lab based series and I will show you how to use demo the code within various test environments and local environments in order to perform and re-create each attacks for yourself.
Note: As usual this is live ongoing research and info will be released as it is coded and exploited.
If you are bored of reading already and just want to watch videos for this info or are only here for the demos and labs check out the first set of videos in the series at the link below and skip to the relevant parts for you, otherwise lets get into it:
Background Info:
This is a bit of a harder topic to write about considering most of my audience are hackers not Ethereum developers or blockchain architects. So you may not know what a smart contract is nor how it is situated within the blockchain development model. So I am going to cover a little bit of context to help with understanding.I will cover the bare minimum needed as an attacker.
A Standard Application Model:
In client server we generally have the following:
Front End - what the user sees (HTML Etc)
Server Side - code that handles business logic
Back End - Your database for example MySQL
A Decentralized Application Model:
Now with a Decentralized applications (DAPP) on the blockchain you have similar front end server side technology however
Smart contracts are your access into the blockchain.
Your smart contract is kind of like an API
Essentially DAPPs are Ethereum enabled applications using smart contracts as an API to the blockchain data ledger
DAPPs can be banking applications, wallets, video games etc.
A blockchain is a trust-less peer to peer decentralized database or ledger
The back-end is distributed across thousands of nodes in its entirety on each node. Meaning every single node has a Full "database" of information called a ledger.The second difference is that this ledger is immutable, meaning once data goes in, data cannot be changed. This will come into play later in this discussion about smart contracts.
Consensus:
The blockchain of these decentralized ledgers is synchronized by a consensus mechanism you may be familiar with called "mining" or more accurately, proof of work or optionally Proof of stake.
Proof of stake is simply staking large sums of coins which are at risk of loss if one were to perform a malicious action while helping to perform consensus of data.
Much like proof of stake, proof of work(mining) validates hashing calculations to come to a consensus but instead of loss of coins there is a loss of energy, which costs money, without reward if malicious actions were to take place.
Each block contains transactions from the transaction pool combined with a nonce that meets the difficulty requirements.Once a block is found and accepted it places them on the blockchain in which more then half of the network must reach a consensus on.
The point is that no central authority controls the nodes or can shut them down. Instead there is consensus from all nodes using either proof of work or proof of stake. They are spread across the whole world leaving a single centralized jurisdiction as an impossibility.
Things to Note:
First Note: Immutability
So, the thing to note is that our smart contracts are located on the blockchain
And the blockchain is immutable
This means an Agile development model is not going to work once a contract is deployed.
This means that updates to contracts is next to impossible
All you can really do is createa kill-switch or fail safe functions to disable and execute some actions if something goes wrong before going permanently dormant.
If you don't include a kill switch the contract is open and available and you can't remove it
Second Note:Code Is Open Source
Smart Contracts are generally open source
Which means people like ourselves are manually bug hunting smart contracts and running static analysis tools against smart contract code looking for bugs.
When issues are found the only course of action is:
Kill the current contract which stays on the blockchain
Then deploy a whole new version.
If there is no killSwitch the contract will be available forever.
Now I know what you're thinking, these things are ripe for exploitation.
And you would be correct based on the 3rd note
Third Note: Security in the development process is lacking
Many contracts and projects do not even think about and SDLC.
They rarely add penetration testing and vulnerability testing in the development stages if at all
At best there is a bug bounty before the release of their main-nets
Which usually get hacked to hell and delayed because of it.
Things are getting better but they are still behind the curve, as the technology is new and blockchain mostly developers and marketers.Not hackers or security testers.
Forth Note:Potential Data Exposure via Future Broken Crypto
If sensitive data is placed on the blockchain it is there forever
Which means that if a cryptographic algorithm is broken anything which is encrypted with that algorithm is now accessible
We all know that algorithms are eventually broken!
So its always advisable to keep sensitive data hashed for integrity on the blockchain but not actually stored on the blockchain directly
Exploitation of Re-Entrancy Vulnerabilities:
With a bit of the background out of the way let's get into the first attack in this series.
Re-Entrancy attacks allow an attacker to create a re-cursive loop within a contract by having the contract call the target function rather than a single request from auser. Instead the request comes from the attackers contract which does not let the target contracts execution complete until the tasks intended by the attacker are complete. Usually this task will be draining the money out of the contract until all of the money for every user is in the attackers account.
Example Scenario:
Let's say that you are using a bank and you have deposited 100 dollars into your bank account.Now when you withdraw your money from your bank account the bank account first sends you 100 dollars before updating your account balance.
Well what if when you received your 100 dollars, it was sent to malicious code that called the withdraw function again not lettingthe initial target deduct your balance ?
With this scenario you could then request 100 dollars, then request 100 again and you now have 200 dollars sent to you from the bank. But 50% of that money is not yours. It's from the whole collection of money that the bank is tasked to maintain for its accounts.
Ok that's pretty cool, but what if that was in a re-cursive loop that did not BREAK until all accounts at the bank were empty?
That is Re-Entrancy in a nutshell.So let's look at some code.
Example Target Code:
function withdraw(uint withdrawAmount) public returns (uint) {
Line 1: Checks that you are only withdrawing the amount you have in your account or sends back an error.
Line 2: Sends your requested amount to the address the requested that withdrawal.
Line 3: Deducts the amount you withdrew from your account from your total balance.
Line 4. Simply returns your current balance.
Ok this all seems logical.. however the issue is in Line 2 - Line 3.The balance is being sent back to you before the balance is deducted. So if you were to call this from a piece of code which just accepts anything which is sent to it, but then re-calls the withdraw function you have a problem as it never gets to Line 3 which deducts the balance from your total. This means that Line 1 will always have enough money to keep withdrawing.
Let's take a look at how we would do that:
Example Attacking Code:
function attack() public payable {
1.bankAddress.withdraw(amount);
}
2.function () public payable {
3.if (address(bankAddress).balance >= amount) {
4.bankAddress.withdraw(amount);
}
}
Line 1: This function is calling the banks withdraw function with an amount less than the total in your account
Line 2: This second function is something called a fallback function. This function is used to accept payments that come into the contract when no function is specified. You will notice this function does not have a name but is set to payable.
Line 3:This line is checking that the target accounts balance is greater than the amount being withdrawn.
Line 4:Then again calling the withdraw function to continue the loop which will in turn be sent back to the fallback function and repeat lines over and over until the target contracts balance is less than the amount being requested.
Review the diagram above which shows the code paths between the target and attacking code. During this whole process the first code example from the withdraw function is only ever getting to lines 1-2 until the bank is drained of money. It never actually deducts your requested amount until the end when the full contract balance is lower then your withdraw amount. At this point it's too late and there is no money left in the contract.
Setting up a Lab Environment and coding your Attack:
Hopefully that all made sense. If you watch the videos associated with this blog you will see it all in action.We will now analyze code of a simple smart contract banking application. We will interface with this contract via our own smart contract we code manually and turn into an exploit to take advantage of the vulnerability.
Then lets open up an online ethereum development platform at the following link where we will begin analyzing and exploiting smart contracts in real time in the video below:
Coding your Exploit and Interfacing with a Contract Programmatically:
The rest of this blog will continue in the video below where we will manually code an interface to a full smart contract and write an exploit to take advantage of a Re-Entrency Vulnerability:
Conclusion:
In this smart contract exploit writing intro we showed a vulnerability that allowed for re entry to a contract in a recursive loop. We then manually created an exploit to take advantage of the vulnerability. This is just the beginning, as this series progresses you will see other types of vulnerabilities and have the ability to code and exploit them yourself. On this journey through the decentralized world you will learn how to code and craft exploits in solidity using various development environments and test nets.
Phishing is the way to obtain sensitive information such as usernames, passwords, and credit card details or any other confidential information, often for malicious reasons, by disguising as a trustworthy entity in an electronic communication. Phishing is typically carried out by several ways like email spoofing or instant messaging, and it often directs users to enter personal information at a fake website, the look and feel of which are almost identical to the legitimate one. In this tutorial, I will be showing how to hack a facebook account through phishing.
SO, HOW TO HACK A FACEBOOK ACCOUNT?
There are few techniques by which you can hack a facebook account but here the easiest way we'll discuss.
REQUIREMENTS
Phisher Creator ( Fake page generator)
Hosting ( To host a fake page). Either you can purchase one or also can use free hosting like 110mb.com. But in free hosting, the account will be suspended after a few logins.
STEPS TO FOLLOW
Download phisher creator and run it.
As you run it, you'll see a screen like the shown below. Here you can type the fields as I have done.
Once you hit the Create Phisher button, it'll create a fake facebook index page and fb_login.php file in the output folder.
Now you need to upload these both files index.html and fb_login.php to the hosting account.
After uploading the file, open the index.html file path. It will open up a page like same facebook page as you can see below.
We're all done, now we just need to copy the URL of our fake page and distribute it to the victims, you just have to trick them with your social engineering that how you convenience them to open this URL to login facebook. Once someone tries to login through your fake facebook page URL, you'll get their account username and password in the log_file.txt in the same directory of hosting where you have uploaded index.php and fb_login.php.
Hope it'll work fine for you and you have learned how to hack a facebook account. If you find any question or query related to this, feel free to comment below or you can also follow another way that might work well for you to hack facebook account.
Attackers exploit Windows SMB vulnerability CVE-2017-0143 or use stolen credentials to gain access, deploy the custom Calypso RAT and use it to upload other tools such as Mimikatz, EternalBlue and EternalRomance. They move laterally and steal data.
In the Hacking Windows 95, part 1 blog post, we covered that through a nasty bug affecting Windows 95/98/ME, the share password can be guessed in no time. In this article, I'm going to try to use this vulnerability to achieve remote code execution (with the help of publicly available tools only).
The first thing we can do when we have read access to the Windows directory through the share, is to locate all the *.pwl files on the c:\windows directory, copy them to your machine where Cain is installed, switch to Cracker tab, pwl files, load the pwl file, add username based on the filename, and try to crack it. If you can't crack it you might still try to add a .pwl file where you already know the password in the remote windows directory. Although this is a fun post-exploitation task, but still, no remote code execution. These passwords are useless without physical access.
One might think that after having a share password and user password, it is easy to achieve remote code execution. The problem is:
there is no "at" command (available since Windows 95 plus!)
there is no admin share
there is no RPC
there is no named pipes
there is no remote registry
there is no remote service management
If you think about security best practices, disabling unnecessary services is always the first task you should do. Because Windows 95 lacks all of these services, it is pretty much secure!
During my quest for a tool to hack Windows 95, I came across some pretty cool stuff:
But the best of the best is Fluxay, which has been written by chinese hackers. It is the metasploit from the year 2000. A screenshot is worth more than a 1000 words. 4 screenshot > 4 thousand words :)
It is pretty hard to find the installer, but it is still out there!
But at the end, no remote code execution for me.
My idea here was that if I can find a file which executes regularly (on a scheduled basis), I can change that executable to my backdoor and I'm done. Although there is no scheduler in the default Windows 95, I gave it a try.
Let's fire up taskman.exe to get an idea what processes are running:
Looks like we need a more powerful tool here, namely Process Explorer. Let's try to download this from oldapps.com:
LOL, IE3 hangs, can't render the page. Copying files to the Win95 VM is not that simple, because there are no shared folders in Win95 VM. And you can't use pendrives either, Win95 can't handle USB (at least the retail version). After downloading the application with a newer browser from oldapps, let's start Process Explorer on the test Windows 95.
Don't try to download the Winsocks 2 patch from the official MS site, it is not there anymore, but you can download it from other sites.
Now let's look at the processes running:
After staring it for minutes, turned out it is constant, no new processes appeared. Looking at the next screenshot, one can notice this OS was not running a lot of background processes ...
My current Win7 has 1181 threads and 84 processes running, no wonder it is slow as hell :)
We have at least the following options:
You are lucky and not the plain Windows 95 is installed, but Windows 95 Plus! The main difference here is that Windows 95 Plus! has built-in scheduler, especially the "at" command. Just overwrite a file which is scheduled to execution, and wait. Mission accomplished!
Ping of death - you can crash the machine (no BSOD, just crash) with long (over 65535 bytes) ICMP ping commands, and wait for someone to reboot it. Just don't forget to put your backdoor on the share and add it to autoexec.bat before crashing it.
If your target is a plain Windows 95, I believe you are out of luck. No at command, no named pipes, no admin share, nothing. Meybe you can try to fuzz port 137 138 139, and write an exploit for those. Might be even Ping of Death is exploitable?
Let's do the first option, and hack Windows 95 plus!
Look at the cool features we have by installing Win95 Plus!
Cool new boot splash screen!
But our main interest is the new, scheduled tasks!
Now we can replace diskalm.exe with our backdoor executable, and wait maximum one hour to be scheduled.
Instead of a boring text based tutorial, I created a YouTube video for you. Based on the feedbacks on my previous tutorialz, it turned out I'm way too old, and can't do interesting tutorials. That's why I analyzed the cool skiddie videoz, and found that I have to do the followings so my vidz won't suck anymore:
use cool black windows theme
put meaningless performance monitor gadgets on the sidebar
use a cool background, something related with hacking and skullz
do as many opsec fails as possible
instead of captions, use notepad with spelling errorz
