wtorek, 1 sierpnia 2017

Brak tagu rel=noreferrer w prywatnych wiadomościach Linkedin

Na dzień dzisiejszy istnieje możliwość korelacji odwiedzin na stronie internetowej z konkretnym użytkownikiem, któremu przesyła się odnośnik w wiadomość na stronie LinkedIn.

Przykładowo wysłanie odnośnika https://redteam.pl/konsultanci.html w prywatnej wiadomości znajduje odbicie w logach serwera HTTP:
198.51.100.5 - - [21/Jul/2017:10:25:54 +0200] "GET /konsultanci.html HTTP/1.1" 200 14118 "https://www.linkedin.com/messaging/thread/6294067405647937536/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36"

Odnośnik https://www.linkedin.com/messaging/thread/6294067405647937536/ kieruje do konkretnej wiadomości (aby zobaczyć trzeba być uczestnikiem rozmowy) i pochodzi on z nagłówka HTTP referer przesłanego w wyniku braku tagu HTML rel=noreferrer.

Nagłówek HTTP referer zawiera adres strony internetowej, z której użytkownik został przekierowany za pomocą odnośnika. Jeśli w kodzie HTML zostałby umieszczony tag rel=noreferrer, to w takim przypadku nagłówek ten nie zostałby ujawniony.

Ujawnienie takich informacji to głównie kwestie prywatności – istnieje możliwość przypisania konkretnych odwiedzin i ruchu na stronie internetowej do konkretnego użytkownika, któremu przesyłamy wiadomość na portalu. Takie działanie może być wykorzystane w marketingu, ale nie tylko. W naszym przypadku istotny jest wątek bezpieczeństwa, ponieważ w ten sposób wysyłając wiadomości do kilku pracowników danej organizacji jesteśmy w stanie przypisać do nich konkretne adresy IP i informacje udostępnione przy pomocy nagłówka User-Agent, a nawet – za pomocą strony, którą odwiedzają – sprawdzić wersje wykorzystywanego oprogramowania.

Nagłówek HTTP User-Agent zawiera informacje o aplikacji klienckiej:
Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
Przeglądarka Chrome w wersji 59 uruchomiona na systemie operacyjnym Windows 7 (Windows NT 6.1) w wersji 64 bitowej. Natomiast przykładowo dodatki mogą zostać wykryte przy pomocy enumeracji prostym skryptem JavaScript:


Dzięki informacjom o oprogramowaniu można wykorzystać konkretną podatność w nim występującą. Informacje takie jak adres IP z kolei nie tylko są celem do zdalnych ataków ale również wskazówką dzięki której możemy określić czy wszyscy pracownicy, którzy odwiedzili odnośnik, łączą się z jednej sieci. Jeśli w polu User-Agent znaleźlibyśmy informacje o urządzeniu mobilnym to dowiadujemy się, że za danym adresem IP kryje się sieć bezprzewodowa. Sprawdzenie revDNS z kolei może dostarczyć kolejnych istotnych informacji. Warto tutaj również wspomnieć, że cały ten proces może być zautomatyzowany i zintegrowany np. z kampanią phishingową.

Przed publikacją sugestia została zgłoszona do portalu LinkedIn.

Brak komentarzy:

Prześlij komentarz