Мед осмотр можно в Москве будет. А собес надо будет в Варшаву ехать. Причем сейчас для этого надо будет сделать крюк через другую страну ЕС с шенгеном на руках
Нам всем только что рассказали что инфля 2.9%. Всем увеличивают зп, растут реальные доходы населения, самая низкая безработица и вообще уже зажили отлично. А следом сразу говорят о том как вложения в ОПК увеличены в разы. И ведь ни у кого не возникает вопроса - каким образом и откуда дополнительные деньги. К моему глубочайшему сожалению абсолютное большинство народа спит сном «завтра заживем». И лучшее что можно сделать в этой ситуации это спасать самого себя, если вдруг этот сон вам не нравится.
Режим не может терять устойчивость, если единственная реакция общества это выезд за пределы страны минимального процента от общего населения. Устойчивость теряется, когда не уезжают, а делают некоторые другие ныне запрещенные вещи.
Какой закон? Вы о чем. Вы наверное призабыли о какой стране идет речь. И о тех законах которые принимаются в последнее время с их наказанием. В этой стране нет границы никакой. Все сьедят.
А мне больше интересно как писать рассказы подобные, если все под NDA. Невозможно обезличить полностью многие компании. Там как не обезличивай - все равно понятно о ком речь. Как можно обезличить крупнейших клауд провайдеров например) У меня в практике уязвимостей найденных по вау эффекту на пяток премий таких хватит в топ попасть. Только вот писать о них невозможно из за nda. А по публичным CVE собственным - это мизерный процент от реальных уязвимостей.
Я занимаюсь ИБ уже не первый год далеко и без слез на эту и прошлую статью просто невозможно смотреть. Проблема раздувается там где ее нет.
Технический уровень статьи никакой. Обе последние статьи выглядят как просто самопиар.
Такое было модно писать много лет назад на форумах для скрипт-кидди, но не как не на хабр
Нет, не сделано. Я согласен с вами, что данная рекомендация полезная и возможно мы возьмем ее на вооружение. Однако в данном случае правильно воспринимать мой пост — как сравнение mail.ru с gmail и yandex. Которые корректно отрабатывают ситуации и с заголовком, и с валидностью ящика.
У мейл.ру абсолютно не адекватное поведение по поводу любых рассылок. Мы проводим переодически рассылки по нашей базе пользователей. Рассылки составлены по всем правилам, включая данный заголовок.
Однако при нажатии данной кнопки — пользователь в дальнейшем начинает в спам получать любые письма восстановления паролей, регистрацией и прочего с нашего сервиса. Это вызывает много проблем и данный кейс совсем не редок.
Ну а насчет того, что mail.ru не отвечает при попытке отправить письмо ее пользователю — есть ли данный ящик в данный момент — вообще ахтунг (gmail и yandex корректно отвечают при этом на запрос попытки отправить). Мейл.ру же принимает все письма, а потом тра-та домен загоняют в мину по репутации, т.к. он шлет на "уже удаленные" ящики.
Когда сервис только открывался, пробовал его колупнуть на баги безопасности. Была тогда фича, что после удаления файлов из облака — реально файлы остаются в облаке. Они удалялись только из интерфейса пользователя. Тестировалось, через добавление себе "новых файлов", имея только хеш рассчитанный по их алгоритму. При этом удаленный файл из облака, добавлялся через его хеш, даже спустя сутки.
Если ничего не поменяли, то тех поддержка с технической точки зрения должна обладать возможностью восстановить "удаленные" вами файлы.
1. На первоначальной версии сайта были реквизиты юр. лица. Сейчас похоже затерли.
2. Есть готовые sql inj запросы. На момент поста в жж — они работали. А уж домыслить что вместо слипа в запрос вставить — не много ума надо.
3. Ну если хотят вести бизнес — то геморрой будет в любом случае.
На самом деле пост видели в Почте. Да и ребята из этой сокол-секьрити сильно лукавят
1. Достучаться до необходимых лиц в почте РФ — более чем возможно. Лично достукивался по вопросам безопасности. И если юр.лицо не смогло достучаться — то это говорит только о компетентности менеджеров компании.
2. Выкладывать в паблик полные запросы на не закрытые уязвимости — это нарушение первой заповеди белого хакинга. Если уж хотели показать что-то, то надо выкладывать было без самих запросов, а только скрины с купюренными ответами.
3. Переодически компании проводят тендеры по аудиту ИТ безопасности, и почтаРФ не исключение. Если уж такие они хорошие — чего б в тендер не сунутся?
Как вы могли прочитать в статье — указанная программа не имя компа с которого тикет открывается пишет. А записывает при каждой авторизации пользователя на компе инфу в БД. Это означает, что даже при первом варианте прав на учетке mssql — мы можем дискредитировать систему логов просто набив туда не верных данных. К примеру указать, что Вася Пупкин на самом деле авторизован не на PC, а совсем на другом компе. Или просто заполнить вымышленными данными. Для того чтобы придумать более серьезный вариант атаки необходимо больше знаний о сети и настройках GPO.
Однозначно могу сказать одно, указанный метод крайне не безопасен в использовании.
Поверьте — это делается элементарно. Хотя первый вариант разумеется наименьшая из возможных бед, которая могла бы получится.
Подумайте сами логически. Приложение запускается на компе пользователя. Значит это приложение в момент запуска должно обладать информацией для конекта в БД. И данную информацию без труда можно получить.
Кстати если авторизация в БД по доменной учетке идет (той самой служебной), то тогда проверяйте какие права в домене имеет эта учетка, т.к. она потенциально есть у любого пользователя в сети.
Объясняю на примере описанного выше приложения.
Исходя из описания — приложение конектится напрямую в сервер БД от имени некой учетной записи (внутри приложения вшито или в нетлогон прописано в «запуск от имени»?)
В обоих случаях пользователь получает доступ к учетной записи, которая имеет права на совершение вышеописанного инсерта в БД.
Далее рассмотрим 3 варианта:
1. Данная учетная запись настроена верно и разрешает только инсерт и только в эту таблицу.
Тогда злоумышленник сможет только подделывать данные. Забивая всякой херней таблицу (включая запись дезинформации о других пользователях в сети)
2. Данная учетная запись настроена не верно, и имеет еще кучу разных прав в БД (если сильно повезет, то делит или запись/чтение других таблиц в БД). В этом случае вы злоумышленнику подарили возможность сделать все вышеописанное с информацией в БД сервере.
3. Данная учетная запись настроена вообще не верно, и не дай бог имеет права sa. Тогда вы подарили злоумышленнику не только данные в БД, но и весь БД сервер.
Никак это не влияет абсолютно. Это всего лишь анкета в лото р не более.
Мед осмотр можно в Москве будет. А собес надо будет в Варшаву ехать. Причем сейчас для этого надо будет сделать крюк через другую страну ЕС с шенгеном на руках
Нам всем только что рассказали что инфля 2.9%. Всем увеличивают зп, растут реальные доходы населения, самая низкая безработица и вообще уже зажили отлично. А следом сразу говорят о том как вложения в ОПК увеличены в разы. И ведь ни у кого не возникает вопроса - каким образом и откуда дополнительные деньги. К моему глубочайшему сожалению абсолютное большинство народа спит сном «завтра заживем». И лучшее что можно сделать в этой ситуации это спасать самого себя, если вдруг этот сон вам не нравится.
Режим не может терять устойчивость, если единственная реакция общества это выезд за пределы страны минимального процента от общего населения. Устойчивость теряется, когда не уезжают, а делают некоторые другие ныне запрещенные вещи.
И останутся там и дальше. Это удобный подход.
Какой закон? Вы о чем. Вы наверное призабыли о какой стране идет речь. И о тех законах которые принимаются в последнее время с их наказанием. В этой стране нет границы никакой. Все сьедят.
Сентябрь помните? Подавляющее большинство схавало. А тут всего лишь впн.
К сожалению судя по настроениям народа - скорее это наши с вами мечты.
А мне больше интересно как писать рассказы подобные, если все под NDA. Невозможно обезличить полностью многие компании. Там как не обезличивай - все равно понятно о ком речь. Как можно обезличить крупнейших клауд провайдеров например) У меня в практике уязвимостей найденных по вау эффекту на пяток премий таких хватит в топ попасть. Только вот писать о них невозможно из за nda. А по публичным CVE собственным - это мизерный процент от реальных уязвимостей.
Пойти в плохо закрытую дверь магазина и вытащить оттуда часть товаров - очевидно является преступлением. Тут аналогично абсолютно.
Технический уровень статьи никакой. Обе последние статьи выглядят как просто самопиар.
Такое было модно писать много лет назад на форумах для скрипт-кидди, но не как не на хабр
Однако при нажатии данной кнопки — пользователь в дальнейшем начинает в спам получать любые письма восстановления паролей, регистрацией и прочего с нашего сервиса. Это вызывает много проблем и данный кейс совсем не редок.
Ну а насчет того, что mail.ru не отвечает при попытке отправить письмо ее пользователю — есть ли данный ящик в данный момент — вообще ахтунг (gmail и yandex корректно отвечают при этом на запрос попытки отправить). Мейл.ру же принимает все письма, а потом тра-та домен загоняют в мину по репутации, т.к. он шлет на "уже удаленные" ящики.
Если ничего не поменяли, то тех поддержка с технической точки зрения должна обладать возможностью восстановить "удаленные" вами файлы.
2. Есть готовые sql inj запросы. На момент поста в жж — они работали. А уж домыслить что вместо слипа в запрос вставить — не много ума надо.
3. Ну если хотят вести бизнес — то геморрой будет в любом случае.
1. Достучаться до необходимых лиц в почте РФ — более чем возможно. Лично достукивался по вопросам безопасности. И если юр.лицо не смогло достучаться — то это говорит только о компетентности менеджеров компании.
2. Выкладывать в паблик полные запросы на не закрытые уязвимости — это нарушение первой заповеди белого хакинга. Если уж хотели показать что-то, то надо выкладывать было без самих запросов, а только скрины с купюренными ответами.
3. Переодически компании проводят тендеры по аудиту ИТ безопасности, и почтаРФ не исключение. Если уж такие они хорошие — чего б в тендер не сунутся?
Однозначно могу сказать одно, указанный метод крайне не безопасен в использовании.
Подумайте сами логически. Приложение запускается на компе пользователя. Значит это приложение в момент запуска должно обладать информацией для конекта в БД. И данную информацию без труда можно получить.
Кстати если авторизация в БД по доменной учетке идет (той самой служебной), то тогда проверяйте какие права в домене имеет эта учетка, т.к. она потенциально есть у любого пользователя в сети.
Исходя из описания — приложение конектится напрямую в сервер БД от имени некой учетной записи (внутри приложения вшито или в нетлогон прописано в «запуск от имени»?)
В обоих случаях пользователь получает доступ к учетной записи, которая имеет права на совершение вышеописанного инсерта в БД.
Далее рассмотрим 3 варианта:
1. Данная учетная запись настроена верно и разрешает только инсерт и только в эту таблицу.
Тогда злоумышленник сможет только подделывать данные. Забивая всякой херней таблицу (включая запись дезинформации о других пользователях в сети)
2. Данная учетная запись настроена не верно, и имеет еще кучу разных прав в БД (если сильно повезет, то делит или запись/чтение других таблиц в БД). В этом случае вы злоумышленнику подарили возможность сделать все вышеописанное с информацией в БД сервере.
3. Данная учетная запись настроена вообще не верно, и не дай бог имеет права sa. Тогда вы подарили злоумышленнику не только данные в БД, но и весь БД сервер.