NextBigWhat brings you curated insights and wisdom on product and growth from the wild web.

Over 2 million people receive our weekly curated insights.

Newsletter

Newsletter

Updated: Payment Gateway CCAvenue Hacked

Payment gateway, CCAvenue has assured that its database is safe and rumors of system breach are false. Declare claims of breach by putting up screenshot of employee list to be mischievous act…

http://www.ccavenue.com/important_notice_hack_claim.htm

We would like to bring to your notice that today, an unknown hacker claimed to have hacked the CCAvenue database by exploiting “SQL injection vulnerability”. This claim is patently false and we strongly deny it.

Based on the investigations done by our security officials, we confirm that no hack has happened of our servers at 15:15 hours on 04th May 2011 as claimed by the unknown hacker. We also confirm that the screenshot shown by the unknown hacker to prove his claim of the hack has clear inconsistencies in the information.

Firstly, the information shown is not of our live database as the Apache Version on our live server is 2.2.17 and not 2.2.14 as claimed by the hacker. This update happened over 5 months ago. Secondly, we also confirm that all the passwords of our merchants and all login credentials in our live database are encrypted and stored in our database and not in text format as claimed by the hacker. The information shown in the screenshot is merely the employee list. Thirdly, the hacker’s claim of gaining access to sensitive data is not only patently false but extremely mischievous as we don’t store credit card details or net banking account details on our servers.”

All the facts given above clearly substantiate our contention that the database is safe. CCAvenue has
worked hard to build a strong reputation by putting in the best work practices for over 10 years. We
reiterate that CCAvenue is extremely cautious about the data security of its merchants, their clients and
its associates. We have consistently been at the cutting edge of technology when it comes to adhering
to security processes and we are adhering to the Payment Card Industry Data Security Standards. We
are confident that the facts mentioned above should be enough to settle the issue of the `claimed’
vulnerability of CCAvenue. We have always put our merchants’ interest first and have worked hard to
ensure that their precious data is safe.

Payment gateway, CCAvenue it seems was hacked by hackers via exploiting SQL injection vulnerability.

As per this site, Hacker identifying himself as d3hydr8 has shared the hack report with them and it seems that ccAvenue stored the password in plain text!

ccavenue_passwords

Below is a report belonging to this compromise

——————

[ + ] USER ()                         : iusr_ccavenueiusr_ccavenue
[ + ] S_USER ()                    : iusr_ccavenue
[ + ] DB_NAME ()              : gateway
[ + ] HOST_NAME ()         : AV-2
[ + ] SERVER_NAME ()   : AVDB-3
[ + ] SERVER_TYPE ()     : Apache/2.2.14 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.8e-fips-rhel5 mod_jk/1.2.28
[ + ] X-POWERED-By ()    : Servlet 2.5; JBoss-5.0/JBossWeb-2.1
[ + ] IP_ADDRESS_INFO  : 124.153.83.27

———————————————————————————————————-

[ + ] Displaying list of databases on this MSSQL host !

[ DATABASE: 0 ]        : gateway
[ DATABASE: 1 ]        : master
[ DATABASE: 2 ]        : tempdb
[ DATABASE: 3 ]        : model
[ DATABASE: 4 ]        : msdb
[ DATABASE: 5 ]        : Reseller

Storing password in plain text – and that too by a payment gateway? Well..god save the ecommerce industry!

We have reached out to ccAvenue for more details.

Update: Official word from CCAvenue CEO, Vishwas Patel

“From our side, we’ll have to look into it. It is not possible, because of the kind of application level firewalls that we have put up. We don’t store credit card numbers or any other kind of payment details because of the Payment Card Industry Data Security Standards, and there is no credit card or payment related info on our servers. There are new standards that have come in, that is PCI DSS 2.0, which are more stringent than the earlier standards, and we have just completed the assessment under that last week.”

Email from ccAvenue CEO, Vishwas Patel:

“Based on our intial investigations by our security officials, we confirm that no hack has happened of our servers at 1515 hours on 04th May 2011 by the following person as claimed in his article:-

******************************************************************
(+) Authors : d3hydr8
(+) WebSite : darkode.com
(+) Date : 04.05.2011
(+) Hour : 15:15 PM
(+) Targets : CCAvenue.com (Payment Gateway)
(+) Document: ESA.int Full Disclosure (Hacked)
(+) Method : Hidden SQL Injection
******************************************************************

We also confirm that that the screenshot is not of our live databse as the Apache version on live server is 2.2.17 (Updated more than 5 months months ago) and not 2.2.14 (as claimed by the hacker). < [ + ] SERVER_TYPE () : Apache/2.2.14 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.8e-fips-rhel5 mod_jk/1.2.28>

We also confirm that all the passwords of our merchants and all login credentials in our live database are all encrypted and stored in our databse and not in text format as claimed by the hacker. Also confirm that we dont store credit card details or Netbanking account deatils on our servers.”


Open Questions:

  • It’s clear that hacker has hacked the ccavenue DB (the table list shows it all, including a special table for rechargeitnow, which delivers quite a good business to ccavenue). Whether this was a staging DB or live DB isn’t the question (or its difficult to believe either of them, i.e. hacker vs. ccavenue). This is question of trust and ccavenue needs to come out clearly on security details of the data.
  • There are passwords (as we see in the screenshot). Even if these are passwords from employee tables, they shouldn’t be storing passwords in text format (even for dummy accounts).
  • Do they really need to store password? Apparently, ccavenue does. Though, we agree with this comment that“I would like to emphasise that a webapp should never store passwords (either encrypted or in plain-text) at all. They should store a hash of the password. Saving an encrypted password in DB is only slightly better than storing it in plain-text because once the machine is hacked, it would be mostly trivial for the cracker to retrieve the encryption key.
    Our outrage should be focused on the fact that they were storing passwords, not just that it was in plain-text.”

What’s your opinion?

Add comment