дом Статии Анализ на основните экономико-технически заплахи за блокчейн приложения

Анализ на основните экономико-технически заплахи за блокчейн приложения

58
0

На пазара на информационната сигурност, като правило, на стъпка изостава от иновациите в света на информационните технологии. Много компании много често си спомнят за безопасността на продукта, в случай, когато нещо вече се е случило и последващите рискове за откриване и експлоатация на липса на сигурност надхвърлят цената на самостоятелно търсене недостатък и да я коригират.

Говорител на компанията BugBounty.Center Григорий Васильков — платформа за предоставяне на възможности за одит на сигурността за компании от трети страни в областта на блокчейн технологии и интелигентни договори — специално за ForkLog анализира основните рискове за блокчейн компании, свързани със сигурността. Общо ще бъдат публикувани три материал на тази становящуюся все по-актуална тема. С първия материал можете да намерите тук.

1. Провала на икономическата модели приложения

Описание: При проектирането на приложения за блокчейн-платформата, икономически чиито елементи се намират в сложна ценностна връзката помежду си, разработчика трябва да се симулира икономическото поведение на един или друг участник приложения.

Трябва да се предвиди, как може да се държат на потребителя, ако му се даде допълнително стимулиране на икономическата или обратното въвеждане на ограничения. Ако в основата на логиката на приложението ще неправилна икономически модел, приложението може да не се изпълнява желаната задача, а участниците — понесат материални загуби.

Този клас недостиг на безопасността най-често се проявява в следните модели на проектиране: емисиите токенов, изграждане на реферална програма, интеграция на икономики блокчейн-приложения с фиатной система и т.н.

Пример 1.1: като пример може да се разгледа следната икономически модел. Умен договор разходи за сметка на потребителите реферальные жетони приложения за извършване на някаква работа. За да се мотивират потребителите максимално дълго да използват разработено приложение, разработчиците решават да се предвиди логиката на договора така, че да жетони начислялись на всички потребители, по-рано които извършват полезна работа. Така, ако потребителят е извършил полезна работа, макар и на път, това не му е изгодно ще бъде да напускате приложението, защото той непрекъснато ще получават допълнителна печалба под формата на токенов за сметка на работата на други потребители.

В описани логика възниква веднага няколко слабости на сигурността, включително и технически, но засега ще се спра само на две икономическо-технически:

  1. Ако потребителят е извършил полезна работа пръв, ще получат допълнителна печалба постоянно и при него ще липсва стимул за работа в бъдеще, в този случай системата ще е осъществимо само чрез нови участници.
  2. Ако активни потребители ще станат прекалено много и да споделят эмитированных токенов ще бъде разпределена между всички съществуващи потребители, това потребителите, които са извършили полезна работа, ще недополучать заслужена печалба и рано или късно ще спрат да използвате приложението.

Начин за отстраняване: При проектирането на сложни системи, състоящи се от различни, не са свързани помежду си елементи, трябва да се опита да промоделировать вероятностни резултатите на заявлението, в резултат на което да се вземе решение дали да приеме един или друг модел на поведение.

2. Невъзможност за прогнозиране на външни по отношение на икономиката приложения фактори

Описание: Колкото по-зависима система от външни лица, по-сложно моделиране на всички компоненти. До данните видове есенции може да се дължи на следните елементи: участие на приложения, обработваните данни, вероятно резултат и др.

Ако предприемачът не може да се предвиди, получени от приложението на данни, правилното функциониране на договора може да се окаже под заплаха.

Предприемачът трябва да се обърне внимание като минимум следните аспекти:

  • Невъзможността за точно прогнозиране на броя на участниците приложения, които ще използвате хитър договор, тъй като за регистрацията на потребителя, като правило, е необходимо само Ethereum-адрес;
  • В сложни системи и методи не е възможно точното прогнозиране на консумация на газ при изпращане на транзакцията;
  • Външни шокове, стимулиране на търсенето или намалява нейната, като вибрациите на очакванията на обществото или драстична промяна на фон;
  • Цената на знак по отношение на фиатным валути (твърде високо или твърде ниско), а също и драстична промяна на стойността на знак. Този компонент може директно да се отрази на доходността на проекта, намаляване на рентабилността от използването на блокчейн-приложения в сравнение с конкурентите.

Начин за отстраняване: Един от начините за отстраняване на недостатъка е смяна на стратегия координаций. Желателно е да се разработи всяка от тях и да има предварителен план, при какви условия те автоматично да се използват.

В идеалния случай да се формира на базата на предварителен анализ на функционирането на системата. Но последното изисква познаване на алгоритми аэд-теории, които се използват за математическата подготовка на алгоритмистов и програмисти.

За промяна на стратегията трябва да бъде ассиметричный. В случай на работа на алгоритъма – фундаментално ассиметричный: при промяна на показателите ние не просто откатываемся назад, а създаваме нов алгоритъм. Така, например, при ръст на пазара да се опита да я улови, а при спад – намаляване на разходите. В резултат на това — алгоритми ярко ассиметричные, но икономическата ефективност се увеличава непрекъснато.

3. Липсата на стимули за лечение на потребителите на смарт-договори, транзакционните разходи

Описание: В този момент в блокчейне Ethereum умен договор не може да предизвика сам себе си. За активиране на всички съществуващи метод, е необходимо да страничен участник Ethereum мрежа изпрати сделката за стартиране на изпълним код.

За да изпратите транзакция, потребителят трябва да направи допълнителни материални разходи като газ, дори и ако активирането на метода няма да донесе никаква печалба, което води до нарастващ транзакционни разходи в приложението и намалява привлекателността му за ползване от потребителя. Така че разработчиците да измислят различни икономически стимули за изпращане на транзакции.

При проектирането на приложения не винаги се получава точно да определите какво количество емисии, необходими за активиране на един или друг метод, особено на този проблем може да възникне и по време на обработката на динамични данни.

Пример 3.1 Нека разгледаме един пример, когато умен договор зарежда равномерно на всички потребители на приложението бонус точки веднъж месечно. Този вид активност предполага допълнителен интерес от страна на потребителите към приложението. Има два начина за начисляване на точки:

  1. Начисляването се случва веднъж, собственик на интелигентни договор.
  2. Начисляването се случва на потребителя всеки път, когато той извиква метод на начисляване на точки.

В първия случай комисията майнеру под формата на газ плаща сам собственик на интелигентни договор. Че не винаги е изгодно за собственика, особено ако проектът е социален и не се включва печалба. И собственика е необходимо да се провеждат месечни допълнителни действия на повикване метод за начисляване на точки, което се въвежда елемент на централизация.

Във втория случай, комисионни такси носи не сам собственик на интелигентни договор, а потребителите на приложението. Ако потребителите твърде много и да трупат точки се извършва по формулата

където b е броят на всички бонус точки, u — потребител, x — бонус точки за всеки потребител, в този случай потенциална печалба на стойност точки могат да бъдат много по-ниски от разходите за транзакция. За този хакер е достатъчно да се генерира известно количество Ethereum адреси и да ги запишете на умен договор. В текущата логика на изпълнение на заявката е на разположение още и технически недостатък, като извън газ лимит в блока.

Начин за отстраняване: Разработчик на приложения трябва да се отчете, че потребителят носи допълнителни материални разходи при достъп до смарт договор. Така че винаги трябва да се оптимизират разходите на използвания газ в алгоритъма на приложения.

4. Работа с неизпитани данни

Описание: може Би, най-важният прилагането на интелигентни договор може да стане младата днес инфраструктура Интернет на нещата». Икономика на бъдещето — това е глобална мрежа от умните неща, общающихся един с друг с помощта на смарт договори. Благодарение на smart договори и «оракулам» (механизми, позволяващи на смарт договори за обмен на информация с външния свят), интелигентни автомобили ще могат сами да паркират автомобилите си и да заредим, умни къщи — да извършват финансови операции с наематели, и на безпилотни летателни апарати — » пазаруване и извършване на пица.

Сфера на приложение блокчейна се разширява, тъй като все повече и повече клонове и представители на бизнеса осъзнават перспективите на тази технология. Но за интеграция в икономиката на реалния свят от една тюринг-пълнотата не е достатъчно. Смарт договори, свързани с реалния свят и в Интернет на нещата, трябва да се обърнат към събития, ставащи извън затворена екосистема блокчейна, независимо дали това е промяна на състоянието на активите на борсата, в резултат на спортен мач или дори на времето.

Някои от блокчейн платформи са на затворена екосистема, която директно да не позволява достъп до външни източници, а други позволяват това да се направи с помощта на средства на перона. В първия случай, за получаване на достоверни данни за събития, излизащи извън рамките на блокчейна, смарт договор е необходим надежден външен агент — оракул. За блокчейна Ethereum един от най-популярните пророчества може да се счита за Oraclize. Този оракул, както и всяко друго, е податлив на рисковете от компрометиране. Дори ако не се разглежда на риска от смяна на информация в интерес на оракуле, това винаги съществува риск от смяна на данни към външен източник. В такъв случай умен договор ще се счита получените данни валидными, което от своя страна може да се отрази на работата на приложението.

Пример 4.1: В този пример умен договор е съставен към външен източник на api.търговец на наркотици.io за получаване на текущия курс на паунда на британската лира GBP по отношение на еврото е EUR. Ако сайтът api.търговец на наркотици.io ще бъде опростен и данни подменени са, а след това резултатите ще бъдат неправилни.

За скриване на компрометиране на ресурс api.търговец на наркотици.io атакуващият може да промени отношението на курса EUR/GBP само в момента на обръщане на един умен договор до оракула, считывая тази транзакция от Memory Pool.

Начин за отстраняване: Да се избегне заплахата от смяна на данни от различни източници, трябва да се предвиди логиката на работа по този начин, за един единствен източник на данни не може да повлияе на целия ход на изпълнение на програмата. Също така трябва да се направи анализ на ползите и разходите от въвеждането на надеждни тълкувание, тъй като стойността на получена информация може да бъде по-ниска цената на разгръщане на собствената си инфраструктура.

Надеждност информация за стойността на обезценяването на британската лира се постига преминаването на източник на информация в блокчейн. Същото важи и в случай на всички други редовни данни.

Когато самият външен източник на данни не желае да предоставя необходимата информация, в такъв случай е възможно да се логирование в блокчейн. Тогава всички временни манипулация с курса ще незаличими.

Надеждността на данни може да се увеличи, ако самият източник на данни изпращане на данни в интелигентен договор. Също така надеждността на данни може да се увеличи, ако договорите ще споделят общи неща. При това може да предизвика вълна от жалби до оракула така, за да временната подмяна на става трудно осуществимой.

В случай На измами с oracle може да добавите в система в състояние на протест, за намаление на цените, на коригиране на стойността на активите и курсове ги исправленным показатели, и да се въведе възможността за забавяне на окончателното плащане, за да се даде време на подаване на протест и рушвети. Но описываемым опция може да не е дошъл там, където е необходима висока скорост на обработка на финансови данни.

5. Зависимостта на изпълнението на програмата от други участници

Описание: ще Мине доста време, преди на умни договори ще бъдат въведени държавни организации и големи търговски компании за автоматизация на текущите процеси. Но сега се разработва множество приложения, в които са включени дейностите веднага множество участници. За такива приложения може да включват: създаването на централния депозитар въз основа на блокчейна, разработване на микрокредити, децентрализирано борса, топлообменници, геймификация и др.

Във всички тези сущностях е необходимо координирано взаимодействие на участниците приложения. Но тъй като ние за реализиране на продажба функционални трябва да разчитат на трета страна на участниците, винаги има появата на умишлено или неумишлени грешки, причинени от човешки фактор.

Пример 5.1: За по-голяма яснота демонстрация на липса, нека да разгледаме като пример за играта «Камък, ножица, хартия». Тази игра включва като минимум двама участници, които същевременно показват един от елементите на камък, ножица или хартия. Ако един от участниците камък, а друг-на хартия, а след това побеждава този, който хартия. Ако камъкът и ножици, а след това побеждава камък. Ако ножици и хартия, след което побеждават ножици. Ако и двамата едновременно се показват едни и същи елементи, кръг започва отначало.

Въпреки привидната простота на тази игра на логика, да го приложи напълно без грешки сигурност е доста трудно. Както си спомняме, всички транзакции, попадат първо в Memory Pool, които са достъпни за всички потребители на блокчейна Ethereum. Ако участниците ще изпрати игрални елементи в прав текст, а след това този участник, който изпраща своя елемент по-късно, може да гледате елемент на противника, изпратено по-рано, и по този начин да получи предимство.

За да се избегне това нечестно предимство, се препоръчва изпратени елементи предварително хешировать с помощта на случайни стойности, така наречената сол. След като всички участници в играта изпратили захешированное значение на елементите, на сесията на играта се счита за завършена, и за определяне на победителя трябва да изпрати още една сделка, съдържащ сол и открит елемент, равен на хешированному стойност. На пръв поглед, никакви недостатъци сигурност не, но това не е съвсем така.

Нека да разгледаме потенциалните икономическо-технически недостатъци по-подробно. За мотивация на играчите ще се въведе парична награда, равна на 2 Ether, който ще получи наградата на победителя. За да участва в играта всеки потребител трябва да направи вноска е равна на 1 Ether.

По-долу са икономическо-технически недостатъци, които могат да повлияят на изпълнението игра на логика:

  • Ако един от играчите, за да вземат участие в играта, се внася такса, за да започнете да играете, трябва да му се ще чакаме потвърждение вноска от втория участник. Този момент може никога да не отстъпват и 1 Ether първия участник ще бъде замразен, така че трябва да се предвиди възможност за връщане на премия, ако за определен интервал от време към играта не се присъединиха към участниците и не са направили необходимата сума на една вноска.
  • Ако и двамата играчи са направили необходимата сума за плащане, а също и изпратили захешированные игрални елементи, а след това за изпращане на транзакциите, съдържащи open елемент и сол, също така трябва да инсталирате определен интервал от време. Иначе един от участниците, за които размерът на печалбата малозначительна, може да дари своя принос, за да се замразява средства на съперника си. Дори при изпълнението на един вид логика, потребителите ще понесат материални разходи, за да активирате метода за връщане на вложените средства.
  • Ако и двамата непрекъснато ще покаже една и съща игра елемент, в този случай, разходите за изпращане на транзакциите могат потенциално надхвърля сумата на печалбата, и на някакъв етап играчите ще стане неблагоприятна повече изпраща транзакцията, причинени в което игра ще остане в режим на готовност.

Трябва да се отбележи, че ние прегледахме детска модел с двама участници. Ако участниците ще бъдат повече, сложността на изпълнение на играта се е съизмеримо с много нови играчи.

Начин за отстраняване: В приложения с много зависими икономически субекти трябва да включва логика намаление на цените на данни към предишните стойности при настъпване на клеймото или съответните задейства.

Желателно е също така да се предвиди възможност за налагане на глоба за нападателя в размер на стойността на транзакциите честните участници.

6. Възможност за манипулация реда на изпълнение на операциите

Описание: Повечето транзакции, използвани в интелигентните договори, представляват отворени данни. Данните от тези транзакции се вижда не само майнерам, но и всеки потребител Ethereum мрежа, който може да се обърнете към Memory Pool. Миньор реши, да ли е изпратено транзакция в блок, залагайки на различни показатели, като Gas Цена и Gas Limit. Бързина на вземане на решение за извършване на транзакции в блок също зависи от това, ще удари нашата транзакция в Uncles, и от време на формирането на нов блок. Сега е времето на формиране на блок отнема около 13 секунди. В пиковите изтегляния на мрежата Ethereum наблюдава ситуация, когато над 4000 транзакции повече минути не могат да влязат в блок.

Един хакер може да използва интервал от време за извършване на транзакции в блок, за в бъдеще да повлияят на резултата от изпълнението на работата на сделката.

Пример работния эксплоита, эксплуатирующего възможност за използване на фронтраннинг атака, може да разгледате на следния линк.

Пример 6.1: Класически пример за демонстрация на липса може да се счита за фронтраннинг. Фронтраннинг — неетични и в някои случаи на незаконна практика, когато брокерът поставя свой собствен поръчка преди-големият поръчка на клиента, който, според него ще доведе до движение на пазара. Търговец от клиента постъпва поръчка за закупуване на пакет ценни книжа, но той първо ги купува за себе си, а след това продава на търговеца или на пазара на по-висока цена.

Прилагането на този термин, за блокчейн системи, могат да бъдат с висока степен на вероятност да се предположи, че фронтраннингу изложени всички децентрализирана топлообменници и децентрализирана на борсата. В този случай атакуващият може да анализира Memory Pool наличието на транзакции, изпратени на умен договор на борсата. Ако заявлението за покупка или продажба на токенов ще отговарят на определени критерии, в този случай атакуващият може да се опита да накара майнера да го вземе на операция по-рано, например, като се използва по-високата цена на Газ Цена, което от своя страна ще доведе до реализирането на печалба за нападателя и промяна на борсата чаши за потребителя.

Начин за отстраняване: Един от възможните начини за отстраняване на недостатък, може да се използва алгоритъм за ZkSNARk. В такъв случай някой хакер ще бъде трудно да се получи информация за данните за цялата транзакция и да повлияят на крайния резултат.

Следва продължение.

Намери грешка в текста? Маркирайте го и натиснете CTRL+ENTER

Източник: forklog

ВАШИЯТ КОМЕНТАР

Please enter your comment!
Please enter your name here