Ruby

Аналіз інциденту вторгнення на helium.ruby-lang.org

Опублікував Shugo Maeda 22-07-2004
Переклав: Andrii Furmanets

Як вже повідомлялося, helium.ruby-lang.org, який є одним із серверів, що надавали різні сервіси, пов’язані з розробкою Ruby, був зламаний несанкціонованим користувачем. Ми, адміністратори ruby-lang.org, повідомляємо про наш аналіз цього вторгнення та заходи, які ми вжили.

Хронологія інциденту

Прогрес часу щодо вторгнення показано нижче. Кожен час у UTC.

19 травня       Оголошено публічне розкриття вразливості CVS
               (CAN-2004-0396). Ми вважаємо, що ця
               вразливість була використана в цьому вторгненні.
20 травня 02:46 Пакет Debian CVS хоста helium.ruby-lang.org
               (далі називається 'helium') оновлено. Однак,
               пакет CVS середовища chroot, який надавав фактичний pserver,
               пропущено.
23 травня 11:15 Найстаріша (підтверджена) мітка часу сліду вторгнення
27 травня 19:03 Відкриття бекдору, встановленого зловмисником
28 травня 09:26 Адміністратор ruby-lang.org виявляє слід
               вторгнення.
28 травня 09:35 Адміністратор відключає 'helium' від мережі.
28 травня 11:53 Адміністратор перезавантажує 'helium' та відновлює сервіси розсилки
               списків.
29 травня 07:28 Наше перше оголошення про це вторгнення.

Машини та сервіси того часу

Сервіси, пов’язані з Ruby, надавалися наступними двома машинами на час вторгнення.

helium.ruby-lang.org
Наступні сервіси надавалися ‘helium’.
  • CVS (cvs.ruby-lang.org)
  • HTTP (www.ruby-lang.org/raa.ruby-lang.org)
  • FTP (ftp.ruby-lang.org)
  • RSYNC (для дзеркальних сайтів)
  • ML (<Назва ML>@ruby-lang.org)
hydrogen.ruby-lang.org (далі називається ‘hydrogen’)
Наступні сервіси надавалися ‘hydrogen’.
  • HTTP (www.rubyist.net)
  • NFS (для експорту /home до ‘helium’)

Деталі вторгнення

На ‘helium’ сервіс pserver надавався під правами користувача anoncvs в середовищі chroot. Цей сервіс CVS використовувався для розробки Ruby, і кілька комітерів мали свої власні облікові записи. Публічний доступ CVS лише для читання дозволявся через обліковий запис користувача ‘anonymous’.

Як згадувалося вище, вразливість CVS була оголошена 19 травня. Хоча пакет Debian CVS ‘helium’ був оновлений 20 травня, пакет CVS середовища chroot не був оновлений.

За цих обставин адміністратор ‘helium’ виявив підозрілі процеси anoncvs 28 травня, 09:26 (UTC). Більше одного підозрілих виконуваних файлів було виявлено встановленими зловмисником(ами), включаючи програму, що створює бекдор, яка слухає TCP порт #54320. Ця програма бекдору працювала на час виявлення вторгнення. Час “Хронології”, згаданий вище, був визначений виводом команди ‘ps’ та міткою часу виконуваного файлу вторгнення. Ми повинні зазначити тут, що всі зовнішні з’єднання з бекдором були запобігнуті функцією фільтрації IP пакетів ядра Linux.

Ще одна примітка: зазвичай процес pserver створює тимчасову директорію (/tmp/cvs-serv<ID процесу>) для кожної сесії та видаляє її в кінці сесії. На час вторгнення більше однієї тимчасових директорій залишилося в директорії /tmp середовища chroot. Це припускає, що процеси pserver були завершені ненормально, можливо, атакою зловмисника(ів). З міток часу цих тимчасових директорій найстаріша - 23 травня, 11:15 (UTC). Час “Хронології”, згаданий вище, був визначений цією міткою часу. Порівнюючи мітки часу цих директорій з журналом сесій pserver, здається, що було кілька незалежних зловмисників, які атакували вразливість.

Це свідчення вказує, що зловмисник(и) експлуатували вразливість CVS та отримали права користувача anoncvs на ‘helium’. Зловмисник(и) могли отримати, змінити та знищити всю інформацію в межах середовища chroot.

Свідчення, такі як захоплення інших облікових записів, локальне підвищення привілеїв, або вторгнення поза середовищем chroot, на сьогоднішній день не знайдено.

Можливість вторгнення поза середовищем chroot

Для того, щоб зловмисники зламали захист chroot, потрібне підвищення до привілейованого користувача.

На час вторгнення ядро Linux, що працювало на ‘helium’, було версії 2.4.24. Патч для вразливості (backported з ядра версії 2.4.25) був застосований. Однак патч для вразливості setsockopt(2), виправленої в ядрі 2.4.26, не був застосований.

Код для атаки DoS, що експлуатує вразливий setsockopt(2), був продемонстрований, але вважається важким успішно досягти локального підвищення привілеїв з цього. Здається неможливим досягти підвищення привілеїв, якщо зловмисник не може отримати образ ядра цільового середовища. На ‘helium’ ядро не було з бінарного пакета, а було зібране з вихідного коду з індивідуально застосованими патчами. Тому можливість того, що зловмисник зміг досягти підвищення привілеїв, вважається мінімальною.

Відновлення сервісів

З першим розслідуванням ми припустили, що вторгнення було ймовірно лише в межах середовища chroot. Спочатку ми вирішили відновити сервіс розсилки списків на ‘helium’, тому що вплив призупинення поштового сервісу, з точки зору користувачів, був вважався найбільшим. Після перевірки, що не було змін бінарного пакета, а також що не було підозрілих налаштувань у файлах конфігурації, ми відновили сервіс розсилки списків.

Потім ми почали роботу з підтвердження для відновлення інших сервісів на ‘helium’, але незабаром вирішили замість цього ретельно перебудувати машину та відновити сервіси індивідуально після перевірки кожного. Це рішення було прийняте через складність перевірки великої кількості файлів.

Для відновлення сервісу нам потрібна була машина, використана як заміна для ‘helium’. Ми вирішили використати ‘hydrogen’, який хостив www.rubyist.net. ‘Hydrogen’ не надавав сервіс pserver і не знайдено слідів вторгнення на машині, але ‘hydrogen’ надавав /home як файлову систему, змонтовану через NFS, для ‘helium’. Щоб переконатися, що hydrogen не був скомпрометований, ми перевстановили ОС ‘hydrogen’ та встановили ім’я хоста ‘lithium’. Потім ми перемістили сервіс розсилки списків з ‘helium’ на ‘lithium’, разом зі сторінкою оголошення про вторгнення веб-сайту.

Далі ми перевстановили ОС ‘helium’ та встановили ім’я хоста ‘beryllium’. Ми плануємо мігрувати всі публічні сервіси на ‘beryllium’ у майбутньому.

Машини та сервіси наразі

Наразі сервіси, пов’язані з Ruby, надаються наступними двома машинами.

lithium.ruby-lang.org
Наступні сервіси надаються lithium.ruby-lang.org.
  • CVS (для розробки комітерів, без публічного доступу)
  • Розсилка списків (переміщення на ‘beryllium’ планується)
beryllium.ruby-lang.org
Наступні сервіси надаються beryllium.ruby-lang.org.
  • HTTP (www.ruby-lang.org/raa.ruby-lang.org/www.rubyist.net)
  • FTP (ftp.ruby-lang.org)
  • Anonymous CVS (cvs.ruby-lang.org)

Перевірка вмісту кожного сервісу

Ми далі пояснимо результати наших зусиль оцінити, чи була якась зміна або знищення сервісів зловмисниками.

Передумова

Найстаріше свідчення, яке ми маємо про вторгнення, з 23 травня, і це було підтверджено; оскільки цей слід міг бути видалений зловмисником(ами) з правами користувача anoncvs, ми не змогли зробити висновок, що це був перший день вторгнення. Оскільки свідчення вторгнення було з вразливості CVS, і оскільки немає інших вразливостей, які могли б бути експлуатовані для вторгнення в ‘helium’, ми впевнені, що зловмисник(и) зловживали вразливістю CVS і тим самим отримали доступ до ‘helium’.

Наша перевірка змін або знищення в сервісах базувалася на припущенні, що перше вторгнення виявиться після 19 травня, коли вразливість CVS CAN-2004-0396 була публічно оголошена.

CVS

Оскільки зловмисники, ймовірно, отримали права користувача anoncvs, ми були найбільш підозрілими та стурбованими щодо можливих пошкоджень CVS серед усіх сервісів на ‘helium’.

На час вторгнення було наступні чотири репозиторії CVS.

/src
Вихідний код
/www
Дані WWW
/doc
Документ
/admin
Файл управління для CVS

Серед них /www та /doc не потребували перевірки, оскільки їх вміст вже не використовувався. Більше того, ми вирішили призупинити використання /admin та просто видалити його.

Те, що ми пояснюємо далі, - це результати перевірки вихідного коду Ruby та кожного іншого модуля, включеного в /src.

Вихідний код Ruby

Ми розділили можливі зміни репозиторію CVS на дві категорії:

(1) Зміна історичних даних у файлах репозиторію CVS до 19 травня

(2) Зміна, яка замаскувала регулярні подання після 19 травня

Для (1) ми перевірили файли в репозиторії CVS за журналом cvsup після 19 травня, які зберігалися безпечно поза ‘helium’. Ми підтвердили, що не було ознак змін файлів у репозиторії CVS. Для (2) ми перевірили весь вміст комітів індивідуально та підтвердили відсутність будь-якого шкідливого коду після 19 травня. Це означає, що не лише немає шкідливого коду, але й що ми перевірили кожен коміт з комітером.

Наша перевірка підтримувалася даними з наступного URL.

  • Журнал cvsup
    https://www.ruby-lang.org/check-data/cvs/cvsup-log/
  • Вміст комітів з 19 травня до 28 травня
    https://www.ruby-lang.org/check-data/cvs/cvs-diff/

Більше того, на додаток до вищезазначеного матеріалу, ми зробили наступну додаткову роботу:

  • Ми підтвердили, що не було неузгодженості між файлами в репозиторії CVS на ‘helium’ та файлами на зовнішньому, безпечному сервері 21 травня.
  • Ми підтвердили, що не було неузгодженості в знімках CVS з 2003-11-02 до 2004-05-27 (день за днем) та знімках, створених з репозиторію CVS на ‘helium’.

Ми зробили висновок, що не було змін або знищення вихідного коду ruby в репозиторії CVS.

Модулі, крім вихідного коду Ruby

На додаток до вихідного коду Ruby, директорія /src репозиторію CVS має наступні модулі:

  • app
  • lib
  • rough
  • rubicon
  • ruby-parser
  • shim
  • vms
  • pocketruby
  • oniguruma
  • mod_ruby
  • eruby

Спочатку ми виявили, що лише наступні файли були змінені після 19 травня шляхом порівняння ctime файлів репозиторію з часами файлів, скопійованих на зовнішній сервер через CVSup:

  • lib/csv/lib/csv.rb,v
  • lib/csv/tests/csv_ut.rb,v
  • lib/soap4r/lib/wsdl/xmlSchema/parser.rb,v
  • lib/soap4r/lib/wsdl/xmlSchema/complexContent.rb,v
  • lib/soap4r/lib/wsdl/parser.rb,v
  • mod_ruby/lib/apache/eruby-run.rb,v
  • mod_ruby/lib/apache/erb-run.rb,v
  • mod_ruby/ChangeLog,v

По-друге, ми порівняли скопійований репозиторій CVS з репозиторієм CVS на ‘helium’, і ми підтвердили, що не було неузгодженості між ними, крім бінарних файлів у ‘pocketruby’. Оскільки ми вже об’єднали ‘wince’ в основну гілку ruby, ми не робили подальшої перевірки на pocketruby та припинили надання його вихідного коду.

Кожен з файлів, які були змінені після 19 травня, згадано нижче.

lib/csv/lib/csv.rb,v
lib/csv/tests/csv_ut.rb,v
lib/soap4r/lib/wsdl/xmlSchema/parser.rb,v
lib/soap4r/lib/wsdl/xmlSchema/complexContent.rb,v
lib/soap4r/lib/wsdl/parser.rb,v
Ми не впевнені щодо цих файлів. lib/csv та lib/soap4r вже об’єднані з ruby, і ці модулі використовуються лише підтримувачами кожного. lib/csv та lib/soap4r видалено з репозиторію CVS, і вони будуть розроблятися в іншому місці.
mod_ruby/lib/apache/eruby-run.rb,v
mod_ruby/lib/apache/erb-run.rb,v
Всі ревізії, включаючи гілки, були перевірені, і проблем не знайдено. Вони були кожен порівняні з випущеними вихідними пакетами, і підтверджено, що немає неузгодженостей.
mod_ruby/ChangeLog,v
Звичайні зміни файлу ChangeLog - це додавання вмісту(ів). ChangeLog можна перевірити наступними методами:

(1) Ми підтвердили, що немає проблеми в першій ревізії.

(2) Ми підтвердили, що немає проблеми в найновішій ревізії.

(3) Ми підтвердили всі ревізії, які включають зміни, не лише додавання.

Більше того, ми порівняли його з випущеними вихідними пакетами, і це підтверджено, що немає неузгодженостей.

На додаток, розробка mod_ruby та eruby переміщена на Subversion, тому ці назви модулів CVS змінено на mod_ruby-old та eruby-old.

HTTP (www.ruby-lang.org)

https://www.ruby-lang.org/{ja, en}/ генерується tDiary. Ми виконали наступне, щоб перевірити, що немає проблем з виконанням програми tDiary CGI:

  • Підтвердження відсутності підозрілого коду в програмах CGI
  • Перевірка коду в елементах <script>, вбудованих у вміст
  • Підтвердження відсутності підозрілих даних у файлах конфігурації

Більше того, ми перевірили вміст та пов’язані URL, але проблем не знайдено. Якщо знайдено будь-які проблеми, будь ласка, зв’яжіться з webmaster@ruby-lang.org.

Онлайн довідковий посібник

Онлайн довідковий посібник був на RWiki. Спочатку ми відновили вміст 29 лютого, потім застосували патчі, надіслані на зовнішні облікові записи електронної пошти 29 лютого. Потім ми порівняли його з вмістом на ‘helium’.

Diff можна отримати з:

https://www.ruby-lang.org/check-data/ruby-man/man-rd-ja.diff

Різниця Base64.rd походить від нових рядків, вставлених при отриманні листа. trap%3A%3ANilClass.rd.rej був відхилений, тому що той самий патч застосовано двічі. Скрипт diff порівняв файли з файлами з 61 хвилини раніше, тому той самий патч надіслано двічі.

Ми підтвердили, що жоден з них не був зачеплений вторгненням.

RAA

Ми зробили наступну перевірку даних.

  • Ми зробили щоденний diff даних RAA з 1) чистої копії даних RAA, зробленої резервної копії 27 березня, 2) щоденних резервних копій з 4 квітня до 28 травня, та 3) останніх даних RAA від 28 травня.

    2) та 3) розташовані в захищеній області chroot на машині. 1) чиста, тому що вона зберігається в середовищі розробки.

    • Оновлення даних RAA:
      http://raa.ruby-lang.org/announce/soapbox-diff-all-passphrasemask.txt
    • Новий запис RAA:
      http://raa.ruby-lang.org/announce/soapbox-new-passphrasemask.txt

  • Ми підтвердили відсутність підозрілих даних у вищезазначених diff.

Можна зробити висновок, що дані RAA від 28 травня (ті самі дані, які ми використовуємо для перезапуску сервісу RAA) не включають жодних підозрілих даних. Тому ми вирішили перезапустити сервіс RAA таким, яким він був 28 травня. Ми не можемо запевнити, що нормальні на вигляд зміни зловмисника не існують. Наприклад, зміна sampleproject 18 травня така:

== sampleproject
- updated: Sun May 09 12:35:19 GMT+9:00 2004
+ updated: Mon May 17 13:00:38 GMT+9:00 2004
- version: 0.0.8
+ version: 0.1.1

Жодні з цих даних не підозрілі, але можливо, що зміни були зроблені зловмисником. Тому ми просимо, щоб кожен власник проекту RAA ПЕРЕВІРИВ СВОЇ ЗАПИСИ RAA ТА ОНОВИВ ЇХ ДЛЯ ПІДТВЕРДЖЕННЯ. Для цього виконайте наступні кроки:

(1) Відкрийте сторінку проекту

(2) Перевірте інформацію про проект

(3) Перейдіть на сторінку “update”

(4) Натисніть кнопку “submit” (зробіть це навіть якщо оновлення не потрібне – цей крок для підтвердження)

Будь ласка, зв’яжіться з raa-admin@ruby-lang.org, якщо ви знайдете будь-які підозрілі дані в RAA, або у вас є будь-які питання. Дякуємо за вашу співпрацю.

FTP

Ми порівняли значення md5sum файлів на FTP з файлами, збереженими на зовнішньому, безпечному сервері, і не було різниць.

Однак ми не змогли перевірити наступні директорії. Отже, вони наразі не надаються.

/pub/ruby/contrib/
/pub/ruby/doc/
/pub/ruby/snapshots/
/pub/ruby/ML/
/pub/ruby/shim/

Якщо вам потрібні файли в цих директоріях, будь ласка, зв’яжіться з ftpadmin@ruby-lang.org.

Розсилка списків

Ми дослідили файли конфігурації кожної розсилки списків, і знайшли немає проблем. Однак списки членів та архіви листів не були ретельно перевірені.

Якщо у вас є будь-які проблеми, будь ласка, зв’яжіться з <Назва ML>-admin@ruby-lang.org.

Shugo Maeda <shugo@ruby-lang.org>
група адміністраторів ruby-lang.org

Останні новини

Більше новин...