Скрытые директории и файлы как источник чувствительной информации о веб-приложении


Источник: https://medium.com/@_bl4de/hidden-directories-and-files-as-a-source-of-sensitive-information-about-web-application-84e5c534e5ad

Скрытые директории и файлы, случайно оставленные на веб-сервере, могут стать очень ценным источником чувствительной информации. В корневой папке веб-приложения может быть множество скрытой информации: файлы и папки системы управления версиями исходного кода (.git, .gitignore, .svn), конфигурационные файлы проекта (.npmrc, package.json, .htaccess), файлы пользовательских конфигураций с популярными расширениями, такими как config.json, config.yml, config.xml и многое-многое другое.

В целом, эти источники могут быть разделены на несколько общих категорий:

  • Системы управлениями версиями исходного кода
  • Конфигурационные файлы проекта, которые создаёт IDE (интегрированная среда разработки — обычно, это редактор исходного кода с расширенными функциями)
  • Специфичные конфигурационные файлы и файлы настроек для данного проекта или технологии

Давайте взглянем на них более внимательно — где их искать и какого рода информацию ожидать от них.

Системы управления исходным кодом

Git

Git это «бесплатная и с открытым исходным кодом распределённая система контроля версий, созданная для быстрой и эффективной работы с любыми проектами от маленьких до очень больших». С GitHub.com это сейчас одна из самых популярных систем контроля версия кода, особенно в мире открытого исходного кода. Также многие компании используют их собственные установки GitLab, а также GitHub Enterprise или Bitbucket.

Базовая информацию о Git проектах

Только что созданный Git репозиторий содержит несколько стандартных папок и файлов, где храниться вся информация. Это пример папки .git в которую уже был сделан один commit (этим словом называют любое изменение в проекте, например, изменение исходного кода какого-либо файла, создание нового файла, удаление строк из файлов или файла полностью и прочее).

Базовая структура папки .git:

Давайте взглянем на это с точки зрения атакующего. Содержимое репозитория Git записано в объекты. Все они хранятся в папке .git/objects.

Объекты могут быть одного из трёх типов: commit, tree и blob.

Commit — это информация о коммитах с текущим Tree (деревом, то есть структурой папок и файлов) хешей объектов.

Tree (дерево) содержит информацию о структуре папок и файлов — и каждая папка или файл имеет свой собственный хеш объект, хранимый в объекте дерева. Это может быть другое дерево (папки которые на один уровень ниже в структуре папок) или файл.

Blob — это тип объекта Git, где храниться содержимое файлов. Если вы знаете хеш определённого файла, вы можете прочитать его содержимого используя команду git cat-file.

Если вы нашли папку .git на веб-сервере, тогда есть простой способ получить содержимое любого файла из неё, просто загружая и читая объекты Git. Иногда, если вам повезло, вы можете попробовать клонировать репозиторий, используя стандартную команду git clone или просто запустим команду wget с установленной опцией -r для рекурсивной загрузки всей папки .git. Но это не всегда возможно по нескольким причинам (такие как отсутствие требуемых учётных данных или отсутствие команды wget). Давайте предположим, что все эти опции невозможны.

Чтобы убедиться, что папка .git доступна, просто проверьте, получите ли вы ответ HTTP 403 (или что-то похожее, гавное чтобы это не был код ответа 404, поскольку он означает, что на этом сервере или в этом расположении нет папки .git):

Ответ 403 говорит о существовании папки .git на этом сервере:

Создание зеркала удалённых файлов и папок используя локальный Git репозиторий

Чтобы это можно было делать, вы должны создать ваш собственный, локальный «заготовочный» репозиторий .git со скелетом структуры папок и загрузить объекты Git с удалённого сервереа.

Начинаем с создания папки-заготовки Git:

git init

Это инициализирует пустой репозиторий Git со всеми необходимыми файлами и папками.


Получение и чтение информации об объектах

Для получения информации из репозитория Git, в начале мы должны найти стартовую точку. Git сохраняет всю информацию в файле журнала и этот файл доступен по пути .git/logs/head

Пример содержимого файла .git/logs/head:

Если .git/logs/head не рабобтает, но .git возвращает Forbidden 403, что означает, что он там, попробуйте вместо этого .git/logs/HEAD.

Давайте взглянем немного ближе на пример строки из этого файла:

0000000000000000000000000000000000000000 07603070376d63d911f608120eb4b5489b507692 
bloorq@gmail.com <bloorq@gmail.com> 1452195279 +0000	commit (initial): index.php initial commit

Первые две строки являются хешами объектов (предыдущий и текущий комит) и это в точности то, что мы ищем. Поскольку это самый первый комит, первый хеш содержит только 0 (очевидно, поскольку нет предыдущего комита), вторая строка содержит информацию о текущем комите.

Вначале мы должны создать верный путь к объекту. Путь содержит: общий путь для всех объектов в этом репозитории, им является .git/objects, за ним следует две части воссозданные из хеша — имя директории (первые два символа хеша) и имя файла (оставшаяся часть хеша, начинающаяся с третьего символа). Поэтому для получения объекта, идентифицируемого хешем 07603070376d63d911f608120eb4b5489b507692, нам следует попытаться открыть следующий url: localhost/testapp/.git/objects/07/603070376d63d911f608120eb4b5489b507692

Вот то, что нам нужно — всплывающее окно загрузки файла:

Помните, вы должны сохранить этот файл в вашу созданную ранее заготовочную папку Git — это самый простой способ читать содержимое объектов Git, поскольку по умолчанию ваш git (программа) будет искать их там. Убедитесь, что вы сохранили их в точности в это же самое расположение:

путь-до-вашего-заготовочного-git-репозитория/.git/objects/07/603070376d63d911f608120eb4b5489b507692

Теперь git cat-file должен стать вашим лучшим другом. Для проверки типа объекта, вы можете использовать следующую команду:

git cat-file -t <хеш>

Для отображения содержимого объекта используйте команду:

git cat-file -p <хеш>

Теперь мы можем проверить тип и прочитать содержимое ранее сохранённого объекта (я делаю это в репозитории, созданном на моём localhost, но вы получите тот же самый результат на вашей машине для любого репозитория Git — только будет другой хеш).

Когда вы взглянете на описание комита, вы можете найти информацию о действительном хеше из дерева объектов — как я упоминал ранее, дерево содержит информацию о текущей структуре папок (более точно: структуре папок на момент, когда был сделан комит). Используя этот же метод, что показан выше, просто посмотреть как он выглядит:


Мы очень близко. Как вы можете видеть, там только один файл — index.php, и также мы знаем его хеш объекта и тип, которым является blob. И этот то, что нам нужно для просмотра содержимого файла, используя этот же самый метод, который до этого мы использовали для чтения содержимого комита и объектов дерева (в начале вам нужно сохранить объект с веб-сервера, как описано выше):

Вуаля!

Важно помнить, что содержимое файла index.php показано в том виде, каким оно было когда был сделан комит описанный объектом 07603070376d63d911f608120eb4b5489b507692. Если вы загляните в файл журнала, вы сможете увидеть, что был сделан второй комит (идентифицирован хешем объекта 4db7a14eee2cd3ff529278b75e1653e677fe1d02) и что это последний комит — он содержит все последние изменения — может быть содержимое index.php отличается от того, что мы видели до этого?

Следуем по всем шагам (читаем содержимое комита для поиска хеша дерева, затем читаем дерево для поиска хеша index.php и так далее), мы увидим действительное содержимое index.php:

bl4de on Rafals-MacBook in /Library/WebServer/Documents/testapp $ git cat-file -p a4215057b6545240452087ad4d015bf9b5b817c5
<?php
echo "Hello testapp!";

$i = 100;
echo "Value of i is $i";

bl4de on Rafals-MacBook in /Library/WebServer/Documents/testapp $

Поскольку ручное получение объекта неэффективно и требует много времени, был создан простой консольный инструмент на Python для автоматизации этого процесса. Вы можете взглянуть на него здесь.

Файл .gitignore

Ещё одна вещь о которой стоит упомянуть если мы нашли оставленную на веб-сервере папку .git — файл .gitignore. Цель этого файла простая — это место, куда вы можете добавить имена всех папок и файлов, которые НЕ должны добавляться в репозиторий (но это не означает, что их там нет — это только означает, что они просто не существуют как часть репозитория Git). То есть это самый простой способ найти всё содержимое, которое не должно раскрываться описанным выше способом.

Пример файла .gitignore, раскрывающего существование интересных папок и файлов:

Subversion (SVN)

Subversion (или SVN) — это система контроля исходного кода созданная в Apache Software Foundation и она ещё очень популярна и широко используется, особенно в корпоративной среде с огромной унаследованной кодовой базой.

Структура SVN папок и файлов выглядит примерно как на следующем скриншоте:

С нашей точки зрения самым важным является файл wc.db базы данных SQLite и содержимое директории pristine/. В wc.db мы найдём хеши используемые как имена файлов в pristine/, то есть мы должны начать с этого файла.

Чтобы получить информацию из Subversion нам нужно убедиться, что файл wc.db доступен. Попробуйте открыть следующий путь в вашем веб-браузере:


http://сервер/путь_до_уязвимого_сайта/.svn/wc.db

Если открылось окно скачивания файла, то это означаете что есть шанс, что остальные .svn файлы будут там. Для начала нам нужно прочитать содержимое wc.db для получения информации о хешах файлов (здесь нет директории .logs как была в описанном выше репозитории Git).

Для чтения содержимого wc.db, вы можете использовать консольный клиент SQLite (или любой другой инструмент для управления базами данных SQLite):

sqlite3 wc.db 
SQLite version 3.8.10.2 2015-05-20 18:17:19
Enter ".help" for usage hints.
sqlite> .databases
seq  name             file                                                      
---  ---------------  ----------------------------------------------------------
0    main             /Users/bl4de/hacking/playground/wc.db                     
sqlite> .dump
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE REPOSITORY (   id INTEGER PRIMARY KEY AUTOINCREMENT,   root  TEXT UNIQUE NOT NULL,   uuid  TEXT NOT NULL   );
INSERT INTO "REPOSITORY" VALUES(1,'svn+ssh://192.168.1.4/var/svn-repos/project_wombat','88dcec91-39c3-4b86-8627-702dd82cfa09');

(...)

INSERT INTO "NODES" VALUES(1,'trunk',0,'',1,'trunk',1,'normal',NULL,NULL,'dir',X'2829','infinity',NULL,NULL,1,1456055578790922,'bl4de',NULL,NULL,NULL,NULL);
INSERT INTO "NODES" VALUES(1,'',0,NULL,1,'',1,'normal',NULL,NULL,'dir',X'2829','infinity',NULL,NULL,1,1456055578790922,'bl4de',NULL,NULL,NULL,NULL);
INSERT INTO "NODES" VALUES(1,'trunk/test.txt',0,'trunk',1,'trunk/test.txt',2,'normal',NULL,NULL,'file',X'2829',NULL,'$sha1$945a60e68acc693fcb74abadb588aac1a9135f62',NULL,2,1456056344886288,'bl4de',38,1456056261000000,NULL,NULL);
INSERT INTO "NODES" VALUES(1,'trunk/test2.txt',0,'trunk',1,'trunk/test2.txt',3,'normal',NULL,NULL,'file',NULL,NULL,'$sha1$6f3fb98418f14f293f7ad55e2cc468ba692b23ce',NULL,3,1456056740296578,'bl4de',27,1456056696000000,NULL,NULL);

(...)

Увидели операции INSERT в таблицу NODES? Каждая из них содержит имя файла и SHA1 хеш, который соответствует записи в папке pristine/:

ls -lA pristine/94/
total 8
-rw-r--r--@ 1 bl4de  staff  38 Feb 21 12:05 945a60e68acc693fcb74abadb588aac1a9135f62.svn-base

Для сопоставления значение из NODES и имён файлов нам нужно выполнить несколько шагов:

  • удалить префикс $sha1$
  • добавить постфикс .svn-base
  • использовать первые два знака как имя папки внутри директории pristine/ (в этом случае это 94)
  • создать полный путь, который в этом примере будет:
http://сервер/путь_до_уязвимого_сайта/.svn/pristine/94/945a60e68acc693fcb74abadb588aac1a9135f62.svn-base

Когда мы попытаемся открыть этот путь в браузере, у нас должно получиться скачать файл или его содержимое должно отобразиться непосредственно в браузере. Как прочитать содержимое определённого файла из репозитория .svn:

Также запись в таблице REPOSITORIES указывает на оригинальный путь в репозитории, которым является:

svn+ssh://192.168.1.4/var/svn-repos/project_wombat

Здесь множество информации. Оставление папки .svn на веб-сервере это огромная ошибка и может быть очень опасным. Это может даже означать полную компрометацию исходного кода веб-приложения.

Файлы проектов IDE

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

Вначале давайте взглянем немного ближе на то, что создаёт JetBrains (https://www.jetbrains.com/).

JetBrains IDEs — IntelliJ IDEA, WebStorm, PHPStorm, RubyMine

Каждый разрабатываемый проект в одном из продуктов JetBrains создаёт свою собственную скрытую папку .idea/. Эта директория содержит всю информацию о текущем проекте, его файлах, директориях и настройках IDE.

Пример содержимого папки .idea JetBrains:

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


Рассмотрим, что именно нам раскрывает этот файл:

<?xml version="1.0" encoding="UTF-8"?>
	(...)
	<component name="FileEditorManager">
	    <leaf>
	      <file leaf-file-name="README.md" pinned="false" current-in-tab="false">
	        <entry file="file://$PROJECT_DIR$/README.md">
				(...)
	</component>
(...)

Все узлы в component name="FileEditorManager" содержат все файлы и их относительные пути (в корневой директории проекта). Проще говоря, это просто XML обёртка результатов Bash команды ls выполненной в главной папке проекта 🙂

Если вы взгляните ближе на каждый узел component, вы найдёте информацию об используемой системе контроля версий, как в этом примере:

<component name="Git.Settings">
    <option name="UPDATE_TYPE" value="MERGE" />
    <option name="RECENT_GIT_ROOT_PATH" value="$PROJECT_DIR$" />
</component>

Также там в узле component name="TaskManager" есть информация о комитах и других выполненных задачах над файлами проекта:

(...)
    <task id="LOCAL-00211" summary="change WebSocket port to 1099">
      <created>1436206418000</created>
      <option name="number" value="00211" />
      <option name="project" value="LOCAL" />
      <updated>1436206418000</updated>
    </task>
(...)

Другие интересные вещи могут быть в истории изменений, хранимой в узле с именем component name="ChangeListManager":

<component name="ChangeListManager">
		(...)
		<change type="DELETED" beforePath="$PROJECT_DIR$/chat/node_modules/socket.io/node_modules/socket.io-adapter/node_modules/debug/Makefile" afterPath="" />
		(...)
</component>

а также в узле component name="editorHistoryManager":

(...)
    <entry file="file://$PROJECT_DIR$/public_html/vendor/angular/angular.js">
      <provider selected="true" editor-type-id="text-editor">
        <state vertical-scroll-proportion="0.0">
          <caret line="3233" column="29" selection-start-line="3233" selection-start-column="29" selection-end-line="3233" selection-end-column="29" />
        </state>
      </provider>
    </entry>
(...)

Если разработчик управлял базой данных через интегрированный менеджер БД, то значит есть другой очень интересный файл: dataSources.ids где вы можете найти структуру базы данных, dataSource.xml, dataSources.xml, dataSources.local.xml и dbnavigator.xml содержат примерно такую информацию:

<database>
          <name value="database_name" />
          <description value="" />
          <database-type value="MYSQL" />
          <config-type value="BASIC" />
          <database-version value="5.7" />
          <driver-source value="BUILTIN" />
          <driver-library value="" />
          <driver value="" />
          <host value="localhost" />
          <port value="3306" />
          <database value="mywebapp" />
          <url-type value="DATABASE" />
          <os-authentication value="false" />
          <empty-password value="false" />
          <user value="root" />
          <password value="cm9vdA==" />   <!-- Base64 encoded -->
</database>

или даже больше как файл dataSources.local.xml:

<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
  <component name="dataSourceStorageLocal">
    <data-source name="MySQL - mywebapp@localhost" uuid="8681098b-fc96-4258-8b4f-bfbd00012e2b">
      <secret-storage>master_key</secret-storage>
      <user-name>root</user-name>
      <schema-pattern>mywebapp.*</schema-pattern>
      <default-schemas>mywebapp.*</default-schemas>
    </data-source>
  </component>
</project>

Всё зависит от самого проекта, используемых в IDE плагинов (таких как отладчики, контролёры версий исходного кода или менеджер БД). В общем, стоит оглядеться и исследовать каждый узел component.

Как вы можете видеть, это очень интересный источник информации. Я рекомендую вам загрузить любую JetBrains IDE (они предлагают 30 дневный пробный период почти для всех продуктов, даже больше — вы можете загрузить IntelliJ Idea Community или PyCharm Community и использовать их бесплатно), затем создайте пробный проект, добавьте несколько папок и файлов, попробуйте поуправлять Git или SVN, создайте пример соединения с базой данных, и поиграйтесь с Database Manager. А затем углубитесь в изучение папки .idea/, чтобы увидеть, что вы можете там найти.

NetBeans IDE

NetBeans (https://netbeans.org/) - это другая очень популярная, бесплатная IDE для Java, C/C++, PHP, HTML5 и JavaScript разработки. В настоящее время поддерживается и принадлежит Oracle, NetBeans стала официальной IDE для Java приложений, и при этом она абсолютно бесплатная и с полностью открытым исходным кодом.

NetBeans создаёт свою собственную папку в корневой папке проекта, содержащую все настройки проекта — nbproject/ (наподобии папки .idea, создаваемой JetBrains IDEs).

NetBeans не такая вербальная как IntelliJ, PHPStorm или WebStorm, но вы всё равно можете найти некоторую интересную информацию, которая может оказаться полезной когда вы ищите определённый вектор атаки в отношении уязвимого веб-приложения. Файл project.xml является хорошей стартовой точкой для исследования конфигурации проекта NetBeans.

Пример содержимого директории .nbproject:

Прочие конфигурационные файлы

Конфигурационные файлы специфичные для NodeJS/JavaScript

Если вы когда-либо работали с современными сборками проектов с JavaScript, вероятно вы были удивлены, сколько много разных *.json и .rc* файлов в корневой папке таких приложений.

Имеется множество подобных конфигурационных файлов, содержащих большое количество информации об используемых библиотеках. Некоторые директории недоступны напрямую из браузера или их даже невозможно обнаружить инструментами, используемых для обнаружения (перечисления) скрытых папок и файлов, но некоторые из них встречаются повсюду. Примеры конфигурационных файлов npm (package.json, package-lock.json), которые содержат все зависимости приложения; конфигурационные файлы linters для JavaScript таких менеджеров пакетов как ESlint или JShint или Bower (файл bower.json) — перечислены только некоторые.

Давайте взглянем в пример файла bower.json, который содержит конфигурацию для Bower и содержит список используемых в веб-приложении пакетах (на стороне пользовательского интерфейса):

{
  "name": "testapp",
  "version": "2.1.0",
  "authors": [
    "Rafal 'bl4de' Janicki <email@gmail.com>"
  ],
  "description": "test application",
  "main": "index.html",
  "moduleType": [
    "globals"
  ],
  "license": "MIT",
  "dependencies": {
    "angular": "1.4",
    "pure": "~0.5.0",
    "angular-route": "~1.2.26",
    "angular-ui-router": "~0.2.11",
    "angular-bootstrap-datetimepicker": "latest",
    "angular-translate": "~2.6.1"
  },
  "devDependencies": {}
}

Намного более интересно с точки зрения безопасности это похожий файл для Node.js или io.js серверной части приложения — package.json. Поскольку это список подробностей о сервере — используемые пакеты, такие как коннекторы баз данных, компоненты промежуточного программного обеспечения и так далее — эти файлы могут содержать множество ценной информации о потенциально уязвимом программном обеспечении.

Если вы можете загрузить package.json с сервера, то есть простой метод идентифицировать любой потенциально уязвимый npm пакет, используемый приложением. Просто следуйте этим шагам:

  • убедитесь, что у вас установлен NodeJS с npm версией 6 или выше
  • сохраните загруженный package.json и запустите следующую команду в той же директории, куда вы его только что сохранили:
npm install
  • в конце процесса вы получите информацию вроде такой:
audited 9307 packages in 8.417s
found 9 vulnerabilities (4 low, 1 moderate, 4 high)
  run `npm audit fix` to fix them, or `npm audit` for details
  • теперь запустите команду audit (вероятно, вам в начале необходимо зарегистрировать аккаунт на веб-сайте npmjs.org чтобы получилось сделать этот шаг):
npm audit
  • после выполнения предыдущей команды, у вас будет отчёт, который содержит все уязвимости, идентифицированные этим инструментом:
npm audit
                                                                                
                       === npm audit security report ===                        
                                                                                
# Run  npm install gulp@4.0.0  to resolve 5 vulnerabilities
SEMVER WARNING: Recommended action is a potentially breaking change
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ minimatch                                                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ gulp                                                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ gulp > vinyl-fs > glob-stream > glob > minimatch             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/118                       │
└───────────────┴──────────────────────────────────────────────────────────────┘
(...другие подробности о каждой уязвимости...)

found 9 vulnerabilities (4 low, 1 moderate, 4 high) in 9307 scanned packages
  run `npm audit fix` to fix 1 of them.
  6 vulnerabilities require semver-major dependency updates.
  2 vulnerabilities require manual review. See the full report for details.

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

Этот пример package.json показывает, что вероятно используется база данных MySQL и некоторые коммуникации клиент-сервер через WebSockets:

{
  "name": "Test application server dependencies",
  "version": "1.0.0",
  "author": "bl4de",
  "dependencies": {
    "socket.io": "^1.3.5",
    "mysql": "^2.9.0"
  }
}

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

Также есть файлы вроде .bowerrc, .eslintrc, .jshintrc и похожие. Даже если они не содержат очень чувствительную информацию, всегда есть шанс, что вы можете найти подробности об архитектуре веб-приложения, используемых библиотеках и/или платформах, или даже какую-нибудь ценную информацию в комментариях. Всегда стоит заглянуть в них, если вы нашли их во время фазы разведки.

Конфигурационные файлы GitLab CI/CD .gitlab-ci.yml

Когда проект использует GitLab Continous Integration (GitLab CI/CD), то в корневой папке проекта существует один очень специальный, недолговечный файл: .gitlab-ci.yml. Этот файл может содержать тонны чувствительной информации: подробности о тестировании и процессе сборки с подробными командами запуска на каждом шагу таких процессов и многую другую критическую информацию.

Вы можете найти пример файла .gitlab-ci.yml здесь.

Файл Ruby on Rails database.yml

Если вы достаточно удачливы и этот файл будет для вас читаемым, то это обычно означает «конец игры» для приложения RoR (Ruby on Rails). Это конфигурационный файл главной базы данных, содержащей всё что вам нужно для подключения к базе данных: имена пользователей, пароли и другие подробности настройки.

Файл macOS .DS_Store

Одна специфичная вещь в macOS системах — это файл с названием .DS_Store. Этот файл создаёт Finder (файловый менеджер) в macOS и он очень часто добавляется в проект по ошибке и попадает в репозиторий контроля версий исходного кода.

Что делает .DS_Store файлы такими полезными — это факт, что они хранят информацию о настройках окна Finder, включая макет иконок, представляющих файлы и папки, отображающиеся в конкретном окне Finder. А это в свою очередь означает, что мы также знаем имена файлов и папок в этом окне. Если вы нашли файл(ы) .DS_Store на веб-сервере, то есть шанс, что они раскроют эту информацию для вас и позволят «перечислить» ресурсы, которые вы не смогли бы найти другим путём (например, используя инструменты поиска скрытых файлов и папок). Убедитесь, что ваши словари, которые вы используете с Dirb, Dirbuster, wfuzz или любыми другими инструментами, содержат .DS_Store в качестве искомого файла.

Пример файла .DS_Store. Мы можем идентифицировать файлы config, LICENCE, loader и package.json, а также папки node_modules/, pages/ , utils/ и wrappers/ - типичная структура приложения NodeJS:

Главная проблема файлов .DS_Store в том, что они используют специфичный формат Apple и их нелегко прочитать, хотя можно найти некоторые онлайн инструменты парсинга. Одним из лучших источников, описывающим этот формат (а также Python библиотека для парсинга) — это Parsing the .DS_Store file format от Sebastian Neef. Подробности вы найдёте в статье Утечка имён файлов в .DS_Store: как просмотреть содержимое и как эксплуатировать.

Ищите скрытые папки и файлы в ваших любимых инструментах с готовыми для использования словарями

Один из самых простых способов обнаружить скрытые папки и файлы — это использовать инструменты перечисления (DirBuster, Dirb, wfuzz — и многие другие) со словарями, содержащими сотни тысяч имён самых популярных папок и файлов. Загляните в файл robots.txt, другие популярные места и т. д. Некоторое время назад автор этой статьи (bl4de) собрал такой словарь из нескольких найденных онлайн (например здесь https://github.com/danielmiessler/SecLists или здесь: https://github.com/danielmiessler/RobotsDisallowed — почёт Daniel Miessler за поддержку этих двух шикарных репозиториев!) и добавил парочку собственных записей.

В настоящее время этот словарь содержит ~80k записей, и он очень эффективен, когда используется в отношении типичного публично доступного веб-сервера. Вы можете скачать его и сами попробовать с инструментом по вашему выбору.

Заключение

Всегда стоит проверить, существуют ли на веб-сервере какие-либо из описанных в этом посте папок. Обнаруженный Git или SVN репозиторий это просто катастрофа, так как за этим последует загрузка исходного кода веб-приложения. Также как и найденные конфигурационные файлы проекта IntelliJ IDE приведут к этому же. Иногда вам не нужно ничего кроме единственной «подсказки» от такого источника чтобы «сломать» веб-приложение целиком (вместе с самим веб-сервером).


Рекомендуется Вам:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *