Ars Longa, Vita Brevis » безопасность

Исправление проблемы обхода хранителя экрана в X11

Vladimir — Thu, 19 Jan 2012 12:18:51 +0000

Программистов всё больше, а профессионалов всё меньше

В X.Org Server 1.11 обнаружена уязвимость, позволяющая через манипуляции с клавиатурой обойти режим блокировки экрана и получить доступ к заблокированному рабочему окружению пользователя.

Подробности либо по ссылке выше, либо на OpenNet.

Исправление: в файле /usr/share/X11/xkb/compat/xfree86 закомментировать следующие строки:

interpret XF86_Ungrab {
action = Private(type=0x86, data="Ungrab");
};
interpret XF86_ClearGrab {
action = Private(type=0x86, data="ClsGrb");
};

После чего перезапустить X Server.

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

AOL Postmaster взломан!

Wandering Soul — Sat, 13 Aug 2011 12:26:58 +0000

A0L S3RV3RZ R00T3D BY H0DLUM L0LZ!

Ибо нефиг себя по-свински вести.

В исходнике домашней страницы присутствует такой код:

Облажались ребята по полной программе…

Корейцы разбушевались…

Vladimir — Fri, 05 Aug 2011 03:40:53 +0000

Не к добру…

Сегодня с утра наблюдается какая-то повышенная активность хакеров с корейскими IP-адресами.

Были замечены попытки подбора паролей на SSH со следующих IP-адресов:

14.36.36.243	14.32.0.0/11
14.42.239.118	14.32.0.0/11
59.2.171.221	59.0.0.0/11
59.2.184.48
59.17.15.76
59.29.157.41
61.76.108.200	61.72.0.0/14
119.195.195.78	119.192.0.0/11
119.199.168.176	119.192.0.0/11
121.131.45.67	121.128.0.0/11
121.146.29.82
121.159.193.229
121.165.92.190	121.160.0.0/11
121.169.48.28
121.187.210.87
175.209.131.3	175.192.0.0/12
220.73.5.10	220.72.0.0/12
220.82.171.129	220.72.0.0/12
221.153.60.141	221.144.0.0/12
222.97.10.66	222.96.0.0/12

Aug 5 02:33:49 sjinks sshd[14588]: Did not receive identification string from 220.73.5.10
Aug 5 02:33:49 sjinks sshd[14587]: Did not receive identification string from 220.73.5.10
Aug 5 02:33:49 sjinks sshd[14589]: Did not receive identification string from 220.73.5.10
Aug 5 02:33:49 sjinks sshd[14590]: Did not receive identification string from 220.73.5.10
Aug 5 02:33:49 sjinks sshd[14591]: Did not receive identification string from 220.73.5.10
Aug 5 02:33:57 sjinks sshd[14592]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=220.73.5.10 user=root
Aug 5 02:33:57 sjinks sshd[14597]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=220.73.5.10 user=root

Aug 5 03:18:40 sjinks sshd[25082]: Did not receive identification string from 59.29.157.41
Aug 5 03:18:40 sjinks sshd[25083]: Did not receive identification string from 59.29.157.41
Aug 5 03:18:41 sjinks sshd[25084]: Did not receive identification string from 59.29.157.41
Aug 5 03:18:41 sjinks sshd[25085]: Did not receive identification string from 59.29.157.41
Aug 5 03:18:41 sjinks sshd[25086]: Did not receive identification string from 59.29.157.41
Aug 5 03:18:49 sjinks sshd[25094]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=59.29.157.41 user=root
Aug 5 03:18:49 sjinks sshd[25091]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=59.29.157.41 user=root

Aug 5 03:18:56 sjinks sshd[25111]: Did not receive identification string from 221.153.60.141
Aug 5 03:18:56 sjinks sshd[25112]: Did not receive identification string from 221.153.60.141
Aug 5 03:18:56 sjinks sshd[25113]: Did not receive identification string from 221.153.60.141
Aug 5 03:18:56 sjinks sshd[25114]: Did not receive identification string from 221.153.60.141
Aug 5 03:18:56 sjinks sshd[25115]: Did not receive identification string from 221.153.60.141
Aug 5 03:19:04 sjinks sshd[25145]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.153.60.141 user=root
Aug 5 03:19:04 sjinks sshd[25147]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.153.60.141 user=root

Aug 5 03:19:49 sjinks sshd[25248]: Did not receive identification string from 121.169.48.28
Aug 5 03:19:49 sjinks sshd[25249]: Did not receive identification string from 121.169.48.28
Aug 5 03:19:49 sjinks sshd[25250]: Did not receive identification string from 121.169.48.28
Aug 5 03:19:49 sjinks sshd[25251]: Did not receive identification string from 121.169.48.28
Aug 5 03:19:49 sjinks sshd[25252]: Did not receive identification string from 121.169.48.28
Aug 5 03:19:57 sjinks sshd[25266]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.169.48.28 user=root
Aug 5 03:19:57 sjinks sshd[25271]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.169.48.28 user=root

Aug 5 03:21:58 sjinks sshd[26375]: Did not receive identification string from 61.76.108.200
Aug 5 03:21:58 sjinks sshd[26377]: Did not receive identification string from 61.76.108.200
Aug 5 03:21:58 sjinks sshd[26378]: Did not receive identification string from 61.76.108.200
Aug 5 03:21:58 sjinks sshd[26379]: Did not receive identification string from 61.76.108.200
Aug 5 03:22:06 sjinks sshd[26390]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.76.108.200 user=root
Aug 5 03:22:06 sjinks sshd[26393]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.76.108.200 user=root

Aug 5 03:22:01 sjinks sshd[26380]: Did not receive identification string from 220.82.171.129
Aug 5 03:22:01 sjinks sshd[26381]: Did not receive identification string from 220.82.171.129
Aug 5 03:22:01 sjinks sshd[26382]: Did not receive identification string from 220.82.171.129
Aug 5 03:22:01 sjinks sshd[26383]: Did not receive identification string from 220.82.171.129
Aug 5 03:22:01 sjinks sshd[26384]: Did not receive identification string from 220.82.171.129
Aug 5 03:22:09 sjinks sshd[26408]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=220.82.171.129 user=root
Aug 5 03:22:09 sjinks sshd[26425]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=220.82.171.129 user=root

Aug 5 03:32:59 sjinks sshd[28817]: Did not receive identification string from 59.17.15.76
Aug 5 03:32:59 sjinks sshd[28818]: Did not receive identification string from 59.17.15.76
Aug 5 03:32:59 sjinks sshd[28819]: Did not receive identification string from 59.17.15.76
Aug 5 03:32:59 sjinks sshd[28820]: Did not receive identification string from 59.17.15.76
Aug 5 03:32:59 sjinks sshd[28821]: Did not receive identification string from 59.17.15.76
Aug 5 03:33:07 sjinks sshd[28826]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=59.17.15.76 user=root
Aug 5 03:33:07 sjinks sshd[28828]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=59.17.15.76 user=root

Всем, кто не пользуется средствами типа Fail2Ban или LFD, самое время задуматься: отсутствие защиты и слабые пароли — короткий путь к участию в ботнете.

Если вы не ожидаете гостей из Кореи, очень рекомендую заблокировать эти адреса либо firewall’ом, либо через /etc/hosts.deny.

Блокирование при помощи iptables:

for i in 14.36.36.243 14.42.239.118 59.2.171.221 59.2.184.48 59.17.15.76 \
59.29.157.41 61.76.108.200 119.195.195.78 119.199.168.176 121.131.45.67 \
121.146.29.82 121.159.193.229 121.165.92.190 121.169.48.28 121.187.210.87 \
175.209.131.3 220.73.5.10 220.82.171.129 221.153.60.141 222.97.10.66; do \
iptables -A INPUT -s $i -j DROP; \
done

Агрессивное блокирование:

for i in 14.32.0.0/11 59.0.0.0/11 61.72.0.0/14 119.192.0.0/11 121.128.0.0/11 \
121.160.0.0/11 175.192.0.0/12 220.72.0.0/12 221.144.0.0/12 222.96.0.0/12; do \
iptables -A INPUT -s $i -j DROP; \
done

Если iptables поддерживает цель TARPIT, можно использовать её вместо DROP.

Блокирование с использованием tcpwrappers: нужно добавить такие строки в /etc/hosts.deny:

sshd: 14.36.36.243 14.42.239.118 59.2.171.221 59.2.184.48 59.17.15.76
sshd: 59.29.157.41 61.76.108.200 119.195.195.78 119.199.168.176 121.131.45.67
sshd: 121.146.29.82 121.159.193.229 121.165.92.190 121.169.48.28 121.187.210.87
sshd: 175.209.131.3 220.73.5.10 220.82.171.129 221.153.60.141 222.97.10.66

Коллеги, будьте бдительны!

Интеграция LFD с blocklist.de

Wandering Soul — Sun, 17 Jul 2011 18:17:24 +0000

Автоматическое уведомление blocklist.de при попытке атаки на сервер

LFD (Login Failure Daemon) — модуль замечательного пакета CSF (ConfigServer Security and Firewall), отвечающий за анализ системных журналов и блокировку потенциальных взломщиков.

CSF умеет отправлять отчёты об атаках в формате X-ARF (в виде, пригодном для перенаправления отчёта в отдел жалоб и нарушений провайдера атакующего). Но иногда хочется сделать добро окружающим людям — чем быстрее узнают о потенциальном взломщике и заблокируют его IP-адрес, тем меньше вреда он успеет нанести.

Один из сервисов, занимающихся публикацией IP-адресов всяких взломщиков — это Blocklist.de. Этот сервис очень хорошо интегрируется с Fail2Ban, но существует и возможность посылать отчёты и без Fail2Ban.

У LFD есть опция вызывать пользовательский скрипт при блокировке IP-адреса нарушителя; эту опцию можно использовать для отправки отчёта в Blocklist.de.

Пользовательский скрипт принимает 8 параметров:

IP-адрес нарушителя
Блокируемые порты
Тип блокировки (постоянная или временная)
Направление блокировки
Срок блокировки
Информация о причинах блокировки (например, (CT) IP 91.77.88.36 (RU/Russian Federation/ppp91-77-88-36.pppoe.mtu-net.ru) found to have 348 connections)
Строки из системного журнала/доказательства, свидетельствующие о попытке атаки
Триггер блокировки (идентифицирует атакуемый сервис)

Ниже приведена простая версия скрипта, отправляющая уведомление об атаке в Blocklist.de:

#! /usr/bin/perl

use strict;
use warnings;
use MIME::Lite; # Пакет libmime-lite-perl в Debian/Ubuntu

my $from = 'security@domain.com';
my $to = 'email@example.com';
my $rp = $from;

my $ip = $ARGV[0] || '';
my $ports = $ARGV[1] || '';
my $perm = $ARGV[2] || '';
my $inout = $ARGV[3] || '';
my $ttl = $ARGV[4] || '';
my $msg = $ARGV[5] || '';
my $logs = $ARGV[6] || '';
my $trigger = $ARGV[7] || '';

my %services = (
LF_SSHD => 'sshd',
LF_FTPD => 'ftpd',
LF_SMTPAUTH => 'smtpd',
LF_POP3D => 'pop3d',
LF_IMAPD => 'imapd',
LF_HTACCESS => 'httpd',
LF_MODSEC => 'httpd',
LF_BIND => 'named',
LF_SUHOSIN => 'httpd',
LF_APACHE_404 => 'httpd',
CT_LIMIT => 'portflood',
);

my $service = $services{$trigger} || '';

if ($service) {
my $email = MIME::Lite->new(
From => $from,
To => "$to,fail2ban\@blocklist.de",
Subject => "[Fail2Ban]: $service: banned $ip",
Data => "Hi,

The IP $ip has just been banned by Fail2Ban

$msg

Lines containing IP:$ip

$logs

Regards,

Fail2Ban",
);

$email->send("sendmail", "/usr/lib/sendmail -t -oi -r $rp");
}

Есть два настраиваемых параметра: $from и $to: первый используется blocklist.de для идентификации сервера, отправляющего отчёт об атаке (кроме того, адрес, указанный в $from, используется и как Return-Path); второй — адрес, на который отправляется копия уведомления (например, какая-нибудь CRM типа RT).

В /etc/csf/csf.conf нужно добавить строку:

BLOCK_REPORT = "/path/to/script.pl"

и перезапустить сервис.

Вариант данного скрипта успешно используется на нескольких серверах.

SQL Injection Vulnerability в Z-Vote 1.1

Wandering Soul — Fri, 25 Feb 2011 19:32:49 +0000

Исправление уязвимостей в плагине WordPress Z-Vote 1.1

В плагине WordPress Z-Vote 1.1 была обнаружена уязвимость, позволяющая злоумышленнику выполнять произвольные запросы к базе данных (уязвимость типа «SQL-инъекция»).

Уязвимость существует из-за неправильного использования метода wpdb::prepare() и отсутствия проверки и очистки переменной $_GET['zvote'].

Уязвимость позволяет злоумышленнику изменять запросы к базе данных, выполнять произвольные запросы, читать или изменять конфиденциальную информацию.
Вторая уязвимость (незначительная по сравнению с SQL-инъекцией) — раскрытие пути к плагину (path disclosure) при прямом доступе к файлу плагина.

Патч, исправляющий уязвимости в Z-Vote 1.1:

diff -uwdBrN z-vote.orig/zvote.php z-vote/zvote.php
--- z-vote.orig/zvote.php 2011-02-25 21:05:44.000000000 +0200
+++ z-vote/zvote.php 2011-02-25 21:10:46.531798756 +0200
@@ -9,6 +9,8 @@
License: GPL
*/

+ defined('ABSPATH') or die();
+
// --- DEFINITIONS

//define where zvote is installed on the wordpres system. In 99.9% of the case the path below is correct.
@@ -271,7 +273,7 @@
function zVote_getEntry($postid) {
global $wpdb;

- $entries = $wpdb->get_results($wpdb->prepare("SELECT * FROM " . $wpdb->prefix . "zvotedata WHERE postid = " . $postid . ""));
+ $entries = $wpdb->get_results($wpdb->prepare("SELECT * FROM " . $wpdb->prefix . "zvotedata WHERE postid = %d", $postid));

return $entries;
}
@@ -282,7 +284,7 @@
global $wpdb;

$votes = 0;
- $votes = $wpdb->get_var($wpdb->prepare("SELECT COUNT(*) FROM " . $wpdb->prefix . "zvotedata WHERE postid = " . $postid . ""));
+ $votes = $wpdb->get_var($wpdb->prepare("SELECT COUNT(*) FROM " . $wpdb->prefix . "zvotedata WHERE postid = %d", $postid));

return $votes;
}
@@ -292,7 +294,7 @@

global $wpdb;

- $votes = $wpdb->get_var($wpdb->prepare("DELETE FROM " . $wpdb->prefix . "zvotedata WHERE postid = " . $postid . ""));
+ $votes = $wpdb->get_var($wpdb->prepare("DELETE FROM " . $wpdb->prefix . "zvotedata WHERE postid = %d", $postid));

return $votes;
}
@@ -353,7 +355,7 @@
global $wpdb;

//ipcheck for now, will expand to userid-check, based on the user setting in version 1.5
- $ipcheck = $wpdb->get_var($wpdb->prepare("SELECT id FROM " . $wpdb->prefix . "zvotedata WHERE postid = " . $postid . " AND userip = \"" . $_SERVER['REMOTE_ADDR'] . "\""));
+ $ipcheck = $wpdb->get_var($wpdb->prepare("SELECT id FROM " . $wpdb->prefix . "zvotedata WHERE postid = %d AND userip = %s", $postid, $_SERVER['REMOTE_ADDR']));

$wpdb->insert( $wpdb->prefix . 'zvotedata', array( 'postid' => $postid, 'userip' => $_SERVER['REMOTE_ADDR'], 'userid' => 0, 'time' => time() ), array( '%d','%s', '%d', '%d' ) );

@@ -365,7 +367,7 @@
global $wpdb, $wp_query, $redirect_meta_key;

//ipcheck for now, will expand to userid-check, based on the user setting in version 1.5
- $ipcheck = $wpdb->get_var($wpdb->prepare("SELECT id FROM " . $wpdb->prefix . "zvotedata WHERE postid = " . $postid . " AND userip = \"" . $_SERVER['REMOTE_ADDR'] . "\""));
+ $ipcheck = $wpdb->get_var($wpdb->prepare("SELECT id FROM " . $wpdb->prefix . "zvotedata WHERE postid = %d AND userip = %d", $postid, $_SERVER['REMOTE_ADDR']));

if (!$ipcheck) {
//ok to vote, register vote
@@ -382,7 +384,7 @@
}

//send user to post
- header('Location: ' .$injectionPoint);
+ wp_redirect($injectionPoint);
exit;
} else {
//user already registered, push to entry-page and inform the user.
@@ -394,7 +396,7 @@
$injectionPoint = $post . '?zvoters=2';
}

- header('Location: ' .$injectionPoint);
+ wp_redirect($injectionPoint);
exit;
}
exit;

Межсайтовый скриптинг в плагине Accept Signups 0.1

Vladimir — Wed, 09 Feb 2011 04:10:34 +0000

Исправление OSVDB-70101 для плагина Accept Signups

В плагине Accept Signups 1.0 обнаружена уязвимость, позволяющая провести удалённому пользователю XSS-атаку.

Уязвимость связана с отсутствием обработки входных данных в параметре email, передаваемом файлу wp-content/plugins/accept-signups/accept-signups_submit.php, а также с отсутствием экранирования специальных символов при выводе данных в wp-content/plugins/accept-signups/accept-signups.php.

Уязвимость позволяет при помощи специально сформированного URL выполнить произвольный код сценария в браузере жертвы в контексте безопасности уязвимого сайта.

Патч для плагина Accept Signups 0.1:

diff -uwdBrN accept-signups.orig/accept-signups.php accept-signups/accept-signups.php
--- accept-signups.orig/accept-signups.php 2010-12-21 11:07:21.000000000 +0200
+++ accept-signups/accept-signups.php 2011-02-09 06:06:33.612991546 +0200
@@ -223,7 +223,7 @@
$r = $wpdb->get_results($sql, ARRAY_A);
$xml = '';
foreach($r as $k=>$v) {
- $xml .= '["email"] . '" ip="' . $v["ip"] . '" timestamp="' . $v["timestamp"] . '" />';
+ $xml .= '($v["email"]) . '" ip="' . $v["ip"] . '" timestamp="' . $v["timestamp"] . '" />';
}
$xml .= '';
file_put_contents(ABSPATH . 'wp-content/plugins/accept-signups/accept-signups.xml', $xml);
@@ -290,7 +290,7 @@
if (strpos($v1, '@')) {
$email = $v1;
}
- $html .= ' ' . $v1 . ' ';
+ $html .= ' ' . esc_html($v1) . ' ';
}
$html .= '($email) . '" id="acceptSignupsDeleteCB">';
$html .= '';
diff -uwdBrN accept-signups.orig/accept-signups_submit.php accept-signups/accept-signups_submit.php
--- accept-signups.orig/accept-signups_submit.php 2010-12-21 11:07:21.000000000 +0200
+++ accept-signups/accept-signups_submit.php 2011-02-09 06:03:04.017742924 +0200
@@ -1,6 +1,5 @@
-require_once('../../../wp-config.php');
-require_once('../../../wp-includes/wp-db.php');
+require_once('../../../wp-load.php');

if (true) {
if (isset($_GET['email'])) {
@@ -9,6 +8,16 @@
if (hasEmail($_GET['email'])) {
echo get_option('accept-signups-email-already-exists');
} else {
+ $email = stripslashes($_GET['email']);
+ if (function_exists('filter_var')) {
+ if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
+ die('-1');
+ }
+ }
+ elseif (!preg_match('/^([a-z0-9_\-\.])+\@([a-z0-9_\-\.])+\.([a-z]{2,4})$/i', $email)) {
+ die('-1');
+ }
+
saveEmail($_GET['email']);
echo get_option('accept-signups-email-saved');
}

Помимо OSVDB-70101, данный патч исправляет еще пару мелких недочётов.

Межсайтовый скриптинг в WordPress BezahlCode-Generator 1.0

Vladimir — Wed, 09 Feb 2011 03:13:15 +0000

Патч для BezahlCode-Generator, исправляющий уязвимость

В плагине BezahlCode-Generator 1.0 обнаружена уязвимость, позволяющая провести удалённому пользователю XSS-атаку. Уязвимость связана с отсутствием обработки входных данных в параметрах gen_name, gen_account, gen_BNC, gen_amount, gen_reason в bezahlcode-generator/der_generator.php.

Удаленный пользователь может с помощью специально сформированного запроса выполнить произвольный код сценария в браузере жертвы в контексте безопасности уязвимого сайта.

Патч для BezahlCode-Generator 1.0:

--- der_generator.orig.php 2011-02-09 04:52:27.000000000 +0200
+++ der_generator.php 2011-02-09 05:00:20.457537559 +0200
@@ -16,15 +16,15 @@
($_REQUEST['gen_type']=="singlepaymentspende") echo 'checked="checked"'?>/> Spendenzahlung

($_REQUEST['gen_type']=="singledirectdebit") echo 'checked="checked"'?>/> Lastschrift

-Name:
(this, 'dtaus')" name="gen_name" maxlength="27" value="($_REQUEST['gen_name'])?$_REQUEST['gen_name']:""?>">
+Name:
(this, 'dtaus')" name="gen_name" maxlength="27" value="($_REQUEST['gen_name'])?esc_attr($_REQUEST['gen_name']):""?>">

-Kontonummer:
1234" id="gen_account" onblur="checkInput(this, 'ganzzahl')" name="gen_account" value="($_REQUEST['gen_account'])?$_REQUEST['gen_account']:""?>" >
+Kontonummer:
1234" id="gen_account" onblur="checkInput(this, 'ganzzahl')" name="gen_account" value="($_REQUEST['gen_account'])?esc_attr($_REQUEST['gen_account']):""?>" >

-BLZ:
1234" id="gen_BNC" onblur="checkInput(this, 'ganzzahl')" name="gen_BNC" value="($_REQUEST['gen_BNC'])?$_REQUEST['gen_BNC']:""?>" >
+BLZ:
1234" id="gen_BNC" onblur="checkInput(this, 'ganzzahl')" name="gen_BNC" value="($_REQUEST['gen_BNC'])?esc_attr($_REQUEST['gen_BNC']):""?>" >

-Betrag in Euro (z.B. 1234,50)
1234,50" onblur="checkInput(this, 'dezimalzahl')" id="gen_amount" name="gen_amount" value="($_REQUEST['gen_amount'])?$_REQUEST['gen_amount']:""?>" >
+Betrag in Euro (z.B. 1234,50)
1234,50" onblur="checkInput(this, 'dezimalzahl')" id="gen_amount" name="gen_amount" value="($_REQUEST['gen_amount'])?esc_attr($_REQUEST['gen_amount']):""?>" >

-Verwendungszweck:
(this, 'dtaus')" name="gen_reason" maxlength="54" value="($_REQUEST['gen_reason'])?$_REQUEST['gen_reason']:""?>" >
+Verwendungszweck:
(this, 'dtaus')" name="gen_reason" maxlength="54" value="($_REQUEST['gen_reason'])?esc_attr($_REQUEST['gen_reason']):""?>" >

Заголовки HTTP для обеспечения безопасности сайта

Wandering Soul — Mon, 03 Jan 2011 12:28:06 +0000

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

Безопасность сайта — это бесконечная битва между веб-мастерами и хакерами. В зарегистрировано около 40,000 сайтов, подверженных атакам XSS. XSS-атаки позволяют злоумышленникам красть cookie, личную информацию, взламывать аккаунты и многие другие вещи.

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

В данной статье будет показан один из вариантов защиты — основанный на использовании заголовков HTTP.

Современные браузеры сами предоставляют довольно мощную защиту для своих пользователей… Единственное «но» — сайт должен попросить браузер включить эту защиту. К счастью, это довольно просто.

Для Apache:

# Запретить всем сайтам загружать страницу через /
Header set X-Frame-Options DENY

# Разрешить выполнение JavaScript, загруженного только с нашего домена.
# Не выполнять встроенный (inline) JavaScript
Header set X-Content-Security-Policy "allow 'self';"

# Включение предотвращения XSS-атак в IE 8
Header set X-XSS-Protection "1; mode=block"

Для nginx:

add_header X-Frame-Options DENY;
add_header X-Content-Security-Policy "allow 'self';";
add_header X-XSS-Protection "1; mode=block";

X-Frame-Options

Данный заголовок указывает браузеру, можно ли загружать страницы сайта через <frame>/<iframe>.

Значение DENY запретит загрузку через фреймы, значение SAMEORIGIN разрешит загрузку через фреймы, но только если и фрейм, и страница, его загружающая, находятся на одном домене (Same Origin Policy).

основная функция данной защиты — предотвращение кликджекинга; в качестве дополнительного бонуса это позволит предотвратить атаку, описанную Ben Schmidt.

Заголовок воспринимается Internet Explorer 8.0+, Firefox 3.6.9+ (Gecko 1.9.2.9+), Opera 10.50+, Safari 4.0+, Chrome 4.1.249.1042+.

Подробное описание приведено здесь.

X-Content-Security-Policy

Данный заголовок указывает, как контент на сайте взаимодействует с самим сайтом. При помощи данного заголовка можно указывать, откуда можно загружать картинки, JavaScript, фреймы, шрифты, объекты, таблицы стилей, медиаконтент и многое другое.

Приведённый в примере выше заголовок разрешает загрузку контента только с того же домена, на котором располагается загружаемая страница. При этом браузеру запрещается выполнение встроенного JavaScript (скрипты внутри блоков <script>…</script>, обработчики событий и т.п.), создание кода из строк (например, через функцию eval(), а также передача строк в функции setTimeout(), setInterval() и т.п.), использование протокола data:.

Данный заголовок можно использовать на HTTPS-страницах для запрета загрузки небезопасного контента:

X-Content-Security-Policy: allow https://*:443

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

X-XSS-Protection

Данный заголовок работает исключительно в Internet Explorer: он включает встроенную в браузер защиту от XSS-атак (по умолчанию она отключена, так как может некорректно работать с некоторыми сайтами). Подробная информация о принципах работы защиты от XSS-атак в IE приведена в The Windows Internet Explorer Weblog.

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

Оригинал статьи.

Не удивительно, что DreamHost ломают

Vladimir — Tue, 07 Dec 2010 04:01:14 +0000

Security by Obscurity себя не всегда оправдывает

Сегодня мне довелось поработать на одном из серверов DreamHost. На сервер был shell, что приятно облегчило работу. В свете последних событий с массовым взломом серверов было интересно посмотреть, как у них обстоят дела с безопасностью.

Далее по тексту все имена/названия/группы изменены!

Задача поставлена простая: установить, можно ли залезть в домашний каталог другого пользователя.

Начинаем с простого:

[server]$ ls -la /home
ls: cannot open directory /home: Permission denied
[server]$ whoami
user1
[server]$ groups user1
g5628
[server]$ ls -lhad ~
drwxr-x--x 8 user1 g5628 4.0K 2010-12-06 18:00 /home/user1

Что мы видим:

домашние каталоги других пользователей хостинга скрыты (на каталоге /home установлены права 0711);
домашние каталоги открыты на чтение другим пользователям, входящим в ту же группу.

Что нам нужно:

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

Первое решается довольно просто: cat /etc/passwd

Второе тоже элементарно:

awk "FS=\":\" { if ( \$4 == `id -g`) { print \$1, \$6 } }" /etc/passwd

Со вторым не особо повезло — пользователю user1 не довелось попасть в другие группы, хотя там есть группы, в которые входит много пользователей:

[server]$ awk 'FS=":" {print $4}' /etc/passwd | sort | uniq -c | sort -n -r | head
84 626950
73 627297
66 20591
24 627651
24 20432
22 79268
20 211919
19 221497
16 626722
13 627359

Переходим к третьему пункту:

[server]$ cat /etc/passwd | awk 'FS=":" { print $6 }' | xargs ls -lhad | grep 'r-x ' | wc -l
365

Таким образом, взломав один аккаунт, мы можем попробовать скомпрометировать еще 365 — если в каталоге пользователя есть файл/каталог, доступный всем на запись, аккаунт может быть скомпрометирован. Ну разве они не лапочки после этого?

Но это еще не всё: эти 365 пользователей могут входить в совершенно разные группы, что открывает нам путь к другим аккаунтам:

for i in `cat /etc/passwd | awk 'FS=":" { print $6 }' | xargs ls -lhad |awk '/r-x / { print $3 }' | sort | uniq | xargs`; do id -G $i | sed 's/ /\n/g'; done | sort | uniq | wc -l

Оказалось, что пользователи (уникальных имён оказалось 354) входят в 174 группы.

А дальше дело техники:

G=`for i in `cat /etc/passwd | awk 'FS=":" { print $6 }' | xargs ls -lhad |awk '/r-x / { print $3 }' | sort | uniq | xargs`; do id -G $i | sed 's/ /\n/g'; done | sort | uniq | wc -l`
for i in $G; do echo -n "$i `id -G $i` "; grep :`id -G $i`: /etc/passwd | wc -l; done

Такие вот пироги.

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

ICS Security Fixes: исправление уязвимостей в прошлых версиях WordPress

Vladimir — Thu, 02 Dec 2010 14:10:06 +0000

Попытка сделать старые версии WordPress безопаснее.

Многие блоггеры не торопятся с обновлением WordPress, особенно когда дело касается новых релизов WordPress: по традиции, каждый новый релиз потребляет больше памяти, чем предыдущий, создаёт бóльшую нагрузку на базу и содержит новые, мало кому нужные функции А еще говорят, что нельзя обновляться до версии x.y.0, нужно обязательно ждать x.y.1

Что же, доля истины во всём этом есть, но есть и одно большое НО: все эти обновления, включая новые релизы, обычно содержат важные исправления безопасности, причём иногда разработчики об этом могут не догадываться.

К сожалению, разработчики не делают бэкпорты исправлений в старые ветки, и те, кто по тем или иным соображениям остаётся на старом WordPress, остаются уязвимыми.

Вчера судьба меня свела с человеком с ником M4g, обладающим отменными знаниями уязвимостей WordPress самых различных версий. Он любезно предоставил ссылки на свои статьи, касающиеся уязвимостей WordPress. Своё профессиональное знакомство с WordPress я начинал с версии 2.5, поэтому в статьях обнаружил достаточно много откровений для себя. Но дело не в этом. От прочитанного в голову пришла мысль написать плагин, максимально совместимый с предыдущими версиями WordPress, который бы пытался исправить известные уязвимости, не заставляя пользователя при этом обновлять WordPress.

Естественно, что таким образом можно исправить далеко не всё (например, уязвимость в Snoopy на FreeBSD так не исправить), но отфильтровать параметры запросов или запросы к базе данных вполне реально (хотя тоже не всегда).

Так родился плагин ICS Security Fixes.

Версия 0.1 содержит следующие исправления:

отключение whitelisting’а для трэкбэков/пингбэков (то, что было сделано в 3.0.2 и тянется с 1.x);
попытка борьбы с SQL truncation attack при регистрации пользователя;
исправления, призванные не допустить SQL injection attack при обработке трэкбэков;
исправление CVE-2008-4769;
Old slug redirect bug fix;
Попытка исправления ошибки cURL, связанной с перенаправлением на URI с протоколами file:// и scp:// (трудно сказать про работоспособность, ибо такой древний cURL найти трудно);
Исправление SQL injection в wp_insert_attachment();
Тупой способ для борьбы с подменой фидов;
Защита от атаки на генератор псевдослучайных чисел (надеюсь, что получилось — сгенерировать 80-гигабайтные радужные таблицы нет возможности);
Попытка защиты от 2.7.x/2.8.x admin remote code execution exploit;
Исправление Wordpress 2.5 Cookie Integrity Protection Vulnerability;
Исправление ошибки со сбросом пароля в 2.5.1.

Версия 0.2:

Исправление ошибок, связанных с активацией плагина;
Установка версии по умолчанию для скриптов и таблиц стилей в 0.0.

Версия 0.3:

Исправление ошибок в предыдущих версиях (спасибо Сергею Бирюкову за патч);
Сокрытие версий используемых таблиц стилей и скриптов (удаление параметра ver из строки запроса; кстати, Google рекомендует не использовать строку запроса в URL статических ресурсов);
Частично закрыта уязвимость SA23621 — пользователь получает одно и то же сообщение об ошибке и при неверном имени пользователя, и при неверном пароле. Тем не менее, проверка существования пользователя возможна путём использования функции напоминания пароля;
По многочисленным просьбам добавлено сокрытие версии плагина All in One SEO Pack.

Версия 0.4:

Закрытие уязвимостей, исправленных в WordPress 3.0.5 (r17393, r17387, r17400, r17406).

Хочу выразить большую благодарность Сергею Бирюкову за тестирование и патч, исправляющий ошибки. Спасибо!

Дальнейшее направление работы:

Бэкпортирование патчей уязвимостей для серии 3.x;
Бэкпортирование патчей и закрытие незакрытых уязвимостей для серии 2.x.

У кого есть ссылки на рабочие эксплойты для WordPress любых версий и кто может ими поделиться, а также те, кто готов помочь с тестированием — you are welcome!

Скачать последнюю версию ICS Security Fixes

Внимание: перед обновлением плагин должен быть деактивирован, после обновления — активирован. Это связано с некоторыми неприятными особенностями WordPress 3.1, а также тем, что для некоторых версий WordPress подменяются функции проверки cookies.

UPDATE Feb 15, 2010:
Страница плагина теперь живёт здесь: http://blog.sjinks.pro/wordpress-plugins/ics-security-fixes/
Страница плагина на wordpress.org: http://wordpress.org/extend/plugins/ics-security-fixes/