
The Bitcoin Piñata - amirmc
http://ownme.ipredator.se
======
ctz
As far as I can tell (I can't read O'Caml very well) the crypto library
underpinning this makes the same mistake that all PKCS#1 signature
verification functions have had at some point or another: they unpick the
padding by hand[1], and then decode the ASN1 DigestInfo. The only sane way to
do this is to generate the padding from scratch and check if the signature
plaintext is the same (the added benefit is your ASN1 decoder is now not on a
front-line security boundary).

Is this exploitable in this bounty? No idea. At least, it's the right kind of
vulnerability you need to forge a certificate.

CVE-2014-1568 was this problem in NSS.

[1]: [https://github.com/mirleft/ocaml-
nocrypto/blob/master/src/rs...](https://github.com/mirleft/ocaml-
nocrypto/blob/master/src/rsa.ml#L151)

~~~
hannesm
This is about the DigestInfo -- which we generate and compare here:
[https://github.com/mirleft/ocaml-
tls/blob/master/lib/handsha...](https://github.com/mirleft/ocaml-
tls/blob/master/lib/handshake_common.ml#L186)

The unpad does RSA unpadding... or am I completely mistaken?

~~~
ctz
I was reading the X509 certificate verification code, rather than the TLS
code:

[https://github.com/mirleft/ocaml-x509/blob/master/lib/certif...](https://github.com/mirleft/ocaml-x509/blob/master/lib/certificate.ml#L157)

~~~
pqwy
Why do you think this creates malleability?

PKCS1.5 stripping takes away the leading 0x00 0x01 0xff ... 0x00 -- if this
prefix is not present, it fails.

The rest goes through the RSA tranform, and is parsed as PKCS1 DigestInfo, an
ASN.1 structure. All ASN parsing checks for presence of trailing bytes, on top
and in CONSTRUCTED nodes.

The presence of suffix-checking prevents malleability in my mind. Am I missing
something?

~~~
ctz
ASN parsing code, in general, does not check for presence of trailing bytes
(see Bleichenbacher's original signature forgery attack, and CVEs passim).
Should they? Yes. Do they? No, it is a frequent implementation error.

In NSS, they did check for trailing bytes, but allowed one part of the ASN1
structure to have an arbitrary value (to work around flaws in other
implementations).

To be abundantly clear: I am not saying that any of the presented code has an
exploitable flaw. I am saying that the way the code is written has frequently
been found to be faulty in the past.

~~~
hannesm
"ASN parsing code, in general"... this sounds like you're a bit stuck in ad-
hoc ASN.1 parsers written in C...

We actually use combinators for doing that - this explains our ASN.1 library
in more depth: [http://openmirage.org/blog/introducing-
asn1](http://openmirage.org/blog/introducing-asn1)

------
Apofis
I'm more interested in the OS they hosted their site on.

Mirage, developed in OCaml for the cloud. The part that really interested me:
"If a sudden spike in traffic occurs, the web-servers can be configured to
create and deploy copies of themselves to service the demand. This auto-
scaling happens so quickly that an incoming connection can trigger the
creation of new server and the new server can then handle that request before
it times out (which is on the order of milliseconds)."

[http://openmirage.org/wiki/overview-of-
mirage](http://openmirage.org/wiki/overview-of-mirage)

~~~
amirmc
Yup, this is work in progress. The first part of this is Jitsu, which is a DNS
server that can spin up Unikernels on an incoming request.

[https://github.com/MagnusS/jitsu](https://github.com/MagnusS/jitsu)

~~~
edwintorok
Are the DNS requests used only to scale up in anticipation of more traffic, or
is a steady stream of DNS requests required to keep the instances running once
they are started? I see that there is an expiration TTL, but what happens if
there is a download in progress for longer than the VM expiration time?

Also how well does this work with persistent HTTP connections (and TLS
handshakes)? i.e. will the browser keep a persistent connection to the jitsu
proxy and the actual requests might be served by different VMs?

~~~
amirmc
We're actually putting a paper together that uses Jitsu so you might find that
answers most of your questions (the team is busy with eval at the moment).

For the time-being, Jitsu [1] 'just' spawns a unikernel which serves requests,
with no apparently latency for the requester. At some point, when the
unikernel hasn't done anything for a while, it is culled (which is something
of an implementation detail). In principle, we should be able to use this as
part of a set of tools to create the hyper-elastic clouds mentioned upthread.

[1] Just in Time Summoning of Unikernels

------
joshu
The other interesting bit is that if you really want to chip in you could send
bitcoin TO that address to sweeten the pot.

~~~
amirmc
I bet the authors never considered that as part of their threat models.

~~~
ikeboy
Wait aren't _you_ one of the authors?

~~~
amirmc
I'm part of the Mirage team but when I say 'authors' I'm specifically
referring to the people who wrote the Piñata code.

~~~
ikeboy
The site is down now. Any idea why? Too much traffic, or DDos, or other hack?

~~~
pqwy
Syn flood...

~~~
edwintorok
Does mirage's TCP/IP stack implement syn cookies [0] when under attack?

[0] [http://lwn.net/Articles/277146/](http://lwn.net/Articles/277146/)

~~~
zem
i wasn't familiar with syncookies, but the article you linked to says

> Syncookies are discouraged these days. They disable too many valuable TCP
> features (window scaling, SACK) and even without them the kernel is usually
> strong enough to defend against syn floods and systems have much more memory
> than they used to be. So I don't think it makes much sense to add more code
> to it, sorry.

~~~
edwintorok
You probably only want to enable syn cookies when you are under heavy attack,
but from the same article:

"I can trivially prevent any inbound client connections with 2 threads of syn
flood. Enabling tcp_syncookies brings the connection handling back up to 725
fetches per second."

"This data compellingly supports the continued value of the syncookie and that
position seems to have won the day."

Of course this refers to the Linux TCP/IP stack, the Mirage stack is
completely different so it remains to be seen what measures will be effective
against syn floods.

------
amirmc
There's some additional context at [http://amirchaudhry.com/bitcoin-
pinata/](http://amirchaudhry.com/bitcoin-pinata/)

------
gradinafrica
They seem to assume the reader has a certain level of competency with web
traffic monitoring and client/server communicating tools. I suppose this is
half the fun. Still, I'm trying to figure out what they mean by

> " _Before you ask: yes, Piñata will talk to itself and you can enjoy
> watching it do so._ "

Also, what should I be using to connect using TLS/TCP?

~~~
nothrabannosir
They offer a TLS client and server interface, so you can have your own host
act as a proxy.

Try this:

    
    
        $ mkfifo /tmp/tlspipe
        $ nc -l -p 40001 </tmp/tlspipe | tee /tmp/tlsconvo | nc ownme.ipredator.se 10000 > /tmp/tlspipe
    

Then visit [http://ownme.ipredator.se:10001](http://ownme.ipredator.se:10001)
from that same host (curl or firefox or whatever). Now look at /tmp/tlspipe.

Disclaimer: I'm completely unfamiliar with named pipes or tls, but I think
this is what they mean.

EDIT: This should also work:

    
    
        $ mkfifo /tmp/tlspipe
        $ nc ownme.ipredator.se 10002 </tmp/tlspipe | tee /tmp/tlsconvo2 | nc ownme.ipredator.se 10000 >/tmp/tlspipe
    

EDIT2: Just realized that the above only captures one part of the convo. Try
this:

    
    
        $ nc ownme.ipredator.se 10002 </tmp/tlspipe | tee /tmp/client-to-server | nc ownme.ipredator.se 10000 | tee /tmp/server-to-client >/tmp/tlspipe
    

Now you have the full back and forth. E.g.:

    
    
        $ strings /tmp/server-to-client
        sYcdI*
                Cambridge1
        BTC Pinata Team1 0
        ocaml-tls@h3q.com0
        150207183718Z
        150329183718Z0$1
        tls services0
        
        ...

~~~
posnet
For those who are interested, this is a great source of cool things you can do
with netcat.

[http://www.felipemartins.info/2013/03/netcat-the-it-swiss-
kn...](http://www.felipemartins.info/2013/03/netcat-the-it-swiss-knife-
complete-commented-examples/)

------
MrRogers
Where could I, a total beginner in crypto-stuff, learn more about this kind of
thing? What would be the list of things I'd need to know how to do in order to
"break in", and where could I learn how to do them?

~~~
philk10
One possible starting point is here -
[http://cryptopals.com](http://cryptopals.com)

~~~
eterm
But oddly not [http://www.cryptopals.com/](http://www.cryptopals.com/)

~~~
Cederfjard
Not so odd, I don't always use nor redirect www either (well I do if it's for
a client, but otherwise I usually can't be bothered).

Edit: But I do get 404s when I click the "language-links" on the challenge
pages, like
[http://cryptopals.com/sets/1/challenges/1/ruby](http://cryptopals.com/sets/1/challenges/1/ruby).
What are those anyways?

~~~
eterm
They are Solutions. The C++ one to the first exercise works:

[http://cryptopals.com/sets/1/challenges/1/cpp/](http://cryptopals.com/sets/1/challenges/1/cpp/)

~~~
omega_rythm
It's probably the only one that works, and it's just a hint (the conversion
function is weird btw, it accepts hexadecimal symbols ranging from '0' to 'z';
it actually "decodes" any base from binary to triacontahexadecimal (36)).

------
marcell
Suggestion: add an endpoint on the piñata that proves it has the private key.
You can do this using Bitcoin's sign message method.

~~~
ikeboy
And then I just make it sign a message sending all the btc to my address, then
broadcast that publicly.

 __Very bad idea __to sign _everything_ that comes your way, kind of like
`eval` on text input.

~~~
martinko
> Very bad idea to sign everything that comes your way, kind of like `eval` on
> text input.

Nowhere did he suggest this.

~~~
ikeboy
Others said it in the replies. And any implementation that tries to check the
message opens up another avenue of attack.

------
packetized
Probably want to also go ahead and catch up on the TCP/IP stack; the
pqwy/mirage-tcpip repo is some 232 commits behind mirage/mirage-tcpip, and is
missing fixes for things like [https://github.com/mirage/mirage-
tcpip/issues/56](https://github.com/mirage/mirage-tcpip/issues/56)

~~~
avsm
His master branch isn't uptodate, but the pinata branch that's deployed is
tracking the head of mirage/mirage-tcpip. See the opam manifest here:
[https://raw.githubusercontent.com/mirleft/btc-
pinata/master/...](https://raw.githubusercontent.com/mirleft/btc-
pinata/master/opam-full.txt)

~~~
packetized
You're right - mea culpa.

------
econner
FYI The bounty is about $2000.

~~~
avsm
As Bruce Schneier pointed out [1], the price is definitely not meant to be a
massive incentive -- any cryptographer worth their salt is going to be worth a
hell of a lot more than our prize amount. But at the same time, we're really
keen to make it easier to audit protocols in MirageOS, and hope that this
Piñata "permitted breakin" is something that'll catch on. The worst case for
us is that someone does break in and doesn't tell us how they did it. Let's
hope the eventual winner wants to brag, and we get to improve our source code
:-)

[1] [https://www.schneier.com/crypto-
gram/archives/1998/1215.html...](https://www.schneier.com/crypto-
gram/archives/1998/1215.html#contests)

~~~
runeks
> The worst case for us is that someone does break in and doesn't tell us how
> they did it.

I do hope you're logging all incoming data to a backup server somewhere, so
you can analyze it afterwards if this were to happen.

------
neals
Can sombody explain this in a bit less technical terms?

~~~
pjc50
It's a security bounty contest that requires no intervention by the organisers
to hand out the bounty. Break in and take it.

~~~
amirmc
> _" Break in and take it."_

But please tell us if you do. We'd like to learn from this exercise and
improve the stack.

~~~
mintplant
If you're not already, it'd be a good idea to log all traffic to/from the box
so that you'll at least have something if no one owns up.

~~~
kzrdude
Ah, but it's so ironic if ipredator.se does that.

~~~
hnarn
As far as I know, ipredator is not a service to prevent logging, they're a
service to prevent unauthorized surveillance.

~~~
tP5n
...preventing surveillance by running a vpn service and claiming not to have
any kind of traffic logs, so yeah ;)

------
pqwy
Update: DDoS, SYN flood. Stay tuned...

~~~
pqwy
... back.

------
unwind
This is a duplicate of
[https://news.ycombinator.com/item?id=9027701](https://news.ycombinator.com/item?id=9027701),
not sure why the URL-matching didn't catch it.

------
ricket
So the server always sends the same plaintext (the private key of the bitcoin
wallet), encrypted presumably by the same cipher but each time with a
different symmetric key of course (negotiated by the handshake). It seems
(naively, I'm sure) like this is a weakness, like you could collect a bunch of
the encrypted samples, and then use the fact that they are all from the same
plaintext in order to figure out what the plaintext is. How many samples would
it take before you could deduce the key?

~~~
comex
In theory, a block cipher is broken if an attacker can even tell the
difference between application of the cipher and of a random permutation,
different for each possible key, more efficiently than brute force (i.e.
trying every possible key). Since encrypting the same plaintext with a bunch
of different random permutations would not help an attacker recover it, I
believe an attack like you describe would not be possible without breaking
AES.

~~~
un1xl0ser
A weak RNG may create an opportunity for successful cryptanalysis. This can
especially be a problems on virtual hardware/platforms that don't have a
mechanism for keeping a good random seed, and have predictable hardware
events, et cetera.

