Про дипломную работу, написанную ChatGPT

Добавить комментарий

Про дипломную работу, написанную ChatGPT. Прочитал оригинальный тред biblikz (ссылку давать не буду, чтобы не рекламировать). Если кто-то слышал мельком новость и думает, что ChatGPT сам смог выдать структурированный осмысленный текст, который хотя бы издали был похож на дипломную работу, тот ошибается. Если кто-то думает, что студент использовал ChatGPT для развития собственных мыслей, что это какое-то совместное творчество человека и машины, тот тоже ошибается. Все гораздо проще и гнуснее.

1. Студент несколько раз пытался сдать своему научному руководителю сгенерированный ChatGPT текст как план дипломной бакалаврской работы "Анализ и совершенствование управления игровой организацией", принципиально не желая написать его нормально по методичке. "И на четвертый раз ломаю научницу, она присылает план моего диплома". План ему написали.
2. Чтобы получить введение, студент вводил в ChatGPT план диплома целиком (!) в качестве запроса, получал какой-то бред (потому что релевантный ответ на "это" получить нельзя), а потом переводил его яндекс-переводчиком.
3. Для теоретической части студент генерил текст в ChatGPT на тему "5 принципов менеджмента", а потом переводил это опять же яндекс-переводчиком.
4. Практическая часть это рерайт текста из чужого дипломного проекта про мясокомбинат. 😐
5. Проверку научного руководителя полученный текст не прошел, студент приводил текст до более-менее читаемого вида вручную и с помощью ChatGPT. Основной критерий, на который смотрели это уникальность текста по антиплагиату.
6. Отзывы студенту написали нормальные.
7. На защите диплома студент устроил клоунаду, его выгоняли из аудиториии, но в итоге трояк поставили.

После этого студент вывалил всю эту позорную историю в паблик, подставляя научного руководителя, рецензентов, дипломную комиссию и ВУЗ в целом. Видимо за то, что те не выгнали его в шею, хотя он этого полностью заслуживал, а выдали несчастную корку. Видимо из жалости. Не знаю как вам, но по мне так это всё отвратительно от начала и до конца.

С другой стороны это наглядная демонстрация типичного адепта ChatGPT - человека, которому достоверность сгенеренного текста глубоко безразлична, лишь бы только этот текст доставался бесплатно в неограниченных количествах и выглядел убедительно.

Некоторые заметки по итогам митапа Яндекс-а

Добавить комментарий

Некоторые заметки по итогам митапа Яндекс-а. Зафиксирую, чтобы не забылось. Для тех, кто не смотрел, полное видео уже доступно.

1. Прикольная тема из Яндекс Финтех про "одна команда - один Golden Image":

"У нас большой стек. У нас сервисы пишутся и на Kotlin, и на плюсах, и для разных языков мы используем разные Golden Image-ы. Но стараемся, чтобы внутри команды, которая пишет на одном фреймворке и на одном языке сформировался какой-то единый образ, который будет использоваться внутри этой команды. У нас есть набор этих золотых образов, которые используются конкретными командами. Все контейнеры, которые получаются мы пушим в наш registry. Вопрос сколько их сложный, т.к. у нас микросервисная архитектура и у нас очень много микросервисов."

➡️ Вопрос: Используете ли вы distroless образы в Банке, да и в Яндексе в целом, к примеру Google distroless, чтобы минимизировать поверхность атаки и уменьшить размер самих образов?
Ответ: нет, но очень хотим к этому прийти
➡️ Вопрос: Если не секрет, что у вас за базовый образ? Аstra Linux? 😉
Ответ: отвечу, что такой же как и во всем Яндексе )

Вполне возможно это секрет полишинеля на основе какого Linux-дистрибутива базовые образы в Яндексе делают, но я не знаю. Если кто знает - шепните в личку, любопытно. 😉

2. То, что Яндекс Финтеху комфортно в Яндекс Облаке это понятное дело. Но будет ли так же комфортно другим банкам и финтехам?

➡️Вопрос: Возвращаясь к сертификации банка в облаке по стандартам PCI DSS и ГОСТам. Я смогу запустить такой банк в я.облаке и получить содействие при прохождении аудита со стороны Команды облака или это единичный случай для «родственной» компании?
Ответ: Можно это получить как отдельную услугу в Облаке.
➡️ Вопрос: прям услуга Облака или рекомендованная внешняя команда?
Ответ: В Облаке есть архитекторы и premium support.

3. В Wildberries и Яндекс Финтех для организации привилегированного доступа к Linux-инфраструктуре используют Teleport. Почему именно его? Как минимум половина доклада команды Wildberries была про обоснование этого выбора. Очень подробно и убедительно. Единственное жаль, что тема в основном крутилась про то как безопасно дать доступ до нужных серверов и дать/не дать root-а, но не про хитрое ограничение прав пользователя на хосте. А это у Wildberries есть, т.к. Teleport у них сильно допиленный:

"Команда переписала админку Teleport-а полностью с нуля. Написала свой PAM-модуль, который учитывает роли, которые передаются телепортом при аутентификации и на основе этого настраивает sudo. Но мы сегодня про это подробно не рассказывали, потому что оно опять же не поместилось."

Про sudo тема интересная, будем ждать следующего раза. 🙂

SQL-инъекция в сетевых хранилищах QNAP (CVE-2022-27596)

Добавить комментарий

SQL-инъекция в сетевых хранилищах QNAP (CVE-2022-27596)

SQL-инъекция в сетевых хранилищах QNAP (CVE-2022-27596). CVSS 9.8. До какого состояния докрутят эту SQLi сказать сложно, но угрозу конфиденциальности и целостности данных можно смело предположить. Нужно патчить. Хоть эксплоита и признаков эксплуатации вживую пока не видно.

QNAP это тайваньский вендор. В основном они выпускают NAS-ы (Network-attached storage) различного класса: от "для дома для семьи" до серьезных энтерпрайзных решений. Используют свои операционные системы QTS (для устройств попроще) и QuTS hero (для навороченных). Эти ОС и предлагается обновить на устройствах для исправления уязвимости.

NAS-ы это излюбленные мишени для ransomware. Во-первых, там хранятся ценные данные компаний. Во-вторых, их частенько выставляют прямо в Интернет. 🙃

Судя по тому, что у QNAP есть вполне актуальный русскоязычный сайт и активная группа в ВК, продаются они в России неплохо. А значит и в инфраструктуре вашей организации они вполне могут найтись. Дайте знать своим админам! 😉

Парень нашел "уязвимость" в VK и ему стали массово писать в личку заинтересованные девушки

Добавить комментарий

Парень нашел "уязвимость" в VK и ему стали массово писать в личку заинтересованные девушки. 🙂 Этот забавный кейс я увидел в канале Standoff News. Технически там не очень интересно. Но как пример простой "уязвимости" для иллюстрации почему искать уязвимости это прикольно и как противостоять эксплуатации уязвимостей - вполне норм (студентам младших курсов, школьникам на профориентации т.п.).

В чем там было дело:

1. В VK пользователи могут видеть кто смотрел их сторисы (формат вертикальных публикаций, которые исчезают из ленты через 24 часа). В отличие от обычных сообщений в ленте, для которых видно только тех, кто полайкал.
2. В VK не было лимита на просмотр сторисов. Было возможно автоматически "просматривать" хоть миллионы чужих сторисов в день. (не конкретизируется как)
3. Было возможно массово получить идентификаторы пользователей из групп типа "любители котиков". (не конкретизируется как)
4. Было возможно автоматически получить сторисы для идентификаторов пользователей. (не конкретизируется как)

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

Далее конверсия: миллионы просмотренных сторисов -> десятки тысяч заходов от любопытных пользователей на страницу Накрутчика -> сотни сообщений от тех, кому совсем уж любопытно. Profit.

Вопросы, которые можно задать аудитории:
1. Что можно было бы предусмотреть на стороне VK, чтобы так было делать нельзя? Возможный ответ: установить лимиты, при превышении таймаут или показывать капчу.
2. Что ждет Накрутчика, когда это обнаружится? Возможный ответ: как минимум забанят профиль, т.к. автоматизация действий нарушает пользовательское соглашение.
*3. Как можно подвести действия Накрутчика под УК РФ? Возможный ответ: по факту это скрэпинг, можно в теории натянуть на 272 и 273.

После этого можно поставить риторический вопрос. Что лучше: сдать уязвимость в VK и получить $100/спасибо, или пытаться эксплуатировать и подставляться? Каждый сам для себя решает.

Программу мероприятия подкрутили, круглый стол убрали

Добавить комментарий

Программу мероприятия подкрутили, круглый стол убрали. А жаль. 🙂 Но остальные доклады на месте.

Свести к минимуму непредсказуемый интерактивчик в текущей ситуации и правда выглядит весьма разумным решением. Мало ли что журналисты по итогам свободной дискуссии ИБшников могли себе додумать и нагенерить. Яндексу сейчас такое точно ни к чему. 🤫

Сканировать принтеры на уязвимости следует с осторожностью

Добавить комментарий

Сканировать принтеры на уязвимости следует с осторожностью

Сканировать принтеры на уязвимости следует с осторожностью. Классической является ситуация, когда взбесившийся принтер начинает печатать страницы крякозябр пока у него бумага в лотках не закончится. 🙂 Это значит, что кто-то натравил на принтер сканер уязвимостей с дефолтным профилем сканирования.

Некоторые Vulnerability Management вендоры вообще не рекомендуют активно сканировать принтеры. Например, в #Tenable относят принтеры к "хрупким устройствам" ("fragile devices") и рекомендуют использовать для обнаружения уязвимостей на них пассивные детекторы. Т.е. перехватывать трафик и определять по нему версию устройств и связанные уязвимости. Продвигают этим Nessus Network Monitor (NNM), бывший Passive Vulnerability Scanner (PVS), но тем не менее.

Если будете активно сканировать принтеры (например в связи с уязвимостью Lexmark-ов), покопайтесь в настройках профиля вашего сканера, там должны быть специальные опции. А лучше спросите службу поддержки вашего VM вендора.

RCE в 130 моделях принтеров (МФУ) Lexmark (CVE-2023-23560)

2 комментария

RCE в 130 моделях принтеров (МФУ) Lexmark (CVE-2023-23560)

RCE в 130 моделях принтеров (МФУ) Lexmark (CVE-2023-23560). Нашли в наиболее уязвимом, в web-интерфейсе. Получив контроль над устройством, злоумышленник может воспользоваться дополнительными сетевыми доступами для развития атаки. Непонятно может ли получить доступ к тому, что печатается/сканируется, но тоже исключать нельзя. Либо патчимся, либо отключаем TCP 65002 (WSD Print Service) в настройках.

Хороший повод, чтобы поразмышлять об активах неудобных для VM:

1. Вы обо всех принтерах в вашей инфраструктуре знаете?
2. Ваш сканер уязвимостей умеет детектировать уязвимости для ваших принтеров?
3. Давно вы сканировали принтеры на наличие уязвимостей?
4. Давно вы обновляли принтеры? Есть понимание кто, как и в какой срок это должен делать?

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