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