Exposing Security and Privacy Liabilities in Modern Browsers

Exposing security and privacy liabilities in modern browsers

Nikolaos Tsalis

March 2017

Exposing security and privacy liabilities in modern browsers

Nikolaos Tsalis

A dissertation submitted

for the partial fulfillment of a Ph.D. degree

March 2017

Supervising Committee:

1. Dimitris Gritzalis, Professor, Athens University of Economics & Business (Chair) 2. Theodoros Apostolopoulos, Professor, Athens University of Economics & Business 3. Ioannis Marias, Assistant Professor, Athens University of Economics & Business

Examination Committee:

1. Dimitris Gritzalis, Professor, Athens University of Economics & Business 2. Theodoros Apostolopoulos, Professor, Athens University of Economics & Business 3. Ioannis Marias, Associate Professor, Athens University of Economics & Business 4. Vasileios Katos, Professor, Bournemouth University, United Kingdom 5. Ioannis Stamatiou, Associate Professor, University of Patra 6. Panos Kotzanikolaou, Assistant Professor, University of Piraeus 7. Alexios Mylonas, Lecturer, Bournemouth University, United Kingdom

iii

Exposing security and privacy liabilities in modern browsers

Nikolaos Tsalis

Department of Informatics Athens University of Economics and Business 76 Patission Ave., Athens GR-10434, Greece

All rights reserved. No part of this manuscript may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the author.

"Η έγκριση διδακτορικής διατριβής υπό του Τμήματος Πληροφορικής του Οικονομικού Πανεπιστημίου Αθηνών δεν υποδηλοί αποδοχή των γνωμών του συγγραφέως.”

(Ν. 5343/ 1932, άρθρο. 202)

Acknowledgements

First and foremost, I would like to thank my Ph.D. supervisor Prof. Dimitris Gritzalis. We met back in 2008, while I was on my second year of undergraduate studies. I had selected Information Systems Security as an optional module without too much thought, as I was certain from the beginning that this was the field I would like to excel and purchase a career in. Mr. Gritzalis, as my academic shepherd, I thank you for your support and inspiration during my studies, but most importantly your patience and guidance throughout my life. I would also like to thank Prof. Theodoros Apostolopoulos and Associate Prof. Ioannis Marias for their support and inspiration during my undergraduate studies and Prof. Jason Crampton (Royal Holloway) who guided me in my preliminary steps in research by supervising my MSc thesis. Secondly, I would like to thank Prof. Alexios Mylonas for his guidance during my academic path, as well as along my personal life, where he stood better than I hoped for. I am grateful that I shared my research journey with Prof. Vasileios Katos and Dr. Nikos Virvilis. Also, I would like to thank Dr. Vasilis Tsoumas, Dr. Stelios Dritsas, Dr. Marianthi Theocharidou and Dr. Giannis Soupionis. They were the ones that helped me the most on my first research steps, either by co-authoring, reviewing or tutoring. I am grateful for their support and professionalism but mainly for their friendship. I also want to thank Dr. George Stergiopoulos, Miltiadis Kandias and Vasilis Stavrou for their support, cooperation, and their friendship, which guided us all through time. Furthermore, I am thankful to Prof. Panos Constantopoulos and Prof. Theodoros Apostolopoulos for offering me a position as a systems and network administrator during my academic research. I am also thankful to Dr. Theorodos Ntouskas, Antonia Nisioti, Despoina Metzelioti, Georgia Lykou and George Iakovakis for their friendship and support during these years. Finally, I would like to thank all the people that stood right besides me all my life; my parents for their endless love and support, my family for their guidance and Elena Hadjiyiangou for her support and patience all these years.

Time will always heal the mind, but the heart will never forget.

Dedication

To those who take care of us, even from far away. To the people I loved and cared for. We will all be together in the end.

vii

Abstract

The number and complexity of the available online threats have been increasing steadily in recent years. One of the primary goals of the attackers is financial gains against the users, who can barely protect themselves against such threats. This matter is further empowered by the weakened security environment that users operate in. More specifically, the average user is not technologically savvy, especially when it comes to the security aspect of the technology she uses, while she is not familiar with the available security countermeasures along with their usage. Similarly, the manufacturers must supposingly take care of an untrained user by providing an adequate level of security and privacy certainty, when the user is performing her online browsing activities, via the use of a simple browser. In contrast, it is proven to be more than challenging to achieve the golden ratio between usability and security, while the scale usually leans on the former. The online threat landscape is continuously expanding due to the sophisticated types of theats and vulnerabilities that exist within a browser environment. For instance, modern browsers adopt additional features and services, with a view on funtionality, and thus further attack entry points are created that could surely aim in user’s security and privacy. By analyzing the security perspective of modern browser, one can easily result in the priorities that are set by the manufacturers, which are translated into significant threats that are currently available. To be more specific, phishing attacks are considered to be one of the most perilous threats, where the user is deceived into discolusing sensitive personal information. Similarly, the malware threat is equally important since, due to its complexity, it is more difficult to deal with. Privacy threats are also available which aim in the aforementioned information disclosure. Browser manufacturers are aware of the formerly mentioned threat landscape and have implemented several controls within modern browsers. Such controls are utilized as either built- in controls to the browser itself, or additional services (i.e. add-ons) that enhance or substitute the build-in ones. In addition, users rely on manufacturers for their protection and are not aware of how to operate the existing controls or implement additional ones for enhanced security. In order to protect the average user’s security and privacy in the online environment, it is vital to evaluate the existing defences and redisign the technologies that appear to be less effectictive as expected. The purpose of this thesis is to offer a comprehensive view of the online threat problem through analyzing the currently offered countermeasures along with their features, attack paths and techniques that are utilized. Such an approach will provide a clear view of whether the manufacturers do provide an adequate level of security from a quantitative perspective. In addition, the qualitative evaluation of some of the aforementioned controls are a focal point of

viii this thesis. More specifically, those anti-threat mechanisms are put to the test via our assessment methodology and, in some cases, further enhancements or alternative sollutions are proposed and evaluated, in comparison to their predecessors.

(this page is intentionally left blank)

Extended abstract (in Greek)

Ο αριθμός και η πολυπλοκότητα των απειλών στο διαδίκτυο, έχουν αυξηθεί σταθερά τα τελευταία χρόνια. Ο βασικός στόχος των επιτιθέμενων είναι τα οικονομικά κέρδη έναντι των χρηστών, οι οποίοι δύσκολα μπορούν να προστατευθούν από τέτοιου είδους επιθέσεις. Το γεγονός αυτό ενισχύεται περαιτέρω από το αποδυναμωμένο περιβάλλον ασφαλείας μέσα στο οποίο λειτουργούν χρήστες καθημερινα. Πιο συγκεκριμένα, ο μέσος χρήστης δεν είναι επαρκώς ενημερωμένος σε θέματα τεχνολογίας, ειδικά σχετικά με θέματα ασφάλειας, ενώ παράλληλα, δεν γνωρίζει ποια είναι τα υπάρχοντα αντίμετρα ή πώς να τα χρησιμοποιεί. Ομοίως, οι κατασκευαστές των browers, είναι υποχρεωμένοι να προστατεύσουν τον ανεκπαίδευτο μέσο χρήστη και να του παράξουν ένα ανεκτό επίπεδο ασφάλειας όταν επισκέπτεται το διαδίκτυο. Όμως, έχει αποδειχθεί πως είναι αρκετά δύσκολο να βρεθεί η χρυσή τομή ανάμεσα στην χρηστικότητα και την ασφάλεια, ενώ συνήθως, το τελικό αποτέλεσμα της υλοποίησης των κατασκευαστών τείνει προς όφελος της πρώτης. Παράλληλα, οι υπάρχοντες απειλές και επιθέσεις, έχουν γίνει περισσότερες σε πλήθος και πιο πολύπλοκες. Για παράδειγμα, οι νέοι browsers περιέχουν επιπρόσθετα στοιχεία και υπηρεσίες (π.χ. JavaScript, Flash) με σκοπό την αυξημένη λειτουργικότητα, το οποίο έχει ως αποτέλεσμα την αύξηση των ευπαθειών και απειλών σχετικά με την ασφάλεια και την ιδιωτικότητα του χρήστη, δεδομένου ότι τα κενά ασφάλειας των υπηρεσιών αυτών κληρονομούνται στους browsers. Μέσω της ανάλυσης της ασφάλειας ενός σύγχρονου browser, είναι εμφανείς οι προτεραιότητες που έχουν τεθεί από τους κατασκευαστές, ως προς την προτεραιοποίηση των απειλών που υπάρχουν. Πιο συγκεκριμένα, οι απειλές τύπου phishing, έχουν χαρακτηριστεί ιδιαίτερα σημαντικές καθώς στοχεύουν στην απόκτηση προσωπικών δεδομένων του χρήστη. Το ίδιο ισχύει και για τις απειλές τύπου malware, οι οποίες είναι εξίσου σημαντικές, ιδιαιτέρως εξαιτίας της πολυπλοκότητάς τους, καθώς επίσης και οι τύποι των απειλών που στοχεύουν στην πλήξη της ιδιωτικότητας του χρήστη. Οι κατασκευαστές των browsers έχουν υλοποιήσει συγκεκριμένα αντίμετρα για να προστατεύσουν τον χρήστη ενάντια στις προαναφερθέντες απειλές. Τα αντίμετρα αυτά είναι είτε προεγκατεστημένα στους browsers, είτε προσφέρονται ως επιπρόσθετα (add-ons) με σκοπό να ενισχύσουν ή να αντικαταστήσουν τους προεγκατεστημένους μηχανισμούς ασφάλειας. Επιπροσθέτως, οι χρήστες βασίζονται στους κατασκευαστές για την προστασία τους, καθώς δεν γνωρίζουν ποια είναι τα αντίμετρα αυτά, ούτε πώς να τα χρησιμοποιήσουν, όπως αναφέρθηκε προηγουμένως. Σκοπός της παρούσας διατριβής είναι η μελέτη και αξιολόγηση των μέτρων ασφάλειας και ιδιωτικότητας που προσφέρονται από τους browsers, τόσο σε σταθερούς υπολογιστές (desktop και laptop) όσο και στις υπόλοιπες σχετικές συσκευές (smartphones και tablets). Πιο

συγκεκριμένα, χωρίζεται σε δύο επιμέρους κομμάτια στα οποία (α) χαρτογραφούνται τα σχετικά αντίμετρα, παράλληλα με τα χαρακτηριστικά και τις ιδιαιτερότητές τους και (β) αξιολογούνται τα πιο σημαντικά από αυτά, με βάση την αποδοτικότητα και την αποτελεσματικότητά τους απέναντι στις απειλές για τις οποίες είχαν αρχικά σχεδιαστεί.

Η συνεισφορά της διατριβής στην ερευνητική περιοχή της ασφάλειας και ιδιωτικότητας των browsers, συνοψίζεται ως εξής:

 Τεχνική ανάλυση των αντίμετρων που είναι διαθέσιμα στους browsers. Αναλύεται η προστασία που παρέχεται από τις αρχικές ρυθμίσεις των browsers καθώς και η δυνατότητα ρύθμισης των αντιμέτρων των browsers. Η ανάλυση αποκαλύπτει ότι: (α) μόνο ένα υποσύνολο των διαθέσιμων αντιμέτρων που παρέχουν οι browsers των υπολογιστών είναι διαθέσιμα στους browsers των smartphones, (β) οι browsers των smartphones παρέχουν περιορισμένες δυνατότητες ρύθμισης σε σχέση με τους browsers στους υπολογιστές, (γ) οι χρήστες των smartphone είναι εξαιρετικά ευάλωτοι σε ιστότοπους με ιομορφικό λογισμικό ή/και επιθέσεις phishing, καθώς τα διαθέσιμα αντίμετρα δεν είναι διαθέσιμα στους browsers των smartphones, και (δ) οι αρχικές ρυθμίσεις των browsers και στις δυο υπολογιστικές πλατφόρμες δεν προστατεύουν τους χρήστες από απειλές που προσβάλουν την ιδιωτικότητα τους (παρακολούθηση πλοήγησης του χρήστη, δημιουργία προφίλ του χρήστη κτλ.).  Τεχνική ανάλυση των αντίμετρων που προσφέρονται στους browsers μέσω των επίσημων marketplaces των κατασκευαστών. Η ανάλυση αυτή απέδειξε συγκεκρικένες ευπάθειες στην κατηγοριοποίηση που έχει πραγματοποιηθεί από τους κατασκευαστές, όπου σε κάποιες περιπτώσεις υπήρχε λάθος κατηγοριοποίηση του εν λόγω αντιμέτρου, ενώ σε άλλες οι προσφερόμενες κατηγορίες ήταν ελάχιστες. Επιπροσθέτως, εντοπίστηκε μεγάλη διαφοροποίηση ανάμεσα στους εξεταζόμενους browsers ως προς το πλήθος των προσφερόμενων αντιμέτρων.  Αξιολόγηση της αποτελεσματικότητας των αντίμετρων ασφάλειας για επιθέσεις τύπου phishing. Μέσω συγεκριμένης μεθοδολογίας που περιλάμβανε πειράματα ελέγχου απόδοσης, ελέγχθησαν οι μηχανισμοί ασφάλειας ani-phishing. Πιο συγκεκριμένα, χρησιμοποιήθηκαν URLs από έγκυρες πηγές (π.χ. Phishtank), που περιήχαν τέτοιου είδους ιστοσελίδες, τα οποία προσπελάσσανε οι εκάστοτε browsers για να εκτιμηθεί το αν θα προστατεύσουν απέναντι στην απειλή αποδοτικά ή όχι. Τα αποτελέσματα των πειραμάτων έδειξαν μεγάλη διαφοροποίηση ανάμεσα στις δύο πλατφόρμες (desktop και smartphones), η οποία αποδείδεται στις ιδιαιτερότητες της εκάστοτε τεχνολογίας. Επιπροσθέτως, αναλύθηκαν οι καμπάνιες τύπου phishing, από τις ίδιες πηγές, με σκοπό την απεικόνιση του πως δρα ένας επιτηθέμενος σε μία επίθεση τύπου phishing.

xii

 Αξιολόγηση της αποτελεσματικότητας των αντίμετρων ασφάλειας για επιθέσεις τύπου malware. Σύμφωνα με την προαναφερθείσα μεθοδολογία, αξιολογήθηκαν τα αντίμετρα για απειλές τύπου malware, που υπάρχουν στους σύγχρονους browsers. Τα αποτελέσματα έδειξαν πως το συγκεκριμένο αντίμετρο είναι χαμηλότερο σε απόδοση σε σύγκριση με το αντίστοιχο για απειλές τύπου phishing.  Υλοποίηση αντίμετρου για απειλές τύπου malware. Δεδομένης της χαμηλής απόδοσης των υπαρχόντων μηχανισμών απέναντι στις απειλές malware, η παρούσα διατριβή περιλαμβάνει μία νέα πρόταση-υλοποίηση που στοχεύει στην ενίσχυση της προστασίας του χρήστη. Πιο συγκεκριμένα, υλοποιήθηκε και δοκιμάστηκε σε όλους του εξεταζόμενους browsers η λύση αυτή, η αξιολόγηση της οποίας κατέληξε στο γεγονός ότι ήταν αμειδρώς καλύτερη από την υπάρχουσα, εξαιτίας και της πολυπλοκότητας του είδους της απειλής.  Αξιολόγηση αποτελεσματικότητα αντιμέτρου ιδιωτικής περιήγησης. Χαρτογράφηση και ανάλυση των στοιχείων (artefacts) που παραμένουν διαθέσιμα μετά από μία συνεδρία ιδιωτικής περιήγησης. Τα αποτελέσματα των πειραμάτων, συγκρίθηκαν με το τι δηλώνουν οι κατασκευαστές πως ισχύει, για το αν παραμένουν διαθέσιμα ή όχι, με σκοπό να αποτυπωθεί η ορθότητα της ενημέρωσης που λαμβάνει ο μέσος χρήστης από τους κατασκευαστές των browsers. Επιπλέον, θεωρήθηκε απαραίτητο να καταγραφεί η γνώση και η άποψη του μέσου χρήστη, μέσω σχετικής έρευνας, για το ποια στοιχεία θεωρεί πως παραμένουν διαθέσιμα και ποια θα ήταν ιδιαίτερα ενοχλητικό αν παρέμεναν. Η έρευνα αυτή αποτύπωσε τις προτεραιότητες που πρέπει να τεθούν, σύμφωνα με τον μέσο χρήστη.  Ανάλυση νέας προσέγγισης ιδιωτικής περιήγησης. Πραγματοποιήθηκε μελέτη για την ιδιωτική περιήγηση, η οποία χωρίστηκε σε δύο επιμέρους σημεία. Στο πρώτο σημείο, εξετάστηκε αν μπορεί να χρησιμοποιηθεί μία υλοποίηση λύσης που βασίζεται στην RAM του συστήματος, έτσι ώστε ο μέσος επιτηθέμενος να μην έχει την δυνατότητα άμεσης πρόσβασης στις πηγές των στοιχείων που δημιουργούνται κατά την περιήγηση ενός χρήστη στο διαδίκτυο. Ενώ στο δεύτερο, επεκτάθηκε το προηγούμενο σενάριο, περιλαμβάνοντας ασφαλή διαγραφή των περιεχομένων της RAM, για να αποφευχθεί η ανακάλυψη τους από ένα περισσότερο έμπειρο επιτηθέμενο, με επιπλέον γνώσεις ανάλυσης.

Τα κεφάλαια της διατριβής συνοψίζονται ως εξής:

Στο Κεφάλαιο 2 παρουσιάζεται το υπόβαθρο της διατριβής. Πιο συγκεκριμένα, ορίζεται ο browser και τα επιμέρους χαρακτηριστικά του και αναλύονται οι σχετικές δημοσιευμένες εργασίες όσον αφορά την ασφάλεια και την ιδιωτικότητα της συγκεκριμένης υπηρεσίας. Επιπλέον, το κεφάλαιο περιλαμβάνει το μοντέλο απειλής που ακολουθείται στην παρούσα διαυτιβή, καθώς και την σύνοψη των παραπάνω.

xiii

Το Κεφάλαιο 3 περιλαμβάνει μια συγκριτική μελέτη της διαθεσιμότητας και της δυνατότητας ρύθμισης των αντίμετρων των browsers. Το πεδίο της έρευνας περιλαμβάνει τους δημοφιλείς browsers των ηλεκτρονικών υπολογιστών και των smartphones. Από την μία πλευρά χαρτογραφούνται και αναλύονται τα αντίμετρα που είναι προ-εγκατεστημένα και συγκρίνονται τα αποτελέσματα που αξιολογούνται και στις δύο πλατφόρμες. Ενώ από την άλλη, εξετάζονται τα αντίμετρα που προσφέρονται ως προσθήκες (add-ons) από τους κατασκευαστές, με σκοπό την ενίσχυση ή αντικατάσταση των υπαρχόντων αντιμέτρων, χωρίς όμως να είναι προ-εκατεστημένα στον εκάστοτε browser. Στο Κεφάλαιο 4, το οποίο χωρίζεται σε δύο επιμέρους υποκεφάλαια, γίνεται μελέτη της αποδοτικότητας των προαναφερθέντων αντιμέτρων ασφάλειας που εντοπίζονται στους σύγχρονους browsers. Πιο συγκεκριμένα, μέσω της ανάλυσης του συνόλου των αντιμέτρων που εντοπίζονται, είναι εμφανές πως οι κατασκευαστές έχουν χαρακτηρίσει τρεις απειλές ως τις περισσότερο σημαντικές, συγκριτικά με την βαρύτητα της προστασίας που έχουν δώσει προς αυτές. Τα μέτρα αυτά περιλαμβάνουν προστασία ενάντια επιθέσεων (α) τύπου phishing, (β) μέσω ιομορφικού λογισμικού και (γ) που στοχεύουν στην προσβολή της ιδιωτικότητας του χρήστη. Ως αποτέλεσμα, μέσω της μεθοδολογίας της παρούσας διατριβής, τα προαναφέρθέντα αντίμετρα εξετάστηκαν με επίκεντρο της αποδοτικότητά τους απέναντι στην απειλή για την οποία είχαν αρχικά σχεδιαστεί. Επιπροσθέτως, το παρόν κεφάλαιο περιλαμβάνει προτάσεις, και αξιολόγηση αυτών, που αποσκοπούν στην ενίσχυση ή ακόμα και αντικατάσταση των αντιμέτρων αυτών, ειδικά στις περιπτώσεις όπου τα πειράματα έδειξαν στο ότι τα αντίμετρα αυτά ήταν μη επαρκή ως προς την απόδοσή τους. Η διατριβή ολοκληρώνεται στο Κεφάλαιο 5 με τη σύνοψη και προτάσεις για μελλοντική έρευνα.

xiv

Table of Contents

LIST OF FIGURES XVIII

LIST OF TABLES XIX

1 INTRODUCTION 22

1.1 RESEARCH MOTIVATION 22 1.2 RESEARCH STATEMENT AND APPROACH 24 1.3 CONTRIBUTIONS 25 1.4 DISSERTATION OUTLINE 26

2 BACKGROUND 28

2.1 BROWER DEFINITION AND ARCHITECTURE 28 2.2 BROWSER SECURITY 29 2.2.1 BROWSER CONTROLS 29 2.2.2 PHISHING ATTACKS 30 2.2.3 MALWARE ATTACKS 32 2.2.4 PRIVATE BROWSING 33 2.3 THREAT MODEL 35 2.4 SUMMARY 36

3 COUNTERMEASURES AGAINST WEB THREATS 38

3.1 BROWSER CONTROLS 38 3.1.1 METHODOLOGY 40 3.1.2 AVAILABILITY AND MANAGEABILITY OF SECURITY CONTROLS 41 3.1.2.1 CONTENT CONTROLS 42 3.1.2.2 PRIVACY CONTROLS 43 3.1.2.3 BROWSER MANAGEABILITY 45 3.1.2.4 THIRD-PARTY SOFTWARE CONTROL 47 3.1.2.5 WEB BROWSING CONTROLS 49 3.1.2.6 OVERALL AVAILABILITY OF CONTROLS 51 3.1.2.7 PROTECTION FROM WEB THREATS 52 3.1.3 RECOMMENDATIONS 55 3.2 BROWSER ADD-ONS 60 3.2.1 METHODOLOGY 60 3.2.1.1 SECURITY AND PRIVACY CONTROLS 60 3.2.1.2 SECURITY AND PRIVACY ADD-ONS 61 3.2.2 RESULTS 62 3.2.2.1 REVISITING PRE-INSTALLED SECURITY CONTROLS 62 3.2.2.2 SURVEY OF BROWSERS ADD-ONS 64 3.2.3 DISCUSSION 66 3.2.3.1 REVISITING PRE-INSTALLED SECURITY CONTROLS 66 3.2.3.2 SURVEY OF ADD-ONS 67 3.2.4 OVERALL AVAILABILITY OF ADD-ONS 69 3.3 DISCUSSION 71

4 EVALUATION OF BROWSER CONTROLS 75

4.1 PHISHING PROTECTION 75 4.1.1 INTRODUCTION 75

4.1.2 METHODOLOGY 76 4.1.3 RESULTS 78 4.1.3.1 OVERVIEW 78 4.1.3.2 IOS BROWSERS 80 4.1.3.3 ANDROID BROWSERS 80 4.1.3.4 DESKTOP BROWSERS 80 4.1.4 SAFE BROWSING API 81 4.1.5 RESULTS REVISITED 82 4.1.5.1 TEST METHODOLOGY 82 4.1.5.2 IOS BROWSERS 84 4.1.5.3 ANDROID BROWSERS 85 4.1.5.4 DESKTOP BROWSERS 85 4.1.5.5 COMPARISON WITH PREVIOUS EVALUATION 86 4.1.6 PHISHING CAMPAIGNS 87 4.1.7 ANALYSIS OF PHISHTANK’S STATISTICS 88 4.1.8 DISCUSSION 90 4.2 MALWARE PROTECTION 92 4.2.1 INTRODUCTION 92 4.2.2 EXPERIMENTS AND METHODOLOGY 94 4.2.2.1 TEST METHODOLOGY 94 4.2.2.2 MALWARE TESTS 95 4.2.3 EXPERIMENTAL RESULTS 96 4.2.3.1 IOS BROWSERS 96 4.2.3.2 ANDROID BROWSERS 96 4.2.3.3 DESKTOP BROWSERS 97 4.2.4 SECURE PROXY 98 4.2.4.1 ARCHITECTURE 98 4.2.4.2 SECURE PROXY EVALUATION 99 4.2.4.3 URL-ONLY AND HASH-BASED ANALYSIS 100 4.2.4.4 FILE-BASED ANALYSIS 101 4.2.4.5 PERFORMANCE EVALUATION 102 4.2.5 DISCUSSION 102 4.2.5.1 LIMITATIONS 102 4.2.5.2 PROTECTION OF DESKTOP AND MOBILE BROWSERS 103 4.2.5.3 PROPOSED COUNTERMEASURE 105 4.3 PRIVATE BROWSING 108 4.3.1 INTRODUCTION 108 4.3.2 METHODOLOGY 109 4.3.3 RESULTS 111 4.3.3.1 BROWSER DOCUMENTATION 111 4.3.4 BROWSER DATA SOURCES 113 4.3.4.1 SUMMARY OF MODIFICATIONS IN THE FILESYSTEM 113 4.3.4.2 LOCATION AND ANALYSIS OF ARTEFACTS 114 4.3.4.3 GENERIC ARTEFACTS 114 4.3.4.4 BROWSER ARTEFACTS 117 4.3.4.5 WEBSITE ARTEFACTS 119 4.3.5 SUMMARY OF FINDINGS 120 4.3.6 USER SURVEY 122 4.3.7 CASE STUDY: VIRTUAL FILESYSTEM VS. PRIVACY VIOLATIONS 126 4.3.7.1 COUNTERMEASURE SETUP 126 4.3.7.2 VERIFICATION OF THE PROPOSED COUNTERMEASURE 127

xvi

4.3.8 DISCUSSION 129 4.3.9 LIMITATIONS 131

5 CONCLUSIONS 133

5.1 SUMMARY AND DISCUSSION 133 5.2 PUBLICATIONS 134 5.3 FUTURE WORK 135 5.4 CONCLUDING REMARKS 136

REFERENCES 139

APPENDIX 149

A. SECURITY EVALUATION OF WEB BROWSERS 149 B. SECURITY EVALUATION OF BROWSER ADD-ONS 154 C. MALWARE MATERIAL 156 D. PRIVATE BROWSING MATERIAL 160

xvii

List of Figures

Figure 1: Availability of security controls in web browsers...... 51 Figure 2: Preconfigured enabled security controls...... 55 Figure 3: Manageability of security controls...... 56 Figure 4: Available add-ons in Safari (n=38) ...... 65 Figure 5: Available add-ons in Chrome (n=65) ...... 65 Figure 6: Available add-ons in Internet Explorer (n=7) ...... 65 Figure 7: Available add-ons in Firefox (n=65) ...... 65 Figure 8: Available add-ons in Opera (n=52) ...... 66 Figure 9: Overall availability of add-ons (n=227)...... 69 Figure 10: Percentage of blocked URLs (n=5651) ...... 79 Figure 11: Percentage of phishing URLs that were not filtered out (n=5651) ...... 79 Figure 12: URLs not in blacklist and not phishing (manual verification, n=5651)...... 79 Figure 13: Laboratory setup ...... 83 Figure 14: Snippet - HTML content ...... 83 Figure 15: Comparison of anti-phishing protection (Q1 2014 – Q2 2014) ...... 87 Figure 16: Main targets ...... 89 Figure 17: Laboratory setup ...... 95 Figure 18: Snippet - HTML content ...... 95 Figure 19: Proposed architecture ...... 99 Figure 20: Detection percentage of hashes ...... 101 Figure 20 - Detection percentage of executables ...... 102 Figure 22: Phishing URL detection percentage ...... 104 Figure 23. Malicious URL detection percentage ...... 105 Figure 24: Snapshot of password artefact in Opera ...... 115 Figure 25: Snapshot of bookmark artefact in Firefox ...... 115 Figure 26: Snapshot of bookmark artefact in Chrome ...... 115 Figure 27: Snapshot of bookmark artefact in Opera...... 116 Figure 28: Snapshot of bookmark artefact in ΙΕ ...... 116 Figure 29: Snapshot of bookmark artefact revealing Chrome’s history ...... 116 Figure 30: Location of bookmark artefact in moz_bookmarks ...... 116 Figure 31: Website visit id in moz_history_visits ...... 117 Figure 32: OCSP responses’ snapshot in Firefox cache memory ...... 117 Figure 33: Snapshot of Chrome’s guest settings ...... 117 Figure 34: Snapshot of Chrome’s guest content settings ...... 118 Figure 35: Snapshot of permissions artefact in Firefox...... 119 Figure 36: Snapshot from DNS records ...... 120 Figure 37: Snapshot of translation in Google’s Incognito mode ...... 120 Figure 38: Sample responses regarding the artefacts that do not remain after private browsing ...... 123 Figure 39: FAT boot sector of the Scenario 1 while RAMDisk’s process is alive ...... 128 Figure 40: FAT boot sector of the Scenario 1 after the termination of RAMDisk’s process ...... 128 Figure 41: JPEG header and beginning of its contents (Scenario 1) while RAMDisk’s process is alive . 128 Figure 42: JPEG header and beginning of its contents (Scenario 1) after the termination of RAMDisk’s process ...... 129 Figure 43: FAT boot sector of the Scenario 2 before the use of the file shredder ...... 129 Figure 44: FAT boot sector of the Scenario 2 after the use of the file shredder ...... 129 Figure 45: JPEG header and beginning of its contents (Scenario 2) before the use of the file shredder ...... 129 Figure 46: JPEG header and beginning of its contents (Scenario 2) after the use of the file shredder 129

xviii

List of Tables

Table 1. Browser availability in the smartphones that were used in the evaluation...... 41 Table 2. Manageability of content controls...... 43 Table 3. Manageability of privacy controls ...... 44 Table 4. Mechanisms for browser management...... 47 Table 5. Mechanisms for third-party software control...... 48 Table 6. Web browsing controls...... 49 Table 7: Counterexamples about sandbox restrictions ...... 52 Table 8. Taxonomy of browser controls and web threats...... 53 Table 9. Comparison of security-oriented settings vs. preconfigured desktop security settings. The suggestions1,2 do not apply to vendor settings (c.f. Tables 6-10) ...... 58 Table 10. Browsers user base ...... 61 Table 11. Availability of controls (n=32) ...... 63 Table 12. Available security/privacy add-ons per browser ...... 64 Table 13. Browser availability in iOS and Android ...... 77 Table 14. Support of anti-phishing mechanisms ...... 78 Table 15. Detailed results per browser ...... 79 Table 16. Phishing protection statistics on iOS ...... 85 Table 17. Phishing protection statistics on Android ...... 85 Table 18. Phishing protection statistics on Windows ...... 86 Table 19. Main Phishing Campaigns...... 87 Table 20. Phishing URL1 ...... 88 Table 21. PhishTank statistics per month ...... 89 Table 22. PhishTank statistics per category...... 89 Table 23. Main phishing campaigns revisited ...... 90 Table 24. Browser availability on tested platforms ...... 94 Table 25. Malware protection statistics on iOS ...... 96 Table 26. Malware protection statistics on Android ...... 97 Table 27. Malware protection statistics on Windows ...... 97 Table 28. Percentage of blacklisted malicious sites - Secure Proxy vs. Internet Explorer (n=1400) ...... 100 Table 29 – Browsers’ user base (February 2016, (W3schools, 2016a)) ...... 109 Table 30. User activity categorization...... 110 Table 31. Artefacts tested by authors ...... 110 Table 32. Browser documentation regarding private mode ...... 113 Table 33. Total interactions found in the filesystem during the private mode ...... 113 Table 34 – Paths that were modified in the filesystem...... 114 Table 35 – Overall results of the protection that is offered by private mode in each browser. † ...... 121 Table 36. Comparison of the documentation with the results from the analysis regarding the protection that is offered by private mode in each browser. † ...... 122 Table 37. Number of respondents who indicated they would be very upset if an artefact is exposed. 124 Table 38. Browser configuration steps (RAMDisk, 2016) ...... 127 Table 39. Hidden functionality in browsers ...... 149 Table 40. List of common controls that appear in browser settings...... 150 Table 41. Navigation to proxy configuration widget ...... 151 Table 42. Number of security controls that are preconfigured and enabled in each browser ...... 152 Table 43. Number of controls that are manageable from users in each browser ...... 153 Table 44. Number of add-ons in each browser (n=227) ...... 154 Table 45. Desktop browser popularity ...... 156 Table 46. Browser popularity on Android ...... 156 Table 47. Default CIF feeds ...... 156 Table 48. Percentage of URLs that were blacklisted ...... 157 Table 49. Percentage of false negatives ...... 157 Table 50. Percentage of URLs that were manually verified as non-phishing...... 157 Table 51. Malicious file detection based on the hash of the samples ...... 158 Table 52. Malicious file detection based on file analysis (submission of the file) ...... 158

xix

Table 53. VirusTotal AV Engines ...... 159 Table 54. VirusTotal URL reputation providers ...... 159 Table 55. Summary of the results regarding how upset the sample would be if an artefact is exposed...... 163

(this page is intentionally left blank)

xxi

Introduction

1 Introduction

1.1 Research motivation Internet usage has risen during the past years, while during 2016 (Internetworldstats, 2016) almost one out of two users (i.e. 50.1%) uses this service on a daily basis. In fact, the related growth from 2000 to 2016 was more than 900%. In addition, considering the arrival of new types of devices (i.e. smartphones and tablets), which are heavily used, users are capable of using other devices than personal computers for browsing activities, even when on the move. The preceding technological evolution has bolstered the threat landscape that the average user faces when online. More specifically, the browsers that the user uses to go online, serve their purpose at a satisfactory level on the one hand, but at the same time they include certain threats and vulnerabilities that must be taken into consideration from both the manufacturers and the users. The former should aim in achievieng the golden ration between the offered usability and security of their products, while the latter must become more technologically savvy so as to try to protect themselves even when manufacturers fail to do so. As mentioned, average users are not familiar with the details of security controls, which are used while browsing the web. For instance, a user may understand that SSL offers a level of protection to her online transactions (Gritzalis, 2001; Iliadis et al., 2000). It is rather unlikely though, that she is aware of the relevant security details (e.g. cryptography) and threats she is exposed to (e.g. eavesdropping). Also, users come across to different threats while browsing the web which range from traditional client-side attacks (e.g. malicious files), up to recent zero- day exploits that target Java plugins (Reuters, 2016). In contrast, CISCO (2013a) reports that browser malware are not only present in ‘bad’ webpages (e.g. adult websites, gambling, etc.), but also in benign ones (e.g. social media websites, search engines). The latter may unwittingly serve malware embedded in their active content, typically after a server compromise or with the inclusion of malicious advertisements. Furthermore, progressively more attackers use in their client-side attacks browser exploitation frameworks (e.g. Blackhole exploit kit, Phoenix, etc.), which are available in the underground market. One of the major threats that target users suffer by is phishing. Phishing can be deemed as one of the most popular and profitable attacks, having almost 450,000 attacks in 2013 and estimated losses of over 5.9B$. NIST defines phishing (Mell, et al., 2005) as: “Phishing refers to use of deceptive computer-based means to trick individuals into disclosing sensitive personal information. Phishing attacks aid criminals in a wide range of illegal activities, including identity theft and fraud. They can also be used to install malware and attacker tools on a user’s system.”

Introduction

Although the majority of phishing attacks are widespread and focus on financial gain, targeted phishing attacks also appear. These are widely known as spear-phishing and have been used in a large number of sophisticated attacks against government, military and financial institutions. The analysis of past major security incidents has revealed that attackers used targeted phishing attacks in order to gain access to the internal network of their target. Similarly to the phishing threat, the web users might visit rogue web sites, namely sites that serve malicious software (malware) and/or host phishing scams. It is worth clarifying that users might be exposed to such threats not only when they visit nefarious web sites, such as adult websites, ones hosting pirated software or gambling sites. Benign sites (e.g. social media websites) have been misused in the past to deliver phishing/malware attacks after being compromised (i.e., watering hole attacks) (Cisco, 2013). As a result, the likelihood that users will be exposed to such threats, should not be neglected. In addition, the malware threat is constantly increasing, with Kaspersky Labs reporting that over 3 billion attacks were detected in 2013, with a total of 1.8 million malicious or potentially unwanted programs used in these attacks (Kaspersky, 2013a). McAfee Labs Threat Report highlighted that there is a 167 percent growth in mobile malware between 2014 and 2015 (McAfee 2016b). The lack of security awareness of mobile users is well known (Mylonas, Kastania, et al. 2013) and this has been confirmed by a recent report that reveals that 57% percent of adults are unaware of the existence of security solutions for mobile devices (Symantec 2016a). This discovery is very worrying if we take into account the sensitive information stored on smartphones as well as their use to access business resources (e.g. accessing corporate emails, files etc.). Web browsers are the primary line of defense on all platforms, both desktop and mobile, against such attacks. Although it is unrealistic to expect that targeted phishing/malware attacks will be detected by the web browser or any third party security solution (e.g. Antivirus engine), the available security mechanisms on modern browsers must be put to the test regarding their detection efficacy. More specifically, web browsers communicate security events to users through their Graphical User Interfaces (GUIs). For instance, the padlock icon appears every time a user visits a website with a valid digital certificate. Also, browsers include window gadgets (widgets), such as checkboxes, buttons, etc., for the configuration of their security controls. Users are expected to configure the browser’s security controls as they see fit (by interacting with its menu), so as to protect their security and privacy. To aid users in this task, every web browser contains a menu option focused on the configuration of security and/or privacy controls. Even though average users generally tend to ignore security events (Egelman et al., 2008; Motiee et al., 2010; Sunshine et al., 2009), some of them are trained to interact with the above interfaces in desktop browsers towards a safe web browsing.

Introduction

In addition, pre-installed security controls exist in modern browsers, that aim to protect the user from web threats. Similarly, browsers offer additional software, namely add-ons, which extend the functionality of browsers. Add-ons are focused on catergories, such as accessibility, news & weather, photos, productivity, social, etc. One of them (that exists in some of the browsers) is security and/or privacy, which includes add-ons that aim to offer additional security/privacy mechanisms to the user. However, add-ons are based on a community of developers and do not have the same popularitty in the different browser ecosystems. As a result, some add-ons that are valuable at protecting users’ security and privacy (e.g. NoScript) are not available in in some of the browsers (e.g. Internet Explorer).

1.2 Research statement and approach Under the aforementioned circumstances, it is evident that browsers must be protected against security and privacy violations. The security model of a browser must provide a secure ecosystem, by offering the mechanisms that protect users’ security and privacy. By examining the security mechanisms provided to browser users, it is noticed that for their correct use, as in any computing platform, a security concerned user is required. More specifically, the security models expect reasonable security concerned users, who are able to set the bar of the offered security in a level that satisfies their needs. In this thesis the validity of the current level of modern browsers’ security is questioned. Steps are taken in order to understand the manufacturers’ approach towards browser security and the level of security awareness that current users have. More specifically, we taken steps in order to (a) understand how an adequate level of security and privacy is implemented and preserved within modern browsers, (b) identify which are the available countermeasures that stand between the user and the threats and (c) evaluate whether some of the most essential implemented security controls operate in an efficient manner. In this context, this thesis makes the following research statement:

The current state of browser security fails to protect the security and privacy of users.

This thesis contains evidence that support this statement. Our findings suggest that modern browsers’ manufacturers may have included some security and/or privacy controls but have failed to provide a holistic solution towards the threat landscape the average user faces when in her online activities. More specifically, users are exposed to various threats while browsing the web, due to the unavailability or insufficiency of the available security controls. Similarly, our findings reveal manufacturers tend to lean more on the usability perspective and thus the security side is left exposed.

Introduction

1.3 Contributions

This thesis makes the following contributions:  An in-depth technical analysis of web browser controls in smartphones and desktops is performed. The out-of–the box security of web browsers is analysed, as well as the manageability options that are offered for their security controls. The analysis revealed that: (a) smartphone browsers provide a subset of security controls and limited manageability over them, compared to their desktop counterparts, (b) smartphone users are unprotected from rogue websites (i.e. ones that serve malware or host phishing scams) and (c) the default browser settings expose users to third-party tracking/profiling in both platforms.  A thorough analysis of web browser security and/or privacy add-ons in the available marketplaces is performed. This analysis resulted in exposing specific liabilities in the categorization that manufactures propose and a wide disparity among them. For instance, one vendor implemented more than one thousand add-ons, while another one only included 7. Also, in several cases, the categorization was incorrect in terms of either lacking of specific categories, or including an add-on in the wrong category.  The effectiveness of the phishing protection mechanism in smartphones and desktops is evaluated. By following a specific methodology, these mechanisms are evaluated through experiments which include already compromised URLs derived from legitimate sources (i.e. Phishtank). The results showed that a disparity exists among the two platforms (i.e. desktop and smartphones), which mainly exists because of the differences in each technology. In addition, the available phishing campaigns are analyzed, so as to depict the behavior and the way an attacker operated when creating a phishing case.  The effectiveness of the malware protection mechanism in smartphones and desktops is evaluated, based on the aforementioned methodology. More specifically, the anti-malware control is evaluated in both platforms, which resulted in less efficient results, compared to the anti-phishing mechanism. This was applied to almost all of the tested browsers, with the most effective of them scoring no more than 50% in its evaluation.  Implementation of an anti-malware mechanism. The results of the assessment of the current anti-malware mechanisms pointed out that a new enhancement is needed. In that approach, a new anti-malware implementation is proposed, which is applied to all tested browsers. The evaluation of this newly proposed mechanism resulted in slightly higher effectiveness, in comparison with the previous evaluation, while this revealed the difficulty when coping with the malware threat.  The effectiveness of the private browsing control in modern desktop browsers is evaluated. The artefacts that are created when performing browsing activities, are analyzed, along with their sources that each browser uses. Such an approach, gave input to the evaluation phase

Introduction

which outlined which of the aforementioned artefacts still remain available after a private session is terminated. Also, these results were compared to what manufacturers claim about these artefacts, regarding whether they remain available or not. Last, it was considered vital to capture the user’s opinion via a survey, according to which artefacts she though to be available and the level of annoyance created if those where indeed available after her private session.  Evaluating a private browsing approach. A case study included two separate scenarios regarding coping with the identified deviations of the aforementioned private browsing evaluation. The first included the use of a RAM-based system was evaluated on whether it could protect the browser from leaving discriminating artefacts behind. While the second extended the initial case study so as to further protect the RAM-based system via secure deletion of the related RAM contents.

1.4 Dissertation outline The rest of the dissertation s organized as follows: Chapter 2 presents background information, namely the definition of the modern browser, along with its characteristics. The chapter also presents the current state of academic work in browser security, before concluding with the thesis’ threat model. Chapter 3 includes a technical analysis of the availability and configurability of security controls in web browsers and consists of two sections. Initially, it focuses on the analysis of embeded controls in popular browsers of the desktop and smartphone platforms and more specifically content, privacy, browser management, third-party software and web browsing controls. Also, this section compares the results between the two platforms and provides insights about the out-of-the-box protection that is offered by the browsers in each platform. After that, it presents a thorough analysis of the available security and / or privacy add-ons, via a survey in the manufacturers’ marketplaces, along with a discussion over the results. In Chapter 4, which is again separated into two sections, the effectiveness of some of the previously mentioned controls is explored. More specifically, through the analysis in the previous chapter, three controls were caracterized as most crucial, based on the manufacturers’ view. These controls are (a) phishing protection, (b) malware protection and (c) private browsing, all of which are embeded within the browsers as protection mechanisms. Thus, according to our methodology, they are evaluated via tests from a performance perspective, on the grounds of the threat each of them are trying to protect the user from. Additionaly, this chapter includes proposals to enhance or even replace the aforementioned controls, in cases that their evaluation was resulted in them being not sufficient enough. Chapter 5 concludes the dissertation with a summary, concluding remarks and future work.

Introduction

(this page is intentionally left blank)

Background

2 Background

2.1 Brower definition and architecture The web browser is used to access online webpages and browser their content. More specifically, it is a graphical user interface (GUI) (Google, 2017) which allows access to network servers that include the aforementioned webpages. These mechanisms can be located in all of the available desktop platforms (e.g. Windows, MAC, Linux), as well as their mobile counterparts (i.e. smartphones and tablets). The five most popular browsers used today are: Google Chrome, Internet Explorer, Mozilla Firefox, Safari and Opera, which all hold large shares of the market. Note that each browser’s popularity and usage varies according to the platform the user operates on. According to (HTML5, 2017), a browser’s main funtionality is to provide the user with access to specific resource that she chooses, for instance a specific webpage, a document, an image, etc. This is achieved through its simple architecture, where the important components included are described as follows:  User interface: address bar, back/forward button, bookmarking menu, etc. Every part of the browser display except the window where you see the requested page.  Browser engine: marshals actions between the UI and the rendering engine.  Rendering engine: responsible for displaying requested content. For instance, in the case that the requested content is HTML, the rendering engine parses HTML and CSS, and displays the parsed content on the screen.  Networking: for network calls such as HTTP requests, using different implementations for different platform behind a platform-independent interface.  UI backend: used for drawing basic widgets like combo boxes and windows. This backend exposes a generic interface that is not platform specific. Underneath it uses operating system user interface methods.  JavaScript interpreter: Used to parse and execute JavaScript code.  Data storage: Α persistence layer in case the browser may need to save all sorts of data locally, such as cookies. Browsers also support storage mechanisms such as localStorage, IndexedDB, WebSQL and FileSystem.

Background

2.2 Browser security

2.2.1 Browser controls

Modern browsers have implemented security countermeasures, in the form of controls, so as to protect the users against the existing threats. These mechanisms are either built-in, within the browser, or can be casted upon afterwards, as add-on features. Current literature deals with browser security oriented issues, so as to enhance the current security landscape. To begin with (Botha et al., 2009), provides a simple comparison of the availability of security options that exist between Internet Explorer 7 (for Windows XP) and Internet Explorer Mobile (for Windows Mobile 6 Professional Edition). This work examines the availability of the security controls in current web browsers, as well as their manageability and the preconfigured protection against web threats. In addition, (Amrutkar et al., 2012), focused on the visibility of secrity indicators in smartphones. Recent literature on web security has focused on the protocols for secure connections (i.e. SSL/TLS). It has exposed vulnerabilities in the protocol itself (AlFardan and Paterson, 2013; Panday, 2011; Paterson et al., 2011;), as well as in the way the protocol is implemented in devices (Fahl et al., 2012; Georgiev et al., 2012). Literature has also focused on the visibility of security indicators in desktop browsers, mostly focusing on invalid digital certificates, indicating the majority of users tend to ignore them (Amrutkar et al., 2012; Egelman et al., 2008; Fahl et al., 2012; Schechter et al., 2007; Shin and Lopes, 2011;Sunshine et al., 2009). The extra functionality that is offered by the capability of browsers to execute code in the client side has been exploited by attackers via JavaScript malware (Johns, 2008). In response to the threat of malicious content, browser security literature has focused on the proposition of novel browser security architectures, which either extend a browser architecture with new components that offer enhanced security (Amrutkar and Traynor, 2012; Barth et al., 2010; Carlini et al, 2012; Chen et al, 2011; Meyerovich and Livshits; 2010), or provide new browser architectures (De Groef et al., 2012; Grier et al., 2008; Jang et al., 2012; Wang et al., 2009). Researchers have also proposed detection mechanisms tailored for JavaScript malware, using either static (Canali et al, 2011; Cova et al, 2010; Curtsinger et al., 2011) or dynamic analysis (Jang et al, 2010; Kolbitsch et al., 2012; Saxena et al, 2010) techniques. Furthermore, (Amruktar, et al., 2012) focuses on the visibility of security indicators in smartphones. Carlini et al. performed a security review of 100 Google Chrome’s extensions, which resulted in 70 located vulnerabilities across 40 of the total extensions examined (Carlini, et al., 2012). In addition, (Li, et al., 2007) proposed a privacy preserving mechanism called “SpyShield”, which enhances spyware protection by detecting malicious add-ons, that aim to monitor sensitive information, which was tested on the Internet Explorer browser. Similarly,

Background

Kapravelos et al. in (Karpravelas, et al., 2014) focused on detecting malicious behavior of browser extensions. Such an approach included monitoring the extensions’ execution phase in corellation with the related network activity, for anomaly detection. Lastly, (Barth, et al., 2009) analyzed 25 of the most popular Firefox’s extensions. They have found that 88% of them need less than the full set of the available privileges and they have proposed a novel extension system that enforces the least privilege principle.

2.2.2 Phishing attacks

The main defence against phishing attacks is based on lists (i.e. 'blacklists'), which are used by browsers to identify if a requested URL must be blocked or not. Such a prominent blacklist is Google’s Safe Browsing (Google, 2014), which protects users both from phishing and malware web sites. Safe Browsing is currently used by Google Chrome, Mozilla Firefox and Apple Safari browsers. Internet Explorer is using Microsoft’s proprietary blacklist, the SmartScreen (SmartScreen, 2014). Other browsers also use their own proprietary lists, as well as aggregate information from third parties. For instance, Opera uses a combination of blacklists from Netcraft (Netcraft, 2014) and PhishTank (PhishTank, 2014), as well as a malware blacklist from TRUSTe (TRUSTe, 2014). Although each blacklist implementation is different, all of them follow a basic concept, i.e., before a URL is loaded by the browser, a URL check occurs via data from a local or remote database. If the current URL matches a known malicious site, a warning is raised to the user advising her to avoid browsing to the current URL. Limited information is available on how these blacklists get updated and maintained, as this could enable attackers to bypass them more easily. However, a considerable part of the submissions to blacklist are performed manually by users (PhishTank, 2014). Based on the number of the submissions to anti-phishing sites, such as PhishTank, it turns out that phishers are still very active, generating several hundred phishing pages/domains on a daily basis. The main reason for the popularity of such attacks, regardless of the attacker’s objective (e.g. identity theft, malware infection, information gathering, etc.), is their effectiveness. The use of blacklists always allows a window of several hours - on average 26 hours - when attackers can exploit their victims (Abrams, et al., 2013). To make the matters worse, our work shows that this window is significantly larger on mobile devices (i.e. Safari Mobile) due to the way blacklists are getting updated. The academic literature has also focused on combating this threat. As a result, a number of approaches have been proposed in an effort to protect the users from phishing attacks. This research varies from surveys regarding user awareness, to experiments of the effectiveness of current security mechanisms and proposals of novel ones. More specifically, the work in (Banu,

Background et al., 2013), (Rosiello, et al., 2007), (Rani, et al., 2014) focuses on phishing with regards to its properties, characteristics, attack types, and available counter-measures. Also, (Rank, et al., 2014) and (Jansson, et al., 2013) present a survey on user training methods, as well as their effectiveness against phishing attacks, as user participation plays an major role in phishing protection. Literature has also focused on the use of visual indicators to protect users from phishing. In (Bian, et al., 2013) an overview of the warning indicators and its advances over the last decade is presented. Also, (Darwish and Bataineh, 2012) has surveyed users’ interaction with security indicators in web browsers. A study on the effectiveness of browser security warnings was published in (Akhawe and Felt, 2013), focusing on the Google Chrome and Mozilla Firefox browsers. The authors collected over 25M user reactions with phishing and malware security warnings, measuring the user reactions to these warnings. A similar study (Egelman and Schechter, 2013) analyzed the impact on the users' decision based on the choice of background color in the warning and the text descriptions that were presented to them. In (Egelman, et al., 2008), the authors conducted a survey regarding the effectiveness of security indicators, comparing the warning messages of Firefox and Internet Explorer. In (Sheng, et al., 2008), the authors focused on the effectiveness of phishing blacklists, in particular on their update speed and coverage. The authors used 191 phishing sites that had been active for 30 min or less, and compared 8 anti-phishing toolbars. Less than 20% of the phishing sites were detected at the beginning of the test. In addition, they identified that blacklists were updated in different speeds, which varied from 47-83%, 12 hours after the initial test. Similarly in (Kirda and Kruegel, 2005), the authors proposed the use of 'Anti-Phish', a browser extension for the Mozilla Firefox browser, so as to detect web site-based phishing attacks. A Novel-Bayesian classification, based on textual and visual content, was proposed in (Zhang, et al., 2011). Authors used a text classifier, an image classifier, and a fusion algorithm to defend against known properties of phishing attacks. Furthermore, (Rosiello, et al., 2007) provides a methodology that aims to distinguish malicious and benign web pages, which is based on layout similarity between malicious and benign web pages. In (AV, 2012), the authors analyzed 300 phishing URLs and measured the effectiveness of desktop browsers in detecting them. Opera browser offered the highest level of protection, by blocking 94.2% of the phishing sites. In (Mazher, et al., 2013), the authors tested the effectiveness of anti-phishing add-ons for Internet Explorer, Google Chrome and Mozilla Firefox. In their evaluation Google Chrome outscored the other browsers. Finally, in (Abrams, et al., 2013) authors tested popular desktop web browsers (i.e. Firefox, Chrome, Opera, IE, Safari), focusing on the time required for browsers to block a malicious site. The initial results (zero-day) ranged

Background from 73.3% (IE) to 93.4% (Safari), while the final results (7-day) varied from 89.3% (IE) to 96.6% (Firefox). A number of anti-phishing mechanisms have been proposed for use in smartphones. In (Vidas, et al., 2013), the authors investigate the viability of QR-code-initiated phishing attacks (i.e. QRishing) by conducting two separate experiments. A similar approach was presented in (XU and Zhu, 2012), where the authors worked on how notification customization may allow an installed Trojan application to launch phishing attacks or anonymously post spam messages. Related work on browser security revealed that security controls that are typically found on desktop browsers are not provided in their smartphone counterparts (Mazher, et al., 2013), (Mylonas, et al., 2011). In our work we also find that smartphone browsers still do not offer anti-phishing protection. Moreover, the analysis in (Mylonas, et al., 2013) revealed that the implementation of the security controls (among them the security control against phishing attacks) was not hindered by restrictions from the security architecture (i.e. the application sandbox). The related literature does not adequately focus on the effectiveness of anti-phishing mechanisms on Android and iOS browsers.

2.2.3 Malware attacks

Although the majority of browsers rely solely on blacklists to detect malicious URLs, on Windows Internet Explorer and Chrome perform further analysis to detect malicious downloads. Both browsers analyze the metadata of the downloaded file (i.e. digital signature, hash, file’s popularity, etc.) to warn users about potential risks (Rajab et al. 2013), (Microsoft 2011), (Colvin 2011). Furthermore, non-browser specific models have been proposed for the detection of malicious domains through DNS monitoring (Antonakakis et al. 2011), while (Bilge et al. 2011) discusses large-scale, passive DNS analysis techniques to detect domains that are involved in malicious activity. A zero-day anti-malware solution is proposed in (Shahzad et al. 2013), which uses a combination of whitelists and blacklists. The authors discuss that such whitelists do not need signature updates and provide protection against sophisticated zero-day malware attacks by enforcing software restriction policies, which allow only legitimate executables, processes and applications to be executed. In addition, a number of models have been suggested in the literature focusing on malware detection, namely: (a) the AMICO project (Vadrevu et al. 2013), which detects malware downloads in live web traffic using statistical analysis to identify characteristics of malware distribution campaigns, (b) the ZOZZLE (Curtsinger et al. 2011), which detects and prevents JavaScript malware from been deployed in the browser, and (c) the EFFORT system (Shin et al. 2012), which focuses on the detection of malware serving bots. Furthermore, multiple models have been proposed that rely on machine learning techniques: (a) for malware detection

Background

(Kolter & Maloof 2006), (Roberto Perdisci et al. 2008), (Antonakakis et al. 2011), (R Perdisci et al. 2008) and (b) for detection of drive-by downloads (Caballero et al. 2011), (Cova et al. 2010), (Lu et al. 2010), (Provos et al. 2007), (Mavrommatis & Monrose 2008), (H. Zhang et al. 2011). Finally, models focusing on malware and attack propagation models have also been proposed (Komninos et al. 2007), (Kammas et al. 2008). The industry offers a large number of content filtering solutions, ranging from software- based solutions, to Cloud services and hardware appliances. Multiple software solutions exist, such as McAfee’s Site Advisor and Symantec’s Safe Web (Mcafee 2014), (Symantec 2014c). They are usually offered for free or at low cost. However, they require the installation of third- party software/browser extensions and are browser and platform dependent, with limited support for mobile platforms. Commercial content filtering appliances and Cloud Services (e.g. OpenDNS (Opendns 2014)) are popular in enterprises and are usually platform and browser agnostic. However, their effectiveness is hard to measure due to the use of proprietary technologies. Also, their significant cost limits their use. Lastly, a number of online services exists offering file analysis. One of the most popular is VirusTotal (VirusTotal 2014), which utilizes a large number of popular antivirus engines to analyze (suspicious) files. Users can upload and analyze their files, or query the service for files that have already been analyzed by searching their hash. VirusTotal also supports URL scans, querying a URL against a large number of blacklists.

2.2.4 Private browsing

To the best of our knowledge, research regarding private mode and its effectiveness, is still limited and in an early stage. To begin with (Aggarwal et al., 2010) was among the first to cope with the analysis of private browsing and the artefacts that were exposed after the private session. More specifically, Aggarwal et al. tested a subset of the artefacts that were discussed in this work, in earlier versions of Chrome, Firefox, Internet Explorer and Safari. Also, the authors expanded their analysis in both extensions and plugins, so as to identify any security weaknes- ses. They concluded to the inadequate implementation of private mode in those browsers, which exposed users’ activities. They proposed a mechanism for Firefox that protects against extensions that expose browsing artefacts after private mode. In contrast, since the tested browsers were at early versions, the authors’ results should be revisited. In 2011, Oh et al. (2011) focused on analysing the log files created by the browser, focusing on timeline analysis (e.g., timestamps), search history, URL encoding, search keywords and the recovery of deleted data. The authors proposed WEFA, a tool for evidence collection and analysis. Note that only normal browsing mode was analysed, but again, browsers’ versions are currently outdated. In (Said et al., 2011) the authors examined if artefacts were available in the

Background system’s memory. The work in (Ohana and Shashidhar, 2013) focused on portable browsers (e.g., stored on a USB flash drive) and whether artefacts are still available after the session terminates. The approach resembles the work in (Said et al., 2011), in terms of capturing and analyzing RAM, while the artefacts tested included: history, credentials, images and videos. The authors in (Heule et al., 2015) provided a control for that purpose, based on mandatory access control which protects sensitive data that may be accessed and used by extensions in Chrome. Similarly, Lerner et al., (2013) focused on JavaScript extensions by Firefox, while in private mode. The authors verified a number of extensions, from a safety, behavioral and de- bugging perspective that resulted in identifying which extensions could be malicious. Satvat et al., (2014) expanded the work in (Aggarwal et al., 2010), by performing RAM, file system and network analysis, which revealed a notable amount of inconsistencies in the private browsing implementation. The authors also focused on extensions, by developed testing extensions for Chrome, Internet Explorer, Safari and Firefox so as to evaluate whether any browser could leave artefacts that violate user’s privacy. In contrast, Opera and Chrome’s guest mode was not tested, while the examined artefacts only pose as a subset of the tested ones (c.f. Table 31). Ruiz et al., (2015) focused on recovery techniques for page related data (i.e., text and grap- hics) created during private browsing. The authors performed their tests within 4 individual phases: shutdown, freeze, kill process and power down, while each phase indicated the way the browser was terminated (e.g., kill process – browser interruption). Their results showed that all phases included flaws regarding user’s privacy, in terms of acquiring browsing artefacts. In addition, Montasari and Peltola, (2015) analysed both system’s locations and RAM, in all browsers except Opera. Although the used operating system was not mentioned, it is implied that they used Windows for their experiments. Their results showed that Chrome is the most secure browser, since there are no artefacts available after private browsing, while Firefox only included low risk artefacts. In a parallel work, Xu et al., (2015) studied private browsing using the threat model defined in (Aggarwal et al., 2010). They analyzed the data flows that were generated by Firefox and Chrome with a system call tracer (for Linux) and detected the privacy violations that occurred, similarly to our work. To mitigate the identified privacy threats, they implemented UCOGNITO for Firefox and Chrome only, which also sandboxes the browser in order to control and delete the files that are created by the browser. UCOGNITO uses MBOX to redirect (write) access to the filesystem by rewriting file paths in a static location, which can be deleted after the private session. However, as in UCOGNITO the browsing artefacts are stored in the filesystem, they can be recovered even if they are deleted unless secure deletion is used (Gutmann, 1996), which is time consuming. In our work all the browsing artefacts are stored in a virtual filesystem, instead of a long term storage medium (e.g., hard disk). In our work all the browsing artefacts are stored in a virtual filesystem within a volatile medium, instead of a long term storage

Background medium (e.g., hard disk). As a result, any browsing artefact cannot be recovered when the electromagnetic load of the RAM is lost. In addition, secure deletion in the RAM is quicker compared to hard disks. Finally, the proposed solution can be used with any browser irrespective of its technology. In a similar approach, recent works focused on the forensic perspective of mobile versions of web browser. Marrignton et al. (2012) dealt with Chrome’s normal and incognito mode and the forensic traces left behind in comparison to the installed and the portable version of the browser. The results showed that both the installed and portable version revealed the same amount of artefacts, thereby concluding that the portable version of the browser does not offer enhanced security guarantees regarding the user’s privacy. Moreover, Al Barghouthy et al. (2013) evaluated the available solutions that offer privacy protection to users. More specifically, they evaluated the Orweb browser that anonymizes network traffic and avoids saving the browsing history. Their results that the browsing artefacts (e.g., visited URLs, login data, etc.) can be retrieved even when the Orweb browser is used. In addition, a recent survey (Gao et al., 2014) focused on private browsing mode awareness from a user perspective. The authors surveyed 200 users regarding if, why and when they use this feature, and which are its benefits or drawbacks, if any. Finally, this work expands our previous evaluations of the available security mechanisms offered by modern web browsers. In our previous work (Virvilis et al., 2014; Tsalis et al., 2015a) and (Virvilis et al., 2015) the performance of the available malware and phishing mechanisms offered by modern browsers in desktop and smartphone platforms were evaluated from a qualitative perspective. Also, Tsalis et al., (2015b) focused on enumerating, from a quantitative perspective, the available security and / or privacy add-ons and commented on the security provided by modern web browsers in that area. Finally, Mylonas et al. (2013) enumerated the security controls offered by modern browsers in both desktop and smartphone platforms, so as to outline and discuss on any possible gaps between the two counterparts.

2.3 Threat model The chapter assumes average users (i.e. ones that are not security and technical savvy), who have been trained, via the browser’s support pages, to adjust its settings through its GUI (i.e. menu options, buttons, etc.) for a safe web browsing. Thus, it is assumed that some users have been trained to change the default values of security and privacy controls as they see fit, so as to adjust the level of protection that is provided by the browser. Finally, in accordance with the initial threat model, it is assumed that (a) the user has not altered the operating system of her device (e.g. smartphone rooting) and (b) the browser’s security mechanisms are unmodified, i.e. the user has not installed any extension/add-on that adds a security mechanism to the browser (e.g. AdBlockPlus). This type of user is referred to as Alice.

Background

The extended threat model includes three types of attackers. Firstly, it includes an attacker who has unauthorized control over the network. Such an entity, uses active attacks (e.g. ARP spoofing) to conduct Man in the Middle (MiM) attacks and is referred to as Eve. The second type of attacker has control of malicious web servers in the Internet. The servers are either used to distribute malware (e.g. by exploiting vulnerabilities in plugins, add-ons or the browser itself), or to conduct fraud attacks (i.e. phishing). This type of attacker is referred to as Mallory. The last attacker type controls advertising services used for ‘malicious’ user tracking and is referred to as Gorwel. More specifically, Gorwel uses advanced user tracking mechanisms (e.g. non-persistent tracking data (Eckersley, 2010)), aiming at user profiling and/or user identification. The use of such malicious user tracking constitutes an intrusion of Alice’s fundamental right to privacy (Commission of the European Communities, 2006). It is worth noting that using an advertising service on the web is not a malicious act per se.

2.4 Summary This chapter presented a definition of the term browser along with a review of the academic work in browser security and its related components. Our study reveals that the majority of the academic work concentrates in a small extend of the security controls available in modern browsers, along with their corresponding add-on enhancements. This is of great importance since the installation of the majority of the proposed security controls requires advanced technical skills from the users, who rely on the manufacturers for a “pre-installed” protection.

Background

(this page is intentionally left blank)

Countermeasures against web threats

3 Countermeasures against web threats

3.1 Browser controls The proliferation of smartphones has introduced new challenges in secure web browsing. These devices often have limited resources, as well as small size, which may limit the security ‘arsenal’ of their users. Such lack of protection controls, however, does not seem to hinder users from browsing the web via smartphones. On the contrary, according to a recent report (CISCO, 2013b), by 2017 smartphone mobile data traffic will increase 81%, comparing to 2012. The same report predicts that smartphones will be responsible for the 67.5% of mobile traffic growth in 2017. Average users – i.e. not security and/or technical savvy ones – are not familiar with the details of security controls, which are used while browsing the web. For instance, a user may understand that SSL offers a level of protection to her online transactions (Gritzalis, 2001; Ili- adis et al., 2000). It is rather unlikely though, that she is aware of the relevant security details (e.g. cryptography, server authentication, etc.) and threats she is exposed to (e.g. eavesdropping, session hijacking, etc.). Nowadays, users come across to different threats while browsing the web. These range from traditional client-side attacks (e.g. malicious files, Cross-Site-Scripting (XSS), etc.), up to recent zero-day exploits that target Java plugins1. Contrary to what one would expect, CISCO (2013a) reports that browser malware are not only present in ‘bad’ webpages (e.g. adult websites, ones hosting pirated software, gambling, etc.), but also in benign ones (e.g. social media websites, search engines). The latter may unwittingly serve malware embedded in their active content, typically after a server compromise or with the inclusion of malicious advertisements. Furthermore, progressively more attackers use in their client-side attacks browser exploitation frameworks (e.g. Blackhole exploit kit, Phoenix, etc.), which are available in the underground market. Web browsers (hereinafter referred to as browsers) communicate security events to users through their Graphical User Interfaces (GUIs). For instance, the padlock icon appears every time a user visits a website with a valid digital certificate. Moreover, browsers include window gadgets (widgets), such as checkboxes, buttons, etc., for the configuration of their security controls. Users are expected to configure the browser’s security controls as they see fit (by interacting with its menu), so as to protect their security and privacy. To aid users in this task, every web browser contains a menu option focused on the configuration of security and/or privacy

1 http://www.reuters.com/article/2013/01/11/us-java-security-idUSBRE90A0S320130111

Countermeasures against web threats controls. Even though average users generally tend to ignore security events (Egelman et al., 2008; Motiee et al., 2010; Sunshine et al., 2009), some of them have been trained to interact with the above interfaces in desktop browsers towards a safe web browsing. In this context, this work contributes by providing a systematic and comprehensive analysis of web browser security controls. In particular, this work focuses on popular browsers in smartphones and desktops. Their security controls are enumerated and collected. Furthermore, their default settings as well as their manageability options are compared. Then, a comparative evaluation of the offered protection against web threats is provided. Specifically, our goal is to examine the following research questions regarding the security controls that are provided by web browsers, namely:

• What protection against web threats is offered by the preconfigured security settings in browsers? • What is the manageability options are provided by the security controls that protect from certain web threats?

The former provides indications of the offered protection to average users. The latter reveals the manageability of countermeasures for each threat, i.e. the flexibility to adjust the offered protection according to the users’ “risk appetite” (e.g. a user may be willing to receive targeted advertising). This work summarizes the differences in the availability and manageability of browsers’ security controls. Overall, as expected, desktop browsers provide an increased manageability and availability. Regarding protection against web threats, the analysis revealed that browsers by default focus mostly on a subset of the examined threats (e.g. malware, privacy breach, phishing), while offering poor protection against the rest (e.g. third-party tracking, browser fingerprinting). The key findings can be summarized as:

 Limited security and manageability in smartphone browsers. The analysis revealed that smartphone browsers provide a subset of security controls and limited manageability over them, compared to their desktop counterparts.  Smartphone users are unprotected from rogue websites. The evaluation revealed that smartphone browsers do not protect users from websites that host malware and/or phishing scams. Contrarily, desktop browsers include mechanisms, such as Google’s Safe Brows- ing technology, Smartscreen technology, etc. (Google Developers; Microsoft, Opera), that filter out rogue websites.  Users are exposed to third-party tracking. Users are exposed to third-party tracking/profiling in all examined browsers. This holds true, since by default browsers mechanisms that protect users from this tracking are disabled.

Countermeasures against web threats

The remainder of this sub-chapter is organized as follows. Section Error! Reference source not found. presents related work and Section Error! Reference source not found. a suggested threat model. Section 3.1.1 provides the reader with the methodology of this research. Section 3.1.2 includes the empirical and experimental observations. Section 3.1.3 presents the recommended browser settings and UI modifications.

3.1.1 Methodology

The research scope is to evaluate whether the security controls that are available in a smartphone browsers provide Alice with similar manageability as in their desktop counterparts. In addition, it is examined if smartphone browsers offer a similar level of protection against the aforementioned three attackers. The scope of the evaluation includes the popular web browsers, i.e. Google Chrome, Mozilla Firefox, Internet Explorer, Opera, and Apple Safari (StatCounter), as well as their smartphone counterparts2. More specifically, the latest versions of desktop browsers were installed (as of June 2013, i.e., Chrome (v. 27), Firefox (v. 21), Internet Explorer 10, Opera (v. 12.15), and Safari (v. 5.1.7)) in two desktops. Windows 7 and Windows XP were selected for the installation of the aforementioned browsers due to their popularity in the desktop platform (78% of global market share (StatCounter)). Contrary to desktops, the above browsers are not available in all smartphones. Table 1 summarizes the smartphones that were used in the evaluation, as well as the availability of different third-party browsers in them. The evaluation includes devices with Android, iOS and Windows Phone, which constitute the 96.5% of the smartphone market share (Gupta et al., 2013). Fur- thermore, it includes devices with the following Android versions: Gingerbread (v. 2.3), Ice Cream Sandwich (ICS, v. 4.0.*), and Jelly Bean (JB, v. 4.1.2); which constitute the 91% of the in use Android devices (Google). Therefore, the evaluation can be regarded as representative both in the desktop and smartphones platforms. Finally, for readability and space reasons, Table 1 refers to the stock browsers of Android, iOS and Windows Phone (i.e. Browser, Safari, and IE Mobile respectively) as ‘stock browser’.

2 The scope of the analysis includes only unmodified browsers that are available to the users via the app marketplace. Other hardened browsers or browsers part of a Mobile Device Management solution may exist, but they are out of the scope of this work.

Countermeasures against web threats

Table 1. Browser availability in the smartphones that were used in the evaluation.

Ver- Device Chrome Firefox Opera Opera Stock Platform sion Mobile Mobile Mobile Mini Browser† (v. 26) (v.21) (v. 14) (v. 10) Android 2.3.5 HTC Ex-   plorer 2.3.6 LG-E400   4.0.3 LG - P700     4.0.4 Sony      Xperia 4.1.2 Samsung     Galaxy S3 Samsung     Nexus S iOS 5.1.1 iPhone 4    6.1.2 iPhone 4S    Windows 7.5 HTC Tro-  Phone phy7 † Browser for Android, Safari for iOS and IE Mobile for Windows Phone

Initially, all the available support pages in each browser that are dedicated for security and privacy were enumerated, since Alice is expected to use this material in order to be trained to configure the browser controls. Then, the graphical interfaces in desktop and smartphone browsers were enumerated and all the available configurable security controls, as well as their default values were collected. Any confusing text labels that may exist were marked, as well as any widgets that had obvious usability problems. The controls were grouped together into five categories according to their intended use from the support pages, namely: (a) content controls, (b) privacy controls, (c) browser manageability, (d) third-party software controls, and (e) web browsing controls. The next section presents the results regarding the manageability of web browsers’ security controls.

3.1.2 Availability and manageability of security controls

Overall, thirty-three (33) security controls appear in the browsers’ interfaces, which are listed herein. The majority of the controls’ labels are self-explanatory (e.g. block JavaScript). The rest of them are briefly described here, namely: (a) external plugin check refers to the existence of a web service that analyses the browser’s plugins for vulnerabilities (e.g. Mozilla, Qualys) (b) local blacklist enables users to enforce controls on a per-site basis via local blacklist/whitelist (e.g. per-site cookie blocking), (c) under master password the browser requests the entry of a master password every time it restarts, before accessing any stored passwords, and (d) website checking enables a user to manually initiate analysis (for malware/phishing) on the web site she visits.

Countermeasures against web threats

Tables 2-6 summarize the availability and manageability status of all the security controls that are available via the browsers’ interfaces. Their availability and manageability differs between each browser as well as between the two versions, i.e. desktop and smartphone, of the same browser. The findings are grouped together into five categories, according to the controls intended use from the support pages, namely: (a) content controls, (b) privacy controls, (c) browser manageability, (d) third-party software controls, and (e) web browsing controls. Tables 2-6 use the following notation: (i)  is used when the mechanism is not supported, (ii)  is used when the mechanism is supported but not configurable, (iii) is used when the mechanism is supported but not easily configurable, and (iv) is used when the mechanism is supported and easily configurable. A security control is marked as ‘not easily configurable’ when it can only be configured from a hidden menu (e.g. about:config, see Appendix A), or when there is a usability problem in the configuration of the control (e.g. confusing wording of the widget’s label). In such cases, it is rather unlikely that users will be able to find and/or correctly configure it.

Regarding the default values of security controls,  and  stand for default enabled and default disabled control, respectively. The following notation is also used: {GC=Chrome, MF=Firefox, IE=Internet Explorer, OP=Opera, AS=Safari; AB= Android’s stock browser, CM=Chrome Mobile, FM= Firefox Mobile, IM=IE Mobile, OM =Opera Mobile, Om=Opera Mini, SM=Safari Mobile}. Finally, the stock browser of Android is referred to as ‘ABrowser’.

3.1.2.1 Content controls

Table 2 summarizes the manageability of content controls, i.e. controls that enable Alice to block cookies, images and pop-ups. All browsers enable Alice to block cookies. Safari desktop and mobile were the only browsers that allowed, by default, only first-party cookies (c.f. Table 3). First-party cookies, i.e. those that are not created from a third-party domain, are normally used by web servers for user authentication and their blocking might cause disruptions in web applications’ functionality. By-default, all browsers present website images. Otherwise, a serious usability problem would arise in the webpages that they visit. Users may wish to block images for various reasons, such as to protect their privacy (Zeigler et al.), to speed up their browsing, etc. Contrary to desktop browsers, where Alice can block images in all browsers, this option is not available in most smartphone browsers (c.f. Table 2). This holds true, since only ABrowser and Opera Mini, provide a widget to enable this control and in Firefox Mobile this control is only available in a hidden menu (c.f. Appendix A).

Countermeasures against web threats

Similarly, as summarized in Table 2 all browsers block pop-up windows by default. Firefox Mobile allows the configuration of the pop-up blocking mechanism from a hidden menu interface (see Appendix A for hidden menus). IE Mobile and Opera Mini block pop-ups by default without allowing Alice to disable this control. This fact may break the functionality of web applications that use benign pop-ups (e.g. a pop-up shown to upload a resume).

Table 2. Manageability of content controls.

GC MF IE OP AS AB CM FM IM OM Om SM Controls Block cookies             Block images             Block pop-ups            

3.1.2.2 Privacy controls

Blocking location data – either geolocation data in desktops, or via the smartphone’s location provider – is configurable in most browsers (c.f. Table 3). Only Chrome and Safari block them by default, i.e. they prompt users before accessing location data. Safari Mobile follows a similar approach, but the control of location services is not configurable until such a request is made by Safari Mobile for the first time. In such a case, the user is prompted and access to location data is subsequently manageable from the settings of location data, not from those of Safari Mobile. Thus, this hinders Alice from finding the control, since it resides in a different configuration menu. Alice is also expected to have difficulties in configuring this mechanism in Fire- fox versions (i.e. desktop and mobile), since it is configured only from a hidden menu. Finally, the evaluation revealed that the availability of this control is different in iOS and Android, being unavailable in the former and available but default disabled in the latter. By default, browsers send the referrer value in HTTP headers (it is misspelled as ‘referer’ in the header), a value that can be collected from Gorwel for user tracking (Fielding et al., 1999). The analysis revealed that the security control that removes the referrer is unavailable in most smartphone browsers and in the desktop version of Internet Explorer and Safari (c.f. Table 3). Both versions of Firefox allow Alice to manage this control only via a hidden menu. Finally, enabling this control in Chrome is rather difficult, since it involves starting its executable with a parameter via the terminal (see Appendix A). Regarding third-party cookies, the majority of desktop browsers permit them (except for Sa- fari). In smartphones the majority of browsers accept all cookies in an all-or-nothing approach, thus failing to protect Alice’s privacy. This holds true, since they either block both first-party and third-party cookies, or allow them (c.f. Table 3). Only Firefox Mobile and Safari Mobile provide manageability over third-party cookies, while having the same default values as their desktop counterparts. One could argue that enabling tracking by default is acceptable, since in

Countermeasures against web threats the majority of the examined browsers the user is allowed to block it. Nevertheless, it is unclear whether Alice can understand the impact of tracking (Madrigal), which, in its ultimate form (e.g. via user identification (Eckersley, 2010)) may constitute an intrusion of her fundamental right to privacy. Furthermore, during browser installation Alice is not explicitly asked whether she wishes to receive personalized advertisements. As summarized in Table 3, by default, only Internet Explorer sends the do-not-track (DNT) preference, i.e. the value “DNT: 1” in the HTTP header (Zeigler et al.). In smartphones only a subset of browsers contains settings for DNT, namely: Chrome Mobile, Firefox Mobile and Safari Mobile. Moreover, DNT in Safari is available only in iOS 6 and the wording near the widget is confusing, i.e. “Limit ad tracking”. Therefore, it is likely that Alice will accidentally enable web tracking by selecting the option “off”, believing that she is disabling ad tracking in this way. Most browsers provide a History Manager. ABrowser, Opera mini and Safari Mobile allow a user to delete history data, but the relevant widgets are scattered in the browsers’ interfaces. Safari for desktop provides the widget under a widget with title “Reset Safari…”, thus making it rather difficult for a normal user to find it. Moreover, Alice may initiate private browsing – i.e. a session where browsing data (cookies, browsing data, downloads) are not stored locally – in all desktop browsers. Contrary to desktops, smartphone browsers support private browsing only in ABrowser, Firefox Mobile, Safari Mobile and Chrome for Android. ABrowser does not offer private browsing in Android Gingerbread at all, while the newest Android versions do offer this mechanism only from a hidden menu (see Appendix A). Finally, this control is offered by Chrome Mobile for iOS, but its effectiveness is hampered by the platform’s limitations3.

Table 3. Manageability of privacy controls

GC MF IE OP AS AB CM FM IM OM Om SM Controls

Block location † data       |      Block referrer             Block third- party cookies             Enable DNT            |† History Man- ager            

Private brows- † ing      |       † heterogeneity in different platforms.

3 http://support.google.com/chrome/bin/answer.py?hl=en&answer=95464

Countermeasures against web threats

3.1.2.3 Browser manageability

Browser updates protect Alice from security vulnerabilities and bugs. All desktop browsers support automatic installation of browser updates, except for Safari. Safari for Windows - as well as Mac OS Leopard - does not offer update support for the browser anymore, thus exposing its users to more than 100 vulnerabilities that were patched in Safari 6 (Apple). Alice is not aware that Apple does not provide updates for her browser, since she is not explicitly informed in the browser’s download page or during/after its installation. Thus, she can only be informed that she is vulnerable by a third source (e.g. forum, blog, etc.), which may eventually make her decide to switch to an alternative desktop browser in order to stay secure. Browser updates in most smartphones are, contrary to desktop browsers, semi-automatic (c.f. Table 4). Stock browsers (e.g. ABrowser, Safari Mobile) update with platform updates and third-party browsers update via the application marketplace (e.g. Google Play, App Store, etc). In both cases, the update requires the user’s initiation. Only Firefox Mobile can be configured via a menu option to be updated automatically4. Finally, it is worth noting that browser updates in smartphones often suffer from delays. The updates of third-party browsers may be delayed by the app analysis process of the app marketplace. Also, updates of Android may be either delayed or even be unavailable by the device vendor. Therefore, in some cases users of ABrowser may not get updates even if they are officially available from Google. Among desktop browsers, only Safari did not offer a configurable certificate manager,5 i.e. an interface where Alice can either inspect or edit the certificates that are trusted or blocked by the browser. The ability to manage trusted certificates is important, especially in the case that a Certification Authority (CA) becomes compromised (e.g. in Network Computing). In this case, Alice must be able to disable this CA. In smartphones, the evaluation showed that most browsers (i.e., Safari Mobile, Chrome for iOS, ABrowser for Android Gingerbread, Firefox Mobile, IE Mobile, and Opera Mini) do not offer a configurable certificate manager. ABrowser, Opera Mobile and Chrome for Android use the certificate manager that is provided in the newest Android versions (i.e. the ones after Gingerbread version). All browsers offer auto-fill functionality, i.e. the browser can remember passwords of certain websites. As shown in Table 4, only a subset of the desktop browsers offers password protection via a master password – i.e. the browser asks users to enter a master password every time it restarts, before accessing stored passwords. Furthermore, Chrome and Firefox were found to enable the unmasking of stored passwords. Therefore, it is very easy for an attacker who has temporary access to Alice’s browser to access her passwords. Among smartphone browsers, only Firefox Mobile offers password protection with a master password. Even though

4 However, in Android the rest of them can be configured to be automatically updated in the Google Play app 5 Safari uses Internet Explorer’s certificate manager without providing a link to its interface.

Countermeasures against web threats smartphone browsers and most of the desktop browsers do not unmask passwords, an attacker with physical access to the browser can login to websites where Alice has enabled password auto-fill. The risk of this attack is greater in smartphones, due to their small size and mobility and the fact that in the user study (see §4) only 64.4% of the respondents password-protected their device. All desktop browsers provide an interface to configure a proxy server6, which can provide Alice with anonymity (e.g. via a free proxy or onion network) and enhanced security, if the proxy implements a malware and/or phishing detection engine. Most smartphones can be configured to use a proxy server via the device’s Wi-Fi settings, but it is rather difficult for Alice to find the configuration widget. This holds true, since the navigation to this configuration widget clearly violates the three-click rule (c.f. Appendix A). Furthermore, the evaluation showed that Alice cannot enable a proxy server in any smartphone, when the device uses cel- lular connectivity (e.g. UMTS (3G), HSDPA, etc.). Thus, the aforementioned protection options that are offered by a proxy server are unavailable when Alice uses mobile Internet. Alice may wish to configure her browser to use a search engine that does not track her (e.g. DuckDuckGo, Startpage).7 As summarized in Table 4, this option is only available in four desktop browsers. The rest browsers either allow the selection of a search engine provider from a static list (e.g. Google, Bing, Yahoo), or do not offer such a selection, at all. Among the examined browsers, only Internet Explorer and Opera enable Alice to inspect and select which protocol version of SLL and TLS is used in her secure connections. Various vulnerabilities have been discovered in SSL/TLS (e.g. BEAST, CRIME, Lucky 13) and re- cently new vulnerabilities have been discovered in TLS as well as in the SSL implementation that uses the RC4 algorithm (AlFardan and Paterson, 2013; Panday, 2011; Paterson et al., 2011; Paterson). Currently, the above protocol vulnerabilities in browsers and servers are fixed via workarounds that patch certain instances of the vulnerabilities. Furthermore, the adoption of the latest TLS protocol (i.e. TLS 1.2) may either hinder user experience, if the server does not support it, or it may be skipped during the protocol negotiation between the server and browser. For instance, during a MiM attack an attacker may convince the two communicating parties to switch to a vulnerable version of the protocol. Finally, the current interfaces in Internet Explorer and Opera browser allow Alice to disable or select an older version of SSL\TLS protocol, as any other non-security related setting in the browser's menu (e.g. enabling the automatic resizing of images). The results revealed that only Chrome offers a task manager. Even though the absence of this control does not imply that Alice is directly exposed to any threats, its presence can aid her

6 Chrome and Safari use a link to the interface implemented by Internet Explorer. 7 https://duckduckgo.com/, https://startpage.com/

Countermeasures against web threats to enhance control over web browsing by inspecting resource consumption (e.g. network, memory). Table 4. Mechanisms for browser management.

Controls GC MF IE OP AS AB CM FM IM OM Om SM Browser update             Certificate manager      /2 /2      Master Password             Proxy server      1 1 1 1  1 1

Search engine 1 1 1 1 1 manager             SSL/TLS version selection             Task manager             1 the control has a limitation, 2 heterogeneity in different platforms

3.1.2.4 Third-party software control

Desktop browsers and Firefox Mobile auto-update extensions, as soon as they become available in their application marketplace (e.g. Chrome Web Store). In some circumstances Alice may prefer to disable automatic updates (e.g. when she is roaming). Among the examined browsers that support extensions (c.f. Table 5), only Firefox and Safari provide Alice with this control over updates. Moreover, only Internet Explorer, Opera and Firefox Mobile do not enable Alice to manually update extensions. The rest of the browsers that support extensions provide such an interface to initiate an update, which will aid Alice to be timely protected from security vulnerabilities and bugs in extensions. Contrary to extension updates, browsers do not update plugins automatically. Thus, browsers must provide an interface to inform Alice which plugins must be manually updated. During the evaluation only Firefox and Chrome alerted users about vulnerable plugins. Firefox provides crystal clear indications when a plugin is vulnerable by highlighting it and providing an update link. Chrome alters the plugin’s version color to red and provides an update link. However, Alice may ignore this warning since it is not easily spotted among the various plugin details.

Countermeasures against web threats

Table 5. Mechanisms for third-party software control.

Controls GC MF IE OP AS AB CM FM IM OM Om SM Auto update extensions      N/A N/A  N/A N/A N/A N/A Auto update plugins             Disable extension      N/A N/A  N/A N/A N/A N/A Disable Java      N/A N/A N/A N/A N/A N/A N/A

Disable 1 JavaScript       |      

Disable 1,2 2 plugin      |       External plugin check             Manually update      N/A N/A  N/A N/A N/A N/A extensions Manually update             plugins 1 heterogeneity in different platforms, 2 the control has a limitation

All desktop browsers, except for Safari8, allow Alice to disable plugins as she feels fit. As summarized in Table 5, this option is not available in the majority of smartphone browsers. Smartphone browsers cannot be configured to individually block plugins (e.g. flash player video) from their settings. ABrower (version ICS and JB only, plugins in previous versions are enabled by default) and Firefox Mobile allow only limited plugin management. More specifically, the two browsers provide an ‘all-or-nothing’ control over the plugins and therefore Alice cannot disable individual plugins. By default, Alice will be explicitly asked to enable a plugin via a mechanism referred to as ‘tap to play’. Furthermore, smartphones often invoke other applications to present content to the user (e.g. video players). Again, Alice cannot neither inspect which applications are invoked for specific content, nor disable them. Browser’s extensions (or “add-ons”) can be enumerated and disabled in all desktop browsers. In smartphone browsers, only Firefox Mobile supports browser extensions and provides Alice the ability to inspect and individually disable extensions. In desktop browsers, Java can be disabled in the plugin configuration interface - except from Safari, where Java can be disabled in the security menu tab. Java was enabled by default in all desktop browsers, even when the browser was installed in a desktop which included a vulnerable Java version. Finally, smartphone browsers do not support Java applets and returned an alternative text, namely “Your browser is completely ignoring the tag!” during the evaluation.
8 Plugins in Safari can only be enumerated. They can be manually removed from the plugins installation folder
48
Countermeasures against web threats
As summarized in Table 5, JavaScript is enabled by default in all browsers. While all desktop browsers allow Alice to disable JavaScript in case she feels that this will protect her from malicious content from a webpage, this option is not available in all smartphone browsers. More specifically, only Safari Mobile, ABrowser, and Chrome for Android enable Alice with such a configuration. Chrome for iOS, Opera Mobile, Opera Mini, and IE Mobile do not offer the manageability of JavaScript, whereas Firefox Mobile offers it only from a hidden menu. There- fore, in most smartphone browsers Alice is exposed to any malicious JavaScript code. Alice may initiate a web based plugin check only from Firefox’s interface (referred as ‘external plugin check’). The analysis revealed that the use of this control may mislead Alice. This holds true, because when Alice enumerates her plugins she may accidentally interact with a widget in the upper right corner of the interface and not with the correct control that appears as a link. This widget checks for extension updates and not for plugin updates. The widget has a label “Check for Updates” and, as a result, Alice cannot distinguish its proper use. Moreover, if Alice had checked for extension updates before navigating to the plugins tab and no extension update was found, then the widget’s label will remain “No updates found”, potentially mislead- ing Alice that there are no updates for the extensions, as well. Finally, the experimental analysis provides proof that this control is not always effective.
Table 6. Web browsing controls.
GC MF IE OP AS AB CM FM IM OM Om SM Controls Certificate Warning             Local blacklist             Malware protection             Modify user-agent             Phishing protection             Report rogue             Website Website checking            
3.1.2.5 Web browsing controls
All desktop browsers provide a mechanism to protect Alice from Mallory. This mechanism includes a system's wide blacklist and/or page analysis (Google Developers; Microsoft, Opera). Chrome and Firefox use Google’s Safe Browsing technology, Internet Explorer uses Smart- screen technology, and Opera and Safari do not document which engine they use. Such a mechanism is enabled by default in all desktop browsers. However, all of them enable Alice to disable malware protection without displaying any confirmation security warning. Contrarily, in
49
Countermeasures against web threats smartphones, only Opera Mobile and Firefox Mobile inform Alice that this technology is supported in their support pages. Chrome Mobile’s support page informs her that Safe Browsing is not available, whereas the rest smartphone browsers neither provide any information to Alice about this control, nor provide any option in their menus. Furthermore, the above mechanisms of desktop browsers also protect Alice from fraudulent websites (i.e. phishing attacks). Besides the aforementioned smartphone browsers that document protection from fraud, Safari Mobile also documents such a protection. In addition, Safari Mobile provides an interface allowing Alice to configure this control. Once more, this control can be easily disabled, without displaying any warning that this action would lower Alice’s security protection. Apart from the above two controls, which aim to block access to Mallory’s websites, only Internet Explorer and Opera allow Alice to manually initiate analysis on the site she is curently visiting (referred as ‘website checking’). Furthermore, only9 Mozilla Firefox, Internet Explorer, and Opera allow Alice to manually report a rogue site. Among the examined browsers, only Chrome, Firefox, Opera, and Internet Explorer provide local blacklists and whitelists of websites. Alice can edit these lists, as she sees fit, by adding or removing websites and setting restrictions or allowing access in the lists (e.g. blocking cookies, enable pop-ups, share location, etc.). Among the browsers that offer this mechanism, Inter- net Explorer provides a fine grained mapping of the rest browser mechanisms to the lists (referred as trusted/restricted zones). On the contrary, Chrome, Firefox, and Opera provide only a coarse grained mapping of the available mechanisms. This mapping is available through the page information interface (or the ‘site’s preferences’) for a given domain or from a widget (e.g. button) near the configurable mechanism in the browser’s menu10. Alice may wish to use a modified user-agent (UA) string in her HTTP request (i.e. a string which provides the browser’s software details). For instance, Alice may prefer to navigate to the desktop version of a site with her smartphone, or to access a service that is available to a browser other than the one she is using (UA modification). Alice may change her UA in all examined browsers, except for Opera Mini and Safari Mobile, whereas in Firefox and Safari this configuration takes place only via a hidden menu. It is worth noting that UA modification may occur for privacy reasons (c.f. Eckersley, 2010). Finally, the evaluation revealed that Opera Mini is the only browser that does not display a security warning for rogue digital certificates, i.e. either an invalid certificate (e.g., certificate with domain mismatch, expired), or an untrusted one, i.e. one that is not signed by a trusted CA
9 The control must be initiated via the browser’s interface. Other browsers may indirectly use other services such as https://support.google.com/websearch/contact/reporting_malware?rd=1 10 Firefox also enables this mapping from a Permissions Manager that resides in a hidden menu
50
Countermeasures against web threats
(Amrutkar et al., 2012; Iliadis et al., 2000; Gritzalis 2001; Lekkas 2004). Thus, Alice is unprotected from Mallory’s rogue web servers. Security warnings for rogue digital certificates may also unmask a MiM attack. The aforementioned are summarized in Table 6.
Figure 1: Availability of security controls in web browsers.11
3.1.2.6 Overall availability of controls
Figure 1 outlines the percentage of security controls provided by each browser. The descrip- tive statistics omit controls, where applicable, for instance "Disable Extensions" in Chrome Mobile. As the figure illustrates, smartphone browsers form three groups, regarding the availability of controls. The first group includes Firefox Mobile that offers the majority of security controls in smartphones (67.14%). The second includes browsers with control availability around 50%, i.e. ABrowser, Chrome Mobile and Safari Mobile. The browsers in the last group, i.e. Internet Explorer Mobile, Opera Mobile, and Opera Mini, provide around 30% control availability. Similarly, desktop browsers form three groups. Firefox and Opera form the group of browsers that offers the majority of security controls (87.5%, 84.38% respectively). Google Chrome and Internet Explorer provide control availability around 80%. Finally, Apple Safari browser provides only 62.5% of the security controls. As expected, smartphone browsers implement a subset of security controls that are available in their desktop counterparts (c.f. Tables 6-10). One could argue that the unavailability of controls is due to the restrictions that are imposed by the smartphone sandbox profiles to all applications (Mylonas, 2011a). To test the validity of this argument the security controls that are implemented by at least one smartphone browser, while being not implemented by other smartphone browsers in the same smartphone OS, were filtered. Such controls exist both in iOS
11 The figure holds the percentage for AB (later than Gingerbread), CM (Android) and SM (iOS 6). The percentage for AB (Gingerbread), CM (iOS) and SM (iOS 5) is 46.43%, 42.86%, 46.43% respectively.
51
Countermeasures against web threats and Android. More specifically, the controls in {Block images, Block location data, Block third-party cookies, Certificate manager, Certificate Warning, Disable JavaScript, Private browsing} are counterexamples of this argument both in Android and iOS, as well as {Block referrer, Master Password, Search engine manager} in Android (c.f. Table 7). Thus, any browser that does not support any of these controls (where applicable) is not restricted by the OS’s sandbox.
Table 7: Counterexamples about sandbox restrictions
GC MF IE OP AS AB CM FM IM OM Om SM Controls Block im-             ages Block location       |      data Block re-             ferrer Block third- party             cookies
Certificate 2 2 manager      / /      Certificate Warning             Disable JavaScript       |     
Disable 1,2 1 plugin      |       Enable            |2 DNT Malware protection             Master Password             Modify user-agent             Phishing protection            
Private 2 browsing      |       Search engine     1 1 1    1 1 manager 1 the control has a limitation, 2 heterogeneity in different platforms
When a browser implements the majority of security controls, it does not de facto mean that this is the most secure browser. This holds true, as browsers are preconfigured to disable security controls for the sake of functionality. The analysis continues with the default protection from web threats.
3.1.2.7 Protection from web threats
52
Countermeasures against web threats
This section presents a comparative evaluation of the offered protection against web threats. Specifically, the goal is to examine: (a) the protection of preconfigured security settings against web threats, and (b) the manageability of security controls that protect from certain web threats. The former provides indications of the offered protection to average users. The latter reveals the manageability of countermeasures for each threat, i.e. the flexibility to adjust the offered protection according to the users’ “risk appetite” (e.g. a user may be willing to receive targeted advertising). In doing so, a taxonomy of the security controls and web threats was created. The threats, which combine ICT threats (Marinos and Sfakianakis, 2012) and smartphone threats (Theoharidou et al., 2012), are listed in Table 8 along with their mapping to security controls (for a short description of the controls see Appendix B). The mapping was created in line with the controls’ descriptions in the browser help pages, as well as the recommendations from (Veracode; CERT; CERT-US). Then, two heat maps were introduced summarizing the num ber of security controls that are enabled by-default in each browser, and the manageability of security controls that browsers provide, according to Tables 6-10.
Table 8. Taxonomy of browser controls and web threats.
Security Controls Threat (Ti) Block images, Block pop-ups, Certificate Warning , Disable extension, Annoyance (T1) Disable java, Disable JavaScript, Disable plugin, Local blacklist, Modify user agent Browser fingerprinting (T2) Disable JavaScript, Local blacklist, Modify user agent, Proxy server Auto update extensions, Auto update plugins, Block pop-ups, Browser update, Disable extension, Disable java, Disable JavaScript, Disable Exploits/Malware (T3) plugin, External plugin check, Local blacklist, Malware protection, Man- ually update extension, Manually update plugin, Modify user agent, Proxy server, Report rogue website, Website checking Disable JavaScript, History manager, Local blacklist, Master password, Identity theft (T4) Phishing protection, Private browsing, Report rogue website, Website checking Certificate manager, Certificate Warning, Local blacklist, SSL/TLS ver- Data interception (T5) sion selection Block pop-ups, Certificate manager, Certificate Warning , Disable Ja- Phishing (T6) vaScript, Local blacklist, Phishing protection, Proxy server, Report rogue website, Website checking Block cookies, Block images, Block location data, Block referrer, Block third-party cookies, Certificate Warning, Disable extension, Disable java, Disable JavaScript, Disable plugin, Enable do-not-track, History Privacy breach (T7) manager, Local blacklist, Malware protection, Master password, Modify user agent, Phishing protection, Private browsing, Proxy server, Report rogue website, Search engine manager, Website checking Disable extension, Disable java, Disable JavaScript, Disable plugin, Ex- Resource abuse (T8) ternal plugin check, Local blacklist, Malware protection, Report rogue website, Task manager, Website checking Rogue certificates (T9) Certificate manager, Certificate Warning , Local blacklist
53
Countermeasures against web threats
Block images, Block pop-ups, Local blacklist, Proxy server, Search en- Spam advertisements (T10) gine manager Auto update extensions, Auto update plugins, Browser update, Disable extension, Disable java, Disable JavaScript, Disable plugin, External Technical failure (T11) plugin check, Malware protection, Manually update extension, Manually update plugin, Task manager
Figure 2 presents the heat map of the security controls that are enabled by-default in each browser. The analysis revealed that desktop browsers (except for Safari) and Firefox Mobile have the majority of pre-enabled controls (c.f. Figure 1). Opera Mini provides no protection for the majority of the threats. Overall, the majority of pre-enabled security controls protect users from phishing, privacy and malware/exploits. Specifically: (a) desktop browsers (except from Safari) and Firefox Mobile enable by default the most controls against malware/exploits, (b) Chrome, Internet Explorer, Safari, Firefox Mobile, and Safari Mobile provide similar privacy protection, while ABrowser, Internet Explorer Mobile, and Chrome Mobile weak privacy protection, and (c) preconfigured settings in all browsers offer a comparable protection level against phishing (except for ABrowser, Chrome Mobile, IE Mobile, and Opera Mini). Regarding the threat of technical failure (browser crashing), desktop browsers (except for Safari) and Firefox Mobile pre-enable the most relevant controls. The results indicate that all browsers provide similar protection from annoyance, interception of network data, rogue certificates, and spam/advertisements. The preconfigured browser settings provide similar protection against identity theft - except for ABrowser, Chrome Mobile, IE Mobile, and Opera Mini, which do not enable any relevant security control. Similarly, they provide comparable protection against resource abuse (except for Chrome Mobile, IE Mobile, and Opera Mini). Finally, the results suggest that none of the browsers is preconfigured to avoid browser fingerprinting. Similarly, Figure 26 summarizes the number of security controls that protect users from each web threat and are manageable. As expected, desktop browsers provide greater manageability of security controls than their smartphone counterparts. Overall, Opera and ABrowser provide the greatest manageability among desktop browsers and smartphone browsers, respectively. Chrome, Firefox and Internet Explorer offer comparable manageability and this also holds true among Chrome Mobile and Firefox Mobile and Opera Mobile and Safari Mobile. In addition, Safari provides the least manageability of security controls in desktop browsers. Similarly in smartphones, this holds true for IE Mobile and Opera Mini. In both platforms, privacy controls are the most manageable, whereas data interception and rogue certificates are the least manageable ones. In desktops the threat of malware/exploits follow privacy controls w.r.t. control manageability, which in turn is followed by annoyance, identity theft, phishing, and resource abuse. Likewise, in smartphones the controls for annoyance and malware/exploits follow privacy controls w.r.t. control manageability.
54
Countermeasures against web threats
Figure 2: Preconfigured enabled security controls.12
On the other hand, browser fingerprinting, data interception, rogue certificates and technical failure are the threats in desktops having the less manageable controls. In smartphones the least configurable ones are: data interception, recourse abuse, rogue certificates, and spam/advertisements. Finally, browser crashing, browser fingerprinting, identity theft and phishing are threats that smartphone browsers do not offer manageable controls.
3.1.3 Recommendations
This section includes suggestions for services and mechanisms that can offer Alice a better level of security and protect her from threats and vulnerabilities that were presented beforehand.
Security-oriented settings. Table 9, (columns 3 and 4) presents the preconfigured security settings in the examined desktop browsers (Table 9 uses the notation for controls that is described in Tables 6-10). These settings were collected by noting the default value and/or configurability option that appeared more often in them. Only the settings of desktops were examined, since (a) they offer a superset of security controls comparing to smartphone browsers (c.f. Figure 1) and (b) their longer presence in the field has made them more mature than their smartphone counterparts. As depicted in Table 9, this default configuration is functionality- oriented, i.e. provides reduced security for the sake of functionality (e.g. support of active content).
12 For space and readability reasons the heatmaps include only CM for Android and SM for iOS 6
55
Countermeasures against web threats
Figure 3: Manageability of security controls.13
Average users are less likely to change the default values of security controls. For this reason, this work proposes a (default) configuration, which is security-oriented, i.e. aims to maximize the protection of the user’s security and privacy (cf. Table 9 columns 2 and 4). This set extends the configuration that is proposed in (Veracode; CERT; CERT-US). In this work it is considered that all security controls should be, where applicable, implemented and enabled by default to maximize the offered protection. It is also considered that a user should be able to configure them as she feels fit to adjust the level of her protection, except for (Certificate warning, Mal- ware protection, Master password). Users should be discouraged from disabling malware and phishing protection (Malware protection, Master password) and warnings for invalid certificates (Certificate warning), or should be able to do so from an interface where only advanced users can reach, such as a hidden menu (e.g. about:config). Also, this work proposes that the controls Auto update extensions, Auto update plugins, and Browser update, should reside also in an advanced interface, e.g. one that asks for user confirmation before changes are applied. This will protect average users from accidentally disabling the controls. This work also proposes that the browser before/upon its installation should provide an interface which guides the user to configure the settings of Block cookies, Block location data, Block third-party cookies, Enable do-not-track, and Master password. This interface should be reasonably comprehensive by a normal user, e.g. “Would you like to receive targeted advertising” instead of “Enable third-party cookies” (the proposition of such an interface falls outside of the dissertation’s scope). Finally, one should note that the configuration of the above controls by the user avoids any conflict with other stakeholders on the web (e.g. ad companies (Wired)).
13 For space and readability reasons the heatmaps include only CM for Android and SM for iOS 6
56
Countermeasures against web threats
Table 9 summarizes the differences between the security-oriented settings and the preconfigured settings of desktop browsers. Almost half of controls (14/32) have the same status (i.e. configurability, default enabled/disabled). A 22% (7/32) was proposed to be added in browsers as configurable and/or enabled by default and 25% (8/32) of existing controls to be enabled by default. Comparing to vendor settings, 9% (i.e. Auto update extensions, Malware protection, Phishing protection) are proposed to change configurability status. Our security configuration is rather restrictive, i.e. functionality is disabled for the sake of security (e.g. cookies, location data, etc.). To ensure user experience, the browser should allow the user to enable such controls via local whitelists, similarly to the NoScript extension.
GUI issues. The browser’s GUI allows users to disable security controls, which downgrades the offered protection level, as easy as modifying any other browser setting that is not security oriented (e.g. automatic resizing of images). Moreover, security controls often reside together with not security related options, such as zoom, character encoding, etc. In this case, this work proposes that all security oriented controls should be organized under the same interface. For instance, a tabbed menu interface may be used to organize security controls, as in Mozilla Fire- fox. Also, the security controls that can directly impair the security of Alice if they are disabled (e.g. disabling blacklists with malicious websites/phishing websites, disable SSL\TLS) must: (a) reside in an ‘advanced’ section of the configuration interface for security controls, and (b) need a confirmation prompt (e.g. in the same manner the browser prompts the user before de- leting all history entries) and/or master password before being disabled. Finally, the widgets that configure security controls must be easy for Alice to understand, avoiding confusing wording, such as in the DNT control in Safari Mobile.
Control manageability (local blacklist/whitelists). Smartphone browsers must enable Al- ice to map security controls to specific web domains, as in desktop browsers that use blacklists /whitelists. Otherwise, Alice has to either accept all websites or block all websites in a subset of controls (e.g. cookies, JavaScript, plugins, pop-ups, etc.).
Protection from third-party advertising. The browser must enable Alice to make an informed decision about third-party advertising. This work proposes that the browser should ask Alice during its installation or post installation (i.e. first time the browser executes), if she wishes to receive third-party advertising. On the background, the browser must configure the appropriate privacy controls (e.g. third-party cookies, DNT, etc.). At this point, it is rather important that the interface reasonably aids Alice to make an informed decision (e.g. with easily comprehensible text), giving her a clear understanding about the impact of third-party tracking (Madrigal). Furthermore, the interface of smartphone browsers must allow Alice to selectively
57
Countermeasures against web threats delete cookies, as well as hinder some websites to install cookies in her device via a local blacklist/whitelist.
Table 9. Comparison of security-oriented settings vs. preconfigured desktop security settings. The suggestions1,2 do not apply to vendor settings (c.f. Tables 6-10)
Suggested settings Vendor settings Common settings Sta- tus  Auto update extensions1, Auto Malware protection, Block pop-ups, Browser update plugins1, Block location Phishing protection update1 data2, Block referrer, Block third-party cookies2, Disable extension, Disable java, Disable Ja- vaScript, Disable plugin, Enable do-not-track2, Master password2  Block location data, Website checking, Block Block referrer, Block images third-party cookies, Dis- able extension, Disable java, Disable JavaS- cript, Disable plugin, Enable do-not-track  Malware protection1, Phishing Auto update extensions Certificate Warning 1 protection1  External plugin check, Manually Certificate manager1, His- update plugin, SSL/TLS version tory manager, Local black- selection1, Task manager, Web- list, Manually update ex- site checking tension, Modify user agent, Private browsing, Proxy server, Report rogue website, Search engine manager  Auto update plugins, External plugin check, Manually update plugin, Master password, SSL/TLS version selection, Task manager, Website checking 1 configuration from an advanced interface, 2 user preference before/upon installation.
Rogue sites. Smartphones include sandboxes that place restrictions in functionality of third- party (security) apps (see §2). As a result, while desktops’ antivirus or other security software may be able to filter rogue webpages (i.e. those hosting malware and/or phishing scams), this is currently not feasible in smartphones. In this context, it appears that the browser itself must detect and/or block rogue sites. This can be achieved either with a frequent acquisition of a blacklist, or with ad-hoc queries in an online blacklist (e.g. by using a service similar to the one offered by Safe Browsing). Alternatively, the smartphone may connect to a secure proxy, i.e.
58
Countermeasures against web threats one that filters rogue sites. Current smartphone browsers do not permit the connection to a proxy, when mobile Internet is used (e.g. 3G, HSDPA, etc).
Third-party software management. Smartphone browsers must provide an interface where Alice can inspect the plugins and other applications that are being used by them. The browsers must also allow her to selectively disable this software, as she sees fit. Furthermore, both desktop and smartphone browsers must be able to inform Alice regarding third-party software vulnerabilities (at least the well-known one).
User awareness. As discussed earlier, browsers offer support pages dedicated to security and privacy. The support pages must be amended to provide enough background as well as links to material (such as National Cyber Security Alliance), focusing on the current threats on the web and the available countermeasures. This will enable Alice to understand the relevant threats and effectively adjust the browser’s protection level, according to her security and privacy needs.
59
Countermeasures against web threats
3.2 Browser add-ons Web browsing activities (e.g. e-commerce, online banking, social media, etc.) are accom- panied by web threats that pose a direct risk towards the user, such as phishing attacks, malicious software, tracking sensitive information etc. (Securelist, 2015). When a user selects one of the popular web browsers (i.e. Apple Safari, Google Chrome, Internet Explorer, Mozilla Firefox or Opera) it is important to make that choice based on the features each browser provides (e.g. appearance, speed, usability, etc.). Among them there should be the available security controls provided by all modern browsers (e.g. malware/phishing protection, do-not- track service, etc.). Pre-installed security controls aim to protect the user from web threats. Moreover, browsers offer additional software, namely add-ons, which extend the functionality of browsers. Add- ons are focused on catergories, such as accessibility, news & weather, photos, productivity, social, etc. One of them (that exists in some of the browsers) is security and/or privacy, which includes add-ons that aim to offer additional security/privacy mechanisms to the user. However, add-ons are based on a community of developers and do not have the same popularitty in the different browser ecosystems. As a result, some add-ons that are valuable at protecting users’ security and privacy (e.g. NoScript) are not available in in some of the browsers (e.g. Internet Explorer). In this context, our work provides:  a comprehensive analysis of the availability of security and/or privacy controls, which are pre-installed in modern browsers and  a comprejensive survey of the available security and/or privacy add-ons of each browser and examine whether they cover the identified gaps of the browsers’ controls, when one or more security controls are not offered. Our work reveals that browsers differentiate a lot concerning both the availability of the provided security controls and the corresponding add-ons. The rest of this subchapter is structured as follows. Section Error! Reference source not found. presents our results. Section 3.2.1 includes our research methodology. Section 3.2.2 depicts the results of our findings.
3.2.1 Methodology
3.2.1.1 Security and privacy controls
The scope of our analysis includes the popular browsers for Windows desktops, i.e. Chrome (v. 41), Firefox (v. 36), Internet Explorer 11, Opera (v. 27), and Safari (v. 5.1.7). Table 10 includes the popularity of each browser, until March 2015 (W3Schools, 2015):
60
Countermeasures against web threats
Table 10. Browsers user base Browser User base (%) Chrome 63.7% Firefox 22.1% Internet Explorer 7.7% Safari 3.9% Opera 1.5%
The browsers were installed in a workstation running Windows 7, which is the most commonly used operating system (52.3%) (W3Schools, 2015). Then, we enumerated the browsers graphical interfaces and any available hidden menus (e.g. “about:config” in Firefox) in order to collect which security controls are offered in each browser.
3.2.1.2 Security and privacy add-ons
We visited each browser’s add-on repository, so as to identify the available security and privacy add-ons. To this end, we visited the add-on repository of Safari (Safari, 2015), Chrome (Chrome, 2015), Internet Explorer (Internet explorer, 2015), Firefox (Firefox, 2015) and Opera (Opera, 2015) and enumerated their add-ons. Then, we grouped the add-ons’ categories and mapped each add-on to one category, based on the add-ons functionality (i.e. services and features offered). Some add-ons have been grouped in more than one categories, as they provide multiple functionality. For the mapping of the add-ons functionality we used the following taxonomy14:
1. Content filtering: Block content (advertisements, cookies, images, pop-ups, etc.) 2. Parental control: Includes traffic filters to block websites containing inappropriate mate- rial15 3. Passwords: a. Generators: Generation of strong passwords b. Managers: Creation of a master password and password management 4. Plain proxy: Simple proxy without any encryption included 5. Privacy: Privacy protection add-ons (e.g. privacy settings manager) 6. Protection from rogue websites: a. Antivirus blacklists: Websites providing online antivirus scans of files for malicious software (e.g. Virus Total (VirusTotal, 2015)) b. Malware blacklists: Websites providing blacklists blocking malicious content (e.g. MalwareDomains (MalwareDomains, 2015))
14 Categories marked with 1, 2, 3… are the 1st level categories, while those marked with a, b, c… are the 2nd level categories (i.e. sub-categories). 15 Apart from the parental control functionality, since such sites often include malware, this control can protect users’ security and privacy
61
Countermeasures against web threats
c. Phishing blacklists: Websites providing blacklists blocking phishing attacks (e.g. PhishTank (Phishtank, 2015)) d. Reputation blacklists: Websites providing blacklists blocking pages based on their reputation (e.g. Web Of Trust (WebOfTrust, 2015)) e. Sandbox: Analysis of downloaded files for malicious software (e.g. Dr. Web Link- Checker (LinkChecker, 2015)) 7. Third-party software management: Blocking third-party software (e.g. Flash, Java, Ja- vaScript, etc.) 8. Tracking: Blocking website(s) that track user’s online behavior a. Social Media (SM) redirection: Blocking the visited website from redirecting the user to a social media website 9. Traffic encryption via proxy: Proxy that encrypts user’s traffic
3.2.2 Results
3.2.2.1 Revisiting pre-installed security controls
In our previous work (Mylonas, et al., 2014), we examined the availability and manageability of security controls offered by popular smartphone and desktop browsers. The availability of those controls is re-examined to highlight any changes that may exist in the latest browsers’ versions. The results of our work are summarized in Table 11, using the following notation: (i)  is used when the security control is not offered whereas (ii)  is used when the browser offered the security control. Also, the following acronyms are used for the browsers: AS = Apple Safari, GC = Google Chrome, IE = Internet Explorer, MF = Mozilla Firefox and OP = Opera. Opera modified three of its controls in its latest version: the “master password” and the “SSL/TLS version selection” controls, both of which were available in the past and are now removed. While, the same browser altered one of the available controls of this category, i.e. the “manually update extensions” control, which was not available in the past. Also, Chrome added a “master password”, which was previously unavailable. Finally, Firefox no longer provides the reporting control for rogue websites and Opera removed both “modify user-agent” and “website checking” controls. The last two rows of Table 11 include the amount of unavailable controls in each browser from a total of 32 controls, and the percentage of those, respectively. Indicatively, Safari did not implemented 34.4% of the surveyed controls, while Firefox offered the majority of the controls that are examined herein. The availability of a control does not offer, though, any guarantees regarding the security offered. The scope of this work does not include the accuracy or precision of these controls.
62
Countermeasures against web threats
Howerver, the relevant literature has explored this area. For instance the authors in (Virvilis, et al., 2014)), (Virvilis, et al., 2015) and (Tsalis, et al., 2015) evaluated phishing and malware protection controls provided by popular mobile browsers in Android and iOS and desktop browsers in Windows.
Table 11. Availability of controls (n=32)
Browsers AS GC IE MF OP Content controls Block cookies      Block images      Block pop-ups      Privacy controls Block location data      Block referrer      Block third-party cookies      Enable DNT      History manager      Private browsing      Browser management controls Browser update      Certificate manager      Master password      Proxy server      Search engine manager      SSL/TLS version selection      Task manager      Third-party software controls Auto update extensions      Auto update plugins      Disable extension      Disable Java      Disable JavaScript      Disable plugin      External plugin check      Manually update extensions      Manually update plugins      Web browsing controls Certificate warning      Local blacklist      Malware protection      Modify user-agent      Phishing protection      Report rogue Website      Website checking     
 = 11 5 7 4 8 % = 34.4% 15.65% 21.9% 12.5% 25%
63
Countermeasures against web threats
3.2.2.2 Survey of browsers add-ons
The amount of security and/or privacy add-ons offered by each browser, up to April 2015, is depicted in Table 12. We tested only a subset of the add-ons offered by Chrome (65) and Firefox (65), based on user popularity, so as to end up with almost the same amount of tested add-ons in all browsers. All the available add-ons, that were included in the rest of the browsers, were tested. Thus, we examined a total of 227 add-ons. The list of the examined add-ons is available in the dissertation’s Appendix B. Chrome did not offer a specific category, so we found relevant add-ons with the use of specific keywords for each of the proposed categories (e.g. privacy, tracking, etc.). The add-ons were selected again based on user popularity.
Table 12. Available security/privacy add-ons per browser Security and/or Browser privacy add-ons Safari 38 Chrome N/A16 Internet Explorer 7 Firefox 1327 Opera 52
The mapping between the available categories and the add-ons is not one-to-one, as some add-ons offer mechanisms for more than one of the categories. Moreover, the tests were conducted from January to April 2015 therefore it is possible that some add-ons might have been altered (e.g. deleted or added). Figures 4-8 summarize the results regarding the security/privacy add-ons that were found in each category17. Each figure indicates the percentage of the total security/privacy add-ons, in each browser. The sum the percentages of security/privacy add-ons in Figs. 4-8 might exceeds 100%, since one add-on may belong in more than one category, based on the features it offers (e.g. tracking protection and a proxy service). Additionally, Table 4 (see Appendix) depicts the add-ons of each category provided by surveyed browsers and the names of the examined add- ons are included in the Appendix.
16 GC does not group security add-ons in one category, which so the total number of security add-ons is unknown. 17 2nd level categories (e.g. password manager, etc.) are included in Table 4 of the Appendix, and not depicted in this section.
64
Countermeasures against web threats
Content filtering 5.26% Parental control 18.42% Passwords 36.84% Plain proxy 0% Privacy 10.53% Protection from rogue sites 18.42% Third-party software 5.26% Tracking 26.32% Traffic encryption via proxy 2.63%
Figure 4: Available add-ons in Safari (n=38)
Content filtering 15.40% Parental control 23.00% Passwords 15.40% Plain proxy 8% Privacy 7.70% Protection from rogue sites 20.00% Third-party software 7.70% Tracking 15.40% Traffic encryption via proxy 12.30%
Figure 5: Available add-ons in Chrome (n=65)
Content filtering 0% Parental control 0% Passwords 0% Plain proxy 0% Privacy 0% Protection from rogue sites 0% Third-party software 0% Tracking 100% Traffic encryption via proxy 0%
Figure 6: Available add-ons in Internet Explorer (n=7)
Content filtering 39.47% Parental control 7.89% Passwords 15% Plain proxy 13.16% Privacy 23.68% Protection from rogue sites 17.50% Third-party software 13.16% Tracking 42.11% Traffic encryption via proxy 10.53%
Figure 7: Available add-ons in Firefox (n=65)
65
Countermeasures against web threats
Content filtering 15.38% Parental control 5.77% Passwords 21.15% Plain proxy 4% Privacy 23.08% Protection from rogue sites 23.08% Third-party software 5.77% Tracking 28.85% Traffic encryption via proxy 13.46%
Figure 8: Available add-ons in Opera (n=52)
3.2.3 Discussion
3.2.3.1 Revisiting pre-installed security controls
Our analysis showed that all browsers provide the content controls, while the second category (i.e. privacy controls) does not include the “block referrer” control in the majority of the tested browsers. Thus, the HTTP value in the header is most of the times transmitted and can be collected by malicious entities that aim to track users. Browser management controls were not available in the majority of the browsers. More specifically, most of the browsers did not support the use of a master password, the selection of the SSL/TLS version and a task manager. None of them offered an auto-update function for the included plugins, while most of them failed to provide manual updates or external checks for those plugins. These are important in terms of aquiring the latest updates, which often include security patches. Only a few browsers offered reporting rogue websites, although IE was the only one to provide a website checking control. Such an approach is clearly a major drawback, in terms of not offering a checking service for possible rogue websites and so, the user is exposed to malicious sites. In the rest of this section, we discuss the security gaps in terms of non implemented controls, that were found in each browser: Safari: As summarized in Table 11, 34.4% of the surveyed controls were not implemented, and thus AS does not offer an adequate level of security. From those controls, the most critical are summarized as follows: the browser lacks a master password service and thus the user cannot manage the installed passwords in the browser. Also, there is no blacklist mechanism available to filter websites based on reputation, and no reporting services if the user wants to check a visited website regarding its legitimacy. In addition, there is no SSL/TLS version selection option available, and as a result the user cannot upgrade the mechanism to its latest version.
66
Countermeasures against web threats
Chrome: We had similar results to Safari. Once more, there is lack of SSL/TLS version selection and no reporting or checking mechanisms regarding the websites visited by the user. Thus, the user is unable to check a visited website whether it is malicious or not. Internet Explorer: It does not offer a master password service and the option to block the referrer. Moreover, there were not available controls regarding the manual update of the browser’s features (i.e. extensions and plugins). Finally, the user cannot use an external source to check the included plugins, a feature that is currently offered only by MF. Firefox: As summarized in Table 11, Firefox provides the highest number of available controls. In addition, its community offers the highest amount of available add-ons, regarding security and/or privacy (i.e. 1327, April 2015). The only security limitation of Firefox’s was the absence a reputation based mechanism to filter the visited websites, as discussed in the Safari browser. Opera: It was the second less secure browser (after IE) with regards to the availability of security controls. Almost all of the unavailable controls were similar to the AS, except the “modify user-agent” control, which was not provided by Opera.
3.2.3.2 Survey of add-ons
The analysis revealed that all browsers except for GC and IE offered a 1st level categorization dedicated for security and or privacy add-ons. More specifically, Safari provided Security, Firefox and Opera provided Privacy & Security. Chrome and IE did not, and as a result we manually searched for the security and privacy add-ons. This confusing structure/organization of add-ons may result in confusing the users when searching for any useful (with respect to the provided security) add-on. For example, Chrome classified a popular add blocker add-on (i.e. AdBlock Plus (AdBlockPlus, 2015)) in the “search & browsing tools” category, which does not encourage the user to install the application. Additionally, none of the browsers offered a 2nd level categorization (e.g. passwords, malware protection, VPNs, etc.). Such approach, could be proven beneficial for users, since they could be searching for specific add-ons only in. All of the browsers provided an adequate description of each add-on, except Safari, which only provided a short paragraph. Thus, the user had to visit the developer’s website to find additional information regarding the add-on(s). In the rest of this subsection, we discuss the results of our analysis, concerning the available add-ons in each browser’s repository: Safari: As Figure 4 depicts, Safari’s community clearly covers almost every one of the surveyed categories. Its main focus is two-fold: offering password services for password generation and management (36.84%), and protecting the user from tracking (26.32%). These
67
Countermeasures against web threats two pose as the community’s highest priorities. Note that the first category was one the browser’s gap, in terms of unavailable controls. Next, Safari’s add-ons focus in website filtering protection, i.e. parental control and rogue sites’ filtering (both at 18.42%). Thus, they protect the user from visiting websites that contain malicious or offensive content that covers the second security gap as well. The other categories were partially covered by Safari’s community, with the highest being the “privacy” category (10.53%) and the lowest being the “plain proxy”, which is not covered. Chrome: According to Figure 5, Chrome provides add-ons in each of the surveyed categories, thus, satfisfied the unavailable controls that we have been identified in this work. More specifically, the browser’s community focuses on offering parental control services (23%) and rogue sites filtering mechanisms (20%), therefore succeeding in protecting the user against malicious websites. Moreover, Chrome offers add-ons that provide the user with content blocking mechanisms, password services and tracking blocking services (all with a 15.4% availability). This suggests that the Chrome communicty considers those services almost as equal of importance as the highest priorities, as discussed above. All the other categories, were partially covered by Chrome’s community, with the highest being the “traffic encryption via proxy” category reaching 12.3%, while the rest of the categories have a 7.7% availability. Note that this applies only to the current tested subset, which includes a part of the most popular add- ons of the browser, based on user popularity. Internet Explorer: Internet Explorer offers only 7 security and/or privacy add-ons. All of them focus on tracking protection and, thus, all the categories that are not covered by the browser’s controls, are unprotected by the offered add-ons as well. As a result, Internet Explorer’s add-ons fail to provide the unavailable security and/or privacy protection. Firefox: According to Figure 7, Firefox browser fully covers not only the unavailable controls, but the total categories (and sub-categories) of the add-ons. More specifically, the browser’s highest priorities are tracking protection (42.11%) and content filtering services (39.47%). As a result, the user is able to block both tracking websites that aim in accessing sensitive information and content elements (e.g. pop-ups) that could either annoy or harm the user (e.g. phishing content). Also, all the other categories are again adequatelly covered, while varying from 23.68% (privacy) to 7.89% (parental control). Overall, Firefox succeeds in offering almost a full set of both controls and add-ons regarding the surveyed categories. Opera: Despite the controls’ unavailability, Opera offered a variety of add-ons regarding all the tested categories. Four categories clearly pose as Opera’s main focus: tracking blocking services (28.85), privacy and protection from rogue sites (both at 23.08%) and password services (21.15%). The rest of categories were partially covered by Opera’s community, with the highest being the “content filtering” category reaching 15.38% and the lowest being the “plain proxy” one, which is located at 3.85%. Overall, Opera may not offer a complete set of
68
Countermeasures against web threats security and privacy controls, but such a feature is clearly covered by the browser’s community regarding the available add-ons.
3.2.4 Overall availability of add-ons
Figure 9 summarizes the above. It reveals the overall focus of the community that provides security-oriented add-ons in the browser ecosystem.
30% 25% 25% 25% 19.34% 18.40% 20% 14.15% 15% 8.49% 9.43% 10% 5.66% 7.07% 5% 0%
Figure 9: Overall availability of add-ons (n=227)
As Figure 9 suggests, “tracking” and “content filtering” categories include 25% of the most popular, security-oriented add-ons. This suggests that the highest priority in the browsing ecosystem is enhancing the protection of the user from malicious entities who aim to violate users’ privacy. In parallel, the community aims to offer filtering services for content elements (i.e. cookies, advertisements, images and pop-ups), which could either create annoyance or include malicious software (e.g. phishing, scam) that harm the user. After that, there are the “passwords” and “protection from rogue websites” categories, which hold 19.34% and 18.4% respectively. The former category includes password oriented services, i.e. managers (15.1%) and generators (9.43%), and covers the identified gap, since almost all modern web browsers (except Firefox) do not offer such a control. The latter, includes protection based on\against: malware (8.02%), reputation (8.02%), phishing (5.19%) antivirus (4.72%) and sandbox (3.77%). Such services aim in protecting the user from malicious websites. The “privacy” category includes privacy oriented contents (e.g. autofill forms, cache, location, etc.). Those can either be blocked or cleared (e.g. cache cleaner), so as not to be monitored by an unauthorized entity. This category includes 14.15% of the surveyed add-ons.
69
Countermeasures against web threats
The remaining four categories are located just below 10%. More specifically, in descending order: traffic encryption via proxy (9.43%), parental control (8.49%), third-party software (7.07%) and plain proxy (5.66%). The first and last category reveal the need to use a proxy service to either access any region protected content, or hide user’s identity for tracking protection. The “parental control” category includes website filtering to block any inapropriate material18. Finally, the last surveyed category (i.e. third-party software) allows the management (i.e. blocking, enabling) of third-party software: flash, java, javascript, etc., in order to protect the user from services that are not built-in the browser, since malicious content may be included.
18 Pornographic or gambling material.
70
Countermeasures against web threats
3.3 Discussion This chapter provided a systematic and comprehensive analysis of the availability and manageability of security controls in popular smartphones and desktop browsers. It also provided a comparative evaluation of the: (a) protection of preconfigured security settings against web threats, (b) manageability of security controls that protect from certain web threats and (c) the available security and/or privacy add-ons that are available for each browser. The former provides indications of the ‘out of the box’ offered protection to average users. The latter reveals the flexibility to adjust the offered protection according to the users’ “risk appetite” (e.g. a user may be willing to receive targeted advertising). The results can be used from browser users to adjust their protection level, as well as from browser vendors to cross-compare their security offerings. This work provides proof that the controls that are available in desktop browsers are a superset of the ones found in smartphones. Currently in smartphones, a user has to use multiple browsers in order to use certain security controls. For instance, in iOS she has to use Chrome Mobile for a robust control of security warnings, and Safari Mobile for both private browsing and phishing detection. This unavailability of browser controls can be partially explained by the restrictions of the smartphones’ security models (e.g. private browsing in Chrome Mobile for iOS). However, the evaluation reveals occasions where a security control is available in a subset of browsers of a smartphone OS. This suggests that the restrictions from the sandbox were not the reason that the control was not implemented in the rest smartphone browsers in this platform. The analysis revealed that two browsers (Safari and Opera Mini) had a number of security issues, which are serious (i.e. unpatched vulnerabilities, no protection from invalid digital certificates). Furthermore, the analysis of the preconfigured security settings in browsers revealed that Firefox Mobile provides comparable protection against web threats to desktop browsers (c.f. Figure 2). The evaluation also revealed that third-party advertising is enabled by default in most desktop browsers. In addition, in their smartphone counterparts it is not easily manageable, since they adopt all-or-nothing approach in cookie management. Therefore a user has to either accept all cookies including tracking cookies, or disable all of them, which will break the functionality of several benign websites. Also, DNT is disabled by default - or unavailable as a control in smartphone browsers. This work proposes that privacy controls should be configured during browser installation or post installation (i.e. first time the browser executes), where the user should be reasonably aided to make an informed decision. Finally, private browsing is not supported in a subset of smartphone browsers. Users are unprotected from rogue websites, which serve malware and/or perform phishing scams, while browsing with their smartphone. This holds true, as smartphone browsers fail to
71
Countermeasures against web threats detect rogue websites. Users can be protected by disabling all dynamic content (i.e. the plugins, JavaScript) - a control that is not offered in all smartphone browsers. This, however, will not protect them from a Blackhole exploit framework that targets vulnerabilities in the browser’s software (e.g. in plugins). It also hinders their browsing experience, since most web applications require JavaScript to function correctly. For this reason, this work proposed that smartphone browsers either use a local blacklist or ad-hoc query an online blacklist with reported rogue websites, such as Google’s Safe Browsing. This, however, will introduce delays, as well as additional bandwidth consumption, which in the case of mobile Internet may not be acceptable (due to cost and bandwidth quota limitations). Moreover, online queries introduce privacy issues. Alternatively, a proxy server may be used that provides detection of rogue websites. This proxy may also be used for UA modification, which protects users from system disclosure attacks. In this case, the proxy - apart from altering the device’s UA - must filter out JavaScript code that may leak the UA string. The analysis revealed that security controls can be disabled as easy as disabling controls that are not security oriented. Also, security controls often reside together with non security related options (such as zoom, character encoding, font size, etc). As discussed earlier, the interface of security controls must be reorganized in order to assist users correctly configure the security level offered by the browser. The evaluation focused on smartphone and Windows desktop and omits differences in the availability of controls in other platforms in the former (e.g. BlackBerry, Symbian), or latter (e.g. Mac-OS) device type. The evaluation includes the most popular devices in the two platform and as a result, the security findings are adequately representative in them. Another limitation of this work is that security controls may be added to browsers – especially to smartphone browsers – when they update. However, as discussed earlier, updates for smartphone browsers are less frequent, semi-automatic, suffer from delays (from the app market or device vendor), as well as an update may also be unavailable if the device is not supported anymore. Additionaly, this work provides a comparative evaluation of the availability of security-oriented add-ons in each desktop browser. We re-analyzed a total of 32 pre-installed security- oriented controls and found that Firefox provided the majority of them (i.e. 84.4%). Safari offered only 65.6% of the controls and the availability of the controls in the rest of the browsers varied (from approx. 71-85%). The analysis of the available security-oriented add-ons revealed that Firefox and Chrome provided a plethora of security and/or privacy oriented add-ons. The other browsers had in total approximately 50 security-oriented add-ons only, while Internet Explorer offered only seven. Almost all browsers (except IE) provided add-ons that fill the gap for the unavailable pre-installed security controls. In addition, already existing controls (e.g. malware protection, master password, etc.) are enhanced by the availability of add-ons, if the user chooses not to only trust the browser’s built-in mechanisms.
72
Countermeasures against web threats
The analysis reveals that web browsers can enhance the grouping of the available security- oriented add-ons. That holds true as all browsers, except GC and IE, offered only a 1st level categorization. The absence of this add-on grouping hinders users’ searches for add-ons that enhance their security. However, none of the browsers offered additional subgroups (2nd level categorization), which could further enhance user’s search results when looking for a specific subcategory of an add-on (e.g. password generators). In this work, we provide such a taxonomy of add-on categories. Our analysis focuses on the availability of security oriented controls. However, their performance is not in the scope of this paper. Another limitation of our work is that that new security controls and add-ons may be added to browsers or the popularity of the addons might change. While, some add-ons could include security features even if they were not categorized as security and/or privacy add-ons and thus were out of scope. Also, in Chrome and Firefox only the 65 most popular add-ons, in order to have a consistent comparison with the rest browser that had only approximately 35 addons on average.
73
Countermeasures against web threats
(this page is intentionally left blank)
74
Evaluation of browser controls
4 Evaluation of browser controls
4.1 Phishing protection
4.1.1 Introduction
The proliferation of smarpthones is increasing. According to (Gartner, 2014), in the Q3 of 2013 more than 445M mobile phones were sold, out of which 250M were smartphones. Despite the unarguable important benefits and capabilities which they offer, the use of such devices - especially for sensitive online tasks - has turned them into a new profitable target for attackers. More specifically, nowadays: (a) smartphones are frequently used as part of a two-factor authentication scheme for online services (e.g. e-banking), (b) wireless payments using NFC- enabled smartphones are getting continuously more popular, exceeding 235Β$ in 2013 (Gartner, 2014b), (c) the use of smartphones in business is also increasing (e.g. under the Bring Your Own Device (BYOD) trend), even in sensitive environments, with iOS and Android devices getting accredited for use in the US Dept. of Defence (Capaccio, 2014), and (d) smartphones have become appealing targets as recent reports have revealled (CBC, 2014). One of the threats that target (smartphone) users suffer by is phishing. Phishing can be deemed as one of the most popular and profitable attacks, having almost 450,000 attacks in 2013 and estimated losses of over 5.9B$. NIST defines phishing (Mell, et al., 2005) as: “Phishing refers to use of deceptive computer-based means to trick individuals into disclosing sensitive personal information. Phishing attacks aid criminals in a wide range of illegal activities, including identity theft and fraud. They can also be used to install malware and attacker tools on a user’s system.” Although the majority of phishing attacks are widespread and focus on financial gain, targeted phishing attacks also exist. These attacks are known as spear-phishing and have been used in a large number of sophisticated attacks against government, military and financial institutions. The analysis of past major security incidents, involving Advanced Persistent Th- reats (APT) (Virvilis, et al., 2013) (Virvilis, et al., 2013b), has revealed that attackers used targeted phishing attacks in order to gain access to the internal network of their target. In this work, we evaluate the protection offered against phishing attacks on smartphone platforms. The scope of our analysis includes the popular browsers in Android and iOS. We measured the protection offered by these browsers, by accessing more than 5,000 manually verified phishing URLs, within a period of two months. We performed the same evaluation against popular desktop browsers and compared their detection rate. Our results indicate a significant gap in the effectiveness of phishing protection between smartphone and dekstop browsers. Finally, we collected and analyzed all the URLs of phishing campaigns that have not
75
Evaluation of browser controls been filtered out by the browsers in any of the two platforms to identify common characteristics that enable us to strengthen our defences against the above threat. This work makes the following contributions:  It provides a comparison of the phishing protection offered by popular browsers in Android, iOS and Windows platforms.  It provides insights of the characteristics of successful phishing campaigns, i.e. phishing URLs that were not filtered out by web browsers. We discuss how these characteristics can be used to further stregthen the defences against phishing. The remainder of the paper is structured as follows. Section 4.1.2 describes the methodology and Section 4.1.3 presents our results.
4.1.2 Methodology
The scope of our work includes popular desktop browsers, i.e. Chrome, Internet Explorer, Firefox, and Opera, together with their smartphone counterparts. In smartphones, the scope of our analysis focuses in iOS and Android, as they are the prominent smartphone platforms, having ~90% of the global market share (Bradley, 2014). For the evaluation of smartphone browsers, an iPhone 5S was used for iOS, and a Sony Xperia Tipo for Android. The smartphone counterparts of desktop browsers may appear either as a pre-installed browser (e.g. Safari Mobile in iOS), or as a third party application that the user has to download from an app marketplace (e.g. Firefox Mobile for Android). Their availability in the two smartphone platforms is heterogeneous (see Table 1). To evaluate the protection that is offered by the above mentioned web browsers, we visited phishing URLs that were indexed in PhishTank. We selected phishing URLs that were confirmed - i.e. PhishTank confirmed the reported URL as a fraudulent one - and online. However, the state of a phishing URL is dynamic, namely a confirmed URL might be cleaned or be taken down short after its submission to an anti-phishing blacklist list. Therefore, all the URLs were manually examined to separate web pages that have been cleaned (i.e. false positives) from the ones that were fraudulent and not filtered out by the browsers' blacklists (i.e. false negatives).
76
Evaluation of browser controls
Table 13. Browser availability in iOS and Android Android 4.0.4 (Sony Xperia iOS 7.0.4 Tipo) Windows 7 (64bit) Safari Mobile X Chrome Mobile X X Opera Mini X X Browser† X Firefox Mobile X Opera Mobile X Chrome X Firefox X Internet Explorer X Opera X † 'Browser' is the pre-installed browser in Android
We collected URLs from PhishTank for two months (Jan-Mar 2014). During this period we noticed that their number fluctuated significantly, with an average of several hundred URLs per day. Although some of the evaluation could be automated (e.g. URL that returned HTTP Error Codes or URL for which the browsers raised warnings), it was necessary to verify whether URLs, that were not filtered-out by the browsers as fraudulent, were actually legitimate sites (i.e. not false negatives). This required manual verification. To keep the analysis manageable, each day we manually verified at most 100 URLs, which were indexed in PhishTank as confirmed and online. In cases, more than 100 URLs were indexed in PhishTank on a given day, we randomly selected 100 URLs from them. In total, we collected and evaluated the web browsers that were in our scope, against 5651 phishing sites. Each URL was categorized into one of the following three categories: a. Blacklisted: The URL was filtered-out by the web browser, i.e. the user receives a warning indicating the threat of a potential phishing site. b. False Negative: Denoting a phishing site that was manually verified by us as fraudulent, but was not on the browser’s blacklist (e.g. the browser generated no warning). c. Non-Phishing/Timeout/Error: A site that during our manual verification had either been cleaned, or suspended/taken down when we accessed it. For each URL found to be a false negative, we kept the URL and the contents of the malicious phishing page. This enabled us to identify the most popular phishing targets, as well as identify patterns that helped us improve the detection mechanisms. Finally, for each URL that was collected, we used the Safe Browsing Lookup API (Google, 2014) to query directly the Safe Browsing database. This enabled us, to compare the results from the Safe Browsing Lookup API with the web browsers’ results.
77
Evaluation of browser controls
Table 14. Support of anti-phishing mechanisms Phishing protec- Platform Browser name tion† Safari Mobile Y iOS Chrome Mobile N Opera Mini N Browser† N Firefox Mobile Y Android Chrome Mobile N Opera Mobile Y Opera Mini N Firefox Y Chrome Y Windows 7 Opera Y Internet Explorer Y † Y: Security control available, N: Security control not available †† 'Browser is the pre-installed browser in Android
4.1.3 Results
4.1.3.1 Overview
A finding that arose early in our analysis is that only a subset of the mobile browsers supported anti-phishing protection (see Table 14). Thus, their respective users were unprotected from phishing attacks. On the contrary, all desktop browsers provided anti-phishing protection, even though their effectiveness differed significantly. Table 14 summarizes the availability of anti-phishing protection per operating system and browser (as of March 2014). The results of our analysis are presented in Figs. 10-12. More specifically, (a) Figure 10 presents the percentage of blocked URLs per browser, (b) Figure 11 depicts the percentage of active phishing URLs that were not filtered out, namely the ones that were not in the browser’s blacklist and were manually verified as active malicious sites (false negatives), and (c) Figure 12 presents the percentage of URLs that were not in the browser’s blacklist and were manually verified during our analysis as non-malicious sites (i.e. URLs that had been cleaned, or domains that had been taken down or were not accessible when we accessed them). The browsers that did not support any anti-phishing mechanism are not included in the charts, as their detection rate is zero.
Blacklisted domains per browser
78
Evaluation of browser controls
Figure 10: Percentage of blocked URLs (n=5651)
False Negatives per browser
Figure 11: Percentage of phishing URLs that were not filtered out (n=5651)
Non-phishing URLs
Figure 12: URLs not in blacklist and not phishing (manual verification, n=5651)
For further information, the detailed results (per browser) are depicted as follows: Table 15. Detailed results per browser Browser Black-listed False negatives Non-phishing Safari Mobile (iOS) 4239 751 661 Firefox Mobile (Android) 4821 168 662 Opera Mobile (Android) 4448 84 1119 Firefox (Windows) 5362 117 172 Chrome (Windows) 5341 94 216 Opera (Windows) 4920 79 652 IE (Windows) 3653 376 1622
79
Evaluation of browser controls
In the next sections we discuss the findings in every platform, the protection offered by Safe Browsing API. Also, we perform a brief analysis of phishing URLs that were not filtered out (i.e. false negatives). Detailed results per browser are available in the Appendix.
4.1.3.2 iOS browsers
In iOS devices, Mobile Safari - which is the default (i.e. pre-installed) web browser of the platform – supports the detection of fraudulent websites by utilizing Google’s Safe Browsing blacklist. Our evaluation revealed that the anti-phishing control suffers from a significant design weakness. This holds true, since the Safe Browsing blacklist is only updated when a user synchronizes her iOS device with iTunes (on a desktop/laptop). Considering that a subset of iOS users may not synchronize their devices frequently (e.g. when they are on a trip) or at all, they end up with an outdated blacklist. Thus, these users eventually receive only a limited protection against phishing attacks. Our analysis also revealed that (see Fig. 10-12): (a) Mobile Safari had significantly more false negatives (i.e. phishing URLs that were not filtered out) comparing to the other mobile web browsers, and (b) iOS users can be protected from phishing attacks only when they use Mobile Safari, since Chrome Mobile and Opera Mini do not offer such protection.
4.1.3.3 Android browsers
In Android, the default web browser (commonly known to Android users as “Browser”) offers no phishing protection. The same applies to the Mobile Chrome and Opera Mini browsers. Οur evaluation revealed that Android users can only be protected from phishing attacks if they use Firefox Mobile and Opera Mobile. Also, our results revealed that the two above mentioned browsers offer comparable but not equal protection from phishing with their desktop counterparts. If one considers that: (a) not all users are willing and/or capable to install a third party browser on their devices and (b) the pre-installed browser offers no protection, then a very large number of Android users is not adequately protected from phishing attacks.
4.1.3.4 Desktop browsers
All desktop web browsers offered phishing protection using either Google’s Safe Browsing (i.e. Chrome and Firefox) or their own proprietary blacklists (i.e. in Opera and Internet Explorer). The protection against phishing in Chrome and Firefox was similar; both blocked
80
Evaluation of browser controls almost all the fraudulent URLs that we tested. At the same time, they achieved low false negatives. However, this similarity in their performance was expected, as both use the same blacklist. During our experiments we found another issue with the synchronization of blacklists, which, similarly to (Abrams, et al., 2014), offered a window of exploitation to phishers. We noticed that if the desktop browsers were not executing for a few minutes before we started our evaluation, then the blacklist was not properly updated. This is especially true for Firefox, as in this web browser we frequently encountered a large number of false negatives (i.e. phishing pages that were not blocked) during the first few minutes of our tests. This is very likely due to the way that the Safe Browsing protocol updates the list of malicious sites (Sobrier, 2014). Interestingly enough we did not face this problem in Chrome. In (Abrams, et al., 2014), authors highlighted the same issue during their tests for an older version of Chrome, which adds to our suspicion that the inconsistent results are due to the Safe Browsing protocol’s update procedure. As summarized in Figs. 10-12, Opera outscored in our evaluation the rest browsers. Even though the percentage of blocked URLs was less, this does not translate to a less accurate blacklist. This holds true, as the percentage of false negatives (i.e. the phishing sites that were not filtered out) is lower than both Chrome and Firefox. As a matter of fact, it seems that Opera’s blacklist is updated more frequently, as it did not block URLs that had been cleaned or taken down, while these URLs were still blocked by the browsers that used the Safe Browsing blacklist. Finally, the proprietary blacklist that Internet Explorer uses, i.e. Microsoft's SmartScreen, offered the least protection in the desktop browsers. As our results indicate, Internet Explorer had the highest rate of false negatives among them, i.e. filtered out fewer manually confirmed phishing URLs than the other desktop web browsers.
4.1.4 Safe Browsing API
For each test URL of our analysis we used Google’s Lookup API (Sobrier, 2014) to query directly the Safe Browsing blacklist, to compare its results with the browsers' results. The results from Safe Browsing Lookup API differed significantly from those of Chrome and Fire- fox browsers. More specifically, on average only 73.21% of the URLs that were blocked by Chrome and Firefox, were reported as malicious by Google’s Safe Browsing Lookup API. After manually verifying the URLs that were not blocked, we noticed that their majority were active phishing sites (i.e. false negatives of the API). Two ways are available for querying the Safe Browsing database: (a) using the Google Safe Browsing API v2, or (b) using the Lookup API (Google, 2014). The first, which is used by web browsers, offers better privacy as the browser does not need to send the queried URL to Google
81
Evaluation of browser controls for analysis; also, it is optimized for a large number of requests. The latter offers simpler implementation (i.e. a single HTTP GET request) and can be used for testing up to 10.000 URLs per day. Nevertheless, both API query the same database according to Google (Google, 2014) and should provide the same results. Our experiments reveal that the results between these two ways differ significantly. This difference is not documented by Google. This may be due to the fact that: (a) web browsers use additional anti-phishing mechanisms which complement the Safe Browsing, and/or (b) the Safe Browsing API v2 and Lookup API do not query the same data set, contrary to Google documentation (Google, 2008).
4.1.5 Results revisited
4.1.5.1 Test methodology
The experiments were conducted in June and July 2014 and focused on the most popular browsers on the desktop and smartphone platforms, namely:
 Desktop browsers. Internet Explorer 11, Chrome v35, Firefox v29, and Opera v22, which were installed on a Windows 7 64-bit system.  Mobile browsers. Safari Mobile (built-in on iOS 7.1.1), Chrome Mobile v35, Opera Mini v7.0, “Browser” or “Internet” (i.e. the default browser for Android 4.0.4), Firefox Mobile v30, and Opera Mobile v22, which were installed on an iPhone 5S (iOS v7.1.1) and a Sony Xperia Tipo (Android v4.0.4). Although some of the desktop browsers have mobile counterparts, their availability on the two smartphone platforms is heterogeneous.
Our effort in the smartphone platform focused on iOS and Android, as these are the two most popular operating systems, comprising almost 90% of the global smartphone market share (Brandley, 2013). To evaluate the protection that is offered to users against rogue web sites, 1400 phishing and 1400 malicious URLs were accessed. The ones for which browsers raised alerts, were recorded. As technology that can be used to fully automate this process is not currently available, a security savvy user manually verified if a web page that had not been reported by the browser, was indeed a rogue or a benign web page. Since this was a cumbersome task, the architecture presented in Figure 13, was set up.
82
Evaluation of browser controls
Figure 13: Laboratory setup
The URL Collection included the URLs that were used in the evaluation. The URL Container parsed daily the URL Collection and selected the URLs that had been reported to Phishtank in the last 24 hours. Then, two HTML files were created, one for phishing URLs and one for malicious URLs, which were formatted as the Snippet below. Finally, a researcher used each browser installed on the test devices, to access each HTML file and collect the number of: a) blocked URLs, b) false negatives, and c) non-phishing/malicious URLs. To evaluate the anti-phishing protection that is offered by the aforementioned web browsers, 1400 phishing URLs were collected from PhishTank (Phishtank 2014). PhishTank was selected as it is a popular online service that lists phishing URLs, which are verified by an active community. PhishTank publishes every day a list of verified phishing URLs, i.e. ones that have been confirmed as fraudulent and online. However, as the state of a phishing URL is dynamic, a confirmed URL might be cleaned or be taken down shortly after its submission.
Figure 14: Snippet - HTML content
Although part of the experiments could have been automated (e.g. when the request returned an HTTP Error Code or the browser raised a warning), manual review was required in order to measure the false negatives (actual phishing URLs, which were not blocked by the browser). In specific, each URL that was not blocked by the browser was examined and classified it as (a) benign or not responsive/non accessible site (i.e. inactive phishing site) or (b) false negative (i.e. an active phishing site that was not blocked by the browser).
83
Evaluation of browser controls
Thus, in the end of the experiment every URL in the phishing collection was manually classified as:
a) Blacklisted: The phishing URL was blocked by the web browser, i.e. the user received a warning indicating a phishing site. b) False Negative: An active phishing URL that was manually verified as fraudulent, but was not blocked by the browser. c) Non-Phishing/Timeout/Error: The phishing URL had been suspended/taken down/cleaned when it was accessed.
It should be noted that the data set included only verified phishing URLs (i.e. a human operator from PhishTank has manually verified them as fraudulent), as the main objective was to examine the efficacy of browsers’ anti-phishing blacklists. Therefore, the false positive rate of all browsers, which is out of the scope of this work, was zero. Finally, the results are compared with our previous work in (Virvilis, et al., 2014).
4.1.5.2 iOS browsers
Mobile Safari, which is the pre-installed iOS web browser, uses Google’s Safe Browsing to provide anti-phishing protection. The evaluation revealed that the implementation of this anti- phishing control suffers from a significant design weakness, as the Safe Browsing blacklist is only updated when the iOS device is synchronized with iTunes. Considering that some iOS users may not synchronize their devices frequently, they may end up with an outdated blacklist. Furthermore, the list is updated only once per day. Thus, any phishing site that has been created in the meantime - even if it has been reported to Safe Browsing list - will not be blocked. As a result, iOS users receive considerably limited protection against phishing attacks. In fact, during the experiments Safari Mobile did not block any phishing URL when this synchronization step was skipped. Therefore, the iOS test device was synced daily, right before starting our evaluation. Chrome Mobile offers phishing protection since January 2014. However, this option is not enabled by default, but requires the user to enable the “Reduce Data Usage” option, which uses Google’s servers as a proxy to fetch the requested URL. When this option is enabled, the contents of the web page are downloaded and compressed and the URL is checked against the Safe Browsing list. This feature is privacy intrusive - as all traffic is transferred through Google’s servers - and does not work for SSL/TLS pages or in Incognito mode (private browsing). This browser has been excluded from the evaluation as: a) it is less likely that normal users (i.e. not security and savvy ones) would enable security controls, as smartphone users tend to be oblivious about their security and privacy (Mylonas, et al., 2013) and (b) the control
84
Evaluation of browser controls is not ‘easily configurable’ (Mylonas, et al., 2013b), i.e. the label of the control is not intuitive and confusing even for security savvy users. Finally, Opera Mini did not support phishing protection.
Table 16. Phishing protection statistics on iOS
URL Blacklisted False negatives Non-phishing iOS Browser Safari Mobile 542 370 488 Chrome Mobile N/A N/A N/A Opera Mini N/A N/A N/A
4.1.5.3 Android browsers
Android users also receive limited protection against phishing attacks, as the default Android browser (known as “Browser” or “Internet”) does not offer phishing protection. The same holds true for Chrome Mobile and Opera Mini. It must be noted that these are the most popular browsers on Android, according to the number of downloads on Google Play. On the other hand, Firefox Mobile and Opera Mobile offer anti-phishing protection. The results suggest that both browsers offer similar protection with their desktop counterparts. Specifically, Firefox and Opera on Windows blocked 86.7% and 77.9% of the phishing URLs and Firefox Mobile and Opera Mobile blocked 85.4% and 75.9%, respectively. Nevertheless, if one considers that: (a) not all users feel the need and/or are capable to install a third-party browser on their devices (Mylonas, Kastania, et al. 2013) and (b) the pre-installed browser offers no anti-phishing protection, then a large number of Android users is not protected from phishing attacks.
Table 17. Phishing protection statistics on Android
URL Blacklisted False negatives Non-phishing Android Browser Firefox Mobile 1196 48 156 Opera Mobile 1062 110 228 Chrome Mobile N/A† N/A N/A Opera Mini N/A N/A N/A Android Browser†† N/A N/A N/A
†† 'Browser' (or Internet) is the pre-installed Android browser † N/A: Browser does not support anti-phishing mechanisms
4.1.5.4 Desktop browsers
85
Evaluation of browser controls
The analysis revealed that all desktop browsers offered anti-phishing protection using either Safe Browsing list (Chrome and Firefox) or their own proprietary blacklists (Opera and Internet Explorer). The most phishing URLs were blocked by Chrome and Firefox. Although their results are similar - which is expected as they use the same blacklist - Chrome outperforms Firefox, as in our experiments it blocked roughly 5% more phishing sites and has a lower false negative rate. During our experiments another issue was encountered with the synchronization of blacklists in Firefox, which was also raised by (Abrams, et al., 2014). Specifically, each day Safe Browsing blacklist in Firefox was not updated, unless Firefox was executed for a few minutes before our evaluation, which resulted to a large number of false negatives. This stems from the way the Safe Browsing protocol updates its local database (Sobrier, 2014). Interestingly, this problem did not appear in Chrome or any smartphone browsers that use Safe Browsing. To avoid this synchronization issue, Firefox was executed for at least 10 minutes prior testing, to allow the browser to update its blacklist. Opera blocked roughly 10% less phishing sites than Firefox and had slightly more false negatives. Finally, Internet Explorer offered the lowest level of protection among the desktop browsers, having the smallest percentage of blocked URLs (less than 50%).
Table 18. Phishing protection statistics on Windows
URL Black- False neg- Non- Browser listed atives phishing Firefox 1215 83 102 Chrome 1302 18 80 Opera 1090 118 192 Internet Explorer 678 138 584
4.1.5.5 Comparison with previous evaluation
Herein, the anti-phishing protection that the popular desktop and mobile browsers offer in Q2 2014, are compared with the results of our previous work in (Virvilis, et al., 2014), which was conducted in Q1 2014. Since the phishing ‘ecosystem’ is dynamic, i.e. phishing sites are short-lived with an average life expectancy of 23 hours (Abrams, et al., 2013), our aim is to examine how this dynamic nature is reflected in the browsers’ anti-phishing protection over this period of time. The results are summarized in Figure 15. The browsers blocked fewer phishing URLs in Q2 with the exception of Firefox Mobile on Android. Safari Mobile’s (iOS) detection dropped almost by half. This stresses again the problematic implementation of the Safe Browsing protocol on iOS. Furthermore, the analysis showed a small decrease in the performance of the
86
Evaluation of browser controls desktop versions of Firefox and Opera, with respect to the blacklisted URLs and false negatives. Finally, Internet Explorer blacklisted less URLs and was prone to more false negatives, and Opera Mobile had more false negatives.
100% 90% 80% 70% 60% 50% Q1 Blacklisted 40% 30% Q1 False-negative 20% 10% Q1 Non-phishing 0% Q2 Blacklisted Q2 False-negative Q2 Non-Phishing
Figure 15: Comparison of anti-phishing protection (Q1 2014 – Q2 2014)
4.1.6 Phishing Campaigns
During our experiments we noted every phishing campaign (both URL and page contents) that was manually verified as phishing, but was not filtered out by at least one of the web browsers in our scope that supported anti-phishing protection. The analysis of the phishing URLs that were not filtered out aimed at identifying the most popular phishing targets. It also aimed at highlighting similarities between phishing campaigns that could be used to strengthen our defenses against such attacks. Table 4 summarizes these results.
Table 19. Main Phishing Campaigns
Percent- Target String in URL age paypal.com 61.68% 48.19% appleid.apple.com 15.17% 47.61% Banks (Multiple) 4.41% N/A Web Email (Multiple) 5.10% N/A Random Cam- 13.64% N/A paigns
PayPal was the primary target of the phishing campaigns, as 61.68% of the phishing URLs that were tested targeted PayPal users. The second most popular target was Apple, with 15.17% of the phishing URLs targeting Apple users. A compromised Apple account gives access to all information stored on the victim’s iCloud account (iCloud, 2014), including contacts, calendar, email, files and photos. Therefore, this is another fruitful target for attackers.
87
Evaluation of browser controls
The rest of the phishing results have been divided in three generic categories: a. Banks - Phishing campaigns that target online banking from various banks. b. email - Phishing campaigns that target web based email providers (Gmail, Yahoo Mail, Outlook). c. Misc - Random phishing campaigns against other websites. Our analysis revealed that in the two popular phishing campaigns, the 48.19% and 47.61% of them contained in their URL the word “paypal” or “apple”, respectively. By including those strings in the beginning of the URL, the phishing attack is more likely to succeed against naive users who do not inspect the whole URL (examples appear in see Table 5). Our results suggest that web browsers can implement URL filtering based on regular expressions, so as to increase their detection rate against sites that are not yet blacklisted. For instance, web browsers can change the color of the location bar or issue a warning to the user, when visiting a URL that includes the string of a popular site (e.g. “paypal”, Table 5), while the URL does not originate from a benign web site (e.g. www.paypal.com or www.paypalobjects.com). Such a solution might not scale adequately for a large number of sites, but it could be implemented to protect a few hundred of popular ones, in the same way that Google Chrome implements Certificate Pinning for specific sensitive domains (OWASP, 2014). Nevertheless, such countermeasures can only partially address the problem. Only a multi-layered defense of both technical and procedural means, will enable us to defend effectively against the phishing threat (Theoharidou, et al., 2010), (Theoharidou, et al., 2009).
Table 20. Phishing URL1 Target URL† Paypal http://paypal.com.cgi-bin-websc5.b4d80a13c0a2116480.ee0r-cmd-login-submit-dis- patch- 5885d80a13c0d.b1f8e26366.3d3fae.e89703d295b4.a2116480e.e013d.2d8494db97095 .b4d80a13c0a2116480.ee01a0.5c536656g7e8z9.real.domain.name.removed?cmd=_home&dis- patch=5885d80a13c0db1f8e&ee=8ae65ec5a442891deac1bc0534a61adb http://paypal.com.real.domain.name.removed/update/?cmd=_home&dis- patch=5885d80a13c0db1f8e&ee=46accb06788060b6e5ae1a1a964d625c † The domain names have been anonymized
4.1.7 Analysis of PhishTank’s statistics
To further expand our research, we visited PhishTank and derived statistics based on the published phishing database. More specifically, we collected the submitted phishing URL’s from January to December 2014, which rounded up to 19826 URL’s. Following, we identified the top 8 phishing campaigns and grouped them together when applicable: Amazon, Apple Services, Ebay, Facebook, Financial Institutions(Banks), Google Services and Paypal. It should be noted that the categorization was based on the results published by Phishtank and
88
Evaluation of browser controls there was no way to verify their validity, as the vast majority of the phishing sites were no longer accessible. Unfortunately, only a small percentage of results were categorized by Phishtank and thus, the analysis was based on this limited data, ignoring any uncategorized URL (marked as “Other” by Phishtank and in the table below). The following tables include the aforementioned elements, categorized both by month and target:
Table 21. PhishTank statistics per month
Apple Financial In- Google Amazon Ebay Facebook Paypal Other Services stitutions Services January 0% 0.47% 0% 0% 1.89% 0.47% 5.19% 91.98% February 0% 0.81% 1.22% 0% 14.23% 1.63% 8.13% 73.98% March 0.20% 0.20% 1.19% 0% 30.04% 0.40% 4.35% 63.64% April 0% 0% 0.09% 0% 29.22% 0.19% 3.04% 67.46% May 0% 0% 0.90% 0% 17.51% 0.30% 3.59% 77.69% June 0% 0.71% 0.71% 0.53% 3.91% 1.07% 3.91% 89.15% July 0% 0.28% 1.97% 0.28% 2.53% 0.84% 8.43% 85.67% August 0% 0.73% 1.61% 0.73% 3.22% 0.88% 9.81% 83.02% September 0% 1.79% 1.62% 0.09% 3.33% 0.68% 6.74% 85.75% October 0.16% 0.59% 1.89% 0.22% 2.16% 0.75% 4.80% 89.43% November 0.02% 0.66% 1.42% 0.21% 1.36% 1.79% 4.27% 90.25% December 0.14% 0.95% 0.91% 0.14% 1.24% 0.63% 10.77% 85.22%
Table 22. PhishTank statistics per category
Category No of URL’s Percentage Amazon 16 0.08% Apple Services 155 0.75% Ebay 241 1.17% Facebook 36 0.18% Financial Institutions 922 4.49% Google Services 188 0.92% Paypal 1495 7.28%
Amazon, Apple 0.08% Services, Ebay, 0.75% 1.17% Facebook, 0.18% Paypal, 7.28% Financial Institutions; 4,49% Google Services, 0.92% Figure 16: Main targets
Based on these statistics, the most popular phishing target was Paypal, with approximately 7.28% of the phishing URL’s targeting the service. Financial Institutions (banks) follow next with 4.49%. This confirms the fact that the prime target for phishers is monetary gain. Ebay
89
Evaluation of browser controls follows with 1.17%. Last but not least, all the other targets (i.e. Amazon, Apple Services, Facebook and Google Services) hold less than 1% each, with the Amazon element to hit the lowest percentage, i.e. 0.08%. Finally, similarly to what we had done with our initial data set, we analyzed all classified URLs in the new data set. Our goal was once more, to identify whether for each targeted service/site, there was a corresponding string in the URL (i.e. if the target was paypal.com we search the URL for the string “paypal”). The following table presents the percentage of URLs which included the target’s string somewhere in the URL. The results support our previous recommendation for performing additional checks on the URL as a means of detecting phishing campaigns.
Table 23. Main phishing campaigns revisited
Category String in URL Amazon 18.75% Apple Services 32.90% Ebay 46.89% Facebook 19.44% Financial Institutions N/A Google Services 23.94% Paypal 40.64%
4.1.8 Discussion
Nowadays phishing is one of the most popular and profitable attacks. Our work reveals that Android and iOS users are not adequately - or sometimes not at all - protected from this threat. More specifically, our work evaluates the anti-phishing protection that is offered by web browsers within a period of two months. The scope of our analysis includes popular browsers in iOS, Android and Windows platforms. We evaluated and manually verified their protection against several thousand phishing URLs. Our results revealed that only a subset of browsers in iOS and Android offer potentially adequate phishing protection, leaving their users exposed to such attacks. For instance, in Chrome Mobile and Opera Mini do not offer anti-phishing mechanisms. In Android, which is currently the most popular smartphone platform, the pre-installed browser (i.e., Browser) does not offer anti-phishing protection. Therefore, Android users who are incompetent and/or reluc- tant to install a third-party browser that offers this protection are exposed to phishing scams. In addition, these users might be unaware of the threat and/or of the browsers that offer the relevant protection. Our results also point out that the anti-phishing protection that is offered by the mobile browsers is not similar to their desktop counterparts. This is true in cases where the same blacklist is used (e.g. in Safari Mobile that uses the Safe Browsing blacklist), and/or the same
90
Evaluation of browser controls browser in different platform (e.g. Opera Mobile and Opera for desktop, Firefox Mobile and Firefox for desktop). To make the matters even worse, our analysis has revealed implementation/design flaws that limit the effectiveness of blacklists usage. For instance, we discovered that Mobile Safari (i.e. the pre-installed browser in iOS) requires a synchronization with iTunes so as to download the latest version of Safe Browsing list. Thus, if users fail to synchronize their devices they will not be alerted when accessing known phishing sites. Moreover, it is more likely that iOS users are unaware that failing to synchronize their device with iTunes lowers their security while they browse the web. In desktop browsers, despite the fact that the popular web browsers included anti-phishing mechanisms, their effectiveness varied significantly. Internet Explorer offers the least protection from phishing attacks, while Opera offers the highest level of protection. Firefox and Chrome offered similar level of protection. The above mentioned findings can be more worrisome if one considers the proliferation of mobile devices. We consider the lack of anti-phishing mechanism on mobile browsers important due to the impact of phishing attack to their users. We thus suggest that all vendors of mobile browsers need to implement protection mechanisms at least as efficient as the ones offered by the desktop browsers. This task is aided by the 'technological convergence' of desktops and mobile devices, as the latter devices gradually offer adequate resources for anti- phishing protection (e.g. blacklist). In the meantime, users of mobile devices can be protected against phishing attacks by installing the third-party web browsers that offer phishing protection and/or rely on filtering proxies.
91
Evaluation of browser controls
4.2 Malware protection
4.2.1 Introduction
Mobile devices and more specifically smartphones and tablets, have become an integral part of our life. Apart from facilitating communication, smartphones are frequently used for a number of sensitive tasks which include online banking and shopping, acting as two-factor authentication tokens for online services, and wireless payments. Furthermore, the use of smartphones in business under the Bring Your Own Device (BYOD) trend is continuously increasing, even in sensitive environments, with iOS and Android devices getting accredited for use in the US Dept. of Defense (Taborek & Capaccio, 2013). Smartphones are now being the primary device used to access the web (Gartner, 2014b). However, while browsing the web users might visit rogue web sites, namely sites that serve malicious software (malware) and/or host phishing scams. It is worth clarifying that users might be exposed to such threats not only when they visit nefarious web sites, such as adult websites, ones hosting pirated software or gambling sites. Benign sites (e.g. social media websites, search engines, news sites, etc.) have been misused in the past to deliver phishing/malware attacks after being compromised (i.e., watering hole attacks) (Cisco, 2013). As a result, the likelihood that users will be exposed to such threats, should not be neglected. In fact, Symantec states that 38% of mobile users have experienced mobile cybercrime in past 12 months (Symantec, 2014a). The malware threat is constantly increasing, with Kaspersky Labs reporting that over 3 billion attacks were detected in 2013, with a total of 1.8 million malicious or potentially unwanted programs used in these attacks (Kaspersky, 2013a). McAfee Labs Threat Report highlighted that there is a 167 percent growth in mobile malware between 2013 and 2014 (McAfee 2014b). The lack of security awareness of mobile users is well known (Mylonas, Kastania, et al. 2013) and this has been confirmed by a recent report that reveals that 57% percent of adults are unaware of the existence of security solutions for mobile devices (Symantec 2014a). This discovery is very worrying if we take into account the sensitive information stored on smartphones as well as their use to access business resources (e.g. accessing corporate emails, files etc.). Most modern operating systems (e.g. Windows 7 and newer, Mac OS X 10.9 and newer) include built-in security features such as a firewall, malware detection software, automated security updates and basic auditing. Thus, even the less security conscious users are enjoying a basic level of protection. Unfortunately, this is not the case for smartphone platforms. Especially for the Android platform malicious applications have found their way even on the official marketplace (Zhou et al. 2012), causing data loss, exfiltration of information and phone charges etc. The availability of endpoint protection software is limited and its effectiveness
92
Evaluation of browser controls questionable. The same is true for the auditing/logging features of mobile platforms. As a result, it is logical to assume that smartphones will be the next APT target, as they offer an easy way to gain access to personal and business data, with significantly less risk of detection for the attackers. Phishing is one of the most popular and profitable attacks as almost 450.000 attacks happened in 2013 with an estimated loss of over $5.9 billion (RSA 2014). In addition, one in every 392 emails contained a phishing attack in 2013 (Symantec 2014a) and to make things worse, 80% of business users were unable to detect phishing attacks effectively (McAfee 2014a). If we take into account the increased exchange of emails on mobile devices (Gartner 2012), users are very likely to access phishing pages on such a device. Although the majority of phishing attacks are widespread and focus on financial gain, targeted phishing attacks also exist. These attacks are known as spear-phishing and have been used in a large number of sophisticated attacks against government, military and financial institutions. The analysis of multiple security incidents has revealed that attackers used targeted phishing attacks in order to gain access to the internal network of their target (Drummond 2010), (RSA 2011), (Virvilis et al. 2013). Web browsers are the first (and unfortunately in some cases the last) line of defense on mobile platforms against such attacks. Although it is unrealistic to expect that targeted phishing/malware attacks will be detected by the web browser or any third party security solution (e.g. Antivirus engine), what is evident from our analysis (see 4.2.4.4) is that the available security mechanisms on smartphones are failing to address even the most basic, non- targeted web threats. Furthermore, their detection efficacy differs significantly when compared to similar mechanisms available on Desktop environments. In the next paragraphs, the most popular browsers on Android and iOS are tested, and their efficacy in blocking phishing and malicious URLs is compared with popular Desktop browsers on Windows. Furthermore, statistics are created for all the malicious files which were downloaded during the tests (when visiting a malicious web site), revealing the disappointing efficacy of Antivirus engines, even against non-targeted malware.
93
Evaluation of browser controls
4.2.2 Experiments and methodology
4.2.2.1 Test methodology
Table 24. Browser availability on tested platforms
iOS Android Windows 7.1.1 4.0.4 7 Safari Mobile X Chrome Mobile X X Opera Mini X X Browser† X Firefox Mobile X Opera Mobile X Chrome X Firefox X Internet Explorer X Opera X
The experiments were conducted in June and July 2014 and focused on the most popular browsers on the desktop and smartphone platforms, namely:
 Desktop browsers. Internet Explorer 11, Chrome v35, Firefox v29, and Opera v22, which were installed on a Windows 7 64-bit system.  Mobile browsers. Safari Mobile (built-in on iOS 7.1.1), Chrome Mobile v35, Opera Mini v7.0, “Browser” or “Internet” (i.e. the default browser for Android 4.0.4), Firefox Mobile v30, and Opera Mobile v22, which were installed on an iPhone 5S (iOS v7.1.1) and a Sony Xperia Tipo (Android v4.0.4). Although some of the desktop browsers have mobile counterparts, their availability on the two smartphone platforms is heterogeneous, as shown in Table 24.
Our effort in the smartphone platform focused on iOS and Android, as these are the two most popular operating systems, comprising almost 90% of the global smartphone market share (Bradley 2013). To evaluate the protection that is offered to users against rogue web sites, 1400 phishing and 1400 malicious URLs were accessed. The ones for which browsers raised alerts, were recorded. As technology that can be used to fully automate this process is not currently available, a security savvy user manually verified if a web page that had not been reported by the browser, was indeed a rogue or a benign web page. Since this was a cumbersome task, the architecture presented in Figure 17, was set up.
94
Evaluation of browser controls
Figure 17: Laboratory setup
Figure 18: Snippet - HTML content
4.2.2.2 Malware Tests
An online, well-known service that reports on a daily basis verified malware-hosting websites, offering strong community support (comparable to PhishTank), is not currently available. Therefore, to gather the malicious URL collection the open source Collective Intelligence Framework (CIF) (CIF 2014) was used. CIF allows the collection and analysis of malicious threat information from a large number of trusted sources, which is used for incident response and intrusion detection and mitigation. Similarly, to the anti-phishing experiment, our tests included manual browsing to 1400 URLs that hosted malicious software. Every URL was categorized as follows:
a) Blacklisted: The browser blocked either the URL or the file that was downloaded (or issued a warning that the file could be potentially dangerous). b) False Negative: A URL that was not blocked by the browser and triggered the download of a potentially malicious file, without any further alert being raised by the browser.
95
Evaluation of browser controls
c) Non-Malicious/Timeout/Error: The URL had either been cleaned or suspended/taken down when it was accessed. This category also included the URLs that did not trigger a download.
Similarly, the dataset for this test included only verified malicious URLs as this work examines the efficacy of browser blacklists in blocking such attacks. As a result, the false positive rate of all browsers, which is out of the scope of this work, was zero.
4.2.3 Experimental Results
4.2.3.1 iOS Browsers
The results revealed that none of the iOS browsers offered any protection against malicious sites, leaving their users exposed to this threat. In the case of Mobile Safari this was rather surprising, as the browser uses Safe Browsing to provide anti-phishing protection, but it does not provide detection of malicious sites. Opera Mini did not utilize any blacklist for the detection malicious sites and neither did Chrome Mobile (not enabled by default and excluded due to the shortcomings that were mentioned previously).
Table 25. Malware protection statistics on iOS
URL Blacklisted False negatives Non-malware iOS Browser Safari Mobile (iOS) N/A N/A N/A Chrome Mobile N/A N/A N/A Opera Mini N/A N/A N/A
N/A: Browser does not support anti-malware mechanisms
4.2.3.2 Android Browsers
The results suggest that Android users are also unprotected against malicious sites. This finding is very worrying if one considers the increasing number of attacks against Android and the exponential growth of Android malware (Kaspersky 2013a), (Zhou & Jiang 2012), (Zhou et al. 2012). Specifically, the pre-installed web browser (“Browser” or “Internet”), Chrome Mobile and Opera Mini offered no protection against malicious sites. As summarized in Table 26, only Firefox Mobile and Opera Mobile utilized malware blacklists. Nonetheless, our results suggest that the level of offered protection was very limited, as they blocked only 10-12% of the malicious URLs.
96
Evaluation of browser controls
Table 26. Malware protection statistics on Android
URL Blacklisted False nega- Non-mal- Android Browser tives ware Firefox Mobile (Android) 139 641 620 Opera Mobile (Android) 166 683 551 Chrome Mobile N/A N/A N/A Opera Mini N/A N/A N/A Browser† N/A N/A N/A
† 'Browser' (or Internet in newer versions) is the pre-installed browser on Android N/A: Browser does not support anti-malware mechanisms
4.2.3.3 Desktop browsers
The results suggest that popular desktop browsers offer poor protection against malicious sites. Internet Explorer (IE) blocked the most malicious sites and was the least prone browser to false negatives, which confirms findings from similar research conducted by the industry (Abrams et al. 2013). Nevertheless, even though IE outperformed all the other browsers, it only blocked ~41% of the malicious URLs and had a 30% of false negatives. This highlights that the application reputation mechanism that is used by IE does offer an extra line of defense against malware, but is far from perfect. Chrome had more false negatives than IE, even though it offers a similar mechanism against malicious downloads. Opera ranked third in terms of blocking malicious sites, but had 58% of false negatives, the highest in the experiments. Firefox offered the poorest protection, blocking only 5% of the malicious URLs and having a ~43% of false negatives. During the experiments Firefox and Opera blocked malicious sites only by examining their URLs, without analyzing the downloaded files. Newer versions of Firefox now analyze the downloaded files using the same technology as Chrome (Mozilla 2014).
Table 27. Malware protection statistics on Windows
URL Blacklisted False negatives Non-malware Browser Firefox 70 729 601 Chrome 280 552 568 Opera 180 816 404 Internet Explorer 573 420 407
97
Evaluation of browser controls
4.2.4 Secure Proxy
The results uncovered three problems that must be addressed to protect users from rogue sites:
a. The limited effectiveness of blacklists against malicious sites and phishing sites. b. The limited effectiveness of reputation based mechanisms (e.g. in Internet Explorer and Chrome) to block malicious downloads. c. The unavailability of the relevant security controls in popular mobile browsers.
In this context, Secure Proxy is proposed and implemented, as a proof-of-concept security mechanism, which proves the efficacy of aggregating multiple data sources in the detection of rogue sites. Currently, and due to the heterogeneity and restrictions of smartphones and their security models, a different security control might be incompatible (e.g. due to the limitations enforced by iOS) or infeasible to be implemented due to resource restrictions (e.g. on older Android smartphones). The proposed proxy is browser and platform agnostic (i.e. does not require the installation of third party software) and can protect the user, regardless of the browser she is using. Finally, and in contrast with the commercial and closed source content filtering solutions, we are proposing an open architecture which can be built with a fraction of the cost.
4.2.4.1 Architecture
A secure forward HTTP proxy has been implemented, which uses VirusTotal’s public API to analyze the requested URLs and downloaded files. VirusTotal was selected due to (a) its popularity, (b) the number of AV engines and blacklist providers that it offers, and (c) the availability of free API. Nevertheless, any other similar service could be used. The proxy queries VirusTotal for each requested URL to identify if the URL is blacklisted by any of the blacklist providers. If the URL is blacklisted, the request is blocked and a warning message is returned to the user. Otherwise, the proxy returns the HTTP response (i.e. page contents) to the browser. If a download is triggered, the proxy calculates the SHA-256 hash of the file and queries VirusTotal. Once more, if the hash is known and is reported as malicious by any AV vendor, then the download will be blocked and a warning will be raised. If the hash is unknown (i.e. the file has not been analyzed beforehand), then the proxy uploads the contents of the file for analysis and allows the user to download the file if it not flagged as malicious by the AV engines. These steps are summarized in Figure 19.
98
Evaluation of browser controls
4.2.4.2 Secure proxy evaluation
The evaluation of Secure Proxy focused on the detection of malicious sites, as the majority of browsers provide only weak protection (or hardly any) against them. The proxy was also tested with the complete collection of phishing URLs from PhishTank. However, this test was only a verification of the correct operation of Secure Proxy, as PhishTank is one of the anti- phishing providers that is used by VirusTotal.
Figure 19: Proposed architecture
To evaluate Secure Proxy the same list of malicious URLs that the browsers were tested against on a daily basis was accessed, and the requests were redirected through the Security Proxy. A script that simulated the web requests was used instead of a browser, to make sure that no browser specific countermeasure would interfere with the results, as well as to automate this process. The number of blocked URLs were collected and compared with the results of the browser that achieved the highest blocking rate in our evaluation. Secure Proxy was configured to block downloaded files (either based on the hash or the actual file analysis), when the number of detections reported by VirusTotal were at least one. This parameter is configurable and it can be configured to block a request with a different blocking threshold, according to the existing security policy or risk appetite.
99
Evaluation of browser controls
Statistics were also collected regarding: (a) the number of URLs that were blocked due to URL-only analysis, (b) the number of downloads that were blocked due to hash analysis, and (c) the number of downloads that were uploaded and blocked by VirusTotal.
Table 28. Percentage of blacklisted malicious sites - Secure Proxy vs. Internet Explorer (n=1400)
Secure proxy Best browser (Internet Explorer)
53.2% 40.9%
4.2.4.3 URL-only and hash-based analysis
As summarized in Table 28, the use of multiple blacklists enabled Secure Proxy to block almost half of the malicious URLs - thus outperforming Internet Explorer by 12.3% - which was the browser that blocked the most malicious URLs. This finding highlights that while the aggregation of multiple blacklists provides higher protection than any individual browser, it still fails to detect almost half of the malicious URLs (i.e. 46.8% false negatives). Browsing to these URLs triggered the download of 460 unique files (based on their SHA- 256 hash), all of which were PE executables. Secure Proxy downloaded these files and queried VirusTotal for their hashes. The results revealed that 57.3% of the submitted hashes (i.e. 264 out of 460) were unknown to VirusTotal, meaning that the files had not been submitted for analysis beforehand. The detection rate of the rest of the files is summarized in Figure 20 (for detailed results see Table 15 in the Appendix). The number of AV engines that are available during the analysis of a file in VirusTotal ranges between 49-54 antivirus engines. Figure 20 summarizes the results based on the detection ratio for each file. This ratio was calculated with z/n, where z represents the number of antivirus engines that flagged the file (hash) as malicious and n is the number of antivirus engines that were used. The results indicated that the detection rate of approximately half of the malicious files was in the range of 6-38% of the antivirus engines. Moreover, only the 27.4% of the malicious files were detected by the majority of the antivirus engines.
100
Evaluation of browser controls
Figure 20: Detection percentage of hashes (X-axis lists the percentage of AV engines that flagged the file as malicious, Y-axis lists the percentage of the samples).
4.2.4.4 File-based analysis
During the experiments, Secure Proxy uploaded 264 (57.3%) of the downloaded files to VirusTotal for analysis, as their hashes were unknown. All of them were reported as malicious and the majority of them (~71.0%) were detected by 46-50% of the antivirus engines. This suggests that with the absence of file-based analysis from Secure Proxy, there is ~50% likelihood that malicious files will not be detected from the user’s AV (assuming that the user is using only one AV program). Finally, it should be highlighted that the abovementioned detection rates refer to desktop antivirus engines. Mobile antivirus applications are more constrained due to the sandboxed environment of mobile platforms and also lack the advanced features that are available at desktop antivirus engines (i.e. advanced heuristic analysis).
101
Evaluation of browser controls
Figure 21 - Detection percentage of executables (X-axis lists the percentage of AV engines that flagged the file as malicious, Y-axis lists the percentage of the samples).
4.2.4.5 Performance evaluation
As mentioned beforehand, Secure Proxy performs three types of queries to VirusTotal, which incur delays: (a) URL Query to identify if the URL is reported as rogue by any of the blacklist providers, (b) Hash Query to identify if the hash of the file is known to be malicious, and (c) File Query in which the actual file is uploaded to VirusTotal for analysis. The analysis revealed that for URL Queries the proxy received a response from VirusTotal and allowed or blocked the request on average in 648ms. The average Hash Query time for each triggered download was 516ms. The longest delay occurs when the hash is unknown as the file needs to be uploaded for further analysis (File Query). The delay depends on various parameters, e.g. the size of the file, the network speed, and the load on the VirusTotal service - with the latter often being the most time consuming parameter. In the evaluation, the average size of the collected malicious executables was 848KB and our Internet connection was a 20Mbit (2048Kbit upload) ADSL line. On average, the file queries were completed in under 41sec, including the time required to upload a file and get the detection report.
4.2.5 Discussion
4.2.5.1 Limitations
The corpus was limited to 2800 rogue URLs (1400 phishing and 1400 malicious URLs), due to the significant manual effort that was required to test different browsers on Windows, iOS and Android. This introduced a potential bias in the results, which describe the level of protection in the period that the tests took place, namely June-July 2014. However, even though the results are not generalizable, it is our belief that they provide adequate indications about the level of protection offered to the users for two reasons: a) the findings for desktop browsers are
102
Evaluation of browser controls in accordance with the results in (Abrams et al. 2013) and b) the results of this work regarding the effectiveness of anti-phishing protection are similar to our previous evaluation of a much larger data set of 5651 URLs (Virvilis, Tsalis, et al. 2014). This work focuses only on the popular desktop browsers (Windows) and their smartphone counterparts that are available on iOS and Android. While there are other browsers that were not examined, such as Safari on Mac OS X and Internet Explorer Mobile on Windows Phone, the current results are considered as representative. This holds true as Windows is the most popular operating system for desktops and laptops, as well as Android and iOS users constitute the 94% of the smartphone users (78.4% and 15.6% respectively) (Gartner 2013). In addition, as iPads and Android tablets use a similar operating system (iOS, Android), and in most cases the exact same browser versions, the findings are considered to reflect the protection that is offered on a larger user base. In this work Secure Proxy was proposed, as a countermeasure against rogue sites. It is worth noting that the implementation is a proof-of-concept one, highlighting the benefits that the aggregation of multiple blacklists and AV engines offers against rogue websites. The evaluation regards issues such as privacy or performance as out of scope of this work. However, as discussed in section 4.2.5.2, both issues can be addressed in a real-world implementation. The implementation of Secure Proxy is based on the public version of VirusTotal’s API, which introduces limitations. Firstly, VirusTotal is a service which was not designed to support semi-real time queries, as the ones used by the proposed control. A dedicated service optimized for such use, such as CloudAV (Oberheide et al. 2008), might achieve better performance and as it can be hosted locally, it avoids privacy concerns. Also, Secure Proxy - similarly to VirusTotal - does not weight differently the responses from the various antivirus engines or URL blacklists. It can be extended to assign different weights to these responses according to organization’s security policy. Finally, the results are affected by the dynamic nature of the web ecosystem. This is due to the dynamic nature of the threats and the new evasion techniques that attackers create. This is reflected on the comparison of the anti-phishing protection that is offered by the examined browsers in Q1 and Q2 (2014). Moreover, browsers add to the complexity of the evaluation due to their frequent updates, which might include new security controls (e.g. analysis of downloaded files is now supported in newer versions of Firefox).
4.2.5.2 Protection of desktop and mobile browsers
Overall, the results revealed that desktop browsers performed better in comparison to their smartphone counterparts, both against phishing and malicious sites. This is a worrisome finding if we consider the proliferation of smartphones, as well as the increased web browsing with
103
Evaluation of browser controls these devices. One could argue that this is expected, as smartphones lack the processing capabilities of desktops and laptops. Nonetheless, this is only partly true today, as most smartphones have similar resources as a 3-4 year old laptop (e.g. dual core CPU, 1-2 GB or RAM, etc.). In addition, work by (Mylonas, Gritzalis, et al. 2013) has shown that the unavailability of important security controls - such as blacklists for phishing and malicious sites in which this paper focuses - does not stem from the (API) restrictions that are imposed from the smartphones operating system (i.e. sandbox profile). The reason that this happens is still unclear; however, it falls out of the scope of this work. More specifically, the results revealed that only a subset of the mobile browsers offer anti- phishing protection and thus, their users are not protected from such attacks. This is particularly true for Android users, where the pre-installed browser does not offer anti-phishing protection. On iOS, the pre-installed browser offers anti-phishing protection, but its effectiveness is questionable (c.f. Section 4.2.3.1). On the contrary, all desktop browsers provided anti-phishing protection, even though their effectiveness was significantly different and blacklist synchronization issues were identified for Firefox on Windows. Figure 22 summarizes the results of the anti-phishing experiments.
Phishing URL Detection
Blocked False Negatives Non Phishing 93.0% 77.9% 86.7% 75.9% 85.4% 48.4% 41.7% 38.7% 34.9% 16.3% 26.4% 9.9% 8.4% 13.7% 1.3% 5.7% 5.9% 7.3% 7.9% 3.4% 11.1%
IE (Windows) Opera Chrome Firefox Opera Mobile Firefox Mobile Safari Mobile (Windows) (Windows) (Windows) (Android) (Android) (iOS)
Figure 22: Phishing URL detection percentage
Contrary to anti-phishing protection, the results suggest that both desktop and mobile browsers offer very limited protection against malicious URLs (Figure 23). While Internet Explorer and Chrome, which used application reputation mechanisms, blocked more malicious URLs/resources than other browsers, their detection rate was still low. Moreover, only a subset of the browsers on iOS and Android offer any protection against malicious URLs - the browsers that did not block phishing URLs also did not block malicious URLs. Interestingly, Safari Mobile did not block malicious URLs, even though it uses Safe Brows- ing to offer anti-phishing protection. Apple may have assumed that using such a blacklist would not increase the level of protection for iOS users, based on the fact that iOS devices only execute code signed by Apple. This assumption seems flawed as: (a) a significant percentage of users jailbreak their iOS devices, thus the device can also execute unsigned code (Love 2013), (b) if iOS users do not receive any warning when visiting a malicious site, they can unwillingly put
104
Evaluation of browser controls other users at risk by forwarding/sharing the URL, and (c) files that are downloaded on an iPhone might be synchronized to a computer, resulting to its infection.
Malicious URL Detection
Blocked False Negatives Non Malicious
58.3% 48.8% 52.1% 45.8%44.3% 40.9% 42.9% 39.4% 39.4% 40.6% 30.0% 29.1% 28.9% 12.9% 20.0% 11.9% 9.9% 5.0%
Opera Mobile Firefox Mobile IE (Windows) Opera Chrome Firefox (Android) (Android) (Windows) (Windows) (Windows)
Figure 23. Malicious URL detection percentage
4.2.5.3 Proposed countermeasure
To raise the bar of protection that is offered to users against rogue sites Secure Proxy was proposed, implemented as a proof of concept and evaluated. Secure Proxy is a HTTP forward proxy that uses multiple anti-phishing and anti-malware blacklists. Our work suggests that such browser agnostic architectures are currently the only solution for protecting normal (i.e. not security savvy) smartphone users, as they are less likely to install third-party browsers or security products on their devices (Mylonas, Kastania, et al. 2013). The evaluation showed that Secure Proxy blocks more rogue URLs and is less prone to false negatives than any individual browser. Our work focused on reducing false negatives, i.e. active phishing or malicious URLs that were not blocked by the browsers, as they could result in a successful attack. Secure Proxy however, may be prone to false positives as some sites may have erroneously been added to a blacklist without proper verification. In this case, a URL might be blocked until it is removed from all blacklists causing a temporal nuisance to users. Nonetheless, popular blacklists (e.g. Safe Browsing) allow site administrators to request their site’s removal from a blacklist when it has been cleaned, which would reduce the inaccessibility time. Furthermore, Secure Proxy can be configured, based on the user’s or organization’s risk appetite, to block a URL if the number of blacklists that identify it as malicious exceeds a threshold, thus reducing potential false positives. However, specifying this threshold falls outside the scope this work. Similarly to Internet Explorer’s and Chrome’s metadata analysis of the downloaded files, Secure Proxy offers hash-based analysis with the aggregation of multiple AV engines. In specific, it queries the file’s hash on VirusTotal and blocks its download if it is reported as malicious by at least one AV engine – similarly to URL-only analysis this threshold is configurable. The results prove that hash-based analysis adds an extra layer of protection against malicious sites and - as URL-only analysis - does not introduce significant delays.
105
Evaluation of browser controls
The benefit of online queries is that the URL or hash will always be checked against an up- to-date blacklist, avoiding any blacklist synchronization issues. In addition, using a browser agnostic countermeasure, such as Secure Proxy, enables the end user to use a browser that does not offer any built-in countermeasures and still be protected. Finally, it also allows devices with limited resources (e.g. smartphones) to avoid resource intensive operations and thus reduces energy consumption. The inherent drawback of any online, centralized architecture is user privacy. Each visited URL is submitted to a third party for analysis, thus exposing the users’ browsing history/profiles. Even though this falls outside the scope of this work, it can be mitigated by maintaining a local blacklist/whitelist, thus avoiding the need for a central architecture (e.g. as in our case, a proxy server) - similarly to the way Safe Browsing protocol works. The browsers that implement the protocol, keep a local database of reported URLs, which is updated frequently while the browser is running. As a result, all lookups use the local database, thus avoiding unnecessary delays and privacy issues. Based on the fact that VirusTotal is owned by Google, it seems fairly easy to include the aggregated results from all blacklist providers to a single list (e.g. imported into Safe Browsing list). Still, this will require the browser vendors to implement/adopt the Safe Browsing protocol and make sure that they avoid any synchronization issues. Another potential solution could be to host a service similar to VirusTotal locally e.g. CloudAV (Oberheide et al. 2008), which would also address the privacy issues. The tests have also revealed the significant benefit of aggregating multiple AV engines for the detection of malicious files. Secure Proxy uploads for further analysis all downloaded files for which a hash-only query returned no results. This analysis introduces delays (41 sec on average in our experiments), which may not be acceptable for some users. However, Secure Proxy can be configured to upload these files according to a policy, e.g. by default deny access to these files, move the files in a sandbox or ask the user to decide whether the files will be submitted for further analysis. The last option however assumes users’ security awareness, which might not be the case for all users, as they are known to click through security messages (Akhawe & Felt 2013), (Egelman & Schechter 2013), (Mylonas, Kastania, et al. 2013), (Mylonas, Gritzalis, et al. 2013). Similarly to other instances in the security domain, there is a tradeoff between security and usability. A combination of a whitelist and reputation based system will further limit the number of files that have to be submitted for analysis - as only files that are not included in the whitelist and are not blocked by the reputation system have to be analyzed. Nevertheless, the benefits of such detailed analysis are significant. This holds true as the results suggest that even if an AV engine is in use, it will fail to detect all malicious files (in our experiments on average an AV detected only half of the malicious files). On the contrary, Secure Proxy offered better
106
Evaluation of browser controls anti-malware protection due to the aggregation of multiple AV engines and blocked all the malicious files in the corpus. Finally, it should be noted that the focus of Secure Proxy is to allow mobile users to achieve a comparable level of protection with the one offered to desktop users, regardless of the limitations imposed by the mobile platform or browsers. However, as this countermeasure is based on the aggregation of Antivirus engines, the shortcomings of which have been raised both in this chapter as well as in the bibliography (Cole 2012), (Schneier 2012), it should not be considered effective against targeted attacks. For the latter, different detection techniques such as the ones presented in the next chapter, have to be investigated.
107
Evaluation of browser controls
4.3 Private browsing
4.3.1 Introduction
Since Internet penetration has risen in the last years (almost 3.4 million users by the end of 2015 (Internetworldstats, 2016) it is important to preserve an adequate level of privacy to protect the average user while browsing the web. Average users, i.e., those who are not technical, nor security savvy, rely on the default security countermeasures that are provided by the popular web browsers, such as protection from sites serving malware or hosting phishing attacks. However, previous work has revealed that the actual protection that this control offers is rather limited (Virvilis et al., 2014), (Tsalis et al., 2015a), (Virvilis et al., 2015), (Tsalis et al., 2015b) and (Mylonas et al., 2013). Private browsing is a security control that is implemented by all popular web browsers, in order to provide enhanced privacy to the end user while browsing the web (Google, 2016a), (Google, 2016b), (Mozilla, 2016), (Microsoft, 2016a) and (Opera, 2016). Its primary goal is to protect the confidentiality of users’ data, which are generated in a private browsing session, by avoiding to store them in the file system. In contrast, when the user is not under a private session (hereinafter this paper will refer this mode as normal mode), the data that are generated while the user is browsing the web are stored in the filesystem for usability (e.g., facilitate authentication) and efficiency reasons (e.g., caching). Thus, private browsing can aid users to protect their privacy, against a local attacker who has access (temporal or permanent) to the user’s device and attempts to uncover their online activities. After the revelations of state sponsored mass surveillance by Edward Snowden (BBC, 2016), average users are concerned, more than ever, about protecting their privacy. In a recent survey (Gao et al., 2014), 200 people were asked about the use of private browsing. Nearly half of them (39.5%) stated that they use private browsing, so as to prevent their browsing history and any cookies from being saved. This paper, examines the protection that is offered by private mode in popular web browsers, i.e., Chrome, Firefox, Internet Explorer and Opera. A specific set of web artefacts was surveyed, which are typically created in a normal browsing session, to uncover if and where these are stored after the private session is terminated, contrary to the browser’s documentation. Therefore, this work uncovers the deficiencies of the private browsing mode in web browsers and the respective privacy violations. In addition, to estimate the impact of the findings, a user survey was performed so as to note user opinion, based on the tested artefacts and their importance. Lastly, this work proposes the use of a virtual filesystem as a countermeasure against the privacy violations that have been uncovered. The rest of the paper is structured as follows: Section 4.3.2 includes our methodology. Section 4.3.3 contains the test results. Section 5 presents our case study. Finally, Section 4.3.8 adds a discussion and concludes our work.
108
Evaluation of browser controls
4.3.2 Methodology
The scope of this current analysis includes the popular desktop browsers (see Table 29)19 for Windows, i.e., Chrome v. 47, Firefox v. 43, Internet Explorer 11 and Opera v. 34. Windows 7 was selected as it was -- at the time of the writing of this paper -- the operating system with the largest user base (43.1% of the market share according to (W3schools, 2016b)). This work assumes that a user browses the web with a desktop browser in which the attacker has temporal physical access (e.g., Internet cafe, shared desktop). The user wishes to protect the details of her browser session and as such, she browses the web with private mode enabled and quits the browser without shutting down the workstation. It is also assumed that the attacker does not possess any forensic skills or tools, but is able to find any traces of the user’s online activity by simply browsing the filesystem. In this context, all the aforementioned browsers are used in private mode to evaluate whether they indeed provide the documented protection against privacy violations. To identify whether any traces of the user’s online activities remain after a private session, each browser was executed in private mode and online activities were performed. More specifically, we assume that the user in her private session performs online activities that will create the artefacts of Table 30. For instance, when she visits a website, bookmarks it and downloads a file, then those actions will create artefacts regarding: bookmarking, browser cache memory, browsing history, cookies, download list and downloaded files.
Table 29 – Browsers’ user base (February 2016, (W3schools, 2016a)) Browser User base (%) Chrome 69.0% Firefox 18.6% Internet Explorer 6.2% Opera 1.3%
Any changes to the filesystem as a result of these online activities were automatically monitored. The online activities that were performed aimed to create data which are typically left behind during a normal browsing session (see Table 30). More specifically the artefacts that were generated can be classified as: (a) generic artefacts (Aggarwal et al., 2010), which is a set similar to the set of protected data sources compiled from the browsers’ documentation pages (c.f. Table 31) and include simple browsing activities (e.g., bookmarking a webpage, downloading a file, etc.), (b) browser artefacts, which describe changes in the browser itself (e.g., installing a digital certificate, modifying browser settings) and (c) website artefacts, which include per site configurations, such as website translation or website zoom.
19 Apple offered a Safari for Windows but it was excluded from the analysis as it has been discontinued since 2012 (Apple, 2016).
109
Evaluation of browser controls
Table 30. User activity categorization. Generic artefacts Browser artefacts Website artefacts Auto-complete elements Add-ons / Extensions Permissions Bookmarks Certificates Translation Browser cache memory Plugins Zoom level Browsing history Settings - Cookies - - Download list - - Downloaded files - - Passwords - - Search terms - -
Table 31 summarizes the set of artefacts that were examined by the authors of the relevant literature (see Section Error! Reference source not found.). To the best of our knowledge, no other work in the literature focuses on the superset of all the artefacts that we have tested (see the related work section). The majority of works in the relevant literature focuses on a subset of artefacts only, except for the work of Xu et al. (2015). Lastly, to measure the impact of the corresponding findings, a survey was conducted that measured user awareness. Specifically, the survey collected the users’ opinion about private browsing mode, and measured the impact of a privacy violation concerning the artefacts of Table 30. For readability reasons, the questionnaire that was used in the survey is available in the Appendix A.
Table 31. Artefacts tested by authors
Artefacts
2015) 2013)
(Xu et al., 2015) al., et (Xu 2011) al., et (Oh
(Said et al., 2011) al., et (Said
(Ruiz et al., 2015) al., et (Ruiz
(Satvat et al., 2014) al., et (Satvat
(Aggarwal et al., 2010) al., et (Aggarwal
(Montasari and Peltola, Peltola, and (Montasari
(Ohana and Shashidhar, Shashidhar, and (Ohana
Generic artefacts Auto-complete elements x x Bookmarks x x x x Browser cache memory x x x x x x Browsing history x x x x x x x x Cookies x x x Download list x x Downloaded files x x x x x Passwords x x Search terms x x x x Browser artefacts Add-ons / Extensions x
110
Evaluation of browser controls
Artefacts
2015) 2013)
(Xu et al., 2015) al., et (Xu 2011) al., et (Oh
(Said et al., 2011) al., et (Said
(Ruiz et al., 2015) al., et (Ruiz
(Satvat et al., 2014) al., et (Satvat
(Aggarwal et al., 2010) al., et (Aggarwal
(Montasari and Peltola, Peltola, and (Montasari
(Ohana and Shashidhar, Shashidhar, and (Ohana
Certificates x x Plugins Settings Website artefacts Permissions Translation x Zoom level x x
The browsers were monitored inside a virtual running Windows 7. Every browser was installed using the default installation settings in a different snapshot of the virtual machine. This initial clean state of the analysis environment was retained and was restored if needed in the analysis. As a result, this setup avoided any instances of cross contamination issues during the analysis. To monitor any changes in the filesystem and the registry that occurred during the private sessions, all the relevant events created by the process of each browser were collected, in the same way dynamic malware analysis is conducted (Sikorski & Honig, 2012). To this end, bat scripts were facilitated that used process monitor v. 3.2 (Microsoft, 2016c), for the collection and parsing of all the modifications (events) occurred by the browsers’ process.
4.3.3 Results
4.3.3.1 Browser documentation
The documentation for each browser was enumerated regarding the protection that is offered by each private mode. It is worth clarifying that each browser refers to this control differently, namely: incognito and guest mode in Chrome (Google, 2016a; 2016b), private mode in Firefox (Mozilla, 2016), InPrivate mode in Internet Explorer (Microsoft, 2016a) and private mode in Opera (Opera, 2016). Even though all the examined browsers offer this documentation online, this documentation is rather limited. More specifically, only Firefox and Internet Explorer provide adequate documentation regarding the protection of almost all the artefacts that are in the scope of the analysis. The rest of the examined browsers have a very limited documentation regarding this control, especially Chrome that provides as little as one simple sentence regarding private mode.
111
Evaluation of browser controls
In addition, web browser users can get additional information regarding the private browsing within their browser. Specifically, when a user opens a new window in private mode, a welcome page is presented that informs the user regarding private mode and redirect the user to the official documentation page. However, the user can be confused from inconsistencies between the information for this control which is available in the online documentation and these welcome pages: Chrome (incognito mode) does mention the deletion of cookies, something that is not available in the online documentation, as well as there is no information about the protection of downloaded files. Firefox does not mention anything about passwords. Internet Explorer states that the extensions are disabled, which is something that is not available in the online documentation. Finally, Opera provides a generic message that states “all the information connected with them will be erased”, which is rather vague (and invalid, as will be proven).
112
Evaluation of browser controls
Table 32 includes only the artefacts mentioned in the documentation, while using the following notation:  is used when the documentation states that the artefact is available after private mode,  when it is not and “-” when the documentation does not include any information about that specific artefact.
113
Evaluation of browser controls
Table 32. Browser documentation regarding private mode Chrome Fire- Internet Ex- Artefact / Browser Pri- Opera Guest fox plorer vate Add-ons / Extensions - - - * - Auto-complete form - -   - data Bookmarks - -  -  Browser cache - -    memory Browsing history      Cookies *     Download list - -  - - Downloaded files  -  -  Passwords - -    Search terms - -   -
There is no consensus regarding the data that should be protected. In fact, each browser selects a different set of artefacts to protect. For instance, Opera does not protect the passwords that are created in a private session whereas Firefox and IE do. Chrome do not document the absence or the protection of this data.
4.3.4 Browser data sources
4.3.4.1 Summary of modifications in the filesystem
By monitoring the events that were created by each browser process, all the interactions with the system were identified. Table 33 summarizes the total interactions with the filesystem that occurred, with a breakdown of whether the browser created, deleted, or changed the attributes of a file or folder. One would consider that during a private session only a few or none changes should occur to the system. However, the results invalidate this assumption.
114
Evaluation of browser controls
Table 34 summarizes the paths in the filesystem in which these modifications occurred.
Table 33. Total interactions found in the filesystem during the private mode Chrome Internet Ex- Action / Browser Firefox Opera Private Guest plorer Create 20 161 62 100 99 Modify 34 28 24 13 20 Delete 2 2 2 2 2 Total actions 67 202 94 116 125
115
Evaluation of browser controls
Table 34 – Paths that were modified in the filesystem.
Browser Data source location
AppData\Local\Google\Chrome\User Data\Default
Chrome AppData\Local\Google\Chrome\User Data\Local State incognito AppData\Local\Google\Chrome\User Data\ShaderCache
HKEY_LOCAL_MACHINE\software\microsoft\SystemCertificates
AppData\Local\Google\Chrome\User Data\Default Chrome AppData\Local\Google\Chrome\User Data\Guest Profile guest AppData\Local\Google\Chrome\User Data\System Profile\databases
AppData\Local\Mozilla\Firefox\Profiles\nyaofkb5.default Firefox AppData\Roaming\Mozilla\Firefox\Profiles\nyaofkb5.default
AppData\Local\Microsoft\Feeds
AppData\Local\Microsoft\Internet Explorer
AppData\Local\Microsoft\Windows Internet AppData\Local\Temp Explorer AppData\LocalLow\Microsoft
AppData\Roaming\Microsoft\Internet Explorer
HKEY_LOCAL_MACHINE\software\microsoft\SystemCertificates
AppData\Roaming\Microsoft\Windows
AppData\Local\Opera Software\Opera Stable Opera AppData\Roaming\Opera Software\Opera Stable
HKEY_LOCAL_MACHINE\software\microsoft\SystemCertificates
4.3.4.2 Location and analysis of artefacts
When a user browses the Internet, she performs specific activities, which generate artefacts based on the type of the performed activity. For instance, when the user bookmarks a website this action creates a new entry in the files which are used by the browser to store browsing data. Thus, if these entries are retrievable after the private session they constitute a privacy violation, revealing the user’s browsing actions.
4.3.4.3 Generic artefacts
The analysis revealed that during a private session none of the browsers allow the user to save auto-complete form data and, with the exception of Opera, passwords. Opera in particular allows the user to store passwords in private mode (see Figure 24). Also, the username is stored in the “LoginData” file, but the password is only visible via the browser itself (i.e., following the path in the browsers interface Settings  Privacy & Security  Manage Saved Passwords
116
Evaluation of browser controls
 Show). Session cookies and search terms do not remain in the filesystem after the private session.
Figure 24: Snapshot of password artefact in Opera
The analysis revealed that all browsers protect the “download list” artefact, i.e., all the browsers do not keep the list of files the user downloaded during the private session. However, as these files remain in the filesystem (see Table 35) the compilation of this list is straightforward. This holds true as, all the downloaded files can be found in the download folder of each browser after private mode, unless the user manually deletes them. As summarized in Table 35, the bookmarks that are created during a private session remain in the filesystem, with the exception of Chrome’s guest mode that disallowed the creation of bookmarks. More specifically, in Firefox bookmarks are stored in the “places.sqlite” database, along with the creation timestamp of last access as shown in Figure 25. In Chrome, bookmarks are saved in the “bookmarks” file (
Figure 26), along with their creation and/or modification timestamp. Similarly, in Opera, bookmarks are saved in the “bookmarks” file in the browser’s directory (
117
Evaluation of browser controls
Figure 27). Lastly, Internet Explorer places the bookmarks in the Windows “favourites”
folder ( Figure 28).
Figure 25: Snapshot of bookmark artefact in Firefox
Figure 26: Snapshot of bookmark artefact in Chrome
Figure 27: Snapshot of bookmark artefact in Opera.
Figure 28: Snapshot of bookmark artefact in ΙΕ
While all browsers attempt to delete the browsing history after the private session, the analysis revealed that it can be inferred from browser’s cache memory and bookmarks in Firefox and Chrome. Specifically, when a user bookmarks a webpage Chrome and Firefox store additional data about the bookmarked website, which reveal that the activity was performed during
118
Evaluation of browser controls private mode. Chrome creates a new profile page in the history database and it marks the hidden field with a “1” (Figure 29), which suggests that the bookmark was created in private mode. Similarly, Firefox creates a new entry in the moz_bookmarks field of the places.sqlite file (Figure 30). This entry contains a unique id, which correlates with the moz_history_visits field of the same file (Figure 31) and indicates the visit.
Figure 29: Snapshot of bookmark artefact revealing Chrome’s history
Figure 30: Location of bookmark artefact in moz_bookmarks
119
Evaluation of browser controls
Figure 31: Website visit id in moz_history_visits
Finally, in almost all browsers the cache memory does not remain after the private session. In Firefox however the ocsp responses remain in the browser’s cache folder. The ocsp protocol is used by the browser to check the validity of a digital certificate (Santesson et al., 2013), but as shown in Figure 32 leaks part of the user’s browsing history.
Figure 32: OCSP responses’ snapshot in Firefox cache memory
4.3.4.4 Browser artefacts
When a user modifies or views the browser’s settings, she is redirected to the same settings window that is used in normal mode. As a result, any changes in the browser’s settings will still be available after private browsing is terminated. Note that this applies to all of the tested browsers except Chrome’s guest mode, where the user can only configure the browser’s search engines.
Figure 33: Snapshot of Chrome’s guest settings
Furthermore, while Chrome’s guest mode offered very limited access to the browser’s settings, a user can manually access them via manually browsing to chrome://settings/content. Note
120
Evaluation of browser controls that the user can even update Chrome via the guest mode, by visiting the “about” field. These settings, except for the browser update, only apply to the guest mode and the changes are not available in normal mode. In contrast, these are available in the preferences file in Google’s Guest profile folder. Thus, the user can manually visit and change the settings, which may result in revealing specific artefacts. For instance, if the user modifies the content settings and blocks the cookies from a specific website, this will still be available after the private session, and thus reveal the corresponding browsing activities.
Figure 34: Snapshot of Chrome’s guest content settings
All browsers deactivate add-ons / extensions by default in private mode, with the exception of Chrome’s guest mode, which does not allow their use. Although disabled, the user has the ability to navigate to the corresponding add-ons/extensions panel and make them available in private mode. More specifically, the user can view, modify and delete existing ones, or even install new ones from the browser’s repository. These will be available in normal mode, along with any changes in their settings. Thus, if she installs an add-on which is specific to one of the tested artefacts (e.g., history - ad-blocker), this will result in disclosing the user’s activities performed (e.g., blocked website), since the change will also be available during normal mode. As a result, the blocked website will remain in the installed add-on and it is straightforward to infer that this website was visited (i.e., history) While in private mode the user is able to delete existing certificates and add new ones. For instance, when a new certificate is added to Firefox, a new entry is created in the “cert8.db” file, while the same applies to the remaining browsers which use the system’s certificates. And since the certificate includes the corresponding website, the user’s history is available, as far as websites with certificates is concerned. During the analysis, only Chrome’s guest mode does not offer the functionality to access the system’s certificates. Similarly, the user can access the browser’s plugins, through the settings panel in any browser, which is already discussed earlier. Thus, any changes will still remain in normal mode in all browsers (why is this important). It should be noted that in the case of Chrome’s Guest mode, any changes in these settings only apply to the guest profile and are stored in the preferences file in Google’s Guest profile folder.
121
Evaluation of browser controls
4.3.4.5 Website artefacts
Both in normal and private mode, the user has the option to set settings that are valid or a specific web page/domain. These settings are referred as permissions and define how the browser will present specific content, such as images. Firefox is the only browser that groups these settings together in a panel, while the rest browsers allow a user to modify them either by visiting the “settings” panel, or by configuring them in an ad-hoc manner. For instance, full screen is set with a pop-up message. Note that in Chrome’s guest mode, the changes are only available while guest mode is enabled, but are stored in the “preferences” file. Thus, since the permissions operate at a per-website basis, any change will include the website itself in the above mentioned file and as a result expose the “history” artefact. Similarly, Chrome, Internet Explo- rer and Opera store these changes in their default folders (as depicted in Table 35), while Firefox uses the “permissions.sqlite” file.
Figure 35: Snapshot of permissions artefact in Firefox
All browsers except for Firefox and Opera allow the user to translate a webpage or choose to never translate a web page. The analysis has revealed that this action in Internet Explorer does not leave any traces in its preferences folder. More specifically, the browser uses bing.com, which is automatically visited when the user translates a website. Thus, traces regarding this action can only be found in the DNS records (Figure 36), where the translated website is also included. In contrast, in Chrome (in both incognito and guest mode) user’s translation preferences are stored in the “preferences” file, which is available in each mode’s folder. For instance, Figure 37 depicts data regarding the user’s language preferences in incognito mode – i.e., blocked languages, blacklisted websites, etc. Lastly, the results suggest that a website’s zoom level cannot be recovered in the file system after a private session.
122
Evaluation of browser controls
Figure 36: Snapshot from DNS records
Figure 37: Snapshot of translation in Google’s Incognito mode
4.3.5 Summary of findings
Table 35 summarizes the privacy protection that is offered in each web browser against an attacker who has unauthorized access to the user’s device after the use of private mode. Moreover, the analysis of the privacy protection that is offered by private mode in each browser, uncovered inconsistencies in the documentation of this control, are summarized in Table 36. Both tables use a superset of symbols that have been used previously, namely define: the symbol  is used when an artefact which is created/modified during private mode remains after the session terminates, the symbol  depicts that the artefact does not remain, the symbol  indicates that the artefact is indirectly available after the session (see comments in the analysis), and the symbol  is used when the browser does not allow the creation/modification of the artefact during the private mode. Chrome. During the analysis of incognito mode, almost all of the artefacts were revealed, except for: browser cache memory, cookies, passwords and zoom level. The same applies to the guest mode, where the browser did not offer the option to bookmark a webpage, while the permissions were not stored in the file system. Firefox. The results were similar to Chrome’s incognito mode, while there was not any website translation option available by Firefox. Also, the use of the ocsp protocol disclosed the browsing history within the ocsp responses. Internet Explorer. Similarly, the analysis of InPrivate mode yields similar results to Chrome’s incognito mode, with the exception of the “download list” artefact that was not saved in the filesystem.
123
Evaluation of browser controls
Opera. The protection of the web artefacts in Opera’s private mode is similar to Firefox’s. However, the browser cache memory cannot be retrieved from the filesystem after the private session. In addition, only Opera enables the user to save her password during a private session, as well as the password is not deleted after its completion.
† Table 35 – Overall results of the protection that is offered by private mode in each browser. Chrome Artefact / Fire- Internet Ex- Pri- Opera Browser Guest fox plorer vate Generic Artefacts Auto-complete form      data Bookmarks      Browser cache      memory Browsing history      Cookies      Download list      Downloaded files      Passwords      Search terms      Browser Artefacts Add-ons / Extensions      Certificates      Plugins      Settings      Website Artefacts Permissions      Translation      Zoom level      †  is used when an artefact remains after the private session,  depicts that the artefact does not remain,  indicates that the artefact is indirectly available after the session, and  is used when the browser does not allow the creation/modification of the artefact during the private mode.
The analysis revealed two facts regarding the protection that is offered to the user by private sessions: (a) some artefacts that are created in private sessions are not included in the documentation of this control and most of the cases remain after the end of the browsing session and (b) some artefacts remain in the filesystem after the private browsing session even though the documentation states otherwise. One should note that in both cases this results in a privacy violation, as these artefacts can be collected by the attacker. However, in the second case the control creates a false sense of privacy protection as the documentation promises to discard the data after the private session. Also, in the first case (assuming that a privacy concerned user will go through the relevant documentation pages) the
124
Evaluation of browser controls user is not informed that the artefact is created and that it remains in the file system after using private browsing. Table 36. Comparison of the documentation with the results from the analysis regarding the protec- † tion that is offered by private mode in each browser. Chrome Artefact / Browser Firefox Internet Explorer Opera Private Guest
Analysis Analysis Analysis Analysis Analysis
Documentation Documentation Documentation Documentation Documentation
Generic Artefacts Auto-complete form data -  -      -  Bookmarks -  -    -    Browser cache memory -  -        Browsing history           Cookies           Download list -  -    -  -  Downloaded files   -    -    Passwords -  -        Search terms -  -      -  Browser Artefacts Add-ons / Extensions -  -  -    -  Certificates -  -  -  -  -  Plugins -  -  -  -  -  Settings -  -  -  -  -  Website artefacts Permissions -  -  -  -  -  Translation -  -  -  -  -  Zoom level -  -  -  -  - 
†  is used when an artefact remains after the private session,  depicts that the artefact does not remain,  indicates that the artefact is indirectly available after the session, and  is used when the browser does not allow the creation/modification of the artefact during the private mode.
4.3.6 User survey
The results in the previous subsection reflect the priorities with regards to the protection of the web artefacts in each browser. For instance, the implementation of private browsing in Opera does not protect passwords, whereas all the rest browsers do so. Similarly, all the browsers regard that cookies and the browsing history should be protected. However, it is unclear whether the users agree with these priorities.
125
Evaluation of browser controls
In this context, this subsection presents the results of a survey that focused on capturing user opinions and perceptions regarding the artefacts of this work. Our survey included 153 participants, having the following demographics: 53.6% were men and 26.8% studied at MSc level and 73.2% at BSc level. 90.2% were Chrome users, 51% were Firefox users, 7% were Opera users and only 2.1% were using Internet Explorer.20 Amongst the participants, 71.2% were aware of the existence private browsing, 9.8% did not and 19% were not completely sure about the security control. Also, it was important to find whether users read the documentation of private mode, since this would inform them which artefacts are protected via the use of such mechanism. The corresponding results revealed that only 1.3% of the sample have read the whole online documentation, 11.8% of them quite read it, 30.7% hardly read it and 55.6% have not read it at all. Figure 38 summarizes the sample’s knowledge regarding the artefacts that are protected by private browsing. As the results indicate, the sample is more likely to consider that the artefacts remain after the private session if they are not mentioned in the documentation or the welcome page of private browsing. It also summarizes the expectation of our sample with regards to the protection of their online privacy, in which sensitive data such as the browsing history and passwords should not be stored in the private session. However, as our results in this work prove that this expectation is not valid.
Add-ons / Extensions 23.50% Auto-complete form data 63.40% Bookmarks 30.00% Browser cache memory 25.50% Browsing history 60.80% Certificates 28.10% Cookies 49.00% Download list 39.90% Downloaded files 19.60% Passwords 65.40% Permissions 31.40% Plugins 21.10% Search terms 49.00% Settings 30.20% Translation 36.00% Zoom level 31.40%
Figure 38: Sample responses regarding the artefacts that do not remain after private browsing
Table 37 summarizes the results from Q9 of the questionnaire regarding the number of respondents that would be very upset if an artefact was recovered by the attacker after the
20 The questionnaire (see Appendix A) allowed more than one option to be selected in Q5 to reflect participants who were using multiple browsers.
126
Evaluation of browser controls private session.21 The results reveal that the passwords (80.4%) and browsing history (62.7%) are the artefacts that will upset the sample the most if they were collected by the attacker. Moreover, the sample expressed least concern about the translation settings (41.8%), bookmarks (34.6%) and downloaded files (32%). The results also suggest that the artefacts auto- complete form data, browser cache memory, cookies, download list, and search terms, would upset one out of two survey participants if they were exposed to an attacker. The majority of the artefacts for which most of the sample stated that they would be very upset if they are exposed are included in the control’s documentation, stating that they are unavailable after the private session. Our analysis, as discussed in the previous subsection, revealed instances in which these artefacts are exposed to a local attacker even after a private session is terminated. This holds true, as (a) the browsing history in both Chrome and Firefox can be retrieved by the data from bookmarks, (b) passwords are not deleted after the private session in Opera, and (c) the browsing history in Firefox can be retrieved from the ocsp responses. It is worrisome that the users are unaware of this correlation between these artefacts, as these artefacts are classified with medium critically and, as with almost all of the medium and low criticality artefacts, can be retrieved after the private session in almost any browser.
Table 37. Number of respondents who indicated they would be very upset if an artefact is exposed.
Artefact Very Upset Passwords 80.4% Browsing history 62.7% Cookies 52.3% Search terms 48.4% Auto-complete form data 45.1% Browser cache memory 45.1% Download list 33.3% Certificates 28.1% Downloaded files 22.2% Permissions 20.3% Bookmarks 17.0% Settings 14.0% Add-ons / Extensions 13.7% Translation 11.2% Plugins 10.5% Zoom level 10.5%
21 Table 55 in Appendix B includes all the results from Q9.
127
Evaluation of browser controls
128
Evaluation of browser controls
4.3.7 CASE STUDY: virtual filesystem vs. privacy violations
This work proves that currently private sessions in all browsers fail to protect the confidentiality of the artefacts that are created while a user is browsing the web, even against a local attacker who has no forensic knowledge or tools. This holds true, as the artefacts are stored in the filesystem within each browser’s folder that is used for data storage or caching. Thus, their unauthorized physical access is considered to be trivial. To mitigate this threat, this work proposes the use of a virtual filesystem as a countermeasure against the privacy violations that have been uncovered. A virtual filesystem is stored in a volatile storage medium, i.e., the RAM instead of a long term storage medium, e.g., hard disk. Currently, software exists that creates a one-off volatile virtual filesystem that the browser can use to operate and support the browsing activities of the user. Such software is available in all popular operating systems for desktops, e.g., RAMDisk (RAMDisk, 2016)) for Windows, i.e., Linux (JamesCoyle, 2016) and OS X (Tanous, 2016). This section will verify if the data that were placed in the virtual filesystem (i.e., in the RAM) were properly deleted upon the termination of the private session. For this reason, we focus on two scenarios: a) using software that creates the virtual filesystem and erase its contents after its use and b) using a file shredder in order to erase the contents of the filesystem. In each scenario, we locate the virtual filesystem in memory and examine if its contents have indeed been deleted.
4.3.7.1 Countermeasure setup
In this case study RAMDisk was selected to create the virtual filesystem in Windows. Windows was the selected operating system, as it has the largest user base. Upon installation of RAMDisk, the browser is configured to use a new destination path to store any data and settings to a RAM location, instead of the default filesystem location. All popular desktop browsers allow this configuration via their interface.
129
Evaluation of browser controls
Table 38, summarizes the configuration steps that are necessary for each browser in our scope.
130
Evaluation of browser controls
Table 38. Browser configuration steps (RAMDisk, 2016)
Right click Chrome icon  Properties  Add string “-- Google Chrome: user-data-dir=” folder path”” after “chrome.exe”  Replace “folder path” with the RAMDisk path about:config  Add string “browser.cache.disk.parent_di- Mozilla Firefox: rectory” as preference name  Add the new path to the RAMDisk path Tools  Internet options  Settings  Move folder  Se- Internet Explorer: lect RAMDisk path Properties  Target  Add “--disk-cache-dir=your folder Opera: path” after “launcher.exe"  Add the new path to the RAMDisk path
4.3.7.2 Verification of the proposed countermeasure
The first scenario of the case study uses RAMDisk as the software that creates the virtual filesystem for storing the user’s private browsing artefacts and uses the tool’s capability of erasing the part of the memory where the virtual disk resides, after the process is terminated. Upon creating the virtual filesystem we enabled the tool’s erase functionality in the software’s configuration and created a volume having only a FAT partition. We configured a browser in the scope of analysis (Firefox in this scenario) to use the filesystem as described above. Also, we placed an existing browser cache in order to make the scenario realistic. We browsed the web and a JPEG file was downloaded to simulate the user’s behavior. While the RAMDisk process was still alive, a memory dump was acquired. After terminating RAMDisk’s process, another memory dump was acquired. In both cases, we identified and isolated the memory pages where the filesystem resides. The two memory dumps were compared with a hex editor in order to make sure that the data that were stored in the virtual filesystem were indeed deleted. As demonstrated in Fig. 16, offset 0x19954000 of the first memory dump contains the boot sector of the virtual disk. At the same offset of the second memory dump, the boot sector has been replaced by zeros, as shown in Fig. 17. The same applies for all the data (files, folders) that have been stored in the virtual filesystem. For readability reasons, this is demonstrated with the aid of a snapshot of image’s contents, which was downloaded in this scenario. As shown in Fig. 18, the header of the file was found in offset 0x17C60000 of the first memory dump. The figure also shows part of the contents of the file. On the second dump, the header as well as the contents of the file have been replaced by zeros, as presented in Figure 40. As a result, our results prove that RamDisk’s functionality of erasing the virtual filesystem’s contents from memory, indeed erases the data in the filesystem. Therefore, RAMDisk or any other software that offers similar functionality, can be used as a countermeasure to protect the user from the privacy violations that have been discussed previously.
131
Evaluation of browser controls
In the second scenario we worked similarly to the previous one (i.e., using RAMDisk to create a virtual disk) with the main difference that we did not enable the tool’s erase functionality upon process termination. Instead, we securely deleted all the browser related files with the use of a file shredder (File Shredder: http://www.fileshredder.org/). Again a real browser cache and a JPEG file were used replicating Scenario 1. A first memory dump was acquired before the deletion of the files and a second after it, while the process was still alive - otherwise the virtual disk would be inaccessible to the file shredder. After the isolation of the corresponding process’ memory space from both dumps, the extracted data were analyzed via a hex editor. As expected, the figures below demonstrate that the boot sector of the virtual disk can be found in offset 0x14436036 in both dumps. This is not surprising as i) the virtual disk is still mounted through the RAMDisk process and ii) the file shredder does not erase the filesystem’s structure. As before, the header and a part of the JPEG file are located in the first dump in offset 0x17845A00,as shown in Figure 45. After the secure deletion of the virtual filesystem this part of the memory is overwritten with zeros, as shown in Figure 46. Consequently, the file shredder successfully erased any browsing related traces, thus protecting the web user’s privacy.
Figure 39: FAT boot sector of the Scenario 1 while RAMDisk’s process is alive
Figure 40: FAT boot sector of the Scenario 1 after the termination of RAMDisk’s process
Figure 41: JPEG header and beginning of its contents (Scenario 1) while RAMDisk’s process is alive
132
Evaluation of browser controls
Figure 42: JPEG header and beginning of its contents (Scenario 1) after the termination of RAMDisk’s process
Figure 43: FAT boot sector of the Scenario 2 before the use of the file shredder
Figure 44: FAT boot sector of the Scenario 2 after the use of the file shredder
Figure 45: JPEG header and beginning of its contents (Scenario 2) before the use of the file shredder
Figure 46: JPEG header and beginning of its contents (Scenario 2) after the use of the file shredder
4.3.8 Discussion
Web browsers offer private browsing mode, a security control that protects user’s privacy against an attacker who has physical access to the user’s device. The presence of this security control allows the user to browse the Internet, without having concerns about whether her online actions will be available to another user who will subsequently use the same device. This paper evaluates the level of protection against privacy violations that is provided by private sessions, as they are implemented by the current popular web browsers in the Windows platform. Windows was selected as it is currently the operating system with the largest user base in desktops, therefore, ensuring the representativeness of this work. Chrome, Firefox, In- ternet Explorer and Opera were monitored during private sessions that were mounted, with the aim to identify any browsing artefacts that remained after the termination of the private session. This work identifies instances in which the official documentation of each browser is either (a) inadequate, as artefacts that are created during the private sessions were not part of the
133
Evaluation of browser controls documentation, or (b) inconsistent, as artefacts that were documented to be deleted after the private session were found, directly or indirectly in the filesystem. In both cases, a user who has physical access to the device with moderate IT skills is able to access the profile directories of the aforementioned browser and access the browsing artefacts. This work also includes a user survey with a two-fold purpose: (a) categorizing the findings based on user opinion regarding their importance and significance (Table 37) and (b) exploring whether the priorities in protecting web assets set forth by the web browsers are consistent with the priorities as collected by their users. Overall, our results revealed that private mode has room for improvement, regarding desktop web browsers. The evaluation of the protection that is offered by every browser revealed inconsistencies regarding the artefacts documented not to be available after a private session is terminated. Specifically, as discussed in Section 4, there were artefacts that were either not included in the documentation, as well as others that can be recovered after the private session, even though the documentation states otherwise. Thus, an average user who has read the browser’s documentation for private browsing, would be either ignorant about the existence of some browsing artefacts during private mode or misled as the security control is not efficient. Almost none of the tested browsers documented or informed the user regarding the browser artefacts and website artefacts, as defined in Table 30. As a result, all browsers have a considerable set of artefacts exposed to local attackers. More specifically, based on the results in Table 35, almost all browsers offered a similar protection to the artefacts that were tested, with the exception of Chrome’s guest mode. Our analysis revealed that all of the browsers protect the majority of the artefacts that the users consider as most important with regards to their privacy, as summarized in Table 37. However, as expected, during this impact valuation the users did not take into consideration the indirect impact of some artefacts with a low or medium valuation. For instance, the majority of the users were least concerned about the exposure of their bookmarks. However, as our results reveal, the bookmarks can be used to recover part of the browsing history, which was the second highest artefact in our survey results. Moreover, in principle, these were the web artefacts that the current implementation of the private mode in all browser tend to forget to protect. Furthermore, the user survey showed that the users’ perceptions regarding the artefacts that are not available after the private session (Figure 38) were consistent with the browsers’ documentation. Indeed, web artefacts that were included in the browsers’ documentation or the control’s welcome screen were more likely to be identified by the sample as deleted after the private session. This is an interesting finding if one considers that the sample responses indicated that more than half of the participants did not read the documentation at all, while only 1.3% of them read it at a great extent.
134
Evaluation of browser controls
Lastly, a case study was used in order to explore how a virtual filesystem can mitigate the privacy violations that were found in this work. Specifically, it was proposed that browsing artefacts are stored in a virtual filesystem within a volatile medium (i.e., RAM) instead of a long term storage medium. Apart from the fact that any data cannot be recovered when the electromagnetic load of the RAM is lost, we examined two scenarios in which the contents of the virtual filesystem are erased (i.e., they are replaced with zeros). The first scenario uses RAMDisk’s integrated capability of erasing the memory occupied by the virtual disk. The second scenario utilizes a file shredder to securely delete the contents of the disk. Our memory analysis experiments did confirm that in both scenarios user’s privacy was successfully preserved by replacing any browsing artefacts with zeros.
4.3.9 Limitations
Our work focuses on the latest versions (at the time of our experiments, i.e., March 2016) of the desktop browsers in Windows only. Other browsers that are available in other desktop operating systems (e.g., Linux, OS X) along with their mobile counterparts (Android, iOS) fall outside the scope of this paper. Moreover, the dynamic nature of the web browsers due to their frequent updates, add another limitation to our work, as browser functionality – including security controls – may be altered or added in the future. Also, the survey results provide only insights of the users’ awareness and perceptions for the private mode and the impact of privacy violations regarding the artefacts that were examined in this work. Our analysis did not aim to be representative and generalizable. Therefore, our results from the user survey are biased toward our sample demographics, but we regard these limitations as out of the scope of this work and we leave them for future work. Finally, our experiments proved that the contents of the virtual filesystem will be erased from memory. However, any data related to browsing artefacts (directly, indirectly) might remain in memory, in other processes (such as web browser), in clipboard, or in residues of received network packets. Nevertheless, this falls out of scope of this work.
135
Evaluation of browser controls
(this page is intentionally left blank)
136
Conclusions
5 Conclusions
5.1 Summary and discussion This dissertation provides evidence suggesting that more work is required for the protection of the users’ security and privacy, via the use of browsers in their daily online activities. Firstly, the control availability survey’s findings revealed that there is a high disparity among the tested browsers. This holds true since there were security controls that were available only on few browsers, while there were differences even between the tested platforms. This is a considerable vulnerability in the browser’s security model, which is rather difficult to overcome since each manufacturer has its own design and technical difficulties to cope with. In contrast, the fact that a security control was implemented by at least one manufacturer in one platform, reveals that there are no serious technical obstacles, but rather different priorities, which need to be aligned with the rest of the vendors. Thus the user will have a clear and common view of a browser’s security perspective in all platforms and vendors. Similarly, another vulnerability was identified via the manageability survey, as the tested browsers again varied based on their controls’ manageability status and default values. In short, there were controls that were false activated, or de-activated, by default, while others were rather challenging to locate and interfere with. That is also an important issue, due to the fact that the average user is not security or technically savvy and simply relies on the manufacturer for her protection when online. Thus, the pre-established level of security is either low, or difficult to interact with when the user chooses to do so. Secondly, as discussed in Section 3.2, the add-ons that were another security countermeasure that was used in browsers to enhance their security, could also be considered as faulty. These mechanisms, which were freely chosen by users through the associated marketplaces, included serious issues that could possibly provoke their use. For instance, most of the tested browsers included only a few of these mechanisms, while others lack of an adequate and sufficient categorization among their identified categories. In addition, in some browsers, there is a huge variety identified, which could possibly confuse the average user when she needs to choose one of them, a fact that is enhanced by the aforementioned faulty categorization, where the user may find wrongly identified add-ons or not even find them at all. Thirdly, the evaluation performed in Section 4 regarding some of the identified security and privacy browser controls, revealed additional vulnerabilities that must be taken into consideration. Most of the browsers that provided anti-phishing mechanisms, were evaluated and marked as high from a performance perspective, since they protected the user throughout the performed tests. Note that some browsers did not succeed in achieving such high figures, while others did
137
Conclusions not offer such protection at all. In contrast, the anti-malware mechanism, which was also evaluated in the same browsers and platforms, showed lower results due to the complexity of the threat. The results’ figures depicted that the most efficient browser protected the user from as low as half of the identified threats via our tests. This was confirmed by our proposed countermeasure, which succeeded in achieving a higher performance figure, but did not reached higher than that due to the aforementioned complexitity. Also, again, some browsers did not offer such a protection mechanism at all. Finally, our study revealed that the private browser mechanism that is available in all of the tested browsers deals with problems of each own. To start with, the manufacturers’ documentation that was publicly available did not hold enough information regarding the artfacts created by a private browsing session, while in some cases, the available information was inaccurate. This was resulted via our conducted tests which revealed artefacts that were supposed not to be available, and others which were not discussed by manufacturers at all. In addition, our user survey reported the users’ opinion regarding the private browsing mechanism, which resulted in confirming the aforemtioned statement regarding the incomplete documentation.
5.2 Publications Our contribution is published in peer-reviewed journals, conferences and book chapters, namely:
. Publications in peer-reviewed, academic journals: j1. Virvilis N, Tsalis N, Mylonas A, Gritzalis D, “Security Busters: Web browser security vs. suspicious sites”, Computers & Security, Vol. 52, pp. 90-105, July 2015. j2. Tsalis N., Mylonas A, Nisioti A, Gritzalis D, Katos V, “Exploring the protection of private browsing in desktop browsers”, Computers & Security, March 2017.
. Publications in peer-reviewed, international conferences: c1 Mylonas A, Tsalis N, Gritzalis D, "Evaluating the manageability of web browsers controls", in Proc. of the 9th International Workshop on Security and Trust Management (STM-2013), pp. 82-98, Springer (LNCS 8203), United Kingdom, September 2013. c2 Mylonas A, Tsalis N, Gritzalis D, "Hide and seek: On the disparity of browser security settings", Research poster, 9th Symposium on Usable Privacy and Security (SOUPS- 2013), United Kingdom, July 2013. c3 Virvilis N, Tsalis N, Mylonas A, Gritzalis D, "Mobile devices: A phisher's paradise", in Proc. of the 11th International Conference on Security and Cryptography (SECRYPT- 2014), pp. 79-87, ScitePress, Austria, August 2014. c4 Tsalis N, Mylonas A, Gritzalis D, "An intensive analysis of the availability of security and privacy browser add-ons", in Proc. of the 10th International Conference on Risks and
138
Conclusions
Security of Internet and Systems (CRiSIS-2015), pp. 1-16, Springer (LNCS 9572), Greece, July 2015.
. Publications in peer-reviewed book chapters: b1. Tsalis N, Virvilis N, Mylonas A, Apostolopoulos T, Gritzalis D, " Browser Blacklists: The Utopia of Phishing Protection", in E-Business and Telecommunications, Obaidat M., et al. (Eds.), pp. 278-292, Springer (CCIS-554), 2016.
As a PhD candidate Mr. Tsalis was involved in other research in the field of Information Security and co-authored the following two peer-reviewed conference papers and one peer- reviewed book chapter, i.e.: c5 Tsalis N, Theoharidou M, Gritzalis D, “Return on security investment for Cloud platforms”, in Proc. of the Economics of Security in the Cloud Workshop (ESC-2013), pp.132-137, IEEE Press, United Kingdom, December 2013. c6 Tsalis N, Virvilis N, Mylonas A, Apostolopoulos T, Gritzalis D, " Browser Blacklists: The Utopia of Phishing Protection", in E-Business and Telecommunications, Obaidat M., et al. (Eds.), pp. 278-292, Springer (CCIS-554), 2016.
b2. Theoharidou M, Tsalis N, Gritzalis D, "Smart Home Solutions for Healthcare: Privacy in Ubiquitous Computing Infrastructures", Technical Report, AUEB-CIS/REV-0513/v.1.1, Athens University of Economics & Business, November 2013.
5.3 Future work To begin with, as discussed in Section 3, the current level of security provided in modern web browsers for both platforms is necessary to be identified and mapped. Thus, future work should include the evaluation of the available controls, either build-in or additional, in all browsers’ versions in all desktop (i.e. Windows, Mac and Linux) and mobile (i.e. Android and iOS) platforms. In that way, the current research will be kept up-to-date with the latest additions / modifications that manufacturers offer. Since this dissertation is based on the most popular systems and browsers (e.g. Windows 7), future work should also include further related elements. For instance, users have started using cloud-based browsers that offer enhanced usability. As a result, a similar evaluation must take place so as to conclude on whether the newly proposed technologies can keep up or even replace the existing one.
139
Conclusions
As discussed in Section 3.1, the browser add-ons that are offered by the manufacturers’ marketplaces, are evaluated from a quantitative perspective. Our future work will include a qualitative evaluation as well, similar to the one performed in the anti-phishing, anti-malware and private browsing controls. The results of the aforementioned evaluation will conclude on whether the add-ons can be used to protect the user against the related attack, or even replace the existing build-in control, at best case. Future research can extend our work on control evaluation by elaborating on an extended review of the rest of the countermeasures that were not evaluated in this dissertation. Phishing, malware and privacy violations may have been achnowledged by manufacturers as the top threats, but there are additional controls that are high in priority and need to be further examined. For instance, the block-popups control shields the user from unwanted advertisements or even malicious websites. Last but not least, the private browsing mechanism, which is discussed in Section 4.3, is a newly introduced technology that is not mature enough yet. Our research has revealed an adequate amount of disefficiencies that target directly user’s privacy when online. As a result, our future work will extend our work by including the mobile counterpart in modern mobile environments (i.e. iOS and Android) so as to create the full privacy landscape that users operate within. In addition, our conducted survey (discussed in Section 4.3) revealed that there is users are usually misinformed about applies to modern browsers when it comes to privacy protection, or they simply do not bother to get informed about it. Thus, our future work will include an enhanced survey for all tested browsers and platforms, so as to conclude on whether our results agree with user’s opinion, or whether manufacturers should enhance the provided security and privacy protection since users solely rely on them for their protection.
5.4 Concluding remarks The protection of the security and privacy of the average user is crucial, as modern threats become more complex and sophisticated, while the user provides the online environment a larger amount of important data (e.g. personal information). This work explored the current state of protection which is offered by modern desktop and mobile browsers and identifies that their users are exposed to both security and privacy violations. “Security is a chain; it's only as secure as the weakest link”. This popular quote from Bruce Schneier is well known among security practitioners and researchers. Often the weakest link in the security chain is the user, irrespective of the computing platform. This stems from the fact that security often creates usability issues that users try to get rid of by decreasing or circum- venting the offered security. This is confirmed by our testing results that revealed the manufacturers’ difficulty to maintain a golden ratio between the usability and security offered. Also, the findings indicate that users must also get more acquainted with the security perspective that
140
Conclusions exists in their daily lives so as to identify possible threats when the existing protection fails to do so. As a result, the user, which was formerly identified as the weakest link in the security chain, will enhance her stance and make a step further towards efficiently protecting herself against the aforementioned sophisticated threats. This thesis utilized the lessons learned while studying browser’s security and explored whether further enhancements could be deployed to improve the existing level of protection. In that approach, new sollutions were implemented and evaluated so as to result on whether their effectiveness was greater that the one from the existing security mechanisms.
141
Conclusions
(this page is intentionally left blank)
142
References
References
Abrams R., Pathak J.,Barrera O., Ghimire D. "Browser Security Comparative Analysis", NSS Labs, 2014. [Online]. Available: https://www.nsslabs.com/reports/browser-security-comparative-analysis- report-socially-engineered-malware [Accessed: 6th Aug 2014].
Addons.mozilla.org (2015) Add-ons for Firefox. https://addons.mozilla.org/en-US/firefox/. Accessed 10 Apr 2015
Aggarwal, G., Bursztein, E., Jackson, C., & Boneh, D. (2010). Analysis of Private Browsing Modes in Modern Browsers. USENIX Security Symposium (pp. 79-94).
Akhawe D., Felt A. P., “Alice in Warningland: A large-scale field study of browser security warning effectiveness”, in Proc. of the 22nd USENIX Security Symposium, 2013.
Al Barghouthy, N., Marrington, A., & Baggili, I. (2013). The forensic investigation of android private browsing sessions using orweb. In Computer Science and Information Technology (CSIT), 2013 5th In- ternational Conference on (pp. 33-37). IEEE.
Amari, K. (2009). Techniques and tools for recovering and analyzing data from volatile memory. SANS Institute.
Amrutkar C., Traynor P., van Oorschot P. (2012) Measuring SSL Indicators on mobile browsers: Ex- tended life, or end of the road?. pp. 86-103, LNCS 7483, Springer
Antonakakis M., Perdisci R., Lee W., Vasiloglou II N. and Dagon D. "Detecting Malware Domains at the Upper DNS Hierarchy", in Proc. of the 20th USENIX conference on Security (SEC'11), USENIX Association, Berkeley, CA, USA, p.16, 2011.
Apple, (2016). Safari 6 for PC? | Apple Support Communities. [online] Available at: https://discus- sions.apple.com/thread/5713095?tstart=0 [Accessed 16 Jan. 2016].
AV “Anti-Phishing protection of popular web browsers,” AV Comparatives, Dec 2012. [Online]. Avail- able: http://www.av-comparatives.org/images/docs/avc_phi_browser_201212_en.pdf [Accessed: 05 Jan 2014].
Banu, M. Nazreen, S., Munawara Banu, “A Comprehensive Study of Phishing Attacks”, in Proc. of the International Journal of Computer Science and Information Technologies, vol. 4, issue 6, pp. 783-786, 2013.
Barth A., Felt A. P., Saxena P.,Boodman A. (2009) Protecting browsers from extension vulnerabilities. In: 17th Network and Distributed System Security Symposium (NDSS ’10), USA
Bian R. M., “Alice in Battlefield: An Evaluation of the Effectiveness of Various UI Phishing Warnings”. [Online]. Available: https://www.cs.auckland.ac.nz/courses/compsci725s2c/archive/termpa- pers/725mbian13.pdf [Accessed 2 Feb 2014]
Bilge, L., Kirda, E., Kruegel, C. and Balduzzi, M. "EXPOSURE: Finding Malicious Domains Using Passive DNS Analysis", ACM Transactions on Information and System Security, ACM, Vol. 16, No 4, USA, April 2014.
Botha R., Furnell S., Clarke N. (2009) From desktop to mobile: Examining the security experience. Computers & Security. 28(3-4), 130-137
Bradley, T., “Android Dominates Market Share, But Apple Makes All The Money”. [Online]. Availa- ble at: http://www.forbes.com/sites/tonybradley/2013/11/15/android-dominates-market-share-but-apple-makes-all-the-money/ [Accessed: 12 Apr 2014].
143
References
Browser Security Settings for Chrome, Firefox and Internet Explorer: Cybersecurity 101, http://www.veracode.com/blog/2013/03/browser-security-settings-for-chrome-firefox-and-internet-explorer/
Caballero J., Grier C., Kreibich C., and Paxson V. "Measuring pay-per-install: the commoditization of malware distribution". in Proc. of the 20th USENIX conference on Security, SEC'11, 2011.
Canali, D., Cova, M., Vigna, G., Kruegel, C.: Prophiler: A fast filter for the large-scale detection of malicious web pages. In: 20th International Conference on World Wide Web, pp. 197-206. ACM, India (2011)
Capaccio, N., “Apple Mobile Devices Cleared for Use on U.S. Military Networks”. [Online]. Available at: http://www.bloomberg.com/news/2013-05-17/apple-mobile-devices-cleared-for-use-on-u-s-military-networks.html [Accessed: 10 Mar 2014].
Carlini N., Felt A., Wagner D. (2012) An evaluation of the google chrome extension security architecture. In: 21st USENIX Conference on Security, USA
CBC, “Smartphones becoming prime target for criminal hackers”. [Online]. Available at: http://www.cbc.ca/news/technology/smartphones-becoming-prime-target-for-criminal-hackers- 1.2561126 [Accessed: 09 Apr 2014].
CERT, Browsing Safely: Understanding active content and cookies, http://www.us-cert. gov/ncas/tips/st04-012 CERT, Securing Your Web Browser, http://www.cert.org/tech_tips/secur- ing_browser/
Chen, E., Bau, J., Reis, C., Barth, A., Jackson, C.: App isolation: Get the security of multiple browsers with just one. In: 18th ACM Conference on Computer and Communications Security, pp. 227-238. ACM, USA (2011)
Chrome.google.com (2015) Adblock Plus. https://chrome.google.com/webstore/detail/adblock-plus/af- kdehgifkgjdcdlbfkjnmaeagepfbgp?hl=en. Accessed 25 Apr 2015
Chrome.google.com (2015) Chrome Web Store. https://chrome.google.com/webstore/category/extensions. Accessed 10 Apr 2015
CIF "Collective Intelligence Framework" [online]. Available: https://code.google.com/p/collective-intelligence-framework/ [Accessed: 6th Aug 2014].
CISCO, "Cisco Annual Security Report". [Online]. Available at: http://www.cisco.com/c/en/us/products/security/annual_security_report.html [Accessed 10 Oct 2014]
Cisco, Visual Networking Index: Global Mobile Data Traffic Forecast Update. Technical Report (2013)
Colvin R. " SmartScreen Application Reputation – Building Reputation". [Online]. Available: http://blogs.msdn.com/b/ie/archive/2011/03/22/smartscreen-174-application-reputation-building- reputation.aspx [Accessed: 4 Aug 2014].
Curtsinger, C., Livshits, B., Zorn, B. and Seifert, C. "ZOZZLE: Fast and Precise In-Browser JavaScript Malware Detection". in Proc. of the 20th USENIX conference on Security (SEC'11), USENIX Associa- tion, Berkeley, CA, USA pp.33--48, 2011.
Darwish A., Bataineh E., “Eye tracking analysis of browser security indicators”, in Proc. of Computer Systems and Industrial Informatics Conference, pp. 1–6, 2012.
Eckersley, P.: How unique is your web browser?. In: 10th International Conference on Privacy Enhancing Technologies, pp. 1-18. Springer (2010)
Edward Snowden: Leaks that exposed US spy programme - BBC News. [online] Available at: http://www.bbc.com/news/world-us-canada-23123964 [Accessed 13 Mar. 2016].
144
References
Egelman S., Cranor L., Hong J., “You’ve been warned: an empirical study of the effectiveness of web browser phishing warnings”, in Proc. of the SIGCHI Conference on Human Factors in Computing Sys- tems, pp. 1065–1074, 2008.
Egelman S., Schechter S.: The Importance of Being Earnest [In Security Warn-ings]. In: Financial Cryp- tography and Data Security, Springer, pp. 52–59 (2013)
ENISA, ENISA threat landscape - Responding to the evolving threat environment. Technical Report (2012)
Extensions.apple.com (2015) Apple - Safari - Safari Extensions Gallery. https://extensions. apple.com/. Accessed 10 Apr 2015
Fielding, R., Gettys J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T.: Hypertext Trans- fer Protocol–HTTP/1.1. Technical Report (1999)
Funk C., Garnaeva M. "Kaspersky Security Bulletin 2013. Overall Statistics for 2013". [Online]. Available: http://securelist.com/analysis/kaspersky-security-bulletin/58265/kaspersky-security-bulletin- 2013-overall-statistics-for-2013/ [Accessed: 4 Aug 2014].
Gao, X., Yang, Y., Fu, H., Lindqvist, J., & Wang, Y. (2014, November). Private Browsing: an Inquiry on Usability and Privacy Protection. In Proceedings of the 13th Workshop on Privacy in the Electronic Society (pp. 97-106). ACM.
Gartner, (2015). Gartner Says 4.9 Billion Connected. [online] Available at: http://www.gartner.com/newsroom/id/2905717 [Accessed 13 Dec. 2015].
Gartner, “Gartner Says Annual Smartphone Sales Surpassed Sales of Feature Phones for the First Time in 2013”, [Online]. Available: https://www.gartner.com/newsroom/id/2665715 [Accessed: 10th Aug 2014].
Gartner, “Gartner Says Smartphone Sales Accounted for 55 Percent of Overall Mobile Phone Sales in 3rd Quarter of 2013”. [Online]. 2014 Available at: https://www.gartner.com/newsroom/id/2623415 [Ac- cessed: 10 Mar 2014].
Gartner, “Gartner Says Worldwide Mobile Payment Transaction Value to Surpass $235 Billion in 2013”. [Online]. Available at: https://www.gartner.com/newsroom/id/2504915 [Accessed: 10 Mar 2014].
Gartner, “Gartner Survey Highlights Top Five Daily Activities on Media Tablets”. [Online]. Available: https://www.gartner.com/newsroom/id/2070515 [Accessed: 10 Mar 2015]
Gartner, “Top 10 Strategic Technology Trends For 2014”. [Online]. Available at: http://www.forbes.com/sites/peterhigh/2013/10/14/gartner-top-10-strategic-technology-trends-for- 2014/ [Accessed: 2 Aug 2014].
Gartner: Gartner Says Worldwide Mobile Payment Transaction Value to Surpass $235 Billion in 2013, https://www.gartner.com/newsroom/id/2504915
Google. (2017). Patent US5572643 - Web browser with dynamic display of information objects during linking. [online] Available at: https://www.google.com/patents/us5572643 [Accessed 5 Jan. 2017].
Google, (2016). Browse in private with incognito mode - Chrome Help. [online] Available at: https://support.google.com/chrome/answer/95464?hl=en [Accessed 16 Jan. 2015].
Google, (2016). Let others browse Chrome as a guest - Chrome Help. [online] Available at: https://support.google.com/chrome/answer/6130773?hl=en [Accessed 16 Jan. 2015].
Google, “Safe Browsing API”. [Online]. Available at: https://developers.google.com/safe-browsing/ [Accessed: 8 Mar 2014].
145
References
Gupta, A., Cozza, R., Milanesi, C., Lu, C.: Market Share Analysis: Mobile Phones, Worldwide, 4Q12 and 2012. Technical Report (2013)
Gutmann, P. (1996, July). Secure deletion of data from magnetic and solid-state memory. In 6th USENIX Security Symposium, San Jose, CA (Vol. 14).
Heule, S., Rifkin, D., Russo, A., & Stefan, D. (2015). The most dangerous code in the browser. In 15th Workshop on Hot Topics in Operating Systems (HotOS XV). USENIX Association.
HTML5. (2017). How Browsers Work: Behind the scenes of modern web browsers - HTML5 Rocks. [online] Available at: https://www.html5rocks.com/en/tutorials/internals/howbrowsers- work/#The_browsers_we_will_talk_about [Accessed 5 Jan. 2017].
Internet Explorer Gallery (2015) Internet Explorer Gallery. http://www.iegallery.com/ PinnedSites. Ac- cessed 10 Apr 2015
Internetworldstats, (2016). World Internet Users Statistics and 2015 World Population Stats. [online] Available at: http://www.internetworldstats.com/stats.htm [Accessed 28 Feb. 2016].
JamesCoyle.net. (2013). Create a RAM disk in Linux | JamesCoyle.net. [online] Available at: https://www.jamescoyle.net/how-to/943-create-a-ram-disk-in-linux [Accessed 15 Jul. 2016].
Jang, D., Jhala, R., Lerner, S., Shacham, H.: An empirical study of privacy-violating information flows in javascript web applications. In: 17th ACM Conference on Computer and Communications Security, pp. 270-283. ACM, USA (2010)
Jansson, K., Von Solms, R.: Phishing for phishing awareness. In: Behavior & In-formation Technology Conference, vol. 32, issue 6, pp. 584-593 (2013)
Kapravelos A., Grier C., Chachra N., Kruegel C., Vigna G., Paxson V. (2014) Hulk: Eliciting malicious behavior in browser extensions. In: 23rd USENIX Security Symposium (USENIX Security 14), USA. USENIX Association
Kirda E., Kruegel C.: Protecting users against phishing attacks with antiphish. In: Computer Software and Applications Conference, vol. 1, pp. 517–524 (2005)
Kolbitsch, C., Livshits, B., Zorn, B., Seifert, C.: Rozzle: De-cloaking internet malware. In: 33th IEEE Symposium on Security and Privacy, pp. 443-457. IEEE, USA (2012)
Kolter J. and Maloof M. "Learning to detect and classify malicious executables in the wild", in Proc. of the Journal of Machine Learning Research, 7, pp.2721--2744, 2006.
Lekkas, D., Gritzalis, D.: Long-term verifiability of healthcare records authenticity. In: International Journal of Medical Informatics. 76(5-6), 442-448. Elsevier (2006)
Lerner, B. S., Elberty, L., Poole, N., & Krishnamurthi, S. (2013). Verifying web browser extensions’ compliance with private-browsing mode. In Computer Security–ESORICS 2013 (pp. 57-74). Springer Berlin Heidelberg.
Li L., Wang X., Choi J. (2007) SpyShield: Preserving privacy from spy add-ons. In Conference on Recent Advances in Intrusion Detection
LinkChecker D (2013) Dr.Web LinkChecker. In: Addons.mozilla.org. https://addons. mozilla.org/en- US/firefox/addon/drweb-anti-virus-link-checker/?src=search. Accessed 25 Apr 2015
Love D. " The Latest Jailbreak Statistics Are Jaw-Dropping". [Online]. Available: http://www.busi- nessinsider.com/jailbreak-statistics-2013-3 [Accessed: 4 Aug 2014].
146
References
Ltd. W (2015) Safe Browsing Tool | WOT (Web of Trust). In: Mywot.com. https://www.mywot.com/. Accessed 25 Apr 2015
Lu L., Yegneswaran V., Porras P., and Lee W. "Blade: an attack-agnostic approach for preventing drive-by malware infections", in Proc. of the 17th ACM conference on Computer and communications security, CCS '10, 2010.
Lu M., Leita C., Thonnard O., Keromytis A., and Dacier M.. "An analysis of rogue av campaigns", in Proc. of the 13th international conference on Recent advances in intrusion detection, RAID'10, 2010.
Madrigal, I'm being followed: How Google - and 104 other companies - are tracking me on the Web, http://www.theatlantic.com/technology/archive/2012/02/im-being-followed-how-google-151-and-104- other-companies-151-are-tracking-me-on-the-web/253758/
Malwaredomains.com (2015) DNS-BH – Malware Domain Blocklist. http://www.malwaredomains.com/. Accessed 25 Apr 2015
Marrington, A., Baggili, I., Al Ismail, T., & Al Kaf, A. (2012). Portable web browser forensics: A forensic examination of the privacy benefits of portable web browsers. In Computer Systems and Industrial Informatics (ICCSII), 2012 International Conference on (pp. 1-6). IEEE.
Mazher N., Ashraf I., Altaf A.: Which web browser work best for detecting phish-ing. In: Information and Communication Technologies Conference, pp. 1–5 (2013)
McAfee "Site Advisor" [online]. Available: https://www.siteadvisor.com/ [Accessed: 6th Aug 2014].
McAfee, “McAfee Labs Report Highlights Success of Phishing Attacks with 80 Percent of Business Users Unable to Detect Scams”, 2014. [Online]. Available: http://www.mcafee.com/us/about/news/2014/q3/20140904-01.aspx. [Accessed: 10 Mar 2015]
McAfee, “McAfee Labs Threats report”, 2014, [Online]. Available: http://www.mcafee.com/mx/resources/reports/rp-quarterly-threat-q1-2014.pdf [Accessed: 12 Mar 2015]
Mell, P., Kent, K., Nusbaum, J.: Guide to malware incident prevention and han-dling, National Institute of Standards and Technology (NIST), (2005)
Memory.dataram.com. (2016). RAMDisk Product FAQ - RAMDisk Support Center - Support - Dataram. [online] Available at: http://memory.dataram.com/support/ramdisk-support-center/ramdisk-product- support-faq [Accessed 8 Jul. 2016].
Memory.dataram.com. (2016). RAMDisk Product FAQ - RAMDisk Support Center - Support - Dataram. [online] Available at: http://ftp.raxco.com/pub/download/rd/UserGuides/RAMDISK_PLUS_HOW- TO_INSTRUCTIONS.pdf [Accessed 8 Jul. 2016].
Microsoft (2016). Process Monitor. [online] Available at: https://technet.microsoft.com/en-us/sysinter- nals/processmonitor.aspx [Accessed 16 Mar. 2016].
Microsoft, (2016). InPrivate Browsing - Microsoft Windows. [online] Available at: http://windows.microsoft.com/en-us/internet-explorer/products/ie-9/features/in-private [Accessed 16 Jan. 2015].
Microsoft, (2016). Translate websites. [online] Available at: http://onlinehelp.microsoft.com/en- us/bing/gg445029.aspx [Accessed 16 Jan. 2015].
Microsoft, “SmartScreen Filter”. [Online]. Available at: http://windows.microsoft.com/en-us/internet- explorer/products/ie-9/features/smartscreen-filter [Accessed: 8 Mar 2014].
147
References
Montasari, R., & Peltola, P. (2015). Computer Forensic Analysis of Private Browsing Modes. In Global Security, Safety and Sustainability: Tomorrow's Challenges of Cyber Security (pp. 96-109). Springer International Publishing
Motiee, S., Hawkey, K., Beznosov, K.: Do windows users follow the principle of least privilege?: Inves- tigating user account control practices. In: 6th Symposium on Usable Privacy and Security, pp. 1-13. ACM, USA (2010)
Mozilla, (2016). Private Browsing - Use Firefox without saving history | Firefox Help. [online] Available at: https://support.mozilla.org/en-US/kb/private-browsing-use-firefox-without-history [Accessed 16 Jan. 2015].
Mozilla, “Mozilla Support”, [Online]. Available: https://support.mozilla.org/en-US/kb/how-does- phishing-and-malware-protection-work#w_how-does-phishing-and-malware-protection-work-in-firefox [Accessed: 20/3/2015].
Mylonas A., Dritsas S, Tsoumas V., Gritzalis D.: Smartphone Security Evaluation - The Malware Attack Case. In: 8th International Conference on Security and Cryp-tography, pp. 25-36, SciTePress, Spain, July (2011)
Mylonas A., Gritzalis D., Tsoumas B., Apostolopoulos T.: A qualitative metrics vector for the awareness of smartphone security users. In: 10th Inter-national Conference on Trust, Privacy & Security in Digital Business (TRUSTBUS-2013), pp. 173-184, Springer (LNCS 8058) Czech Republic (2013)
Mylonas A., Kastania A., Gritzalis D.: Delegate the smartphone user? Security awareness in smartphone platforms. In: Computers & Security, Vol. 34, pp. 47-66, (2013)
Mylonas A., Tsalis N., Gritzalis D.: Evaluating the manageability of web browsers controls. In: 9th In- ternational Workshop on Security and Trust Management, pp. 82-98, Springer (LNCS 8203), UK (2013)
Mylonas, A., Dritsas, S, Tsoumas, B., Gritzalis, D.: Smartphone security evaluation: The malware attack case. In: 8th International Conference on Security and Cryptography, pp. 25-36. SciTePress, Spain (2011)
Mylonas, A., Kastania, A., Gritzalis, D.: Delegate the smartphone user? Security awareness in smartphone platforms. Computers & Security. 34, 47-66 (2013)
Mylonas, A., Tsalis, N., Gritzalis, D.: Hide and seek: On the disparity of browser security settings. In: 9th Symposium on Usable Privacy and Security (poster), UK (2013)
Netcraft, “Phishing Site Feed”. [Online]. Available at: http://www.netcraft.com/anti-phishing/phishing- site-feed/ [Accessed: 8 Mar 2014].
Network Computing: Certificate authority compromises are global in reach, http://www.networkcom- puting.com/security/certificate-authority-compromises-are-gl/ 231601123
Nielsen, “The Digital Consumer”, The Nielsen Company. [Online]. Available at: http://www.nielsen.com/content/dam/corporate/us/en/reports-downloads/2014%20Reports/the-digital-consumer-report-feb-2014.pdf [Accessed: 2 Aug 2014].
Oberheide J., Cooke E, and Jahanian F. "CloudAV: N-Version Antivirus in the Network Cloud." In USENIX Security Symposium, pp. 91-106. 2008.
Oh, J., Lee, S. and Lee, S. (2011). Advanced evidence collection and analysis of web browser activity. Digital Investigation, 8, pp.S62-S70.
Ohana, D. and Shashidhar, N. (2013). Do private and portable web browsers leave incriminating evidence?: a forensic analysis of residual artifacts from private and portable web browsing sessions. EURASIP J Inform Secur, 2013(1), p.6.
148
References
OpenDNS [online]. Available: http://www.opendns.com/ [Accessed: 18th Aug 2014].
Opera add-ons (2015) Opera add-ons. https://addons.opera.com/en/. Accessed 10 Apr 2015
Opera, (2016). Opera Help. [online] Available at: http://help.opera.com/Mac/12.10/en/private.html [Ac- cessed 16 Jan. 2015].
OWASP. “Certificate and Public Key Pinning”. [Online]. Available at: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning [Accessed: 18 Mar 2014].
Perdisci R., Lanzi A., and Lee W. "Classification of packed executables for accurate computer virus detection". Pattern Recognition Letters, 29(14):1941, October 2008.
Perdisci R., Lanzi A., and Lee W. "Mcboost: Boosting scalability in malware collection and analysis using statistical classication of executables", in Proc. of the 2008 Annual Computer Security Applica- tions Conference, ACSAC '08, pages 301{310, 2008.
Phishtank "Phishtank" [online]. Available: https://www.phishtank.com/ [Accessed: 6th Aug 2014].
PhishTank, “Join the fight against phishing”. [Online]. Available at: https://www.phishtank.com/ [Ac- cessed: 8 Mar 2014].
Provos N., Mavrommatis P., Rajab M., and Monrose F. "All your iframes point to us", in Proc. of the 17th conference on Security symposium, SS'08, 2008.
Provos N., McNamee D., Mavrommatis P., Wang K., and Modadugu N. "The ghost in the browser analysis of web-based malware", in Proc. of the 1st conference on First Workshop on Hot Topics in Understanding Botnets, HotBots'07, pages 4--4, Berkeley, CA, USA, 2007. USENIX Association.
Rajab, M. A., Ballard, L., Lutz, N., Mavrommatis, P., AND Provos, N. "CAMP: Content-Agnostic Mal- ware Protection", in Proc. of the Network and Distributed System Security Symposium (NDSS) (2013).
RAMDisk. (2016). RAMDisk - Software that Accelerates, Protects, Optimizes - Server Memory Products & Services - Dataram. [online] Available at: http://memory.dataram.com/products-and-services/software/ramdisk [Accessed 3 Mar. 2016].
Rani, S., Dubey, J.: A Survey on Phishing Attacks. In: International Journal of Computer Applications, vol. 88, issue 10 (2014)
Reuters. (2016). U.S. warns on Java software as security concerns escalate. [online] Available at: http://www.reuters.com/article/2013/01/11/us-java-security-idUSBRE90A0S320130111 [Accessed 13 Dec. 2016].
Rosiello, A. P., Kirda, E., Kruegel, C., Ferrandi, F.: A layout-similarity-based ap-proach for detecting phishing pages. In: Security and Privacy in Communications Networks Workshops, pp. 454-463 (2007)
RSA, “RSA Online fraud report - 2014”. [Online]. Available at: http://www.emc.com/collateral/fraud- report/rsa-online-fraud-report-012014.pdf [Accessed: 10 Mar 2015]
Ruiz, R. D. S., Amatte, F. P., Park, K. J. B., & Winter, R. (2015). Overconfidence: Personal Behaviors Regarding Privacy that Allows the Leakage of Information in Private Browsing Mode. IJCSDF, 4(3), pp.404-416.
Said, H., Al Mutawa, N., Al Awadhi, I., & Guimaraes, M. (2011). Forensic analysis of private browsing artifacts. In Innovations in information technology (IIT), 2011 International conference on (pp. 197-202).
Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., & Adams, C. (2013). X. 509 Internet public key infrastructure online certificate status protocol-OCSP. (No. RFC 6960).
149
References
Satvat, K., Forshaw, M., Hao, F. and Toreini, E. (2014). On the privacy of private browsing – A forensic approach. Journal of Information Security and Applications, 19(1), pp.88-100.
SearchDataManagement, (2016). What is CRUD cycle (Create, Read, Update and Delete Cycle)? - Def- inition from WhatIs.com. [online] Available at: http://searchdatamanagement.techtarget.com/definition/CRUD-cycle [Accessed 16 Jan. 2015].
Securelist.com (2015) Financial cyber threats in 2014: Things changed - Securelist. http://securelist.com/analysis/kaspersky-security-bulletin/68720/financial-cyber-threats-in-2014-things-changed/. Accessed 10 Apr 2015
SERT: Quarterly Threat Intelligence Report Q4 2012. Technical Report (2013)
Shahzad A., Hussain M. and Khan M. "Protecting from Zero-Day Malware Attacks", in Proc. of the Middle-East Journal of Scientific Research, Vol. 17, No, 4, pp.455--464, 2013
Sheng S., Wardman B., Warner G., Cranor L. Hong J., Zhang C.: An empirical analysis of phishing blacklists. In: 6th Conference on Email and Anti-Spam (2009)
Shin S. Xu Z. and Gu G. "EFFORT: Efficient and effective bot malware detection", Computer Net- works, Volume 57, Issue 13, pp.2846--2850, 2012.
Sikorski, M. and Honig, A., (2012). Practical malware analysis: the hands-on guide to dissecting malicious software. no starch press.
Sobrier J., “Google Safe Browsing v2 API: Implementation notes”. [Online]. Available: http://www.zscaler.com/research/Google%20Safe%20Browsing%20v2%20API.pdf [Accessed: 10/01/2014].
StatCounter: StatCounter Global Stats, http://gs.statcounter.com
Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., Cranor, L.: Crying wolf: An empirical study of SSL warning effectiveness. In: 18th Conference on USENIX Security Symposium, pp. 399-416. USENIX Association, USA (2009)
Symantec "Safe web" [online]. Available: https://safeweb.norton.com/ [Accessed: 6th Aug 2014].
Symantec, “2014 Internet Security Threat Report”. [Online]. Available at: http://www.symantec.com/se- curity_response/publications/threatreport.jsp [Accessed 10 Oct 2014]
Tanous, J. (2013). How to Create a 4GB/s RAM Disk in Mac OS X - TekRevue. [online] TekRevue. Available at: https://www.tekrevue.com/tip/how-to-create-a-4gbs-ram-disk-in-mac-os-x/ [Accessed 15 Jul. 2016].
Theoharidou M., Kotzanikolaou P., Gritzalis D., “A multi-layer Criticality Assessment methodology based on interdependencies”, Computers & Security, Vol. 29, No. 6, pp. 643-658, 2010.
Theoharidou M., Kotzanikolaou P., Gritzalis D.: Risk-based Criticality Analysis. In: 3rd IFIP Interna- tional Conference on Critical Infrastructure Protection, Springer, USA (2009)
Theoharidou, M., Mylonas, A., Gritzalis, D.: A risk assessment method for smartphones. In: 27th IFIP International Information Security and Privacy Conference, pp. 428-440, Springer (AICT 267), Greece (2012)
Tryfonas, T., Kokolakis, S., Gritzalis, D.: A qualitative approach to information availability. In: 15th Conference on Information Security for Global Information Infrastructures, pp. 37-48, Kluwer, China (2000)
150
References
Tsalis N., Virvilis N., Mylonas A., Apostolopoulos A., Gritzalis D. (2015) Browser Blacklists: A utopia of phishing protection. Security and Cryptography.
Tsalis, N., Mylonas, A., & Gritzalis, D. An intensive analysis of security and privacy browser add-ons. In Proc. of the 10th International Conference on Risks and Security of Internet and Systems (CRISIS- 2015), Springer (LNCS).
Tsalis, N., Virvilis, N., Mylonas, A., Apostolopoulos, T., & Gritzalis, D. (2015). Browser Blacklists: A utopia of phishing protection. Security and Cryptography. In Security and Cryptography, M. Obaidad and A. Holzinger (Eds.), Lecture Notes (CCIS), Springer.
Vadrevu P., Rahbarinia B., Perdisci R., Li, K. and Antonakakis, M. "Measuring and Detecting Malware Downloads in Live Network Traffic". Computer Security – ESORICS 2013, [online] pp.556-573. Available at: http://dx.doi.org/10.1007/978-3-642-40203-6_31 [Accessed 19 Jul. 2014].
Vidas T., Owusu E., Wang S., Zeng C., Cranor L., Christin N.: QRishing: The Susceptibility of Smartphone Users to QR Code Phishing Attacks. In: Financial Cryptography and Data Security, pp. 52– 69 (2013)
VirusTotal "VirusTotal" [online]. Available: https://www.virustotal.com/ [Accessed: 6th Aug 2014].
Virustotal.com (2015) VirusTotal - Free Online Virus, Malware and URL Scanner. https:// www.virustotal.com/. Accessed 10 Apr 2015
Virvilis N., Gritzalis D., “Trusted Computing vs. Advanced Persistent Threats: Can a defender win this game?”, in Proc. of 10th IEEE International Conference on Autonomic and Trusted Computing, pp. 396- 403, IEEE Press, Italy, 2013.
Virvilis N., Gritzalis D.: The Big Four - What we did wrong in Advanced Persistent Threat detection?. In: 8th International Conference on Availability, Reliability and Security, pp. 248-254, IEEE, Germany (2013)
Virvilis, N., Mylonas, A., Tsalis, N. and Gritzalis, D. (2015). Security Busters: Web browser security vs. rogue sites. Computers & Security, 52, pp.90-105.
Virvilis, N., Tsalis, N., Mylonas, A., & Gritzalis, D. (2014). Mobile devices: A phisher's paradise. In Proc. of the 11th International Conference on Security and Cryptography (pp. 79-87).
W3schools, (2016). Browser Statistics. [online] Available at: http://www.w3schools.com/browsers/browsers_stats.asp [Accessed 16 Jan. 2015].
Xu Z., Zhu S.: Abusing Notification Services on Smartphones for Phishing and Spamming. In: 6th USENIX conference on Offensive Technologies, pp. 1–11 (2012)
Xu, M., Jang, Y., Xing, X., Kim, T., & Lee, W. (2015). UCognito: Private Browsing without Tears. In 22nd ACM SIGSAC Conference on Computer and Communications Security (pp. 438-449). ACM.
Zhang J., Seifert C., Stokes J., and Lee W. "Arrow: Generating signatures to detect drive-by downloads", in Proc. of the 20th international conference on World wide web, WWW '11, 2011.
Zhang, H., Liu, G., Chow, T. W., Liu, W.: Textual and visual content-based anti-phishing: A Bayesian approach. In: IEEE Transactions on Neural Networks, vol. 22, issue 10, pp. 1532-1546 (2011)
Zhou Y, Jiang X. "Dissecting Android malware: Characterization and evolution", in Proc. of the IEEE Symposium on Security and Privacy. IEEE, pp. 95-109, 2012.
151
References
Zhou Y, Wang Z, Zhou W, Jiang X. “Hey, you, get off of my market: Detecting malicious apps in official and alternative Android markets”, in Proc. of the 19th Network and Distributed System Security Symposium. USA; 2012.
152
Appendix
Appendix
A. Security evaluation of web browsers This subsection includes supplementary material for Chapter 3.
List of controls. Table 40 summarizes the common security controls that were found in the browsers’ interfaces, along with a short description.
Hidden menus. The following hidden menus were found in security settings of the surveyed browsers.
Table 39. Hidden functionality in browsers
Hidden element Element location Browser
ABrowser private menu about:debug Android (v. ICS, JB) private browsing tabs icons-> menu device key -> new incognito tab Chrome all private menu about:about Chrome block referrer execute Chrome with the parameter “—no-referrers” Firefox all private menu about: about Safari developers tools hidden menu item configurable from the advanced menu settings. Safari alter user-agent develop (must be enabled see above) -> user agent-> other… Chrome alter user-agent l5->Developer Tools->Settings-Overrides IE alter user-agent l1-Developer Tools->Tools-Change user agent string
Navigation to proxy configuration. Assuming that the user is in the browser’s configuration interface, i.e. either the browser’s menu (e.g. Chrome Mobile, Firefox Mobile), or device menu (e.g. iPhone Safari settings), the following navigation clearly violates the three-click rule; hence it is more likely that the control will not be found.
153
Appendix
Table 40. List of common controls that appear in browser settings
c# Control label Short Description 1. Auto update exten- Configures the browser to auto update extensions\add-ons sions 2. Auto update plugins Configures the browser to auto update plugins 3. Block cookies Deny any cookie 4. Block images Deny images in web content 5. Block location data Deny location data 6. Block pop-ups Blocks pop-up messages 7. Block referrer Blocks the referrer field in the HTTP header 8. Block third-party Denies cookies from third-party domains cookies 9. Browser update Settings for browser update 10. Certificate manager Allows viewing and editing of trusted CA certificates and user certificates 11. Certificate Warning Displays a warning for rogue certificates 12. Disable extension Disables individual extension 13. Disable java Disables java (separate setting from plugins) 14. Disable JavaScript Disables JavaScript 15. Disable plugin Disables individual plugin 16. Enable do-not-track Settings regarding the DNT field in the HTTP header 17. External plugin Initiate web based search of plugin vulnerabilities. This service is check offered by Mozilla 18. History manager Allows viewing and modifying of the browsing history 19. Local blacklist Blacklist that allows per-site configuration of other controls such as block cookies. block images, etc. 20. Malware protection Blacklist for domain that are known to contain malicious content 21. Manually update ex- Manually initiate a check and if available an update for an exten- tension sion\add-on 22. Manually update Manually initiate a check and if available an update for a plugin plugin 23. Master password Configure the browser to request password entry before accessing passwords stored on the browser 24. Modify user agent Settings modifying the user-agent field in the HTTP headers 25. Phishing protection Blacklist for domain that are known to host phishing scams 26. Private browsing Configure the browser to start a private browsing session, i.e. one where cookies, cache and passwords entered are not stored in the browsing history 27. Proxy server Configure the browser to use a proxy server 28. Report rogue web- Report via the browser’s menu a web site that host malware or site phishing 30. Search engine man- Add, view and modify the search engine used by the browser ager 31. SSL/TLS version se- Configure the SSL\TLS protocol version that the browser uses. lection 32. Task manager View background information on open tabs, such as memory usage, network usage. 33. Website checking Initiate analysis of the current web site for malware of phishing
154
Appendix
Table 41. Navigation to proxy configuration widget
Path Browser Safari Mobile tap back (settings) -> scroll up -> Wi-Fi -> connected Wi-Fi network (hit blue icon -> scroll down -> http proxy manual -> setting server & port Android Ginger- home button-> options button from device ->settings->wireless and networks-> bread Wi-Fi settings->options button from device ->advanced-> Wi-Fi proxy->fill in proxy details Android ICS/ JB home button-> device’s options button -> settings-> Wi-Fi->on->hold network id* -> modify network-> scroll down-> check show advanced options-> scroll down- > proxy setting -> manual -> scroll down-> fill in proxy details -> tap save *unless the user holds the network id for a few seconds the hidden menu will not appear Windows Phone Settings (General) -> Scroll down to Wi-Fi Option -> Toggle Wi-Fi networking - 7.5 > tap the desired WiFi Network from the list -> toggle Proxy option -> specify any additional proxy options needed
Heatmap data. Tables 42-43 provide raw data for the heatmaps which were presented in Chapter 3, regarding the number of security controls in each browser that are: (a) available and default enabled and (b) manageable by the user.
155
Appendix
Table 42. Number of security controls that are preconfigured and enabled in each browser
Preconfigured & enabled controls # of controls GC MF IE OP AS AB CM FM IM OM Om SM
Annoyance 9 2 2 2 2 2 3 2 3 2 2 1 2 Browser fingerprinting 4 0 0 0 0 0 0 0 0 0 0 0 0 Exploits / Malware 17 4 4 4 4 2 3 2 5 2 3 2 2 Identity theft 8 1 1 1 1 1 0 0 1 0 1 0 1 Interception of network data 4 1 1 1 1 1 1 1 1 1 1 0 1 Phishing 9 3 3 3 3 3 2 2 3 2 3 1 3 Privacy breach 22 4 3 4 3 5 2 1 4 1 3 0 4 Resource abuse 10 1 1 1 1 1 1 0 2 0 1 0 0 Rogue certificates 3 1 1 1 1 1 1 1 1 1 1 0 1 Spam advertisements 5 1 1 1 1 1 1 1 1 1 1 1 1 Technical failure of browser 12 3 3 3 3 1 2 1 4 1 2 1 1
156
Appendix
Table 43. Number of controls that are manageable from users in each browser
Manageability controls # of controls GC MF IE OP AS AB CM FM IM OM Om SM
Annoyance 7 7 7 8 5 6 3 3 1 2 1 2 7 Browser fingerprinting 3 3 3 4 2 2 2 1 1 1 0 1 3 Exploits / Malware 10 13 11 12 8 4 3 4 1 2 0 2 10 Identity theft 5 7 7 8 3 1 3 3 0 1 0 3 5 Interception of network data 2 2 3 3 0 2 1 0 0 1 0 0 2 Phishing 6 7 8 8 4 4 3 0 0 2 0 3 6 Privacy breach 16 17 18 21 11 7 7 9 3 3 2 5 16 Resource abuse 7 7 8 8 4 2 1 2 0 0 0 1 7 Rogue certificates 2 2 2 2 0 2 1 0 0 1 0 0 2 Spam advertisements 5 5 5 5 3 2 1 0 0 1 1 1 5 Technical failure of browser 8 9 6 6 6 2 1 3 0 0 0 1 8
157
Appendix
B. Security evaluation of browser add-ons Table 44. Number of add-ons in each browser (n=227) 1st level 2nd level AS GC IE MF OP Content filtering - 7 15 0 17 18 Parental control - 2 10 0 4 53 Passwords - 14 10 0 6 41 Generators 4 6 0 4 20 Managers 14 7 0 5 32 Plain proxy - 0 5 0 6 12 Privacy - 4 5 0 10 30 Protection from - 7 13 0 8 39 rogue websites Antivirus 2 3 0 3 10 Malware 4 5 0 3 17 Phishing 4 2 0 2 11 Reputation 2 7 0 3 17 Sandbox 2 3 0 3 8 Third-party software - 2 5 0 6 15 Tracking - 10 10 7 17 53 SM redirection 3 0 0 0 5 Traffic encryption - 1 8 0 5 20 via proxy Total 38 65 7 65 52
Apple Safari. 1Password, AdBlock Lite, Adblock Plus, Adguard AdBlocker, Avatier Single Sign-On (SSO), Blur, Bonafeyed, Cognisec Workspace Application Helper, Cryptocat, Cryptonify, DisableGoogleRedirect, Dr.Web LinkChecker, Facebook Disconnect, Ghostery, Google Disconnect, HyprKey Authenticator, Incognito, JavaScript Blocker, Keeper - Password and Data Vault, LastPass, Mitto Password Manager, MyPermissions Cleaner, PoliceWEB.net, Redirector, RoboForm Online, SafariSGP, Safe In Cloud, SafeSurf, Search Virustotal.com, Security Plus, SID, Teddy ID Password Manager, Total Defense TrafficLight, TrafficLight, Twitter Disconnect, uBlock, URLFilter, WOT. Google Chrome. 1Password, AdBlock, Adblock Plus, Adblock Plus Pro, Adblock Super, Ad-blocker for Gmail, Adguard AdBlocker, Adult Blocker, Avast Online Security, AVG Do Not Track, AVG PrivacyFix, Bitdefender QuickScan, Blockfilter | The Advanced Adult Filter, Blocksi Web Filter, Blur, Browsec, Cache Killer, Clear Cache, Clear Cache Shortcut, CommonKey Team Password Manager, Cookie Manager, CyberGhost VPN, Deadbolt Password Generator, Do Not Track, DotVPN, Dr.Web Anti-Virus Link Checker, EditThisCookie, eSafely, Falcon Proxy, FlashControl, FreeMyBrowser, Ghostery, Hide Images, HTTPS Everywhere, iNetClean porn filter - protect your family, LastPass, Parental Control App, Parental Controls & Web Filter from MetaCert, Passter Password Manager, Password Hasher Plus, PasswordBox, Privacy Badger, Privacy Guardr, Privacy manager, Proxy
158
Appendix
Auto Auth, Proxy Era, Proxy Helper, Proxy SwitchyOmega, Proxy SwitchySharp, ScriptBlock, ScriptSafe, Secure Downloader, Secure Passwords, Security Plus, Simple JavaScript Toggle, Simply Block Ads!, StopItKids parental control, Strong Password Generator, Swap My Cookies, Vanilla Cookie Manager, VTchromizer, WebFilter Pro, Webmail Ad Blocker, YouDeemIt - Parental Advice System, ZenMate Security & Privacy VPN. Internet Explorer. EasyList Standard, EasyPrivacy, Indonesian EasyList, PrivacyChoice - all companies, PrivacyChoice - Block companies without NAI, Stop Google Tracking, TRUSTe. Mozilla Firefox. Ad Killer, Adblock Edge, AdBlock for Firefox, AdBlock Lite, Adblock Plus, Adblock Plus Pop-up Addon, Advanced Cookie Manager, anonymoX, Anti-Porn Pro, Autofill Forms, AutoProxy, AVG Do Not Track, BetterPrivacy, Bitdefender QuickScan, BlockSite, Bluhell Firewall, Blur, BugMeNot, Censure Block, Clear Console, Click&Clean, Cookie Monster, Cookies Manager+, Disable Anti-Adblock, Disconnect, Dr.Web LinkChecker, DuckDuckGo Plus, Empty Cache Button, Facebook Disconnect, FB Phishing Protector, Flash Block, Flash Control, friGate, Ghostery, Google Privacy, Google search link fix, Hide My Ass! Web Proxy, JavaScript Deobfuscator, KeeFox, LastPass Password Manager, Lightbeam for Firefox, McAfee Security Scan Plus detection, Modify Headers, Multifox, NO Google Analytics, NoScript Security Suite, Password Exporter, Private Tab, ProCon Latte Content Filter, ProxTube - Unblock YouTube, Public Fox, QuickJava, RefControl, RequestPolicy, Saved Password Editor, Self-Destructing Cookies, SSL Version Control, Stealthy, Strict Pop-up Blocker, Tamper Data, User Agent Overrider, Web of Trust, WorldIP, YesScript, ZenMate Security & Privacy VPN. Opera. Ghostery, ZenMate, WOT, LastPass, Dr.Web Link Checker, DotVPN, HTTPS E- verywhere, History Eraser, Avira Browser Safety, Browsec, Disconnect, CyberGhost VPN, Blur, AVG PrivacyFix, VPN.S HTTP Proxy, MyPermissions Cleaner, HideMy Ass, PasswordBox, Adult Blocker, Google Analytics Opt-out, Cryptocat, History On/ Off, RoboForm Lite Password Manager, µMatrix, Location Guard, Blocksi, SingleClick Cleaner, Security Plus, SimpleClear, Facebook Redirect Fixer, Stop-it, SafeBrowser, Show passwords, Local pass store, BlocksiLite, Show Password, Cobra Online Security ATD, Disconnect Privacy Icons, Cookie Jar, IvlogSafe, Blockfilter, KANOPE, Google Safe Browsing, Filter request headers, Twitter Redirect Fixer, PasswordMaker Pro, Certified Messages, Floodwatch, vPass, Limitlesslane, LogMote, PreferSafe.
159
Appendix
C. Malware material Table 45. Desktop browser popularity
Source: http://gs.statcounter.com/ (June-July 2014)
Browser Use percentage Chrome 46.03% Internet Explorer 25.87% Firefox 20.04% Safari 4.93% Opera 1.3% Other 1.84%
Table 46. Browser popularity on Android
Based on the number of installs from Google Play (as of Jul 2014)
Browser Million installs Opera Mini 100-500 Chrome Mobile 500-1000 Firefox Mobile 50-100 Opera Mobile 50-100 Android Browser In all browsers
Table 47. Default CIF feeds http://aper.svn.sourceforge.net/svnroot/aper/phishing_reply_addresses http://data.phishtank.com/data/online-valid.json.gz http://malc0de.com/rss http://mirror3.malwaredomains.com/files/bulk_registrars.zip http://mirror3.malwaredomains.com/files/domains.zip http://mirror3.malwaredomains.com/files/url_shorteners.zip http://reputation.alienvault.com/reputation.data http://s3.amazonaws.com/alexa-static/top-1m.csv.zip https://feodotracker.abuse.ch/blocklist/?download=badips https://feodotracker.abuse.ch/blocklist/?download=domainblocklist https://feodotracker.abuse.ch/blocklist/?download=ipblocklist https://spyeyetracker.abuse.ch/blocklist.php?download=domainblocklist https://spyeyetracker.abuse.ch/blocklist.php?download=ipblocklist https://spyeyetracker.abuse.ch/monitor.php?rssfeed=binaryurls https://spyeyetracker.abuse.ch/monitor.php?rssfeed=configurls https://spyeyetracker.abuse.ch/monitor.php?rssfeed=dropurls https://zeustracker.abuse.ch/blocklist.php?download=domainblocklist https://zeustracker.abuse.ch/blocklist.php?download=ipblocklist https://zeustracker.abuse.ch/monitor.php?urlfeed=binaries https://zeustracker.abuse.ch/monitor.php?urlfeed=configs https://zeustracker.abuse.ch/monitor.php?urlfeed=dropzones http://www.malwaredomainlist.com/updatescsv.php http://www.mirc.com/servers.ini http://www.spamhaus.org/drop/drop.lasso http://www.spamhaus.org/drop/edrop.txt http://dragonresearchgroup.org/insight/sshpwauth.txt http://dragonresearchgroup.org/insight/vncprobe.txt http://www.openbl.org/lists/date_all.txt
160
Appendix
Table 48. Percentage of URLs that were blacklisted Browser Blacklisted Results Q2 2014 (n=1400) Results Q1 2014 (n=5651) Safari Mobile (iOS) 38.7% 75% Firefox Mobile (Android) 85.4% 85.3% Opera Mobile (Android) 75.9% 78.7% Firefox (Windows) 86.7% 94.9% Chrome (Windows) 93% 94.5% Opera (Windows) 77.9% 87.1% IE (Windows) 48.4% 64.6%
Table 49. Percentage of false negatives Browser False negatives Results Q2 2014 Results Q1 2014 Safari Mobile (iOS) 26.4% 13.3% Firefox Mobile (Android) 3.4% 3% Opera Mobile (Android) 7.9% 1.5% Firefox (Windows) 5.9% 2% Chrome (Windows) 1.3% 1.7% Opera (Windows) 8.4% 1.4% IE (Windows) 9.9% 6.7%
Table 50. Percentage of URLs that were manually verified as non-phishing Browser Non-phishing Results Q2 2014 Results Q1 2014 Safari Mobile (iOS) 34.9% 11.5% Firefox Mobile (Android) 11.1% 11.7% Opera Mobile (Android) 16.3% 19.8% Firefox (Windows) 7.3% 3% Chrome (Windows) 5.7% 3.8% Opera (Windows) 13.7% 11.5% IE (Windows) 41.7% 28.7%
161
Appendix
Table 51. Malicious file detection based on the hash of the samples AV Engine De- Cumulative AV Engine De- Cumulative % of Malware % of Malware tection % Percent tection % Percent 6 3.6 3.6 44 1 57.1 7 1 4.6 54 0.5 57.7 9 2 6.6 56 1 58.7 10 0.5 7.1 60 0.5 59.2 11 1 8.2 61 0.5 59.7 12 1.5 9.7 63 1 60.7 13 1 10.7 65 1 61.7 14 0.5 11.2 67 2.6 64.3 15 2.6 13.8 68 1 65.3 17 2.6 16.3 69 1.5 66.8 19 1 17.3 70 1 67.9 20 1 18.4 71 0.5 68.4 22 1 19.4 72 0.5 68.9 24 2.6 21.9 73 0.5 69.4 25 0.5 22.4 74 3.1 72.4 26 4.1 26.5 75 1 73.5 27 0.5 27 76 3.1 76.5 28 1 28.1 77 1 77.6 29 0.5 28.6 78 3.1 80.6 30 4.1 32.7 79 2 82.7 31 4.1 36.7 80 1 83.7 32 1 37.8 81 3.6 87.2 33 4.1 41.8 82 1.5 88.8 34 0.5 42.3 83 0.5 89.3 35 1 43.4 85 1.5 90.8 36 0.5 43.9 86 0.5 91.3 37 5.6 49.5 87 4.6 95.9 38 2 51.5 88 0.5 96.4 39 2.6 54.1 89 2 98.5 40 1 55.1 90 1 99.5 43 1 56.1 91 0.5 100
Table 52. Malicious file detection based on file analysis (submission of the file) AV Engine De- Cumulative AV Engine De- Cumulative % of Malware % of Malware tection % Percent tection % Percent 19 0.4 0.4 48 29.3 53.7 25 0.4 0.9 49 13.5 67.2 26 0.4 1.3 50 9.6 76.9 33 0.4 1.7 51 2.2 79 34 0.4 2.2 52 4.8 83.8 35 0.9 3.1 53 3.1 86.9 38 0.4 3.5 54 4.8 91.7 43 0.4 3.9 55 0.9 92.6 44 0.9 4.8 56 3.9 96.5 45 1.3 6.1 57 2.2 98.7 46 5.2 11.4 61 0.9 99.6 47 13.1 24.5 62 0.4 100
162
Appendix
Table 53. VirusTotal AV Engines AVG DrWeb NANO-Antivirus AVware ESET-NOD32 Norman Ad-Aware Emsisoft Panda AegisLab F-Prot Qihoo-360 Agnitum F-Secure Rising AhnLab-V3 Fortinet SUPERAntiSpyware AntiVir GData Sophos Antiy-AVL Ikarus Symantec Avast Jiangmin Tencent Baidu-International K7AntiVirus TheHacker BitDefender K7GW TotalDefense Bkav Kaspersky TrendMicro ByteHero Kingsoft VBA32 CAT-QuickHeal Malwarebytes VIPRE CMC McAfee ViRobot ClamAV McAfee-GW-Edition Zillya Commtouch MicroWorld-eScan Zoner Comodo Microsoft nProtect
Table 54. VirusTotal URL reputation providers ADMINUSLabs Kaspersky SpyEyeTracker AegisLab Malc0de StopBadware AlienVault Malekal Sucuri Antiy-AVL Malware Tencent AutoShun MalwareDomainList ThreatHive Avira MalwarePatrol Trustwave BitDefender Malwarebytes URLQuery C-SIRT Malwared VX CLEAN Netcraft Web CRDF OpenPhish Websense Comodo Opera Webutation CyberCrime PalevoTracker Wepawet Dr.Web ParetoLogic Yandex ESET Phishtank ZCloudsec Emsisoft Quttera ZDB Fortinet Rising ZeusTracker FraudSense SCUMWARE.org malwares.com G-Data SecureBrain zvelo Google Sophos K7AntiVirus Spam404
163
Appendix
D. Private browsing material QUESTIONNAIRE
Athens University of Economics & Business, Dept. of Informatics Information Security and Critical Infrastructure Protection (INFOSEC) Laboratory
This is a voluntary and anonymous questionnaire. Please read the following questions and answer as honestly and responsibly as possible.
Researchers: Nikolaos Tsalis, Ph.D. Candidate ([email protected]), Alexios Mylonas, Lecturer ([email protected]), Vasilis Katos, Professor ([email protected]) Dimitris Grit- zalis, Professor ([email protected])
1. Sex: Male  Female 
2. Age: ....…....
3. Education: PhD  MSc  BSC 
4. Which is the operating system of your personal computer? (you can choose more than one)
Windows  Linux  Mac OS  Other (Please specify ) ………......
5. Which is the browser of your personal computer? (you can choose more than one)
Google Chrome  Mozilla Firefox  Internet Explorer 
Apple Safari  Opera  Other (Please specify) ………………..
6. Do you know what private browsing is?
Yes  No  Not sure 
7. Have you read the browser’s electronic manual about private browsing?
Extensively  Enough  Little  Not at all 
164
Appendix
8. Which of the following artefacts, in your opinion, do not remain in your computer after a private session? (you can choose more than one)
1. Auto-complete form data 
2. Bookmarks 
3. Browser cache memory 
4. Browsing history 
5. Cookies 
6. Download list 
7. Download files 
8. Passwords 
9. Search terms 
10. Add-ons/Extensions 
11. Certificates 
12. Plugins 
13. Settings 
14. Permissions 
15. Translation 
16. Zoom level 
17. Other (Please specify) …...... 
165
Appendix
9. How much would it annoy you if some artefacts did remain in your computer after a private session?
Artefact
Much
A little
Medium
Not at all Not at
I do not know not I do
Auto-complete form      data
Bookmarks     
Browser cache memory     
Browsing history     
Cookies     
Download list     
Downloaded files     
Passwords     
Search terms     
Add-ons/Extensions     
Certificates     
Plugins     
Settings     
Permissions     
Translation     
Zoom level     
Other (please specify)      .....
Thank you for your time and effort
166
Appendix
Table 55 summarizes the results from Q9 of the questionnaire that collected how upset the sample would become if an artefact was recovered by Bob after the private session.
Table 55. Summary of the results regarding how upset the sample would be if an artefact is exposed. Very Up- Little Not up- I do not Artefact upset set upset set know Auto-complete 16.8% 16.7% 14.2% 7.2% 45.1% form data Bookmarks 17% 16.1% 27.1% 34.6% 5.2% Browser cache 23.5% 12.8% 8.8% 9.8% 45.1% memory Browsing history 62.7% 15% 9.2% 11.1% 2% Cookies 52.3% 22.2% 11.1% 8.5% 5.9% Download list 33.3% 24.2% 19.6% 20.3% 2.6% Downloaded files 22.2% 22.9% 17.0% 32% 5.9% Passwords 80.4% 5.2% 6.5% 5.2% 2.7% Search terms 48.4% 18.3% 17.6% 13.1% 2.6% Add-ons / Exten- 18% 28.8% 28.1% 11.4% 13.7% sions Certificates 28.1% 22.2% 16.4% 16.3% 17% Plugins 10.5% 19.6% 28.1% 23.5% 18.3% Settings 14% 22.1% 25.8% 24.7% 13.4% Permissions 20.3% 25.5% 22.2% 17.6% 14.4% Translation 11.2% 12.4% 24.8% 41.8% 9.8% Zoom level 10.5% 11% 24.2% 34% 20.3%
167