Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"ALPACA - новая техника MITM-атак на HTTPS"	+/–
Сообщение от opennews (??), 09-Июн-21, 21:45
Группа исследователей из нескольких университетов Германии разработала новый метод  MITM-атаки на HTTPS, дающий возможность извлечь Cookie с идентификаторами сеанса и другие конфиденциальные данные, а также добиться выполнения произвольного кода JavaScript в контексте другого сайта. Атака получила название ALPACA и может быть применена к TLS-серверам, реализующим разные протоколы прикладного уровня (HTTPS, SFTP, SMTP, IMAP, POP3), но использующим общие TLS-сертификаты... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55307
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

5. Сообщение от Аноним (5), 09-Июн-21, 22:02	+15 +/–
Оригинально. Из категории идей, которые кажутся очевидными после того как кто-то обратит на них внимание. Но ещё больше удивило, что нашлось больше 40 тысяч сайтов, использующий один SSL-сертификат с FTP-серверами, от которых как казалось уже все кто можно отказался.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #8, #40

6. Сообщение от Аноним (104), 09-Июн-21, 22:13	+2 +/–
> ...при наличии контроля над сетевым шлюзом... > ...атакующий может разместить данные в сервисе... Простите, у вас там совсем <сосуд со множеством дырочек>?! С таким сосудом любая альпака - как мелкая шалость.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29, #102

7. Сообщение от СеменСеменыч777 (?), 09-Июн-21, 22:14	–8 +/–
ftp - дрянь-протокол, но зато его все знают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #22, #56

8. Сообщение от Аноним (8), 09-Июн-21, 22:28	–1 +/–
>>если FTP-сервер интерпретирует запрос как файл Очевидно? Мне не очевидно как мой браузер вдруг вместо HTTP начнёт говорить на языке FTP
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #15, #19

9. Сообщение от Аноним (8), 09-Июн-21, 22:30	+/–
С такими дырами хром может убирать из чёрного списка тот набор номеров портов, которые они захардкодили для защиты от NAT slipstreaming. Потому что по факту данная уязвимость как раз и обходит эту защиту, перенаправляя запрос с 443 на уязвимый порт.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #18

10. Сообщение от YetAnotherOnanym (ok), 09-Июн-21, 22:31	+/–
> использующим общие TLS-сертификаты > при наличии контроля над сетевым шлюзом или точкой беспроводного доступа А зачем мудрить с точкой доступа, если у атакующего уже есть "общие TLS-сертификаты" с имитируемым сервером?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12

11. Сообщение от Аноним (8), 09-Июн-21, 22:32	–1 +/–
Мораль: держите FTP, SMTP, IMAP и прочие сервисы на отдельных поддоменах со своими собственными сертификатами благо сейчас стало проще автоматизировать их обновление.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14, #23, #58, #63

12. Сообщение от Аноним (8), 09-Июн-21, 22:35	+2 +/–
Нет. Общие тут имеется в виду что есть например сайт и есть SFTP сервер, использующие общие сертификаты. Например yandex.ru и ftp.yandex.ru могли бы использовать общий условно *.yandex.ru сертификат. Атакующий при помощи точки доступа перенаправляет запрос вашего браузера с HTTPS на SFTP сервер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #13, #83, #85

13. Сообщение от Sw00p aka Jerom (?), 09-Июн-21, 22:43	+/–
>Атакующий при помощи точки доступа перенаправляет запрос вашего браузера с HTTPS на SFTP сервер. а дальше что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #26

14. Сообщение от Аноним (-), 09-Июн-21, 22:54	–2 +/–
не поможет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

15. Сообщение от Аноним (5), 09-Июн-21, 22:57	+2 +/–
Передавай внутри POST-данных любые команды FTP/SMTP/POP3/IMAP, предшествующие HTTP-заголовки просто игнорируются как ошибочные команды.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #21, #38

16. Сообщение от Sw00p aka Jerom (?), 09-Июн-21, 22:57	+2 +/–
митм форвардинг одного порта на другой, тут браузер будет думать, что подключается именно к 443.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

17. Сообщение от Аноним (17), 09-Июн-21, 22:59	–2 +/–
И никого не смутило: <при наличии контроля над сетевым шлюзом или точкой беспроводного доступа> т.е. ломаем шлюз (не суть как) и только потом манипулируем с перенаправлением.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24, #27, #28, #30, #33, #90

18. Сообщение от Аноним (5), 09-Июн-21, 23:01	+2 +/–
Интерес эта атака имеет больше теоретический, так как для проведения требуется MITM. Но авторы обещают на  USENIX Security Symposium раскрыть способ, работающий без MITM, а это уже совершенно другой уровень опасности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

19. Сообщение от Аноним (22), 09-Июн-21, 23:03	+/–
После того, как поддержку FTP убрали, для современного браузера все является HTTP.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

20. Сообщение от richman1000000 (ok), 09-Июн-21, 23:04	+/–
Да это просто тупость. Все об этой фигне знали. Много лет Суть в том что вы доверяете сертификату, который рассполагается у разных админов на разных службах.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #91

21. Сообщение от Sw00p aka Jerom (?), 09-Июн-21, 23:04	+/–
>Передавай внутри POST-данных любые команды написано же "Для успешной атаки злоумышленнику требуется затем каким-то образом извлечь сохранённое содержимое.", а каким - не сказано. Ибо так просто взять и отправить пост от имени bank.com не получится. Далее они предлагают, чтобы заманить жертву на подконтрольный левый сайт и там уже пытаться что-то сделать, но тут может не сработать из-за CORS. "Например, при открытии пользователем страницы, подконтрольной атакующим, с этой страницы может быть инициирован запрос ресурса с сайта, на котором у пользователя имеется активная учётная запись (например, bank.com)." Инициация этого запроса под вопросом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #44

22. Сообщение от Аноним (22), 09-Июн-21, 23:05	+2 +/–
Не забудьте то же самое сказать про email (SMTPS, POP3S, IMAPS).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #94, #96, #101

23. Сообщение от Аноним (22), 09-Июн-21, 23:07	+3 +/–
>  Мораль: держите FTP, SMTP, IMAP и прочие сервисы на отдельных поддоменах со своими собственными сертификатами благо сейчас стало проще автоматизировать их обновление. Полагаю, отказ от "сразу шифрованных" соединений в пользу STARTTLS тоже вполне прокатит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #25

24. Сообщение от Sw00p aka Jerom (?), 09-Июн-21, 23:07	+/–
на "лошарике" можно подплыть и к кабелю подключиться :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #43

25. Сообщение от Sw00p aka Jerom (?), 09-Июн-21, 23:08	–1 +/–
угу
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

26. Сообщение от Аноним (104), 09-Июн-21, 23:11	+1 +/–
SFTP футболит с ошибкой, попутно делая эхо этой ошибки, которая вовсе не ошибка, а нужные данные, переданные через POST. А твой наивный браузер всё это ловит и думает, что это ответ с bank.com и начинает выполнять скрипты в контексте bank.com.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #32

27. Сообщение от Аноним (5), 09-Июн-21, 23:12	+4 +/–
Реалии таковы, что точки беспроводного доступа и домашние маршрутизаторы дырявые как pешето, ломай не хочу. Или можно урожай собирать на выходных узлах Tor и создавая открытые wifi-сети.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #180

28. Сообщение от Аноним (104), 09-Июн-21, 23:13	+1 +/–
+ ещё и к сервису доступ, чтобы логи читать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

29. Сообщение от Аноним (29), 09-Июн-21, 23:13	+3 +/–
Ну вот взять вайфай, например. Даже запароленный. Владелец кафешки или отеля может атаковать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #34

30. Сообщение от онанимус (?), 09-Июн-21, 23:17	+1 +/–
а тебя не смущают миллионы admin:admin роутеров, торчащие голой жопой в интернет? и всякие захардкоденные аккаунты "oelinux123" на случай, если дофига умный лаовай сменит дефолтный пароль?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #114, #181

31. Сообщение от Kuromi (ok), 09-Июн-21, 23:20	–4 +/–
FTP? Ну очень вовремя,особенно на фоне полного удаления поддержки этого протокола из браузеров. Кроме того, FTPS вообще всегда был изрядной редкостью.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #59, #121

32. Сообщение от Sw00p aka Jerom (?), 09-Июн-21, 23:24	+/–
> SFTP футболит с ошибкой, попутно делая эхо этой ошибки, которая вовсе не > ошибка, а нужные данные, переданные через POST. А твой наивный браузер > всё это ловит и думает, что это ответ с bank.com и > начинает выполнять скрипты в контексте bank.com. так так, а как открывается контекст с bank.com?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #35

33. Сообщение от MPEG LA (ok), 09-Июн-21, 23:26	+3 +/–
Там прямо в заголовке написано: MITM.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

34. Сообщение от Аноним (104), 09-Июн-21, 23:27	+3 +/–
> FTP-сервер ... журналирует входящие запросы. Для успешной атаки злоумышленнику требуется затем каким-то образом извлечь сохранённое содержимое. ... каким-то образом попасть на FTP-сервер. Да каждый владелец кафешки имеет доступ на сервер твоего банка!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #89

35. Сообщение от Аноним (104), 09-Июн-21, 23:30	+/–
Твой браузер и открывает, только запрос немного не туда уходит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #39, #41

36. Сообщение от Онаним (?), 09-Июн-21, 23:34	–2 +/–
Нереал. Тчк. Протоколы настолько между собой несовместимы, что подставить ложный ответ без модфикации софта на сервере не получится. А если есть такой доступ - собственно уже все ключи сертификатов есть, и не надо извращаться.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37

37. Сообщение от Онаним (?), 09-Июн-21, 23:37	+3 +/–
Если кто невдогнал, то: 1. "Upload": для успешной атаки злоумышленнику требуется затем каким-то образом извлечь сохранённое содержимое. Ключевое слово - "каким-то". Давай, до свидания. 2. "Download": атакующий в результате каких-то отдельных манипуляций может разместить данные в сервисе - ага, да ещё так, чтобы они вместе с обёрткой исходный протокол сымитировали. "Каких-то" - ключевое слово. Давай, до свидания. 3. Метод основан на возвращении клиенту части запроса, в котором содержится отправленный атакующим JavaScript-код. Вот только проблемка, снова надо в протокольчик обернуть. Туда же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #42, #45, #86, #187

38. Сообщение от Онаним (?), 09-Июн-21, 23:38	+/–
Не совсем так. После X ошибочных команд обычно что клиент, что сервер - дисконнектятся. Не у всех есть такая защита, но мы говорим о серверах (раз POST) - там она в большинстве случаев есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

39. Сообщение от Онаним (?), 09-Июн-21, 23:39	–2 +/–
И сбрасывается, потому что protocol violation.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

40. Сообщение от Онаним (?), 09-Июн-21, 23:41	+/–
Точнее - из категории идей, про которые все давно знают (без шифрования это таки было ещё проще) и давно уже перестрахованы где надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

41. Сообщение от Sw00p aka Jerom (?), 09-Июн-21, 23:42	+/–
> Твой браузер и открывает, только запрос немного не туда уходит. хмммммммммм Условия: 1) evil.com страничка замануха атакующего. 2) атакующий может делать митм и перенаправлять соединения bank.com:443 -> mx.bank.com:465 (postfix tls wrapper mode) и собственно в обоих случаях используется вайлдкард tls сертификат *.bank.com Атака: 1) Жертва переходит на страничку evil.com 2) В контексте странички evil.com пытаемся инициировать отправку POST запроса с пейлоадом на bank.com:443 3) В момент инициации необходимо перенаправить прозрачно соединение с bank.com:443 на mx.bank.com:465 4) В итоге mx.bank.com:465 вернет наш пейлоад, и исполнит его в контексте bank.com, а пейлоад может тупо украсть сессионные куки самого bank.com и отправить на evil.com. Вопрос такой, второй шаг возможен разве? CORS позволит это проделать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #48

42. Сообщение от vitalif (ok), 09-Июн-21, 23:46	+6 +/–
Я нашел уязвимость в замке входной двери! Если злоумышленник каким-то образом зайдет внутрь квартиры и вынесет оттуда запасной ключ, то замок можно будет легко открыть извне!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

43. Сообщение от Аноним (43), 09-Июн-21, 23:46	+/–
ха)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

44. Сообщение от Аноним (8), 09-Июн-21, 23:48	+/–
Каким-то образом извлечь данные это понятно как. Запрос из браузера идёт на FTP сервер и там сохраняется в виде файла. Дальше файл уже можно скачать если это позволено настройками FTP сервера. У меня вопрос как заставить браузер послать нужный запрос. Это выходит надо на страницу банка сперва что-то заинжектить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #47, #50

45. Сообщение от Sw00p aka Jerom (?), 09-Июн-21, 23:49	+1 +/–
> Вот только проблемка, снова надо в протокольчик обернуть. Туда же. ну да, ток не понятно как у них вот это работает 220 1237cfa6400d ESMTP Postfix HELO example.com 250 1237cfa6400d MAIL FROM: example <script>alert(1);</script> 555 5.5.4 Unsupported option: <script>alert(1);</script>
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #46, #53, #54

46. Сообщение от Онаним (?), 09-Июн-21, 23:55	+/–
Только на говносерверах, которые отдают невалидированные данные. Dovecot и Exchange мимо, остальные в топку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #141

47. Сообщение от Sw00p aka Jerom (?), 09-Июн-21, 23:57	+/–
> Каким-то образом извлечь данные это понятно как. Запрос из браузера идёт на > FTP сервер и там сохраняется в виде файла. Дальше файл уже > можно скачать если это позволено настройками FTP сервера. с каких пор фпт будет понимать хттп-ешный запрос и еще умудриться это сохранить в виде файла? я могу только в логах фтп увидеть некорректные команды в виде хттп запроса в которых вероятно и кукисы засветятся > У меня вопрос как заставить браузер послать нужный запрос. Это выходит надо > на страницу банка сперва что-то заинжектить. инжектить не нужно, можно же заманить человека на evil.vom а там уже можно тупо допустим прописать <img src="https://bank.com"> и браузер инициирует запрос на bank.com:443. Но нам же нужен пейлоад, а для этого нужно всякие post запросы формировать и чтобы браузер это еще и инициировал в контексте bank.com:443. CORS куда смотреть будет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #104

48. Сообщение от Аноним (104), 09-Июн-21, 23:59	+1 +/–
Да и да. Некоторые запросы не заставляют срабатывать CORS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #60

49. Сообщение от Alexey (??), 10-Июн-21, 00:03	–1 +/–
Простите в чём суть атаки - в контроле над шлюзом? А как на счёт в контроле над провайдером.. или выше..
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #51, #52, #92

50. Сообщение от Аноним (50), 10-Июн-21, 00:07	+/–
В статье же расписано как заставить послать - заставить зайти на свою страницу и с неё инициировать запрос к цели.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #139

51. Сообщение от Аноним (51), 10-Июн-21, 00:07	+/–
Магистальные провайдеры давно беспардонно вмешиваются в трафик. Про местячковых я бы особо не переживал -- ты им деньги несёшь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

52. Сообщение от Онаним (?), 10-Июн-21, 00:08	+/–
Суть атаки - в попытке с самого клиента послать то, что хочется получить в ответ той софтиной, откуда послано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #71

53. Сообщение от Онаним (?), 10-Июн-21, 00:10	+1 +/–
Ну и блин, браузер, который это отобразит - надо закапывать первым. Потому что перед <script>...</script> должны быть HTTP/1.1 200 OK, корректные хедеры, и двойной CRLF.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #67

54. Сообщение от Онаним (?), 10-Июн-21, 00:11	+/–
Короче, то, что они смогли <script> выдать - ещё не значит, что он где-то обработается. О чём и речь. Свистопляска вокруг потенциальной шкуры сферического медведя Шрёдингера в вакууме.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

55. Сообщение от Аноним (56), 10-Июн-21, 00:15	+1 +/–
А кто-то ещё пользуется браузерами для работы с почтой и разрешёнными скриптами?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #62

56. Сообщение от Аноним (56), 10-Июн-21, 00:16	+6 +/–
FTP отличный протокол. Это руки дрянь у тех кто его не осилил и везде всунул HTTP
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #57, #93

57. Сообщение от Аноним (22), 10-Июн-21, 00:19	–11 +/–
Попробуйте запостить этот же комментарий через FTP, а то как-то голословно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #64, #100

58. Сообщение от Аноним (56), 10-Июн-21, 00:19	+3 +/–
Мораль не пользовать браузер
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #131

59. Сообщение от Аноним (56), 10-Июн-21, 00:21	+1 +/–
Твой любимымй гавняный HTTP там первый в списке
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

60. Сообщение от Sw00p aka Jerom (?), 10-Июн-21, 00:23	+/–
> Да и да. Некоторые запросы не заставляют срабатывать CORS. ok, ясно, а как же быть с protocol violation, когда браузер ожидает HTTP/1.1 200 OK но в замен получает нечто такое 220 1237cfa6400d ESMTP Postfix HELO example.com 250 1237cfa6400d MAIL FROM: example <script>alert(1);</script> 555 5.5.4 Unsupported option: <script>alert(1);</script>
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #65

61. Сообщение от deeaitch (ok), 10-Июн-21, 00:23	+1 +/–
Хаха. Хвалёный HTTPS
Ответить | Правка | Наверх | Cообщить модератору

62. Сообщение от deeaitch (ok), 10-Июн-21, 00:24	+1 +/–
iPony и Fracta1L
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

63. Сообщение от deeaitch (ok), 10-Июн-21, 00:26	+2 +/–
Мораль в том что FTP, SMTP, IMAP оказались совершенно не причём. А проблема вылезла вообще в HTTPS и браузерах. У нормальных людей через ftp, smtp, imap javascript не выполняется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

64. Сообщение от deeaitch (ok), 10-Июн-21, 00:29	+7 +/–
А ты стрелки не переводи. FTP не для того чтобы коменты постить и javascript запускать. А для передачи фалов. И сравляется он с этим куда лучше HTTP и/или HTTPS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #69, #88, #103

65. Сообщение от Sw00p aka Jerom (?), 10-Июн-21, 00:34	+/–
> ok, ясно, а как же быть с protocol violation, когда браузер ожидает можете не отвечать, Internet Explorer - ясно все, удивляться нечему. Is my browser/client vulnerable? Internet Explorer and Edge Legacy (i.e., those not based on Chrome) are "more" vulnerable than other browsers, because they block fewer ports and perform content-sniffing. Content-sniffing is dangerous, because it enables JavaScript code execution in server responses that are noisy due to error messages by the application server that implements a protocol different from HTTP. This means that the pure web attacker variant of ALPACA is more dangerous for users of such browsers than for other users. However, no browser protects the user against all possible ALPACA attacks. In particular, all browsers can be compromised by a Man-in-the-Middle attacker who has write-access to an error-tolerant FTP server presenting a certificate compatible with a target web server under attack. Although the FTP server can in theory protect against this particular attack by detecting HTTP POST requests and/or terminating the connection after a small number of errors, this attack variant shows that this is not a bug in the browser, the web server, or the application server, but an emergent property of the TLS landscape.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #80

66. Сообщение от adsh (ok), 10-Июн-21, 00:34	+1 +/–
Какой ещё SFTP - это часть SSH, речь об FTPS.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #68

67. Сообщение от Sw00p aka Jerom (?), 10-Июн-21, 00:36	+/–
> Ну и блин, браузер, который это отобразит - надо закапывать первым. Internet Explorer - может все :) в оригинале статьи все расписано и все вопросы отпадают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

68. Сообщение от deeaitch (ok), 10-Июн-21, 00:51	+/–
Ну кто-же читает?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

69. Сообщение от Stax (ok), 10-Июн-21, 01:11	+10 +/–
О дааа.. Одна проблема с буквой "я" чего стоит, а про классику в виде отсутствия понятия кодировки имен файлов (и невозможности договориться о ней), работу через два независимых порта, что создает свои неприятности (ну-ка попробуйте с пол-тычка завернуть ftp в ssh туннель, аналогично http) и неопределенность даты файлов уж и не говорим..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #75, #125, #213

70. Сообщение от BrainFucker (ok), 10-Июн-21, 01:34	–2 +/–
> перенаправить на почтовый сервер, в котором используется общий с bank.com TLS-сертификат. Ага, только для этого нужно ещё захватить контроль над этим почтовым сервером. Только причём тут высосанная из пальца "уязвимость" в TLS, когда для реализации требуется захват контроля надо сервером?
Ответить | Правка | Наверх | Cообщить модератору

71. Сообщение от Alexey (??), 10-Июн-21, 02:34	+/–
В наших условиях это сервисная функция ПО стоящего за HTTP, судя по возможностям закладываемых при программировании как клиентов, так и серверов. Будут "чудесней" программировать, будет "чудастей" результат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

72. Сообщение от Аноним (72), 10-Июн-21, 03:11	+/–
"We could confirm that this is indeed the case for Internet Explorer and Edge Legacy, while all other tested browsers do not perform content-sniffing and thus do not execute JavaScript in noisy responses." Атаковать MSIE есть способы и попроще :)
Ответить | Правка | Наверх | Cообщить модератору

73. Сообщение от Аноним (73), 10-Июн-21, 03:36	+/–
Про эту уязвимость знали уже давно, поэтому и убралли ftp mixed content еще год назад
Ответить | Правка | Наверх | Cообщить модератору

75. Сообщение от Аноним (164), 10-Июн-21, 05:14	+/–
FXP покажи через http.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #108, #214

76. Сообщение от Аноним (73), 10-Июн-21, 06:39	+/–
https://www.cisco.com/c/dam/global/ru_ru/training-events/202...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #77

77. Сообщение от Аноним (77), 10-Июн-21, 07:00	+/–
Только все упомянутые в той презентации методы "взлома" TLS сводятся к фразе "Устанавливаем корневой сертификат на клиентское устройство". Там описано как получить доступ к TLS-трафику имея полный контроль над инфраструктурой и всеми рабочими станциями. Это для организации сканирования трафика на предприятиях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #78

78. Сообщение от Аноним (73), 10-Июн-21, 07:14	+/–
https://media.defense.gov/2019/Dec/16/2002225460/-1/-1/0/INFO SHEET%20 MANAGING RISK FROM TRANSPORT LAYER SECURITY INSPECTION.PDF
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

79. Сообщение от kusb (?), 10-Июн-21, 08:25	+/–
Смекалочка. Люблю хакеров.
Ответить | Правка | Наверх | Cообщить модератору

80. Сообщение от Онаним (?), 10-Июн-21, 09:05	+/–
Тут правильнее было написать "no browser protects the user against all possible attacks" И ведь не поспоришь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

81. Сообщение от Онаним (?), 10-Июн-21, 09:07	–3 +/–
Ещё одну вишенку на торте забыли. Если обсуждать применение из браузера, то чтобы отправить что-то из выданного сайтом кода на соседний порт того же сервера - надо сначала каким-то образом вклиниться в выданный сайтом код, собственно. Любители тянуть кучу чужого говна с CDN'очек могут пострадать, конечно, но так им и надо.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #82

82. Сообщение от Онаним (?), 10-Июн-21, 09:09	+/–
Ну и да, если мы уже вклинились в выданный сайтом код - на хрена нам эта "атака" для вклинивания? :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #84

83. Сообщение от YetAnotherOnanym (ok), 10-Июн-21, 09:16	–2 +/–
> Нет. Общие тут имеется в виду что есть например сайт и есть > SFTP сервер, использующие общие сертификаты. Например yandex.ru и ftp.yandex.ru могли > бы использовать общий условно *.yandex.ru сертификат. Атакующий при помощи точки доступа > перенаправляет запрос вашего браузера с HTTPS на SFTP сервер. В любом случае, предполагается, что у атакующего есть закрытый ключ, соответствующий этому сертификату. С ним можно сделать что угодно просто подняв свой веб-сервер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #120

84. Сообщение от Аноним (73), 10-Июн-21, 09:38	+/–
Кто на куче рекламмы сидит им вообще пофиг ломают их или нет, главное бабло да и ваши данные продадут
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #117

85. Сообщение от hefenud (ok), 10-Июн-21, 09:50	+2 +/–
Ванька путает ftp и sftp? Ванька не знает, что это разные протоколы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

86. Сообщение от дауненок (?), 10-Июн-21, 09:54	+/–
shared-хостинги и дыры в них вот это вот отлично включают, т.е. это утилитарная атака, дополняющая уже существующие дыры и их расширяющая
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #87

87. Сообщение от Онаним (?), 10-Июн-21, 09:55	–1 +/–
Тот случай, когда никнейм соответствует персонажу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

88. Сообщение от anonymous (??), 10-Июн-21, 10:18	+4 +/–
И делает он это слишком сложно. Например делать дополнительное соединение,  чтобы передать данные -- это вызывает огромное количество неполадок при использовании FTP.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #127

89. Сообщение от anonymous (??), 10-Июн-21, 10:21	+2 +/–
Доступ на FTP бывает и анонимным. А роутер кафешки может быть уже взломан каким-то другим злоумышленником.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #98

90. Сообщение от Аноним (90), 10-Июн-21, 10:24	+/–
Не смутило: 1. Об MITM написано аж в заголовке статьи. 2. Куча дырявых роутеров вокруг или роутеров с admin/admin (что равносильно дырявости). 3. Атакующий может быть тем самым настоящим провайдером "точки беспроводной связи": кафешка / гостиница / etc. со своей точкой доступа. И ничего ломать не надо. 3.2. да ты сам можешь в кафешке или рядом сесть, включить раздачу вайфая с именем сети Free WiFi (или даже название кафешки вписать) и ловить всех подключившихся. Короче, тут куча вполне себе реальных прикладных сценариев.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #95

91. Сообщение от anonymous (??), 10-Июн-21, 10:25	+/–
Почему "у разных админов"? Проблема не в "разных админах", а в том, что админ рассматривает HTTP и FTP -- как две независимых службы, которые друг на друга не влияют и не вредят. Что позволяет открыть анонимный доступ на FTP, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

92. Сообщение от anonymous (??), 10-Июн-21, 10:28	+1 +/–
Никогда не пользовались WiFi в кафешке или аэропорту?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #132, #142

93. Сообщение от Аноньимъ (ok), 10-Июн-21, 10:53	+3 +/–
Ужасный он. Использует нетривиальную схему соединений вместо одного  TCP стрима. Из за чего его ненавидели уже 20лет назад. Фаерволить подобное сущий ад.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #97

94. Сообщение от Аноньимъ (ok), 10-Июн-21, 10:56	–1 +/–
"Почтовые" протоколы дрянь и ужас. К ним же в кучу nfs3 и всякие сипы и прочие аудио видео звонки которым не хватает одного соединения на один порт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #105

95. Сообщение от Аноньимъ (ok), 10-Июн-21, 11:05	+/–
>Атакующий может быть тем самым настоящим провайдером "точки беспроводной связи": кафешка / гостиница / etc. со своей точкой доступа. И ничего ломать не надо. Ну или просто обычный провайдер, любой проводной или безпроводной.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

96. Сообщение от Moomintroll (ok), 10-Июн-21, 11:16	+/–
> Не забудьте то же самое сказать про email (SMTPS, POP3S, IMAPS). У SMTP, POP3 и IMAP есть STARTTLS, с которым этот фокус не пройдёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

97. Сообщение от нах.. (?), 10-Июн-21, 11:18	–1 +/–
Contrack не пробывал, не?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #111, #126, #129

98. Сообщение от Q2W (?), 10-Июн-21, 11:29	+7 +/–
Анонимный FTP под сертификатом твоего банка? Это про сбербанк что ли?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #196

99. Сообщение от Егор (??), 10-Июн-21, 11:39	–1 +/–
А не удалили бы www - такой бы фигни не было.
Ответить | Правка | Наверх | Cообщить модератору

100. Сообщение от hshhhhh (ok), 10-Июн-21, 11:42	+/–
ну через telnet на bbs сидели, а то целый фтп!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #123

101. Сообщение от СеменСеменыч777 (?), 10-Июн-21, 11:42	+1 +/–
> Не забудьте то же самое сказать про email (SMTPS, POP3S, IMAPS). не согласен как минимум про первых два и отчасти про imap. во-первых используется один порт и одно соединение (а не два навстречу друг другу). дальше продолжать ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

102. Сообщение от hshhhhh (ok), 10-Июн-21, 11:43	+/–
> Простите, у вас там совсем <сосуд со множеством дырочек>?! так в этом же и суть MiTM атак?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

103. Сообщение от СеменСеменыч777 (?), 10-Июн-21, 11:44	–1 +/–
>  А для передачи фалов. фаллов. и даже местами фаллловъ (чтобы выглядели подлиннее и потверже).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #128

104. Сообщение от Аноним (104), 10-Июн-21, 11:51	+/–
> CORS куда смотреть будет? Никуда. Есть запросы, на которые он не реагирует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #116

105. Сообщение от Аноним (105), 10-Июн-21, 11:54	+7 +/–
>  всякие сипы и прочие аудио видео звонки которым не хватает одного соединения на один порт. Итак давай представим себе ситуацию, что есть группа людей из 4-х человек, которые общаются в голосовом/видео чате. Первый второму перекидывает файл, третий пишет им всем сообщения, а четвертый слушает что они все говорят, находясь в мобильной сети, переключаясь между wcdma/hsdpa/hspa+/lte сетями, потому что едет в машине. Ну так вот потом четвертый пришел домой и попал в Wi-Fi сеть и тут же добавил в разговор пятого. Вот для организации всего этого достаточно SIP в сочетании с теми протоколами, которые идут вместе с ним =) А теперь, умник, попробуй мне построить то же самое на клиент-серверной сети с одним соединением на порт. Я посмотрю на тебя. Было уродство под названием XMPP, да сплыло, когда оказалось, что нужно 80% SIP портировать в него чтобы голос добавить. Вот и получился XMPP Jingle, который сдох. Пиринговая сеть рядышком с клиент-серверным XMPP, и, нет, через один порт не получилось. Ни у кого не получится. Дрянь и ужас - это уровень твоего образования. Тех у кого нет жизни вне одной клиент-серверной TCP-сессии лучше держать подальше от проектирования протоколов. И если внутри FTP еще можно было бы как-то обойтись, то медиа... А что НЕ "дрянь и ужас", я стесняюсь спросить? Ну кроме HTTP. Или только на вебне жить прикажешь? Ой. А как же в этой самой вебне делается медиа? Ты не поверишь. ICE+SDP+STUN+TURN+SRTP поверх вебсокетов, которые идут "вторыми" портами. Ой всё...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #110, #137

106. Сообщение от КО (?), 10-Июн-21, 12:32	+1 +/–
Куки не храним, JS блокируем. Куета.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #109

107. Сообщение от andrey (??), 10-Июн-21, 12:33	+/–
<script>alert(1);</script> ничего в этом мире не меняется и вот опять :)
Ответить | Правка | Наверх | Cообщить модератору

108. Сообщение от Annoynymous (ok), 10-Июн-21, 12:35	–2 +/–
FXP покажи через ftp, шутник.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #140

109. Сообщение от Аноним (109), 10-Июн-21, 12:46	–1 +/–
>JS блокируем. К сожалению, в окне браузера может оказаться пусто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

110. Сообщение от Аноньимъ (ok), 10-Июн-21, 12:55	–4 +/–
>умник Спасибо. >попробуй мне >Я посмотрю на тебя >Дрянь и ужас - это уровень твоего образования Мне это саморазоблачение ненужно в общем комментировать. >Ой. А как же в этой самой вебне делается медиа? Ты не поверишь. ICE+SDP+STUN+TURN+SRTP поверх вебсокетов, которые идут "вторыми" портами Да, это дрянь и ужас абсолютная, тут разве что согласен. >XMPP Смешались люди кони у вас в кучу одну.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #115

111. Сообщение от Аноньимъ (ok), 10-Июн-21, 12:59	+/–
?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

112. Сообщение от Аноним (112), 10-Июн-21, 13:09	+1 +/–
>В ходе MITM-атаки этот запрос, адресованный web-сайту bank.com, можно перенаправить на почтовый сервер, в котором используется общий с bank.com TLS-сертификат Минуточку, т.е. вам нужен рутовый доступ к самому серверу, чтобы на нём перенастроить скажем SMTP и выдавать вредоносный код вместо ошибки... Вопрос, зачем вообще вся эта чушь, когда подразумевается, что у атакующего уже есть полный доступ к серверу на котором есть нужные сертификаты? зачем доступ к шлюзу, если можно прямо на сервере порт форварднуть... да блин, доступ уже рутовый, зачем весь этот бред, в чём вообще суть атаки?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #113, #136, #165

113. Сообщение от Аноним (112), 10-Июн-21, 13:12	+/–
P.S. ощущение, что кто-то шикарно пошутил...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

114. Сообщение от Ненавижу SJW (?), 10-Июн-21, 13:40	+/–
И что из этого можно поиметь? Как я понимаю это же скорее всего домашний роутер тарчит, а за ним пару хостов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #118

115. Сообщение от Просто (?), 10-Июн-21, 13:51	+1 +/–
Если ты осуждаешь реализации с множеством соединений, значит у тебя есть рабочие кейсы с одним на все? Есть реализации? Есть что предложить? Рабочее, для всего медиа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #135

116. Сообщение от Урри (ok), 10-Июн-21, 14:18	+1 +/–
CORS вообще одна сплошная профанация.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

117. Сообщение от Аноним (-), 10-Июн-21, 14:33	+/–
bank.com под замком, заходить - ишаком, станешь битым мужиком, а не - просто му-ком
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

118. Сообщение от авыыва (?), 10-Июн-21, 14:49	+/–
А за домашним рутером сидит какой нить инженер из конторы ABB. Оппа и тейковер какой-то электростанции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #122

119. Сообщение от gogo (?), 10-Июн-21, 14:53	+/–
Прикольно. Но ни один банк не делает голых html интернет-банкингов и не рекомендует пользователям отключить яваскрипт. Ибо программисты работы лишатся. Ведь реально скрипты там нах не нужны...
Ответить | Правка | Наверх | Cообщить модератору

120. Сообщение от Аноним (8), 10-Июн-21, 14:56	+3 +/–
Нет, ключ от сертификата тут не нужен. Атакующий не вмешивается в сам трафик, не читает его и не видоизменяет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83

121. Сообщение от Аноним (8), 10-Июн-21, 14:57	+/–
Для этой атаки не нужна поддержка FTP в браузере. После удаления ФТП браузер всё так же остаётся уязвим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #208

122. Сообщение от Ненавижу SJW (?), 10-Июн-21, 15:02	+/–
А если серьёзно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #215

123. Сообщение от СеменСеменыч777 (?), 10-Июн-21, 15:42	+/–
> ну через telnet на bbs сидели, а то целый фтп! было дело. но я уже забыл как там фаллы и ваагины передавали. то ли клиент telnet запускал ZModem и отдавал ему поток, то ли как-то еще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

124. Сообщение от pavlinux (ok), 10-Июн-21, 15:44	+1 +/–
> Суть атаки в том, что при наличии контроля над сетевым шлюзом или точкой беспроводного доступа ... Опять рут нужен?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #130

125. Сообщение от deeaitch (ok), 10-Июн-21, 15:55	+/–
> О дааа.. Именно, да. > Одна проблема с буквой "я" чего стоит, а про классику > в виде отсутствия понятия кодировки имен файлов (и невозможности договориться о > ней), Интересно, почему у меня нет этой проблемы? А? Может маны почитать не? > работу через два независимых порта, что создает свои неприятности А почему у меня работает через 1? Магия? > (ну-ка > попробуйте с пол-тычка завернуть ftp в ssh туннель, аналогично http) sftp это не ftp с ssl. Это на секунду часть ssh и заводится на ура с пол оборота. Но мы же iPony style, неосиляторы. > и > неопределенность даты файлов уж и не говорим.. Откуда вы берёте все эти проблемы. Десятилетиями весят публичные репозитории и ни у кого нет проблем. Одни только неосиляторы ноют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #185, #202

126. Сообщение от СеменСеменыч777 (?), 10-Июн-21, 15:56	+3 +/–
> Contrack не пробывал, не? https://www.opennet.dev/opennews/art.shtml?num=54058 https://www.opennet.dev/opennews/art.shtml?num=54480 анона-фанатика SIP выше по треду тоже касается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

127. Сообщение от deeaitch (ok), 10-Июн-21, 15:57	–6 +/–
> И делает он это слишком сложно. Например делать дополнительное соединение,  чтобы > передать данные -- это вызывает огромное количество неполадок при использовании FTP. Эпичные неосиляторы, когда же вы научитесь доки читать. Нормально ходит и через один порт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #211

128. Сообщение от deeaitch (ok), 10-Июн-21, 15:58	–2 +/–
>>  А для передачи фалов. > фаллов. и даже местами фаллловъ (чтобы выглядели подлиннее и потверже). Это чтобы неосиляторам было чем перед дефачками хвастаться. Своего то тю....
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

129. Сообщение от СеменСеменыч777 (?), 10-Июн-21, 15:59	+/–
вот на этот коммент особое внимание https://www.opennet.dev/openforum/vsluhforumID3/122380.html#119
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #138, #157

130. Сообщение от Аноним (-), 10-Июн-21, 16:25	+1 +/–
да, но теперь знаем зачем рут (и всякие *.* серты)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124

131. Сообщение от Nefrace (?), 10-Июн-21, 16:50	+/–
Как же вы тогда оправили это сообщение сюда?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

132. Сообщение от Alexey (??), 10-Июн-21, 16:52	+/–
Нет ни чего нового в данной атаке, если им нужно захватить контроль над сегментом. С таким же успехом "мамкин хакер" расшаривает свой wifi дома.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #197

134. Сообщение от Аноним (136), 10-Июн-21, 18:10	+1 +/–
Так, стоп! Какой FTP? Его еще несколько лет назад обещали "выпилить" из браузеров! Если его поддержки нет в браузере - как он может что то там куда то отправлять, по протоколу "ftp://" ? 😨
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #147

135. Сообщение от n00by (ok), 10-Июн-21, 18:13	+1 +/–
Просто надо задаться вопросом: а что такое "порт"? ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

136. Сообщение от Аноним (136), 10-Июн-21, 18:13	+2 +/–
>доступ уже рутовый, зачем весь этот бред, в чём вообще суть атаки? Ну, типа для того, что бы манагерам пришла мысль, у админов отобрать еще больше прав! А то будут перехватывать чужие куки на почтовом сервере!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

137. Сообщение от Аноньимъ (ok), 10-Июн-21, 18:52	+1 +/–
Пример протокольного Ада: https://www.opennet.dev/opennews/art.shtml?num=54058 https://www.opennet.dev/opennews/art.shtml?num=54480
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #154

138. Сообщение от Аноньимъ (ok), 10-Июн-21, 18:55	+/–
> вот на этот коммент особое внимание > https://www.opennet.dev/openforum/vsluhforumID3/122380.html#119 В коменте пишут, что производители роутеров ленивые. Я думаю дело не просто в том, что ленивые, а в том, что это реально сложно, особенно для бытовых железок с ограниченной памятью и железом. И опять таки встаёт вопрос совместимости с обратной стороны софта, который уже вероятно ожидает конкретную реализацию ната. Ну и не только в НАТе дело, попробуйте такого монстра протокольного банально разрешить или запретить в фаерволле. А так да, протокольный Ад хорошо описан.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #155

139. Сообщение от Annoynymous (ok), 10-Июн-21, 19:52	–2 +/–
И как-то случайно моя страница будет подписана тем же сертификатом, что и FTP сервер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #150

140. Сообщение от Аноним (164), 10-Июн-21, 20:15	+/–
rfc959 пункт 2.3.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #143

141. Сообщение от penetrator (?), 10-Июн-21, 20:16	+/–
я вот тоже нехрена не понял у меня есть 3 сервиса на разных портах, например SMTP, POP3, HTTP все на одном домене, и на одном и том же сертификате каким образом можно скормить браузеру ответ от моего SMTP сервера? ну он же не сожрет это, потому что протокол невалидный, несовместимые команды не? я что-то не понял?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

142. Сообщение от Онаним (?), 10-Июн-21, 20:45	+/–
Нет :D Кроме того, к внедрению в чужой трафик это отношения не имеет. Там суть в получении назад кусков отправленного запроса, который в теории позволил бы CORS обойти. Но толку нет, потому что чтобы запрос отправить - надо УЖЕ внедриться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

143. Сообщение от Annoynymous (ok), 10-Июн-21, 21:32	–2 +/–
> rfc959 пункт 2.3. Ты б ещё на man сослался, как его включить. Только его никто не включает. Угадаешь, почему?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #144, #199

144. Сообщение от Аноним (164), 10-Июн-21, 21:48	+/–
Да я сразу понял что ты афедроном повертеть сюда зашёл. Не надо было это лишний раз доказывать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #146

146. Сообщение от Annoynymous (ok), 10-Июн-21, 22:03	–2 +/–
Ну ты сразу понял, что был неправ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #200

147. Сообщение от pavlinux (ok), 10-Июн-21, 22:08	+/–
> Так, стоп! Какой FTP? > Его еще несколько лет назад обещали "выпилить" из браузеров! > Если его поддержки нет в браузере - как он может что то > там куда то отправлять, по протоколу "ftp://" ? > 😨 https://github.com/sergi/jsftp
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134

148. Сообщение от anonymous (??), 10-Июн-21, 23:41	+/–
>на другой сетевой порт и организовать установку соединения с FTP или почтовым сервером, поддерживающими TLS-шифрование и использующими общий с HTTP-сервером TLS-сертификат Никак не вкурю, у атакующего должен быть тру сертификат http сервера или он может свой подпихнуть? Если первое, то в чем проблема. Имея серт и так с трафиком можно обращаться как с не зашифрованным.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #149

149. Сообщение от Аноним (104), 10-Июн-21, 23:45	+/–
у атакующего никакого серт-а нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #151, #152

150. Сообщение от Аноним (104), 11-Июн-21, 00:05	+/–
перечитай статью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

151. Сообщение от anonymous (??), 11-Июн-21, 00:47	+1 +/–
Спасибо Анон, перечитал и с твоим комментом вкурил. Пусть Джа тебе только внятные маны заворачивает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149

152. Сообщение от Аноним (112), 11-Июн-21, 01:59	+2 +/–
А на сервере, который будет принимать соединение и выдавать вредоносный код, от куда тогда сертификат должен взяться? Хватит людей путать - вся эта атака полная чушь, подразумевающая, что админ должен профукать сертификат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #153, #166

153. Сообщение от anonymous (??), 11-Июн-21, 02:14	+1 +/–
>т куда тогда сертификат должен взяться? И я не пойму, держатель серта в любом случае контралирует траффик
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152

154. Сообщение от Аноним (105), 11-Июн-21, 02:33	–1 +/–
Сразу видно что ты новости читать умеешь, а про что они написаны не знаешь. Не имел дело, видимо... Специально для таких как ты я подробно объяснял в чем там проблема. Открой каждую из этих новостей и в комментах найди гигантскую телегу (моё авторство) с объяснением о проблемах ALG и что оно не имеет никакого отношения к стандартам SIP. Это истории про отсутствие стандартов на NAT и как неосиляторы-сетевики не могут ни черта сделать дальше TCP-сессии. Готовься. Надвигается QUIC-транспорт, не HTTP/3 а именно QUIC, смотри не перепутай. Он уже есть, но будет больше. Оно выглядит как один порт, но там куча разномастных данных внутри UDP-потока. Ох чую неграмотные сетевики, горя хапнут снова. Черновики на RTP over QUIC уже публиковали вроде бы. И чем больше ты будешь узнавать, работать, понимать тем больше тебе будет мешать твоя категоричность вокруг протоколов. Избавься от нее до того как диплом сдашь. Проще будет =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #156, #164

155. Сообщение от Аноним (105), 11-Июн-21, 03:07	+/–
> Я думаю дело не просто в том, что ленивые, а в том, что это реально сложно, особенно для бытовых железок с ограниченной памятью и железом. Обыкновенный SIP-телефон стоит не сильно дороже роутеров и памяти в нём меньше, а половину цены составляют лицензии на всякие кодеки G729 и прочий проприетарный AMR. Так что враки. > И опять таки встаёт вопрос совместимости с обратной стороны софта, который уже вероятно ожидает конкретную реализацию ната. Совместимость может быть только со стандартами. Ни у NAT, ни у ALG нет стандарта. Они все вендороспецифичные и не совместимые друг с другом. Но ты этого не знаешь, потому что для того чтобы увидеть насколько хреново сделан NAT нужно воспользоваться чем-то сложнее клиент-серверной TCP-сессии. А у тебя проблема в стиле все что не могу зафаерволить с натом всё плохое. > Ну и не только в НАТе дело, попробуйте такого монстра протокольного банально разрешить или запретить в фаерволле. Этот протокол так устроен, потому что его вечно ломают косорылые бараны, которые по ошибке называют себя сетевыми администраторами. Запретить его можно только если он нешифрованый. TLS для сессий и DTLS для медиа и плакала ваша блокировка фаерволом, разве что "по IP вычислять". По DPI можете точечно гадать по хостнеймам в сертификатах. Опять же удачи с TLS1.3 и ESNI. А разрешить его клиентам просто берёте и просто выключаете ALG. На внешний современный SIP-сервер ваши клиенты подключатся из-под любого ната. А свой сервак "прокидывать" не рекомендую, лучше сразу обратитесь к системному администратору.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #159

156. Сообщение от Аноньимъ (ok), 11-Июн-21, 03:35	+2 +/–
Чел, мне твои индюшачии петушения ни к чему. У тебя серьезные проблемы с чувством собственной важности. Меня сокращения из 3х и 4х букв не пугают и не впечатляют, это элементарные вещи знание которых не должно по идее раздувать индюка до размеров дирижабля.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154 Ответы: #158

157. Сообщение от Аноним (105), 11-Июн-21, 03:36	–1 +/–
> анона-фанатика SIP выше по треду тоже касается. Предлагаешь анону фанатику SIP читать его собственный коммент? А ты смешной =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

158. Сообщение от Аноним (105), 11-Июн-21, 03:42	–2 +/–
Не пойму, если я индюк, и меня раздуло до размеров дирижабля, то почему лопнул именно ты? XD
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156

159. Сообщение от Аноньимъ (ok), 11-Июн-21, 03:46	+/–
>Обыкновенный SIP-телефон стоит не сильно дороже роутеров и памяти в нём меньше Речь шла о роутерах. Очевидно создавать богомерзкий сложный трафик и работать с ним - задачи разные. Ну, это мое предположение. Так-же, ничего хорошего сложность протокола не делает и для него самого, как в плане банальной реализации так и в плане безопасности. >а половину цены составляют лицензии на всякие кодеки G729 и прочий проприетарный AMR Еще и платить за бекдоры. Жуть тьма и мрак. >А у тебя проблема в стиле все что не могу зафаерволить с натом всё плохое. У меня нет таких проблем. >Этот протокол так устроен, потому что его вечно ломают косорылые бараны, которые по ошибке называют себя сетевыми администраторами. Ну понятно, протокол чудесный это интернет плохой а протокол то-же плохой хоть и чудесный но плохой потому что интернет плохой. А интернет плохой потому что "косорылые бараны, которые по ошибке называют себя сетевыми администраторами" неспособны понять всю чудесность чудесного протокола который чудесный но из за баранов плохой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155 Ответы: #160

160. Сообщение от Аноним (105), 11-Июн-21, 04:36	+/–
>>> Я думаю дело не просто в том, что ленивые, а в том, что это реально сложно, особенно для бытовых железок с ограниченной памятью и железом. >> Обыкновенный SIP-телефон стоит не сильно дороже роутеров и памяти в нём меньше > Речь шла о роутерах. Среднестатистический телефон слабее роутера. Сильно. > Очевидно создавать богомерзкий сложный трафик и работать с ним - задачи разные. > Ну, это мое предположение. Предположение в корне не верное. В случае с SIP безопасность, балансировка нагрузки и вообще любое управление с точностью до пакета делается на SIP-сервере или B2BUA (back to back user agent) в зависимости от нужд, опять же. B2BUA это роль топологии SIP. Так как это пиринговый протокол, то в нем один и тот же условный сервер может выполнять разные роли в зависимости от соединения. То сервер, то клиент, то прокси, то B2BUA. B2BUA нужны если нужно терминировать сессии. На базе этой роли строят то, что называют модным словом SBC (Session Border Controller) или Application Firewall. Балансируют же сервера и прокси. А теперь возьмем абсолютно бесплатный и свободный Kamailio, который на небольшом устройстве не толще неттопа будет играючи менеджить 10000 сессий в секунду. Этот трафик "сложный" только в инженерном смысле. То есть это траффик пиринговой сети, которая может быть еще и децентрализирована до определенной степени. В одном соединении сессия с метаданными о другой сессии, и другая сессия отдельная. Чтобы менеджить вторую нужно её понимать, чтобы понимать целиком и контролировать, нужно реализовать SIP на промежуточном устройстве. SIP это протокол утсановки ДРУГИХ сессий. Там не только медиа. Там любую пиринговую сеть на уровне приложения можно построить. По это даже есть RFC, что траффик и топология второй сессии может быть любым. Например, через него RDP легко пролазит =) > Еще и платить за бекдоры. > Жуть тьма и мрак. Кодеки это обычные кодеки, для аудио. Ну то есть с тем же успехом нельзя слушать ничего кроме Ogg и смотреть только AOM/VP8-9. Там проблема отчислений при патентованных алгоритмах. Шапочку из фольги можно снять. > У меня нет таких проблем. Есть. "Протокольный Ад", "богомерзкий траффик" и прочая предосудительность к тому в чем не разбираешься - вот настоящее мракобесие. Лечится образованием. > Ну понятно, протокол чудесный это интернет плохой а протокол то-же плохой хоть и чудесный но плохой потому что интернет плохой... Вообще в целом да, но лучше поубавить максимализм и перестать делить мир на белое и черное. Задачи по медиа, особенно по телефонам традиционно развиваются отдельно от вендоров сетевого оборудования и зачастую вне интернета. Медиа существовало еще до интернета и прекрасно жило и без него. Есть задачи и эти задачи сложные, особенно когда дело касается видео-конференцсвязи на много человек (больше восьми). И да, сетевое оборудование исторически имеет костыли с ALG. И да многие сетевые администраторы, которые дальше Олифера в институте ничего не читали вырастают неграмотными в вопросах пиринговых сетей. А потом когда что-то пару раз не получилось вместо того чтобы разобраться ноют на форумах дескать все протоколы плохие, а я дартаньян... такое себе. Самое пожалуй уморительное было увидеть, как такой админ ставит сипофон в офис, фиксирует ренджи портов, пробрасывает порты на роутере. И жалуется, дескать, вот какой гадкий SIP, несекурный. Боты звонят на телефон и молчат, тётенька жалуется у него. Ну и как такому объяснить, что этот телефон для бота то же самое что сервер? Что это ОДНОРАНГОВАЯ СЕТЬ. Что они пытаются деньги со счетов украсть через платные номера зареганные где-то в Африке, но не могут, потому что это просто телефон, а не шлюз или сервер... Классический фродинг, кстати, который был еще до VoIP. У него видите ли телефон не звонит, поэтому он решил порты пробросить... А на роутере стоит ALG, которое ломает ему всю связь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159 Ответы: #161, #209

161. Сообщение от Аноньимъ (ok), 11-Июн-21, 04:42	+/–
Вот кстати интересно, как собственно решается вопрос безопасности, ну хоть с тёткой этой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #162

162. Сообщение от Аноним (105), 11-Июн-21, 06:07	+/–
Есть несколько вариантов, которые лучше комбинировать 1) ACL до нужных SIP-серверов и их медиапроксикластеров (уточнять у провайдеров перечень IP) и хоть что угодно пробрасывайте себе, но суть в том, что телефон сейчас не обязан смотреть в интернет напрямую. Если там вдали какой-то SIP-сервер не релеит траффик и не пишет разговоры, а соединяет напрямую, то белый список ACL не поможет, потому что медиа-соединение пойдет напрямую вообще на другие IP клиентов. Вот если бы заранее знать перечень возможных IP... Для таких задач и нужен SIP-сервер/SBC, чтобы разрешать оперативно. 2) Самый простой способ для обычного телефона в 2021-ом году, когда SIP-сервер в публичном интернете - это NAT любого рода, кроме Fullcone при выключенном UPnP вообще без DST-NAT. SIP его обойдет, а роутер не даст установить входящее соединение. На сервере и на телефоне при этом может быть просто rport ну или накрайняк STUN/TURN. Если удаленный сервер пишет разговоры, то даже STUN не надо, потому что траффик и тай пойдет через него как через relay. Так работают АТС-ки построенные поверх B2BUA вроде asterisk. 3) Не пользоваться старым китайским телефоном, который принимает анонимные звонки. Телефония это не сам SIP. Телефония строится поверх SIP. В ней есть понятие DID (Direct Inward Dial) и диалплана. Самые дешевые китайские телефоны могут не иметь поддержки диалплана вовсе. В идеале при поступлении входящего звонка он должен поступить на корректную "учетку", под которую в диалплане телефона появится DID. Это защита на уровне телефона. Благо, анонимных телефонов сейчас не так много. В зависимости от возможностей/подконтрольности роутера можно выбрать любую комбинацию. Вообще защиты там должно быть всегда 2. Одна на фаерволе, а вторая по смыслу сессий. В случае с телефонией лучше не брать телефоны, которые всегда зазвонят если позвонить на IP:порт. Это отключать надо по-возможности, что опять же не спасет тех у кого номер телефона 101. В зависимости от реализации есть некий endpoint, которому должен предназначаться звонок. Если его нет, то и звонок такой телефон должен отсечь. Если страшно сидеть с такой динамикой можно поставить B2BUA, прицепить телефон к нему, а его к вышестоящему SIP-серверу. Вообще, если мы говорим о серверах к которым прицепляются телефоны с неизвестно каких публичных сетей, то нужно поднять Fail2Ban... как всегда. Если DPI-скриптиком не обойтись, ставьте Kamailio желательно на отдельном IP и проверяйте на нем входящие пакеты. Он на себя может и регистрацию взять сильно разгрузив внутрикорпоративные АТСки. Кстати, DPI-скриптик с телефоном, когда сервер во вне не прокатит. Астериски, кстати, лучше защищать через ACL, потому что они вообще не очень умеют в защиту от DoS. Это разнопротокольная АТС-ка, она даже не полноценный SIP-сервер. Дальше B2BUA она не умеет... да ей и не надо. Опять же, перед ней нужно ставить Kamailio с конфигами собственного приготовления или любую SBC по вкусу, если нужно выставить её напрямую в интернет. Вообще когда-то во FreePBX ваяли фаервол с автобаном, но помнится потом в очередном PHP-модуле нашлась очередная уязвимость и всех поломали. Астериск и безопасность в одном предложении трудно располагать из-за его технических ограничений. Он же SIP до конца не поддерживает и не стремится. Узкоспециализированное ПО. А ну и да, пароли на 16 символов минимум, а лучше с TLS, если можете себе позволить =) SIP для аутентификации использует Digest, а это, мягко говоря, устаревший метод аутентификации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161 Ответы: #163

163. Сообщение от Аноньимъ (ok), 11-Июн-21, 06:24	+/–
Спасибо, сохраню на случай если придётся таким заниматься. Надеюсь конечно что нет :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162

164. Сообщение от Аноним (164), 11-Июн-21, 08:26	+/–
А сейчас мы выслушаем как должен выглядеть стандарт ната на удп конечно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154 Ответы: #204

165. Сообщение от kmeaw (?), 11-Июн-21, 08:30	+/–
Нет, рутовый доступ не нужен. Достаточно иметь возможность влиять на трафик пользователя, например с помощью DNS направить bank.com на свой $evilserver, который перенаправляет $evilserver:443 на mx.bank.com:465. А затем дать пользователю ссылку на https://bank.com/<script.../>, а после установки соединения направлять последующие запросы из этого <script/> уже на настоящий bank.com:443.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #174

166. Сообщение от kmeaw (?), 11-Июн-21, 08:32	+/–
Нет, для успешного проведения атаки достаточно ленивого админа, который вместо выписывания отдельных сертов для www.bank.com и mx.bank.com либо выпишет один на все имена, либо вообще сделает *.bank.com.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #167, #169

167. Сообщение от ыы (?), 11-Июн-21, 09:26	+1 +/–
И? Злоумышленник в этом случае должен иметь доступ либо к инфраструктуре днс имен *.bank.com либо администрировать один из сайтов *.bank.com. То есть  паршивой овцой окажется кто-то из команды bank.com. Ну как один из админов яндекс-почты...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #168

168. Сообщение от kmeaw (?), 11-Июн-21, 09:37	+1 +/–
Не обязательно, можно атаковать сетевую инфраструктуру. Способов полно - злоумышленник может поднять свою wifi AP, свой DHCP, сделать ARP spoofing на местный рекурсивный DNS, стать IPv6-роутером в IPv4-only сети, автосконфигурировать всем http-прокси с помощью wpad, владеть или атаковать какой-нибудь из маршрутизаторов между пользователем и bank.com.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #170

169. Сообщение от ыы (?), 11-Июн-21, 09:41	+1 +/–
Вы кстати как-то вот легкомысленно говорите про ленивость админа который выписывает отдельные сертификаты... Это возможно если вы бесплатные сертификаты с летскрипта выписываете. А вот если вы покупаете нормальные сертификаты, заверенные, с повышенным доверием - то разница в ценнике между *.bank.com и десятком "чтототам".bank.com будет заметная. И тем более если админ имеет возможность САМ выписывать эти сертификаты, там ценник вообще отрывается на порядок... Для конкретно банка- эти суммы может и не в тягость...но "*.bank.com" ведь для примера приведен. Это ведь может быть и не банк а просто предприятие. Которому все эти траты могут быть и не очень приятны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #172

170. Сообщение от ыы (?), 11-Июн-21, 09:43	+/–
И как это все даст ему доступ к внутренним логам сервиса зактытого TLS?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168 Ответы: #171

171. Сообщение от kmeaw (?), 11-Июн-21, 09:53	+2 +/–
Напрямую никак. Это даст ему возможность запустить js-код в браузере пользователя в контексте пользовательской авторизованной сессии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170 Ответы: #173

172. Сообщение от kmeaw (?), 11-Июн-21, 09:56	+/–
Согласен, дело может быть не только в лени, но и в желании сэкономить. > может быть и не банк а просто предприятие. Которому все эти траты могут быть и не очень приятны. Небольшое предприятие скорее всего воспользуется бесплатным letsencrypt, чтобы избежать трат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169

173. Сообщение от Аноним (112), 11-Июн-21, 10:56	+/–
>Это даст ему возможность запустить js-код Товарищ, мне кажется что вы окончательно запутались. Перечитайте ещё раз - мы опять упираемся в необходимость иметь на руках сертификат для совершения этой атаки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #171 Ответы: #176

174. Сообщение от Аноним (112), 11-Июн-21, 10:59	+/–
ну апупеть - всего-то нужно иметь корневой сертификат... Опять же зачем все эти пляски с подстановкой других сервисов, если мы уже можем тупо перехватывать трафик и проксировать запросы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #177

175. Сообщение от Аноним (175), 11-Июн-21, 12:23	+/–
Разве проблема тут не в том, что разным сервисам раздают одинаковые серты, да еще и от банка? Значит после взлома маршрутизатора, предполагается взломать еще и ftp
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #178

176. Сообщение от kmeaw (?), 11-Июн-21, 14:51	–1 +/–
Нет, нужен не сертификат, а наличие другого сервиса с сертификатом, соответствующим атакуемому домену. Предположим, что я - админ bank.com, и у меня есть почтовый сервер, mx.bank.com. Я законным путём получил сертификат сразу на два домена: "bank.com" и "mx.bank.com". Или на *.bank.com. Или на почтовом сервере у меня используется тот же сертификат, что и на веб-сервере - любой из этих вариантов подойдёт для атакующего. Важно лишь то, что сертификат, которым пользуется mx.bank.com, годится и для bank.com. Есть жертва. Она приходит в кафе поесть, но оказывается, что денег на карте не хватает, чтобы расплатиться, и приходится заходить на bank.com, чтобы перекинуть немного с накопительного счёта на карточный. Хорошо, что рядом есть wifi ap, ведь в этом месте мобильная сеть плохо работает. И есть злоумышленник. Который поднял эту wifi ap. Он уже давно пытается перехватить сессию пользователей на bank.com. Сначала он просто заворачивал трафик на свой nginx, но админы настроили https, и пользователь пугается и закрывает браузер, видя большое красное предупреждение. Поэтому злоумышленник стал действовать хитрее. Он стал подсовывать жертве ссылку на свой сайт, который из js делает POST-запрос на https://bank.com/transfer.cgi?to=eviljoe123&amount=100500. Разработчики банка узнали про этот трюк, и стали в веб-формы вставлять случайные CSRF-токены, которые злоумышленник угадать не может, а в обработчике transfer.cgi проверять их наличие. Теперь появилась вот эта новая атака. Злоумышленник подсовывает ссылку на evil.com/switchdns.cgi. Когда жертва переходит по ссылке, switchdns.cgi перенастраивает сеть так, чтобы трафик до bank.com попадал на mx.bank.com, а потом отдаёт редирект на bank.com/<script.../>. Браузер жертвы подключается туда (TLS), проверяет сертификат (с ним всё ок) и отправляет ничего не подозревающему почтовому серверу HTTP-запрос. Почтовый сервер отвечает "я не знаю, что такое <script.../>". Браузер интерпретирует это, как HTTP-ответ с тегом <script/> внутри, и начинает выполнять этот скрипт в контексте bank.com. А дальше злоумышленник возвращает всё обратно - пускает трафик по обычному пути до bank.com, а в своём скрипте делает запрос веб-формы, парсит оттуда CSRF-токен и делает POST на перевод денег - всё это из браузера пользователя, исполняющего его скрипт. Нигде во время атаки злоумышленнику не нужно ни владеть никакими сертификатами, ни находиться в сговоре с админами bank.com.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173 Ответы: #193

177. Сообщение от kmeaw (?), 11-Июн-21, 14:56	+/–
Не можем, потому что у нас нет корневого сертификата. Это расширенный вариант атаки, где на стороне сервера есть скрипт echo.cgi?q=12345, возвращающий строку 12345. Только теперь это делает не веб-сервер, а ftps- или почтовый сервер, находящийся на другой (но тоже принадлежащий тому же владельцу) машине. А злоумышленник подставляет вместо безопасного https-сервера другой сервер, который разговаривает по другому (но тоже завёрнутому в tls) протоколу, ответы которого браузер пользователя ошибочно интерпретирует, как http-ответы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174 Ответы: #182

178. Сообщение от kmeaw (?), 11-Июн-21, 15:02	+/–
> Разве проблема тут не в том, что разным сервисам раздают одинаковые серты, да еще и от банка? Именно в этом. > Значит после взлома маршрутизатора, предполагается взломать еще и ftp Нет, не придётся. Достаточно направить на другой сервер с тем же сертификатом http-запрос, содержащий контролируемую злоумышленником строку, которую тот вернёт в виде "ошибка: неизвестная команда: GET /строка...". А в случае ftp можно ещё воспользоваться тем, что данные передаются по отдельному соединению (тоже с tls), и тогда не придётся расчитывать на то, что браузер правильно угадает Content-Type.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175 Ответы: #195

179. Сообщение от adolfus (ok), 11-Июн-21, 15:10	+1 +/–
Веб должен оставаться просто вебом, и не пытаться стать платформой.
Ответить | Правка | Наверх | Cообщить модератору

180. Сообщение от Аноним (-), 11-Июн-21, 15:47	+/–
какие у тебя там реалии на выходных нодах tor? Сказочник былиный, ты наш )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

181. Сообщение от Аноним (-), 11-Июн-21, 15:50	+/–
А если не торчит, то что дает этот профиль "oelinux123" ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

182. Сообщение от Аноним (112), 11-Июн-21, 16:44	+/–
Вы кажется забыли, что почтовый сервер, чтобы тупо открыть соединение должны поручкаться с клиентом по TLS, а это значит что сертификат на сервере должен соответствовать адресу атакуемого сервера. Ну что за наркомания...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177 Ответы: #190

185. Сообщение от Stax (ok), 11-Июн-21, 21:36	+/–
>> Одна проблема с буквой "я" чего стоит, а про классику >> в виде отсутствия понятия кодировки имен файлов (и невозможности договориться о >> ней), > Интересно, почему у меня нет этой проблемы? А? Может маны почитать не? И какими же манами вы добавите поддержку передачи кодировки? И какими манами почините букву я в cp1251 в сервере, соответствующем RFC? >> работу через два независимых порта, что создает свои неприятности > А почему у меня работает через 1? Магия? Наверное, вы ходите на сервер типа https://ftp.coolserver.com/ и думаете, что это ftp. Ан нет! >> (ну-ка >> попробуйте с пол-тычка завернуть ftp в ssh туннель, аналогично http) > sftp это не ftp с ssl. Это на секунду часть ssh и > заводится на ура с пол оборота. Но мы же iPony style, > неосиляторы. Причем тут sftp вообще? Я про типичную ситуацию когда сервер открыт только для локалхоста, или для внутренней сети, но VPN нет возможности открыть и тп. ssh -L - работает очевидно для http, пускаете и натравливаете браузер на локалхост. Для ftp.. внезапно.. все сложно. >> и >> неопределенность даты файлов уж и не говорим.. > Откуда вы берёте все эти проблемы. Десятилетиями весят публичные репозитории и ни > у кого нет проблем. Одни только неосиляторы ноют. Ну расскажите тогда, вот вы в TZ=MSK, а сервер например где-то в США. Как обеспечивается корректная дата у скаченного файла в случае FTP? Опаньки... Когда FTP придумавали, вообще не задумывались о не-ASCII, временных зонах, стандартиризации формата листинга и тп. Другой несколько мир был, ага. FTP был хорош в 80-ые в рамках использования внутри США. Агитировать за него сейчас могут только маразматики, вот точно...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #198

186. Сообщение от Аноним (186), 12-Июн-21, 02:02	+1 +/–
Как будто проблема только в TLS. Там еще как бы и JavaScript нужен.
Ответить | Правка | Наверх | Cообщить модератору

187. Сообщение от edo (ok), 12-Июн-21, 03:09	+1 +/–
> 1. "Upload": для успешной атаки злоумышленнику требуется затем каким-то образом извлечь сохранённое содержимое. Ключевое слово - "каким-то". Давай, до свидания. если у злоумышленника есть права на аплоад, то вроде бы всё выглядит реальным. 1. иницируем под СВОИМ логином/паролем (или анонимно) в пассивном режиме аплоад через tls, сервер говорит на какой порт к нему подключаться; 2. рвём соединение клиента по https, он 99.99% попробует переподключиться, новое соединение пробрасываем на указанный в первом пункте порт. браузер клиента проверяет сертификат — валидный, начинает слать запрос, сервер записывает его в файл, после чего клиент отваливается по таймауту. 3. идём на ftps-сервер и читаем свежезалитый файл. по мнению сервера его залили мы, поэтому нет причин не дать нам его прочитать. в этом файле должны быть куки, профит P. S. сертификат необязательно должен быть один, главное, чтобы тот сертификат, что используется на ftps-сервере, подходил для https-адреса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #188, #189, #191

188. Сообщение от edo (ok), 12-Июн-21, 04:12	+1 +/–
аналогично, похоже, можно подсунуть браузеру нужный ответ (с js, например).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #187 Ответы: #192

189. Сообщение от Онаним (?), 12-Июн-21, 10:17	+/–
Сущая мелочь: 1) Надо иметь права на FTP-сервере, именно том, что необходимо "подсмотреть", в том числе на аплоад 2) Надо иметь возможность MITM для соединения клиента, рвать соединение не обязательно, можно проксировать в нужную сторону 3) Надо ещё как-то определить конкретный запрос, который перенаправлять, тут открытость SNI конечно поможет, SNI давно надо закрывать По сути комбинация п.1 и п.2 - это сложно, разные зоны ответственности разных лиц. А если (1) получено путём лома сервера - скорее всего смысла в (2-3) уже нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #187

190. Сообщение от Онаним (?), 12-Июн-21, 10:20	+/–
В этом и смысл атаки - они хотят передать в SMTP HTTP и получить его назад. Вот только невозможно это. Более реальную атаку мне тут выше обрисовали - да, в теории с помощью этой атаки можно залить куки на FTP, это действительно сработает. В теории. На практике там понадобится иметь аккаунт R/W на этом самом FTP, что для того же bank.com крайне маловероятно, и _одновременно_ MITM на клиенте, что вдвойне маловероятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182

191. Сообщение от Онаним (?), 12-Июн-21, 10:21	+/–
Но да, ваше описание атаки таки куда более реалистично, нежели "подмена ответа". Это хотя бы действительно сработает, хоть и имеет высокую сложность и малый шанс реализации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #187

192. Сообщение от Онаним (?), 12-Июн-21, 10:23	+/–
С ответом уже сильно сложнее, вплоть до нереалистичности. В теории да, можно залить подготовленный файл с хедерами и телом, но надо точно знать, на какой запрос отвечать, иначе MITM сразу же спалится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188

193. Сообщение от Онаним (?), 12-Июн-21, 10:27	+/–
Через mx.bank.com ты никакой редирект не отдашь - нормальный браузер его не схавает, хедеры нужны корректные. Через ftp.bank.com - можно - edo выше приводит рабочую схему атаки, но для этого надо на нём r/w доступ. У меня например есть под рукой живой шаред хостинг, и меня эта проблема не парит совсем, потому что мы сразу разделили FTP и клиентские серты, FTPS работает с нашим собственным сертом - это нормальная практика. Клиентскому серту - только клиентское, инфраструктура отдельно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #194

194. Сообщение от Онаним (?), 12-Июн-21, 10:32	+/–
(и возможность FTP hijacking меня тоже не парит, потому что соединения данных разрешены только от IP соединения управления)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193

195. Сообщение от Онаним (?), 12-Июн-21, 11:51	+/–
Недостаточно. Ответ надо ещё в HTTP обернуть. А то и в HTTP/2.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178

196. Сообщение от anonymous (??), 12-Июн-21, 12:20	+/–
Это, вообще говоря, и не обязательно банк. Это может быть ваш хостер, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #212

197. Сообщение от anonymous (??), 12-Июн-21, 12:21	–1 +/–
Новое то, что можно обойти буковки "S" в HTTPS обладая доступом лишь к роутеру.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132

198. Сообщение от deeaitch (ok), 12-Июн-21, 15:09	+/–
> И какими же манами вы добавите поддержку передачи кодировки? > И какими манами почините букву я в cp1251 в сервере, соответствующем RFC? Не спорю, была такая проблема. Где-то в конце 90-х начале 2000-х. Но она давным давно решена. Называется UTF > Наверное, вы ходите на сервер типа https://ftp.coolserver.com/ и думаете, что это ftp. > Ан нет! Прикинь. ftp://ftp.coolserver.com > Причем тут sftp вообще? Я про типичную ситуацию когда сервер открыт только > для локалхоста, или для внутренней сети, но VPN нет возможности открыть > и тп. ssh -L - работает очевидно для http, пускаете и > натравливаете браузер на локалхост. Для ftp.. внезапно.. все сложно. 1) Нет не сломано 2) Если у тебя уже есть ssh внутрь то ни http ни ftp тебе не нужен. Пробрось всю сеть через ssh тунель + vpn > Ну расскажите тогда, вот вы в TZ=MSK, а сервер например где-то в > США. Как обеспечивается корректная дата у скаченного файла в случае FTP? > Опаньки... Когда FTP придумавали, вообще не задумывались о не-ASCII, временных зонах, > стандартиризации формата листинга и тп. Другой несколько мир был, ага. А вы просто путаете и подменяете понятия. Если вы о дате создания файла к примеру. То скачав файл его дата создания логично должна быть той датой когда вы его скачали себе, а не когда он был выложен на сервер. И это логично. Еже ли вы скачав файл в 2021 году получаете дату создания файла 2019 то это како-то бред. И вся система отслеживания устаревших файлов летит впень. > FTP был хорош в 80-ые в рамках использования внутри США. Агитировать за > него сейчас могут только маразматики, вот точно... FTP хорош и сейчас. У него есть своя ниша и да, я знаю о действительных недостатках FTP а не то высасоное из пальца что тут все любят приводить, он не панацея от всего да и не должен быть. У него своё назначение и в этом он превосходен. Я не агитирую за FTP везде. Мне не нравятся неосиляторы которые выпиливают отличные технологии просто потому что они их не поняли. А вот за полный отказ от отличного протокола для локальных файловых помоек, публичных глобальных файловых помоек и за превод всего и вся на HTTP вот точно могут только маразматики и эпичные неосиляторы вроде iPony
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #185 Ответы: #203

199. Сообщение от deeaitch (ok), 12-Июн-21, 15:11	+/–
>> rfc959 пункт 2.3. > Ты б ещё на man сослался, как его включить. > Только его никто не включает. Угадаешь, почему? Я угадаю, ты маны читать не умеешь, как и мноние, куда там до rfc
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #201

200. Сообщение от deeaitch (ok), 12-Июн-21, 15:13	+/–
> Ну ты сразу понял, что был неправ. Он понял я думаю. Куда лучше читать маны и rfc, чем общаться с эпичными неосиляторами. Поэтому куда успешнее и продуктивнее потратил своё время.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

201. Сообщение от Annoynymous (ok), 12-Июн-21, 19:44	–2 +/–
> Я угадаю, ты маны читать не умеешь, как и мноние, куда там > до rfc Конечно. Ты же мне покажешь сервер в интернете с работающим FXP, теоретик, читавший маны и RFC? Я поучусь, куда нам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199 Ответы: #205

202. Сообщение от Annoynymous (ok), 12-Июн-21, 19:45	–2 +/–
> sftp это не ftp с ssl. Это на секунду часть ssh и > заводится на ура с пол оборота. Но мы же iPony style, > неосиляторы. Обожаю опеннетовский комментаторов. Ты даже не понял, что у тебя спросили. Про FXP ты тоже не понял. Но апломбу выше крыши, учить всех заявился.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #206

203. Сообщение от Annoynymous (ok), 12-Июн-21, 19:47	–1 +/–
> Еже ли вы скачав файл в 2021 году получаете дату создания файла > 2019 то это како-то бред. И вся система отслеживания устаревших файлов > летит впень. Чувааааак. Ты теоретик. Признайся в этом и перестань это показывать в каждом посте. Спасибо заранее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198 Ответы: #207, #210

204. Сообщение от Да не важно (?), 12-Июн-21, 22:35	+/–
Да хоть как. Но как-то должен. Сейчас же их пять (в Википедии они описаны, в английской, конечно. С чУдными картинками и большими буквами, прямо как азбука у Буратино), и каждый раз приходится гадать, с чем имеем дело.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164

205. Сообщение от deeaitch (ok), 15-Июн-21, 04:24	+/–
Сложно придумать для чего оно может быть, но так и быть. Поднял. Нужнее мне оно от этого не стало. > Конечно. Ты же мне покажешь сервер в интернете с работающим FXP Конечно. А теперь ты мне покажи FXP на http и вообще где это может понадобиться. Знаток.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201

206. Сообщение от deeaitch (ok), 15-Июн-21, 04:25	+/–
> Обожаю опеннетовский комментаторов. Ты даже не понял, что у тебя спросили. Обожаю эпичных неосиляторов. Которые не в состоянии уже даже дерево сообщение проследить. Один только гулоконвесейшены понимают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #202

207. Сообщение от deeaitch (ok), 15-Июн-21, 04:28	+/–
> Чувааааак. Ты теоретик. Признайся в этом и перестань это показывать в каждом > посте. Чувак. Признайся, ты эпичный неосилятор из армии iPony и такой-же нытик как Fracta1L. И это видно в каждом посте. Ну и бухаешь заметно что не слабо. У меня какраз всё работает. И пользуется каждый день. А ты вцепился в этот FXP как буд-то это край технологий и прямо киллерфича что без неё жить нельзя. Вот это и называется теоретик. Так что не подменяй понятия и начни уже работать с реальными задачами а не высасаными из пальца с теоретической нужностью двум землекопа. > Спасибо заранее. Пожалуйста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203

208. Сообщение от Kuromi (ok), 15-Июн-21, 19:46	+/–
> Для этой атаки не нужна поддержка FTP в браузере. После удаления ФТП > браузер всё так же остаётся уязвим. Хахашечки, но уже закрыли - https://bugzilla.mozilla.org/show_bug.cgi?id=1715684 Грязный хак, конечно, но "правильный" фикс https://bugzilla.mozilla.org/show_bug.cgi?id=1683710 пока в работе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

209. Сообщение от СеменСеменыч777 (?), 15-Июн-21, 20:56	+/–
> Медиа существовало еще до интернета и прекрасно жило и без него POTS сдох. ISDN сдох. ATM ("another terrible mistake") сдох. все что приходит от телефонистов - сдохнет. и SIP этот ваш ... ps: по некоторым данным, DOCSIS тоже сдох.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

210. Сообщение от deeaitch (ok), 15-Июн-21, 23:27	+/–
Молодец. Признался таких что нытик и неосилятор. Признание это первый шаг к выздоровлению. Жаль не поможет, в твоём случае последний.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203

211. Сообщение от Аноним (214), 22-Июн-21, 18:41	+/–
> Эпичные неосиляторы, когда же вы научитесь доки читать. Нормально ходит и через один порт. Именно FTP ходит? Или какой-нибудь SFTP, который вообще другой протокол?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

212. Сообщение от Аноним (214), 22-Июн-21, 18:45	+/–
> Это, вообще говоря, и не обязательно банк. Это может быть ваш хостер, например. Не может. У этого "FTP" должен быть тот же сертификат, что и у банка. Откуда у хостера возьмётся сертификат банка? Или банк на шаред-хостинге сидит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196

213. Сообщение от Аноним (214), 22-Июн-21, 18:53	+/–
> О дааа.. Одна проблема с буквой "я" чего стоит, а про классику в виде отсутствия понятия кодировки имен файлов (и невозможности договориться о ней), А зачем кодировки, когда всё в UTF-8? > работу через два независимых порта, что создает свои неприятности (ну-ка попробуйте с пол-тычка завернуть ftp в ssh туннель, аналогично http) Для ssh не нужен ftp. Но если очень хочется, то можно 3мя способами (протокол позволяет задавать фиксированные порты, а у ssh есть -D). > и неопределенность даты файлов уж и не говорим.. Определена не хуже чем в http.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

214. Сообщение от Аноним (214), 22-Июн-21, 19:02	+/–
> FXP покажи через http. Да никому нафиг не сдался тот FXP. У FTP было три киллер-фичи: 1. Скорость. Роутер с подключенным жёстким диском отдаёт по FTP в локалку файлы на скорости этого жёсткого диска. Без гигагерцевого процессора и гигабайта оперативки. 2. Поддержка upload-а и download-а каталогов. 3. Работает в любой ОС из коробки, прямо в браузере. П.3. старательно пытаются выпилить. Но даже без него альтернатив банально нет. Никакой протокол не совмещает в себе эти две возможности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

215. Сообщение от онанимус (?), 30-Июн-21, 23:21	+/–
> А если серьёзно? а если серьёзно, то гуглите  "казино взломали через аквариум", или термометр, не помню точно. за admin:admin девайсами порой скрывается много интересного, как минимум это доступ в локальную сеть таргета.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема