Shopclues is an Indian unicorn ecommerce marketplace. Every user who places an order on Shopclues receives a text message with a link to track the order.

The short links e.g. — http://sclu.es/3zlVa http://sclu.es/3zlVa, http://sclu.es/3zlVb, http://sclu.es/3zlVc were actually serially iterable, , .. etc are all valid links which reveals name, phone numbers, email, home address, order details of Shopclues users. A simple script to iterate over all of them can be written as follows:

We reported this to Shopclues in the first week of March 2017. We received no acknowledgment email from them. A separate email sent to their cofounders did not receive any response. We rechecked the issue on 20 March and it was not fixed but we found it fixed on 3 May 2017. The URL now asks for email id & phone number to confirm that the request is made by the authorised user.

Important Learning

As a developer its important to understand that you do not keep sensitive and private data behind short links without authentication — how short are short links, you ask? Lets do a little math to understand this, if the code is 6 alphabets long (all caps), we have these many possibilities:

You may think that this is a huge number, no one can guess any random link. And that would be correct except that depending on how many links you have generated till now, the guessability of links goes on increasing. Lets say you are an E-commerce website which has generated 1 million short links. Now if you divide:

On an average, with every 308 wrong guesses one will be able to guess a correct link. So, if you decide to put user personal sensitive data behind short links which can be accessed by anyone without authentication, think again.

The vulnerability in case of Shopclues was even more severe as they didn’t even randomize the short links (though it does look gibberish if you just look at a single link and not a bunch of links together), they have merely incremented it serially.

Do something to increase the sample space of non-working short links — make the sample space huge that it makes the guessing (almost) impossible.

Try a combination of these:

• Generate short links randomly, not serially.
• Use longer id in short links rather than 5 or 6 characters — determine the length depending on how many active links you will have at a time.
• If you really need to put sensitive data behind short links, you will have to use additional layer of authentication and authorization.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!

Shopclues user data leak via short links was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cleartrip is an Indian online travel bookings company provides services such as flights, train and hotels bookings for users in India and some other middle -east countries.

We discovered multiple vulnerabilities in public internal APIs of Cleartrip including -

1. Users full credit/debit card information leak including CVV and card expiry date.
2. Users itinerary and personal information data including name, phone number, email for hotels, flights and Cleartrip local bookings.
3. Users personal information leak for failed or in-process transactions.
4. An ability to mass cancel all flight bookings made via Cleartrip.

The vulnerabilities have since been fixed. We intimated the issues to Cleartrip starting 28 Feb 2017 along with our responsible disclosure timeline. Cleartrip was responsive throughout the process of fixing the issues and we helped with verification of fixes and to report other side-effects that emerged from applying the fixes. We received communication that Cleartrip has fixed all vulnerabilities reported by us on 3 May 2017. Here is our initial tweet contacting them since we were not able to find any security related email.

Fallible on Twitter

Hey @Cleartrip could you ask someone from your security team to connect with us or provide us an email.

One notable issue had a HTTP header which was leaking a URL which contained a serial itinerary id and the endpoint itself was not protected. The card details leak happened on an API endpoint which was supposed to pre-fill card information for different payment gateways in a hidden form. The data below has been redacted for user data privacy. We would publish the detailed technical details of the issues on our own blog sometime later.

A HTTP POST request made to the API Endpoint ‘https://www.cleartrip.com/payment/XXXXXX/redirect' with a data containing merchantTransactionId which is simply an integer in this case and could be run in a loop would spit out complete card details in a HTML form response.

<input type=”hidden” name=”vpc_SecureHash” value=”3A189D2ABE416355E604C371005445AE6AF93AF138A52E5FCA37B9FFF185ED45"/><input type=”hidden” name=”vpc_SecureHashType” value=”SHA256"/><input type=”hidden” name=”vpc_CardNum” value=”41476<Redacted>363"/><input type=”hidden” name=”vpc_AccessCode” value=”0<Redacted>EEE0"/><input type=”hidden” name=”vpc_MerchTxnRef” value=”CBC0227<Redacted>Q<Redacted>V”/><input type=”hidden” name=”vpc_TicketNo” value=”59<Redacted>0"/><input type=”hidden” name=”vpc_CardExp” value=”2110"/><input type=”hidden” name=”vpc_CardSecurityCode” value=”<Redacted>"/></form><br />

We would again like to remind users that assuming compliances like PCI-DSS would make you safe from attacks is not intelligent. Compliances are done with the sole objective of checking boxes and move on. The compliance processes most of the time lack the required time & skills to uncover vulnerabilities that might be exploited by a sophisticated hacker. The same goes for talking about ‘being safe from OWASP top 10’. There is a lot more to security vulnerabilities than OWASP top 10.

At Fallible, our key focus area is automation of detection of generic security vulnerabilities in APIs. We believe security vulnerabilities like these corresponding to HTTP APIs needs a technological solution available to everyone running a web service and not a process based solution like bug bounties that only benefit corporations actively running a bug bounty and exploiting the purchasing power difference around the world waiting for someone to report an issue. There have been advances towards making ‘intelligent WAFs’ but most attempts have been unsuccessful. We have been spending some time thinking about the problem in the past few months and are testing various alternative strategies for the same.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!

Security vulnerabilities in Cleartrip.com was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

GO-JEK is an Indonesian unicorn transport startup, often seen as the most famous and biggest startup to come out of Indonesia. GO-JEK provides services like biketaxi, cabs, food delivery, mobile payments ticket booking and more.

At Fallible, one of the things we are working on is to try to accurately automate data leak detections even in complex logic flow scenarios and non-standard auth procedures used. During a security audit of GO-JEK public APIs consumed by mobile applications, we found multiple security vulnerabilities in GO-JEK. We contacted GO-JEK with the a sample of data leak for Mr. Nadiem Makarim, the CEO of GO-JEK (partial redacted screenshot below). The GO-JEK response in June 2016 was that they are fully aware of all security issues and fixes are in the current roadmap. We recently contacted GO-JEK and we were confirmed by their CISO that it was alright to do a public disclosure of the vulnerabilities now.

Vulnerability #1 Ride History Data Leak

You can get a list of all rides taken of any user using this API endpoint including the exact GPS co-ordinates. The Authorization token is present but is not being used for validation.

https://api.gojekapi.com/gojek/v2/customer/v2/history/551925748

Vulnerability # 2 Order details Leak

Get the details of orders placed via Go-jek API:

https://gobox-api.gojekapi.com/v1/users/551925748/history

Vulnerability # 3 Users Data Leak

You can get user personal details by their Id number using this API endpoint. This includes their phone number, name, drivers personal details, location of pickup and drop and other ride related information.

And the response would contain phone number of rider and driver along with origin and destination coordinates.

Unconfirmed # 4 Get other user’s Android notifications for GO-JEK

An unusual vulnerability we detected was that you could use another users id in an API endpoint and and you are all set to snoop on GO-JEK notifications meant for that user. We are researching this vulnerability to see if this can lead to several other stuff and would refrain from disclosing the API endpoint for this.

There are several other API endpoints that can be used to corrupt user data & disrupt operations. For example, you could change the reason of cancellation of rides for all cancelled rides for all users. We would refrain from mentioning the write access APIs at this point.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!

Security vulnerabilities in GO-JEK was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

UPDATE2: The McDonald’s fix is incomplete and the endpoint is still leaking data. We have communicated this again to them and are waiting for their response.

UPDATE1: McDonald’s India has replied to us that they have fixed the issue and would be releasing an official statement urging their users to upgrade the app.

The McDonald’s India app, McDelivery is leaking personal data for more than 2.2 million of its users which includes name, email address, phone number, home address, accurate home co-ordinates and social profile links. We contacted McDelivery on 7th Feb and received an acknowledgement from a Senior IT Manager on 13th Feb (33 days ago). The issue has not been fixed yet and our continued effort to get an update for the fix after the initial acknowledgement has failed.

An unprotected publicly accessible API endpoint for getting user details coupled with serially enumerable integers as customer IDs can be used to obtain access to all users personal information.

The lack of strong data protection and privacy laws or penalties in India, unlike the European Union , United States or Singapore has led to companies ignoring user data protection. There is a similar lack of push from non-government organisations to improve this scenario. We have in the past discovered more than 50 instances of data leaks in several Indian organisations. In fact, we are pleasantly surprised when we find Indian companies without a personal or payment data leak vulnerability in their APIs.

API Endpoint : http://services.mcdelivery.co.in/ProcessUser.svc/GetUserProfile

A sample response to the curl request:

Disclosure Timeline:

• 4th Feb’17 — Fallible reported the issue to McDelivery
• 13th Feb’17 — Issue acknowledged by McDelivery IT Manager.
• 7th March’17 — Fallible sent an email asking about the status, no reply from McDelivery.
• 17th March’17 — Fallible sent another email; No response from McDelivery;
• 18th March’17 — No response yet. McDelivery users are still vulnerable. Public disclosure.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!

McDonalds India is leaking 2.2 million users data was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Data leaks in consumer tech companies effectively exposes their users to a variety of issues including identity theft, physical scams, spam and even threats. There was a recent incident of prepaid mobile recharge shops in India selling phone numbers of random women for money. Phone numbers also enable search on Facebook.

Here is the complete email we sent to disclose the vulnerability along with the technical details. (The extra HTTP headers for 3rd party services in the curl request have been removed and auth tokens changed. We have also removed the curl response with users personal data.) The API uses a JSON Web Token (JWT) for authentication that is possibly consumed in apps being used before the pivot. Post pivot, the company added another JWT for newer apps but kept on using the earlier code to fetch authenticated user-id from the old token leading to open access to all user data. The JWT when decoded contains the following data, with the id being a small integer that can be iterated and new tokens created to fetch corresponding user data.

{“user_name”:null,”id”:XXXX,”mobile”:”YYYYYYYYYY”,”expires”:180558878080}

Hi Founder,

We have researched a security vulnerability in your API used by mobile apps that exposes your users personal data including possibly email, phone numbers, name and address. Here are the technical details to reproduce the issue. We are assuming to support both Akosha and Helpchat clients through the same API, two JWT Auth tokens are being used with only the Akosha one being verified but the authenticated userid for this endpoint is being extracted from the Helpchat token. The userid in the Helpchat token can be changed and a script enumerating all user ids can be used to fetch all user data. A sample data extracted is shown below the curl request.

Please do let us know when you fix this.

Regards,

XXXXXX

https://fallible.co

curl -H ‘Host:api.helpchat.in’ -H ‘User-Agent:helpchat/3.2.1.1 CFNetwork/808.0.2 Darwin/16.0.0’ -H ‘X-HELPCHAT-AUTH:eyJ1c2VyX25hbWUiOm51bGwsImlkIjpYWFhYWFhYWFgsIm1vYmlsZSI6IlhYWFhYWFhYWFgiLCJleHBpcmVzIjoxODAwNRc4=.ODc4MDgwfQUzaVoPFAQsLwsHTjxC0YA=’ -H ‘Connection:keep-alive’ -H ‘X-APP-VERSION:3.2.1.1’ -H ‘X-AKOSHA-AUTH:eyJ1c2VyX25hbWUiOm51bGwsImlkIjpYWFhYLCJtb2JpbGUiOiJZWVlZWVlZWVlZIiwiZXhwaXJlcyI6MTgXMDU1ODg3ODA4=.MH0FM2laDxQELC8LB048QtGA’ -H ‘Accept-Language:en-us’ -H ‘Accept:application/json’ -H ‘Content-Type:application/json’ -H ‘Accept-Encoding:application/json’ ‘https://api.helpchat.in/consumers/v1/customers/me/'

Mail responses:

#1

#2

#3

#4

This was the last email we sent on 10 Feb 2017 asking if a fix has been applied. We have not received a response yet but have verified that the bug has been fixed. This sad practice of not communicating at all with security researchers or not allowing a public disclosure after fix is sadly more prevalent in South Asia than other mature markets. We sincerely hope the companies become more aware and at-least inform their users of the security issues.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!

How a startup pivot led to users data leak vulnerability was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Some of the people on the HN thread suggested we should inform the users that a key was being leaked. There is no way we could inform millions of users without being banned from GitHub due to abuse. If there is someone who could do this the best, it is Github the platform where the secrets are exposed and with an army of engineers it is a matter of couple of days to do this. We are open to work with GitHub if they would like to make secret leaks detection a feature on their platform.

Another point of discussion was we were “exposing people’s secret” which is funny since the data is public and the secrets are searchable via the GitHub interface. We simply optimised the search to focus on secrets and provided a way to check your own GitHub account for leaks. Shodan, the popular search engine for open ports is seen as a great infosec tool even when it can be used for bad purposes with their paid account. Insecam lists realtime stream of thousands of open IP cameras around the world. Someone writing or publicising that a website does not use HTTPS does not make them a criminal. Products like Shodan, Insecam or GitLeaks will eventually make the world more secure.

Now coming to the paid accounts. We have limited queries to 30 per month for free users who are logged-in. Taking a leaf out of Shodan, we will display only the first page and not two pages as earlier if you are not logged in. Maintaining and working on the search infrastructure costs us real money and the paid accounts are simply a way to cover the costs. If you are feeling generous, please contact us at gitleaks@fallible.co and donate to cover our annual cost and we will stop the paid accounts.

The next point was about abuse by criminals. It would be extremely naive to assume that the bad guys are sitting waiting for products like GitLeaks to come out in order for them to exploit. The best way to go about is always creating awareness and not pushing matters under the rug. We have already limited search results for anonymous accounts to a single page of result and would be denying use from newly created GitHub accounts (accounts created after GitLeaks release) since there is no value for them right now anyway.

Will Strafach on Twitter

wow, https://t.co/VqjVFBbQl9 was a very nice idea. it is a shame to see that they took the search down due to silly criticism.

Around 10000 people tried to use GitLeaks.com on 17th February. Most of them left disappointed after being greeted with our message of disabled search and pointing to the discussion. We are sorry. GitLeaks is now open and we shall be adding new sources, features and refresh the data over time.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!

We are resuming GitLeaks.com was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

In Nov’16, we created an online tool to reverse engineer any android app to look for secrets.

This tool was built because of an internal need — we were constantly required to reverse engineer apps for our customers to examine it from a security standpoint. We felt the process could be automated to a point where we could create a web based tool which could be used by anyone. Couple of months after releasing it, users have reverse engineered approximately 16,000 apps and here are some of the interesting findings.

Out of 16,000 apps, most of the apps didn’t have any sort of key or secret in it. Roughly 2500 apps were found to have either a key or a secret of a third party service hardcoded in the app. Some keys are harmless and are required to be there in the app for example Google’s API key but there were lots of api secrets as well which definitely shouldn’t have been in the apps. There were 304 such apps.

These secrets belonged to a lot of different 3rd party services, for example Uber’s secret which can be used to send in-app notification via the uber app.

Then there were AWS secrets too hardcoded in the apps. Some of them had full privilege of creating/deleting instances.

Following is the list of popular services whose secrets were found in the apps.

Takeaways

For app developers reading this, whenever you hardcode any API key/token in the app, think hard if you really need to hardcode this, understand the API usage and the read/write scope of the tokens before putting it in the apps.

For 3rd party services, clearly warn/instruct the developers to not to put these secrets in the apps. Create multiple API secrets with different scopes if required.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!

We reverse engineered 16k apps, here’s what we found was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

It should be noted that your users data leak can happen from any of the third party softwares including customer support, analytics and . If possible, try to minimise sending a lot of personally identifiable information to other system other than what is absolutely required. It should be noted that a vulnerability was disclosed by Zendesk, a Freshdesk competitor in the past.

Here is the mail that was sent to Freshdesk describing the technical details of the issue.

Hi XXXXX,

We have researched a security vulnerability in Freshdesk that exposes user data and chat history for any user, given their email address on all [sic] of Freshdesk customers. The Freshdesk mobile SDK has a design flaw that exposes read functionality on /mobihelp endpoint. We advise you to verify this issue, notify all your customers and do an internal assessment of all your customer data and audit logs to check if any of their data was compromised in the past. Please do let us know when you fix this issue. We would be informing XXXXXX-COMPANY and XXXXXX-COMPANY about this issue later today.

STEPS TO REPRODUCE:

1. Make a request to the given URL with a unique device uuid and the victim’s email address. You will get an API key.

URL: https://bookmyshow.freshdesk.com/mobihelp/devices/register_user?format=json&pt=ios&sv=v1.6.5

REQUEST BODY:

{

“device_info”: {

“device_uuid”: “51BCA4F4–4826–499D-93D2-F3A53C4630A2”,

},

“user”: {

“external_id”: “913934”,

“email”:”victim@email.com”

“name”: “Victim”

}

}

RESPONSE BODY:

“api_key”: “Bo5PcxU45HiJCT26Rfdq”

2. Encode the API key with base64 for further use

Base64encode(Bo5PcxU45HiJCT26Rfdq:x)

3. Use the Base64 encoded string in step 2 in the Basic Auth header and make a GET request to the following URL

URL:https://bookmyshow.freshdesk.com/support/mobihelp/tickets?format=json&pt=ios&sv=v1.6.5

Authorization: Basic Qm81UGN4VTQ1SGlKQ1QyNlJmZHE6eA==

4. The response will contain the ticket/chat history and possibly personal information somehere in it.

We conducted an informal security audit of Uber competitors in South-East Asia. We discovered multiple instances of severe vulnerabilities. GoJek expressed their gratitude for user personal data leak issues. Grab fixed their issues promptly and doled out multiple bounties ranging in several thousand of dollars.

Based on our experience this year, we found one of the major vectors for security vulnerabilities is leaked secret credentials, be it passwords, API tokens or keys. We created a small tool to test Android apps for secret leaks which was used over 12000 apps in less than a month by over 8000 developers from various organisations. This tool resulted in identification of credentials leak in world’s leading travel aggregator, Adobe, ASUS and Lazada, some of which resulted in bounty payouts.

We went on a trip to the Bay area on an invitation from YCombinator for interviews. YCombinator runs a very competitive accelerator program for startups with acceptance rates of less than 0.5% for the interviews and 0.1% overall. It was a great experience but unfortunately we could not make it (not big enough market in India+Startups). We got to meet some really awesome people and couple of other VCs in Palo Alto area. It was a great learning experience with feedback, anecdotes, travel. We did not apply to any other major accelerator program.

We started writing a guide focusing on best practices for web developers and it got good response from developers, making to the top 20 repositories in 2016 and top 150 starred repositories out of more than 50 million on Github. The guide is still not even midway with multiple edits required as we could not allocate enough time to complete it, Sorry folks. We hope to complete this in the coming year. There is an interest from a leading publisher to convert this into a book, but we are not very keen on it yet. It would mean years of effort, not something we can afford right now.

Cybersecurity in India

India has recently banned around 90% of its currency notes. This has lead to a rise in digital payments. With low credit card adoption, digital payments in India is dominated by debit card payments and mobile wallets. The security of Indian payments infrastructure, ranging from payment gateways, mobile wallets to POS companies is a joke. The vulnerabilities in major payment gateways and wallets include multiple ways of data leak, monetary loss, private keys leak and more. In the past month, we have responsibly disclosed security vulnerabilities in 2 major wallet companies. While we sit here waiting for making a responsible disclosure post the fixes which are not going to happen as sometimes it needs changes on the merchants side, your data is out in the open.

After a report of data leak in IRCTC, we independently verified the issue and informed IRCTC, post which after multiple emails, the issue was patched silently without informing the users. We are still unsuccessfully filing RTI first appeal and second appeals as to why this incident was not disclosed publicly post the fix, since it is the users personal data and secret credentials, which most of us reuse across websites.

There is no security breach notification law in India. NONE of the more than dozen companies we informed of a breach have ever informed their customers of a breach. We wish the elders of the Indian internet would work on a movement regarding this along with good stuff like Save the Internet. This would prove more useful in our opinion.

We also received a lot of calls at odd hours from Indian startups with poor security hygiene, who did not bother until they were DDoSed, their data being sold on the Darknet or were victims of ransomware. Unfortunately, there is not much you can do after you are struck by a huge DDoS or ransomware.

Learnings

• Get a good CA to advise on taxation, logistics and accounting. We made a mistake which cost us a bit.
• Despite all the hoopla surrounding lean startup, if you have a small team in India, VCs will hate you, prospective customers will think of you as some shady organisation. Apparently, hiring without need and fit is considered to be signs of growing fast.
• If you have a SaaS business with customers in India, you need to have a recurring plan that deducts payment automatically without going through the hellhole of raising invoices, talking to accounts and waiting for your money. The best solution — Incorporate in the US and use Stripe. We were one of the early beta users of Stripe Atlas, where Stripe incorporated our US entity and provided us with bank accounts and all.
• We had to increase our prices 4 times. If we could redo it, it would have been better to start with a higher price.
• Your point of contact at a particular customer can leave, sometimes not on the best terms with the current company. Always have a backup point of contact at the same level or higher.
• Say no to steep discounts. It is not worth it. We have lost couple of customers over it, but it is worth the cost.
• Log everything. Patch everything. Watch out for security vulnerabilities in 3rd party SaaS you use. They will bring you down.
• Hiring for tech outside of a generalist profile is super difficult. You do not get 5 relevant resumes out of 500. And then there are recruiters disturbing you wanting to talk to your HR. There is no HR. If you wish to work with us please apply here https://angel.co/fallible/jobs/157321-software-engineer-security-r-d
• If you are solving a real problem for people who can pay for it, you will hopefully make a decent fairly large company without drinking the Kool Aid. Patience. Umm, this was for me :)

The road ahead

We can do better by defocusing from India. We intend to diversify geographically and move away from large startups to larger stable enterprises. We have been busy working on a new SecOps product for enterprises for some time. We intend to release it in the coming year after piloting it with our Managed Security Plan (MSP) customers. We intend to go forward with this and our running MSP adding more checks and platforms in 2017. We will have a lot more to share in the coming months. We are loving doing this. We hope to create better products that help our customers improve their security posture and bring more happy customers and $$$ to us.

You can talk to us at hello@fallible.co You can signup for our Managed Security Plan here.

Enjoy the holidays and wish you a happy new year!

— Everyone@Fallible

30 Mar 2016

During the recent months we have discovered,

• One of the most popular PCI DSS Level 1 certified payment gateways is leaking complete credit card details. The gateway claims to do more than 15,000,000 transactions on a monthly basis.
• Another popular payment gateway is leaking partial credit card and user personal information which can be used to engineer a variety of attacks.
• Yet another popular payment gateway has a request data integrity protection which can be cracked using a commodity grade gaming PC within a week (verified), thus allowing free access to virtually anything that is being sold online in India and the transaction history of users.

We have already intimated the respective payment gateways and they are working on the fix but, we are afraid we might not be the first to discover these vulnerabilities. As India still doesn’t have something similar to data breach intimation law in the US and based on our experiences from intimating severe data leaks to more than 15 companies, we do not think the companies will ever make this information known to their end users.

This is a general notice to the public to ensure that their cards are safe. Hackers generally do not attempt to use all the cards as soon as they get access to, so it is requested that you monitor your charges and statements or better disable current cards if possible. Domestic only debit cards which cannot ever work without CVV/ PIN and OTP can be assumed to be safe.

Companies name retracted due to frequent calls.

We will come back with more information regarding these issues once the respective companies have fixed the bugs. We know that no company wants to leak their customer’s payment and personal data and it will be a difficult and time intensive task to fix some of these issues.

At Fallible, we are building products to secure large organisations and startups alike. Contact us at hello@fallible.co

Originally published at fallible.co on March 30, 2016.