summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSanto Cariotti <santo@dcariotti.me>2022-11-22 13:34:47 +0100
committerSanto Cariotti <santo@dcariotti.me>2022-11-22 13:34:47 +0100
commit19fa69ea37bc83141c74f5327b9a2f4c0a0e9f82 (patch)
tree2d8b6cda32d96155cc2f81729ab722cdfcfe8c0f
parent47dc770e34f83f977a7e831c3db4635bcab67417 (diff)
Fix
-rw-r--r--docs/m6.tex28
1 files changed, 12 insertions, 16 deletions
diff --git a/docs/m6.tex b/docs/m6.tex
index 03c1ca0..6b8215e 100644
--- a/docs/m6.tex
+++ b/docs/m6.tex
@@ -7,7 +7,7 @@
\small\textsc{Dipartimento di Matematica e Informatica\\Corso di Internet Security}\\
\Huge\textbf{M6: Insecure Authorization\\Attack side}\\
\author{Santo Cariotti}
- \date{x y z}
+ \date{5 dicembre 2022}
}
\usepackage{graphicx}
@@ -28,14 +28,14 @@
\input{chapters/setup}
\chapter{Traffico di rete}
-In questa versione di testing sarà utilizzato il software Termshark \footnote{https://github.com/gcla/termshark} al post di Wireshark. L'unico vantaggio è facilità d'uso per quello che serve fare a noi, visto che è offre una semplice TUI a \textbf{tshark(1)}.
+In questa versione di testing sarà utilizzato il software Termshark\footnote{https://github.com/gcla/termshark} al post di Wireshark. È un software basato su Wireshark in cui unico vantaggio è la facilità d'uso per quello che serve fare a noi, visto che offre una semplice TUI a \textbf{tshark(1)}.
-Aprendo Termshark la prima cosa che può venir in mente è quella di filtrare per richieste TCP, e così facciamo ma vi sono tanti pacchetti che arrivano in entrata e uscita, quindi potremmo voler aggiungere un filtro in modo tale da filtrare solo le richieste che partono dalla nostra macchina: ma qual è l'IP? Per far ciò basta eseguire
+Aprendo Termshark la prima cosa che può venir in mente è quella di filtrare per richieste TCP, e così facciamo, ma vi sono tanti pacchetti che arrivano in entrata e uscita, quindi potremmo voler aggiungere un filtro in modo tale da filtrare solo le richieste che partono dalla nostra macchina: ma qual è l'IP? Per far ciò basta eseguire
\begin{lstlisting}
-$ ip -c -br a
+$ ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
-wlp2s0 UP 1151.97.156.203/20 fe80::dab5:fab1:2c92:1fcb/64
+wlp2s0 UP 151.97.156.203/20 fe80::dab5:fab1:2c92:1fcb/64
docker0 DOWN 172.17.0.1/16
..
\end{lstlisting}
@@ -48,7 +48,7 @@ prendendo come base l'IP della scheda Wireless possiamo applicare il filtro.
\caption{Screenshot di Termshark}
\end{figure}
-Avviando l'applicazione da Android Studio dobbiamo far caso, dopo aver provato il login, alla colonna Info, dove vi sono le righe con testo "Client Hello" o in chiaro, nel caso di HTTP.
+Avviando l'applicazione da Android Studio dobbiamo far caso, dopo aver provato il login, alla colonna Info, dove vi sono le righe con testo "Client Hello" o con la chiamata HTTP in chiaro.
Nello screenshot in Figura 4.2 si vede a quale endpoint fa la la chiamata per fare il login e anche con quale payload. Non è un problema il fatto che vediamo le credenziali che stiamo usando, proprio perché li stiamo inserendo noi. Può essere un problema in caso di qualcun altro che fa sniffing della LAN perché vedrebbe le nostre credenziali; questo problema scompare quando il server usa HTTPS invece di HTTP.
@@ -60,14 +60,14 @@ Nello screenshot in Figura 4.2 si vede a quale endpoint fa la la chiamata per fa
\section{Informazioni utente}
-Proseguendo nell'applicazione a visualizzare la pagina con le info personali, vediamo da dove e come prende queste informazioni.
-In particolare dobbiamo far attenzione, oltre all'url, qual è il token di accesso che invia per richiedere la risorsa.
-
\begin{figure}[h]
\centering
\includegraphics[width=0.75\textwidth]{data/termshark-get-users}
\caption{Screenshot della GET users}
\end{figure}
+Proseguendo nell'applicazione a visualizzare la pagina con le info personali, vediamo da dove e come prende queste informazioni.
+In particolare dobbiamo far attenzione, oltre all'url, qual è il token di accesso che invia per richiedere la risorsa.
+
Nella Figura 4.3 si vede ciò. Per copiare la riga bisogna entrare in modalità copy premendo \emph{c} e \emph{CTRL+C}. Alla fine avremo in buffer la stringa
@@ -93,7 +93,7 @@ Ricreiamo un payload valido ma con differente "user\_id".
$ echo '{"user_id":2,"exp":1669282872}' | base64
eyJ1c2VyX2lkIjoyLCJleHAiOjE2NjkyODI4NzJ9Cg==
-$ # Ricordiamo che il padding "Cg==" va rimosso da JWT
+$ # Il padding "Cg==" va rimosso da JWT
\end{lstlisting}
Usiamo un software che permette di fare chiamate HTTP come xh\footnote{https://github.com/ducaale/xh} e vediamo come questo nuovo payload non funzioni, proprio perché l'ultima parte non è stata ancora ricalcolata.
@@ -109,8 +109,6 @@ Content-Type: application/json
Date: Tue, 22 Nov 2022 03:24:00 GMT
Server: nginx
Vary: origin
-Vary: access-control-request-method
-Vary: access-control-request-headers
{
"error": "Invalid token"
@@ -121,7 +119,7 @@ Vary: access-control-request-headers
L'Authorization token è qualcosa di pubblico, che possiamo veder ad ogni richiesta HTTP. Il secret no, è usato per fare verificare la firma e rendere valido il token stesso. Quindi useremo un approccio simile a quello impiegato per "forzare" il login di una piattaforma: proveremo per forza bruta tutte le password possibili.
In questo caso proveremo i possibili secret per far sì che la firma sia lo stesso valida.
-Prendendo una lista ben nota di secrets impiegati in servizi in produzione \cite{JWT_SECRETS_LIST:1} useremo il software open-source \textbf{Hashcat} \cite{HASHCAT}.
+Prendendo una lista ben nota di secrets impiegati in servizi in produzione\footnote{https://raw.githubusercontent.com/wallarm/jwt-secrets/master/jwt.secrets.list} useremo il software open-source \textbf{Hashcat} \cite{HASHCAT}.
Per crackare la password usando Hashcat bisogna dare in input il parametro dell'hash type di JWT, il sorgente in cui vi è il token che si vuole crackare e il sorgente in cui vi è la lista dei secrets.
\begin{lstlisting}
@@ -148,7 +146,7 @@ Usando queste informazioni possiamo sfruttare il sopracitato sito web \underline
\caption{Screenshot di Jwt.io}
\end{figure}
-Usando questo nuovo token codificato per fare la chiamata, possiamo riare la chiamata che era fallita prima.
+Usando questo nuovo token codificato per fare la chiamata, possiamo riprovare la chiamata che era fallita prima.
\begin{lstlisting}
@@ -162,8 +160,6 @@ Content-Type: application/json
Date: Tue, 22 Nov 2022 03:30:19 GMT
Server: nginx
Vary: origin
-Vary: access-control-request-method
-Vary: access-control-request-headers
{
"id": 2,