О безопасности в сети Блокчейн в целом, а также о классификации экономико-технических атак узнаете вы от соучредителя BSU Blockchain and Smart Contracts Lab Григория Василькова. Данная презентация была представлена на одном из еженедельных образовательных митапов от компании cyber•Fund. Посмотреть полное видео с митапа можно здесь: https://www.youtube.com/watch?v=sn-g2xZ7WOs Прочитать текстовую версию выступления: https://golos.io/ru--blokcheijn/@cyberevents/klassifikaciya-ekonomiko-tekhnicheskikh-atak-spiker-grigorii-vasilkov Также вы можете задать интересующие вопросы непосредственно спикеру в Telegram @grvasilkov Информация о компании cyber•Fund Мы инвестируем и развиваем блокчейн проекты, способные кардинально менять наш мир в лучшую сторону, создавая экономику роботов и самовыражения людей. Больше о нашей работе вы можете узнать из следующих ресурсов: Наши проекты: сyber.fund - аналитика и разработка блокчейн систем Golos.io - медийная блокчейн платформа Satoshi.fund - первый фонд инвестирующий в криптоактивы Cyberstudio.io - помощь в проведении ICO Мы ждем вас в наших сообществах: Блог: https://blog.cyber.fund/ Email Newsletter: http://company.cyber.fund/#newsletter Социальные сети: https://golos.io/@cyberfund https://steemit.com/@cyberfund https://twitter.com/cyberfundio https://www.reddit.com/r/cyber_Fund/ https://www.facebook.com/cyberfund - официальная страница сyber•Fund https://www.facebook.com/blockchainmeetups/ - официальная страница cyber•Events (Блокчейн митапы, конференции, доклады) https://www.slideshare.net/CyberFund-Official Для разработчиков: https://t.me/CyberFundDev - telegram чат для блокчейн разработчиков https://github.com/cyberFund - наш репозиторий на Github с open source software https://github.com/cyberFund/Library - библиотека знаний по блокчейн

1. Классификация экономико-
технических атак

2. Introductions
About Me:
● Security researcher and auditor
● Co-founder BSU Blockchain and Smart Contracts Lab
● Co-founder BugBounty.Center
● Email:
○ gr.vasilkov@gmail.com
○ g@bugbounty.center
● Telegram: @grvasilkov
● LinkedIn: linkedin.com/in/grigoryvasilkov/

3. Множество блокчейн платформ с возможностью
имплементации умных контрактов

4. ● Общеизвестные: С++, C#, Java, Go, Solidity,
Kotlin, Rust, Scala, Javascript, Plutus;
● Свои собственные: Michelson, Simvolio и др.
Языки программирования умных контрактов

5. Ethereum. Solidity example:
Языки программирования умных контрактов
function safeWithdrawal() afterDeadline {
if (!fundingGoalReached) {
uint amount = balanceOf[msg.sender];
balanceOf[msg.sender] = 0;
if (amount > 0) {
if (msg.sender.send(amount)) {
FundTransfer(msg.sender, amount, false);
} else {
balanceOf[msg.sender] = amount;
}
}
}
}

6. EOS. C++ example:
Языки программирования умных контрактов
auto buyer_account = get_account( highest_bid.buyer.name );
while( highest_bid.at_price >= exchange_ask.at_price ) {
match( highest_bid, buyer_account, exchange_ask, seller_account );
if( highest_bid.quantity == eos_tokens(0) ) {
buyer_account.open_orders--;
save( seller_account );
save( buyer_account );
bids::remove( highest_bid );
if( !bids_by_price::back( highest_bid ) ) {
break;
}
buyer_account = get_account( highest_bid.buyer.name );
} else {
break; // buyer's bid should be filled
}
}

7. Exonum. Rust example:
Языки программирования умных контрактов
impl Api for CryptocurrencyApi {
fn wire(&self, router: &mut Router) {
let self_ = self.clone();
let self_ = self.clone();
let wallets_info = move |_: &mut Request| ->
IronResult<Response> {
if let Some(wallets) = self_.get_wallets() {
self_.ok_response(&serde_json::to_value(wallets).unwrap())
} else {
self_.not_found_response(
&serde_json::to_value("Wallets database is
empty")
.unwrap(),
)
}
};

8. Corda. Kotlin example:
Языки программирования умных контрактов
@InitiatingFlow
class FixSignFlow(val tx: TransactionBuilder, val oracle:
Party,
val partialMerkleTx: FilteredTransaction) :
FlowLogic<TransactionSignature>() {
@Suspendable
override fun call(): TransactionSignature {
val oracleSession = initiateFlow(oracle)
val resp =
oracleSession.sendAndReceive<TransactionSignature>(SignRequ
est(partialMerkleTx))
return resp.unwrap { sig ->
check(oracleSession.counterparty.owningKey.isFulfilledBy(li
stOf(sig.by)))
tx.toWireTransaction(serviceHub).checkSignature(sig)
sig
} } }

9. Hyperledger. Go example:
Языки программирования умных контрактов
func set(stub shim.ChaincodeStubInterface, args []string) (string,
error) {
if len(args) != 2 {
return "", fmt.Errorf("Incorrect arguments. Expecting
a key and a value")
}
err := stub.PutState(args[0], []byte(args[1]))
if err != nil {
return "", fmt.Errorf("Failed to set asset: %s",
args[0])
}
return args[1], nil
}

10. NEO. C# example:
Языки программирования умных контрактов
private static bool Transfer(string domain, byte[] to)
{
if (!Runtime.CheckWitness(to)) return false;
byte[] from = Storage.Get(Storage.CurrentContext, domain);
if (from == null) return false;
if (!Runtime.CheckWitness(from)) return false;
Storage.Put(Storage.CurrentContext, domain, to);
return true;
}
private static bool Delete(string domain)
{
byte[] owner = Storage.Get(Storage.CurrentContext, domain);
if (owner == null) return false;
if (!Runtime.CheckWitness(owner)) return false;
Storage.Delete(Storage.CurrentContext, domain);
return true;
}

11. Cardano. Plutus example:
Языки программирования умных контрактов
count : forall a. Tree a -> Nat {
count Leaf = Zero ;
count (Branch _ l r) = Suc (add (count l) (count r))
}
traversal : forall a. Tree a -> List a {
traversal Leaf = Nil ;
traversal (Branch x l r) = Cons x (append (traversal l)
(traversal r))
}
reverse : forall a. Tree a -> Tree a {
reverse Leaf = Leaf ;
reverse (Branch x l r) = Branch x (reverse r) (reverse l)
}

12. ● В публичных блокчейн платформах логика
разработки умного контракта доступна всем
участникам платформы
● Персональные данные, хранимые в умных
контрактах, также доступны всем
участникам платформы
● При получении данных из внешних
централизованных источников, умный
контракт не может явно гарантировать
достоверность этих данных
Проблемы построения безопасной архитектуры
приложений в блокчейне

13. ● Затрагивает движение ценных
криптовалютных единиц
● Разработка требует
экономического мышления
Особенности недостатков безопасности в
блокчейн системах

14. ● Race Conditions
○ Reentrancy
○ Cross-function Race Conditions
○ Pitfalls in Race Condition Solutions
● Transaction-Ordering Dependence (TOD) /
Front Running
● Timestamp Dependence
● Integer Overflow and Underflow
● DoS with (Unexpected) revert
● DoS with Block Gas Limit
● Call Depth Attack
Существующие технические недостатки
безопасности в умных контрактах

15. Только ли технические недостатки
безопасности актуальны для блокчейн
систем и приложений

16. Экономико-техническая атака - это совокупность действий
злоумышленника, приводящих к нарушению экономической
стабильности информационной системы. Результатом
успешной атаки может стать искажение пользовательских
данных хранящихся в информационной системе или
искажение экономических показателей.
Экономико-техническая атака

17. ● Системный анализ компонентов;
● Иерархия взаимодействия сложных элементов;
● Иерархическое управление элементами;
● Согласование целей в иерархических элементах;
● Обработка полученной информации;
● Оптимизация потоков информации в задачах
управления;
● Контроль и управление в организационных системах;
● Задачи классификации;
● Комплексная оценка элементов системы;
● Кибернетические модели социальных и экономических
систем.
Основные элементы экономической кибернетики

18. Классификация экономико-
технических угроз

19. Необходимо прогнозировать, как может повести себя пользователь,
если ему дать дополнительную экономическую стимуляцию или же
наоборот ввести ограничения. Если в основу логики приложения ляжет
неверная экономическая модель, то приложение может не выполнять
желаемых задач и участники могут понести материальные потери.
Данный класс недостатка безопасности чаще всего проявляется в
следующих моделях проектирования: эмиссия токенов, создание
реферальной программы, интеграция экономик блокчейн-приложения с
фиатной системой и т.п.
1. Несостоятельность экономической модели
приложения

20. Чаще всего рассматриваются следующие аспекты:
2. Невозможность прогнозирования внешних по
отношению к экономике приложения факторов
● Прогнозирование точного количества участников
приложения, которые будут использовать умный контракт;
● Прогнозирование потребляемого газа при отправке
транзакции;
● Внешние шоки, стимулирующие спрос или снижающие его,
такие как колебания ожиданий сообщества или резкое
изменение новостного фона.
● Стоимость токена по отношению к фиатным валютам
(слишком высокая или слишком низкая), а также резкое
изменение стоимости токена.

21. Для того чтобы отправить транзакцию, пользователю необходимо
понести дополнительные материальные издержки в виде газа,
даже если активация метода не принесёт никакой прибыли, что
приводит к возрастанию транзакционных издержек в приложении
и уменьшает привлекательность его использования для
пользователей. Поэтому разработчики придумывают различные
экономические стимулы для отправки транзакций.
3. Отсутствие стимулов обращения пользователей
к смарт-контрактам, транзакционные издержки

22. Некоторые из блокчейн платформ имеют замкнутую
экосистему, обращаются к внешним источникам через
внешних агентов - Оракулов, другие же позволяют это
сделать используя средства самой платформы.
Оракулы, как и любое другое ПО, подвержен рискам
компрометации. Также всегда существует риск подмены
данных на самом внешнем источнике. В таком случае
умный контракт будет считать полученные данные
валидными, что в свою очередь может отразится на работе
приложения.
4. Работа с непроверенными данными

23. Разрабатывается множество приложений, в которых вовлечена
деятельность сразу множества контрагентов. К таковым
приложениям можно отнести: создание депозитария на основе
блокчейна, развитие микрокредитования, децентрализованные
биржи, обменники, геймификация и т.п.
Во всех этих сущностях необходимо скоординированное
взаимодействие контрагентов приложения. Но т.к. для
реализации заложенного функционала приходится полагаться на
сторонних участников, всегда есть возникновение
преднамеренной или непреднамеренной ошибки, обусловленной
человеческим фактором.
5. Зависимость выполнения работы программы от
других участников

24. Большинство транзакций, использующихся в умных контрактах, представляют собой открытые
данные. Майнер решает вносить ли отправленную транзакцию в блок рассчитывая различные
метрики, такие как Gas Price и Gas Limit. Также насколько быстро будет принято решение о внесении
транзакции в блок, зависит от того, попадёт ли наша транзакция в Uncles, а также от времени
формирования нового блока. Злоумышленник может воспользоваться промежутком времени
внесения транзакции в блок, чтобы в дальнейшем повлиять на результат выполнения работы
транзакции.
6. Возможность манипуляции порядком исполнения
транзакций

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

26. Иногда скорость получения данных может не соответствовать
заявленной или внешний ресурс имеет проблемы с доступностью.
Быть может даже случится так, что необходимый нам
централизованный ресурс подвергся DDOS атаке или какая-либо
страна решила заблокировать его на своей территории.
Внутри замкнутых децентрализованных систем задержка с
получением данных тоже имеет место быть, например если
умный контракт зависит от определённых данных другого
контракта, которые должен внести сторонний участник системы.
К проблемам тайминга можно также отнести race condition при
включении транзакции в блок, если транзакция попадёт не в тот
uncles, или будет перегрузка блокчейн сети из-за большого
количества отправленных транзакций.
8. Задержки при получении информации

27. При правильной разработке архитектуры любого приложения, не следует доверять одному
единственному источнику получения данных. Цепочка получения данных очень длинная и
потенциально может быть изменена на любом участке. Правильным решением было бы получать
данные из нескольких независимых источников и сравнивать их. Если данные между собой
отличаются, то это расхождение необходимо заметить и принять меры.
9. Несоответствие полученных данных

28. Иногда, для удобства использования, умные контракты используют сторонние библиотеки или даже
обращаются к сторонним вызовам других контрактов. Данная архитектурная реализация может
помочь с процессом обновления умных контрактов, но одновременно ставит в зависимость
работоспособность самого приложения от работоспособности сторонних программ и библиотек.
10. Зависимость выполнения работы умных
контрактов от других умных контрактов

29. Если полученные данные не соответствуют ожидаемым, то в таком случае необходимо вызывать
исключение. Но может случиться так, что входные данные будут соответствовать ожидаемой
маске, но кардинально отличаться от текущих валидных.
11. Сложности прогнозирования и влияния на
входные данные

30. Блокчейн не является анонимным по своей природе, а
является всего лишь неперсонализированным. Это
означает, что если всего лишь один раз удастся
персонализировать адрес кошелька пользователя
блокчейн системы, то любой участник сможет составить
необходимую картину взаимосвязей данного
пользователя и сделать соответствующие выводы о его
предпочтениях.
12. Раскрытие и влияние собственных данных на
результат работы

31. Артур Пинчук
Роман Гребнев
Александр Бажанов
Максим Лазаревич
Константин Туровец
Павел Бука
Благодарности за рецензию и пометки

32. Вопросы