ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 148
Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 80
Abonament PDF

Cum folosești tehnologia RPA pentru a semnala în mod automat un atac de tip “phishing”

Tudor Șerban
Senior Software Engineer @ UiPath



Sergiu Wittenberger
RPA Developer @ UiPath



TESTARE


Un atac cibernetic de tip phishing (cuvânt omofon cu englezescul "fishing" datorită faptului că presupune folosirea unei "momele" pentru a prinde în plasă victimele) presupune furtul de informații confidențiale precum datele cardului bancar, username-ul sau parola unui utilizator. Acest furt se realizează prin deghizarea atacatorului într-o entitate în care utilizatorul are încredere - o bancă, o persoană cunoscută sau departamentul de IT al companiei la care utilizatorul lucrează - și căreia utilizatorul este inclinat să îi comunice de bunăvoie, acest tip de informații.

Atacurile de tip phishing iau frecvent forma unui e-mail trimis în așa fel încât să pară că vine de la o entitate de încredere și conțin un link către un website utilizat frecvent de către victimă. Victima dă click pe link și e direcționată către o pagină de obicei clonată după cea originală (de exemplu: o pagină de log-in) unde e invitată să introducă date confidențiale care îi parvin mai apoi atacatorului.

Uneori, atacul nu urmărește furtul de informații, ci folosirea unei sesiuni deja existente în browserul victimei pentru a modifica starea unor informații de pe server. (De exemplu, pentru a transfera bani din contul victimei în contul atacatorului sau pentru a schimba adresa de e-mail asociată cu contul victimei). În acest caz avem de-a face cu un atac de tip Cross-Site Request Forgery (CSRF).

Un atac similar, răspândit tot prin intermediul e-mailurilor, e cel de tip Cross Site Scripting (XSS), care profită de sesiuni existente în browser și de vulnerabilități ale aplicației web pentru a fura cookie-uri sau tokenuri care îi permit apoi atacatorului să se dea drept victima și să îi acceseze conturile.

Simulări reale sau cum păstrezi realismul în automatizare?

În vreme ce atacurile de tip CSRF sau XSS pot fi prevenite de către dezvoltatorii aplicațiilor înainte ca ele să fie distribuite utilizatorilor, cea mai bună apărare în fața unui atac de tip phishing clasic este buna informare a utilizatorilor.

Dar dacă am avea la dispoziție un mod 100% automat prin care să putem verifica veridicitatea unui e-mail primit înainte de a-l deschide?

Anumite cursuri sau certificări pun la dispoziția profesioniștilor în securitate diverse exerciții practice care permit testarea unor vulnerabilități într-un mediu realist. Însă o problemă a acestor exerciții este că multe dintre ele, și mai ales cele de tip phishing, necesită intervenție umană și astfel sunt dificil de pus în practică într-un mediu automatizat. Soluția evident nerealistă, e să pui un operator uman să joace rolul victimei monitorizând în mod permanent o căsuță de e-mail.

Cum poate rezolva RPA-ul problema simulării operatorului uman?

Despre tehnologia Robotic Process Automation (RPA) am mai vorbit într-un articol precedent. În termeni prozaici, RPA înseamnă "roboți" software capabili să imite acțiunile manuale pe care le fac oamenii când lucrează pe calculator: clickuri, navigare între ferestre, copy-paste de date, etc. . În cazul nostru, pentru a realiza o soluție complet automată care să pună în scenă rolul victimei umane, avem nevoie să asigurăm următoarele acțiuni:

Toate acestea se pot implementa cu ușurință construind un robot software cu UiPath Studio. Iată cum:

Vom implementa trei nivele de dificultate pentru robotul nostru. Fiecare nivel de dificultate va include funcționalitățile enumerate mai sus. Ce le diferențiază este partea care presupune decizia: în ce cazuri robotul va decide că a fost "păcălit" de linkul trimis de atacator și își va introduce datele confidențiale pe pagina clonată. Prin urmare, robotul va lua deciziile astfel:

  1. La primul nivel, robotul va da click pe linkul din e-mail indiferent de ce conține acesta. Acest nivel este util pentru a testa flowul end-to-end fără alte complicații. Iată un exemplu de e-mail:

  1. La nivelul doi, robotul va urmări structura linkului din e-mail și va da click doar dacă linkul este cel așteptat (de exemplu, dacă e-mailul de phishing pare că vine de la Apple, atunci robotul se așteaptă să "vadă" un link care duce la pagina de login Apple). Această verificare se face doar la nivel de text al linkului, ceea ce înseamnă că, pentru a trece mai departe, este suficient ca atacatorul să deghizeze linkul real. Exemplu de e-mail:

  1. La nivelul trei, robotul știe să facă hover pe linkul din e-mail și să "citească" folosind Optical Character Recognition (OCR) linkul real către care va fi redirecționat dacă dă click. Acest link trebuie să difere în mod subtil de linkul real pentru ca robotul să fie "păcălit":

Pentru a implementa cele de mai sus, avem nevoie de o serie de "activități". În terminologia UiPath, o "activitate" este o acțiune pe care un robot o poate executa cu sau fără parametri de intrare și ieșire. În primul rând, avem nevoie de o activitate de decizie care ne permite să alegem nivelul de dificultate al robotului:

Indiferent de nivelul ales, vom folosi în continuare activitatea "Open Browser" pentru a naviga la inboxul de Gmail (am ales serviciul de Gmail pentru că e cel mai comun, dar se poate folosi orice alt serviciu de e-mail) pe care robotul "victimă" îl monitorizează. După deschiderea inboxului, facem click pe emailul primit și inspectăm linkul:

În final, decidem în funcție de nivelul de dificultate modul în care linkul va fi analizat și dacă avem nevoie să aplicăm OCR pe imagine (pentru a vedea ce afișează browserul în partea de jos când facem hover pe link):

După cum se poate vedea, un scenariu nu tocmai obișnuit de interacțiune automată cu browserul, inclusiv OCR, se poate implementa relativ ușor cu UiPath folosind doar activități care vin out-of-the-box. Robotul creat de noi poate fi folosit acum pentru a înlocui behind-the-scenes operatorul uman în scopul experimentării diverselor scenarii de phishing.

Putem merge mai departe?

Cu siguranță. Nivelul trei implementat mai sus se oprește la "păcălirea" utilizatorului cu un link similar dar nu identic cu cel așteptat. În cazul unui atac de tip man-in-the-middle în care inclusiv DNS-ul victimei a fost modificat astfel încât să ducă la o pagină clonată de pe serverul atacatorului, se poate implementa un robot care dă click doar dacă linkul este 100% identic cu cel așteptat. În acest caz, am dori probabil ca robotul să verifice inclusiv dacă certificatul prezentat browserului de către site-ul vizitat este valid.

De asemenea, robotul mai poate fi configurat să verifice dacă răspunsul primit după introducerea username-ului și a parolei pe o pagină este cel așteptat, astfel încât, chiar dacă atacatorul a reușit să obțină datele confidențiale, utilizatorul să fie alertat și să le modifice în timp util în cazul în care atacatorul nu a mers până la capăt cu procesul de clonare.

UiPath e disponibil free în varianta "community". Puteți să îl încercați oricând și să vă construiți robotul vostru. Limita a ce puteți face cu el este doar imaginația voastră.

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects