This was all dummy code designed to trick a “hacker” who would be looking for that file and give him all wrong information. Not any sensitive information that log is correct and from our logs Martin told you it was sample data. Our front end is on wordpress, we know what we have that is sensitive vs openly available while we are installing our new data servers.
Centra Tech is a startup in the cryptocurrency world that I’ve recently wrote about and given my thoughts on their operation.
For those that don’t know, Centra Tech is a company that will issue debit cards using Visa and Mastercard technologies to make payments with your cryptocurrency coins at pretty much any place that accepts Visa and Mastercard payments. They’ve raised over $5m usd in their ICO with many days left.
Their workflow is basically handling client coins ($BTC, $ETH, etc) in escrow whilst crediting your account with fiat to spend, relying heavily on predominantly open-source software (which was discussed by their CTO; Sam Sharma, in an interview with Clif High.)
I see nothing wrong with this, as long as you’re properly audited for security and integrity, you should be good. My concern is now this;
On Sunday (August 06, 2017) evening, I find a publicly accessable directory on their webserver with data that shouldn’t be public; namely their MySQL credentails, salts, and authorisation keys.
I quickly informed Centra Tech (speaking to “Martin” over live support), and they said they’ll patch it up, (offer me a bounty - which I didn’t get :( (but that’s not the issue I have with them), and issue a statement to their users notifying them of the security “breach”.)
Here’s an exerpt of the chat transcript;
[...] [22:30] Martin: We will address this right now however. Thanks [22:31] harry: Will you release a statement? [22:31] harry: If not, I will be [22:31] harry: Considering your product requires a security audit, you've raised millions, and will be dealing on user funds on their behalf. [22:31] Martin: Yes we will be issuing security related statements [22:32] harry: When? [22:32] Martin: I will check with PR most likely Monday [22:32] harry: So, tomorrow? [22:32] Martin: yes [22:32] harry: I'll give you until 00:00 Monday Night GMT [22:32] harry: If you don't release one, I will release one. [22:32] harry: OR do it now [22:32] Martin: Okay Harry we will thanks [22:33] Martin: It will come from the appropriate department [22:33] harry: Get them online [22:33] harry: This is a red alert for your product [22:33] harry: get them to handle it [22:33] Martin: Our website is a registration portal [22:33] Martin: Thank you [22:33] Martin: I will be on top of it [...]
They’ve since then removed the public file (though the directory is still publically viewable), and I thought “great”, they’re going to do what is neccessary, and notify the public. So I left Monday to them, awaiting their statement release.
I wake up Tuesday (since I have them until 00:00 Monday) to see a new blog post - ready to see what they had to say about the situation. But… nothing. Nothing mentioning their incompetence with basic security, or any responsible actions that were promised and should be mandatory for a company in the financial industry. This is a complete avoidance of their responsibility to their customers, so I must deliver on my promise to release the news as they have failed to do so.
We are mainly interested in line #5462 which is a dump of their configuration file.
What I fear is that this will set a precedent with their security audits & breaches by not properly and timely informing their users.
This ties back to the bigger picture. For someone in the crypto space where scams and hacks are everywhere, this type of laziness and lack of dilligence and transparency should not be accepted.