LearnBitcoin

Bitcoin Dev Archive 2014

Miners MiTM

16 messages, 7 to 9 Aug 2014. Started by Pedro Worcel.

Luke Dashjr (3), Pedro Worcel (2), slush (2), Jeff Garzik (2), Mike Hearn (2), Troy Benjegerdes (2), Christopher Franko, Laszlo Hanyecz, +1 more

Permalink Original thread on gnusha.org

Pedro Worcel permalink original

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

Luke Dashjr in reply to Pedro Worcel permalink original

On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote:

Quoted text (14 lines)
> 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.

slush in reply to Luke Dashjr permalink original

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:

Quoted text (38 lines)
> 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
>
Christopher Franko in reply to slush permalink original

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:

Quoted text (63 lines)
> 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
>
>
Luke Dashjr in reply to slush permalink original

On Friday, August 08, 2014 12:29:31 AM slush wrote:

Quoted text (4 lines)
> 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

Pedro Worcel in reply to Christopher Franko permalink original
Quoted text (1 line)
> 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.

Quoted text (1 line)
> 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>:

Quoted text (86 lines)
> 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
>
>
slush in reply to Pedro Worcel permalink original

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:

Quoted text (6 lines)
>
> 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.
>
>
Jeff Garzik in reply to slush permalink original

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:

Quoted text (63 lines)
> 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
>
>
Mike Hearn in reply to slush permalink original
Quoted text (6 lines)
>
> 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.

Mike Hearn in reply to Luke Dashjr permalink original
Quoted text (6 lines)
>
> 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.

Jeff Garzik in reply to Mike Hearn permalink original

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:

Quoted text (25 lines)
>> 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
>
Luke Dashjr in reply to Jeff Garzik permalink original

On Friday, August 08, 2014 6:21:18 PM Jeff Garzik wrote:

Quoted text (4 lines)
> 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

Laszlo Hanyecz in reply to Jeff Garzik permalink original

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:

Quoted text (50 lines)
> 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
Sergio Lerner in reply to Laszlo Hanyecz permalink original

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.

Troy Benjegerdes in reply to Luke Dashjr permalink original

On Thu, Aug 07, 2014 at 11:45:44PM +0000, Luke Dashjr wrote:

Quoted text (20 lines)
> 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

Troy Benjegerdes in reply to Mike Hearn permalink original

On Fri, Aug 08, 2014 at 11:42:52AM +0200, Mike Hearn wrote:

Quoted text (15 lines)
> >
> > 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.