Como explorar IDOR - Pentest e Bug Bounty (WEB HACKING) — Transcript

Full transcript

1. 0:00Essa é uma das vulnerabilidades mais
2. 0:01fáceis de encontrar em programas de
3. 0:03Bugund. Imagine que alterando um simples
4. 0:05número em uma ORL, você consiga acessar
5. 0:08informações confidenciais de outro
6. 0:10usuário, de um sistema. Essa
7. 0:12vulnerabilidade é conhecida como IDOR,
8. 0:14uma sigla para referência direta e
9. 0:16segura a objeto. Muito prazer, eu sou
10. 0:18Luiz Viana, especialista em segurança
11. 0:20ofensiva e neste vídeo a gente vai
12. 0:22dessar a vulnerabilidade a Idor. Você
13. 0:24vai entender o conceito técnico por trás
14. 0:25dessa falha e claro, a gente vai
15. 0:27explorar ela na prática. Você vai
16. 0:29aprender a identificar esse tipo de
17. 0:30falha nos seus penestes ou em programas
18. 0:32de bugund. Bom, vamos lá. O Aidor é uma
19. 0:34vulnerabilidade de controle de acesso
20. 0:36que permite que o atacante consiga
21. 0:38manipular recursos que ele não deveria
22. 0:40ter permissão. Então, na verdade, como
23. 0:41próprio nome já diz, é quando a
24. 0:43aplicação expõe identificadores de
25. 0:45objetos, por exemplo, ids numéricos,
26. 0:48nomes de arquivos, tokens, e utiliza
27. 0:51esses identificadores diretamente nas
28. 0:53consultas e operações sem verificar a
29. 0:56permissão do usuário. Então, na prática,
30. 0:57isso significa que se a aplicação espera
31. 0:59um identificador em uma request, por
32. 1:01exemplo, o ID de um usuário na URL, se
33. 1:03não existir validação, um usuário
34. 1:05malicioso poderia modificar esse
35. 1:06identificador para obter dados de outro
36. 1:08usuário ou realizar ações no nome desse
37. 1:11outro usuário. Por exemplo, olha só
38. 1:12essas URLs aqui. Se a aplicação usa o
39. 1:15valor do parâmetro cliente para acessar
40. 1:17o perfil ou para fazer alguma
41. 1:18modificação, ou no caso aqui de baixo
42. 1:20passa por PEF parâmet, ou seja, o
43. 1:22parâmetro tá dentro da URL, como se
44. 1:24fosse um caminho. Se ela utiliza esse
45. 1:26parâmetro diretamente para acessar os
46. 1:28dados do banco de dados sem validar se o
47. 1:30usuário é realmente aquele cliente ali
48. 1:32que tá fazendo aquela requisição. Basta
49. 1:34trocar esse número aqui e acessar as
50. 1:36informações ou modificar dados de outra
51. 1:38pessoa. Isso aqui é o que a gente chama
52. 1:40de IDOR. É claro que existem infinitos
53. 1:42outros cenários e o mesmo problema pode
54. 1:44ocorrer com arquivos. por exemplo, é
55. 1:46passado ali com o parâmetro o ID de um
56. 1:48extrato bancário. Se não for feita uma
57. 1:50validação, qualquer pessoa passando
58. 1:52aquele ID conseguiria fazer o download
59. 1:54do documento. Pode acontecer em
60. 1:55requisições post, onde os parâmetros são
61. 1:57passados no corpo da request, em alguns
62. 1:59cenários, até nos próprios cookies.
63. 2:00Enfim, qualquer lugar que o usuário
64. 2:02consiga passar um identificador paraa
65. 2:03aplicação pode ser vulnerável. Se não
66. 2:05houver uma validação correta, a gente
67. 2:07consegue simplesmente alterar esse
68. 2:09identificador, principalmente quando é
69. 2:10um identificador enumerável. Ou seja,
70. 2:12são números que crescem. Então, o
71. 2:13usuário um vai ter o ad um, usuário dois
72. 2:15vai ter o ad. Uma forma de resolver
73. 2:17parte desse problema seria utilizar um
74. 2:19ID, ou seja, um identificador único
75. 2:22aleatório. Então, mesmo que tenha um
76. 2:23problema de falta de validação, o
77. 2:25atacante não conseguiria descobrir o
78. 2:26identificador de um outro usuário ou de
79. 2:28algum outro objeto para fazer o ataque.
80. 2:30Mas é claro que o problema ainda existe.
81. 2:32Se ele encontrar alguma forma de
82. 2:33enumerar esses IDs, a falha ainda vai
83. 2:35estar lá. Inclusive, o IDOR pode ser
84. 2:37utilizado para escalar privilégios numa
85. 2:39aplicação também. Então, a movimentação
86. 2:40horizontal é quando você passa aqui uma
87. 2:42ID de um outro usuário com o mesmo nível
88. 2:44de permissão, você consegue efetuar
89. 2:46ações com aquele usuário. Porém, se você
90. 2:48colocar um ID de um administrador, de
91. 2:51algum usuário com mais privilégios que
92. 2:52você, você conseguiria acessar
93. 2:54funcionalidades restritas, dados ainda
94. 2:55mais sensíveis. E essa vulnerabilidade
95. 2:57aqui é extremamente comum. É de longe
96. 2:59uma das falhas mais encontradas em pain
97. 3:01testes e programas de bugund. É um tipo
98. 3:03de falha que praticamente qualquer
99. 3:05pessoa consegue encontrar. Você não
100. 3:07precisa ser o gênio do hacking para
101. 3:09simplesmente alterar um identificador na
102. 3:11URL ou algum campo da aplicação. Bom,
103. 3:13mas vamos deixar de teoria e vamos ver
104. 3:15como explorar essa vulnerabilidade na
105. 3:16prática. Para isso, eu vou utilizar um
106. 3:18dos laboratórios aqui da Solid One.
107. 3:20Inclusive, se você quer se aprofundar em
108. 3:21segurança ofensiva, se tornar um
109. 3:22profissional completo de pain test, você
110. 3:24precisa conhecer a Solid One. Com uma
111. 3:26única assinatura, você vai ter acesso a
112. 3:27dezenas de cursos, laboratórios
113. 3:29práticos, campeonato de hacking entre os
114. 3:31alunos, comunidade, suporte, tudo que
115. 3:33você precisa para se tornar um
116. 3:34profissional no hacking em penest. Mas o
117. 3:36melhor de tudo são as certificações
118. 3:37práticas, ou seja, você vai sair da
119. 3:39Solid One extremamente qualificado e
120. 3:41certificado, pronto pro mercado. Vou
121. 3:43deixar um link no comentário fixado.
122. 3:45Então, beleza. Vamos lá. Eu vou levantar
123. 3:46aqui o laboratório de Wis Shop. Eu tô
124. 3:48aqui na aba de laboratórios da Solid
125. 3:50One. É só clicar aqui em conectar,
126. 3:52beleza? Esperar alguns segundos e meu
127. 3:54servidor totalmente isolado ali para eu
128. 3:55fazer meus testes vai tá pronto. Olha
129. 3:57só, nosso laboratório já ficou pronto, é
130. 3:59só copiar aqui o IP e acessar o lab.
131. 4:01Beleza? Vou abrir aqui o navegador
132. 4:03dentro do meu car Linux e acessar o meu
133. 4:05laboratório. Esse laboratório aqui
134. 4:07simula uma loja online de sucos. Então a
135. 4:09gente tem diversos cenários ali
136. 4:11extremamente realistas, como se fosse um
137. 4:12programa de Bugbound, por exemplo. Então
138. 4:14vamos lá. Olha só, a gente tem diversas
139. 4:15funcionalidades aqui, os produtos, eu
140. 4:18consigo ver os reviews, olha só, eu
141. 4:21consigo criar uma conta. Então vamos lá,
142. 4:23vamos criar uma conta aqui. Não sou um
143. 4:25customer ainda. Criar aqui com o meu
144. 4:27e-mail [email protected].
145. 4:30Não precisa ser um e-mail real. Colocar
146. 4:32uma senha aqui, uma resposta aqui
147. 4:33aleatória. Beleza, registrei, vou logar.
148. 4:37@example.
149. 4:39Beleza, tô logado. Então agora já posso
150. 4:41interagir com as funcionalidades. E aqui
151. 4:43tá uma dica muito legal. Dentro de um
152. 4:45programa de bug, open test, antes de
153. 4:48procurar pelas vulnerabilidades, você
154. 4:49precisa entender todas as
155. 4:50funcionalidades da aplicação, cada
156. 4:52cenário de ataque, principalmente quando
157. 4:54você tiver buscando por Idor, que é um
158. 4:56tipo de vulnerabilidade totalmente
159. 4:57relacionado com as regras de negócio da
160. 4:59aplicação. Então, o nosso objetivo aqui
161. 5:01com foco no IDOR é identificar esses
162. 5:03cenários onde é passado um identificador
163. 5:06pro back end. Eu posso ver isso através
164. 5:08aqui do dev tools, apertando F12, vindo
165. 5:11aqui na aba Network, consigo ver aqui
166. 5:12todas as requests que meu navegador tá
167. 5:15fazendo. Olha só, ele tá dando um get
168. 5:16aqui em reviews, product reviews. Ele
169. 5:19passa um identificador aqui, ou seja, eu
170. 5:22já consigo enumerar os reviews, muito
171. 5:24provavelmente alterando esse número.
172. 5:26Como resultado aqui, olha só, eu tenho
173. 5:28um array, ou seja, então esse número
174. 5:30aqui é referente ao produto e aqui eu tô
175. 5:31pegando todos os reviews. Enfim, eu
176. 5:33posso fazer esse teste até pelo próprio
177. 5:35navegador aqui, utilizando o editand,
178. 5:37mas o ideal é que a gente tenha um proxy
179. 5:39para interceptar todas as requisições e
180. 5:41conseguir manipular melhor esses IDs e
181. 5:44até para testar outros tipos de
182. 5:45vulnerabilidade. Então, para isso eu vou
183. 5:46utilizar o Burp sutch, beleza? abrir
184. 5:48aqui o burp, ele vai interceptar todas
185. 5:50as requisições e também tem um monte de
186. 5:52ferramenta aqui que ajuda bastante. Eu
187. 5:54vou iniciar o próprio browser aqui do
188. 5:56Burp, que ele já vem configurado com
189. 5:58proxy pra gente interceptar todas as
190. 6:00requests. E vou acessar o nosso labi.
191. 6:03Vou copiar aqui. Beleza? E olha só,
192. 6:05olhando aqui no Burp, já vão aparecer
193. 6:07todas as requisições que o meu navegador
194. 6:09tá fazendo lá pra aplicação. Beleza,
195. 6:12fechou? Vou fazer meu login aqui
196. 6:14novamente. Accountana.com.
197. 6:17Tô logado. Agora sim, vamos analisar as
198. 6:20requisições. Logo de cara aqui, a gente
199. 6:22viu que tem como enviar reviews pros
200. 6:24produtos. Vamos analisar essa
201. 6:26funcionalidade. Vou clicar aqui no Apple
202. 6:28Juice. Olha só, tem um review aqui do
203. 6:30admin shop. Assim que eu cliquei ali,
204. 6:33ele já fez aquela request, olha só, nos
205. 6:35products para listar todos os reviews.
206. 6:37Posso clicar aqui com o botão direito e
207. 6:39enviar pro repeater para repetir essa
208. 6:41request e alterar tudo isso aqui. Então,
209. 6:43por exemplo, enviando essa request, eu
210. 6:45tô pegando os reviews do produto com ID
211. 6:48um. Se alterar aqui para dois, olha só,
212. 6:50as reviews do produto dois. Outro user
213. 6:52aqui é outro review. Então, legal. Aqui
214. 6:54nesse cenário não é um IDOR, porque de
215. 6:57fato os reviews são públicos, porém se
216. 6:59fosse uma informação confidencial aí sim
217. 7:01teria um problema de controle de acesso.
218. 7:03Mas beleza, vamos lá. Vamos enviar um
219. 7:05review para ver como é que funciona. Vou
220. 7:06escrever aqui teste e vou clicar em
221. 7:09submit. Beleza, tá aqui a request. Eu
222. 7:11vou enviar pro repeater novamente. Show.
223. 7:13Então ele faz, ao invés de um get, ele
224. 7:16faz um E no corpo da requisição tem
225. 7:18aqui a mensagem e o autor desse review.
226. 7:22Então olha só que loucura. eu consigo
227. 7:24alterar esse autor. Nesse caso aqui, o
228. 7:27e-mail do usuário tá sendo utilizado
229. 7:29como identificador. Vamos fazer esse
230. 7:30teste. Se não houver uma validação do
231. 7:33autor com a minha sessão ativa, isso
232. 7:35aqui é um IDOR. Então, vamos lá. Eu vou
233. 7:37utilizar o e-mail do admin. Vou pegar
234. 7:40aqui. Olha só, por enquanto existe aqui
235. 7:42o meu review com o meu e-mail e eu vou
236. 7:44colocar aqui o e-mail do admin. Vou dar
237. 7:47um send. E olha só, created.
238. 7:50Aparentemente o review foi criado. Vamos
239. 7:52dar uma olhada lá. Vou reiniciar aqui a
240. 7:54página, acessar aqui o Apple Juice. Olha
241. 7:57só, nosso comentário apareceu aqui como
242. 7:58se fosse o admino. Num contexto real, só
243. 8:01esse cenário aqui já seria bem sensível,
244. 8:03mas imagina isso aqui em funcionalidades
245. 8:05ainda mais críticas. Por exemplo, na
246. 8:07alteração de senha. Se eu clicar aqui no
247. 8:08meu perfil, consigo alterar informações
248. 8:10do usuário ou consigo ver informações do
249. 8:13meu usuário. Vamos ver como que ele faz
250. 8:14essa request. Nesse caso aqui, a sessão
251. 8:16do profile, ele tá pegando as
252. 8:18informações de acordo com o meu token de
253. 8:20sessão. Ou seja, nesse cenário aqui em
254. 8:22específico, se não tiver nenhuma
255. 8:24vulnerabilidade com JWT, não teria um
256. 8:26cenário de IDOR, teria que testar mais a
257. 8:28fundo. Mas são muitos, muitos, muitos
258. 8:30cenários. Aqui dentro do Shop, por
259. 8:32exemplo, vamos ver aqui no carrinho.
260. 8:34Olha só, clicando ali no carrinho, ele
261. 8:36faz uma request. Olha só, rest basket.
262. 8:40Então ele faz uma request paraa API e
263. 8:42coloca um ID ali. Vou enviar isso aqui
264. 8:43pro repeater. Vou alterar isso aqui pro
265. 8:46ID um. Então vou acessar o carrinho com
266. 8:49ID1. E olha só, tô acessando o carrinho
267. 8:50de outros usuários. Imagina que no
268. 8:52processo de pagamento ele passa o ID
269. 8:54ali, uma forma de pagamento de outro
270. 8:56usuário. Eu consigo utilizar o cartão
271. 8:58dele para fazer uma compra ou alterar a
272. 9:00senha desse outro usuário. Enfim, são
273. 9:02muitos, muitos cenários. De acordo com
274. 9:04as regras de negócio da aplicação, podem
275. 9:06chegar em impactos extremamente
276. 9:07críticos. Então, qual que é o segredo
277. 9:09para identificar esse tipo de
278. 9:10vulnerabilidade dentro de programas de
279. 9:12bug bount? Eu recomendo você criar
280. 9:14diferentes contas e, se possível,
281. 9:16diferentes níveis de permissão e testar
282. 9:18o ID de um usuário na outra conta para
283. 9:21verificar se existe essa validação. O
284. 9:23outro ponto importante também é varrer
285. 9:25toda a aplicação, entender cada
286. 9:26funcionalidade, porque às vezes uma
287. 9:28vulnerabilidade aidor só é uma falha no
288. 9:30contexto daquela aplicação por conta da
289. 9:32regra de negócio. Então, muitas vezes
290. 9:34pode passar despercebido e absolutamente
291. 9:36qualquer funcionalidade que passe algum
292. 9:38identificador pode ser vulnerável. E a
293. 9:40pergunta que você tem que se fazer em
294. 9:42cada um desses cenários é: "O que que
295. 9:43acontece se eu simplesmente alterar esse
296. 9:45valor?" Nem sempre um ataque envolve
297. 9:47técnicas complexas e ferramentas de
298. 9:49automação, apesar de ser simvel
299. 9:52automatizar muita coisa paraor, isso
300. 9:53pode ficar para um próximo vídeo, mas
301. 9:55uma simples troca de um ID na URL pelo
302. 9:57seu navegador já basta para identificar
303. 9:59um cenário que muitas vezes pode ser bem
304. 10:01crítico. Yeah.