Расшифровка сохранённых паролей в MS SQL Server

https://blog.netspi.com/decrypting-mssql-database-link-server-passwords/
  • Перевод
Давным-давно, в далёкой галактике, пред-предыдущий администратор вашего SQL Server задал в нём linked server, используя специально для этой цели созданный аккаунт со сгенерированным паролем. Теперь вам с этим линком нужно что-то сделать, например перенести его на другой SQL Server; но просто так это не сделать, потому что никто не знает пароля от того аккаунта. Знакомая ситуация?

Хотя MSSQL не хранит пароли для своих аккаунтов, а хранит только их хэши, — с linked server-ами так не получится, потому что для успешной аутентикации перед внешним сервером нужно обладать паролем в открытом виде. Пароли для linked server-ов хранятся в зашифрованном виде в таблице master.sys.syslnklgns:



Но не всё так просто. Во-первых, эта таблица недоступна из обычного SQL-соединения, а доступна только из Dedicated Administrative Connection. На DAC накладываются существенные ограничения: открыть DAC может только пользователь с привилегией sysadmin, и одновременно к одному серверу может быть открыто только одно DAC. Если у вас есть права локального администратора на сервере, но вы не можете войти в MSSQL с правами sysadmin, то есть обходной путь — заходить не из-под своего аккаунта, а из-под аккаунта сервиса MSSQL или даже из-под LocalSystem.

Во-вторых, несмотря на то, что поле с зашифрованным паролем называется pwdhash — это никакой не хэш, а зашифрованные данные. Ключ для расшифровки хранится в системной таблице master.sys.key_encryptions:



Этот ключ хранится в двух экземплярах: первый (thumbprint=0x01) позволяет использование только из-под аккаунта сервиса MSSQL, второй (thumbprint=0x0300000001) — из-под любого аккаунта на сервере. Обратите внимание, что ни один из хранящихся ключей не пригоден для «офлайн-расшифровки» паролей вне сервера, так что если злоумышленнику и удастся украсть данные обеих этих системных таблиц, ему это ничего не даст.

В-третьих, ключ для расшифровки сам зашифрован, и «ключ для ключа» хранится в системном реестре в HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\$InstanceName\Security\Entropy:



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

Для получения всех трёх составляющих и расшифровки сохранённых паролей, автор создал удобный PowerShell-скрипт.

Если запустить его из-под аккаунта локального администратора на сервере, он порадует вас примерно таким окошком:



Если же вы не хотите запускать на production-сервере непонятно кем написанные скрипты, то саму расшифровку можно выполнить и без прав администратора, если сначала вытащить три составляющих при помощи SQL Studio и regedit, и вставить их в скрипт в явном виде. Первый шаг расшифровки ($ServiceKey = [System.Security.Cryptography.ProtectedData]::Unprotect($SmkBytes, $Entropy, 'LocalMachine')) обязан выполняться на сервере, но второй ($Decrypt = $Decryptor.​CreateDecryptor($ServiceKey,​$Logins.iv) и последующая работа с CryptoStream) может выполняться и в офлайне.

Аналогичным образом расшифровываются и credentials, сохранённые в базе для выполнения команд (xp_cmdshell и т.п.) от имени менее привилегированных аккаунтов, нежели сервис MSSQL.

С одной стороны, всё это кажется вопиющим примером security through obscurity: если расшифровка паролей для соединения с linked server-ами уже реализована в MSSQL, то почему нет возможности показать эти пароли забывчивому администратору? С другой стороны, с точки зрения безопасности всё весьма неплохо: для расшифровки паролей нужен доступ к серверу с правами локального администратора, а если злоумышленник получил такой доступ, то он уже и так может делать с сервером всё что захочет. Нежелательное повышение привилегий возможно лишь в том случае, если пароль от какого-нибудь linked server-а используется впридачу для чего-нибудь важного, например как пароль администратора того же сервера :^)
  • +11
  • 7,3k
  • 8
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 8
  • 0
    Не понимаю зачем это переводить. По запросу «decrypt mssql password» в google эта статья с netspi занимает первое место(даже для новичков там описано все более менее понятно). Кто хотел узнать как дешифровать пароли в MSSQL давно уже узнал.
    • +4
      Зачем тогда вообще хоть что-то переводить, если в гугле и так всё есть?
      • +3
        Я вот даже предположить не мог, что оно так сделано и когда мне надо было вспомнить пароль от тестовой БД (я не DBA), пришлось переустанавливать приклад. Я не гуглил, потому что даже не думал, что что-то можно нагуглить. А теперь, благодаря Тёмычу, я знаю, что пароли MSSQL подвержены расшифровке и при необходимости уже залезу в гугл.
        • +1
          Может гугл вам и хабр заменяет? Новенькие интересные статьи на раз-два гуглятся?
        • +3
          ИМХО, решение проблемы, которой нет.
          Системные пароли для синхронизации или линковки баз, как в данном случае, не надо хранить, а тем более восстанавливать.
          Они сбрасываются!
          Да, просто ресет пароля и установка нового.

          А если вы для разных ликов используете один логин/пароль, то становитесь сами себе злобным чебурашкой, т.к. это абсолютно небезопасно.
          • 0
            Можно сбрасывать, можно восстанавливать — в чём преимущество одного перед другим?
            • +2
              Штатная операция инструментами, которые поставляются вместе с софтом или обход с хакингом и сторонними инструментами.

              Обычно в дом заходят через входную дверь, иногда через пожарный/черный ход. А ведь можно и через окно, и даже кому-то удобно…
          • 0
            del

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое