Уразливості на kpi.ua
23:52 21.05.2010У жовтні, 22.10.2009, я знайшов Information Leakage уразливість на сайті http://kpi.ua. З якої в тому числі можна дізнатися про численні уразливості, що мали місце на даному сайті тривалий час.
Про уразливі, взломані та інфіковані КПІ-шні сайти я писав багато разів за 2008-2010 роки. Навіть писав про інфекцію на kpi.ua, що була виявлена 12.12.2009. Останній раз я писав про уразливості на codecamp.org.ua - сайті організаторів конференції CodeCamp, що проводилася минулого і цього року в КПІ.
Ситуація на http://kpi.ua не краща. Що видно з Information Leakage уразливості на даному сайті.
Information Leakage:
http://kpi.ua/CHANGELOG.txt
Прочитавши перелік виправлених дірок в Друпалі, ви можете дізнатися про численні уразливості, що тривалий час мали місце на даному сайті. Зокрема в жовтні вони використовували Drupal 5.19. Можете подивитися скільки дірок було виправлено за цей час в Drupal до тієї версії, що зараз використовується на сайті. І при цьому врахуйте, що КПІ проводить конференцію про інформаційну безпеку CodeCamp. При цьому забуваючи, як і самі організатори конференції, про безпеку власних сайтів.
Субота, 13:26 22.05.2010
Доречі як я помітив досить таки часто зустрічається подібне. Мало хто (на жаль) розуміє як можна використати Information Leakage в тій чи іншій ситуації, на перший погляд той же changelog чи ще якісь коменти розробників здаються безпечними.
Субота, 18:32 22.05.2010
Так витоків інформації, як FPD, так й інших вистачає на сайтах. Зокрема такий витік інформації, як версія додатку. І як версії в хедерах сервера, так і версії веб додатків потрібно випрвляти.
Про різні Information Leakage уразливостей я писав чимало. Зокрема я зробив 4 статті про витік інформації про версію системи (і з часом зроблю нові статті). В тому числі в другій статті з даної серії я описав і дану уразливість в Drupal.
Одне діло якщо у людей на сайті власний движок, який ніде більше не використовується, то можна і розмістити на сайті версію движка. Інша справа коли у людей на сайті популярний движок (що опенсорсний, що закритий) - тут вже небезпечно повідомляти про його версію. Але в будь-якому разі не треба мати дірок на сайті
, тоді його не взломають (незалежно від виведення версії движка).
Неділя, 10:16 23.05.2010
Ну погодься, що незавжди відсутність дірок захищає від злому. Так як може бути зломаний хостинг чи сусідній сайт, хоча це уже не зовсім злом конкретного сайту, але все ж, добратися до нього можна.
Вівторок, 23:54 25.05.2010
Dementor
Це обов’язкова вимога. Бо якщо є дірки на сайті, то вірогідність взлому збільшується (і тим більше, чим більше дірок, особливо високого ризику).
Є ще питання соціальної інженерії та інші аспекти, що опосередковано відносяться до сайтів. Наприклад, можна змусити жертву самій розповісти свій логін і пароль від сайта - але це не відноситься до питань веб безпеки, це вже питання соціальної інженерії. Можна фізічно вломитися в серверну і забрати сервер (наприклад, як це трапилося торік) - але це вже не питання веб безпеки, а фізичної безпеки. Можна загнати адміну на компьютер вірус і дістати логіни й паролі до адмінки чи ftp - але це вже не питання веб безпеки, а локальної безпеки (на локальному компьютері).
Ми ж говоримо про веб безпеку. А до неї відносяться уразливості на сайтах та веб додатках. З чого випливає, що дірок бути не повинно
. Атаки через хостінг на інші сайти трапляються - але це вже питання хостера (нажаль на вибір надійного хостера мало хто звертає увагу). Щоб права були налаштовані й всі патчі на сервері поставлені, тоді взлом одного сайта не вплине на інші сайти.
Середа, 09:08 26.05.2010
Я згоден, що проблеми людського фактору це не веб-безпека. Але все-таки злом хоста це вже прогалина в безпеці і велика, так як може постраждати не один сайт.
Субота, 23:44 12.06.2010
Як я вже сказав в попередньому коментарі - якщо права будуть налаштовані й всі патчі на сервері поставлені, тоді взлом одного сайта не вплине на інші сайти. Тому при нормальному хостері від взлома сайта проблем для інших сайтів інших клієнтів не буде. Це інша справа, що не всі хостери такі
.
Щоб через один сайт дістатися до інших для цього потрібно мати доступ до файлової системи, що вже само по собі серйозна уразливість (для даного сайту, не кажучи вже про можливість доступу до інших сайтів на даному сервері).
І як я вже казав, при нормально налаштованому сервері (у нормального хостера) проблем для інших сайтів не буде - бо до них не зможуть добратися з похаканого сайта. Тільки до інших сайтів даного клієнта на даному сервері (але це вже будуть проблеми даного клієнта, що він через один дірявий сайт підставляє одразу всі свої сайти на даному сервері). Розміщення своїх сайтів на різних фізичних серверах допоможе уникнути даної ситуауції
.
Неділя, 14:56 13.06.2010
Я з тобою повністю згоден. Правда в людей не завжди є гроші на хорошого хостера, або вони прсто в цьому мало що розуміють, і беруть що є. А такі серйозні вразливості в хостах я зустрічав доволі частенько.
Субота, 14:10 11.12.2010
Серед згаданих мною уразливостей в Drupal, частина дірок має місце і на kpi.ua.
Субота, 15:00 11.12.2010
Більшість хостерів зі своєї сторони не дуже слідкують за безпекою і, враховуючи суцільну дірявість сайтів їх клієнтів, то це створює ризики масових взломів - коли через один сайт взломають одразу всі сайти на сервері. Тому і хостери, і власники сайтів повинні слідкувати за безпекою (і якщо власник сайта має свій виділений сервер, то він повинен слідкувати і за тим, і за тим).
Дірки на сайтах, що дозволяють читати довільні файли, чи навіть мати повний доступ до файлової системи, мені трапляються часто. Проте в більшості випадків мені трапляються сайти, де нормально налаштовані права на сервері, що до сайтів інших аккаунтів не дістатися. Але враховуючи, що в 99% на сервері можуть бути дірки, які дозволять підняти права до рута, то вірогідність атаки на інші сайти дуже висока.