2 марта 2014 в 17:40

Атаки на банковские системы

Не припоминаю я на Хабре статьи про атаки на банки. Никакой теории и фантазии, реальная практика и скрины

Немного введения. Не так давно я выступал на VI уральском форуме по информационной безопасности банков, где много внимания было уделено новому стандарту ЦБ РФ об обеспечении информационной безопасности банковских систем, на эту же тему был и мой доклад. В стандарте выделено 7 этапов жизни банковских систем (ПО), от написания ТЗ до снятия с эксплуатации. И схема моего доклада была следующей — рассказать некоторые реальные истории атак, проецируя их на новый стандарт от ЦБ, и показывая, как бы он (стандарт) мог «сломать» эти вектора, если бы банки его применяли. А на Хабре я опубликую пересказ своего выступления (осторожно, картинки!). Ах и да — вся информация предоставлена исключительно с целью ознакомления и ни в коем случае не является руководством к действию.

История #1 — популярная, SSL'ная


Все мы знаем про SSL. Все sensetive данные должны передаваться через зашифрованные данные, в случае веба — это через HTTPS


Все мы знаем про этот зеленый цвет в начале навигационного бара. Кому я рассказываю?

И в случае атаки «человек посередине» со «стрипом» (подменой) сертификата
:
image

Браузер у клиента ругнется на неверный сертификат:


MitM гугла

«Покраснеет» и бар, и предупреждения будут во всё окно.

С банками тоже самое. Банк везде, где надо, прописал HTTPS для клиентов, везде они используют шифрованное соединение. И если будет перехват трафика — то клиент увидит предупреждение, данная техническая часть переходит на плечи разработчиков браузеров.

Но наступает момент, когда банк выпускает приложение под мобильные платформы. А вот тут уже проверка подобных вещей переходит на плечи разработчиков банковского клиента. Так как при такой же атаке — подмене сертификата между клиентом (мобильным приложением) и API банка может возникнуть ситуация, что сертификат не проверяется. Для атакующего атака проходит схожим образом


MitM proxy при подмене SSL трафика

Как результат — злоумышленник может подменить транзакцию у клиента и увести деньги. Проблемы на этапах:

  • Разработка ТЗ. ТЗ надо разрабатывать с учетом специфики ПО и знания будущей окружающей среды приложения, в т.ч. (а мы в данной статье только про это и говорим) с точки зрения безопасности;
  • Создание и тестирование. Ну, тут понятно. Ошибка по факту была реализована при написании кода, а тесты её пропустили;
  • Приемка и ввод в действие. В новом стандарте об этом сказано — вводите систему в действие — делайте пентесты.

P.S. А по хорошему, надо не только просто корректно проверять сертификат, а еще делать и SSL Pining — зашивать отпечаток сертификата банка в само приложение (и проверять!)

История #2 — хардкорная


Кажется, предыдущая история была слишком простой (хоть и популярной). Поэтому добавим технических приемов и поставим цель — проникнуть во внутреннюю сеть банка, т.е. получить подконтрольную машину. И не будем мудрить, идея вектора будет простой: заслать письмо со сплойтом и получить обратный шлюз.

Начинаем работу. Первое, собираем все доступные емейлы (через harvester, руками, как-то еще). Желательно найти почту сотрудников службы ИБ. Отправляем мы почту через SMTP протокол, который по своей архитектуре позволяет указывать любого отправителя. И получаем первый момент: отправлять мы письмо будем от службы безопасности банка оператору (стараясь увеличить уровень доверия).

Хорошо. Теперь надо подумать над вложением. Просто троян? Слишком просто. На помощь приходит доступный в паблике эксплойт — Adobe Acrobat Reader — ASLR/DEP Bypass Exploit with SANDBOX BYPASS, который аффектит сразу три ветки супер популярного ридера PDF и обходит всевозможные защиты. Вероятность, что именно он будет установлен в банке — очень велика.


1 — это мы, отправляем письмо, 2 — письмо доставляется до адресата, 3 — считаем, что адресат открыл письмо

Итак, мы на шаге 3. Скорее всего, мы попадем в КИС, где не должно быть интернета как такового (или очень ограниченный). Второй момент — применяем DNS tunneling для обратного шлюза. Вкратце — если вы в сети, где нет «интернета», но при пинге какого-нибудь сайта его IP резолвится, например

Pinging somesite.ru [162.243.231.60] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.


Это означает, что всё равно можно выбраться во внешнюю сеть. Часто встречается на практике в банках и во всяких отелях. Идея следующая — берется домен, который настраивается на свой специальный DNS сервер, который логирует к все обращения. Берутся данные и кодируются в поддомены этого домена. Грубый пример:

0x11112222222233333333.attacker.com
0x33333344444444445555.attacker.com
0x55555666666666777777.attacker.com
0x77777788888888999999.attacker.com

DNS сервер их расшифровывает и отдает обратные команды. Задача решена — доступ в внутреннюю сеть получен :)

Проблемы на трёх этапах: приемка и ввод в действие, эксплуатация, сопровождение и модернизация — для атакующего чаще всего «смотрятся» как один — проблемы во внутренней инфраструктуре.

История #3 – тру-банковская


Если первые две истории можно спроецировать не только на банки, то третья специфична по своей сути (хотя, кто знает). Банки не так часто разрабатывают свое ПО, а часто покупают боксовые решения. На атаку одного из них от BSS и направлена следующая статья (оговорюсь сразу, об этом уже множество раз было рассказано, в т.ч. моим коллегой JRun на ZeroNights).

ДБО — это системы дистанционного банковского обслуживания. И их разделяют — на физ. лиц и на юр. лиц. И у вторых в этих системах есть возможность — направлять документы в банк (любые!).


Выглядит как-то так

Документ отправляется:


Какой-нибудь наш документ после отправки

И приходит к оператору:


У оператора специальное десктопное ПО для обработки подобных заявок

Он его открывает, и после этого на нашем счету 13 млрд рублей:


Счет клиента, после того как оператор открыл вложение

WTF!?

Проблема архитектурная — ПО оператора устроено следующим образом: оно напрямую работает с БД SQL-запросами, и прямо в клиент зашивается логин: пароль для подключения к базе (да, они шифруются, но на общем ключе, который был успешно извлечен реверсом-инжинирингом ПО оператора). Интерфейс, логин/пароль самого оператора — лишь визуальные ограничения, которые можно просто выкинуть и подключиться SQL менеджером напрямую к базе.

Тут понятно, что главная проблема на этапе ТЗ и проектирования (ох, встречал я на Хабре статью, где автор в мобильном приложении также напрямую ходил в базу), но также на этапах создания, тестирования и ввода в действие. Да, архитектурная проблема, но можно ограничить запускаемые файлы на рабочей станции, в Windows сделать это не так сложно.

Думаю, на Хабре не так много банковских работников, но уверен, что и просто софтверным разработчикам/админам/тестерам было что почерпнуть.
Автор: @BeLove
Digital Security
рейтинг 221,72
Безопасность как искусство
Похожие публикации

Комментарии (54)

  • +3
    Спасибо, прекрасное доведение до публики некоторых частных проблем. На мой взгляд, немного смазаны решения задач, а именно не очень четко показаны решения этих проблем.
  • +1
    То что эти примеры взяты из реальной практики это печально. Особенно тем что это почти эталонные атаки которые уже много лет как описаны везде от учебников ИБ до глянцевых журналов на околокомпьютерную тематику.

    Можно ли сделать следующие выводы: Что уже начиная с этапа проектирования безопасности уделяется минимум внимания? Что соответствие международным стандартам ИБ не представляет интереса для российской банковской сферы? Угрозы реальны, но размеры убытков от них не оправдывают затрат на защиту?

    и показывая, как бы он (стандарт) мог «сломать» эти вектора, если бы банки его применяли.

    Жаль что в статью не вошла эта часть.
    • 0
      То, что мы встречаем в ТЗ банковских систем — или вообще нет пунктов про безопасность, или если есть, то минимальны и не достаточны (пример первый с SSL. SSL есть, но не работает). Новый стандарт как раз и направлен на исправление данных угроз, так что действия предпринимаются. И про размер убытков — вектор атак явно смещается с клиентов (частные случаи и долгие суды) на сами банки и АБС — а это уже не просто частный случай, это вообще весь банк.
  • +2
    Ох, этот клиент вообще притча во языцех. Мало того, что работает с помощью мамонтов и только на мастдае (IE 7 (на новых версиях — принудительная эмуляция) + куча ActiveX и подгрузок DLL), так еще и дебильно организован (с этими бумажными запросами сертификатов и т.д.).

    Пока самый удобный видел у альфа-банка, там только веб-клиент + подтверждение по SMS, уровень безопасности такой же, как и у 3D Secure.
  • –21
    С каких пор для обозначения канала связи используется символ СС?
    Я думал, что канал связи изображается как-то так:
    itmages.ru/image/view/1531024/93ac4d59

    Это невежество или демонстрация убеждений?
    • +2
      Я думаю, что так автор просто показал разрыв канала. Да и у символа СС наклон не такой.
    • +5
      Откуда вы знаете символ СС? Это как-то связано с вашими убеждениями?
      Я вот не знаю, как символ СС выглядит — и запросто мог нарисовать такой же, чтобы показать разрыв канала.
      • –17
        Ну так посмотрите:

        Теперь это родной символ Россиию Фашистской России!
        • –3
          Теперь это родной символ Россиию Фашистской России!


          Советую вам прекращать эксперементировать с легкими наркотиками.
    • +11
      offtop: А как по мне, просто две молнии символически нарисованы. Видеть всюду нацистскую символику — не к добру это.
      А за статью спасибо, сам общаюсь с программистом, он правда не в банке, а в федеральном казначействе работает, так что мне это тема близка.
    • +1
      Обратил внимание на некую схожесть только после вашего комментария. Что вам сказать… «У кого о чем болит». Не думаю, что подобные высказывания и обвинения здесь уместны.
  • +1
    Всякие веб и мобильные банкинги всегда очень интересны. Жаль что сделать это легально практически невозможно. 5 лет назад мне довелось поковыряться в клиенте своего банка под старушку WinCE 6. Через 10 минут мне позвонили и поинтересовались странной активностью с моего аккаунта. Пронесло. А у Вас такое исследование. Интересно.
  • 0
    Больше бы матчасти. MITM это конечно хорошо, но на текущий момент, по сетям гуляет огромное количество различных форм-грабберов и инжекторов. Более интересно было-бы почитать про то, как подобное зверье работает на зараженной машине. Как инжектится в процессы и тд и тп.
  • +1
    4 — использование флага Secure на куках если уж есть https
  • 0
    Мне, и не только мне, одна украинская «контора» предлагала взламывать банки (банковские сервисы) под видом работы. Так что такие подходы встречаются и даже оплачиваются по рыночным окладам.
  • 0
    Кстати, про SSL и банки. Где-то как-то слышал (©), что страница ввода данных карты должна быть с SSL EV-сертификатом. Последнее время всюду вижу обычный сертификат на таких страницах. Это я путаю, или же раньше такое условие все же было?

    Кроме того, убивал всегда тот факт, что у того же Тинькоффа (карта яндекс.денег) страница 3DSecure подтягивает какую-нибудь незначительную картинку по http и как следствие браузер ругается… И такое не только в ТКС, встречал и в киберплате подобное, и еще где-то, уж не вспомню…
  • 0
    после первой картинки исправьте пожалуйста опечатку
    Все мы знаем про этот цЗеленый цвет в начале навигационного бара. Кому я рассказываю?
    • 0
      Будьте добры, используйте личные сообщения для информирования об опечатках. Спасибо.
  • 0
    Давайте еще раз. Клиент отправляет оператору документ. «Документ» является совокупностью данных и запросов по внесению этих данных в банковскую БД. Я правильно понял?
    • 0
      Судя по всему document.scr это исполняемый файл в формате Windows PE.
      Так как пентестеры знали архитектуру атакуемой системы, скорее всего этот файл содержит механизм получения доступов и соединения с sql базой данных от имени оператора и с машины оператора, с последующим выполнением нужных sql запросов.
      • 0
        Именно так.
        • 0
          Стоит отметить, что вышеописанное характерно и сработает в том случае, если связка между системой ДБО и автоматизированной банковской системой (АБС) используется стандартная и вы знаете какая именно это связка(у БСС в их продукте этих связок много). И нужно отличать что БД ДБО это не БД АБС, в которой как правило есть разграничения по доступам и разграничение контроля, как правило изменение баланса счета без наличия первичных документов обнаружат в кратчайшие сроки и инициируют внутреннюю проверку с блокировкой подозрительного счета.
          А еще может быть связка не стандартной, мне, например, в свое время от предыдущего сотрудника досталась связка между АБС diasoft5nt (40я вроде в нотации БСС) и ДБО, так в этой связке кроме «гвоздей» была реализована антифрод система и все подозрительные документы просто сливались в специальную пачку и им присваивался статус фиктивных. Тем самым в любом случае операционист был вынужден обращать на документы внимание. И не зная реализации этой доработанной связки становится очень сложно реализовать подобное описанному в статье.
          • 0
            Абсолютно верно подмечено про различные базы ДБО и АБС, об этом я написал в комментарии ниже (кстати, классно, что умышленно опущенные моменты в статье всё-таки всплыли :) ). Смысл в том, что АБС забирает платежки из базы, где атакующий создает их уже с таким статусом, где ЭЦП не проверяется, как итог — генерация платежок хоть от кого и хоть кому.
            • 0
              >>Смысл в том, что АБС забирает платежки из базы, где атакующий создает их уже с таким статусом, где ЭЦП не проверяется

              Не спорю по поводу того, что проверки ЭЦП по-умолчанию(!) на стороне связки с БД ДБО и БД АБС нет. По крайней мере, когда я был сотрудником банка, то такой проверки со стороны связки по-умолчанию(!) в этих продуктах я не видел, АБС была Diasoft5NT.

              Но прошу отметить, что БСС и Diasoft предоставляют очень гибкие и очень мощные в плане кастомизации системы.
              Как я отметил в комментарии выше, у нас связка была немного переписана, были забиты специфичные для нас «гвозди» и проверки, не зная о которых сгенерить платежный документ в абс становится практически не возможным, т.к. связка не вываливала статусы наружу и из себя представляла черный ящик. Плюс в АБС у нас было разграничение по ролям и один человек, не мог переводить документы из статуса в статус, ко всем действиям привязывалась ЭЦП из АБС и был последконтроль.
              Но такая ситуация, когда и организационными и техническими мерами были внедрены системы тотального контроля, возникла после неприятного инцидента:).

              Насколько понимаю, в описанном примере, возникла ситуация, когда получилось в БД ДБО внести данные об остатках на счете и затем они попали в БД АБС? Или программный код из «Документ.scr» выполнялся уже в БД АБС?
              • +1
                В самом простом случае автопроцедура BSS выгружает документы которые находятся, например, в статусе «К выгрузке» (т.е. уже прошедшие автоконтроль и проверку ЭЦП). В данной атаке, как я понял, предполагается, что операционист может добавить документ напрямую в базу ДБО BSS сразу в нужном статусе «К выгрузке».
                • 0
                  >>> В данной атаке, как я понял, предполагается, что операционист может добавить документ напрямую в базу ДБО BSS сразу в нужном статусе «К выгрузке».

                  Нет тут немного другой сценарий в статье.
                  В статье описан пример с отправкой «произвольного документа в банк». Произвольный документ приходит в банк, и возможно операционист из своей кастрированной версии bsclient открывает это сообщение (например нам так посылали списки на зачисление зп), но опять же в диктмане можно 65 ветку настроить так, чтоб ничего кроме тхт приложить не смогли:

                  >>>У оператора специальное десктопное ПО для обработки подобных заявок
                  >>>Он его открывает, и после этого на нашем счету 13 млрд рублей:

                  Остается немного не понятным открывает автопроцедура на cbank'e «документ.scr» или все-таки операционист его ручками запускает?
                  • 0
                    Последний абзац немного неправильно написал.
                    Вот как он должен выглядеть:

                    Остается немного не понятным: открывает операционист свое прикладное ПО и вуаля() или он сохраняет «документ.scr» из вложения и потом его уже ручками запускает?
              • 0
                Программный код выполняется на машине оператора, соответственно «злобный бинарь» идет в БД ДБО.
                Если есть проверка платежки перед импортом ее в АБС — данный вектор ломается (но остаются некоторые другие вектора).
                • 0
                  Понятно. Ваш пост подтверждает простую истину: нельзя в сложных продакшн решениях использовать настройки по умолчанию.
  • 0
    Спасибо, очень интересная статья.
  • –2
    На самом деле, то что здесь описано в 95% случаев не работает и не будет работать применительно к банку. И вот почему…

    1. Про вариант атаки с SSL и открытыми паролями.
    Сейчас почти все банки вводят 2-х факторную авторизацию. То есть помимо логина и пароля для совершения платежа в интернет-банк нужно еще кое что:
    а) Одноразовый код, присылаемый на сотовый клиента, без этого кода ни одну операцию выполнить нельзя.
    б) Использование крипто-калькуляторов для создания одноразового кода подтверждения, без этого кода ни одну операцию выполнить нельзя.
    в) Использование всевозможных ключей eToken для подписания операции ЭЦП.

    Поэтому даже если MITM осуществима и пароль на вход украли, от него мало пользы без одноразового кода или eToken'a. Хотя и одноразовые пароли и eToken не дает 100% гарантию защиты, всетаки голова на плечах должна быть в любом случае.

    2. Про История #2 — хардкорная, тут идет в чистом виде социальная инженерия, в нормальных банках есть соответствующие положения касательно политики информациооонй безопасности, в которых описано что такое соц. инженерия и как на неё не поддаться, сотрудники уведомляются под личную подпись. Конечно человеческий фактор никто не отменял, но и банки тоже стараются это учесть в своей политике.

    3. История #3 – тру-банковская — да, тут проблемма есть, но она решается своевременным обновлением прикладного софта, того же Adobe Acrobat и Flash или использованием других программ.
    • 0
      1. Что мешает злоумышленнику показать пользователю нужную ему страницу с подтверждением, а потом самостоятельно отправить в банк совсем другие данные? Да, в SMS иногда будут приходить не те данные (а в некоторых случаях приходят не полные данные), но кто их сверяет?
    • +1
      1. Вообще-то воровать пароль не обязательно — достаточно украсть саму сессию. А все дополнительные проверки пройдет за нас сам пользователь. В этом и вся суть MITM-атаки.

      2. Вообще-то, суть этой истории — не про социальную инженерию, а про DNS-туннель. Скажите, а если бы лично вам поставили задачу настроить сеть так, чтобы исключить утечку информации — вы бы про DNS вспомнили?

      3. При чем тут Adobe Acrobat и Flash, если проблема — в собственном клиенте банка, человеческом факторе — и недостаточно параноидальной настройке ОС? Где вообще в этой истории встретились акробат с флэшем?
    • 0
      В первом случае вам не нужен пароль. Необходимо дождаться, когда клиент полностью войдет в систему и инициирует, например, перевод. Остается просто подменить номер счета, куда идут денежки.
      • –3
        Остается просто подменить номер счета, куда идут денежки.


        В нормальных Интернет-банках, где используется ЭЦП, такой фокус не пройдет.
  • 0
    2. Вообще-то, суть этой истории — не про социальную инженерию, а про DNS-туннель. Скажите, а если бы лично вам поставили задачу настроить сеть так, чтобы исключить утечку информации — вы бы про DNS вспомнили?


    Я в курсе про такую лазейку, еще 4 года назад делел тунель поверх DNS с помощь IODINE.

    3. При чем тут Adobe Acrobat и Flash, если проблема — в собственном клиенте банка, человеческом факторе — и недостаточно параноидальной настройке ОС? Где вообще в этой истории встретились акробат с флэшем?


    Вы видать плохо прочитали статью, в ней написано про Adobe Acrobat Reader — ASLR/DEP Bypass Exploit with SANDBOX BYPASS, и вектор атаки через PDF-файл, ибо EXE файлы прикреплять в Клиент-банк от BSS запрещено.
  • 0
    История №3 не очень реалистична.
    1. Кто из клиентов может отправить файл "*.scr", заверенный ЭЦП?
    2. А если документ поддельный, то почему документы, не прошедшие контроль ЭЦП отображаются у оператора?
    3. Тот грустный факт что в BSS используют разграничение прав на уровне приложения, но не используют на уровне СУБД, пожалуй я могу подтвердить, тем не менее ничто не мешает самостоятельно сделать нужные настройки на PAYDOCRU и т.п. документы
    • 0
      Да точно, совсем забыл в cbank'e БССа реализованы все возможные внутренние механизмы, правда мало кто ими пользуется.
      В этом комментарии habrahabr.ru/company/dsec/blog/214351/#comment_7375847 я отписался, что есть еще эшелон обороны, а именно связка между ДБО и АБС.
  • 0
    Отвечу одним комментом сразу на несколько, так как вопросы схожие. Еще раз отмечу, что условия не идеализированные, а были взяты из реальной практики.
    По первой истории с митмом мобильного приложения. Если внимательно читать статью, то сказано про изменение именно транзакции «на лету». В случае отсутствия двухфакторной авторизации — транзакция просто пролетит. Реальный же случай был именно с 2х факт. авторизацией — и пусть приходит смска, мы же митмаем на лету! ЭЦП, например при пополнении счета телефона (через моб. приложение) не требуется.
    Вторая история. Да, демо в основном показательно слабой настройкой самой сети, о чем также явно сказано в самой статье (снова делаю выводы, что статью читали «наискосок»).
    И третий случай. В BSS в ДБО для юр. лиц отлично крепятся .scr файлы, они же обычные исполняемые файлы под Windows. После атаки на оператора, извлечение конфига для подключения к БД .scr файл (кто вообще сказал, что это .pdf эксплойт? Это из второй истории) коннектится напрямую к БД. Да, это не основная БД банка (АБС), но из нее АБС забирает платежки. Трюк далее в том, что создаются платежки с таким статусом, где уже ЭЦП (самой АБС) не проверяется. В итоге платежки улетают куда надо (без оригинальной подписи).
    • 0
      Здесь принципиальная ошибка — у оператора есть разрешение на создание документов. Оператор может без внешнего проникновения совершать мошеннические действия.
      • 0
        О чем явно сказано в статье — что у оператора, по факту, sql доступ к бд. Расматривается модель внешнего нарушителя, а не внутреннего.
        • 0
          Ну давайте обсудим ситуацию #2. В некоторых крупных банках интернет с клиентскими АРМ ЛВС развязан или физически, или с использованием Citrix/RDP. И это, я считаю правильно, хотя и заставляет нести определённые издержки. Операционист в «одноклассниках» может и из дома поработать.
          • 0
            Всё верно, в идеальном случае. Но банков много (стоит зайти на banki.ru), есть не такие большие и не с такими ответственными админами, что часто встречается на практике.
  • 0
    Оффтоп: Странная ситуация приключилась с первой иллюстрацией (комменты + писали в личку). Честно, взял картинку с очень популярного и признанного многими ресурса по безопасности — OWASP: www.owasp.org/index.php/Man-in-the-middle_attack и в мыслях не было ничего про СС и подобные вещи. Решил заменить на черно-белую, совершенно нейтральную картинку.
    • +1
      Судя по оценке того комментария и ответов к нему хабрасообществом, проблема была надуманная. Ну или на хабре одни нацисты.
      • 0
        Пусть теперь в новой найдут что-нибудь :) а всё это конечно напоминает vk.com/wall-23308460_370179
  • 0
    Спасибо за интересную статью! :)
    Хотел немного уточнить:
    DNS сервер их расшифровывает и отдает обратные команды. Задача решена — доступ в внутреннюю сеть получен :)

    В этом случае необходимо выбирать минимальный TTL для своих ресурсных записей, иначе команды могуть «застрять» в DNS-кэше локального резолвера.
    • 0
      Надо просто запрашивать уникальные записи…
      • 0
        Тоже вариант, но в таком случае прийдется придумать оооочень сложную систему кодирования.

        А так достаточно просто 26 (+26) записей с буквами латинского алфавита и 10 для цифр. Либо же просто
        000-255.example.org для передачи ASCII кодов. Так целую телеграмму передать можно ;-) Конечно, можно подойти более изящно и зашифровать как-то эти символи, сменив порядок.
        • +2
          Вот это — действительно сложно. А закодировать команду — довольно просто. На самом деле, закодировать длинное сообщение — гораздо проще, чем реализовывать операцию «склейки» сообщения из однобуквенных фрагментов.
          • 0
            Да, именно, в таком случае согласен. На замечание с минимальными TTL всё равно остается в силе ;)
  • 0
    А про антиф-фрод системы нет ли у вас материала для статьи? Помню в прошлом было несколько простых критериев — лимит по сумме (например, свыше 1 000 000 рублей), или дополнительный ручной контроль подлинности документов при платежах новым контрагентам.

    Было бы интересно, до чего дошла научно-инженерная мысль.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка