May 9, 2023

Что хранят в себе скрытые файлы и папки на веб-сервере? 

Доброго времени суток! Сегодня я хочу рассказать, что содержат в себе скрытые папки и файлы на веб-сервере.

Скрытые файлы и директории, которые оставляют на веб сервере, могут иметь важную, конфиденциальную информацию. Веб-сервер может содержать много скрытой информации.
Такие файлы как:

  • исходные коды версии системных папок и файлов (.git, .gitignore, .svn)
  • файлы конфигурации (.npmrc, package.json, .htaccess)
  • пользовательские файлы конфигурации (.json, .yml, .xml)
  • и многое другое

Эти данные можно поделить на 3 группы:

  1. Файлы конфигурации для IDE (Интегрированная среда разработки)
  2. Исходный код системы контроля версий
  3. Проекты и/или файлы конфигурации и настройки для конкретной технологии

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

Исходный код системы контроля версий

Git

Git «является распределенной системой для управления версиями разрабатываемых файлов»

Недавно созданный Git-репозиторий содержит несколько папок и файлов по умолчанию, в которых хранится вся информация. Вот пример папки .git с уже сделанным комитом:

Все данные хранятся в .git. Эти данные можно поделить на 3 вида: комиты, каталоги файлов либо «Tree», и блобы «Blob»

1. Комит — хранит информацию с текущими хэшами каталогов файлов

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

3. Blob - это объект Git типа, в котором сохраняется содержимое файлов.

Если все же .git папка встретиться на веб сервере, есть легкий путь для получения содержания любого файла — просто скачав и прочив Git объекты. Если повезет, можно скопировать репозиторий используя команду git clone, либо использовать wget с -r опцией. Но иногда все не так просто…

Давайте рассмотрим ситуацию, когда ни один из этих вариантов не выполняется успешно

Что бы убедиться о наличии .git папки на веб сервере, нужно проверить получения HTTP 403 ответа (если 404 — запрашиваемая папка не найдена).

Отражение файлов и папок используя локальную Git репозиторий

Что бы сделать это, стоит создать свою простенькую .git репозиторий с внутренней структурой и скачать Git объекты с веб сервера

Прежде всего, создания репозитория:

$ git init

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

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

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

Если .git/logs/head не работает, но .git возвращает 403, то нужно попробовать .git/logs/HEAD

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

0000000000000000000000000000000000000000 07603070376d63d911f608120eb4b5489b507592 test@gmail.com <test@gmail.com> 1452195279 +0000 commit (initial);

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

Первым делом нужно создать действующий путь к объекту. Путь содержит общий путь ко всем объектам в хранилище, то есть к .git/objects, за которым следуют две части, построенные из хэша - имя каталога (первые два символа хэша) и имя файла (остальная часть хэша, начиная с третьего символа). Таким образом, чтобы получить объект, идентифицированный по хэшу 07603070376d63d911f608120eb4b5489b507592, нужно открыть следующий URL:

localhost/testapp/.git/objects/07/603070376d63d911f608120eb4b5489b507692

И скачивается файл:

Скачанный файл можно увидеть в своей «простой» Git папке:

vasha_prostaya_git_papka/.git/objects/07/603070376d63d911f608120eb4b5489b507692

Команда git cat-gile -t поможет узнать тип объекта:

$ git cat-file -t <хэш>

Что бы отобразить содержание файла, нужно прописать следующую команду:

$ git cat-file -p <хэш>

Теперь можно проверить тип, и прочитать содержание файла, который был сохранен ранее:

При прочтении содержания, можно найти информацию о нынешнем хэше из каталога объектов:

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

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

PHP:

<?php
echo "Hello World!";

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

Так как ручной перебор объектов мучительный и нудный, в сетях можно найти автоматизированные скрипты, вот например - тык

.gitignore файл

Есть так же одна вещь, которую стоит описать, если вы нашли .git папку оставленную на веб-сервере, а именно - .gitgnore. Цель таких файлов проста — это место где можно положить имена всех папок и файлов который не стоит комитеть в репозиторий. По этому это самый легкий путь найти файлы, которые по каким-то причинам не должны быть закомиченны:

Subversion (SVN)

Subversion (или SVN) это система контроли системы создана Apache Software Foundation и эта система остается очень популярной и широко используемой.

Пример структуры SVN папок и файлов:

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

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

http://server/path_to_site/.svn/wc.db

Если выскочило уведомление о загрузке — обозначает, что есть шанс, что остальные .svn файлы будут находиться здесь. Сперва, нужно прочитать содержание wc.db что бы получить информацию о хэшах файлов.

Что бы прочитать wc.db файл, можно воспользоваться 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/test/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 sor staff  38 Feb 31 12:05 945a60e68acc693fcb74abadb588aac1a9135f62.svn-base

Что бы отобразить значения из NODES в имя файла, нужно выполнить несколько команд:

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

http://server/path_to_site/.svn/pristine/94/945a60e68acc693fcb74abadb588aac1a9135f62.svn-base

При открытии ссылки, нужно будет скачать файл или отобразить содержание прямо в файле:

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

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

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

Так же много информации в себе хранят файлы проектов IDE:

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

Например, возьмем приложения JetBrains IDEs : IntelliJ IDEA, WebStorm, PHPStorm, RubyMine

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

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

Давайте рассмотрим, что именно хранит этот файл:

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” содержат все файлы и их пути. Проще говоря — это просто результат команды ls выполненной в основной папке проекта, и завернутой в XML.

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

XML:

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

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

XML:

<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”:

XML:

<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":

XML:

<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>

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

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="gh7sdQ==" />   <!-- Base64 encoded -->
        </database>

Или даже больше, как например файл dataSources.local.xml:

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, далее создать проект и добавить пару папок и файлов, после этого попробуйте управлять Git или SVN. Так же создайте простую базу данных, и управляйте ею при помощи Database Manager. После всего этого, в .idea/ вы найдете очень много интересной информации.

NetBeans IDE
NetBeans другая популярная и бесплатная IDE для JAVA, C/C++, PHP, HTML5 и JavaScript разработки.

NetBeans создает свою собственную скрытую папку в папке проекты, где содержит всю нужную информацию и настройки — nbprosect/ (стоит отметить, что папка имеет схожую функцию со скрытыми папками продукции JetBrains IDEs)

В скрытой папке, вы сможете найти project.xml. Данный файл является отличным стартом для постижения конфигурации NetBeans проекта.

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

Разные файлы конфигурации

Спецификация файлов конфигурации NodeJS/JavaScript

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

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

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

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

JSON:

{
  "name": "testapp",
  "version": "2.1.0",
  "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
  • теперь запустите команду npm аудита:
    $ 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                       │
└───────────────┴──────────────────────────────────────────────────────────────┘

(...more dtails about every vulnerability...)


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:

JSON:

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

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

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

Вывод:

Под плохой защитой, скрытые файлы и папки на веб-сервере дают хакеру много полезной и ценной информации, которую он сможет использовать для атаки на тот же веб-сервер. Поэтому, всегда удаляйте скрытые папки от IDE, Git’a и прочих приложений перед загрузкой проекта на веб-сервер.

Спасибо за внимание!

Наш канал - https://t.me/webhack_kakao