Typical Vulnerabilities of E-Banking Systems
-
Upload
positive-hack-days -
Category
Technology
-
view
5.063 -
download
3
Transcript of Typical Vulnerabilities of E-Banking Systems
Sergey Scherbel
Dmitry Evteev
Eugenie Potseluevskaya Positive Technologies
Typical Vulnerabilities of
E-Banking Systems
Typical Vulnerabilities of E-Banking Systems
Future NowVulnerabilities of Remote Banking As Examplified by PHDays I-Bank
Future NowVulnerabilities of Remote Banking As Examplified by PHDays I-Bank
PHDays I-Bank IS NOT a real remote banking systemactually used by any bank.
The system was developed specially for PHDays 2012
PHDays I-Bank contains vulnerabilities typical of real
remote banking systems
Some of the vulnerabilities are found too often
Future NowIdentification
Predictable user identifiers are far moredangerous than it can seem!
A PHDays I-Bank identifier consists of numbers, just likemost identifiers in actual remote banking systems
Examples of identifiers: 1000001, 1000002, …
What’s wrong with it? We'll explain a bit later
Future NowPassword Policy
Weak password policy - a problem of all times!
The default password is strong, but user can change it
for a weak one
Even for one composed only of 1 character!
The only thing that gets checked is the length of the
password
So, we're certain to find something like 1234567 or 12345678
Check On Regular Expression
Problem - dictionary passwords, for example, P@ssw0rd
Future NowBrute Force?
Brute Force against Internet banking? What aboutsecurity?
Types of protection from brute force attacks:
Locking accounts
Locking IP addresses
Using CAPTCHA
Future NowLocking is not the answer!
It's easy to bypass these protection mechanisms
An account or IP address gets locked after a number of
failed authorization attempts (usually 3 or 5).
Predictable and weak identifiers
Weak password policy
???????
Profit!!!!111
Future NowLocking is not the answer!
Collect identifiers
Choose 1 or 2 passwords
Match identifiers against passwords,
not passwords against identifiers
1000001
1000002
1000003
...
1001421:12345678
1002236:12345678
1002313:12345678
...
Future NowLocking leads to Denial of Service!
After a few failed authentication attempts, the accountsgets locked
You can attack a target user
If you know all the identifiers...
You can conduct a large-scale DoS attack
As a rule, to unlock the account, users have to contact the
bank office
Someone's day might be ruined
Future NowLocking IP Address
Locking an IP address is not more prudent.
Most companies assign the same external IP address to all its
employees
Numerous authentication attempts can be treated like a brute-
force attempt, thus leading to lock-up of the IP address
Future NowCAPTCHA Problem
Possible repetitive sending of the same value
The value is sent in the hidden field of the HTML form
Sending of an empty value is possible
Insufficient validation: it's OK if the length is
appropriate or there are certain characters
CAPTCHA is not checked for certain headers
Future NowCAPTCHA Problem in PHDays I-Bank
The value is sent in a hidden field of the HTML form
public function encodeCaptchaCode($code) {
return @base64_encode(@strrev(@base64_encode($code)));
}
Encrypting does not use temporal values, it’s a peace of cake to
decrypt a line
PUlUTndVVE0= =ITNwUTM MTUwNTI= 15052
Future NowCAPTCHA Problem in PHDays I-Bank
Besides, one and the same value can be sent
repeatedly
So, you can conduct a brute-force
attack on the account!
Future NowPassword Recovery
Almost every web application provides for a password
recovery. PHDays I-Bank is not an exception
Future NowPassword Recovery: Problems
If password recovery requires not an email, but an
identifier, we can get all identifiers used in the system
Future NowPassword Recovery: Problems
Some users of the I-Bank could recover their
passwords via a web form
For others, the rules provided the only recovery way: to
contact a bank office
‘Please contact any office of the PHDays bank for password
recovery’
Future NowPassword Recovery: Problems
The key required for password recovery is generated
with weak entropy
private function addDataInTable($login) {
$key = md5($login.rand(1, 250));
To guess the key, one needs to go through only 250 values!
Then a new password will be created
Future NowWeak Entropy of Session Identifier
If a session uses its own mechanisms, reliability of
identifiers is crucial
In PHDays I-Bank identifiers are generated according
to a special algorithm
private function getSpecialHash($password) {
$hash = sprintf("%u", crc32($password));
if(strlen($hash) > 4) {
$hash = substr($hash, 0, 4);
Future NowWeak Entropy of Session Identifier
The session identifier consists of only 4 characters
All characters are numerical, which reduces entropy
The session identifier is static. It changes only if the
user changes his/her password
Future NowWeak Entropy of Session Identifier
Cookie: auth=1000001|2|3016
Future NowProblems with Privilege Isolation
While a possibility to transfer money from other accounts
is extremely rare, a possibility to address other users' data
can still be found
Some systems allow sending messages to the support
service on behalf of any user
Others that allow editing payment templates of other
users
Such vulnerabilities were not embedded into
PHDays I-Bank
Future NowOne-time Password
One-time passwords are used to protect systems from
unauthorized activities (transactions, password change,
editing personal data)
OTP can be requested either after the initial
authentication (login and password)
Or before each new transaction (or other action)
Future NowOne-Time Password in PHDays I-Bank
PHDays I-Bank had 2 types of OTP:
Emulation of an external device
OTP on scratch cards
It was implemented as the TransactionA class in the
code
It was implemented as the TransactionB class in the
code
Future NowOne-Time Password, Problems
OTP is not requested to transfer small amounts of
money (for example, up to $100)
One and the same OTP can be sent repeatedly
OTP can be predicted
Some users disable OTP validation
In PHDays I-Bank, transactions without OTP were carried out in TransactionC.
User can skip OTP validation and perform the
transaction stright away
Future NowOne-Time Password, TransactionA
OTP is impossible to predict
However, the OTP validation step can be skipped to
perform the transaction straight away!
Future NowOne-Time Password, TransactionA
Change step3 for step4
Future NowOne-Time Password, TransactionA
Profit!!11
Transaction is successfully completed. Simple bypass of a
reliable protection
Future NowOne-Time Password, TransactionB
Algorithm of OTP generation
protected function generateOTP() {
$OTPs = array();
$s = 44553 + $this->userInfo["id"]; // the variable depends only on
// the user's number
for($n = 10; $n < 24; $n++) { // generating 14 OTP
$OTP = "";
$j = rand(20,39); // the $s variable can take on
$j = substr($j, 0, 1); // only two values – 2 or 3
$OTP = $n*$s*$j;
$OTP = substr($OTP, 0, 5); // OTP consists of 5 characters
$OTPs[] = $OTP;
Future NowOne-Time Password, TransactionB
OTP can take on only 2 values
Future NowOne-Time Password, TransactionC
OTP is not requested - transactions can be completed
freely
In PHDays I-Bank, there were not many users who
were not requested OTP for transaction
But some participants got lucky
Future NowActions without OTP
Sometimes OTP is requested only for transactions, while
other actions could be completed without it:
Send a message to Support Service
Change the password
Change the payment template
Create a payment template
Open a new account
Future NowChanging Payment Template
Payment templates allow saving time on entering similar
data:
Recipient's account
Recipient's name
If an attacker has a chance to change the template data,
they can easily change the recipient's account for theirs.
The user is likely to overlook the change and confirm the
transaction
Future NowHow Was It
20,000 rubles (about $700) - the prize fund
The day before the competition, participants received
the source code of the systems and a virtual machine
with installed PHDays I-Bank
Then, the participants had 20-30 minutes to use
vulnerabilities they had found
Automation of the process decided the winning side.
Hypothreading played a critical role!
Future Now2 Tasks to Succeed
The competition could virtually be divided into 2 tasks:
Gaining access to the account
Simple and dictionary passwords
Weak entropy of the password recovery key
Weak entropy of session identifier
OTP bypass
OTP was not requested
The OTP validation step could be skipped
Predictable OTP
Future NowDistribution of Vulnerabilities
30
18
52
100
Distribution of Vulnerabilities
Simple password
Dictionary password
Session ID
Recovery key
Future NowDistribution of Vulnerabilities
The money was distributed according to a simple principle:
the more difficult it is to get the access, the more money it
"costs"
The accounts used for demonstration had weak passwords -
1234567 and password
The participants' accounts were also vulnerable: the session
identifier had weak entropy
The most reasonable strategy to follow was to transfer all the
money of other participants closer to the end of the competition
Future NowHelpDesk
Together with the remote banking, we implemented an
elementary HelpDesk
HelpDesk is a system for the employees of the bank
The main idea was if an attacker managed to get into
the "restricted-access" system, they would have
enough information to hack the entire system
In practice: Password policy, information on protection
mechanisms and even user passwords
Future NowHelpDesk in PHDays I-Bank
Discussions that hinted at the details to consider
Link to the system that displayed users with simple
passwords
Future NowHelpDesk, Authentication Bypass
HelpDesk is vulnerable to authentication bypass:
You don't need to know the login or the password
Just send the following header in each HTTP request
if(isset($_SERVER["HTTP_BANKOFFICEUSER"])) {
$userId = base64_decode($_SERVER["HTTP_BANKOFFICEUSER"]);
$userInfo = $this->user->getUserInfoById($userId);
$this->user->setupUserInfo($userInfo);
return $this->user;
}
Future NowHelpDesk, Authentication Bypass
Modify Header - handy for the exploitation:
Future NowRace condition
If you send a lot of requests, it can probably lead to a
situation when all of the requests will be processed at a
time:Request N Request N + 1
Checking for the required amount
Checking for the required amount
Depositing Depositing
Profit! $$$
Future NowRace Condition, Nginx
To get protected from Race condition and prevent the
situation when money appears from nowhere, nginx was
set to block the messages coming too often
The limit was 3 requests per second to the script that
fulfilled the transactions.
Nginx was not installed on the virtual machines, so one of
the participants found the Race condition problem.
Future NowBusiness Impact Analysis - How much would it cost?
Assumptions:
I-Bank’s capital is 300 million dollars
100 000 clients use online banking services
Average sum on every account is 1000 dollars
Profit from every client is 500 dollars
Operating costs to change users’ passwords – $0,15 for a
password
Reissuing of one scratch card costs 15 dollars
Future NowBusiness Impact Analysis – Impact (in millions of dollars)
Future NowBusiness Impact Analysis – Impact
Future NowBusiness Impact Analysis: Exploitation Probabilities
30
18
52
100
Distribution of Password Vulnerabilities
Simple password - 90%
Dictionary password -90%
Session ID - 70%
Recovery key - 50%
80
80
40
Distribution of OTP Vulnerabilities
External Device - 90%
Scratch Cards -90%
No OTP - 100%
Future NowBusiness Impact Analysis – Risk Assessment
Probability is
0,54%
Risk=9% of the capital
Risk=Impact x Probability
Risk level of over 3% of the
capital is regarded as critical
for a bank!
Future NowBusiness Impact Analysis: make the right choice
Forewarned is forearmed
(millions o
f dollars
)
Thank you for your attention