Найгірша безпека, яку ви бачили? [зачинено]

Яка найгірша діра в безпеці, яку ви коли-небудь бачили? Напевно, гарна ідея обмежувати дані, щоб захистити винних.

Для чого це варто, ось питання про те, що робити, якщо ви знайдете дірку в безпеці, та ще один із корисними відповідями, якщо компанія (здається) не відповідає.

З перших днів Інтернет-магазини:

Отримайте знижку на 90%, ввівши .1 у полі кількості кошика. Програмне забезпечення належним чином обчислило загальну вартість як .1 * вартість, а людина, що упаковує замовлення, просто зафіксувала понад непарні "." перед кількістю упакувати :)

Найменш пробачувану дірку в безпеці, і, на жаль, дуже поширену та її легко знайти, - це хакерство Google . Справа в точці:

http://www.google.com/search?q=inurl%3Aselect+inurl%3A%2520+inurl%3Afrom+inurl%3Awhere

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

З незначними налаштуваннями мені вдалося знайти незахищені установки phpMyAdmin, незахищені установки MySQL, рядки запитів, що містять імена користувачів та паролі тощо.

Соціальна інженерія:

<Cthon98> hey, if you type in your pw, it will show as stars
<Cthon98> ********* see!
<AzureDiamond> hunter2
<AzureDiamond> doesnt look like stars to me
<Cthon98> <AzureDiamond> *******
<Cthon98> thats what I see
<AzureDiamond> oh, really?
<Cthon98> Absolutely
<AzureDiamond> you can go hunter2 my hunter2-ing hunter2
<AzureDiamond> haha, does that look funny to you?
<Cthon98> lol, yes. See, when YOU type hunter2, it shows to us as *******
<AzureDiamond> thats neat, I didnt know IRC did that
<Cthon98> yep, no matter how many times you type hunter2, it will show to us as *******
<AzureDiamond> awesome!
<AzureDiamond> wait, how do you know my pw?
<Cthon98> er, I just copy pasted YOUR ******'s and it appears to YOU as hunter2 cause its your pw
<AzureDiamond> oh, ok.

З bash.org

Справжня історія з моїх ранніх днів в Microsoft.

Ви не знали страху до того дня, як прокинетесь і побачите заголовок на ZDNet.com того ранку, як " Найгірший отвір безпеки Internet Explorer коли-небудь виявлено в" Blah ", де" Blah "- код, який ви написали самі півроку раніше .

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

(ОНОВЛЕННЯ: Кілька відповідей на питання, порушені в коментарях:

По-перше, зауважте, що я вирішу зайняти благодійну позицію, що зміни ключа безпеки були ненавмисними та ґрунтувалися на необережності чи незнайомості, а не на злобі. Я не маю жодних доказів так чи інакше, і вважаю, що розумно віднести помилки до помилки людини.

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

У всякому разі, помилка полягала в тому, що об'єкт, який НЕ БЕЗПЕЧНО використовувати для Internet Explorer, випадково був випущений як позначений як "безпечний для сценаріїв". Об'єкт був здатний записувати двійкові файли - бібліотеки типу OLE Automation, насправді - на довільні місця на диску. Це означало, що зловмисник може створити бібліотеку типів, яка містить певні рядки ворожого коду, зберегти його до шляху, який був відомим виконуваним місцем, надати йому розширення чогось, що спричинило б запуск сценарію, і сподіваємось, що якось користувач випадково запустив би код. Я не знаю жодної успішної атаки "реального світу", яка використовувала цю вразливість, але з цим можна було випрацювати робочий подвиг.

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

Я викликав і згодом виправив ще багато дірок у безпеці в JScript, але жоден з них ніколи не дістався поблизу реклами, яку він зробив.

Я сподіваюся, що ви можете помітити, що тут не так. (Страшенно неправильно, насправді):

String emailBody = "";

for (int i = 0; i < subscribers.Count; i++)
{
    emailBody += "Hello " + subscribers[i].FirstName + ",";
    emailBody += "this is a reminder with your account information: \n\n:";
    emailBody += "Your username: " + subscribers[i].Username + "\n";
    emailBody += "Your password: " + subscribers[i].Password + "\n";
    emailBody += "Have a great day!";

    emailDispatcher.Send(subscribers[i].EmailAddress, emailBody);
}

Останній отримувач був найщасливішим;)

У старих німих терміналах IBM System 36 була комбінація клавіатури, яка запускала запис макросу. Отже, коли термінал не був увійшов у систему, ви можете почати запис макросу і залишити його в такому положенні. Наступного разу, коли хтось увійде в систему, натискання клавіш буде записано в макрос, і запис завершиться автоматично, коли було записано максимально дозволені клавіші. Просто поверніться пізніше та відтворіть макрос для автологічного входу.

Найгірша дірка безпеки, яку я коли-небудь бачив, насправді була закодована вашими справді і змусила Google Bot видалити всю мою базу даних.

Ще коли я вивчав класичний ASP, я кодував свою основну програму для блогу. Каталог із усіма сценаріями адміністратора був захищений NTLM на IIS. Одного разу я перейшов на новий сервер і забув знову захистити каталог у IIS (ой).

На домашній сторінці блогу було посилання на головний екран адміністратора, а на головному екрані адміністратора ВИДАЛЕНО ЛІНКА для кожного запису (без підтвердження).

Одного разу я виявив кожен запис у базі даних видалений (сотні особистих записів). Я думав, що якийсь читач увірвався на сайт і зловмисно видалив кожен запис.

Я з'ясував із журналів: Google Bot перескакував сайт, перейшов за посиланням адміністратора та перейшов до УСІЛЬНИХ ПОСИЛАНЬ, тим самим видаляючи кожен запис у базі даних. Я відчув, що заслужив нагороду «Дурман року», коли ненароком зірвався Google Bot.

На щастя, у мене були резервні копії.

Найгірша діра, яку я коли-небудь бачив, - це помилка у веб-додатку, коли введення порожнього імені користувача та пароля дозволить вам увійти як адміністратор :)

Одного разу помітив це в URL-адресі веб-сайту.

http://www.somewebsite.com/mypage.asp?param1=x&param2=y&admin=0

Зміна останнього параметра на admin = 1 надала мені права адміністратора. Якщо ви будете сліпо довіряти вводу користувачів, принаймні не телеграфуйте, що ви це робите!

Це я бачив у The Daily WTF .

<script language="javascript">
<!--//
/*This Script allows people to enter by using a form that asks for a
UserID and Password*/
function pasuser(form) {
    if (form.id.value=="buyers") { 
        if (form.pass.value=="gov1996") {              
            location="http://officers.federalsuppliers.com/agents.html" 
        } else {
            alert("Invalid Password")
        }
    } else {  
        alert("Invalid UserID")
    }
}
//-->
</script>

Ніщо не може перемогти цю ІМХО.

В університеті, який не залишиться безіменним, всі їхні запити щодо дій передавались через URL-адресу замість форми.

Справа працювала, поки Google Bot не прийшов і пробіг усі їхні URL-адреси та не витер їхню базу даних.

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

Короткий зміст: зловмисні користувачі можуть придбати кілька десятків флеш-накопичувачів, завантажити їх вірусом або троянським автозапуском, а потім посипати згадані флешки на парковці компанії пізно вночі. Наступного дня всі з’являються на роботу, натрапляють на блискучу, цукеркоподібну, непереборну техніку та говорять собі "ой уау, безкоштовна флешка, мені цікаво, що на ній!" - Через 20 хвилин всю мережу компанії вводили в шланг.

"Pedo mellon a minno" , "Говори друг і вход ", на воротах Морія.

Microsoft Bob
(Кредит: Занедбане програмне забезпечення 20 століття Дана )

Якщо ви ввели свій пароль неправильно втретє, вас запитають, чи ви забули свій пароль.

http://img132.yfrog.com/img132/8397/msbob10asignin15.gif

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

Попередня автентифікація не потрібна. значить, User1 може змінити свій власний пароль, просто ввівши пароль три рази, потім ввівши новий пароль четвертий раз - ніколи не використовуючи "змінити пароль".

Це також означає, що User1 міг змінити паролі User2, User3 ... точно так само. Будь-який користувач може змінити пароль будь-якого іншого користувача, просто помиливши його тричі, ввівши новий пароль, коли буде запропоновано - і тоді він може отримати доступ до облікового запису.

http://img132.yfrog.com/img132/9851/msbob10asignin16.gif

Я мав колишню домашню адресу Джо X, і мені потрібно було знати його нову поточну адресу в тому ж місті, але не мав можливості зв'язатися з ним. Я подумав, що він отримує звичайну щоденну купу каталогів замовлень поштою, тому я довільно назвав номер 800 для цукерок See (на відміну від Victoria's Secret, або Swiss Colony, або будь-якої іншої великої пошти):

Я: "Привіт, я Джо X. Я думаю, що ти двічі потрапив до мене у своєму списку розсилки, як на моїй старій, так і на моїй новій адресі. Чи показує мені ваш комп'ютер за [старою адресою] або за [фальшивою адресою] ? "

Оператор: "Ні, ми показуємо вам [нову адресу]."

Надавши 1 = 1 у текстовому полі, перераховуються всі користувачі системи.

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

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

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

Якби я міг обрати інше, це були б проблеми канонізації шляху у веб-додатках. Чудово вміти робити foo.com?file=../../../../etc/passwd

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

Потрібно сказати, що пароль змінився дуже швидко.

Не змінюючи паролі адміністратора, коли ключові ІТ-співробітники залишають компанію.

Хоча це не найгірша безпека, яку я бачив. Але це принаймні найгірше, що я виявив сам:

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

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

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

Щоб скоротити довгу історію, він змінив URL-адресу (просто з цікавості) і зрозумів, що перегляд каталогів не вимкнено, так що ви можете просто вирізати назву сторінки в кінці URL-адреси та переглянути всі файли на веб-сервер.

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

Люди розміщують свої паролі на загальнодоступних веб-сайтах ...

У 13 років моя школа відкрила соціальну мережу для учнів. На жаль, для них я знайшов помилку в безпеці, де ви могли змінити URI на інший userID, наприклад "? UserID = 123", і ввійти в систему для цього користувача. Очевидно, я сказав своїм друзям, і врешті-решт соціальна мережа шкіл наповнилася порно.

Не рекомендував би, хоча.

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

if (password.equals(requestpassword) || username.equals(requestusername))
{
    login = true;
}

Шкода, що один оператор робить таке велике значення.

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

Отже, по суті, все, що потрібно хакеру, - це моє ім'я користувача, і він може потім отримати доступ до мого облікового запису. Це було для головного банку, про який могли б почути принаймні 90% людей у ​​Сполучених Штатах. Це сталося близько двох років тому. Я не знаю, чи це був погано навчений представник служби обслуговування клієнтів чи це стандартна процедура.

Я поділюсь одним, який я створив. Типу.

Роки, роки та роки тому компанія, на якій я працював, шукала індексації на їх веб-сайті ASP. Так що я пішов і створив індекс-сервер, виключив кілька адміністративних каталогів і все було добре.

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

Пам'ятайте дітей, білі списки, а не чорні списки.

Один з найпростіших, але дійсно гідних:

Платіжні системи, які використовують двигуни, такі як PayPal, можуть бути помилковими, оскільки відповідь, отримана від PayPal після успішного платежу, не перевіряється як слід.

Наприклад:

Я можу зайти на якийсь веб-сайт із придбання компакт-дисків і додати деякий вміст у кошик, тоді на етапах оформлення замовлення на сторінці зазвичай є форма, заповнена полями для paypal, і кнопка для надсилання на "Оплатити" ..

Використовуючи редактор DOM, я можу перейти до форми "жити" та змінити значення з £899.00на, £0.01а потім натиснути кнопку "Надіслати" ...

Коли я перебуваю на стороні PayPal, я бачу, що сума становить 1 копійку, тому я плачу за це, і PayPal перенаправляє деякі параметри на початковий сайт покупки, який лише перевіряє параметри, наприклад payment_status=1, і т. Д. І т.д., і не підтвердити сплачену суму.

Це може бути дорого, якщо вони не мають достатнього місця для входу в систему або продукти автоматично відправляються.

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

Як щодо он-лайн-менеджера документів, який дозволив встановити кожен дозвіл на безпеку, який ви могли запам'ятати ...

Це поки ви не потрапите на сторінку завантаження ... download.aspx? DocumentId = 12345

Так, documentId був ідентифікатором бази даних (автоматичним збільшенням), і ви можете зафіксувати кожен номер і кожен може отримати всі документи компанії.

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

Норвезька доставка піци мала захисну дірку, де ви можете замовити негативні кількості піц на новому і блискучому Інтернет-порталі та отримати їх безкоштовно.