28 августа 2011 года сообщество Linux было слегка потрясено, узнав о взломе kernel.org — основного сервера для распространения исходного кода ядра Linux, главного места хостинга репозиториев ядра и разных дистрибутивов Linux. На kernel.org обнаружился троян с рутовым доступом, который оставался незамеченным в течение 17 дней. Его обнаружили благодаря сообщениям об ошибках в Xnest /dev/mem на машинах без установленной системы X Window.

Троян записывал пароли, вёл лог действий пользователей, предоставлял root-доступ и модифицировал ПО на сервере kernel.org.

Системный администратор kernel.org сообщил, что были модифицированы файлы, относящиеся к ssh (openssh, openssh-server и openssh-clients), а загрузчик трояна добавлен в стандартный скрипт загрузки сервисов rc3.d. Сайты kernel.org и git.kernel.org ушли в офлайн на 35 дней.



Серверы были очищены, программное обеспечение переустановлено. Только после этого открыли доступ к репозиториям.

Спустя некоторое время стало известно также о взломе веб-сайтов LinuxFoundation.org и Linux.com с утечкой учётных данных пользователей, в том числе паролей пользователей. Высказывались предположения, что это был первый этап атаки, на котором злоумышленник узнал пароль одного из разработчиков, имеющего рутовый доступ к kernel.org.

Система управления версиями Git гарантирует аутентичность исходного кода, который доступен для проверки миллионам пользователей. На тысячах серверов по всему миру хранятся копии кода ядра. Если бы кто-то попытался модифицировать его, то система контроля версий Git сразу бы сообщила об этом. Все 40 000 файлов ядра подписаны SHA-1 и подменить их невозможно.

Благодаря открытому коду и такой системе контроля ядро Linux надёжно защищено от внедрения посторонних троянов в старые файлы. Если у злоумышленника была такая цель, то ему не удалось выполнить поставленную задачу. По крайней мере, на данном этапе операции. Неизвестно, что конкретно он планировал делать дальше, после распространения своего трояна на компьютеры разработчиков. Кто знает, может, он хотел запушить коммит с трояном с компьютера Линуса Торвальдса?

Так или иначе, но почерк злоумышленника не был похож на методы работы спецслужб, у которых имеются более продвинутые инструменты, им не нужно красть пароли на форумах. Хотя и такую версию не исключали.



Kernel.org вернулся в онлайн к ноябрю 2011 года, за исключением нескольких второстепенных сервисов. Расследование инцидента при участии агентов ФБР продолжалось несколько лет, но им наконец-то удалось выйти на след злоумышленника.

1 сентября 2016 года Министерство юстиции США опубликовало пресс-релиз, в котором объявило о задержании программиста из Южной Флориды по подозрению в незаконном проникновении на компьютеры, принадлежащие организациям Linux Kernel Organization и Linux Foundation.

Подозреваемый — 27-летний Дональд Райан Остин — был задержан 28 августа 2016 года офицерами полиции посёлка Miami Shores, которые остановили на дороге его автомобиль. Ордер на арест был выписан 23 июня и рассекречен после ареста подозреваемого.

Судя по записи в базе данных жителей Флориды, Дональд Райан Остин родился 20 апреля 1989 года, домашний адрес: 3425 Collins AVE #518 Miami Beach FL 33140, удостоверение избирателя 116597683.


Квартира Остина находится в 300 метрах от побережья. Фото многоквартирного дома сделано в июне 2015 года, когда он достраивался

На момент преступления парню было 22 года.

Дональду Райану Остину предъявлены обвинения по четырём инцидентам «умышленных действий, нанёсших ущерб защищённому компьютеру», по статье 18 U.S.C. § 1030(a)(5)(A). Данная статья предусматривает штраф до $250 000 и/или тюремное заключение на срок до 10 лет, плюс компенсацию ущерба пострадавшей стороне. По четырём случаям Дональд может получить штраф $1 млн, тюремный срок 40 лет и требование компенсировать ущерб пострадавшим.

В судебных документах прокуратура обвиняет программиста в установке трояна Ebury и руткита Phalanx на серверы Odin1, Zeus1 и Pub3, которые находились в аренде у Linux Foundation и использовались для поддержания работы сайта kernel.org. Вредоносная программа работала с 13 августа 2011 года по 1 сентября 2011 года. Остина также обвиняют в заражении личного сервера электронной почты разработчика ядра Linux Питера Энвина (H. Peter Anvin) в те же сроки.



Учитывая серьёзность преступления, можно предположить, что одним штрафом программист не отделается. Всё-таки под Linux работает абсолютное большинство серверов и около двух процентов десктопных компьютеров в мире.

С другой стороны, Дональда вряд ли удастся обвинить в получении коммерческой выгоды, потому что на сервере kernel.org размещается свободного программное обеспечение, которое общедоступно и распространяется бесплатно.

Прокуратуре придётся много поработать, чтобы определить мотивы злоумышленника и объяснить его действия. Вероятно, в этих действиях не было корыстного мотива. На форумах предполагают, что парень просто хотел «взломать всех» и показать своё превосходство. Очевидно, он был неравнодушен к операционной системе Linux, хотя и не прислал ни одного патча. Его имени также нет в списке почтовой рассылки Linux Kernel Mailing List.

После задержания Остин представлен перед судом и был выпущен под залог $50 000, который оплатила семья его девушки.

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

Следующие слушания по его делу назначены на 21 сентября 2016 года, 9:30 утра, в суде Сан-Франциско.
Поделиться с друзьями
-->

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


  1. GreatBOND
    04.09.2016 15:24
    +4

    Жаль не сообщается нигде как именно его вычислили…


  1. pnetmon
    04.09.2016 15:37

    Арестовали в годовщину публичного обнаружения заражения сайта. Шутники однако… ;)


  1. ChALkeRx
    04.09.2016 18:33
    +4

    подписаны SHA-1 и подменить их невозможно.

    Как раз вот относительно этого назревает маааленькая проблема =).


    1. antonwork
      04.09.2016 18:53

      Так изменить код, чтобы он работал (с трояном) да еще контрольная хеш сумма SHA-1 (или даже MD5) сошлась — невозможно.


      1. ChALkeRx
        04.09.2016 19:17
        +2

        Если бы было возможно — то проблема бы не назревала, а уже бы вовсю давала последствия.


        До того, как будет возможно, по некоторым прикидкам осталось всего несколько лет (где несколько — это 3 для крупных участников или 5 для какого-нибудь университета). Про md5 тоже когда-то так говорили.


        Кстати, чтобы подложить закладку — достаточно внести какую-нибудь незаметную ошибку в какую-нибудь проверку, этого вполне может оказаться достаточно.


        1. tmin10
          04.09.2016 20:54

          За эти несколько лет как раз можно успешно перейти на SHA-256 и проблемы опять не будет в ближайшее время.


          1. ChALkeRx
            05.09.2016 11:11

            Ммм. Насколько я знаю, пока этим не занимаются (могу быть неправ). Да и это будет означать пересборку репозиториев (аналогично миграции с svn на git) и перезагрузку их у всех причастных (ну или локальную пересборку), плюс сломанные подписи коммитов. Плюс куча софта, работающего с git, будет вынуждена внести серьёзные изменения и обновиться, чтобы поддерживать новый хеш.


        1. antonwork
          04.09.2016 23:06
          +3

          sha1 ('uno due tre quattro cinque sei sette otto nove dieci') = '8d83cae8032da7a1ab3e2f611e42613e8e711a16'
          можно сгенерировать какой-нибудь трешь, что-то вроде 'aDSWLIYUDklqaigdrekRWERQW432 [и еще 100 кб данных]' который даст такой же хеш (коллизию), что и строка выше. Это может сработать при подборе пароля (без соли) или при выпуске сертификатов.
          Но для вычисления контрольных сумм (для программного кода) ЭТО НЕ РАБОТАЕТ. Нельзя так модифицировать исходный код, чтобы он был одновременно: а) компилируемый, б) содержал закладку, в) дал тот же хеш на выходе,
          (зануда мод) хотя теоретически это возможно, но боюсь, что вероятность меньше чем найти атом в нашей галактике


          1. Bodigrim
            04.09.2016 23:40
            +2

            Написать закладку, а затем подогнать хеш, модифицируя комментарии? Это при условии, что мы умеем находить коллизии, разумеется.


            1. Alexeyslav
              05.09.2016 13:53

              Комментариями в общем случае не получится. Чтобы подобрать коллизию потребуется вставлять символы с кодами от 0 до 255 а это гарантированно порушит компилируемость исходника т.к. компилятор точно не переварит символ с кодом 0(я думаю проблемы может вызвать любой из символов в диапазоне 0...15) в исходнике. Подбирать же коллизию с ограниченным набором символов во много раз сложнее и не даст гарантии существования такой коллизии.
              С двоичными файлами конечно же другое дело — всегда можно прицепить в конец свой двоичный блоб на который никто и слова не скажет.


              1. zagayevskiy
                05.09.2016 14:59

                … ограниченным набором символов… не даст гарантии существования такой коллизии.

                Кажется, кто-то не понимает суть коллизий.


              1. DimkaI
                05.09.2016 21:13

                Код 9 — TAB — используется.
                -/- 10 — LF — используется. В Windows как комбинация CR + LF (перевод строки)
                -/- 13 — CR — используется.
                -/- 12 — FF — устарел, но порой используют при печати для продолжения печати на новом листе.
                -/- 7 — BEEP — устарел.
                Вероятно только код 0 может вызвать проблемы, хотя текст в кодировке UTF-8 легко может в себе содержать и этот байт. Но не в этом суть.


              1. Abiron
                07.09.2016 10:40

                Как то на лабораторной была задача вывести текст максимально коротким кодом. Один из вариантов был — кодировать бинарные данные прямо в константах. В исходнике были символы с кодами от 0 до 255. gcc хорошо переваривал этот код, а вот большинство редакторов начинали глючить, приходилось компилировать из консоли. Но это было под виндой.


          1. jamezzz
            05.09.2016 00:15
            +2

            Почему нельзя? Можно добавить закладку и закомментированный сгенерированный трэш.


          1. ozzee
            05.09.2016 00:41
            +1

            Возможно. Просто потребуется очень мощный компьютер.


          1. ChALkeRx
            05.09.2016 07:26

            Ну, для md5 пару создать заранее давно можно, дело не в случайном треше и не в паролях.
            Смотрите: http://www.mscs.dal.ca/~selinger/md5collision/ — этому примеру десять лет, и это пример именно для работоспособной программы, где два бинарника дают один и тот же хеш и делают разные вещи. С исходниками такое тоже возможно сделать, поломав какое-нибудь условие, например.


            Вот со sha1 когда-нибудь случится как минимум то же самое, и это когда-нибудь может оказаться уже весьма скоро.
            Поэтому надо срочно что-то решать и менять адресацию блобов по sha1 пока не поздно.


      1. humbug
        04.09.2016 19:31
        +1

        Возможно. Только маловероятно…


    1. Lamaster
      05.09.2016 10:03

      > подписаны SHA-1
      Строго говоря, эта фраза полнейший бред. Наверное имелось в виду, что это fingerprint сертификата, которым подписывали бинарники?


      1. ChALkeRx
        05.09.2016 11:02

        Нет, судя по контексту, имелось ввиду, что git адресует все попавшие в него объекты (включая коммиты) по sha-1 хэшу.
        Поэтому чтобы подделать содержимое или историю так, чтобы куча форкнувших людей этого не заметила — нужно сломать sha-1, подменив код какого-то объекта с сохранением хэша.


  1. servermen
    05.09.2016 00:34
    +1

    >Остину приказано не приближаться к компьютерам, не пользоваться интернетом, любыми видами социальных сетей и электронной почтой.
    Интересно, а почему ему не запретили приближаться ещё и к своей девушке? У неё ведь интернеты наверняка тоже имеются!


    1. Maccimo
      05.09.2016 00:46

      Ещё интереснее то, насколько процент полностью соблюдающих подобные запреты отличен от нуля.


  1. ideological
    05.09.2016 10:45

    2011-2016. Как обычно объясняют в подобных случаях огромное количество пройденного времени?


  1. ChpoKDev
    05.09.2016 16:32

    Потрачено… А вообще, было бы интересно узнать как его вычислили, чтобы не повторять его ошибок расширить кругозор.