 |
|
|
|
Человеческий фактор как основа ИТ-безопасности
Человеческий фактор Статья посвящена тому, насколько важным является человеческий фактор в вопросах безопасности ИТ-инфраструктуры предприятия и какие возможности открываются перед злоумышленником, если он получает физический доступ к рядовой рабочей станции предприятия. Российский подход В большинстве случаев, когда разговор заходит о безопасности ИТ-инфраструктуры, мы обсуждаем различные программные или аппаратные решения, предотвращающие проникновение в локальную сеть предприятия или кражу важной бизнес-информации, либо антивирусные продукты, способные надежно защитить наши данные от порчи. Но почему-то частенько забываем о том, что очень значимую часть всей модели безопасности занимает Человек. Во многих курсах Microsoft, рассматривается модель безопасности Defense-in-depth. Это концепция из семи уровней защиты данных. Если соблюдать рекомендуемые на каждом уровне требования, то в итоге мы получаем необходимый для сохранности данных уровень безопасности на предприятии. Посмотрите на схему и обратить внимание на то, какой уровень является базовым для всей концепции (см. рис. 1). Это уровень человеческого фактора. Многие мои слушатели, являющиеся, как правило, системными администраторами и инженерами ИТ-отделов крупных российских компаний, рассказывали, что сегодня человеческому фактору при организации ИТ?безопасности уделяется меньше всего внимания. Меня это не удивляло, но очень расстраивало.
Рисунок 1. Модель безопасности Defense-in-depth В отличие от российского подхода западные компании понимают, что в основе всей безопасности лежит в первую очередь осознание важности корпоративных данных непосредственно работниками компании. Если вы работаете (или работали) в международной компании, то наверняка знаете, как ответственно подходит руководство к сохранности важной корпоративной информации. Если нет, готов рассказать о том, как соблюдаются подобные меры безопасности на примере компании Siemens, с которой мы, MCP-сообщество, дружим достаточно давно. Безопасность, какой она должна быть Когда вы приходите на работу в Siemens, то одним из первых этапов будет общение с инженером по ИТ-безопасности, который предложит вам для ознакомления достаточно объемную документацию, где описаны те основные правила, соблюдение которых в конечном итоге будет способствовать сохранности важной корпоративной информации. Среди прочего запрещается оставлять на рабочем месте любые носители информации, сообщать или передавать кому-либо свои учетные данные, покидать рабочее место без предварительной блокировки ПК, а также оставлять без присмотра свою смарт-карту, с помощью которой осуществляется доступ к корпоративной сети. Причем сотрудников уведомляют о том, что никто и никогда не будет запрашивать у них учетные данные ни по телефону, ни по электронной почте. А в случае возникновения подобных попыток рекомендуется их просто игнорировать. Делается это в целях предотвращения утечки учетных данных в ответ на применение так называемой «социальной инженерии», когда злоумышленник маскируется под сотрудника ИТ-службы компании, представляясь таковым в письме или при телефонном разговоре. Кроме этого, к рабочим станциям предприятия применяются достаточно жесткие политики безопасности, запрещающие запись на рабочие диски компьютера непроверенной либо посторонней информации. Дыра в безопасности? А вот другая история. Она произошла со мной, когда я ездил по приглашению в качестве сертифицированного тренера Microsoft читать курсы по Windows Server 2008 в один из вузов, расположенный в небольшом городке на юге нашей страны. Руководство университета устроило для меня небольшую экскурсию по главному корпусу. Во многих кабинетах административного значения компьютеры на рабочих местах пустовали, и ни один из них не был заблокирован! А что дает нам незаблокированный компьютер? Самое банальное – доступ к корпоративной электронной почте, которую можно прочитать и узнать различную бизнес-информацию в компании. Либо можно скомпрометировать сотрудника или даже целый отдел, произведя вредоносную рассылку заведомо ложных данных с такого компьютера. На мой вопрос руководству, почему компьютеры не заблокированы, я получил недоуменный ответ: «А зачем? У нас подобную рассылку просто никто не примет всерьез». Видимо, руководство учебного заведения до сих пор находится в счастливом неведении о том, к чему может реально привести такая беспечность. Хорошо, если кто-то просто пошутит и разошлет всем по почте анекдот или прикол, а если это будет информация, дискредитирующая человека? Как всегда, в нашей стране все это будет продолжаться до тех пор, «пока гром не грянет». Но просмотр корпоративной электронной почты и рассылка дезинформации – далеко не самое страшное из того, что можно сделать с такого незаблокированного рабочего ПК. Очень часто случается, что на простые рабочие станции заходит пользователь с правами доменного администратора, что делать крайне не рекомендуется, поскольку, даже если такой пользователь заблокировал компьютер, хэш его учетных данных сохраняется в определенной области памяти, и с помощью специальных утилит его можно подменить. Дыра в безопасности! Хочу продемонстрировать вам, каким образом легко и просто можно получить доступ к Active Directory и создать пользователя с правами доменного администратора, имея в наличии всего лишь такой вот незаблокированный компьютер, имеющий учетную запись в домене предприятия. Причем среднее время, которое необходимо будет затратить на данную операцию, составит около 15 минут! Конечно, нужно учитывать тот факт, что делать это будет подготовленный специалист, цель которого – внедриться в домен предприятия. В других случаях необходимое время может варьироваться. Итак, что нам дано в исходном состоянии? Системный администратор (назовем его Пояра), который вошел на клиентскую рабочую станцию с правами доменного администратора, поработал какое-то время и ушел в курилку на 15 минут, заблокировав компьютер. Злоумышленник (назовем его Роба), который проник в здание компании «Х» и нашел там любой незаблокированный компьютер, имеющий учетную запись в домене компании «Х». Кроме этого, он знает доменное имя рабочей станции, на которой регулярно работает Пояра. Узнать это для злоумышленника тоже не проблема: методы «социальной инженерии» прекрасно действуют до сих пор. И, конечно же, настоящий хакер должен иметь при себе набор «отмычек» – специальных инструментов, которые помогут ему стать доменным администратором. В случае Пояры это:
Итак, Роба получил физический доступ к рабочей станции в домене. Для начала ему необходимо запустить Ophcrack, чтобы извлечь хэш пароля локального администратора (см. рис. 2). Этот хэш нам еще понадобится, поэтому Роба записывает его на клочке бумаги. Затем он сбрасывает пароль локального администратора с помощью диска для сброса паролей (см. рис. 3) и входит на рабочую станцию с административными правами. Роба знает о том, что доменный администратор Пояра ушел в курилку и заблокировал компьютер, но это не проблема, поскольку хэш учетных данных доменного администратора также хранится на удаленной рабочей станции. Чтобы этот хэш узнать, нашему хакеру нужно только запустить на удаленной машине утилиту whosthere из пакета Pass-the-Hash Toolkit. Но, чтобы запустить эту утилиту удаленно, необходимо сначала скопировать ее на атакуемый компьютер, а для этого опять-таки необходимы права. Причем вполне достаточно прав локального администратора атакуемой рабочей станции.
Рисунок 2. Извлечение хэша пароля локального администратора с помощью Ophcrack
Рисунок 3. Сброс пароля локального администратора с помощью диска для сброса паролей Как же их получить? Не секрет, что во многих компаниях ОС на рабочие станции устанавливается централизованно, например, с сервера WDS, и при установке используется файл ответов, где указывается стандартный пароль локального администратора. Таким образом, на всех рабочих станциях учетная запись локального администратора имеет одинаковый пароль, и все, что нужно для получения прав на удаленной машине, – подменить хэш. Роба запускает утилиту iam (Pass-the-Hash Toolkit), в параметрах которой указывают имя локального администратора и хэш, который он ранее записал на бумажке (см. рис. 4). Данная утилита подменяет в области памяти LSA текущий хэш на указанный, а поскольку на всех рабочих станциях пароль локального администратора одинаковый, то Роба автоматически получает удаленный доступ к диску атакуемого компьютера, и теперь он легко может скопировать туда утилиту whosthere. Дальше Роба использует psexec для удаленного запуска консоли командной строки (cmd), которая запускается на его компьютере локально, и он получает возможность выполнить whosthere на атакуемом компьютере, получая на этот раз хэш учетных данных доменного администратора Пояры (см. рис. 5). Выходим из сессии psexec и еще раз запускаем iam, подставив хэш доменного админа вместо нашего текущего (см. рис. 6).
Рисунок 4. Утилита iam (Pass-the-Hash Toolkit)
Рисунок 5. Хэш учетных данных доменного администратора
Рисунок 6. Подстановка полученного хэша доменного администратора вместо текущего Все! Роба теперь может делать с контроллером домена все что угодно в рамках разрешений доменного администратора! Но у нас задача создать собственного пользователя в домене с правами доменного администратора. Элементарно! Для этого используем команды: net user <имя_нового_пользователя> <пароль_нового_пользователя> /add /domain и такой пользователь будет создан. Фактически за полтора десятка минут при наличии пары дисков и физического доступа к любому доменному компьютеру можно получить огромные привилегии! Разбор полетов А теперь давайте разбираться, почему Робе так легко удалось получить контроль над контроллером домена. И начнем мы именно с человеческого фактора. Как злоумышленник вообще получил физический доступ к рабочей станции? Скорее всего по недосмотру охраны компании «Х», либо ему удалось выведать у сотрудников компании какой-то обходной путь (часто в компаниях есть этакий «бэкдор для своих»). Тут очень показательным будет мультик про бабушку-уборщицу в «ОченьКрутомБанке», который я предлагаю посмотреть тут: http://mults.spb.ru/mults/?id=2041. Как ни печально, но в наше время по-прежнему хорошо работает и способ под названием «я из службы доставки/электрокомпании/почты/водоканала с очень срочной информацией, но забыл свой ключ/прокси-карту». И таким вот образом совершенно посторонний человек получает право войти внутрь. Как Роба узнал доменные имена нужных ему компьютеров? Скорее всего просто втерся в доверие к кому-то из работников. Это тоже достаточно легко сделать, особенно если сотрудники изначально не были проинструктированы о том, что нельзя сообщать никаких сведений об инфраструктуре компании незнакомым лицам. Возможен еще и такой вариант: Роба – бывший сотрудник компании «Х», который за что-то обижен на своих прежних работодателей и хочет просто навредить. И пустили его, что называется, «по старой памяти». Чтобы риск возникновения ситуаций из первых двух пунктов и свести к минимуму, регулярно проводите с сотрудниками тренинги и семинары, посвященные тому, как выявить приемы «социальной инженерии». Объясните им, насколько важно обеспечить безопасность всей инфраструктуры предприятия, а не только учетных данных. Почему злоумышленнику удалось запустить компьютер, используя свои загрузочные диски? Очевидно, по недосмотру сотрудников ИТ-отдела компании «Х». Они не подумали, что неплохо было бы отключить в BIOS возможность загрузки с внешнего USB-носителя или с CD/DVD. К слову сказать, в той же компании Siemens вам не удастся выполнить запуск компьютера с какого-либо постороннего носителя, ибо данная возможность отключена в BIOS, а сам вход туда закрыт паролем. Поверьте, сотрудники ИТ-отдела вам его не раскроют (я сам пытался их уговорить – ни в какую). Как удалось получить доступ к рабочей станции, на которой находились учетные данные доменного администратора? Тут сработали два фактора: во-первых, на всех рабочих станциях компании был установлен одинаковый пароль локального администратора, а во-вторых, сама учетная запись локального админа была включена. Второе в данном случае является более весомым, поскольку если бы она была выключена, то доступ получить бы не удалось. А ведь отключить учетную запись локального админа на уровне всего домена (или отдельного OU) очень легко через групповые политики (для ОС Windows Server 2008 и 2008 R2): Computer Configuration –> Windows Settings –> Security Settings –> Local Policies –> Security Options –> Accounts: Administrator account status –> Disabled (см. рис.7).
Рисунок 7. Отключение записи локального администратора на уровне домена Подмена хэша учетных данных доменного админа удалась, потому что Пояра, когда уходил на перекур, просто заблокировал компьютер, а не выполнил Log Off. Вообще входить интерактивно на рабочую станцию под учетными данными доменного администратора строго не рекомендуется. Лучше использовать функцию временного повышения прав, которую предоставляет UAC (вы ведь его не выключаете, верно?). С помощью консоли MMC, к примеру, можно создать так называемый Admin Launchpad – набор всех необходимых административных инструментов, которые будут запускаться всегда с повышенными правами. Более подробно о том, как создать такую коллекцию инструментов, можно прочитать тут: http://cut.ms/bj7B. *** Помните главное – при планировании модели безопасности ИТ-инфраструктуры вашего предприятия очень важно уделять повышенное внимание именно человеческому фактору. Если у вас есть возможность организовать небольшой тренинг для ваших сотрудников, где их научат выявлять паттерны, характерные для приемов «социальной инженерии», где им объяснят важность сохранности не только учетных данных, но и другой служебной информации об инфраструктуре предприятия, сделайте это. Поверьте, лучше предотвратить ситуацию, при которой вы потеряете конфиденциальные данные, чем затратить огромные средства на их восстановление в дальнейшем. |
НИКИТА ПАНОВ, технический эксперт по решениям Microsoft, Кречет ИТБ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
