[Bitcoin-development] Miners MiTM

[Bitcoin-development] Miners MiTM

[Pedro Worcel]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

Hi there,

I was wondering if you guys have come across this article:

http://www.wired.com/2014/08/isp-bitcoin-theft/

The TL;DR is that somebody is abusing the BGP protocol to be in a position
where they can intercept the miner traffic. The concerning point is that
they seem to be having some degree of success in their endeavour and
earning profits from it.

I do not understand the impact of this (I don't know much about BGP, the
mining protocol nor anything else, really), but I thought it might be worth
putting it up here.

Ta,
Pedro

[-- Attachment #2: Type: text/html, Size: 972 bytes --]

Re: [Bitcoin-development] Miners MiTM

[Luke Dashjr]

On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote:
> Hi there,
> 
> I was wondering if you guys have come across this article:
> 
> http://www.wired.com/2014/08/isp-bitcoin-theft/
> 
> The TL;DR is that somebody is abusing the BGP protocol to be in a position
> where they can intercept the miner traffic. The concerning point is that
> they seem to be having some degree of success in their endeavour and
> earning profits from it.
> 
> I do not understand the impact of this (I don't know much about BGP, the
> mining protocol nor anything else, really), but I thought it might be worth
> putting it up here.

This is old news; both BFGMiner and Eloipool were hardened against it a long 
time ago (although no Bitcoin pools have deployed it so far). I'm not aware of 
any actual case of it being used against Bitcoin, though - the target has 
always been scamcoins.

Re: [Bitcoin-development] Miners MiTM

[slush]

[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]

AFAIK the only protection is SSL + certificate validation on client side.
However certificate revocation and updates in miners are pain in the ass,
that's why majority of pools (mine including) don't want to play with
that...

slush


On Fri, Aug 8, 2014 at 1:45 AM, Luke Dashjr <luke@dashjr.org> wrote:

> On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote:
> > Hi there,
> >
> > I was wondering if you guys have come across this article:
> >
> > http://www.wired.com/2014/08/isp-bitcoin-theft/
> >
> > The TL;DR is that somebody is abusing the BGP protocol to be in a
> position
> > where they can intercept the miner traffic. The concerning point is that
> > they seem to be having some degree of success in their endeavour and
> > earning profits from it.
> >
> > I do not understand the impact of this (I don't know much about BGP, the
> > mining protocol nor anything else, really), but I thought it might be
> worth
> > putting it up here.
>
> This is old news; both BFGMiner and Eloipool were hardened against it a
> long
> time ago (although no Bitcoin pools have deployed it so far). I'm not
> aware of
> any actual case of it being used against Bitcoin, though - the target has
> always been scamcoins.
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2598 bytes --]

Re: [Bitcoin-development] Miners MiTM

[Christopher Franko]

[-- Attachment #1: Type: text/plain, Size: 2575 bytes --]

What exactly makes bitcoin less of a target than a "scamcoin" which I
suspect means anything that != bitcoin?


On 7 August 2014 20:29, slush <slush@centrum.cz> wrote:

> AFAIK the only protection is SSL + certificate validation on client side.
> However certificate revocation and updates in miners are pain in the ass,
> that's why majority of pools (mine including) don't want to play with
> that...
>
> slush
>
>
> On Fri, Aug 8, 2014 at 1:45 AM, Luke Dashjr <luke@dashjr.org> wrote:
>
>> On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote:
>> > Hi there,
>> >
>> > I was wondering if you guys have come across this article:
>> >
>> > http://www.wired.com/2014/08/isp-bitcoin-theft/
>> >
>> > The TL;DR is that somebody is abusing the BGP protocol to be in a
>> position
>> > where they can intercept the miner traffic. The concerning point is that
>> > they seem to be having some degree of success in their endeavour and
>> > earning profits from it.
>> >
>> > I do not understand the impact of this (I don't know much about BGP, the
>> > mining protocol nor anything else, really), but I thought it might be
>> worth
>> > putting it up here.
>>
>> This is old news; both BFGMiner and Eloipool were hardened against it a
>> long
>> time ago (although no Bitcoin pools have deployed it so far). I'm not
>> aware of
>> any actual case of it being used against Bitcoin, though - the target has
>> always been scamcoins.
>>
>>
>> ------------------------------------------------------------------------------
>> Infragistics Professional
>> Build stunning WinForms apps today!
>> Reboot your WinForms applications with our WinForms controls.
>> Build a bridge from your legacy apps to the future.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 4031 bytes --]

Re: [Bitcoin-development] Miners MiTM

[Luke Dashjr]

On Friday, August 08, 2014 12:29:31 AM slush wrote:
> AFAIK the only protection is SSL + certificate validation on client side.
> However certificate revocation and updates in miners are pain in the ass,
> that's why majority of pools (mine including) don't want to play with
> that...

Certificate validation isn't needed unless the attacker can do a direct MITM 
at connection time, which is a lot harder to maintain than injecting a 
client.reconnect. This, combined with your concern about up to date 
certs/revokes/etc, is why BFGMiner defaults to TLS without cert checking for 
stratum.

Luke

Re: [Bitcoin-development] Miners MiTM

[Pedro Worcel]

[-- Attachment #1: Type: text/plain, Size: 4354 bytes --]

> the only protection is SSL + certificate validation on client side.
However certificate revocation and updates in miners are pain in the ass,
that's why majority of pools (mine including) don't want to play with
that...

Another solution which would have less overhead would be to implement
something akin to what openssh does. The OpenSSH client stores a
certificate fingerprint, which is then verified automatically upon further
connections to the server.

The initial connection needs to be verified manually by the operator,
though.

> Certificate validation isn't needed unless the attacker can do a direct
MITM
at connection time, which is a lot harder to maintain than injecting a
client.reconnect. This, combined with your concern about up to date
certs/revokes/etc, is why BFGMiner defaults to TLS without cert checking for
stratum.

Seems to me that it would correctly mitigate the attack mentioned in the
wired article. I am surprised that miners are not worried about losing
their profits, I would personally be quite annoyed.



2014-08-08 12:37 GMT+12:00 Christopher Franko <chrisjfranko@gmail.com>:

> What exactly makes bitcoin less of a target than a "scamcoin" which I
> suspect means anything that != bitcoin?
>
>
> On 7 August 2014 20:29, slush <slush@centrum.cz> wrote:
>
>> AFAIK the only protection is SSL + certificate validation on client side.
>> However certificate revocation and updates in miners are pain in the ass,
>> that's why majority of pools (mine including) don't want to play with
>> that...
>>
>> slush
>>
>>
>> On Fri, Aug 8, 2014 at 1:45 AM, Luke Dashjr <luke@dashjr.org> wrote:
>>
>>> On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote:
>>> > Hi there,
>>> >
>>> > I was wondering if you guys have come across this article:
>>> >
>>> > http://www.wired.com/2014/08/isp-bitcoin-theft/
>>> >
>>> > The TL;DR is that somebody is abusing the BGP protocol to be in a
>>> position
>>> > where they can intercept the miner traffic. The concerning point is
>>> that
>>> > they seem to be having some degree of success in their endeavour and
>>> > earning profits from it.
>>> >
>>> > I do not understand the impact of this (I don't know much about BGP,
>>> the
>>> > mining protocol nor anything else, really), but I thought it might be
>>> worth
>>> > putting it up here.
>>>
>>> This is old news; both BFGMiner and Eloipool were hardened against it a
>>> long
>>> time ago (although no Bitcoin pools have deployed it so far). I'm not
>>> aware of
>>> any actual case of it being used against Bitcoin, though - the target has
>>> always been scamcoins.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Infragistics Professional
>>> Build stunning WinForms apps today!
>>> Reboot your WinForms applications with our WinForms controls.
>>> Build a bridge from your legacy apps to the future.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 6725 bytes --]

Re: [Bitcoin-development] Miners MiTM

[slush]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

Although 140 BTC sounds scary, actually it was very minor issue and most of
miners aren't even aware about it.

TLS would probably make the attack harder, that's correct. However if
somebody controls ISP routers, then MITM with TLS is harder, yet possible.

slush


On Fri, Aug 8, 2014 at 3:07 AM, Pedro Worcel <pedro@worcel.com> wrote:

>
> Seems to me that it would correctly mitigate the attack mentioned in the
> wired article. I am surprised that miners are not worried about losing
> their profits, I would personally be quite annoyed.
>
>

[-- Attachment #2: Type: text/html, Size: 1102 bytes --]

Re: [Bitcoin-development] Miners MiTM

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 2831 bytes --]

You don't necessarily need the heavy weight of SSL.

You only need digitally signed envelopes between miner and pool[1].

[1] Unless the pool is royally stupid and will somehow credit miner B, if
miner B provides to the pool a copy of miner A's work.



On Thu, Aug 7, 2014 at 8:29 PM, slush <slush@centrum.cz> wrote:

> AFAIK the only protection is SSL + certificate validation on client side.
> However certificate revocation and updates in miners are pain in the ass,
> that's why majority of pools (mine including) don't want to play with
> that...
>
> slush
>
>
> On Fri, Aug 8, 2014 at 1:45 AM, Luke Dashjr <luke@dashjr.org> wrote:
>
>> On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote:
>> > Hi there,
>> >
>> > I was wondering if you guys have come across this article:
>> >
>> > http://www.wired.com/2014/08/isp-bitcoin-theft/
>> >
>> > The TL;DR is that somebody is abusing the BGP protocol to be in a
>> position
>> > where they can intercept the miner traffic. The concerning point is that
>> > they seem to be having some degree of success in their endeavour and
>> > earning profits from it.
>> >
>> > I do not understand the impact of this (I don't know much about BGP, the
>> > mining protocol nor anything else, really), but I thought it might be
>> worth
>> > putting it up here.
>>
>> This is old news; both BFGMiner and Eloipool were hardened against it a
>> long
>> time ago (although no Bitcoin pools have deployed it so far). I'm not
>> aware of
>> any actual case of it being used against Bitcoin, though - the target has
>> always been scamcoins.
>>
>>
>> ------------------------------------------------------------------------------
>> Infragistics Professional
>> Build stunning WinForms apps today!
>> Reboot your WinForms applications with our WinForms controls.
>> Build a bridge from your legacy apps to the future.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

[-- Attachment #2: Type: text/html, Size: 4417 bytes --]

Re: [Bitcoin-development] Miners MiTM

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

>
> AFAIK the only protection is SSL + certificate validation on client side.
> However certificate revocation and updates in miners are pain in the ass,
> that's why majority of pools (mine including) don't want to play with
> that...
>

Why would miners need updates? If they implement the standard SSL
infrastructure you can change certificates and keys without needing to
update miners.

Besides, when it comes to financial services SSL is essential, I'm kind of
surprised it wasn't already used everywhere. I wouldn't use an online bank
that didn't support SSL, I would see it as a a sign of serious problems.
Heck I wouldn't even use webmail that didn't support SSL these days.

[-- Attachment #2: Type: text/html, Size: 1006 bytes --]

Re: [Bitcoin-development] Miners MiTM

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

>
> Certificate validation isn't needed unless the attacker can do a direct
> MITM
> at connection time, which is a lot harder to maintain than injecting a
> client.reconnect.
>

Surely the TCP connection will be reset once the route reconfiguration is
completed, either by the MITM server or by the client TCP stack when it
discovers the server doesn't know about the connection anymore?

TLS without cert validation defeats the point, you can still be connected
to a MITM at any point by anyone who can simply interrupt or corrupt the
stream, forcing a reconnect.

[-- Attachment #2: Type: text/html, Size: 849 bytes --]

Re: [Bitcoin-development] Miners MiTM

[Jeff Garzik]

gmaxwell noted on IRC that enabling TLS could be functionally, if not
literally, a DoS on the pool servers.  Hence the thought towards a
more lightweight method that simply prevents client payout redirection
+ server impersonation.


On Fri, Aug 8, 2014 at 5:53 AM, Mike Hearn <mike@plan99.net> wrote:
>> Certificate validation isn't needed unless the attacker can do a direct
>> MITM
>> at connection time, which is a lot harder to maintain than injecting a
>> client.reconnect.
>
>
> Surely the TCP connection will be reset once the route reconfiguration is
> completed, either by the MITM server or by the client TCP stack when it
> discovers the server doesn't know about the connection anymore?
>
> TLS without cert validation defeats the point, you can still be connected to
> a MITM at any point by anyone who can simply interrupt or corrupt the
> stream, forcing a reconnect.
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Miners MiTM

[Luke Dashjr]

On Friday, August 08, 2014 6:21:18 PM Jeff Garzik wrote:
> gmaxwell noted on IRC that enabling TLS could be functionally, if not
> literally, a DoS on the pool servers.  Hence the thought towards a
> more lightweight method that simply prevents client payout redirection
> + server impersonation.

My thought for GBT2 a while ago was to use simple ECDSA signatures for 
messages. It'd be nice to use the same as Bitcoin, but then we'd hit problems 
with RedHat/Fedora legal being stupid. :(

Luke

Re: [Bitcoin-development] Miners MiTM

[Laszlo Hanyecz]

Mutual CHAP could work.  This is commonly done in PPP and iSCSI.  The idea is simply that both sides authenticate.  The server expects the client to provide a password, and the client expects the server to provide a (different) password.  If you masquerade as the server, you won't be able to authenticate because every client has a different password they expect from the server, so they won't do work for you. MITM on the server can capture the exchange but CHAP protects against replay.

https://en.wikipedia.org/wiki/Challenge-Handshake_Authentication_Protocol

-Laszlo


On Aug 8, 2014, at 6:21 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:

> gmaxwell noted on IRC that enabling TLS could be functionally, if not
> literally, a DoS on the pool servers.  Hence the thought towards a
> more lightweight method that simply prevents client payout redirection
> + server impersonation.
> 
> 
> On Fri, Aug 8, 2014 at 5:53 AM, Mike Hearn <mike@plan99.net> wrote:
>>> Certificate validation isn't needed unless the attacker can do a direct
>>> MITM
>>> at connection time, which is a lot harder to maintain than injecting a
>>> client.reconnect.
>> 
>> 
>> Surely the TCP connection will be reset once the route reconfiguration is
>> completed, either by the MITM server or by the client TCP stack when it
>> discovers the server doesn't know about the connection anymore?
>> 
>> TLS without cert validation defeats the point, you can still be connected to
>> a MITM at any point by anyone who can simply interrupt or corrupt the
>> stream, forcing a reconnect.
>> 
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> 
> 
> 
> 
> -- 
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Miners MiTM

[Sergio Lerner]

Since the information exchanged between the pool and the miner is
public, all that's needed is a mutual private MAC key that authenticates
messages.
This requires a registration step, that can be done only once using a
simple web interface over https to the miner website.
But the miner website is not the miner server, so the worst DoS would be
preventing new miners to join the pool, which is not very often.
The MAC key can be provided directly by the miner. And the pool
associates the MAC key with a Bitcoin public address.
The overhead would be minimal.


-Sergio.

Re: [Bitcoin-development] Miners MiTM

[Troy Benjegerdes]

On Thu, Aug 07, 2014 at 11:45:44PM +0000, Luke Dashjr wrote:
> On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote:
> > Hi there,
> > 
> > I was wondering if you guys have come across this article:
> > 
> > http://www.wired.com/2014/08/isp-bitcoin-theft/
> > 
> > The TL;DR is that somebody is abusing the BGP protocol to be in a position
> > where they can intercept the miner traffic. The concerning point is that
> > they seem to be having some degree of success in their endeavour and
> > earning profits from it.
> > 
> > I do not understand the impact of this (I don't know much about BGP, the
> > mining protocol nor anything else, really), but I thought it might be worth
> > putting it up here.
> 
> This is old news; both BFGMiner and Eloipool were hardened against it a long 
> time ago (although no Bitcoin pools have deployed it so far). I'm not aware of 
> any actual case of it being used against Bitcoin, though - the target has 
> always been scamcoins.

That statement right there is all the evidence I need to convince myself that
Bitcoin is under continuous and active BGP feed manipulation by organized
crime elements.

Just the phrase of referring to !bitcoin as 'scamcoins' is a signal of an
organized marketing/psychological operations effort to marginalize other 
competitors, and the documented altcoin BGP highjacks were most likely 
testing of the system to confirm both
a) that it works
b) how to hide it below the detection threshhold

Re: [Bitcoin-development] Miners MiTM

[Troy Benjegerdes]

On Fri, Aug 08, 2014 at 11:42:52AM +0200, Mike Hearn wrote:
> >
> > AFAIK the only protection is SSL + certificate validation on client side.
> > However certificate revocation and updates in miners are pain in the ass,
> > that's why majority of pools (mine including) don't want to play with
> > that...
> >
> 
> Why would miners need updates? If they implement the standard SSL
> infrastructure you can change certificates and keys without needing to
> update miners.
> 
> Besides, when it comes to financial services SSL is essential, I'm kind of
> surprised it wasn't already used everywhere. I wouldn't use an online bank
> that didn't support SSL, I would see it as a a sign of serious problems.
> Heck I wouldn't even use webmail that didn't support SSL these days.

Because turning on SSL gives pool operators a way to hack your miners.

http://www.symantec.com/connect/blogs/openssl-patches-critical-vulnerabilities-two-months-after-heartbleed

Just because SSL is the answer for financial services regulated security
theatre, where fraud means you just roll-back the transaction, it does not
mean it is actually a good cryptographic solution.

There are far better mechanisms that could be implemented using ECDSA 
keys (aka bitcoin addresses) to authenticate both miners and pools, but
the problem is there zero economic incentive to do so. As long as the
BGP/SSL/zero-day-of-the-week man-in-the middle fraud cost is lower than the
engineering cost to do some real cryptography and code audits, we'll keep
having new 'security patches' every couple of months.