[THEORY] Reverse exploiting Bitcoin | Bitcointalksearch.org

AGD

legendary

Activity: 2070

Merit: 1164

Keeper of the Private Key

Just want to bring my old idea up, due to CVE-2018–17144 and a comment I read
https://medium.com/@awemany/600-microseconds-b70f87b0b2a6

Quote

I always feared that someone from the bankster circles, someone injected into the Bitcoin development circles with the sole goal of wreaking unsalvageable havoc, would do exactly what happened. Injecting a silent inflation bug. Because that is what would destroy one of the very core advantages that Bitcoin has over the current status quo.

Still pretty much possible to me to intentionally infiltrate obviously harmless code, that is in reality exploitable.

As a footnote I reapeat this link: http://en.wikipedia.org/wiki/Underhanded_C_Contest

AGD

legendary

Activity: 2070

Merit: 1164

Keeper of the Private Key

Quote from: jdbtracker on January 07, 2018, 05:50:41 AM

It is completely possible, I have worked in countless industries and I can tell you no one really cares enough to check... it's sad, but it's true.

A lot of the code has insane amounts of bugs and glitches, the best method practices have to be applied by a strict supervisor... an overworked supervisor trying to keep all the shit being submitted to them straight.
there are so many points of vulnerability that can be introduced by an exhausted team eager to perform, look at Intel, they knew about that processor flaw and they kept making them for 25 years... what does that tell you?

The best we can do is resolve the problems we can see now. patch every exploit we find as fast as possible.

I bet they have developed a lot more of these gimmicks meanwhile.

jdbtracker

hero member

Activity: 727

Merit: 500

Minimum Effort/Maximum effect

It is completely possible, I have worked in countless industries and I can tell you no one really cares enough to check... it's sad, but it's true.

A lot of the code has insane amounts of bugs and glitches, the best method practices have to be applied by a strict supervisor... an overworked supervisor trying to keep all the shit being submitted to them straight.
there are so many points of vulnerability that can be introduced by an exhausted team eager to perform, look at Intel, they knew about that processor flaw and they kept making them for 25 years... what does that tell you?

The best we can do is resolve the problems we can see now. patch every exploit we find as fast as possible.

AGD

legendary

Activity: 2070

Merit: 1164

Keeper of the Private Key

+1
Not as weird as it sounded years ago.... Tongue

AGD

legendary

Activity: 2070

Merit: 1164

Keeper of the Private Key

+1 because thanks to Gavn, we have a scenario, where exacty this reverse exploit could be implemented. Please core devs: Don't let it happen!

http://blogs.msdn.com/b/vcblog/archive/2014/02/04/challenge-vulnerable-code.aspx
http://www.underhanded-c.org/_p_26.html

AGD

legendary

Activity: 2070

Merit: 1164

Keeper of the Private Key

My idea of a scenario - Swedish military version here: http://cryptome.org/2014/11/heartbleed-cyber-op.pdf

After I read this, I am pretty convinced now, that there are countless possibilities to implement an exploitable code - even into open source software.

AGD

legendary

Activity: 2070

Merit: 1164

Keeper of the Private Key

Quote from: ?? on ??

You're kidding right
One person can't just go into the code and edit it as they place or dump malicious content
it is reviewed, cleaned, edited by other devs before it is completely published

Quote from: AGD on June 04, 2014, 03:34:27 AM

Quote from: franky1 on June 04, 2014, 03: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

From my posting #4
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.

TheTruth4

member

Activity: 108

Merit: 10

Is it possible the bug was introduced into OpenSSL intentionally?

AGD

legendary

Activity: 2070

Merit: 1164

Keeper of the Private Key

Quote from: pozmu on June 06, 2014, 01: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.

pozmu

hero member

Activity: 770

Merit: 504

(っ◔◡◔)っ🍪

I'm 90% sure this will happen.

AGD

legendary

Activity: 2070

Merit: 1164

Keeper of the Private Key

I guess, most people here in this forum are pro Bitcoin

mymenace

legendary

Activity: 1596

Merit: 1061

Smile

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

sickpig

legendary

Activity: 1260

Merit: 1008

Quote from: AGD on June 05, 2014, 01:49:00 PM

Quote from: franky1 on June 05, 2014, 07:18:56 AM

Quote from: turvarya on June 05, 2014, 02: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

AGD

legendary

Activity: 2070

Merit: 1164

Keeper of the Private Key

Quote from: franky1 on June 05, 2014, 07:18:56 AM

Quote from: turvarya on June 05, 2014, 02: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.

turvarya

hero member

Activity: 714

Merit: 500

Quote from: franky1 on June 05, 2014, 07:18:56 AM

Quote from: turvarya on June 05, 2014, 02: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.

franky1

legendary

Activity: 4410

Merit: 4788

Quote from: turvarya on June 05, 2014, 02: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

turvarya

hero member

Activity: 714

Merit: 500

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?

Soros Shorts

donator

Activity: 1617

Merit: 1012

Quote from: Este Nuno on June 04, 2014, 02:25:36 PM

Quote from: justusranvier on June 04, 2014, 07:56:30 AM

Quote from: franky1 on June 04, 2014, 03: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.

AGD

legendary

Activity: 2070

Merit: 1164

Keeper of the Private Key

Quote from: justusranvier on June 04, 2014, 07:56:30 AM

Quote from: franky1 on June 04, 2014, 03: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

freedombit

sr. member

Activity: 274

Merit: 250

Quote from: Este Nuno on June 04, 2014, 02:25:36 PM

Quote from: justusranvier on June 04, 2014, 07:56:30 AM

Quote from: franky1 on June 04, 2014, 03: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. ;-)

Topic: [THEORY] Reverse exploiting Bitcoin (Read 2451 times)