ETH украден на Ropsten

Кто-нибудь сталкивался со следующим сценарием на Ropsten:

  1. Вы создаете учетную запись в Geth и продолжаете переводить немного ETH себе через кран.
  2. Вы разблокируете учетную запись и приступите к составлению и запуску контрактов.
  3. Внезапно вы обнаруживаете, что все ваши ETH пропали, переведены на 0x6Ef57BE1168628A2bD6c5788322A41265084408a.

Это случилось со мной и группой участников во время семинара, где за считанные секунды был украден весь наш ETH.

Если вы посмотрите на транзакцию, которая произошла на этом счете в Etherscan, она проходит рывками, переводя на себя небольшое, а иногда и довольно значительное количество ETH.

Хотел узнать, объяснимо ли это. Я понял, что этот же адрес 0x6Ef57BE1168628A2bD6c5788322A41265084408a встречается и на Ринкеби.

Хотел упомянуть, что, поскольку это было просто испытание, никто из нас не защитил наш экземпляр Geth. Эта команда запускала экземпляр: geth --testnet --syncmode "light" --rpc --rpcapi db,eth,net,web3,personal,admin --cache=1024 --rpcport 8545 --rpcaddr 0.0. 0.0 --rpccorsdomain "*
Какие веб-сайты вы посещали, пока учетная запись была разблокирована? С этими настройками RPC любой веб-сайт, который вы посетили, мог получить средства.
Просто эфирскан. Все мы вводили идентификатор своей учетной записи в etherscan для отслеживания наших транзакций. Я знаю, что настройки RPC были небезопасными, но мне интересно узнать, как можно написать скрипт для поиска в блокчейне незащищенных гетов, чтобы украсть ETH, и как они это сделали.
Кажется маловероятным, что виноват Etherscan. Для любого другого веб-сайта это всего несколько строк кода: new Web3('http://localhost:8545')затем вызов web3.eth.getAccountsдля поиска аккаунтов и web3.eth.sendTransactionотправки эфира.
Это также не обязательно должен быть веб-сайт... программное обеспечение на вашем компьютере или, возможно, на любом другом в мастерской может сделать то же самое. Ничего особо сложного в этом нет.
Предполагая, что я хочу сделать 2 вещи: 1) иметь туманный кошелек, подключенный к моему экземпляру geth в облаке 2) выполнять транзакции локально с той же машины в облаке, как мне написать командную строку geth для ее защиты?
Я не тот человек, чтобы отвечать на этот вопрос. Я думаю , что --rpcaddr 127.0.0.1и избавиться от --rpccorsdomainявляются хорошим началом.

Ответы (1)

Я столкнулся с точно такой же ситуацией в частной сети, когда оставил учетную запись разблокированной на узле с общедоступным IP-адресом, чтобы посмотреть, что произошло - все средства были переведены на тот же адрес, который вы разместили, в течение нескольких секунд после пополнения учетной записи - Я был поражен тем, как быстро была найдена уязвимость, но не удивлен, что ею воспользовались!

Комментарии Smarx указывают на исправление для блокировки доступа к вашему локальному компьютеру: --rpcaddr 127.0.0.1и удаление --rpccorsdomain "*"тега позволит хорошо заблокировать все.

Если вы хотите расширить свою точку доступа, чтобы включить запросы web3 (например, разместить интерфейс DApp на сервере) и предположить, что вы хотите, чтобы локальные узлы работали и не использовали такие службы, как infura.io, есть несколько возможных вариантов. обходные пути:

  1. используйте Nginx (или аналогичный) в качестве обратного прокси -сервера , чтобы сохранить эту точку доступа открытой, но ограничить ее только авторизованными сторонами. Это не сильно отличается от подхода infura.io , и безопасность будет такой же хорошей, как и вы, в зависимости от применяемых методов аутентификации. Настройте Nginx для пересылки запросов на ваш RPC-порт geth и настройте geth для приема только локальных запросов с--rpcaddr 127.0.0.1
  2. web3.js 1.0 позволяет вам подписывать транзакции удаленно , поэтому вы можете держать узел в сети без учетных записей и просто использовать его для распространения этих подписанных транзакций напрямую, без возможности внешнего доступа к вашим учетным записям через интерфейс HTTP-RPC. Это не мешает кому-либо использовать ваш узел для чтения состояния и потенциального поражения его DDOS-атакой.
  3. ( очень рискованно, гораздо менее безопасно и не то, что я бы рекомендовал ) - держите ваши учетные записи финансируемых узлов заблокированными и включите personalтег в вашей конфигурации RPC, а затем отправьте web3.personal.unlockAccount(eth.accounts[0], "<password>")и web3.personal.lockAccount(eth.accounts[0])инструкции непосредственно до и после любых строк транзакции в вашем коде. Предотвращая простой вывод ваших средств с разблокированной учетной записи, включение personalтега сопряжено с собственными рисками, поскольку вы оставляете дверь открытой для ряда различных атак.
вы сказали: «Несмотря на то, что ваши средства не могут быть легко сняты с разблокированной учетной записи, включение личного тега сопряжено с собственными рисками, поскольку вы оставляете дверь открытой для ряда различных атак здесь». Можете ли вы предоставить информацию о том, что это за различные атаки? Отпирание и запирание — это то, что делает туман, не так ли? Также по умолчанию geth использует -rpcaddr 127.0.0.1, разве этого недостаточно, чтобы убедиться, что все запросы являются локальными? я любопытный
Включив personalобщедоступный IP-адрес, вы оставляете дверь открытой для атак методом грубой силы на пароли вашей учетной записи, поскольку злоумышленник может свободно пытаться разблокировать вашу учетную запись столько, сколько им захочется. Они также могут создать любое количество новых учетных записей на вашем узле и спамить сеть подписанными транзакциями с нулевой стоимостью из этих учетных записей, помимо других возможностей. Я не на 100% понимаю, как Mist работает с разблокировкой учетной записи — я думаю, что он может подписывать транзакции локально, а затем отправлять только подписанную транзакцию на узел, но я могу ошибаться.
В основном правильно, за исключением случаев, когда вы укажете --rpccorsdomain "*", и в этом случае любой веб-сайт, который вы посещаете, может (в javascript) выполнить запрос JSON к локальному хосту на порту RPC и инициировать транзакции и т. д., указав домен CORS с подстановочным знаком в ответе, который вы сообщаете браузер это нормально и что вы одобряете такие действия.
Я провел собственное испытание. Я указал --rpcaddr 0.0.0.0 и --rpccorsdomain "<конкретный IP-адрес>". Мои ETH все еще были украдены. Из этого я сделал вывод, что скрипт вора ETH не был написан для кражи через межсайтовый скрипт. Это правильный вывод?
Если ваш узел не работает или ваш фильтр домена rpc cors включен и работает, то хакер теоретически не сможет вывести деньги... однако, возможно, он был достаточно умен, чтобы оставить скрипт работающим на вашем узле или что-то в этом роде.
ETH украден на Ropsten
СпросиСетьПолитика конфиденциальности1y, 0v