For purposes of clarity: this article discusses the issue of CIMB Clicks password or login system exclusively. The other issue regarding problems of CIMB debit transactions is indeed concerning and should be investigated by CIMB.
Misinformed people had been running around spewing a lot of untrue allegations and wild speculations lately about CIMB Clicks. We thought that we might clear things up with facts and logic instead of impulsive and sensational journalism. Let’s get straight to the point, we will take points from said sources and try to analyze if it is true or false.
First off, we will start with where this all started:
LOWYAT.NET
First article
“CIMB Clicks May Contain Serious Security Flaws”
Original Article: http://archive.fo/X2wqm
This might be where it all started for the mainstream media. The website portal published a short article about “something strange is happening with CIMB Clicks” which they never revealed. Their belief seems to be strengthened by stating “rather abrupt implementation of a reCaptcha code on their login page” and “there are reasons to be concerned”.
Analysis
So far, Lowyat.net has shown genuine concern about user security which is totally acceptable. By not disclosing the problem due to concerns about it being abused was a totally good move. Usually, ethical pen-testers will report a problem or bug first and wait for a response from the company. But then again, the article seems to be fear-mongering.
However, bug/hacking/exploit cases are first tested, verified and dissected down to the core before it is even considered to be publicized because wrong assumptions and baseless accusations will damage a party’s reputation. These could potentially be regarded as unethical journalism or malicious journalism(ignorance is not an excuse especially when you are running a specialized news portal).
Second article
“What CIMB Malaysia has not told you, but should”
Original Article: http://archive.fo/aRbC2
This is where it starts to be a bit sketchy. By this time, the public and media had already been fed with multiple untrue allegations and unfounded concerns or misinformation.
Point 1:
“So, when the new password policy came into effect, CIMB Malaysia somehow decided that instead of compelling all users to do a password change to adhere to the new policy, they would instead allow both new and old passwords to co-exist simultaneously. And instead of making massive changes to how their system would allow this to be done securely, they chose a very simple, insecure, and downright nasty way of doing it.”
Right here they start to refer to the Javascript implementation within the codes of the CIMB Clicks login page.
Analysis – Point 1:
Short version:
Let’s say you have a text input box & the text input box is limited to 8 characters. You start typing and the characters come displays as you type. For the sake of visualization, let’s just assume the text input box is visible(passwords will show asterisks).
At this particular point, the text box is full and can’t be populated more over 8 characters. Even when you keep typing and smash random keys, nothing will come out. You press enter and the system logs you in. Does it still consider correct password or incorrect password? Of course, it is considered a correct password.
The only difference is that instead of hard limiting what you typed in, CIMB just shifted that behaviour and process it after with Javascript. It detects that this is an old password and it is impossible to have more than 8 characters. Which is actually CONSISTENT with the old password policy’s behaviour.
So in other words, the Javascript implementation was not wrong. It does not decrease the security level even the slightest. Security integrity remains the same.
Long version:
This is inaccurate and untrue to the fact that it was “insecure and downright nasty”. As a matter of fact, the client side Javascript code to truncate the password does not matter at all!
CIMB old password consists of letters, numbers and symbols(just not a requirement). CIMB new password consists of letters, numbers and symbols(mandatory). Going with this logic, CIMB new password can never have the characteristic of an old password.
The Javascript does not impact the security of any currently existing password. The truncation affects passwords which do not have special characters that are longer than 8 characters in length. However, in the past passwords could not be longer than 8 characters, while currently, passwords require a special character. This means that it’s impossible in the past or present to create a password that was more than 8 characters long without any special characters in the first place.
So since the old password is 8 characters long maximum, adding more stuff after that just increases the complexity of the old password so by logic, the old password was never affected. The truncation process is in no way going to make it easier for anyone to log into your account without knowing your password since they would need to have your password or something with greater complexity!
By going with that, security was never compromised in the implementation of the Javascript. Thus, making the claim “insecure and downright nasty” totally invalid.
If you still don’t get it, lets put it into practice:
Active password: “SOMETHIN”
Hacker obtained: “SOMETHINGnew”
Attempts to be made(with JS):
“SOMETHINGnew” – Returns valid because truncated
Number of attempts: 1
Attempts to be made(without JS):
“SOMETHINGnew” – Returns invalid
“SOMETHIN” – Returns valid
Number of attempts: 2(as we try to understand Lowyat.net’s logic)
However, since the attacker already knows that “SOMETHINGnew” is not a valid phrase, they would not be trying that in the first place and that made the number of attempts back to 1.
So, by this logic, truncation on the Javascript client side does not even matter at all! Simply because of the fact that the old password’s policy is public knowledge.
You might argue that hiding the old password requirements would make things harder for the attacker and increase security. However, that is just security through obscurity and isn’t security at all.
Remember that lesson in Security Engineering regarding ‘security through obscurity’? This theory or method had been rejected by security experts as far back as 1851 and can never be treated as a security mechanism. Thus, not having the Javascript is never going to be considered as increasing security level. In fact, this view was rejected by the National Institute of Standards and Technology(NIST)[1]. This is actually being called as “pseudo-security” by many IT Security sector peers.
To sum this up, by implementing the Javascript, security level was never reduced. With CIMB’s exercise of implementing a new password policy, they are actually increasing their security level gradually and in not any shape or form, reducing the old password policy. The level had been where they are all along.
Point 2:
“Coding is an artform, and any self respecting coder would not be using this piece of code to check for the passwords to his grandmothers basement, let alone on the front end of a major Online Banking system.”
Analysis – Point 2:
No comment
Point 3:
“Essentially, what the code does is this.
IF password CONTAINS SPECIAL CHARCTERS, ACCEPT WHOLE password,
IF NOT, JUST MATCH THE FIRST 8 CHARACTERS”
Analysis – Point 3:
This is not true. Let’s look at the code:
var format = /[~!@#$%^&*()_+-=[]{};’:”\|,.<>\/?]/;
if (format.test(password) && password.length >= 8) {
password = password
} else {
password = password.substring(0, 8)
}
The correct logic here is:
IF PASSWORD CONTAINS SPECIAL CHARACTERS AND EQUAL OR GREATER THAN 8 CHARACTERS, ACCEPT THE WHOLE CHARACTERS.
IF NOT, SEND JUST THE FIRST 8 CHARACTERS FOR SUBMISSION
The client side never matches any characters to anything. It just simply determines that if this is an old password format or new password format. If it is an old password format, then it should be impossible to have more than 8 characters in the first place.
Point 4:
“While this does not automatically grant anybody access to your account, it greatly increases the chances of someone who more or less knows your password habits to guess the right password.”
Analysis – Point 4:
This has nothing to do with the Javascript implementation. It is just simply, that the old password policy is already weak with having just 8 characters.
Point 5:
“Now, if your password was a combination of letters and numbers, it would be harder to crack, but there are a lot of people who use just numbers as their password. How long does it take to crack a 8 character all number password – about 5 minutes.”
Analysis – Point 5:
This is while in theory sounds very scary, with CIMB Click login system, it is simply not possible to crack a password within 5 minutes. The process of cracking a password itself is a process of testing if the password is correct. The only way to do that is by logging in or contacting/trying with CIMB Click login servers.
Only 3 attempts are allowed per account. After that, the account will be suspended as per the security procedure.
The probability of getting a password correct in just 3 attempts is almost impossible.
To get it into perspective, your chance of getting the password right is
The probability of finding in 3 tries is
3 in times
3/
4.5220193085866145017949888033745015142962308859368634 × 10^-16 *Note that we simplified into approximates since the number is so huge it is negligible.
Yeah, that is a load of zeros which approximates to zero chance of finding the password.
The article only goes as far as mentioning about logging in into CIMB Clicks so we will only elaborate until there.
Point 6:
“Some smaller banks around the world do turn to Google’s reCaptcha to keep away unwanted traffic because its free, and extremely easy to implement, but to say reCaptcha has been implemented to enhance customers’ security is nothing but a blatant lie.”
Analysis – Point 6:
By saying that “reCaptcha has been implemented to enhance customers’ security is nothing but a blatant lie.” is wrong. ReCaptcha does indeed benefit the customer or end user’s security by blocking automated requests, probes and vulnerability bots being constantly trying to find holes in the system.
Point 7:
“reCaptcha does not figure anywhere on this list for an organisation of this size.”
Analysis – Point 7:
Google themselves are using ReCaptcha to protect their website and servers. Cloudflare is one of a big organization that relies on ReCaptcha to negate DDOS attacks and bot swarms. This, in turn, put companies such as DigitalOcean, Zendesk and many more behind ReCaptcha under Cloudflare[2]. These companies have a higher bandwidth requirement and traffic than CIMB.
To put in perspective, CIMBClicks.com.my global ranking is 3,833 while digitalocean.com global ranking is 1,332. Zendesk.com sits at global ranking of 323.
This shows that websites that has more traffic(and attacks that come with it) than cimbclicks.com.my uses ReCaptcha.
Point 8:
“simply because there is no way of knowing the first 8 characters of the password, or even correctly guessing how many characters were in the password to start with just from the hash stored on the database.”
“So, unless CIMB has been only hashing the first 8 letters all the way back from 2011, it is looking very unlikely that the customers passwords were hashed.”
Analysis – Point 8:
According to that section, Lowyat.net seems to think that the passwords are not hashed because once passwords are hashed, you would no longer know what the individual characters are, and will be unable to get the first 8 characters to match with the user input.
While that is true, it doesn’t apply in this case, as old passwords can only ever be 8 characters long. Therefore, there’s not much point in saying “the first 8 characters”, as there are only ever 8 characters to begin with.
So far there is no evidence to suggest that the passwords are not hashed. Limiting passwords to 8 characters is not a strong indication and far from evidence of the system is storing unhashed passwords.
The only evidence of an organization having unhashed passwords are that they send you a plaintext password through email, their staff member could recover your password for you or there had been a data leak where every single password is in plain-text.
CIMB Clicks has none of this that we could see so far.
Bonus Review
Buffer Overflow
It sure sounds fancy but it is just not the case. We explained more about that in our previous article here. The mainstream media has nobody else to blame but themselves. A few prominent news outlet are citing and using this term in regards to the “CIMB Clicks Hacked” episode.
Some of the offenders are:
The Straits Times (Singapore)
Malaysia Internet (Malaysia)
The Business Times (Singapore)
Guang Ming Daily (Malaysia)
CNBC (Indonesia)
Worse of all, they’re citing the information from random Facebook users.
Here is a bit of free advice, perhaps contact a real security researcher for advise or run a fact check before publishing. This act of throwing around buzzwords is stirring up speculations, brewing unfounded allegations and creating a whole lot of misinformed readers.
Closing Statement
We strongly believe that as a media & journalism company, we should all educate the public with proper and accurate information at all times. Please reach out to us if you spot an error in the facts, we would be happy to amend and provide more accurate information.
Here is a good example from our friends at Pokde.net writing up not about the CIMB Clicks Javascript drama, but they apparently found out about something that could genuinely become interesting without using fearmongering headlines.
What the CIMB Clicks developer did was to just accommodate for new and old password policy seamlessly without disrupting the two groups of customers by maintaining systems consistency. This was done without any downgrade or reducing the existing or previous level of security and integrity.
It is agreeable that the old security policy was weak and flawed. However, the recent update of using the Javascript and ReCaptcha was not in any way, reduced the security level of the login system of the site.
We wish the Information Security community in Malaysia to be more objective and constructive for the betterment of our nation’s cybersecurity level.
“Beware of false knowledge, it is more dangerous than ignorance.”
– George bernard shaw
Co-authored with, Raymond Choo
Like our Facebook Page here at NasiLemakTech.com for more news and in-depth reviews! Also, join our Facebook Group for insightful information and memes!
Subscribe to our YouTube channel too!
