Topic: Camp BX Hacker / Security Audit: Results - page 2. (Read 15921 times)

Thank you OP. It is great to see free-market certification solutions meeting the needs of customers, instead of ridiculous government laws "mandating" security.

Cheers to you, I've opened an account.

Keyur,

I have to say that I feel you have done an excellent job in responding to customer questions and issues. Far more so than any of the other exchanges, although I will say in all fairness that I think TradeHill does a decent job as well.

It's good to see that your team is taking security very seriously, and I enjoy knowing that CampBX is taking a multi-tiered approach towards security. I'm obviously biased being in the United States, but it's reassuring to see you playing by all the rules and regulations. I think you guys are positioned to do very well.

I already have some of my BTC on your site, and I will probably have more in the future.

Keep up the good work!

Jim,
     Agree with you 100% - Coming from a corporate background we consider what you mentioned essential for security.

Our servers are housed in a physically secured data-center designed to survive F3 category tornadoes (if I am not mistaken), and have connectivity with three telco backbones.  There are two Caterpillar diesel generators for extended power outages.

We have identified primary and secondary owners for Wallet, and only these two people have access to it.  
Same goes for the database.

We also background check our employees as part of the security policy, and have a matching MSA with contracting firms.


Thank you,
      Keyur

PHP/MySQL do not have any specific vulnerabilities that are not also present in comparable other languages/platforms. They are not any worse of a language/platform than any other.
That most vulnerable sites are written using PHP/MySQL, does not mean that all sites using PHP/MySQL are vulnerable. Correlation, causation, etc.

Error,
     Thank you very much for a thorough and unbiased review of the McAfee result.  We really appreciate this from you!

Wanted to add that we have a patch and upgrade schedule in place for our environment.  Admins prioritize patches based on criticality, and test / deploy them accordingly.  For majority of software we are on most recent codebase.

Thank you again,
     Keyur

It's a start, but security for a financial institution takes a whole lot more than an automated test. You need to think about things like managing an offline wallet, physical security for that wallet and for your servers, and background checks for employees. You need a non-automated inspection by an expert, who will actually take the time to look at your source code.

If you run a Bitcoin exchange and it takes off, you aren't just up against script kiddies.

Right, or to put it another way, 96% of the script-kiddie hackzorz have no shot.

I'm dubious of offerings from big corporates like MacAfee -- they might be more show than go, because there is a PR aspect for both sides (PR = lies).

Nevertheless, kudos to Camp BX for getting *some* accreditation from an objective third party.  Sure, a top-drawer hacker might still be able to waltz right in, but at least there is a real barrier to entry.  That's a lot more than some exchanges can say, and it shows that they've made a commitment to doing it right.

Thanks for reading through the report, error.

Now we should ask them about their plans for two-factor authentication, because they might not have thought about that yet...  ;-)

OK, my opinion is as follows. If you find it too long, there's a brief summary at the end. In the interest of full disclosure I must say that I signed up for Camp BX today, just like many of you, though I have yet to make any trades there.

Keyur sent me a copy of a McAfee security report dated June 30, 2011, for review. McAfee generates several types of reports after each scan. The report provided was the "Executive Report." This report states whether the site scan passed or failed and gives an explanation and summary of the results. This comprised the first four pages. The next 726 pages of the 730-page document listed all of the tests that McAfee may perform on a server, though without specific results. In short, this version of the report was designed to beat clueless CIOs over the head with and to keep the company lawyers quiet.

The results showed that the site passed scanning, with 29 severity 1 issues, and no issues of severity 2, 3, 4 or 5. An explanation within the report states that in order to maintain PCI compliance, the site must have no issues of severity 3 or higher. (Severity 1 issues are typically pointless blather; some examples I have seen elsewhere are: "Your site has a DNS server," "Your site is running Drupal" etc.)

The report provided did not give specific information as to the issues identified. This information is in a separate technical report. I asked Keyur for a copy of this report, explaining that my opinion would be limited without it. Today he contacted me and stated that he would not provide a copy of the technical report as it contains server information that he did not want to be available outside his organization, even under a confidentiality agreement. This is quite understandable.

Now for some background.

When one of these security scans identifies an issue, this is what happens. Let's say for instance that you have an SSH daemon running on your server. You almost certainly will, since this is how your administrators will make a remote connection to do normal system administration stuff. McAfee or whoever will connect to the SSH daemon and check its version, and then check the version number against known vulnerabilities. If the version number is one that's known to be vulnerable, then you get an issue. Depending on the specific vulnerability it could be anywhere from severity 2 to 5, where 2 is not very serious and 5 is fix this yesterday or you're going to be pwn3d.

So this issue pops into your next report and you have to deal with it immediately or lose your certification. In the case of the SSH daemon, the original authors of the daemon patched the issue and released a new version. Now if you were smart and bought an off the shelf Linux distribution like Red Hat Enterprise, then you are mostly guaranteed that versions of various critical software on your system won't change for the lifetime of the distribution. It will always have the specific version number of the SSH daemon (and anything else on the system). Enterprise distributions lock versions in this way to guarantee that various APIs and ABIs don't change and break the applications you deploy. So Red Hat will take the security patch from the SSH daemon, leave the rest, and give you a patched SSH daemon with the same version number, and only the security patch applied.

But this is a problem for McAfee since they really don't know you've applied such an update (known as a backported patch) unless you tell them. So one of the ways you can resolve that issue and keep your compliance is to tell them you upgraded your SSH daemon to the patched version that Red Hat provided you. The trick here is that this may or may not be true and McAfee has no way of knowing from an external scan, without actually attempting to exploit the vulnerability! I don't believe that any of the security scanning services go this far with system daemons (though they do with web app security such as SQL injection), as attempting to exploit some vulnerabilities can disrupt production servers.

TL;DR:

It appears that Camp BX is being responsible with server security. The report provided to me showed that it passed McAfee SECURE and PCI compliance. Keyur has also told me that his team responds to anything of severity 2 or higher within 72 hours. (Severity 1 "issues" typically are merely informational.) However, the external security scan services themselves have limitations, in that some of the information necessary to determine whether site services are vulnerable is self-reported rather than being scanned. This is a limitation of all such services. I can offer no informed opinion on whether Camp BX's system administrators are actually applying system updates from the operating system vendor, or on what schedule, as this information was not provided to me.

This actually took some time and a bit of work. If you found it helpful, feel free to send some BTC or fractions thereof to 15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W .

I've written some contracts there, but they are struggling with the MtGox API and it's just kind of amateur looking. I don't wanna risk a whole lot of money until the site grows up a little.

The Gods have spoken to us!  Thank you error - PMing you.

I've done PCI compliance stuff for Free Talk Live; I'd be happy to review your report in strict confidence and offer my opinion.

Thank you Keyur for such great responsiveness!
Your rate is looking great!

bitoption.org

But, if a big site that could actually get some volume going that would be awesome.

Got it!   We are at 0.55% for non-margin trades.

Thanks. I actually live in the States, but was wondering if you'd work on global scale.

Any word on your rates?

Thanks Keyur, I am aware what they offer, I talked to them at some length.   Here is their three products.  There actually aren't different tests involved between the three.
http://www.mcafeesecure.com/us/products/compare_products.jsp

Yes, you fill a questionnaire out and then the tests start.  Then the tests are the same every day.  I understand.   I am just saying to admit to what this actually is. 
 
No doubt you have logs full of tests, no one is questioning you signed up and did Mcafee Secure.  The tests in your logs will be the standard tests that the Mcafee Secure Daily PCI scan gives to every website that pays for that service.

Itsagas,
      I think there may have been couple of miscommunication on your call - McAfee has three products.  (1) McAfee Secure  (2) McAfee PCI Certification, and (3) McAfee Saas Vulnerabilities Scan.

Sales teams are not the best source for technical answers.  Please open a ticket with their support team, who will be able to tell you far more details.

Essentially, the test includes a set of probes to guess what software / versions you are running, and then the specific tests battery starts.  I have the full log available to me, and can share it with a reputed member of Bitcoin forum for independent verification.

And as I mentioned couple of messages back, McAfee is just one facet in our approach.  We are using everything from Nmap to peer-reviews to find holes before launch.

Hope this helps,
      Keyur

While it is great you have had this done, this is mostly marketing.   Unless there were some other tests done, you are being very misleading on what this really means.

Ranked #1.  When and by whom?

Really?  How were the tests specific to your platform?  To my knowledge, and after talking to them on the phone today, there is only one McAfee Secure product.  It is a standard daily PCI scan that is the same for everyone that buys that product.  You can be set up and them scanning you in hours by putting some code on your site.  As their rep said on the phone  "it is all in the cloud, you just put the code on your site and we scan every day."      

The trustmark is just a badge you get for passing all the automated tests every day.  It is a marketing "bonus" to show your customers you got the scan done, there are no additional tests involved.  They even say on their site that by displaying the badge customers got "12% increase in sales conversions"

Is this what McAfee says you have passed from using their McAfee secure product?  Or do you have other tests?  

These logos and shit are just an expensive way to demonstrate that the simple bases have been covered - something that MtGox's previous implementation would have failed to achieve, and I'm not even sure the new implementation would pass as easily as MT seems to think it would (writing your own DB abstraction layer from scratch? Really? You know the site probably would have been recovered a lot quicker if you didn't spend time reinventing the fuckin' wheel, right?). Yes, it's not anything that couldn't be checked with ./nessus - but the point is they spent the money having a third party demonstrate it, instead of saying "take our word for it".

Only a fool really thinks a "hacker safe" badge means "hacker safe", it's just an over-paid but very public way of demonstrating they probably won't fall for the dumbest of shit.

FWIW, hackers don't get into .gov boxen because of the government's weak security standards, they get into them because some asshole doesn't implement the standards correctly or completely when in practice.

Edit: ...and yes, your question about response to breaches is pertinent. My guess is, losses are not covered. To my knowledge, there are no FDIC-style things that apply to Bitcoin - ever. You probably won't have any luck finding a private insurance company who'd insure against Bitcoin losses either because of the wildly fluctuating (and potentially skyrocketing) valuation of them, and even if you could I'm sure the cost would be prohibitive for such an exchange to ever get off the ground.

I would be interested in performing a penetration test, however only with written consent.