Все, що ви хотіли знати про уразливості Shellshock (але боялися запитати)

Пам'ятайте Heartbleed? Shellshock можна віднести до тієї ж «вагової категорії», з таким же стильним назвою, хоч і без класного логотипу (кому-то з департаменту маркетингу цієї проблеми треба б цим зайнятися). Але у Shellshock є потенціал стати не менш важливою птахом, ніж Heartbleed. І зараз я хотів би зібрати воєдино всю необхідну інформацію, яка допоможе усім бажаючим впоратися з ситуацією і уникнути можливих проблем з-за неочевидною, на перший погляд, загрози.

Для початку дозвольте поділитися з вами деякою інформацією з блогу Роберта Грема, який провів чудовий аналіз вразливості. Розглянемо нижче представлений HTTP-запит:

target = 0.0.0.0/0
port = 80
banners = true
http-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)
http header = Cookie:() { :; }; ping-c 3 209.126.230.74
http header = Host:() { :; }; ping-c 3 209.126.230.74
http header = Referer:() { :; }; ping-c 3 209.126.230.74

Якщо його застосувати до діапазону вразливих IP, то отримаємо такий результат:



Простіше кажучи, Роберт змусив купу віддалених машин пінгувати його, просто відправивши в мережу спеціально сформований запит. Занепокоєння викликає той факт, що він змусив ці машини виконати довільну команду (в даному випадку нешкідливий ping), що відкриває найширші можливості.

Що таке Bash і навіщо він нам потрібен?Можете пропустити цей розділ, якщо ви вже в темі. Але якщо ви не знайомі з Bash, то рекомендую ознайомитися з цим розділом для розуміння загальної картини. Bash — це командна оболонка (інтерпретатор), широко використовувана на Linux і Unix-системах, зазвичай з підключенням через SSH або Telnet. Bash також може працювати як парсер для CGI-скриптів на веб-сервері, наприклад, Apache. Свою історію Bash веде з 1980-х, де він розвинувся з попередніх реалізацій командної оболонки (назва походить від Bourne shell) і неймовірно популярний. Звичайно, є й інші інтерпретатори, але Bash йде за замовчуванням в Linux і Mac OS X, які, як ви розумієте, дуже широко поширені. Цей інтерпретатор навіть визнаний «однією з найбільш поширених утиліт Linux-системах». Саме поширеність Bash є головною причиною того, чому Shellshock настільки небезпечний.

Цей графік дає наочне уявлення про повсюдність Bash:



Половина інтернету працює на Apache (зазвичай встановлений під Linux), і це реально дуже, дуже багато. У тій же статті повідомляється, що ми вже перейшли рубіж в 1 млрд діючих веб-сайтів, а оскільки багато з них розташовані на масових хостингах, то ми маємо справу з величезною кількістю встановлених копій Bash. І крім веб-серверів не забудьте ще про безліч інших серверів та пристроїв під управлінням Linux. Але повернемося до цього пізніше.

Bash використовується для широкого спектру управлінських завдань, від конфігурування веб-сайтів до управління З вбудованим в периферійних пристроях, наприклад, веб-камерах. Такі можливості не повинні бути відкриті всім бажаючим, і теоретично доступні тільки авторизованим користувачам, що мають певні права доступу. Теоретично.

У чому суть вразливості?Ступінь серйозності ситуації можна оцінити по наступній цитаті з бази даних вразливостей NIST:

GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.
Уразливості присвоєно рівень «10 з 10», тобто гірше нікуди. Додайте до цього легкість здійснення атаки (Access Complexity низький) і, що ще важливіше, відсутність необхідності аутентифікації для використання Bash з допомогою CGI-скриптів. Давайте розберемося в суті самого бага.

Основна небезпека полягає в можливості довільно задати змінні середовища всередині інтерпретатора Bash, яка задає визначення функцій. Проблеми починаються в той момент, коли Bash продовжує обробляти команди інтерпретатора після визначення функції, що дозволяє здійснити атаку з впровадженням коду. Візьмемо лише один рядок з прикладу Роберта:

http header = Cookie:() { :; }; ping-c 3 209.126.230.74


Визначення функції — це
() { :; };
, а команда інтерпретатора — ping і її параметри. При обробці рядка інтерпретатором Bash, може бути виконана будь-яка команда. В контексті інтернету, це можна зробити через такий механізм, як CGI-скрипт, і необов'язково через заголовок запиту. Більше інформації можна знайти на сторінці seclists.org, ще там встановлено, що шлях і рядок запиту також можуть бути потенційним вектором атаки.

Звичайно, ситуацію можна пом'якшити просто відключивши CGI-функціонал. Але в багатьох випадках це надасть занадто серйозний вплив на ваш веб-сайт і, як мінімум, потребує активного тестування, щоб переконатися в його працездатності.

Наведений вище HTTP-запит простий і ефективний, будучи лише одним з багатьох можливих використань цього протоколу. Якщо взяти до уваги Telnet і SSH, і, очевидно, навіть, DHCP, то масштаб проблеми зростає багаторазово, незважаючи на те, що ми говоримо лише про атаки на веб-сервери. Поки що небезпека є тільки після аутентифікації в SSH, але надалі ми виявимо і інші вектори атаки.

Необхідно пам'ятати, що можливості зловмисників простягаються далеко за межі пінгування конкретних адрес, як у прикладі Роберта, це лише невеликий приклад самої можливості управління віддаленими машинами. Зараз питання стоїть так: якої шкоди здатні завдати зловмисники, виконуючи різні команди інтерпретаторів віддалених машин?

Які потенційні наслідки?Отримання доступу до інтерпретатору завжди було великою перемогою для атакуючого, тому що це рівнозначно отриманню контролю над сервером (з відповідним правами). Доступ до внутрішніх даних, перенастроювання оточення, поширення шкідників і так далі. Можливості майже безмежні і автоматизируемы. Є вже дуже багато прикладів експлойтів, які можуть бути легко застосовані проти великої кількості машин.

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

Те ж саме відноситься і до можливості запису файлів на віддалену машину. Це один з найлегших способів заміни сторінок чужому веб-сайті, не кажучи вже про поширення шкідливого ПЗ. Або як вам ось це?



Коли мова заходить про черв'яків, то мається на увазі злоблива, яке створює власні копії на систему-жертву. В якості прикладу дуже ефективного хробака можна привести XSS-хробака Samy, який інфікував мільйони веб-сторінок менш ніж за один день.

Небезпека Shellshock ще і в тому, що таким чином може початися епідемія заражень, особливо на ранній стадії, поки на більшості машин не закрита ця вразливість. Самі інфіковані машини будуть шукати нові жертви і інфікувати їх. І небезпеки зараз схильні всі публічні машини, а при проникненні через корпоративні файрволы вже ніде не буде спасіння. Люди вже експлуатують це прямо зараз. Зараз у розпалі справжня гонка озброєнь між тими, хто хоче використовувати пролом, і тими, хто хоче її закрити.

Які версії Bash схильні до вразливості?Всі версії за останні майже 25 років, включаючи 4.3. Порівняйте з Heartbleed, небезпеку якого були схильні до версії OpenSSL за останні два роки. Так, люди оновлюють версії, але це не робиться планомірно, і як не крути, Shellshock загрожує набагато більшого кількістю машин, ніж Heartbleed.

На жаль, але уразливість може зберегтися і в наступних версіях. Вже є відомості про латках, які виявилися не надто ефективні. Так що за цією уразливістю потрібно стежити дуже уважно, вона не з тих речей, про які можна забути після установки патча.

Коли була виявлена уразливість?Перше знайдене мною згадка було в дуже короткій замітці на seclists.org, опублікованій в середу близько 14-00 за Гринвічем. Більш детальна інформація була викладена на тому ж ресурсі через годину. Так що це дуже «свіжа» новина, і поки занадто рано говорити про масовій появі експлойтів в «дикій природі». Але це може відбутися дуже скоро, ймовірність збільшується з кожною годиною.

Як згадувалося вище, уразливість існує у всіх версіях Bash, створених за останні 25 років. Так що, теоретично, всі це час знаючі люди могли її використовувати.

Наші девайси під загрозою?Питання цікаве, адже існує безліч приладів, потенційно використовують Bash. Я маю на увазі «інтернет речей» (IoT), коли все більш широке поширення одержує призначення IP-адреси кожній дрібниці, від вилки до дверного замка і лампочки. Багато «інтернет-речі» використовують вбудовані версії Linux з Bash. Ті ж самі девайси вже продемонстрували серйозні діри в безпеці, наприклад, з лампочок LIFX можна отримувати ідентифікаційні дані по Wi-Fi. Так що вже і без вразливостей начебто Shellshock ми опинилися в ситуації, коли, підключаючи до мережі всілякі прилади і предмети, ми одержуємо безліч нових вразливостей в тих сферах, які раніше були абсолютно безпечні.

Це ставить перед нами багато нових завдань. Наприклад, хтось замислюється про те, щоб регулярно ставити патчі на лампочки? Враховуючи «довговічність» подібних пристроїв, навряд чи хтось буде займатися підтримкою вбудованого ПО. Згадайте історію з камерами Trendnet, що сталася кілька років тому. Безсумнівно, величезна їх кількість все ще залишається підключеними до мережі, тому що з точки зору оновлення їх набагато простіше поставити і забути. Є Твіттер-аккаунт, цілком присвячений публікації знімків з подібних камер, коли їх власники навіть не знають, що їх знімають. Це велика проблема, адже оновлення ПО периферійних пристроїв часто утруднено, тому що нас з часом буде оточувати все більше приладів і предметів зі всілякими уразливими.

Але інтерпретатор Bash також вже присутня у багатьох звичних приладах, наприклад, домашніх роутерах. Коли ви востаннє оновлювали його прошивку? Звичайно, якщо ви читаєте цей текст, то, ймовірно, ви з тих, хто регулярно займається подібними речами. Але звичайні користувачі про це навіть не думають.

У нас все працює ПО від Microsoft, нам треба турбуватися?Коротка відповідь — ні, довгий — так. Незважаючи на те, що існують версії Bash під Windows, для цієї екосистеми дана утиліта не є скільки-небудь поширеною. Також неясно, чи мають вразливість Shellshock Windows-версії Bash.

Однак той факт, що ви працюєте виключно у Windows-середовищі не означає, що Bash відсутній на машинах, які обслуговують окремі завдання вашого оточення. Як пояснює картинки хочу привести ілюстрацію з поста Ніка Крэйвера:



Як бачите, трафік проходить від вашої Windows-середовища через неWindows-пристрої. Можуть бути компоненти, що мають привілеї над фаєрволом, що можна буде зробити тоді з допомогою Shellshock?

Я сисадмін, що я можу зробити?По-перше, дуже легко можна визначити, чи знаходитеся ви в зоні ризику. Є один дуже простий тест, який просто виконує цю команду в вашому інтерпретатор (дозволив собі трохи змінити початкову команду — прим. pkruglov):

env X="() { :;} ; echo busted" bash-c "echo stuff"

У вас може з'явитися «busted», якщо наявна вразливість Shellshock.

Звичайно, потрібно в першу чергу закрити діру. Патч істотно знизить ризик виконання чужого коду в кінці Bash-функції. Для ряду Linux-дистрибутивів, наприклад, Red Hat, вже з'явилися інструкції, так що займіться цим як можна швидше (насправді, вже для більшості дистрибутивів вийшли патчі — прим. pkruglov).

Вже з'явилися інструкції з оновлення систем виявлення вторгнень (IDS), і їх негайно треба взяти на озброєння різним організаціям, особливо тим, в яких потрібно проводити тривалі тестування перед установкою патчів. Провайдер Qualys запропонував свій спосіб визначення атаки, напевно і багато інших IDS-провайдери працюють над цією проблемою.

Більш кардинальні способи включають в себе заміну Bash на інший інтерпретатор, або блокування піддається ризику системи. Обидва способи можуть мати далекосяжні наслідки, їх не варто застосовувати бездумно. Але саме це може стати головною особливістю Shellshock: швидке прийняття важких рішень, які можуть мати серйозний вплив на реальний бізнес, заради уникнення потенційно куди більш значної шкоди.

Ще одне питання постає куди більш гостріше: експлуатувався чи Shellshock вже кимось раніше? Це складно визначити, якщо не фіксувалися вектори атаки. І часто цього не буде відбуватися, якщо атака буде проводитися через HTTP чи POST-запит. На питання «чи були ми атаковані через Shellshock» найчастішою відповіддю буде такий: у нас немає доказів, що ми закрили цю вразливість. Це залишає власників веб-сайтів та інших систем в неприємній невідомості щодо того, чи були вони скомпрометовані.

Я користувач, що я можу зробити?Залежить від конкретної ситуації. Якщо ви використовуєте Mac OS X, то ця вразливість буде легко (і, сподіваємося, швидко) закрита за допомогою стандартного механізму оновлення. Перевірити, чи знаходитеся ви в зоні ризику, можна легко з допомогою тесту:



Це простий тест, хоча я сумніваюся, що середній користувач Мас з легкістю піде радам і перекомпилирует Bash.

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

Коротенько, поради користувачам такі: інсталюйте оновлення системи безпеки, не ігноруйте поради свого провайдера і постачальників використовуваного устаткування з вбудованим ПЗ. Остерігайтеся листів, запитують інформацію або дають інструкції по запуску, подібні послання часто приходять під час фішингових атак, які експлуатують «модні» власні страхи.

ПідсумокЗа всіма ознаками, ми знаходимося тільки на самому початку нашого дослідження всіх глибин цієї уразливості. Звичайно, проведено багато паралелей з Heartbleed, і в чому-то нам це навіть допомогло. На прикладі Heartbleed ми знаємо, що ситуація може погіршитися дуже швидко, а наслідки ми будемо розгрібати ще дуже довгий час.

Але в даному випадку все може бути куди гірше, ніж з Heartbleed. Якщо та вразливість дозволяла отримати віддалений доступ до невеликої кількості даних в пам'яті зараженої машини, то Shellshock дає можливість впровадити довільний код, що потенційно набагато небезпечніше. В цьому плані я погоджуся з Робертом:



Думаю, що мине ще день-два, і ми будемо холодити при думці, що ж ще може статися.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.