>> (p.1)
    Author Topic: [THEORY] Reverse exploiting Bitcoin  (Read 2494 times)

    • AGD (OP)
    Legendary
    *
    Offline Offline

    Activity: 2070
    Merit: 1170


    Keeper of the Private Key


    View Profile
    June 04, 2014, 07:55:56 AM
    Last edit: September 22, 2018, 01:14:57 PM by AGD
     #1
    I had this idea. Dunno if it is realistic, maybe its BS, but need to let it go Cheesy

    When the Heartbleed bug was found, the Bitcoin core was quickly updated to version 0.9.0 (then shortly after updated to 0.9.1)

    Since it was a "major security issue" I assume, that alot of people already updated their client and the new version is more ore less accepted by the majority of the network. Noone wants to get hacked ...

    Now, what if some expert hacker invents an exploit that targets an issue, which is still not implemented in Bitcoin core, but - with a good reason - COULD be implemented in future versions, because of another big security issue, that will convince the majority of the community to update to the new version.

     If this expert hacker has a possibility to convince the key persons behind the BitcoinFoundation Bitcoin Development to update the source code with the reasonable security update (like it was done with the Heartbleed bug), he would be the only person with an exploit to the new implementation.

    This sounds like a quite realistic cenario to me. What do you think?
    Bitcoin is not a bubble, it's the pin!
    +++ GPG Public key FFBD756C24B54962E6A772EA1C680D74DB714D40 +++ http://pgp.mit.edu/pks/lookup?op=get&search=0x1C680D74DB714D40

  • franky1
    Legendary
    *
    Online Online

    Activity: 4662
    Merit: 5189



    View Profile
    June 04, 2014, 08:00:58 AM
     #2
    Quote from: AGD on June 04, 2014, 07:55:56 AM
    I had this idea. Dunno if it is realistic, maybe its BS, but need to let it go Cheesy

    When the Heartbleed bug was found, the Bitcoin core was quickly updated to version 0.9.0 (then shortly after updated to 0.9.1)

    Since it was a "major security issue" I assume, that alot of people already updated their client and the new version is more ore less accepted by the majority of the network. Noone wants to get hacked ...

    Now, what if some expert hacker invents an exploit that targets an issue, which is still not implemented in Bitcoin core, but - with a good reason - COULD be implemented in future versions, because of another big security issue, that will convince the majority of the community to update to the new version.

     If this expert hacker has a possibility to convince the key persons behind the BitcoinFoundation to update the source code with the reasonable security update (like it was done with the Heartbleed bug), he would be the only person with an exploit to the new implementation.

    This sounds like a quite realistic cenario to me. What do you think?


    people dont simply dump compiled exe's into the bitcoin dev project area. they put in lins of code, which get reviewed by the other dev's before its then added into the main code area, and then tested to ensure it does not cause other things to fall apart or become exploitable.

    so its not 'theoretically' possible to hide a trojan horse in the main bitcoin-core
    I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
    Please do your own research & respect what is written here as both researched opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at

  • shwackd
    Newbie
    *
    Offline Offline

    Activity: 25
    Merit: 0


    View Profile
    June 04, 2014, 08:01:47 AM
     #3
    To be perfectly honest:

    If the sun was blocked out of the sky for JUST long enough to cause the surface temperature of hydrated driving surface to drop below the freezing point of deionized water we could possibly cause an an automobile accident that would delay an important bitcoin foundation meeting JUST long enough to postpone the next update until our super virus elite hacker skills technician can compromise the mainframe.

  • AGD (OP)
    Legendary
    *
    Offline Offline

    Activity: 2070
    Merit: 1170


    Keeper of the Private Key


    View Profile
    June 04, 2014, 08:34:27 AM
     #4
    Quote from: franky1 on June 04, 2014, 08:00:58 AM

    people dont simply dump compiled exe's into the bitcoin dev project area. they put in lins of code, which get reviewed by the other dev's before its then added into the main code area, and then tested to ensure it does not cause other things to fall apart or become exploitable.

    so its not 'theoretically' possible to hide a trojan horse in the main bitcoin-core

    I agree, that new implementations are reviewed over and over by expert coders until they are released, but this is not the relevant part of it.
    SSL had a flaw that was indeed exploitable until the core devs were convinced, that they had to change the code and release v 0.9.0.
    Before that, the guys either didn't know about the Heartbleed bug or they thought it was not necessary to update.  This means, that a code - even after multiple reviews by good programmers - can contain bugs/flaws/exploitable parts, which either still has to be found or - in my example - was already found, but kept secret.
    Bitcoin is not a bubble, it's the pin!
    +++ GPG Public key FFBD756C24B54962E6A772EA1C680D74DB714D40 +++ http://pgp.mit.edu/pks/lookup?op=get&search=0x1C680D74DB714D40

  • justusranvier
    Legendary
    *
    Offline Offline

    Activity: 1400
    Merit: 1014



    View Profile
    June 04, 2014, 12:56:30 PM
     #5
    Quote from: franky1 on June 04, 2014, 08:00:58 AM
    so its not 'theoretically' possible to hide a trojan horse in the main bitcoin-core
    Haven't you ever heard of this NSA crowdsourcing program?

    http://en.wikipedia.org/wiki/Underhanded_C_Contest

    Quote
    The Underhanded C Contest is a programming contest to turn out code that is malicious, but passes a rigorous inspection, and looks like an honest mistake. The contest rules define a task, and a malicious component. Entries must perform the task in a malicious manner as defined by the contest, and hide the malice. Contestants are allowed to use C-like compiled languages to make their programs.

  • jonald_fyookball
    Legendary
    *
    Offline Offline

    Activity: 1302
    Merit: 1019


    Core dev leaves me neg feedback #abuse #political


    View Profile
    June 04, 2014, 04:08:52 PM
     #6
    The most critical part of bitcoin is arguably the implementation of ECDSA, which would probably be the most scrutinized and heavily reviewed code.  Thus, it would seem unlikely that a serious exploit could be introduced.
    proof LN isn't Decentralized           official Electron Cash wallet

  • Este Nuno
    Legendary
    *
    Offline Offline

    Activity: 826
    Merit: 1002


    amarha


    View Profile
    June 04, 2014, 07:25:36 PM
     #7
    Quote from: justusranvier on June 04, 2014, 12:56:30 PM
    Quote from: franky1 on June 04, 2014, 08:00:58 AM
    so its not 'theoretically' possible to hide a trojan horse in the main bitcoin-core
    Haven't you ever heard of this NSA crowdsourcing program?

    http://en.wikipedia.org/wiki/Underhanded_C_Contest

    Quote
    The Underhanded C Contest is a programming contest to turn out code that is malicious, but passes a rigorous inspection, and looks like an honest mistake. The contest rules define a task, and a malicious component. Entries must perform the task in a malicious manner as defined by the contest, and hide the malice. Contestants are allowed to use C-like compiled languages to make their programs.

    That is pretty wild. I had never heard of this. I wonder how many people have been caught trying to pull something like this on open source projects? I also wonder how many people(if any) have gotten away with inserting such code(intentionally of course) in to any major open source projects.

  • freedombit
    Sr. Member
    ****
    Offline Offline

    Activity: 274
    Merit: 250


    View Profile
    June 05, 2014, 04:08:43 AM
     #8
    Quote from: Este Nuno on June 04, 2014, 07:25:36 PM
    Quote from: justusranvier on June 04, 2014, 12:56:30 PM
    Quote from: franky1 on June 04, 2014, 08:00:58 AM
    so its not 'theoretically' possible to hide a trojan horse in the main bitcoin-core
    Haven't you ever heard of this NSA crowdsourcing program?

    http://en.wikipedia.org/wiki/Underhanded_C_Contest

    Quote
    The Underhanded C Contest is a programming contest to turn out code that is malicious, but passes a rigorous inspection, and looks like an honest mistake. The contest rules define a task, and a malicious component. Entries must perform the task in a malicious manner as defined by the contest, and hide the malice. Contestants are allowed to use C-like compiled languages to make their programs.

    That is pretty wild. I had never heard of this. I wonder how many people have been caught trying to pull something like this on open source projects? I also wonder how many people(if any) have gotten away with inserting such code(intentionally of course) in to any major open source projects.

    Is there a contest like this for Bitcoin or crypto? If not, then there should be. And then just hope that there are more white hats than black hats. If there are more black hats, then we are doomed as a race. ;-)

  • AGD (OP)
    Legendary
    *
    Offline Offline

    Activity: 2070
    Merit: 1170


    Keeper of the Private Key


    View Profile
    June 05, 2014, 07:03:48 AM
     #9
    Quote from: justusranvier on June 04, 2014, 12:56:30 PM
    Quote from: franky1 on June 04, 2014, 08:00:58 AM
    so its not 'theoretically' possible to hide a trojan horse in the main bitcoin-core
    Haven't you ever heard of this NSA crowdsourcing program?

    http://en.wikipedia.org/wiki/Underhanded_C_Contest

    Quote
    The Underhanded C Contest is a programming contest to turn out code that is malicious, but passes a rigorous inspection, and looks like an honest mistake. The contest rules define a task, and a malicious component. Entries must perform the task in a malicious manner as defined by the contest, and hide the malice. Contestants are allowed to use C-like compiled languages to make their programs.

    Did this guy win the contest?

    http://www.dailymail.co.uk/sciencetech/article-2602277/Heartbleed-accident-Developer-confesses-coding-error-admits-effect-clearly-severe.html
    Bitcoin is not a bubble, it's the pin!
    +++ GPG Public key FFBD756C24B54962E6A772EA1C680D74DB714D40 +++ http://pgp.mit.edu/pks/lookup?op=get&search=0x1C680D74DB714D40

  • Soros Shorts
    Donator
    Legendary
    *
    Offline Offline

    Activity: 1618
    Merit: 1012



    View Profile
    June 05, 2014, 07:34:39 AM
     #10
    Quote from: Este Nuno on June 04, 2014, 07:25:36 PM
    Quote from: justusranvier on June 04, 2014, 12:56:30 PM
    Quote from: franky1 on June 04, 2014, 08:00:58 AM
    so its not 'theoretically' possible to hide a trojan horse in the main bitcoin-core
    Haven't you ever heard of this NSA crowdsourcing program?

    http://en.wikipedia.org/wiki/Underhanded_C_Contest

    Quote
    The Underhanded C Contest is a programming contest to turn out code that is malicious, but passes a rigorous inspection, and looks like an honest mistake. The contest rules define a task, and a malicious component. Entries must perform the task in a malicious manner as defined by the contest, and hide the malice. Contestants are allowed to use C-like compiled languages to make their programs.

    That is pretty wild. I had never heard of this. I wonder how many people have been caught trying to pull something like this on open source projects? I also wonder how many people(if any) have gotten away with inserting such code(intentionally of course) in to any major open source projects.
    I used to work for a financial institution and we had custom static code analysis modules developed for our build systems for the purpose of detecting malicious code checked in by programmers. There are common techniques as well as counter-measures so this is not a new thing. Disallowing uninitialized variables would probably neutralize half of the attacks.

  • turvarya
    Hero Member
    *****
    Offline Offline

    Activity: 714
    Merit: 502


    View Profile
    June 05, 2014, 07:39:35 AM
     #11
    Maybe I am wrong, but wasn't the Version 0.9 the one with the Heartbleed-Bug(0.8.6 didn't have it) and 0.9.1 the fixed Version?
    https://forum.bitcoin.com/
    New censorship-free forum by Roger Ver. Try it out.

  • franky1
    Legendary
    *
    Online Online

    Activity: 4662
    Merit: 5189



    View Profile
    June 05, 2014, 12:18:56 PM
     #12
    Quote from: turvarya on June 05, 2014, 07:39:35 AM
    Maybe I am wrong, but wasn't the Version 0.9 the one with the Heartbleed-Bug(0.8.6 didn't have it) and 0.9.1 the fixed Version?

    version 0.1-0.9 were all vulnerable. the version 0.9 was not released due to heartbleed, it was a standard scheduled release. no one in the world knew about heartbleed at this point... but it just happened to be around the time that the separate matter of heartbleed became public, and as such the dev's released a 0.9.1 update pretty quickly
    I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
    Please do your own research & respect what is written here as both researched opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at

  • turvarya
    Hero Member
    *****
    Offline Offline

    Activity: 714
    Merit: 502


    View Profile
    June 05, 2014, 12:46:57 PM
     #13
    Quote from: franky1 on June 05, 2014, 12:18:56 PM
    Quote from: turvarya on June 05, 2014, 07:39:35 AM
    Maybe I am wrong, but wasn't the Version 0.9 the one with the Heartbleed-Bug(0.8.6 didn't have it) and 0.9.1 the fixed Version?

    version 0.1-0.9 were all vulnerable. the version 0.9 was not released due to heartbleed, it was a standard scheduled release. no one in the world knew about heartbleed at this point... but it just happened to be around the time that the separate matter of heartbleed became public, and as such the dev's released a 0.9.1 update pretty quickly
    That can't be true:
    Quote
    The vulnerable code was adopted into widespread use with the release of OpenSSL version 1.0.1 on March 14, 2012
    http://en.wikipedia.org/wiki/Heartbleed

    Quote
    2012-03-16 - Bitcoin-Qt version 0.5.3.1 released
    • 2012-03-14 - Bitcoin-Qt version 0.5.3 released
    • 2012-01-09 - Bitcoin-Qt version 0.5.2 released


    https://bitcoin.org/en/version-history

    So, which Bitcoin-Qt vesion was first affected, depends on which first used OpenSSL 1.0.1.
    https://forum.bitcoin.com/
    New censorship-free forum by Roger Ver. Try it out.

  • AGD (OP)
    Legendary
    *
    Offline Offline

    Activity: 2070
    Merit: 1170


    Keeper of the Private Key


    View Profile
    June 05, 2014, 06:49:00 PM
     #14
    Quote from: franky1 on June 05, 2014, 12:18:56 PM
    Quote from: turvarya on June 05, 2014, 07:39:35 AM
    Maybe I am wrong, but wasn't the Version 0.9 the one with the Heartbleed-Bug(0.8.6 didn't have it) and 0.9.1 the fixed Version?

    version 0.1-0.9 were all vulnerable. the version 0.9 was not released due to heartbleed, it was a standard scheduled release. no one in the world knew about heartbleed at this point... but it just happened to be around the time that the separate matter of heartbleed became public, and as such the dev's released a 0.9.1 update pretty quickly

    I still have version 0.9.0 in my Download folder.
    Bitcoin is not a bubble, it's the pin!
    +++ GPG Public key FFBD756C24B54962E6A772EA1C680D74DB714D40 +++ http://pgp.mit.edu/pks/lookup?op=get&search=0x1C680D74DB714D40

  • sickpig
    Legendary
    *
    Offline Offline

    Activity: 1260
    Merit: 1014


    View Profile
    June 05, 2014, 07:30:53 PM
     #15
    Quote from: AGD on June 05, 2014, 06:49:00 PM
    Quote from: franky1 on June 05, 2014, 12:18:56 PM
    Quote from: turvarya on June 05, 2014, 07:39:35 AM
    Maybe I am wrong, but wasn't the Version 0.9 the one with the Heartbleed-Bug(0.8.6 didn't have it) and 0.9.1 the fixed Version?

    version 0.1-0.9 were all vulnerable. the version 0.9 was not released due to heartbleed, it was a standard scheduled release. no one in the world knew about heartbleed at this point... but it just happened to be around the time that the separate matter of heartbleed became public, and as such the dev's released a 0.9.1 update pretty quickly

    I still have version 0.9.0 in my Download folder.


    on linux bitcoin-qt/bitcoind are dynamically linked to the openssl library bundle with your distro of choice, hence you could have been vulnerable to heartbleed even with 0.9.0 or higher if your libssl package wasn't up to date

    Code:
    $ ldd `which bitcoin{-qt,d}` | grep ssl
    libssl.so.1.0.0 =>lib/i386-linux-gnu/libssl.so.1.0.0 (0xb5c8b000)
    libssl.so.1.0.0 =>lib/i386-linux-gnu/libssl.so.1.0.0 (0xb70b0000)

    I don't think the same applies for ms win and/or osx
    Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.

  • mymenace
    Legendary
    *
    Offline Offline

    Activity: 1596
    Merit: 1061


    Smile


    View Profile
    June 05, 2014, 07:41:19 PM
     #16
    if it is about choosing a secure currency and your underlying fear is why trust the bitcoin code

    its simple

    banks, other currency, shares, investments are subject to hackers, scams and thieves etc etc etc

    it is just a matter of choosing which one you believe to be the most foolproof

    for me a network and code monitored by the whole community rather than a company or other is far more trustworthy e.g. linux
    Grin

  • AGD (OP)
    Legendary
    *
    Offline Offline

    Activity: 2070
    Merit: 1170


    Keeper of the Private Key


    View Profile
    June 06, 2014, 09:17:29 AM
     #17
    I guess, most people here in this forum are pro Bitcoin
    Bitcoin is not a bubble, it's the pin!
    +++ GPG Public key FFBD756C24B54962E6A772EA1C680D74DB714D40 +++ http://pgp.mit.edu/pks/lookup?op=get&search=0x1C680D74DB714D40

  • pozmu
    Hero Member
    *****
    Offline Offline

    Activity: 770
    Merit: 504


    (っ◔◡◔)っ🍪


    View Profile
    June 06, 2014, 06:56:31 PM
     #18
    I'm 90% sure this will happen.


                ▄▄██████▄▄
           ▄█████████████▄     
      ▄██████████████████▄   
    ▄████▄███▄███▄███▄███▄ 
    ▄██████████████████████▄
    ██████▀███▀███▀███▀█████
    ████████████████████████
    ████████████████████████
    ██████▄███▄███▄███▄█████
    ▀██████████████████████▀
    ▀████▀███▀███▀███▀███▀ 
      ▀██████████████████▀   
          ▀██████████████▀       
               ▀▀███████▀▀  


    .color.

    ▄███▄
    █████
    ▀███▀




    ▄███▄
    █████
    ▀███▀



    ▄███▄
    █████
    ▀███▀


    ▄███▄
    █████
    ▀███▀

    		██
    ██
    ██
    ██

    .Colorful dApp Platform.    		██
    ██
    ██
    ██


    ▄███▄
    █████
    ▀███▀




    ▄███▄
    █████
    ▀███▀



    ▄███▄
    █████
    ▀███▀


    ▄███▄
    █████
    ▀███▀


    		.

  • AGD (OP)
    Legendary
    *
    Offline Offline

    Activity: 2070
    Merit: 1170


    Keeper of the Private Key


    View Profile
    June 07, 2014, 07:13:00 AM
     #19
    Quote from: pozmu on June 06, 2014, 06:56:31 PM
    I'm 90% sure this will happen.



    Is it possible that it already happened? I mean, there were several events in the past, in which bitcoins simply "disappeared" from trading sites and owners seemed to be clueless on how it was done.
    Bitcoin is not a bubble, it's the pin!
    +++ GPG Public key FFBD756C24B54962E6A772EA1C680D74DB714D40 +++ http://pgp.mit.edu/pks/lookup?op=get&search=0x1C680D74DB714D40

  • TheTruth4
    Member
    **
    Offline Offline

    Activity: 108
    Merit: 10


    View Profile
    June 07, 2014, 06:11:00 PM
     #20
    Is it possible the bug was introduced into OpenSSL intentionally?
    Pages: [1] 2 »  All
      Print  
Page 1
Viewing Page: 1

IRLBTC™ © 2025 IRLBTC.com