Topic: What can really be done about server hacking (Read 8328 times)

me to but now that you say "e to the i pi" and I look at his avatar that's what it has to be. Now it makes sense.

Nice, thank you for taking the time to respond.

I am up for this, i guess it is time to get over python forcing me to indent...

I will take a look early next week and send you a mail or two.

Just out of interest is your username "e to the i pi"?

I keep reading it as ethiopia

cheers,

steve

This is most interesting!  

I actually purchased a couple USB-to-serial cables and a null-modem converter and had started to play around with this myself.  I got as far as determining that it would work, for $25 in cables, and when I get done with some other crazy priorities, I plan to develop and integrate a serial-port interface into the GUI for the hardcore users.  It's a promising idea for filling in the "optimal" usability-security curve...

Unfortunately, Armory code is extremely well-commented, but there's not a lot of top-level documentation for using it.  Again with the priorities...most users are using Armory instead of developing with it, so I haven't spent much time on the developer documentation.   However, there is a lot of example code in the extras/sample_armory_code.py file, which shows a whole bunch of different ways to access the armoryengine tools from python.  Loading & querying the blockchain, reading wallets, scanning for balances, iterating over all blocks/txs/txins/txouts.  It needs to be cleaned up a bit, but obviously it is usable since Armory is built with it.

And, I'm always willing to help other developers dig in.  Please PM or email me if you have any questions about leveraging specific functionality with the library.  I would be pleased if someone else was able to expand the functionality like this while I work on some of the more critical stuff (like making sure Armory still works at all, after the blockchain exceeds 2 GB...)

Just purely for my own interest. Thanks for sharing.

I think so, I think someone would be able to do this will little effort, maybe get the bloke who maintains the armory to see if he fancies doing it.

from the faq

I have mainly been focusing my efforts on component searching (for mistfgpa) and getting the bitcoin testing project off the ground, so this is fighting with a couple of other things for my time, however I am getting a bit more inspired.

I will take a look at this over the weekend and see if a couple of the mistfpga boys want to help.

I will probably start another thread, but I think I have a reasonaoble way of solving a lot of the business rule issues.  create a hash of rules that are in use on server A (this has to be done before it ever goes online.  store this hash in the hsm, then pass the business rules across with the transaction, check them by hashing, if they are different, computer B shreds keys and blue screens kernel panics. thus encrypting the drive.

edit: although I would like to run this on a RTOS, like QNX (ignore the RIM purchase, QNX is nearly military spec posix.)

The thing that would make this a lot quicker would be if i could code properly in c/++ or even python, perl and x86 assembler are my day job bread and butter...

just out of curiosty, are you intersted in this for academic reasons or do you want to use a system like this at home?

cheers,

steve

Ah I see, interesting way of doing it. I wonder if the offline transactions functionality is available in API form to make the proof-of-concept easier  faster.

Sure no problem,

Do you mean like a setup guide or data flow?  i more or less tried to implement what death and taxes has already posted for the poor mans hsm. I was not trying to secure anything, just prove to myself that the armory client can handle this with little extra work.


I intend to address all the issues, but for the moment i just wanted to make sure that the concept would work before i invested any more time in it. I would like to add similar functionality to having an edge (remote card reader that has administration control of the device, but no access to keys) and the poor mans hsm.

I havent properly checked the armory documentation or even seen if it has an api. (it is open source though...) I feel it is necessary to pointout how integral the armory client is to this, without that this would be a massive task.  as it is, he has done all the hard work, and bitcoined it up. It is an amazing tool.  

if that guy ever wants to earn serious cash he should apply to the likes of ncipher or thales as a systems architecht using armory as a demo pitch, they would snap him up. I am really surprised there are not more public partnerships between him and sites. maybe that will change.

So far I have only done some minor proof of concept perl scripts and am completely relying on the integrity of the armory client.

(a quick overview of how the armory client works)

http://bitcoinarmory.com/index.php/start-page/what-is-armory/features

I knocked up a perl script using win32::guitest to drive the armory gui. (it literally clicks the buttons, i am a tester and test scripting is quicker for me...)

So the online machine has  no sensitive information on it(per armory faq), it checkes an email box, then based off that is generates an offline transaction this is then passed to a different perl script that sole purpose is to spout data over serial to a receiving script on machine B. machine b has the offline private key.  The script on machine B checks the transaction against the rules it has (at the moment that is just it is a testnet address and the amount is less than 5btc) then it signs the transaction and passes this to back to machine A, machine A checks this again against its validation rules (just sanity checks, these can be manipulated) then squirts it out over the network.

I did this in about an hour or so.

So the concept works.  and 90% of the hard work has already been done to get a quick and dirty implementation up and running.

I would like to add much more to this and do it in python so it can interact with the actual armory client rather than just driving the mouse and keyboard. If you are interested I can tidy up the code a bit and share it with you? maybe wait until I have something that functions a bit better?

tl;dr
I changed the air gap for a serial cable, and rather than me clicking on buttons i did it with a perl script.

Hope this helps.

steve

Do tell! I would like some pictures and a longer description. Pretty please?

This is confusing and in the context of this thread, not true.

It is not the implementation of the bitcoin protocol that has a problem, it is people not doing due dilligence in regard to the securing of private keys (bitcoin or not, it just so happens that bitcoin private keys are cash...) - bitcoin does offer some unique challenges, but nothing that is _unsecureable_ by design or something that can be fixed with protocol changes.

This thread is about _physically_ securing a hotwallet from your server being rooted (keys cannot be accessed/copied), or someone stealing the box (keys cannot be physically recovered off the chips).  this can and should be protected against.  please check out the links I have already posted, the technology to do this has been around for years (and is legally required in the banking industry - check fips 140-2)

This is only the foundation of a proper defense in depth security approach.  If the foundations are not solid then you are correct, the hotwallet is doomed. And just because you have a solid foundation it does not mitigate the need for further security measures.

Without a solid foundation when you are hacked you will lose your coins.  You cannot stop someone hacking you, what you can do is mitigate the damage they can cause.

cheers,

steve

edit: i managed to get something similar to this setup with the armory client, a serial cable and a little perl socket io.

The way bitcoin is implemented right now, if you have a "hot wallet" to do transactions on, someone can hack it. Any automated way and it's hackable. Bitcoin has to be exposed to the network to send and receive coins and as such there's always an exploit to break in somehow.

If you are a miner or only receive deposits, you can create a wallet totally offline, get an address and deposit coins there and it is secure so long as it never sees the internet.

year it is better than nothing, but still i would like to see something a little more robust.  It was good enough for RPOW and Hal Finney...

Check out his security model for securing his 'blockchain'

http://web.archive.org/web/20071222072154/http://rpow.net/

and that has code running on one of these (imagine how much this would cost now days, probably one or two side channel attacks though...)

http://web.archive.org/web/20071027105630/http://www-03.ibm.com/security/cryptocards/pcicc.shtml

these are the more modern ones

http://www-03.ibm.com/security/cryptocards/

So you dont have to go thales, you could go ibm... 


You are right it doesnt.  and it appears (after a couple of conversations with some people) it seems that the edge is a little lite on the resources and doesnt support SSE (it does support codesafe - which runs within the boundary of the device, all fips 140-2 level 3+ have to it would seem) thus making it a bit of a pig to code for.  So the solo would be the ideal option.  they are no where near as expensive as i first thought.  only a couple of $k

add acouple of edges and you have distributed key management and the remote access security that a payshield affords.

the Edge, contains a minihsm, (like the solo)

Here is more info than you could want for the security model of the miniHSM

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp972.pdf

They do not give the details of the resources that are avaliable to a coder though - you did used to be able to get this from the ncipher site, in their dev tools.  however it seems that these are no longer avaliable to the general public.

cheers,

steve

Even if I have 1 BTC in my account, thus not using up even 0.1% of my funds?

It might even be possible to accumulate pay-outs by the way, so people _can_ request 1000*1 Satoshi to the same address, but they would get 1*1000 Satoshis instead once the transaction gets created.

Which the website would then reports as error to the user and never send it to the tx server.  Eventually it would shutdown your account and ask you to contact customer support.  None of those requests would ever make it to the tx server.

I would not execute code on your server, I would (if you are MtGox for example) spam you with withdrawal requests.

The tx server only accepts inputs from serial port hardwired to the web server.

If the attacker has admin access to the frontend webserver and is executing arbitrary code then the site likely SHOULD be locked down don't you think?

So just by writing a program that requests 1000 withdrawals of 1 Satoshi (which would very likely look like a malfunction or an attack) one could bring down the site potentially for hours? Nice!

I would still go with my initial idea:
Pay-ins are credited as soon as they are confirmed
Pay-outs are processed every x hours en block (saves on Tx-fees, keeps wallet offline etc.etc.)

Instant payouts will always be a security risk and unless you have a site that pays out less than a handful of BTC every day anyways, you really should just use an offline wallet, collect transactions and manually create a sendmany every once in a while on an offline PC.

D&T,

very clear, thank you.

spiccioli.

D&T seems to know a little something here.

I would have a team write a withdrawal.log file that is read from another server somewhere that reads the withdrawal requests, verifies against the preknown accounts (hashed of course), and executes the outgoing to the network from a completely different location. This Floating 'float' account can be moved at intervals to provide another level of security.

OFC, this doesn't prevent messing with the positions of people in the code but it would help to not lose $300K.

D&T has already pointed out in another thread in a strongly worded opinion things that should have been learned. I would have thought $300K would have taught somethings if at least another degree.

Business rules.

The serial port wouldn't connect to the bitcoind directly.  Instead its access would be limited to only a process/service/daemon which validates tx requests (not commands) against business rules.  

Just brainstorming here but as an example imagine the tx server had these rules:
1) Max Tx value is 1000 BTC (or whatever limit is useful for 90% of users).
2) TX value > 100 BTC results in 60 minute delay before return the signed tx.
3) TX value > 300 BTC reults in 180 minutes delay before returning the signed tx.
4) Certain conditions which indicate either a probable attack or software malfunction trigger an automatic lockdown.**
5) If total tx value in last 15 minutes exceeds preset limit delay all tx an additional 30 minutes (even those under 100 BTC) and notify admins.
5) TX volume 50% higher than 7 day peak causes a security hold. *
6) TX value 50% higher than 7 day peak cause a security hold. *
7) TX velocity increases by more than preset limit causes a security hold. *


Web front end -> API via serial port -> tx processors -> wallet.

* Security hold:
On a security hold the server remains online and queues up tx requests but stops returning signed txs.  Admin are notified and the server remains halted until it receives a security key (which isn't stored on front end server).  This would be useful to put a "man in the loop" when volume is high.  

 It is possible this is just a valid but unusual event.  Admin can check the tx logs, access logs, and if everything checks out provide the security key to resume operation.   Grocery stores use a system like this.  Ever seen a cashier mess up and she needs the manager key?  Same concept.  It limits the potential for fraud based on business rules of unusual behavior.

** Lockdown:
In a lockdown (possible intrusion) the server powers off.  Resuming tx processing requires powering on the server, providing the startup key, and optionally waiting for a preset delay.  All admins are notified of the lockdown and the front end server is halted also.   "Red alert.  Shields up".  

For more security the box could be designed to allow a security hold or lockdown command to be issued from any internet connected computer.  The command would need to be digitally signed to prevent abuse but this would provide a "manual override".  Zhou noticed the admin reset and the "weird" tx within minutes.   Even if the tx server hadn't realized it was fraudulent if it was still in the delayed signing queue Zhou could have forced the server into lockdown and saved six figures.

The rules could start out simple and get more complex as the business evolves.  The goal is to prevent direct access to the keys or funds by limiting unusual activity even when someone has "access".  Does anyone think in a traditional bank if a teller uses their terminal to make a "valid" $100,000,000 cash withdrawal the bank's vault automatically swings opens and bags of money roll out?  Meanwhile security guards and bank managers stand by helpless as thieves fill a dumptruck with cash because "she had the right code".

SgtSpike,

ah OK, yes, now it is clear.

Thanks.

spiccioli