Password strength explained

#engineering #security

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

What Makes Israel So Good at Hacking?

#security

Із самого початку повномасштабного вторгнення РФ в Україну, у суспільстві почали говорити про те, що Україні потрібно брати приклад з Ізраїлю у військовій справі.

Один з напрямків - це кібербезпека. Але чому та як Ізраїль став чи не найкращим в світі у цій сфері? Чому ми можемо навчитись вже зараз? Чи легко щось подібне буде збудувати в нашій країні?

А ви як думаєте?

Security Certification Roadmap

#curious #security

В світі тестування люди постійно холіварять - чи потрібно отримувати якісь сертифікати (на кшталт ISTQB) чи можна обійтись без них? А який сертифікат найкращий? А що він дає? А чи обов'язково мати такий?

Для порівняння - подивіться на роадмап сертифікатів в світі security та оцініть масштаби та кількість.
Багато компаній вимагають наявність декількох сертифікатів одразу.
А ще - там для кожного курсу наведена вартість ... Та порівняйте з 100-200$ за тестувальницькі сертифікати.

Avi Rubin: All your devices can be hacked

#security #video

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

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

Як? Відповіді у відео.

Про "ненадійність" MFA та нові технології зламу систем

#security #testing

Колись, треба було мати хоча б один пароль (який-небудь) для усіх сервісів. Потім рекомендували мати складний пароль з цифрами, спеціальними символами та літерами. Бажано - різний для кожного Вашого сервісу.
Далі настала потреба мати ще більше захисту - ввели OTP або інший варіант мульти-факторної аутентифікації. Один з розповсюджених варіантів - користуватись сервісом для генерації паролів типу Google Authenticator.

Та чи справді це гарантія захисту? Виявляється, що ні.
В кінці серпня цього року компанію Retool зламали. Причому зламали аккаунти, що були захищені MFA.

Але як?
Зловмисники спочатку надіслали фішингові SMS співробітникам. Більшість людей проігнорувала такі SMS, але одна людина таки клікнула.
Далі, ця людина зайшла по посиланню на фейковий "робочий" портал та ввела свій логін та пароль. А для того, щоб отримати згенерований пароль з Google Authenticator - зловмисники подзвонили цій людині, змінили свій голос за допомогою deepfake!!! на голос системного адміністратора та попросили співробітника сказати цей OTP пароль. Причому, хакери мали достатньо інформації про компанію, щоб звучати переконливо.

Додатковою проблемою стало те, що Google Authenticator з замовчуванням дозволяє синхронізувати дані між девайсами. Тому зловмисникам вдалося отримати не просто разовий доступ до аккаунту, а постійний.

Висновки:
- скільки не будуй систему безпеки - найбільш ненадійними все ще залишаються люди
- треба вивчати та перевіряти усі функції систем (навіть ті, що йдуть за замовчуванням та "покращують" usability)

Більше про цей інцидент - в блозі компанії.

How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack

#security

В серпні місяці багато великих компаній, у тому числі Google, зіткнулися із новим видом DDoS атак - HTTP/2 ‘Rapid Reset’.
Деякі наймасштабніші атаки досягали (тільки уявіть!) майже 400 мільйонів запитів за секунду.

Коротко
Як завжди, зловмисники знайшли недосконалість у тому, як працює HTTP/2 протокол.
А саме - відкривали багато конекшенів одразу, а потім надсилали RST_STREAM фрейм для того, щоб цей конекшн розірвати завчасно.
Сервер не міг досить швидко зупинити обробку конекшену - тому деякий час продовжував працювати (та займати свої ресурси).

Вже навіть завели окрему вразливість під це - CVE-2023-44487.

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

Автентифікація у Web - невеличкий посібник

#security

Час від часу читаю та слухаю матеріали з кібербезу (бо цікаво).
Ось натрапив недавно на гарний посібник з багатьох аспектів автентифікації у Web.
Плюс - є навіть підбірка гайдів від OWASP (там просто купа корисного!)

How SMS Fraud Works and How to Guard Against It

#security

Twitter, він же X, в лютому відключив аутентифікацію за допомогою SMS для усіх користувачів, крім преміальних.

- Нащо це було зроблено?
- Як це пов'язано зі злочинними схемами?
- Як захиститись від SMS fraud?

Про все це - сьогодні у невеличкій статті.

Топ 10 вразливостей LLM систем

#security #ai #llm

Організація OWASP, яка відома своїми списками вразливостей для веб й мобільних застосунків, нещодавно випустила список вразливостей для сучасних LLM систем, типу ChatGPT.

Можна навіть скачати в PDF.

Дуже цікаво дивитись як методи зламу еволюціонують разом із технологіями.

Як це працює: злам віддаленого доступу до Kia

#howitworks #security

Тестування непотрібне! Тим паче якесь там тестування безпеки!
А в результаті маємо можливість за лічені хвилини віддалено відкрити будь-який новий автомобіль Kia.

TL;DR - Як зламали?

Для того, шоб відкрити авто, на сервер надсилається POST запит з sessionId та VIN кодом машини. VIN отримати нескладно. А от як отримати sessionId?

1. Реєструємося як дилер та отримуємо sessionId
2. Шукаємо авто в базі по VIN коду
3. Модифікуємо доступ до авто для дилера
4. Додаємо мейл зловмисника для авто по VIN коду
5. Можемо відправляти запит на відкриття авто

Більше про вразливість у статті.

P.S. Вразливість вже закрили, тому й виклали цей приклад у вільний доступ

This is how you make a $100 billion AI worm

#security #ai

Всім привіт.

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

Як? За допомогою ... Штучного Інтелекту!

Але ж ШІ має блок на "шкідливі" відповіді? Це можна обійти, шляхом тренування моделі.
Але ж треба знайти вразливості системи? Так, ШІ сканує бази даних усіх останніх вразливостей автоматично.
Але ж системі треба знайти як використати ту чи іншу вразливість? Так, але її можна натренувати на купі вже готових гайдів.

Тобто ШІ вже зараз дозволяє навіть людям з мінімальними технічними навичками створювати доволі серйозні загрози.

Дуже раджу до перегляду.
P.S. ось тут можна почитати, якщо нема часу на відео.

Тестування безпеки LLM систем

#ai #llm #security #testing

Багато хто користується LLM системами, такими як ChatGPT, Claude, Gemini та інші. Дехто - тестує інтеграцію таких систем з власними продуктами. А хтось навіть розробляє свої власні LLM системи для внутрішнього користування.

Але що там з безпекою LLM-ок? Виявляється, prompt injection атаки то не вигадка, а реальна загроза. Бо ШІ може погано розрізняти системні запити та користувацькі запити. В такому випадку зловмисник може відносно легко обійти авторизацію, закинути SQL інʼєкцію чи навіть виконати команди віддалено.

Деякі корисні ресурси з теми:
- Гайд по вразливостям від OWASP
- Обмеження в тестуванні LLM систем
- Як саме виконувати prompt injection

Тренуватись можна тут: Portswigger Web LLM attacks