1
00:00:00,000 --> 00:00:03,220
Всем привет. Извините за задержку.

2
00:00:04,400 --> 00:00:07,840
Меня зовут Кирилл Калегаев, со мной Роман Новых.

3
00:00:12,620 --> 00:00:15,720
Сегодня мы расскажем о результатах хейтинг-команды.

4
00:00:16,040 --> 00:00:19,260
Мы по соглашению с организаторами не называем,

5
00:00:20,340 --> 00:00:22,020
к какой компании мы относимся.

6
00:00:22,680 --> 00:00:25,580
Хейтинг-команда, которая занимается тестированием

7
00:00:25,580 --> 00:00:29,800
внешнего периметра непрерывном,

8
00:00:30,340 --> 00:00:31,400
проведем анализ результатов,

9
00:00:31,480 --> 00:00:32,140
которые мы собрали,

10
00:00:33,320 --> 00:00:35,440
немного посмотрим на статистику, интересные кейсы

11
00:00:35,440 --> 00:00:37,460
и какие выводы

12
00:00:37,460 --> 00:00:39,080
из этого всего можно сделать.

13
00:00:40,080 --> 00:00:41,500
Тут небольшой план.

14
00:00:43,660 --> 00:00:45,060
Расскажем, о чем вообще

15
00:00:45,060 --> 00:00:47,600
доклад, какая была каталогия,

16
00:00:47,740 --> 00:00:48,720
какие там ограничения,

17
00:00:49,600 --> 00:00:50,820
типу изимести, типу КО,

18
00:00:50,820 --> 00:00:52,060
как мы классифицировали.

19
00:00:53,380 --> 00:00:54,680
Расскажем интересные кейсы,

20
00:00:54,680 --> 00:00:59,700
от реализимости к инвестивному событию, ну и какие выводы из этого всего можно сделать.

21
00:01:01,540 --> 00:01:10,240
Да, о чем вы вообще? У нас накопился довольно большой, на наш взгляд, опыт проведения тестирования на предотвращение внешнего периметра,

22
00:01:10,640 --> 00:01:19,040
это более 50 проектов. У нас накопилось командной командой довольно большое количество опубликованных 0-0 реализимости,

23
00:01:19,040 --> 00:01:24,100
более 150 опубликованных для раздельности на текущий момент.

24
00:01:26,100 --> 00:01:31,480
И, соответственно, нам показалось, что этого объема данных может быть достаточно,

25
00:01:31,660 --> 00:01:36,640
чтобы провести какой-то анализ, вывести какие-то интересные инспекционно-мерности.

26
00:01:39,040 --> 00:01:43,380
Мы сфокусировались не на известной ЦВЕ, АПДУ и так далее,

27
00:01:43,380 --> 00:01:49,160
нас интересовали именно новые уязвимости, которые не встречались ранее,

28
00:01:49,160 --> 00:01:56,040
которые мы находим на проектах, либо которые мы находим в рамках 0D research.

29
00:01:57,120 --> 00:02:03,820
Также нам хотелось рассмотреть не просто эти уязвимости, а составить какую-то модель.

30
00:02:05,240 --> 00:02:12,440
В сумме у нас получилось 250 плюс записи, то есть суммировая 0D и проектные находки и так далее.

31
00:02:13,380 --> 00:02:36,920
В каждой записи мы категорировали, то есть есть категория по WAST-POP10, есть vulnerability type, это CVE, по сути как CVE, тип, только человек читаемый, то есть не номер просто, а ну и скеллигентц, например.

32
00:02:36,920 --> 00:02:45,920
Нам хотелось рассмотреть потенциальный импакт, то есть сразу посмотреть, ну например, что там вот CSS и потенциальный импакт это account recover.

33
00:02:45,920 --> 00:02:53,920
Также нам хотелось, мы посмотрели какой у нас был подтвержденный импакт, то есть для чего у нас получилось закрутить данную изюимость,

34
00:02:53,920 --> 00:03:04,920
какой тип ПО используется, где была найдена изюимость и по потенциальному либо подтвержденному импакту, какие есть рекомендуемые исправления.

35
00:03:04,920 --> 00:03:09,740
Как можно предотвратить данную уязвимость?

36
00:03:09,740 --> 00:03:11,740
Логика такая.

37
00:03:16,680 --> 00:03:20,380
Важно сказать еще раз про методологию отличения.

38
00:03:20,380 --> 00:03:25,140
Dataset — это наш набор уязвимостей, которые не встречались раньше.

39
00:03:25,140 --> 00:03:27,640
Проектный плюс 0D.

40
00:03:27,640 --> 00:03:32,540
Нет никаких CVE, BDU, местонфигураций, которые находятся с фонарами.

41
00:03:32,540 --> 00:03:43,540
То есть у нас фокус здесь не на vulnerability management, а именно на новостях поезвимости, о которых встречаются в бизнес-логике и так далее.

42
00:03:43,540 --> 00:03:49,540
По типам поезвимости, как сказал, мы классифицируем по WAST 2025 и CVE Like.

43
00:03:49,540 --> 00:03:53,540
Типы PO – это тоже, собственно, классификация.

44
00:03:53,540 --> 00:04:08,620
Испакт и контролл — это словарь, человекочитаемый, чтобы по тегам можно было понять вообще, какой здесь импакт и какие контролл закрывают эти уязвимости.

45
00:04:09,620 --> 00:04:14,860
Тут же важно сказать про ограничения. Это не универсальная статистика всех уязвимостей.

46
00:04:14,860 --> 00:04:25,660
То есть это только наш опыт, соответственно, мы не можем сказать, что его можно взять и опоксимировать, допустим, на весь внешний периметр Рунеты или еще где-то.

47
00:04:25,780 --> 00:04:28,380
То есть это только наш командный опыт.

48
00:04:28,940 --> 00:04:30,740
И это только внешний периметр.

49
00:04:31,460 --> 00:04:43,840
Соответственно, тут стоит сразу сказать, что недопустимые события, мы их понимаем как что-то крайне критичное, что можно реализовать из позиции внешнего злоумышленника.

50
00:04:43,840 --> 00:04:46,880
То есть здесь не будет взять замены и так далее.

51
00:04:47,060 --> 00:04:50,400
То есть для нас недопустимое событие – это что-то очень критичное,

52
00:04:50,500 --> 00:04:54,320
что можно реализовать из позиции внешнего нарушения.

53
00:04:54,460 --> 00:04:57,580
Ну там, RCE и так далее.

54
00:04:57,740 --> 00:05:01,940
То есть никаких дальнейших закруток здесь не будет.

55
00:05:04,380 --> 00:05:08,900
Так, да, все любят слайды, которые едут по цветам.

56
00:05:08,900 --> 00:05:13,000
Все любят слайды, которые с большими красивыми цифрами.

57
00:05:14,360 --> 00:05:15,360
У нас такой тоже есть.

58
00:05:15,840 --> 00:05:17,660
Мы же не зря классифицировали.

59
00:05:18,300 --> 00:05:25,060
По нашим результатам у нас broken access control – это почти половина всех уединенных уязвимостей.

60
00:05:26,840 --> 00:05:32,760
Если посмотреть на два остальных категории – это authentication, failures и injection,

61
00:05:32,760 --> 00:05:41,820
то в сумме все эти три типа уязвимости будут составлять более 90% всего, что мы находим.

62
00:05:41,960 --> 00:05:45,000
Это просто интересные цифры.

63
00:05:47,060 --> 00:05:56,240
Далее чуть более подробная статистика по типам уязвимостей и по типам пола, на которых они были найдены.

64
00:05:56,240 --> 00:06:03,060
Здесь, если по типам уязвимости посмотреть, то уже более равномерное распределение.

65
00:06:03,060 --> 00:06:10,300
Всем известные XSS, KIDOR, DISPLOSUR, YouTube NAM и так далее.

66
00:06:10,300 --> 00:06:19,420
С такой классификацией, во-первых, человекочитаемый, во-вторых, более равномерно получается,

67
00:06:19,420 --> 00:06:23,920
потому что все в одну кучу broken access control, например, не сложено.

68
00:06:23,920 --> 00:06:34,920
И по типам ПО у нас более 50% можно увидеть, что это либо какие-то бизнесовые вебчики, либо CMS.

69
00:06:34,920 --> 00:06:42,920
На самом деле довольно логично, учитывая, что мы фокусируемся не на CVE и не на известных каких-то уязвимости,

70
00:06:42,920 --> 00:06:49,920
а на новых уязвимости, они существуют где-нибудь в бизнес-логике.

71
00:06:49,920 --> 00:07:02,560
Да, не будем сильно тянуть со статистикой всем остальным, мы потом к ней еще вернемся, перейдем к наиболее интересным кейсам, которые приводили к негативным событиям.

72
00:07:02,560 --> 00:07:04,560
Это все, что там вполне.

73
00:07:04,560 --> 00:07:06,560
Помоги?

74
00:07:07,560 --> 00:07:09,560
Небольшой степеньер.

75
00:07:09,560 --> 00:07:12,560
Мы были сосредоточены больше на

76
00:07:12,560 --> 00:07:15,560
инфакте, а не на технической части самоизвимости.

77
00:07:15,560 --> 00:07:18,560
То есть мы стараемся здесь рассмотреть не то, что существует

78
00:07:18,560 --> 00:07:20,560
в QE-рекции какой-то интересный для нее bypass,

79
00:07:20,560 --> 00:07:24,560
а то, что существует в QE-рекции и что, в принципе, с ней можно сделать.

80
00:07:26,560 --> 00:07:29,560
Первая история — это один из сообщений,

81
00:07:29,560 --> 00:07:36,140
Грубо говоря, user-in-up плюс сабый парольный политико, что в себе это вообще подразумевает.

82
00:07:36,140 --> 00:07:43,520
То есть вообще user-in-up как таковой, некоторые компании даже и вендоры не считают за какую-либо уязвимость.

83
00:07:44,280 --> 00:07:51,540
То есть не подумаешь, что можно получить ими пользователя, который существует в системе, как бы ни 4 реакции, ни 6-е-шка, ничего такого не утекает.

84
00:07:52,280 --> 00:07:57,920
Но опять же, в совокупности с сабый парольный политико эта история вообще может стать критичной.

85
00:07:57,920 --> 00:08:10,820
Мы вообще постоянно с этим сталкиваемся. В осложках, в качественных шлюзах, в всевозможных подкладных интеграциях, самописном таком поле и так далее.

86
00:08:11,040 --> 00:08:13,960
То есть юзеринам может оказаться вообще везде.

87
00:08:15,920 --> 00:08:22,640
Последствия наглядные. То есть приложение, где не используется интеграция с доменом, 99% в случае,

88
00:08:22,640 --> 00:08:31,640
В итоге мы собираем набу по пользователям и просто начинаем брутить топ-100, 1000, 10 тысяч и как-то, насколько у нас хватает ресурсов.

89
00:08:31,640 --> 00:08:39,640
Интересно здесь то, что этот баг часто не живет один, а в принципе, ну, идут облегчающие баги.

90
00:08:39,640 --> 00:08:47,640
Это отсутствие RAID-лимитов, отсутствие блокировок учетных записей и отсутствие блокировки атакующего, например, по IP.

91
00:08:47,640 --> 00:09:00,640
Ну, собственно, да, то есть в этом кейсе мы показываем, то есть мы перебрали, собрали мапу и в реальный пароль мы попали в супер критический актив, который не особо можно показывать.

92
00:09:00,640 --> 00:09:09,760
в следующем кейсе он уже более интересным, более интересной истории

93
00:09:09,760 --> 00:09:13,360
был выполнен DINAM в Exchange

94
00:09:13,360 --> 00:09:22,080
собраны учетки, по ним был выполнен Spray и одна из учетов постоянного

95
00:09:22,080 --> 00:09:25,960
после этого был получен доступ в Google Playpack

96
00:09:25,960 --> 00:09:35,560
и там уже найдены интересные истории про доступ к машинам обновениям, доступ к работам.

97
00:09:35,560 --> 00:09:48,580
Очень дешевая атака получилась, просто подождали, просто посмотрели на консольку, все, получили, пробив внешне.

98
00:09:48,580 --> 00:09:59,020
Следующий кейс он не в Enterprise в каком-то приложении, но тоже очень интересен тем, что это интеграция с LDAQ.

99
00:09:59,020 --> 00:10:08,080
LDAQ был достаточно разговорчивым и по остаткам мы могли достаточно точно финтровать вообще успешно была аутентификация или нет.

100
00:10:08,240 --> 00:10:14,380
То есть передание фактически была только форма входа и все. Что из этого мы получили?

101
00:10:14,380 --> 00:10:22,300
получили могла сетич существующих доменных учетных записей и примерно 100 удалось подобрать

102
00:10:22,300 --> 00:10:32,800
пароль а так получил супер дешевый супер тривиальный но в этом всем здесь достаточно пятичных

103
00:10:32,800 --> 00:10:45,800
Собственно, реализованные места этих кейсов — это правильный финишник инфиритера, доступ к политических сегментах контроля, управление администрированием и тому подобное.

104
00:10:45,800 --> 00:10:53,800
То есть вообще не будем рассказывать, а с вопросом нет. Следующий факт — это сбор актиноменов ОЗ и материал по вотфишнекотеке.

105
00:10:53,800 --> 00:11:01,320
Инам это еще старые добрые фиши, с которыми можно очень активно работать.

106
00:11:01,320 --> 00:11:04,280
В том числе как раз на больших объемах данных.

107
00:11:06,280 --> 00:11:07,960
Соло перенадки, ребята.

108
00:11:07,960 --> 00:11:17,320
Спасибо. Следующая выявимость, типа неудивенность и история, про которую мы расскажем, это Айдоры, которые всем довольно знакомы.

109
00:11:17,320 --> 00:11:29,320
На слайде представлен самая стандартная история, когда, во-первых, идентификатор какой-то объекта перебираемый, то есть это просто числовой номер.

110
00:11:29,320 --> 00:11:36,320
И как меме это можно просто делать и смотреть на чужие идентификаторы.

111
00:11:36,320 --> 00:11:43,320
Либо такой же еще один пример, всем уже давно знакомый.

112
00:11:43,320 --> 00:11:50,320
Мы тут, естественно, не будем рассказывать про такие IDOR, и интерес этой истории не в этом.

113
00:11:50,320 --> 00:11:55,320
В том, что когда мы обычно про такие IDOR рассказываем, даем рекомендации,

114
00:11:55,320 --> 00:11:58,320
мы говорим, что нужно сделать две вещи.

115
00:11:58,320 --> 00:12:04,320
Первая — это уйти от перебираемых редфикаторов, использовать WID,

116
00:12:04,320 --> 00:12:07,320
чтобы их нельзя было просто с одним минус одним делать.

117
00:12:07,320 --> 00:12:13,320
И второе, это естественно реализовать разрешение контроля доступа.

118
00:12:13,320 --> 00:12:20,320
То есть, что объект, субъект, который не имеет права доступа на какой-то объект,

119
00:12:20,320 --> 00:12:26,320
не должен, если у него этого права нет, он его должен получать даже по прямой ссылке.

120
00:12:26,320 --> 00:12:37,880
Мы часто сталкиваемся с таким мнением, видимо, потому что реализовать просто уиды, чтобы они были неперебираемыми легко

121
00:12:37,880 --> 00:12:47,060
А вот реализовать полноценную ролёвку, чтобы нельзя было проверку на уровне нового объекта, иметь субъект доступ и так далее

122
00:12:47,060 --> 00:12:53,600
Чуть послоднее, видимо, поэтому нам часто говорят, а вот давайте мы просто уиды реализуем

123
00:12:53,600 --> 00:13:05,920
когда мы общаемся, пытаемся, чтобы эти выживости закрыли, давайте мы просто уиды реализуем, соответственно, перебрать вы никак не сможете, на этом будет строиться все безопасно.

124
00:13:06,820 --> 00:13:18,920
Вот, собственно, следующий кейс, как раз про то, что на одном только знании уидов, их секретности безопасно строить нельзя.

125
00:13:18,920 --> 00:13:26,680
Тут приложение мы должны стали скринить, чтобы не рассказывать, что это за приложение.

126
00:13:27,680 --> 00:13:28,680
В чем здесь история?

127
00:13:30,120 --> 00:13:35,560
В самом приложении обрабатывались крайне критичные и чувствительные информации.

128
00:13:37,120 --> 00:13:41,220
Аутентификация была через ESEA, то есть это просто OAUS, по сути.

129
00:13:41,220 --> 00:13:43,480
То есть аутентификация была делегирована.

130
00:13:45,320 --> 00:13:48,320
И там в целом все выглядело неплохо в самом приложении.

131
00:13:48,920 --> 00:13:54,920
Немного фотографировавшись, посмотрев, обнаружили интересный JavaScript endpoint,

132
00:13:54,920 --> 00:14:02,920
на котором увидели ряд интересных, во-первых, ключик, которые...

133
00:14:02,920 --> 00:14:09,920
На слайде внизу видно, что говорят нам о какой-то регистрации,

134
00:14:09,920 --> 00:14:14,420
видимо есть какая-то внутренняя регистрация.

135
00:14:14,420 --> 00:14:21,920
И также увидели некие роли, которые тоже выглядят как GUID и так далее.

136
00:14:21,920 --> 00:14:26,920
Вот тыкнулись в ручку, которая позволяла, кажется, регистрировать пользователя,

137
00:14:26,920 --> 00:14:33,920
причем это явно была не та ручка, которая стандартная через eSea.

138
00:14:33,920 --> 00:14:39,980
Видно, что GED не поддерживается, поддерживается пост.

139
00:14:39,980 --> 00:14:46,980
Соответственно, в процессе изучения этого API было замечено, что…

140
00:14:46,980 --> 00:14:55,680
Чтобы вообще… Это, видимо, было API какой-то встраиваемой системы, то есть чего-то стороннего.

141
00:14:55,680 --> 00:15:02,080
Там было замечено, что чтобы амфицироваться и чтобы прилетел валидный токен, сессия,

142
00:15:02,080 --> 00:15:07,980
нужно передать определенные идентификаторы, там ECR ID и WIC Profiles.

143
00:15:08,180 --> 00:15:15,280
То есть тоже то, что на самом деле не перебираемо, особо не раскрывалось и так далее.

144
00:15:15,960 --> 00:15:23,080
Но тем не менее здесь была найдена уязвимость, что на самом деле эта ручка возвращала валидный токен

145
00:15:23,080 --> 00:15:26,180
даже без передачи этих идентификаторов.

146
00:15:26,180 --> 00:15:31,520
То есть токен возвращался, не передавая эти идентификаторы.

147
00:15:31,520 --> 00:15:37,340
Единственная разница у этого токена была в том, что он не был привязан за конкретную сущность.

148
00:15:37,340 --> 00:15:43,800
Видимо, привязка за субъект была как раз по идентификаторам.

149
00:15:43,800 --> 00:15:47,800
Но, тем не менее, этот токен был валидный, и с ним можно было отходить.

150
00:15:47,800 --> 00:15:52,920
И далее мы еще поговорялись и раскрыли схему ролей.

151
00:15:52,920 --> 00:16:00,560
То есть какой гуид, за какую роль отвечаем.

152
00:16:01,660 --> 00:16:07,600
Ну, соответственно, тут можно увидеть, что уже в этом есть крайне критичная уязвимость.

153
00:16:08,360 --> 00:16:12,340
Есть предыдущая уязвимость, где нет, по сути, никакой проверки.

154
00:16:12,540 --> 00:16:15,280
То есть просто нам нужно только предоставить какую-то роль,

155
00:16:15,280 --> 00:16:20,580
и нам дается, соответственно, валидный токен.

156
00:16:20,800 --> 00:16:22,400
Дальше мы с этой ролью можем ходить.

157
00:16:22,920 --> 00:16:28,200
И мы только что раскрыли все роли, которые есть в этой системе.

158
00:16:28,200 --> 00:16:34,040
Соответственно, в дальнейшем эксплуатация была связана с логикой.

159
00:16:34,040 --> 00:16:39,400
То есть мы смогли повыситься до роли работника этой системы.

160
00:16:39,400 --> 00:16:43,520
И далее мы могли раскрывать крайне критичную информацию.

161
00:16:43,520 --> 00:16:51,000
Соответственно, информацию обо всех пользователях, которые к этому работнику прикреплены.

162
00:16:51,000 --> 00:17:00,000
крайне критичную информацию про их файлы и также информацию про…

163
00:17:00,000 --> 00:17:10,000
В конечном итоге можно было раскрыть даже линк на видеоконференцию, в которой можно было подключиться.

164
00:17:10,000 --> 00:17:16,000
Хотя здесь все было реализовано на уидах, и чтобы получить доступ к такому-то файлу,

165
00:17:16,000 --> 00:17:19,800
не нужна была даже роль, тут вообще никакого токена нету.

166
00:17:19,800 --> 00:17:25,180
То есть можно увидеть на слайде ниже, что получение файла,

167
00:17:25,180 --> 00:17:33,860
вся защита строилась просто на знании, секрете, идентификатор, который сложно перебираем,

168
00:17:33,860 --> 00:17:46,100
Но здесь случилась уязвимость по модификации и были получены крайне фитичные информации.

169
00:17:46,100 --> 00:17:53,220
На одно реализованное событие – это массовое раскрытие персональной данной, чувствительной информации.

170
00:17:53,220 --> 00:17:59,280
Тут раскрывалась как информация о работниках, так и о посетителе, пользователях платформы.

171
00:17:59,280 --> 00:18:02,280
Возможно, включаться в видеоконференции.

172
00:18:02,280 --> 00:18:05,280
И также, как я сказал, все дальше было связано с бизнес-логикой,

173
00:18:05,280 --> 00:18:09,280
была возможность влиять на расписание работников этой системы.

174
00:18:09,280 --> 00:18:18,280
Быстрый вывод, что на основе других уидов строить безопасность, конечно же, нельзя.

175
00:18:18,280 --> 00:18:21,280
Слово о том, слово передам нельзя.

176
00:18:29,280 --> 00:18:38,280
Небольшой спойлер, а почему будет плохо. Вообще очень часто 1С — это фактически нервная система бизнеса.

177
00:18:38,280 --> 00:18:42,280
То есть это документы, бухгалтери, кадры, документы и все такое.

178
00:18:42,280 --> 00:18:52,280
1С исторически вообще развивалось как что-то внутреннее, почему никто не должен иметь доступа.

179
00:18:52,280 --> 00:18:59,280
доступа, но в силу того, что стали обрастать, что кто хочет иметь доступ к 1С, это бухгалтерия,

180
00:18:59,280 --> 00:19:05,340
также администраторы, удаленные какие-то сотрудники и тому подобное. 1С стала обрастать не совсем

181
00:19:05,340 --> 00:19:11,600
безопасными практиками, это, например, какие-то обработки, это обработки специфичные, это публикация

182
00:19:11,600 --> 00:19:17,720
11 как вы приложение в большой интернет, доступный, в общем-то, извне.

183
00:19:17,720 --> 00:19:21,980
Вот. И, в общем-то, сейчас расскажу, что из этого бывает.

184
00:19:23,180 --> 00:19:29,480
Первый кейс, уже, наверное, народный метод, фаундификация реализована через СОШКУ, базируют на ID.

185
00:19:30,600 --> 00:19:37,640
Вот. Вроде бы все хорошо, но архитектурная СОШКУ является либо отдельной базой данных,

186
00:19:37,640 --> 00:19:41,040
либо общий баз данных, на который ты входишь.

187
00:19:43,920 --> 00:19:50,880
Нам удалось с помощью небольшого лауза спуститься до классической аутентификации 1С,

188
00:19:50,880 --> 00:20:01,280
то есть немножко архитектурная такая бага, которая позволяла нам уже получить список пользователей этой базы,

189
00:20:01,620 --> 00:20:04,720
получается, сочный, и попробовать уже поддеваться внутрь.

190
00:20:04,720 --> 00:20:12,120
Мы отцвотились вообще на RCA. Нам не повезло, не было ни слабых паролей, ни пустых паролей.

191
00:20:12,120 --> 00:20:18,720
Но мы не сдавались, значит нам лутнулось, начали накрутить, начали пазить пути на том же домене.

192
00:20:18,720 --> 00:20:29,720
Оказалось так, что была найдена дополнительная база.

193
00:20:29,720 --> 00:20:39,040
Она имела также такую же дополненную авторизацию в Dynastity.

194
00:20:39,040 --> 00:20:42,260
Там также был список пользователей. И тут нам уже как раз повезло.

195
00:20:42,260 --> 00:20:53,400
Мы получили список пользователей и получили пользователя с пустим паролем и с административной валютой.

196
00:20:53,400 --> 00:21:00,400
Тем самым далее мы выполнили EPU и RCE, и получили RCE шкур пластыри.

197
00:21:02,400 --> 00:21:05,400
По классическим пунктам.

198
00:21:05,400 --> 00:21:10,400
Второй кейс, он больше рассказывает не про чиповые какие-то истории,

199
00:21:10,400 --> 00:21:12,400
что просто опубликовали базу, забыли прикрыться,

200
00:21:12,400 --> 00:21:17,400
он рассказывает больше о как раз архитектурных сложностях в NESCM.

201
00:21:17,400 --> 00:21:26,400
На встрече с порталом. Портал из себя представлял тоже подобие SSO, но там была небольшая такая особенность.

202
00:21:26,400 --> 00:21:36,400
То есть в процессе аутентификации первичной пользователь автоматически инициировался подсистемным пользователем 1С.

203
00:21:36,400 --> 00:21:46,400
А после этого уже внутри, на базе 1С выполнялась регистрация и та же аутентификация, но уже внутренние методы.

204
00:21:46,400 --> 00:21:54,400
Это нас привлекло. Мы заметили в логах утечку от системного пользователя.

205
00:21:54,400 --> 00:22:01,400
Провернули ту же историю с даунгрейдом до прямого пути к базе данных.

206
00:22:01,400 --> 00:22:08,400
Мы пытались перебрать пароль к этому пользователю. Не увенчалось успехом.

207
00:22:08,400 --> 00:22:14,400
И после 10 попыток мы столкнулись с тем, что учетная запись была заблокирована.

208
00:22:14,400 --> 00:22:16,400
Собственно, почему это было?

209
00:22:16,400 --> 00:22:22,900
Из-за того, что системные учетные записи используются в процессе аутентификации, в процессе редириктов до аутентификации.

210
00:22:22,900 --> 00:22:30,400
Таким образом, заблокировав учетную запись, мы заблокировали полностью национал администрации и аутентификации для пользователей порталов.

211
00:22:34,400 --> 00:22:42,400
После мы начали проверять дальше, начали смотреть, так как у нас был путь прямой до аутентификации, до базы.

212
00:22:42,400 --> 00:22:45,680
Вот, национально мы были на именно пользователя 1С.

213
00:22:45,680 --> 00:22:48,640
Вот, начали отходить легитимную регистрацию.

214
00:22:48,640 --> 00:22:51,580
Внутри получается решение самого портала.

215
00:22:51,580 --> 00:22:53,620
Вот, все делали легитимно, красиво.

216
00:22:53,620 --> 00:22:56,180
Нам пришли входить на почек, все хорошо.

217
00:22:56,180 --> 00:22:59,360
Проблема заключалась в том, что для того, чтобы попасть внутрь портала

218
00:22:59,360 --> 00:23:01,680
и дотянуться до какого-то функционала,

219
00:23:01,680 --> 00:23:04,220
нам нужно было получить аппроф от админара.

220
00:23:04,220 --> 00:23:08,720
А аппроф этот, ну, как я понял, просто так ты не получаешь.

221
00:23:08,720 --> 00:23:19,880
связываться немножко короче в бюрократии вот это все замечено что все таки мы какую-то хотя бы часть

222
00:23:19,880 --> 00:23:33,240
часть на статиста что мы практически то акулы же им пользоваться через штатный механизм один

223
00:23:33,240 --> 00:23:38,740
В Web1DNS по прямому пехватику, по прямому окно операции нам удалось сбросить пароль.

224
00:23:38,740 --> 00:23:41,740
Через тот же штатный функционал забыли пароль. Мы восстановились.

225
00:23:41,740 --> 00:23:46,740
Все, после этого мы попали уже в портал и начали изучать функциональный стан.

226
00:23:49,240 --> 00:23:53,240
Попрыли кнопочки, всякие интересности.

227
00:23:53,240 --> 00:23:57,240
И было замечено, что в штатном методе перепоходить открытие формы.

228
00:23:57,240 --> 00:24:01,240
То есть в Web1DNS работает достаточно специфично.

229
00:24:01,240 --> 00:24:15,420
То есть мы когда запрашиваем какую-то форму, когда хотим что-то открыть, мы сначала запрашиваем список доступных, можно их назвать патологами, если точнее, патолог HTF.

230
00:24:15,420 --> 00:24:22,580
То есть, грубо говоря, ссылка, куда мы должны сходить, что нам должно открыться, что нам должно вернуть беп и что должно отрасывать на хром.

231
00:24:22,580 --> 00:24:29,980
вот этот как раз возникли странности у нас раскрылась распространясь полпе

232
00:24:29,980 --> 00:24:35,420
там начали перебирать смотреть почему вообще можно дотянуться с

233
00:24:35,420 --> 00:24:43,320
смотри мы дотянуться по списка пользователей то есть инициировалась как вообще работала то есть

234
00:24:43,320 --> 00:24:48,960
при попытке открыть любую легитимную форму помирался запрос кей мы с очень-очень

235
00:24:48,960 --> 00:24:56,160
дополнительных метров. И как раз параметры OK мы сманипулировали, подставили из полкрефа,

236
00:24:56,160 --> 00:25:04,560
грубо говоря, остаточное описание и получили форму, отрисовку нелегитимной формы в легитимном функционале.

237
00:25:05,440 --> 00:25:10,640
Вообще, начали смотреть, что еще происходит, что мы еще можем сделать, так как мы можем

238
00:25:10,640 --> 00:25:17,760
манипулировать, мы можем дотягиваться до списка файлов, можем дотягиваться до персональных данных,

239
00:25:17,760 --> 00:25:19,400
сотрудников,

240
00:25:20,000 --> 00:25:21,960
контрагентов и так далее.

241
00:25:23,060 --> 00:25:24,260
Но что еще

242
00:25:24,260 --> 00:25:25,760
в общем можем получить про мечтение?

243
00:25:30,680 --> 00:25:31,880
Ну, это вот как раз сайт

244
00:25:31,880 --> 00:25:34,100
о том, что контакт-поставщиков утекает,

245
00:25:34,180 --> 00:25:34,980
правила утекают.

246
00:25:36,880 --> 00:25:38,020
Что мы можем получить?

247
00:25:38,140 --> 00:25:39,720
Здесь, конечно, на сайте не будет,

248
00:25:39,720 --> 00:25:41,800
но через манипуляцию

249
00:25:41,800 --> 00:25:43,600
как раз, вы помните, что у нас веб,

250
00:25:43,680 --> 00:25:45,380
через манипуляцию от сервера

251
00:25:45,380 --> 00:25:46,740
удалось немножко

252
00:25:46,740 --> 00:25:49,780
JS попробовать, и удалось

253
00:25:49,780 --> 00:25:51,080
позначировать кнопки.

254
00:25:51,960 --> 00:25:52,820
И, на удивление,

255
00:25:54,740 --> 00:25:55,980
кнопки формировали

256
00:25:55,980 --> 00:25:57,780
легитимные события, и так как

257
00:25:57,780 --> 00:25:59,860
с низкоперегированными пользователями

258
00:25:59,860 --> 00:26:01,580
мы имеем ограничения, только, грубо говоря,

259
00:26:02,060 --> 00:26:03,340
по кнопкам интерфейса,

260
00:26:03,700 --> 00:26:05,840
но внутри, наоборот, мы не имеем никаких ограничений,

261
00:26:05,940 --> 00:26:07,860
и формируем легитимное какое-то событие.

262
00:26:08,560 --> 00:26:09,900
Нам удалось провести

263
00:26:09,900 --> 00:26:11,580
нам удалось провести

264
00:26:11,580 --> 00:26:12,340
а то

265
00:26:12,340 --> 00:26:15,640
с низкоперегированными пользователями, и таким образом мы получили

266
00:26:15,640 --> 00:26:17,880
администратора портала.

267
00:26:18,160 --> 00:26:19,740
То есть фактически ничего не ломает,

268
00:26:19,840 --> 00:26:22,080
просто немножко, посмотрев кур, посмотрев логи,

269
00:26:23,560 --> 00:26:24,100
имеем, собственно,

270
00:26:24,280 --> 00:26:25,320
доступ уже

271
00:26:25,320 --> 00:26:28,020
к более обширной информации,

272
00:26:28,460 --> 00:26:30,100
ну, также по персональным данным,

273
00:26:30,220 --> 00:26:31,500
также коммерческой тайне,

274
00:26:31,880 --> 00:26:32,900
вот, и ведет это

275
00:26:32,900 --> 00:26:36,060
к тому, что, ну, массово

276
00:26:36,060 --> 00:26:37,260
раскрыто персональных данных,

277
00:26:37,460 --> 00:26:38,780
вид чувствительной информации,

278
00:26:39,820 --> 00:26:41,220
ну, выполнение произведенных глоб

279
00:26:41,220 --> 00:26:44,280
из первого кейса, и вот что немало важное,

280
00:26:44,280 --> 00:26:47,180
демонстрации возможностей финансовых и репутационных рисков.

281
00:26:48,100 --> 00:26:51,760
То есть, имея у себя на порту 1С, выставляя ее в интернет,

282
00:26:52,360 --> 00:26:55,660
есть шанс того, что что-то пойдет не так,

283
00:26:56,940 --> 00:27:00,260
а так также остается все еще дешевый,

284
00:27:00,360 --> 00:27:03,280
есть риск того, что потери эти будут.

285
00:27:03,280 --> 00:27:09,940
Мы показали на большом объеме данных,

286
00:27:10,000 --> 00:27:13,060
но это касается также и малого и среднего бизнеса.

287
00:27:13,060 --> 00:27:17,500
с 11, ну, да, кто выставляет интернет. Передаю слово.

288
00:27:18,660 --> 00:27:20,660
Да, спасибо.

289
00:27:21,460 --> 00:27:29,060
Следующая история, пару кейсов, связана с платформой мониторинга.

290
00:27:29,060 --> 00:27:38,660
Эти платформы сами по себе очень склонны, по своей природе склонны по единственным типом SSR.

291
00:27:38,660 --> 00:27:48,660
потому что платформа для мониторинга это обычно подключить какие-то data source и как-то их графически отобразить.

292
00:27:50,660 --> 00:27:54,660
Этот кейс первый не про SSR.

293
00:27:54,660 --> 00:28:07,660
Здесь мы столкнулись с платформой мониторинга, в которой был не авторизованный доступ ко всем dashboard-дам и data source.

294
00:28:07,660 --> 00:28:18,160
Соответственно, неавторизованный доступ на мониторинге на платформе означает, что в эти data source можно ходить.

295
00:28:18,160 --> 00:28:30,660
Что такое обычно data source? Это обычно какие-то базы данных и что-то похожее. Откуда данные тянуть, чтобы их потом графически отображать.

296
00:28:30,660 --> 00:28:38,260
Соответственно, один из датасорсов оказался базой MySQL.

297
00:28:38,260 --> 00:28:47,460
Причем помимо просто просмотра датам этого датасорса, а то, что уже настроено в самой системе мониторинга,

298
00:28:47,460 --> 00:28:58,260
так как у нас получается не авторизованный доступ, мы, соответственно, можем как-то по-своему настраивать отображаемые данные.

299
00:28:58,260 --> 00:29:04,120
Что такое настройка отображаемых данных, когда у вас датасорс это MySQL, это по сути запрос в эту базу данных.

300
00:29:04,240 --> 00:29:04,960
То есть запрос в MySQL.

301
00:29:05,560 --> 00:29:07,020
Соответственно, здесь именно так и было.

302
00:29:07,140 --> 00:29:13,820
То есть просто не авторизовано можно было делать прям запросы в базу данных.

303
00:29:13,820 --> 00:29:20,820
Например, вывести юзера, либо посмотреть пароли, имена и так далее.

304
00:29:20,820 --> 00:29:34,520
Ну и здесь на слайде уже видно, что это, к тому же, была не просто какая-то там случайная база данных, это еще и была база данных Asterisk, то есть это система IP-телефонии.

305
00:29:35,740 --> 00:29:45,720
Соответственно, можно было делать запросы в эту базу данных, в которой как бы хранится информация, связанная с IP-телефонией.

306
00:29:45,720 --> 00:29:57,120
Ну и собственно здесь риск, который был реализован довольно быстро, да, так как это база MySQL, мы там и файлики подгрузили, и файлики читать смогли.

307
00:29:57,120 --> 00:30:06,840
Но самое основное, что в итоге было реализовано, недопустимое событие, это то, что в этой базе данных, собственно, хранятся разговоры,

308
00:30:06,840 --> 00:30:11,460
то есть записи разговоров, которые были по IP-телефонии,

309
00:30:11,460 --> 00:30:16,880
по виду файлов можно видеть, что они есть внешние, есть внутренние.

310
00:30:16,880 --> 00:30:22,060
И здесь весь риск был в том, что мы такие файлы смогли прочитать.

311
00:30:22,060 --> 00:30:31,140
То есть получили доступ к крайне критичной внутренней информации про записи разговоров.

312
00:30:31,140 --> 00:30:39,140
И следующий кейс, если честно, поместился весь на один слайд, мы сами довольно удивились.

313
00:30:39,140 --> 00:30:49,140
Собственно, это была тоже мониторинговая платформа, в которой была форма, функциональность создания отчетов,

314
00:30:49,140 --> 00:30:59,140
мы их замазали, что-то PHP, и можно было передавать линк, который предполагался, что это будут локальные файлы,

315
00:30:59,140 --> 00:31:04,820
Это обходилось значком собачки, то есть можно было сделать SSRF.

316
00:31:04,820 --> 00:31:13,320
У нас было крайне большое удивление, когда мы сделали такой запрос на наш интерактиссар сервер,

317
00:31:13,320 --> 00:31:21,120
и запрос со стороны уязвимого сервера прилетел вместе с заголовком authorization,

318
00:31:21,120 --> 00:31:25,620
в котором в бейсике были учетные данные.

319
00:31:25,620 --> 00:31:28,520
Мы подумали, что это что-то очень странное.

320
00:31:28,520 --> 00:31:37,880
Тем не менее, на внешнем периметре было много различных порталов,

321
00:31:37,880 --> 00:31:43,240
куда можно было попробовать эти учетные данные, и они подошли.

322
00:31:43,240 --> 00:31:49,640
Причем они подошли к SEL-VPN порталу, это оказались еще и доменные учетные данные.

323
00:31:49,640 --> 00:31:56,680
То есть здесь за один запрос открыты оборота в внутренний клинику.

324
00:31:56,680 --> 00:32:02,020
То есть за один запрос мы получили доступ к внутренней сети.

325
00:32:02,400 --> 00:32:05,540
Соответственно, для нас, как мы говорили, мы считаем это недопустимым событием.

326
00:32:06,640 --> 00:32:13,220
Ну, еще стоит сказать, что ЭПССР еще и так, ну, не закручивалось, точнее, тут уже риск серьезный.

327
00:32:13,220 --> 00:32:27,900
Она еще и предоставляла аккаунт takeover. Если эту ссылку нажать пользователю в зарегистрированном системе, запрос прилетал вместе с юзером паролем в get-запросе.

328
00:32:27,900 --> 00:32:34,520
В параметрах get-запроса. Тут еще аккаунт takeover. Причем юзер пароль открытом в битве прилетал.

329
00:32:34,520 --> 00:32:43,180
В общем, тут мы нарвались на что-то очень древнее, что предоставило нам доступ во внутренние периметры.

330
00:32:43,300 --> 00:32:55,400
Ну и, соответственно, здесь реализованы недопустимые события, как я сказал, это получение доступа во внутреннюю сеть и получение несанкционированного доступа к записям телефонных разговоров в системе и телефонные.

331
00:32:56,620 --> 00:32:57,620
Рома, передам сейчас.

332
00:33:04,520 --> 00:33:13,000
Следующий блок вообще о пасеке. Наверное, все знают об инъекциях. Уже везде много раз поговорил, много кто писал. Во всех станираторах уже давно встроено.

333
00:33:13,000 --> 00:33:19,820
То есть здесь, опять же, не столь о каких-то технических историях, столь об импакте.

334
00:33:20,780 --> 00:33:26,440
Первый кейс. В коде был обнаружен параметр, была обнаружена SQL-лекция.

335
00:33:28,020 --> 00:33:34,900
И при изучении ОКДшки был обнаружен тоже, да, у нас есть логин, да, у нас есть пароль,

336
00:33:35,000 --> 00:33:41,560
но он был в современном, в закрешированном современном алгоритме и не подвержен дошифрованию.

337
00:33:41,560 --> 00:33:49,960
назад его не получу немного грустно казалось бы но нет соседи таблицы соседи таблички в колонке

338
00:33:49,960 --> 00:34:01,180
виде пользователя полностью полностью скипает проверку и безопасное хранение пароля также

339
00:34:01,180 --> 00:34:06,620
заходим получаем доступ к вы меняем пароли и в общем делаем что хотели

340
00:34:07,980 --> 00:34:13,500
тройки у нас нужно смещать блок пера про что рассказывал просто вы пароли то

341
00:34:13,500 --> 00:34:19,700
есть у нас есть выбор он закрыт достаточно спичат реализован

342
00:34:19,700 --> 00:34:26,220
пином не просто пином перебрали

343
00:34:26,220 --> 00:34:33,660
попали в обнаде этого приложения, начали изучать. Также в параметре была обнаружена SQL-реакция,

344
00:34:33,660 --> 00:34:39,460
но тут немножко поинтереснее. Тут был пройден путь до эскалации.

345
00:34:39,460 --> 00:34:51,900
То есть внутри был не строгий баг, и это позволило через URL-кодирование, ну, собственно, в IT.

346
00:34:51,900 --> 00:35:00,900
Установили, что Суббд — микрософский сервер, имя пользователя — цензура.

347
00:35:00,900 --> 00:35:09,900
И пользователь также обладает поезд данных правами суперадминистратора и включен доступ в модуль XP.md shell.

348
00:35:09,900 --> 00:35:14,900
Ну, собственно, пару запросов и получили RCE.

349
00:35:14,900 --> 00:35:20,900
Опять же, атака получилась дешевой. Это был 2026 год. Все еще это доступно. Все еще это существует.

350
00:35:20,900 --> 00:35:33,460
Смс также массовое раскрытие персональных данных и чувствительных информации, компрометация всех пользователей порталов по кейс-1 и выполнение произвольных команд на хостях.

351
00:35:33,460 --> 00:35:40,640
Спасибо. Следующий кейс довольно быстрый.

352
00:35:40,640 --> 00:35:43,320
Ну тут тоже опять два кейса, на самом деле.

353
00:35:43,860 --> 00:35:46,080
Это история про CMS и модули в них.

354
00:35:46,800 --> 00:35:51,640
CMS по своей природе – это обычно просто движок, который расширяется

355
00:35:51,640 --> 00:35:58,540
либо различными модулями, либо самописными чем-то, плагинами и так далее.

356
00:35:59,460 --> 00:36:03,600
Ну и, соответственно, это часто приводит к серьезным последствиям,

357
00:36:03,660 --> 00:36:08,100
потому что если в движке еще следят за безопасностью,

358
00:36:08,100 --> 00:36:16,100
то в модулях, особенно в самописных, мы часто встречаемся с тем, что там все совсем плохо.

359
00:36:16,100 --> 00:36:20,100
Ну и здесь на самом деле хрестоматийный пример файлоплода,

360
00:36:20,100 --> 00:36:25,100
то есть у нас просто есть форма, в которой можно прикрепить файл.

361
00:36:25,100 --> 00:36:31,100
Здесь просто прикреплялся файл, соответственно можно было прикрепить HP,

362
00:36:31,100 --> 00:36:38,820
И потом его найти, он в папочке что-то типа TMP-отвод или что-то такое лежал.

363
00:36:38,820 --> 00:36:44,320
Ну и соответственно все. Здесь RCE просто одно очень простое действие,

364
00:36:44,320 --> 00:36:52,220
но если говорить про недопустимые события, исполнение хода, понятно, что мы уже считаем пробивом.

365
00:36:52,220 --> 00:37:06,540
Но здесь все усугублялось тем, что на хосте была обнаружена табличка с персональными данными, которых было более чем 400 тысяч.

366
00:37:06,540 --> 00:37:15,180
На таком легко пробиваемом портале довольно неожиданная была находка.

367
00:37:15,180 --> 00:37:26,180
Еще оказалось, что это не просто хвостинг какой-то, здесь есть связь с внутренним переменком компании.

368
00:37:26,180 --> 00:37:35,180
Здесь, собственно, довольно критичные последствия с довольно простой эксплуатацией.

369
00:37:35,180 --> 00:37:43,180
И следующий кейс с неузнаваемой CMS, ее можно не замазывать, и так никто не узнает.

370
00:37:43,180 --> 00:37:56,180
Да, это Gitrix и здесь модуль, который позволял делать импорт-экспорт-файл.

371
00:37:56,180 --> 00:38:03,180
Тут вся уязвимость из интерфейса прямо на пике в области.

372
00:38:03,180 --> 00:38:09,780
То есть здесь прямо подписано, можно было просто вставить пикфайл, в этом пути можно было написать etc.psvd,

373
00:38:09,780 --> 00:38:17,780
и выпадала ссылка, в которой любезно предоставлялся этот файл.

374
00:38:17,780 --> 00:38:24,180
То есть здесь localfile.read, соответственно, можно было читать произвольные файлы.

375
00:38:24,180 --> 00:38:31,180
Такие два кейса. Здесь просто такой вывод, который мы специфически тоже подтвердим,

376
00:38:31,180 --> 00:38:38,180
что на CMS много всего находится за счет природы,

377
00:38:38,180 --> 00:38:44,180
того, что они очень модульные, модули пишутся разными людьми и так далее.

378
00:38:44,180 --> 00:38:49,180
Про CMS здесь это удаленное выполнение коды и массовое распределение персональных данных.

379
00:38:49,180 --> 00:38:51,180
Передам потом.

380
00:38:51,180 --> 00:38:53,180
Спасибо.

381
00:38:57,180 --> 00:39:05,180
Следующий блок вообще в принципе непроизимости. Он скорее про то, что есть и про то, что не стоит забывать вообще списывать за счетом.

382
00:39:05,180 --> 00:39:14,180
Это богатая документация. Вообще этот блок происходит про недооцененные источники разведки.

383
00:39:14,180 --> 00:39:17,180
Документацию как раз да и технические какие-то артефакты.

384
00:39:17,180 --> 00:39:47,160
во время теста, ну часто так бывает, что не сразу лобби же вломать, вставлять и так далее, а если видимо какой-то возможно коробочный, то стараемся найти документацию, стараемся почитать вообще о чем там, что там, что мы можем сделать, сильно ли стоит нам вообще тратить на эти ресурсы свои силы, вот если это еще в контексте ограниченного какого-то времени, вот, но так привело, что вообще документацию у нас в группе достаточно хорошо описаны, и это классно, это здорово,

385
00:39:47,180 --> 00:39:52,640
это облегчение для администраторов и для пользователей этих платформ но с другой стороны есть

386
00:39:52,640 --> 00:39:57,740
атакующие для которых это документация также очень хорошо для составления какой-то пологи

387
00:39:57,740 --> 00:40:04,760
для выяснения ручек опишек и все подобного на сайте мы можем обратить внимание что что

388
00:40:04,760 --> 00:40:12,260
документацию можно обнаружить то что подминки нас ждет выполнение 3 4 под заметь и поля позволяющий

389
00:40:12,260 --> 00:40:14,260
в чёрную собственную PHP форму.

390
00:40:14,260 --> 00:40:18,260
Ну тут предлагаю, конечно, применить к текстовому шаблону какие-то запросы сделать.

391
00:40:18,260 --> 00:40:21,260
Нас это не интересует, нас интересует, что из этого мы сделаем RCR.

392
00:40:21,260 --> 00:40:25,260
И наша задача будет пробиться туда внутрь и, ну, уж вяжем их на спуск.

393
00:40:27,260 --> 00:40:33,260
При этом всё, отдельные классы в этой документации — это дополненные учётные записи.

394
00:40:33,260 --> 00:40:37,260
А иногда супер высокоприволевированные дополненные учётные записи.

395
00:40:37,260 --> 00:40:40,260
Вот, человеческий фактор, раскачивающийся человеческим фактором,

396
00:40:40,260 --> 00:40:48,760
Иногда это протекает консервная конфигурация, это бывает накатили, забыли убрать, может тестировали, забыли убрать, может вроде поставили, забыли, неважно.

397
00:40:48,760 --> 00:41:02,140
В общем, приводит это к тому, что опять так же, просто погуглив, почитав документацию, посмотрев, что это ZPO, можно одним запросом, грубо говоря, получить достаточно высокий пакт, проникнуть в админку.

398
00:41:02,140 --> 00:41:08,580
просто на основе того, что ты знаешь, что вообще документация есть, что существует на такой поиске.

399
00:41:08,580 --> 00:41:11,140
Ну, роль там достаточно такая привязанная.

400
00:41:13,140 --> 00:41:15,140
При этом всём там поиска документации.

401
00:41:15,140 --> 00:41:19,640
У нас были такие кейсы, что иногда блок не получается найти.

402
00:41:19,640 --> 00:41:27,140
Иногда бывает такое то, что ПО уже не он, и уже сайтики закрыты, как у кого ничего нет.

403
00:41:27,140 --> 00:41:32,520
Веб-архив приходит нам на помощь, пожалуйста, подрядки очень классно хранить.

404
00:41:32,520 --> 00:41:39,160
В этих самых подряд можно найти тоже очень достаточно интересную информацию, которая фактически оказывается правдой.

405
00:41:39,160 --> 00:41:43,580
Ну, порой также. Достаточно реальный.

406
00:41:45,700 --> 00:41:50,660
Достаточно частичный источник тоже вы отнесут глупу. Вообще, это пап-файлы, source maps.

407
00:41:50,660 --> 00:41:56,580
Вот, тоже очень частая история. Часто позже объясню, почему именно документация отнес.

408
00:41:56,580 --> 00:42:00,380
Сорс-мапы очень часто много в себе что раскрывают.

409
00:42:00,380 --> 00:42:04,820
Вот много-много громких кейсов в последнее время, в 26-м году, все там сливают.

410
00:42:04,820 --> 00:42:08,740
Все в этом пишут, паникуют. Все еще есть в 26-м году.

411
00:42:08,740 --> 00:42:14,240
Вообще так используется для отладки, но опять же свои хайкеры пришли, все что-то посмотрели, все что-то поломали.

412
00:42:17,020 --> 00:42:22,820
Вот, в данном случае в мапе от стан-сервера были креда.

413
00:42:22,820 --> 00:42:25,780
Обращайте внимание на то, что тур будет отстана.

414
00:42:25,780 --> 00:42:28,920
Удалось запроксироваться, проверить гипотезу.

415
00:42:28,920 --> 00:42:33,540
Да, до IP мы ходим через проксу и все ок.

416
00:42:33,540 --> 00:42:37,000
Опять же тоже просто посмотрев mapfile.

417
00:42:40,360 --> 00:42:41,640
Pro.ns.

418
00:42:41,640 --> 00:42:46,840
Опять же, уже классический получение доступа к критичным активам, персональным данным, документам.

419
00:42:47,840 --> 00:42:52,340
И тут еще немаловажный момент — это развитие атаки после.

420
00:42:52,340 --> 00:43:03,200
Это поиск 0D-илюзимости, эскалация до каких-то критических находок внутри интеркейсов, которые стали доступны вследствие применения информации из документации.

421
00:43:03,660 --> 00:43:11,960
То есть часто случается так, что первичный самый сложный этап — это пробиться внутрь, а внутри уже всякие интересные находочки.

422
00:43:14,300 --> 00:43:15,460
Передаю микрофон.

423
00:43:15,460 --> 00:43:32,460
По кейсам у нас все, соответственно какие выводы из этого все мы можем сделать и какие ошибки чаще всего дают атакующим реализовать недопустимые события, то на примере кейсов мы, конечно, никого не уделим.

424
00:43:32,460 --> 00:43:37,920
довольно стандартный, что обычно реализация недопустимого события — это комплексная проблема,

425
00:43:37,920 --> 00:43:43,620
которая зачастую троится не в одной конкретной уязвимости, а в комплексе проблем.

426
00:43:43,620 --> 00:43:52,460
Мы в основном выделили на наших примерах слабый контроль за внешним периметром и публикация,

427
00:43:52,460 --> 00:43:58,660
критичный систем, проблемы с учетами данными, которые до сих пор встречаются,

428
00:43:58,660 --> 00:44:00,700
избыточные привилегии,

429
00:44:01,200 --> 00:44:02,660
проблемы с контролем доступа

430
00:44:02,660 --> 00:44:04,600
и избыточное раскрытие информации.

431
00:44:05,160 --> 00:44:05,520
Обычно

432
00:44:05,520 --> 00:44:08,780
реализация недопустимых

433
00:44:08,780 --> 00:44:10,400
событий — это

434
00:44:10,400 --> 00:44:11,580
какой-то комплекс

435
00:44:11,580 --> 00:44:14,180
из этих проблем.

436
00:44:14,880 --> 00:44:16,500
Ну и да, стоит, наверное,

437
00:44:16,500 --> 00:44:18,080
выделить, что проблем access control,

438
00:44:18,220 --> 00:44:20,700
который у нас эстетически оказался

439
00:44:20,700 --> 00:44:21,860
наиболее частым,

440
00:44:23,120 --> 00:44:23,620
также идет

441
00:44:23,620 --> 00:44:26,500
одна эта уязвимость может вести

442
00:44:26,500 --> 00:44:28,620
к реализации

443
00:44:28,620 --> 00:44:30,500
недопустимых событий.

444
00:44:32,600 --> 00:44:33,820
Немного посмотрим

445
00:44:33,820 --> 00:44:35,780
на соотношение

446
00:44:35,780 --> 00:44:37,660
типов ПО

447
00:44:37,660 --> 00:44:40,160
к уязвимостям, которые были на них

448
00:44:40,160 --> 00:44:41,740
найдены, какие там

449
00:44:41,740 --> 00:44:43,820
характерные уязвимости.

450
00:44:45,260 --> 00:44:45,960
У нас там

451
00:44:45,960 --> 00:44:47,720
выделилось два

452
00:44:47,720 --> 00:44:49,600
типа ПО, это CMS,

453
00:44:49,600 --> 00:44:51,340
на них

454
00:44:51,340 --> 00:44:53,740
из-за их природы,

455
00:44:53,780 --> 00:44:55,000
про которую я уже говорил,

456
00:44:55,000 --> 00:45:05,260
Довольно большой набор различных уязвимостей. На нашем опыте наиболее часто это CSRF и iDoor.

457
00:45:05,260 --> 00:45:13,760
И также выделяется тип по мониторинговой платформе. У них явно выделяется тип уязвимости

458
00:45:13,760 --> 00:45:20,320
СССР, про который уже тоже говорил, связано с природой

459
00:45:20,320 --> 00:45:22,480
самого программного обеспечения.

460
00:45:23,880 --> 00:45:28,600
И еще один слайд с большой цифрой.

461
00:45:29,520 --> 00:45:32,720
Да, мы заметили, что на нашем опыте, по крайней мере,

462
00:45:32,720 --> 00:45:38,940
11-напрайз, который выстрелил во внешний периметр, приводит

463
00:45:38,940 --> 00:45:43,800
к ненепустимому событию в 87% случаев.

464
00:45:43,800 --> 00:45:50,060
Но стоит признать и сказать, что крайне редко встречается на внешнем периоде.

465
00:45:50,960 --> 00:45:54,000
Теперь расскажем про какие контролы,

466
00:45:54,000 --> 00:46:05,900
как можно ломать цепочки ненепустимых событий и предотвращать эти уязвимости.

467
00:46:05,900 --> 00:46:07,900
Представим, передам слова.

468
00:46:15,900 --> 00:46:28,900
Вообще, controls и контроль в группе это не какая-то там жестко захардоженная метрика, это вообще наше просто человек понимаемое условность, которую мы хотим принести.

469
00:46:28,900 --> 00:46:40,580
Принести. То есть про кейс, про то, что мы рассказывали, есть в любом случае небольшая такая схожесть прослеживается, что первичный доступ получен каким-то таким достаточно реальным способом.

470
00:46:40,580 --> 00:46:46,620
Где-то внутри паралек, что-то не сошлось, где-то мы еще доступ получили.

471
00:46:46,960 --> 00:46:56,840
То есть основная суть контроля, это еще раз приобрести такое, я думаю, защитник прекрасный экран защищаться, разработчики прекрасный экран, выставить отличный защищенный экран.

472
00:46:56,840 --> 00:47:05,240
Но тем не менее мы все еще находим, все еще у нас есть работа, поэтому хотел бы сказать, то есть первый контроль, и не основные, расскажу про четыре.

473
00:47:06,100 --> 00:47:12,160
Первый это object level authorization, ну то есть он вообще про то, чтобы тестировать систему.

474
00:47:12,160 --> 00:47:25,560
Тестировать систему на то, что низкопривилегированный пользователь не может получать данные, допустим, высокопривилегированного или там соседнего какого-то, ну, горизонтальные, имею в виду, перемещения, тайгуры, паки.

475
00:47:25,560 --> 00:47:27,280
вся вот эта вот классика.

476
00:47:28,100 --> 00:47:29,700
То, что не аутентифицированных

477
00:47:29,700 --> 00:47:31,880
злоумышленных, ну, атакующих

478
00:47:31,880 --> 00:47:33,760
пользователей может получать какие-то

479
00:47:33,760 --> 00:47:35,900
данные там, где он не должен

480
00:47:35,900 --> 00:47:37,520
их получать. То есть я иду к тому,

481
00:47:37,620 --> 00:47:39,560
даже, ну, если

482
00:47:39,560 --> 00:47:41,380
считаете, что ваше положение защищено,

483
00:47:41,440 --> 00:47:42,820
допустим, хорошо защищено

484
00:47:42,820 --> 00:47:45,580
авторизацию,

485
00:47:45,800 --> 00:47:47,460
ну, там, допустим, в вашем случае есть что-то такое,

486
00:47:47,520 --> 00:47:49,440
второй фактор. При этом все,

487
00:47:49,800 --> 00:47:51,440
ну, не стоит списывать счетов, еще тот момент,

488
00:47:51,440 --> 00:47:53,200
что национальные злоумышленные также

489
00:47:53,200 --> 00:48:00,680
Если говорить о короче, то накатите у себя, допустим, демочку или где-то там интернет найти бывает.

490
00:48:01,000 --> 00:48:02,480
Также это все посмотреть, проверить.

491
00:48:02,580 --> 00:48:06,100
Если не сделали вы, я говорю к тому, что это сделает кто-то за вас.

492
00:48:06,620 --> 00:48:10,120
И будет хорошо, если в каком-то хорошем подробке себя окажется.

493
00:48:10,820 --> 00:48:15,500
Второй контроль — это централизованная авторизация.

494
00:48:15,500 --> 00:48:18,560
Вот как раз про то, что происходит, про все такое.

495
00:48:18,560 --> 00:48:28,160
то что в идеале как бы что-то критичное хранить либо засошкой, либо точно заставим фактором,

496
00:48:28,160 --> 00:48:32,880
и не пропускать потенциального злоумышленного к ней.

497
00:48:32,880 --> 00:48:34,720
Ну например, допустим, даже одиннадцать.

498
00:48:34,720 --> 00:48:39,680
Если бы два файла висела, то маловероятно, что получился бы блок,

499
00:48:39,680 --> 00:48:41,680
получилось бы что-то искать про это интересное.

500
00:48:41,680 --> 00:48:55,680
Следующий блок — это лист привилегий. То есть вообще про что? Ну, то есть в принципе понимаемых привилегий — не давать привилегий больше кому пользователю, сколько нужно.

501
00:48:55,680 --> 00:49:07,680
То есть низко привилегированный, опять же, не должен иметь доступ к каким-то системным функциям, не должен иметь возможность выполнять какой-то административный функционал, зергнуть какие-то ручки и так далее.

502
00:49:07,680 --> 00:49:14,680
Опять же как с K7, с цепей инъекции. Особого смысла там суперадминов давать не было, но это было.

503
00:49:14,680 --> 00:49:20,680
Ввиду к тому, что не стоит так делать, если возможно избегать.

504
00:49:22,680 --> 00:49:35,680
И четвертый — это у нас RAID-лимитер. Это как раз по истории с грудным OTP, с паролем, с DOS и со всей такой историей.

505
00:49:35,680 --> 00:50:00,400
Вот никто не запрещает как бы все вместе применять, комбинировать и тем самым, опять же, мы говорили про дешевую атаку, это будет являться, ну можно сказать, дешевой защитой от силуэтта и это будет рвать и на исход. Ну в случае ред-лимитов, например, ну на инаме, там столько количества пользователей, но при этом все, там ты не можешь потом спрейтить пароль, ты не можешь их грузить, ты там, условно, падаешь, падаешь.

506
00:50:00,400 --> 00:50:11,160
вот то есть главный вывод опять же да про то что все четыре контроля и небольшая там

507
00:50:11,160 --> 00:50:20,900
не только не остануешься и не так интересно снова в том что применять и тестировать все еще

508
00:50:20,900 --> 00:50:26,320
нужно применять тестировать нужно для простых бага для простых бага тем более не отталкиваться

509
00:50:26,320 --> 00:50:31,880
только на метрике CvSS, потому что все веги, которые мы рассматривали,

510
00:50:31,880 --> 00:50:37,920
там можно смело вешать PR-high и все на этом отдыхать.

511
00:50:38,020 --> 00:50:38,580
Но это не так.

512
00:50:38,840 --> 00:50:43,100
То есть фактически критичность в какой-то до критикал взлетает,

513
00:50:43,560 --> 00:50:47,440
а так на руках имеем внутривиальные способы байпаса и вот это как раз переведение.

514
00:50:49,840 --> 00:50:50,540
Передаю так.

515
00:50:50,660 --> 00:50:53,700
Да, мы тут немножко, кажется, вышли за время.

516
00:50:53,700 --> 00:50:56,060
быстро про выводы в целом

517
00:50:56,060 --> 00:50:57,960
всего нашего исследования.

518
00:50:59,360 --> 00:51:00,100
Так как уже сказали,

519
00:51:00,160 --> 00:51:01,380
недопустимые события происходят

520
00:51:01,380 --> 00:51:02,380
из-за комплекса проблем

521
00:51:02,380 --> 00:51:04,700
и, соответственно, решать их нужно комплекс

522
00:51:04,700 --> 00:51:05,740
различным командам,

523
00:51:06,260 --> 00:51:08,100
обсекам следить за

524
00:51:08,100 --> 00:51:10,300
реализацией ролевой модели,

525
00:51:11,040 --> 00:51:12,800
в целом следить за внешним периметром

526
00:51:12,800 --> 00:51:14,780
и так далее.

527
00:51:14,960 --> 00:51:16,440
Приоритизировать можно как атакующие,

528
00:51:16,520 --> 00:51:17,420
так и защитные действия.

529
00:51:17,420 --> 00:51:18,180
То есть, соответственно,

530
00:51:18,760 --> 00:51:20,580
как на слайде предыдущем мы показали,

531
00:51:20,580 --> 00:51:26,200
что какие контролы больше покрывают уязвимостей.

532
00:51:27,280 --> 00:51:31,400
Соответственно, если реализовать набор небольшой из четырех,

533
00:51:31,500 --> 00:51:35,320
то можно закрыть довольно большой пласт уязвимостей.

534
00:51:35,940 --> 00:51:39,860
Соответственно, так и атакующие могут приоритизировать свои проверки

535
00:51:39,860 --> 00:51:44,360
на основе, допустим, тех-тетекта,

536
00:51:44,480 --> 00:51:47,820
либо еще каких-то сигналов с внешнего периода.

537
00:51:47,820 --> 00:51:51,640
и проблемы с учетными данными и контролем доступа.

538
00:51:52,020 --> 00:51:55,060
Это наиболее массовые паттерны, которые мы до сих пор встречаем.

539
00:51:56,400 --> 00:51:59,640
Да, как уже сказали, доклад командный.

540
00:51:59,780 --> 00:52:02,180
Соответственно, на слайде представлена команда.

541
00:52:02,540 --> 00:52:05,960
Всем большое здесь спасибо, кто на этом слайде.

542
00:52:07,820 --> 00:52:11,220
Собственно, кто находил баги, делал ресерчи и так далее.

543
00:52:11,660 --> 00:52:12,500
У нас на этом все.

544
00:52:13,960 --> 00:52:17,720
Если есть временные вопросы, готовы выслушать вопросы. Спасибо.

545
00:52:17,820 --> 00:52:46,940
Использовали яички своих, в принципе, все, да, постоянно

546
00:52:46,940 --> 00:52:49,640
используем, если это какие-то анимизированные данные,

547
00:52:49,640 --> 00:52:55,440
которые никак не касаются заказчиков, то мы используем

548
00:52:55,440 --> 00:52:59,640
облачные, если это что-то критичное, то у нас, естественно,

549
00:53:00,020 --> 00:53:03,560
салфост от решения развернутые, которые мы тоже активно

550
00:53:03,560 --> 00:53:07,500
используем на каждом этапе, наверное, от спинтеста,

551
00:53:07,500 --> 00:53:09,880
до анализа информации и так далее.

552
00:53:16,940 --> 00:53:24,120
Там на самом деле все довольно просто обходится.

553
00:53:24,120 --> 00:53:30,020
То есть если, ну, наверное, есть сейчас уже облачные, которые как-то с этим всем построже,

554
00:53:30,180 --> 00:53:35,660
но в целом если говорить, что вот у меня есть моя система, и я хочу понять, как меня, например, могут взломать,

555
00:53:35,980 --> 00:53:43,120
расскажи мне там 5 наиболее каких-нибудь векторов, то и Ромка все, по крайней мере.

556
00:53:43,120 --> 00:53:48,640
Мы пока не сталкивались с такими, чтобы она не отвечала, а каким-то политикам запрещала.

557
00:53:48,640 --> 00:53:51,040
По крайней мере, салфосты точно.

558
00:54:13,120 --> 00:54:16,860
Чуть-чуть легче ее надо успокоить, что это не так.

559
00:54:16,860 --> 00:54:21,720
Он же так же, что это даже справка, с конколонкой.

560
00:54:21,720 --> 00:54:22,960
Делай свой рот.

561
00:54:22,960 --> 00:54:24,880
И теперь, в этой лепестке.

562
00:54:24,880 --> 00:54:27,120
Они сейчас за это деньги берутся?

563
00:54:27,120 --> 00:54:28,860
Нет, нет, даже за деньги.

564
00:54:28,860 --> 00:54:31,860
А у вас это не стоит.

565
00:54:31,860 --> 00:54:33,940
Уже прошедший перейти за ручку.

566
00:54:33,940 --> 00:54:34,940
Да.

567
00:54:34,940 --> 00:54:36,360
А вот это за ручку.

568
00:54:36,360 --> 00:54:39,860
Ну, а ручка нет.

569
00:54:39,860 --> 00:54:41,940
Вот если перейти за ручку.

570
00:54:41,940 --> 00:54:43,940
Я задавал?

571
00:54:43,940 --> 00:54:45,940
Они, конечно, внизу стоят в следующем записи.

572
00:54:51,940 --> 00:54:52,940
Вопросы?

573
00:54:52,940 --> 00:54:53,940
А, да, вопросы.

574
00:54:53,940 --> 00:54:55,940
Репорт сумма не мало.

575
00:54:57,940 --> 00:54:58,940
Это не по-моему, вообще.

576
00:54:58,940 --> 00:55:04,940
Это 0DA, который мы репортим регулятором, который, соответственно, потом...

577
00:55:04,940 --> 00:55:06,940
Пусть они не собственно платили.

578
00:55:06,940 --> 00:55:13,680
То есть, рекортируем регулятором, который, соответственно, вместе с виндарами это устраняем.

579
00:55:14,260 --> 00:55:15,280
Здесь такая история.

580
00:55:18,480 --> 00:55:19,480
Могли бы нам подманчить дать?

581
00:55:19,880 --> 00:55:20,720
Не усекли бы.

582
00:55:21,720 --> 00:55:22,900
Наверное, могли бы.

583
00:55:23,760 --> 00:55:25,940
Почему регулятором, а не виндарам?

584
00:55:25,940 --> 00:55:26,460
Почему?

585
00:55:29,400 --> 00:55:30,620
Регулятором, а не виндарам.

586
00:55:30,620 --> 00:55:32,620
потому что сложности от всех лендеров.

587
00:55:32,620 --> 00:55:40,940
Мы не хотим усложнять процесс репорта уязвимости.

588
00:55:40,940 --> 00:55:43,900
То есть наша задача, чтобы уязвимость закрыли,

589
00:55:43,900 --> 00:55:48,900
искать различных лендеров, есть ли у них какая-то security policy или нет,

590
00:55:48,900 --> 00:55:54,040
есть ли у них отдельный выделенный почтовый ящик, по которому они принимают репорты или нет.

591
00:55:54,040 --> 00:56:01,040
Есть такая, наверное, отлаженная схема, по которой все приятные.

592
00:56:01,040 --> 00:56:13,040
Да, я просто скажу насчет взаимодействия. На самом деле используют эскоржу в России очень странный.

593
00:56:13,040 --> 00:56:24,540
Ту команду, которую не называют, здесь три раза обещали засудить за последний год, причем через рекорд, через стэк.

594
00:56:24,540 --> 00:56:28,040
После этого мы уже просто...

595
00:56:28,040 --> 00:56:34,540
Если что, когда говорите, что все еще битеры, ну и слипся битеры, а потом слип.

596
00:56:34,540 --> 00:56:39,040
Потому что векторы странные, у них уровень зрелости небольшой,

597
00:56:39,040 --> 00:56:43,140
Особенно тех, у кого это первая BDU, это прилетает.

598
00:56:43,140 --> 00:56:50,680
И вот то, что коллеги говорят про Bounty, мы какой-то хоут выдерживаем.

599
00:56:51,060 --> 00:56:56,460
Если мы нашли на проекте Zero Day, мы отправляем, BDU отреагировал,

600
00:56:56,720 --> 00:57:00,240
вендор отреагировал, раз, два, три, четыре, пять, а сейчас можно Bounty.

601
00:57:00,660 --> 00:57:03,680
Потому что иначе это нечестно.

602
00:57:09,040 --> 00:57:16,220
Спасибо еще раз.