ვინ თქვა რომ 2FA დაგვიცავს? როგორ ტეხავენ ჰაკერები ორფაქტორულ ავტორიზაციას Modlishka გამოყენებით?

გაბრთხილება: ქვემოთ მოყვანილი ინფორმაცია მხოლოდ საგანმანათლებლო მიზნებისთვის არის და არავის არ მოუწოდებს მოქმედებისკენ.

ჰაკერების ფორუმები მრავალფეროვანია დაჰაკული ანგარიშების შეთავაზებებით. უმეტეს შემთხვევაში, თავდასხმები ტარდება ყალბი ავტორიზაციის გვერდებით, ფიშინგის გამოყენებით. თუმცა, ეს მეთოდი არაეფექტურია იმ შემთხვევაში, თუ მომხმარებელს მიზდის SMS-ის ვერიფიკაციის კოდი. მე გაჩვენებთ, თუ როგორ უვლიან გვერდს ორი ფაქტორიანი ავთენტიფიკაციას ჰაკერები, Google-ის ანგარიშის «www.spy-soft.net» საიტის რედაქტორის მაგალითზე.

ექსკურსია ორფაქტორულ ავტორიზაციაში

ადრე, როდესაც საიტები მუშაობდნენ HTTP- ზე და არავინ არ ფიქრობდა დაცვაზე, სერტიფიკატთან ტრეფიკის შელახვა ძალიან მარტივი ამოცანა იყო. შემდეგ დაიწყო ტრეფიკის დაშიფვრა, და თავდამსხმელებმა მოუწიათ მოეფიქრებინათ მარშრუტების შეცვლისა და გადამისამართების უფრო დახვეწილი გზები. როგორც ჩანდა, საბოლოოდ, ორი ფაქტორიანმა ავტორიზაციამ პრობლემა მოაგვარა, მაგრამ მთელი საკითხი მისი განხორციელების დეტალებშია.

ორი ფაქტორიანი ავტორიზაციის (Two-Factor authentication) მეთოდი იყო გამოგონილი, როგორც ანგარიშის მფლობელის დადასტურების დამატებითი გზა. იგი დაფუძნებულია ავტორიზაციის რამდენიმე მეთოდზე:

მომხმარებელმა იცის რაღაც (მაგალითად, მას შეუძლია უპასუხოს, რა იყო მისი დედის ქალიშვილობის სახელი ან პირველი საყვარელი ცხოველის მეტსახელი);
მომხმარებელს აქვს უნიკალური თვისებები, რომელთა ციფრიზაცია და შედარებაც შესაძლებელია (ბიომეტრიული ავტორიზაცია);
მომხმარებელს აქვს დევაისი უნიკალური იდენტიფიკატორით (მაგალითად, მობილური ნომერი, USB ფლეშ დრაივი, რომელსაც აქვს ფაილი).

პირველი მეთოდი კვლავ ხდება უსაფრთხოების კითხვების პაროლების ამოღებისას. ეს არ არის შესაფერისი რეგულარული გამოყენებისთვის, რადგან პასუხები არ იცვლება და მარტივად შეიძლება დაკომპლექტდეს. მეორე მეთოდი უფრო ხშირად გამოიყენება მობილური მოწყობილობებზე მონაცემების დასაცავად და სერვერებზე კლიენტის პროგრამების ავტორიზაციისთვის.

ყველაზე პოპულარული 2FA მეთოდი - მესამე. ეს არის SMS დამადასტურებელი კოდებით, გენერირებული OTP ტექნოლოგიით. ყოველ ჯერზე კოდი განსხვავდება, ასე რომ მის გამოცნობა პრაქტიკულად შეუძლებელია.

თუმცა, რაც უფრო რთულია დაცვის გადალახვა ტექნიკური მეთოდებით, მით უფრო ადვილია ამის გაკეთება სოციალური ინჟინერიის საშუალებით. ყველას იმდენად დარწმუნებულია ორფაქტორიანი ავთენტურობის სანდოობაში, რომ ისინი იყენებენ მას ყველაზე მნიშვნელოვან ოპერაციებზე - Google-ში ავტორიზაციიდან (და ეს დაუყოვნებლივ წვდება ფოსტაზე, დისკზე, კონტაქტებსა და ღრუბელში შენახულ ყველა ისტორიას) კლიენტ-საბანკო სისტემებამდე.

ამავე დროს, ამგვარი სისტემის გვერდით ავლის შესაძლებლობა უკვე აჩვენა ავსტრალიელმა მკვლევარმა შუბჰამ შაჰმა (Shubham Shah). მართალია, მისი მეთოდი პრაქტიკაში საკმაოდ რთული იყო. მაში ფამოიყენებოდა ზარის ავტორიზაცით, და არა SMS-ით, მაგრამ პირველ რიგში საჭირო იყო დაზარალებულის ტელეფონის ნომერი და მინაცემების ნაწილი. PoC არ იყო განსაკუთრებით დამაჯერებელი, მაგრამ ასახული იყო შეტევის ვექტორი.

ორი ფაქტორიანი ავთენტურობის დაჰაკვა Modlishka-ს მეშვეობით

2019 წლის დასაწყისში, პოლონელმა მკვლევარმა პიოტრ დუჟინსკიმ (Piotr Duszyński) გამოაქვეყნა Modlishka-ს რევერს-პროქსი ღია წვდომა. მისი თქმით, ამ ხელსაწყოს შეუძლია გვერდი აუაროს ორი ფაქტორიან ავთენტიფიკაციას, რომელსაც ახლა შევამოწმებთ.

თუ შევადარებთ ნას SEToolkit-ს (ის თითქმის ყველა პოპულარულ დისტრიბუტივშია აგებული პენტესტისთვის), მაშინ განსხვავება არის იმაში რომ: SET აკლონირებს და ანთავსებს ლოკალურ სერვერზე ავტორიზაციის გვერდს. იქ ყველაფერი დაფუძნებულია სკრიპტების მუშაობაზე, რომლებიც იჭერენ მსხვერპლისმიერ შეყვანილ მონაცემებს. თქვენ, რა თქმა უნდა, შეგიძლიათ შექმნათ გადამისამართება ორიგინალ საიტზე, მაგრამ დაზარალებულისგან თქვენს სერვერზე ტრეფიკი არ იქნება დაშიფრული. სინამდვილეში, ასეთი პროგრამები მოქმედებს როგორც ვებ სერვერები ყალბი (ფიშინგის) საიტებით.

სტატია დაწერილი საგანმანათლებლო მიზნებისთვის. სტატიის მიზანია აღვნიშნოთ ორი ფაქტორიანი ავთენტიფიკაციის ნაკლოვანებები და გითხრათ, რომ ეს არ არის პანაცეა.

Modlishka განსხვავებულად მოქმედებს. გენერირდება სერთიფიკატი, რომელიც დაშიფვრავს კავშირს დაზარალებულისგან ჩვენს სერვერზე (ისე, რომ არ დავიწვათ). შემდეგ ეს მანქანა მოქმედებს როგორც საპირისპირო პროქსი პირი.

სხვა სიტყვებით რომ ვთქვათ, ყველა ტრეფიკი გადადის ორიგინალ საიტზე, ინსტანციით ჩვენს სერვერზე. ჰაკერთან რჩება მონაცემები და მიღებული აქვს მსხვერპლის საავტორიზაციო სხდომა. კლასიკური MITM შეტევა, რომელსაც წინ უძღვის ფიშინგი (თქვენ უნდა გააკეთოთ როგორმე მსხვერპლს დააინსტალირებინოთ ყალბი სერთიფიკატი და გადაამისამართოთ იგი ყალბ საიტზე).

ორი ფაქტორიანი ავთენტიფიკაციის შემოვლითი სტენდი

მოდით გავაკეთოთ სერვერი Modlishka–ით ლოკალურ აპარატის შიგნით. მე ამას გავაკეთებ Kali Linux–ის გამოყენებით, მაგრამ სხვა დისტრიბუციებისთვის არ იქნება პრინციპული განსხვავება - თუ Go წყაროს გზა ოდნავ არ შეიცვლება.

დასაწყისისთვის ჩვენ ვაყენებთ Go - რევერს-პროქსი არის დაწერილი ამ ენაზე, ხოლო Go-ს გარეშე მისი შედგენა შეუძლებელია.

$ apt-get install golang

შემდეგ ჩვენ მივუთითებთ გზას წყაროების დირექტორიაში:

$ export GOPATH='/root/go'

თქვენ შეგიძლიათ შეამოწმოთ ყველაფერი ამ ბრძანებით:

$ go env

გამომავალში უნდა იყოს მითითებული GOPATH.

ბრძანების ჩვენება

შმედეგ ჩვენ ვაკლონირებთ ტოტს ინსტრუმენტით:

$ go get -u github.com/drk1wi/Modlishka

$ cd /root/go/src/github.com/drk1wi/Modlishka/

ვქმნით სერთიფიკატს:

$ openssl genrsa -out secret.key 2048

$ openssl req -x509 -new -nodes -key secret.key -sha256 -days 1024 -out cert.pem

ახლა თქვენ უნდა გადმოიტანოთ გასაღებისა და სერთიფიკატის შინაარსი plugin/autocert.go ფაილში და შეცვალოთ ორი ცვლადის მნიშვნელობა:

const CA_CERT - სერთიფიკატის მნიშვნელობა (pem ფაილი);
const CA_CERT_KEY - გასაღების მნიშვნელობა (key ფაილი).

Autocert.go ფაილი სერთიფიკატის შეცვლის შემდეგ

ახლა ჩვენ ვაგროვებთ ამ მთლიან ნივთს:

$ make

შედგენა ხდება სამიდან ათ წუთამდე, რაც დამოკიდებულია საკომპენსაციო რესურსების ოდენობაზე.

შესრულებადი ფაილი თავისთავად მდებარეობს dist/ დირექტორიაში სახელწოდებით proxy. შესამოწმებლად, შეგიძლიათ გაუშვათ გასაღებით -h — დახმარების ჩვენება.

$ ./dist/proxy -h

დახმარების ჩვენება Modlishka-ის

მსხვერპლის მონაცემების და სხდომების გადაჭერა

როგორც ზემოთ დავწერე, იმისათვის, რომ მსხვერპლისთვის დაშიფრული არხი გამჭვირვალე შეიქმნას ჩვენს საპირისპირო რევერს-პროქსიში, თქვენ ჯერ უნდა დააექსპორტიროთ სერთიფიკატი ბრაუზერში. შემდგომი ნაბიჯები მიმოიხილება Mozilla Firefox x64 v.67.0-ის მაგალითზე. ჩვენ კგვაინტერესებს google.com_gsuite.json. თითოეული ელემენტის დეტალური აღწერა შეგიძლიათ იხილოთ სახელმძღვანელოში, ამ კონფიგზე.

Google.com_gsuite.json ფაილის შინაარსი

არის 2 ვარიანტი Modlishka-ს გასახსნელად: ხელით და კონფიგურაციის ფაილის გამოყენებით. ხელით რომ გავხსნათ, მინიმალური ბრძანება ასე გამოიყურება:

$ ./dist/proxy -target https://google.com -phishingDomain loopback.modlishka.io -listeningPort 443 -tls

კონფიგურაციის ფაილის გამოყენებით გახსნა:

$ ./dist/proxy -config /templates/google.com_gsuite.json

გავხსნათ კონფიგურაციიდან და გადადით ბრაუზერში loopback.modlishka.io მისამართზე. ჩვენ გაგვეხსნება google.com გვერდი. შევდივართ ექაუნტში და ვხედავთ, თუ როგორ ჩნდება მსხვერპლის მონაცემები ტერმინალში.

ლოგინი და პაროლი Modlishka-ს გამომავალში

თუ ჩვენ გადავალთ loopback.modlishka.io/SayHello2Modlishka მისამართზე (ძალიან სიმბოლური), ჩვენ მივიღებთ კონსოლს გადაჭერილი სესიის გასამართავად (ამ ეტაპზე ეს არის ბეტა ფუნქცია). ამ ეტაპზე, ჩვენ გადავიჭირეთ მსხვერპლის ლოგინი და პაროლი დაშიფვრის შეცდომების და "უსაფრთხო" კავშირის გარეშე. როგორც ვიცი, მსგავსი მიზნის სხვა ინსტრუმენტებს არ შეუძლიათ ამის გაკეთება.

ახლა რა ვუყოთ ორ ფაქტორიან ავთენტიფიკაციით? აი რას: მართვის პანელში არის ცარიელი UUID ველი და ეს რიცხვი არის გასაღები ყველაფერზე.

თუ დაუყოვნებლივ დააჭირეთ Impersonate user (beta) ღილაკს, ცარიელი ჩანართი გაიხსნება, ხოლო Modlishka-ს კონსოლში გვეტყვუს, რომ UID მომხმარებელი არ არის. ის უნდა იყოს მითითებული, და იგი თავიდანვე მითითებულია - მიითითება ბმულში ჩვენს ბოროტი URL-ზე. ამისათვის დაუბრუნდით კონფიგურაციის ფაილს.

ჩვენ გვაინტერესებს სტრიქონი "trackingParam": "ident". მასში, თქვენ უნდა მიუთითოთ ident მნიშვნელობა ისე, რომ ჩვენი URL ასე გამოიყურებოდეს:

https://loopback.modlishka.io/?ident=1

სწორედ ამ (ან დამატებით დამაბრკოლებელ) URL- ზე მსხვერპლის მიმართვა უნდა იყოს.

ამჯერად, ასეთ ბმულზე გადასვლის და ავტორიზაციის შემდეგ, შევსებული UUID-ით სხდომა ხელმისაწვდომი იქნება საკონტროლო პანელში (loopback.modlishka.io/SayHello2Modlishka). რამდენად ზუსტად გამოიყურება, ცოტა მოგვიანებით განახებთ რეალურ მაგალითზე.

ახლა, როდესაც დიდ ყვითელ ღილაკს დააჭირეთ, თქვენ ნახავთ მშვენიერ ცისფერ ანიმაციას და 5-10 წამში მოვხდებითა მსხვერპლის უფლებამოსილ სხდომაზე, მიუხედავად ორი ფაქტორიანი ავტორიზაციისა. დაზარალებული, ჩვეულებრივად მიიღებს და შეიყვანს დადასტურების კოდს, დაინახავს დაშიფრულ კავშირის და ნამდვილი Google-ის ავტორიზაციის პანელს, ისე რომ არც შეამჩნევს Modlishka-ს რევერს-პროქსის ფრაგმენტს შუაში.

თუმცა, მე მოვიყვანე Wiki კონფიგურაციის ფაილის ყველა პარამეტრების ყველა საკითხზე, არის კიდევ ერთი მომენტი. მას შემდეგ, რაც დაზარალებულმა თავისი მონამებემი შეივანა, მიზანშეწონილია, რომ თავიდან აიცილოთ ანგარიშიდან გასვლა და შეინახოთ ავტორიზაციის სხდომა. ამას აკეთებს პარამეტრი terminateTriggers. თუ ამ პარამეტრში მივუთითებთ URL, რომელზეც მომხმარებელი მოხვდება წარმატებული ავტორიზაციის შემდეგ, მაშინ, როდესაც ასეთი მისამართის გამოჩენისას, მთელი ტრეფიკი დაიწყებს გადამისამართებას ორიგინალ URL-ზე, და დაავტორიზირებული სესია არ იქნება შეხევული ექაუნტიდან გამოსვილის შემდეგაც.

მზა კომპლექტი NAT-სთვის.

არც თუ ისე რთული იყო შეტევა ერთი მოწყობილობის ან LAN-ის შიგნით, მაგრამ WWW-ში, როგორც PoC-სთვის, "ბრძოლის" სტენდის მომზადებით დავიწყე თავიდან. ამისათვის თქვენ მოგიწევთ გადამისამართება თეთრი (გარე) IP მისამართის, ან ასეთი მისამართით გამოყოფილი სერვერი. შეგიძლიათ სერვერის დაქირავება თვეში 300 რუბლიდან.

როდესაც ეს სერვერი დავაყენე Kali Linux-ზე, არანაირი პრობლემა არ ყოფილა. Ubuntu სერვერი დაინსტალირებული იყო VDS-ზე, ხოლო Golang–ის ინსტალაციისას აღმოჩნდა, რომ ნაგულისხმევი საცავი შეიცავს Go–ს ძალიან ძველ ვერსიას, რომელმაც შეადგინა უამრავი შეცდომა. ამ შემთხვევაში, თქვენ უნდა დაამატოთ აქტუალური Go საცავი და დააინსტალიროთ უახლესი ვერსია.

პირველი პრობლემა დომენის სახელია. თუ გადადიხართ დაზარალებულის კომპიუტერიდან URL loopback.modlishka.io-ზე, არაფერი გამოვა, რადგან გარე და აკონტროლებელმა DNS-მა არ იცის ასეთი მისამართი. თუ გადაამისამართებთ აპარატის IP მისამართს Modlishka-თან, მაშინ მსხვერპლი გადავა პირდაპირ Google-ს გვერდზე, პროქსი სერვერის გვერდის ავლით, ხოლო ტერმინალში ჩვენ ვიხილავთ ორ სტრიქონს:

Host 192.168.1.15 does not contain the phishing domain

Redirecting client to google.com

თუ მსხვერპლი იმავე ლოკალურ ქსელშია, თქვენ შეგიძლიათ მიუთითოთ დამთხვეული IP - URL ადგილობრივ DNS ან მის hosts ფაილში. ჩემს შემთხვევაში, ეს ასე იყო:

192.168.1.15 loopback.modlishka.io

ინტერნეტით, მე პირველად შევეცადე დამერეგისტრირებინა უფასო მესამე დონის დომენი. მე ვიფიქრე, რომ ეს საკმარისია, მაგრამ ეს ასე არ იყო! გადასვლის დროს, აღმოჩნდა მხოლოდ ის გვერდი, რომ საიტი მიუწვდომელია, ხოლო HTTPS–ის საშუალებით IP მისამართის მითითებისას იგი Google-ში გადამისამართდა. მარტივი HTTP საშუალებით, Apache მისასალმებელი გვერდი გაიხსნა.

გლობალურ ქსელში URL-ზე გადასვლისას, ავტომატურად დაემატა www პრეფიქსი და პროგრამა ელოდება სუფთა წვდომას დომენზე. კონფიგურაციაში www-ს დამატებამ ვერ უშველა და მე უნდა მეშოვა ქვეს დომენების სრული აუზი ჩემს სუბდომენებში. სხვა სიტყვებით რომ ვთქვათ, თუ დომენი ჰგავს loopback.modlishka.io, მაშინ უნდა გქონდეთ *.loopback.modlishka.io.

შემდეგი ნაბიჯი ეხება სერთიფიკატებს. რეგისტრირებულ დომენზე აუცილებელია სერთიფიკატის და გასაღების შედგენა. იდეაში, თქვენ უნდა მოაწეროთ სერთიფიკატი უფლებამოსილების სასერთიფიკატო ცენტრში, მაგრამ შეგიძლიათ გამოიყენოთ თვითწერილი, ტესტისთვის.

მივდივართ ნებისმიერ სერთიფიკატის გენერატორზე, ვქმნით და გადმოვწერთ ორ ფაილს. მათი შინაარსი ყნდა შეიცვალოს Modlishka-ს კონფიგურაციის ფაილში, შესაბამისად, ველებში «cert»: «» და «certKey»: «».

მცირე შენიშვნა: სერთიფიკატი და გასაღები უნდა იყოს მითითებული ერთ სტრიქონზე, ხოლო სტროფის გადატანა, ჩვეულებირივად, მიითითება თანმიმდევრობით \n.

ასე უნდა გამოიყურებოდეს:

"cert": "-----BEGIN CERTIFICATE-----\nMIIDJTCCAg2gAwIBAgIESjdT0DANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDDB5SZWdlcnkgU2Vs\n...".

ასევე კონფიგურაციის ფაილში უნდა შევცვალოთ რამდენიმე სხვა პარამეტრი:

«phishingDomain»: «loopback.modlishka.io» — აქ, loopback.modlishka.io-ს ნაცვლად, ჩვენ ვცვლით ჩვენს დომენს;
«listeningAddress»: «127.0.0.1» — თქვენ უნდა შეცვალოთ იგი 0.0.0.0, წინააღმდეგ შემთხვევაში მხოლოდ lo-ინტერფეისი ისმის, და ყველაფერი იმუშავებს მხოლოდ ლოკალურ აპარატის შიგნით.

Modlishka განილაგება ყოველ ჯერზე კონკრეტული დომენის სახელებისთვის. აქედან გამომდინარე, უმჯობესია დომენის სახელი თავიდან დაარეგისტრიროთ, შემდეგ მიიღოთ სერთიფიკატი და მხოლოდ ამის შემდეგ განათავსოთ ტექნიკური ნაწილი. ამ შემთხვევაში შეგიძლიათ სერთიფიკატებიშ შინაარსის იმპორტირება autocert.go-ში, და აღარ გჭირდებათ რეგისტრაციის გასაშვებად კონფიგურაციის ფაილში ჩაწერა.

ორი ფაქტორიანი ავტორიზაციის შემოვლითი გზა

ეს სტენდი დავტესტე საიტის რედაქტორზე «www.spy-soft.net», რომელიც ძალიან გულუბრყვილო მსხვერპლი იყო. google.com-ზე ჩემი დომეინის მისამართი არ გავს, მაგრამ გადავწყვიტეთ, გამოგვეტოვებინა ბფუსკაცია.

ერთობლივი ექსპერიმენტის შედეგები შეგიძლიათ ნახოთ სკრინებზე. ანდრეი სხვა ქალაქში იყო და ამიტომ ვერაფერს მიზავდა მე. მან სხვა პროვაიდერთან დაკავშირება შეძლო და წვდებოდა ჩემს ფიშინგს საიტის Firefox v. 67.0-ის desktop ვერსიის საშუალებით.

ჯერ მან ჩამოტვირთა ჩემი დომენის ყალბი სერთიფიკატი და დააინსტალირა იგი ბრაუზერში. რეალურ ცხოვრებაში, პენტესტის ჩატარებისას, შეგიძლიათ ასეთ სასოწარკვეთილი საქციელზე მოტივირება უსაფრთხოების, წახალისების ან სიხარბის/შიშის თამაშობით ათასი სხვა გზით მეშვეობით.

მსხვერპლი აყენებს სერთიფიკატს

მისამართების ზოლში საზიზღრობა ხდება, მაგრამ რამდენიმე ადამიანი თუ მიაქცევს მას ყურადღებას (მობილური ბრაუზერებში ის ზოგადად ქრება ეკრანზე, სივრცის დაზოგვის მიზნით). მწვანე საკეტი "უსაფრთხო" კავშირის ნდობას შთააგონებს და Google ავტორიზაციის პანელი ზოგადად იტვირთება ორიგინალში.

ხაფანგი უყურადღებო ადამიანებისთვის

პირველი ეტაპი წარმატებით დასრულდა - ანდრიმა შეიქვანა ლოგინი და პაროლი, რის შემდეგაც Google-მა მას SMS-ში გაგზავნა ერთჯერადი დამადასტურებელი კოდი.

გადამოწმების კოდის მოთხოვნა

წუთზე ნაკლებ დროში ანდრეიმა შეიყვანა კოდი სტანდარტული ვერიფიკაციის ველში. ის თავის ანგარიშზე შევიდა... და მეც!

სრული ავტორიზაციის გადაჭერა

ამის შემდეგ მე მოქმედების სრული თავისუფლება მქონდა. ფოსტა, დისკი, კონტაქტები, ბრაუზერის ისტორია, გეოგრაფიული მოძრაობების ისტორია, დაინსტალირებული აპლიკაციების სიები, შენახული პაროლები Wi-Fi წვდომის წერტილებისა და სარეზერვო ასლებისთვის. უბრალოდ ციფრული Klondike!

დაჰაკული ფოსტა

რაც მთავარია - ჩვენ მოვახერხეთ აქტიური სესიის გადაჭერა.

Modlishka-ს მართვის პანელი

მნიშვნელოვანი შენიშვნა: თუ აქაუნტი გამოიყენება სმარტფონზე, push შეტყობინებას გაუგზავნის მომხმარებელს, რომ აქაუნტზე მოხდა ავტორიზაცია ახალი მოწყობილობიდან. თუმცა, ჰაკერს აქვს დრო, რომ შევიდეს ფოსტაში და წაიშალოს ის წერილი. მსხვერპლისთვის ეს გამოიყურებდეს იქნება როგორც შეტყობინებების სისტემის შეცდომა, თუ რათქაუნდა ის საერთოდ აქციებს შეტყობინებეს ყურადღებას.

იტოგი

Modlishka-ის პანელის სხდომა ძალიან ცოცხალია. იგი არ იღუპება, სანამ მომხმარებელი (ან ჰაკერი) არ გამოვა. ანუ, თუ მსხვერპლი დახურავს ჩანართს, უფლებამოსილი სხდომა აქტიური დარჩება. თუ თქვენ ხელახლა შეხვალთ google.com–ზე, შემდეგ კი თქვენი აკაუნტიდან გამოდიხართ, სხდომა კვლავ ცოცხალი იქნება. მაშინაც კი, თუ შეაჩერებთ Modlishka სერვერს და ჩართავთ მას კვლავ - სესია კვლავ რჩება ცოცხალი. არსებობს დეავტორიზაციის მხოლოდ ერთი გარანტირებული შესაძლებლობა - გასვლა იმ მომენტში, როდესაც თქვენ მხოლოდ რედირექტირდებით პროქსიში.

მიუხედავად იმისა, რომ ტექნიკური დეტალები იყო აღწერილი სტატიაში, ორი ფაქტორიანი ავტორიზაციის გვერდის ავლით არ იმმუშავებს სოციალური ინჟინერიის გარეშე. აუცილებელია საიტის დანიღაბვა და როგორმე დააინსტალიროთ სერთიფიკატი მსხვერპლის კომპიუტერში. თუმცა, ეს შეიძლება არც ისე რთული იყოს. მომხმარებელთა უმეტესობა მზადაა დაიცვას ინსტრუქციები, რომლებიც იწყება სიტყვებით „გამორთეთ ანტივირუსული და ფაერვოლი“, ხოლო სერტიფიკატის დაყენებისას, რამდენიმე ადამიანი თუ კი დაინახავს უბრალო პოტენციური საფრთხეს.