Информация опасносте
19.2K subscribers
605 photos
10 videos
39 files
4.27K links
Чаще про c̶y̶b̶e̶r̶s̶e̶x̶ cybersec
Нет, «опасносте» не опечатка
@alexmaknet

Размещение рекламы остановлено в связи с войной России против Украины
Download Telegram
Я с таким никогда не сталкивался, но пишут, что иногда ФБ заставляет пользователей установить такой антивирус и просканировать компьютер. Причем иногда это показывают Мак-юзерам, а файл — для Винды
И снова здравствуйте! Как обычно это происходит на этом канале - только плохие новости. За последние два дня практически все российские анти-DDoS-провайдеры столкнулись с атаками типа memcache amplification. Наблюдаемые объемы трафика атаки варьируются в пределах от 200 до 400 Гбит/с.

Memcache amplification — это достаточно новый вид атак, открытый китайскими исследователями в 2017 году. Суть amplification-атак в целом — в том, чтобы трафик DDoS-атаки, который атакующий создаёт с собственных серверов, на пути к жертве кратно умножался промежуточным уязвимым сервером-рефлектором. Типичные коэффициенты умножения для прежних amplification-атак (DNS Amp, SSDP Amp и других) — порядка 50-150, в случае NTP Amplification — около 500.

Уязвимость в memcached позволяет записать в память бедняги-рефлектора произвольный объём данных, а потом многократно выслать его в сторону атакуемого сайта. Ввиду этого коэффициент амплификации достаточно сложно рассчитать, поскольку наивный расчёт даёт заоблачные цифры, порядка миллионов. Qrator Labs в своём пресс-релизе отмечают, что, из их опыта, на практике коэффициент — около 9000-10000. То есть на каждый мегабит, сгенерированный атакующим, в сторону жертвы будет отправлено 10 Гбит. Если в ближайшие несколько недель ваш любимый сайт не будет открываться, возможно, причина будет именно в этом.

Самое смешное, что уязвимость сама по себе была обнаружена ещё в 2014 году, но использовать её для DDoS-атак догадались только прошлой осенью.

Почитать детали на английском тут https://medium.com/@qratorlabs/the-memcached-amplification-attack-reaching-500-gbps-b439a7b83c98


А на русском тут https://habrahabr.ru/company/qrator/blog/350074/
Похоже, что израильская компания Cellebrite (она, по неподтвержденным данным, в свое время помогла ФБР разблокировать iPhone террориста из Сан-Бернардино, Калифорния), нашла какую-то уязвимость в iOS, позволяющую разблокировать iPhone различных моделей с операционной системой вплоть до iOS 11, причем включая iPhone X. Детали традиционно не разглашаются — подобная уязвимость стоит миллионы долларов, так что остается только гадать, что это за дыра и исправит ли Apple её в будущем. Обычным пользователям, правда, переживать особо нечего — это не циркулирующая в открытом интернете информация, но все равно хочется надеяться, что кунг-фу Apple окажется сильнее и компания сможет исправить эту ситуацию

Статья на Forbes https://www.forbes.com/sites/thomasbrewster/2018/02/26/government-can-access-any-apple-iphone-cellebrite/

PDF самой Cellebrite c информацией о том, что их решение может взломать “Apple iOS devices and operating systems, including iPhone, iPad, iPad mini, iPad Pro and iPod touch, running iOS 5 to iOS 11.”
кстати, про Apple. какое-то время назад стало известно, что Apple переносит данные iCloud китайских пользователей в Китай, где дата-центром будет управлять государственная компания. Уже тогда возникли опасения, что это может облегчить правительственным организациям в Китае доступ к данным в этих бекапах. В последние пару дней появилась также информация, что Apple также передаст и ключи для дешифровки бекапов iCloud китайской стороне, что напрягло многих еще и больше (и в целом оправданно). Я так понимаю, что Apple была поставлена перед выбором “перевести iCloud для китайских пользователей в Китай или отказаться от продаж в Китае”, и понятно, какой выбор сделала компания.

Из того, что я читал по теме, выглядит все не так однозначно в подобной ситуации — когда речь идет о цифровом мире, и понятие границ крайне размывается. (как доказательство, можно привести в пример дело, которое как раз в эти дни рассматривает Верховный Суд США с Microsoft, где компанию пытались обязать выдать почту пользователя, а почта хранилась в дата-центре за пределами страны). Хранение данных инностранных пользователей в США делает их потенциально уязвимыми для наблюдения со стороны американских разведывательных и правоохранительных органов, так что для них (инностранных пользователей) это еще и риски оказаться втянутыми в какие-то расследования той же ФБР, например. Многие компании и государства не ощущают особого комфорта от того, что их данные могут храниться на каком-то там облаке на территории США (не только Китай, но и РФ требует, например, хранить персональные данные на территории страны). Да и, как мы знаем по многократным публикациям, американские органы не стесняются следить за кем попало. Однако, есть также и стойкое подозрение, что китайским пользователям есть чего опасаться в отношении слежки со стороны китайских органов. Короче, очень щекотливый вопрос.
Фото со съемок сериала “Кремниевая Долина” — они там к информационной безопасности относятся серьезней, чем многие в реальной жизни
Кролики - это не только ценный мех... ой, кажется, не туда пишу. А, не, туда! Я хотел сказать, что безопасность операционных систем - это не только наличие или отсутствие уязвимостей, но и то, как быстро производитель выпускает обновления, исправляющие обнаруженные уязвимости, как быстро эти обновления доходят до пользователей, как долго операционная система поддерживается производителем, и тд. По этому поводу компания Security Lab сделала очень хорошую табличку, сравнив разных производителей и то, как у них обстоят дела с обновлениями для безопасности. Выводы можете сделать сами
Используете #, %, & и другие символы??? Ай-ай-ай, да вы хакер!
Я вчера писал о статье ребят из компании Qrator Labs о DDoS атаках типа memcache amplification (https://t.me/alexmakus/1800). там упоминалось, что с этим столкнулись практически все российские анти-DDoS провайдеры. Однако, не Россией единой. Вот и CloudFlare пишет о том же типе атак с UDP-портом 11211 и пиками в 260Гбит/сек. По ссылке детали и что с этим делать https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
весьма забавное видео с базовыми рекомендациями про пароли! like, share, и что там еще делают по этому поводу! (на англ, но в целом все понятно)
https://www.youtube.com/watch?v=IgCHcuCw_RQ
криптомайнинг везде, или как рекламные сети избегают бллокировщиков рекламы, чтобы использовать ресурсы ваших компьютеров
https://blog.netlab.360.com/who-is-stealing-my-power-iii-an-adnetwork-company-case-study-en/
я упоминал ранее на неделе, что появился интересный сервис проверки утекших паролей, и о том, что 1Password прикручивают его у себя на сайте. Но это доступно только если вы платите подписку за сервис. Тем, кто, как я, купил perpetual лицензию, надо ждать апдейта приложения, либо же можно воспользоваться сторонним скриптом, который может анализировать экспорт паролей из 1Password. опасный момент — скрипт генерит CSV файл с паролями в открытом тексте, поэтому надо потом обязательно его удалить.

Но пересмотреть видео выше, придумать для важных сервисов сложные пароли, и не использовать re-use тоже не помешает!
https://github.com/eblin/1passpwnedcheck
меня тут просят напомнить, что не 1Password-ом единым. Есть много разных других менеджеров паролей, закрытых и открытых, платных и бесплатных. Мол, менеджер паролей, коду которого проведен аудит, будет лучше, чем тот, который проприетарный. Моя точка зрения от этого мнения немного отличается, но помните, что у вас всегда есть выбор. Вот несколько статей с обзорами разных менеджеров паролей:
https://thewirecutter.com/reviews/best-password-managers/
https://www.techradar.com/news/software/applications/the-best-password-manager-1325845
https://lifehacker.com/5529133/five-best-password-managers
https://www.pcmag.com/article2/0,2817,2407168,00.asp

PS нет, я не рекламирую 1Password, я просто им пользуюсь уже много лет, и у меня не было необходимости искать ему альтернативу
так, котаны. Я старательно избегал темы с GetContact, исходя из того, что читатели этого канала достаточно умны, чтобы этим сервисом не пользоваться. Но поскольку все мы общаемся с самыми разными людьми, пожалуй, упомянуть это стоит, тем более, что мне уже не один раз об этом сервисе написали. Сервис (формально) позволяет более лучше идентифицировать звонящих вам, но для этого вам нужно закачать туда свою адресную книгу. в итоге люди устанавливают приложени, чтобы узнать, как их или чей-то еще номер записан в чужих телефонах. Добровольно отдать непонятно кому свою адресную книгу — это даааааааа…. Ладно бы еще человек просто свои персональные данные отдает, так он еще и чужие имена-телефоны и, возможно, другую информацию, записанную в его адресную книгу, в этот сервис отдает.

а ведь часто в адресных книгах хранят не только имена-телефоны, а тут вот такое: “Политикой конфиденциальности данного приложения предусмотрена передача третьим лицам телефонных номеров, учетных записей социальных сетей, фотографий, адресов электронной почты, вплоть до записей телефонных разговоров. Кроме того, в контактных данных телефона может находиться информация о кредитных картах, их PIN и пароли от личных кабинетов.”

Короче, по совету читателей: “Что - можно сделать: Если приложение Get Contact уже установлено в вашем мобильном телефоне, рекомендуем сначала удалить свой аккаунт (это можно сделать в настройках приложения в пункте "О GetContact"), после этого удалить само приложение;
• Скрыть свой номер телефона в базе данных GetContact можно, перейдя по
https://www.getcontact.com/en/unlist

АПД. Кстати, учитывая общую “серость” этого сервиса, я уже не уверен, что вбивать свой номер телефона в unlist — тоже хорошая идея.

берегите там себя, свою информацию, и чужую тоже берегите!

АПД 2 а вообще, как пишут некоторые читатели, проблема не только в этом приложении, а более глобальная, и никак от нее не спастись. Пора переезжать в лесную избушку без интернета
вообще я посмотрел на сайте — там ни адреса, ни телефона, ни толком информации о юрлице этого GetContact нет. как можно в здравом уме отдавать непонятно кому непонятно куда и непонятно зачем свою адресную книгу — это у меня в голове не укладывается. Впрочем, у меня такая неудобная голова, что там многое не укладывается.
еще полезная цитата: “По поводу GetConnet. Там все намного хуже. Штука в том, что уже распарили API до уровня “запрос номера телефон - ответ всего что доступно”, а доступно там дофига чего. То есть, ссылки на соц.сети, адреса, ФИО и тыды. С учетом того, что их серверы отдают 500 и 504 постоянно, их парсят и сливают всю БД тупым перебором. Так что скоро мы увидим глобальную телефонную книжечку в удобненьком формате.”
В пятницу можно и пошутить на скользкую тему:
Russians are so good at hacking because a lot of them come from Cyberia
так, сейчас будет небольшой long read про GetContact, не переключайтесь 🙂
И снова здравствуйте! У меня тут есть немножко информации вдогонку про GetContact, которую мне рассказал читатель канала — он просто мимо, так сказать, проходил :), а я немножко её отформатировал и дополнил. (я уже говорил, что у этого канала лучшие читатели, но не устану это повторять!)

Сначала про юрлицо. Сама компания зарегистрирована двумя турками (BURAK SELAHATTIN SAGLIK и MUSTAFA SEVINÇ, 79 и 80 годов рождения) в Лондоне. Адрес регистрации популярен среди оффшорных компаний, это адрес компании, которая подавала заявку о регистрации компании GetContact LLP. Все очень надежно, можно доверять свои самые заветные данные такой компании, нечего переживать.

Теперь мякотка! Вот поля в базе, которые хранит GetContact о своих пользователях:

"id": "9f29a2fb5532",
"name": "",
"surname": "",
"display_name": "",
"msisdn": "+",
"email": "@",
"gender": null,
"fb_id": null,
"company": null,
"job": null,
"profile_image": null,
"country_id": "192",
"country": "RUSSIA",
"city": null,
"main_street": null,
"street": null,
"zip_code": null,
"accessibility": 2,
"suggestion": "1",
"view_notifications": null,
"language": "ru",
"type": "user",
"is_owner": "0",
"name_count": 14,
"other_names": [

Уже прекрасно, я представляю себе, что с их миллиардами записей (как они утверждают) к ним уже стоит большая очередь купить эту всю информацию. Но это еще не все. При попытке отписаться от сервиса туда передается IMEI устройства.

GET /api/version?os=android&os_version=5.1.1&lang=en_&gt_version=3.2.7&token=null&device_id=ff917ed173746ce7&device_imei=358022070321072&network_iso=de&network_mcc=262&network_mnc=01&network_type=UNKNOWN&sim_state=ABSENT HTTP/1.1
Content-Type: application/json; charset=utf-8
GTC-OS-TYPE: Android
User-Agent: Dalvik/2.1.0 (Linux; U; Android 5.1.1; SM-G800F Build/LMY47X)
Host: getcontact.com
Connection: close

Так что если вы поменяете номер телефона, но потом каким-то образом засветите свой новый номер, вас тут же “скрестят” с уже имеющейся информацией. И необязательно в GetContact — кто-либо другой, кто купит базу информации у GectContact, тоже сможет получить о вас гораздо больше информации, чем вы себе представляете

Впрочем, покупать данные совсем необязательно, многое из этой базы лежит или в открытом, или в полуоткрытом виде, и при желании многое можно выкачать и просто так.
Например, часть информации по юзерпикам лежит в совершенно открытом бакете AWS — https://cdn.getcontact.com — добавив любой из имени файла profile_image, можно посмотреть фотографии различных красавчиков и красавиц.

Вот, например, часть информации, которую можно вытащить по ID пользователя (кое-что я скрыл буквами ХХ по понятным причинам):
id": "86f7f851746b2b8b2329e9a43d0ab64f2be32dbe",
"name": "AykXX”,
"surname": "DoğXX”,
"display_name": "AykXX DoğXX”,
"msisdn": "+90537206XXXX”,
"email": "aykXX.dogXX34@gmail.com",
"gender": "1",
"fb_id": "1015384821978XXXX”,
"company": "",
"job": "",
"profile_image": "http://graph.facebook.com/1015384821978XXXX/picture?type=large",
"country_id": "1",
"country": "TURKEY",
"city": "",
"main_street": "",
"street": null,
"zip_code": "",
"accessibility": 2,
"suggestion": "1",
"view_notifications": "0",
"language": "tr",
"type": "user",
"is_owner": "0",
"name_count": 18,
"total_tag_count": 17,
"list_editable": false,

Забавно, что этого человека залили человек 20, поэтому его разные имена перечислены в списке. Там даже есть такое:
"AykXX Abi",
"Рустем Проблемалы",
"Squartile",
"Abim"

А так, конечно, ему тоже, наверно, нечего скрывать.
Есть еще отдельная и непонятная тема — это ответы на запросы на русском языке, и фигурирование некоторых названий на русском языке. Почему так — пока что непонятно, и я, пожалуй, не буду спекулировать на эту тему. Но это выглядит так, например:

{
"meta": {
"requestId": "job.localdomain-REQ-5a997f43e5d7b",
"httpStatusCode": 403,
"errorMessage": "Вы достигли максимального дневного лимита запросов.",
"errorCode": -4291


Или вот про названия на русском языке. Некоторые номера, похоже, записаны как “забаненные” для исключения их идентификации при звонках:

GET /api/phone/ban?token=3f248b01e250406ec37b38ab34342104&lang=en_ HTTP/1.1
Content-Type: application/json; charset=utf-8
GTC-OS-TYPE: Android
User-Agent: Dalvik/2.1.0 (Linux; U; Android 5.1.1; SM-G800F Build/LMY47X)
Host: getcontact.com
Connection: close


{
"meta": {
"httpStatusCode": 200,
"requestId": "api4.localdomain-REQ-5a99327c04677"
},
"status": 1,
"error": {},
"response": {
"list": [
{
"type": "country",
"id": "14571",
"msisdn": "+78002509890",
"name": "Мтс",
"banned_count": "12",
"create_date": "2018-03-02 00:10:22"
},
{
"type": "country",
"id": "14572",
"msisdn": "+78005551534",
"name": "Тинькофф Банк",
"banned_count": "11",
"create_date": "2018-03-02 00:10:22"
},
{
"type": "country",
"id": "14573",
"msisdn": "+78007552771",
"name": "Тинькофф",
"banned_count": "11",
"create_date": "2018-03-02 00:10:22"
}
],
"sms": [
{
"type": "user",
"id": 1,
"msisdn": "+905464039500",
"name": null,
"banned_count": 1
},
{
"type": "user",
"id": 2,
"msisdn": "+905418376041",
"name": null,
"banned_count": 1
},
{
"type": "user",
"id": 3,
"msisdn": "+905389837455",
"name": null,
"banned_count": 1
},
{
"type": "user",
"id": 4,
"msisdn": "+905372064704",
"name": null,
"banned_count": 1
}
]
}
}

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