Web Applications nowadays are capable of making online video and audio chatting and sometimes without even the need of external *plugins* or *extensions* Hooray!
From usability perspective this is something so cool and very helpful but we are not here for usability, Usability is always cool but when it comes to security concerns, the whole idea is a nightmare when poorly configured or implemented!
What we are showing case here is something that MUST concern YOU as Business owner, Developer, Executive, or even normal user!
Taking advantage of the user’s built trust!
You are someone who loves usability, getting everything done without taking more actions, you don’t want to repeatedly allow your beloved browser for granting access to your microphone or camera are you?
Getting everything done with less efforts is something built on top of trust, the trust you have built over those years between you and your web browser so to narrow down the times you grant access to your microphone and camera is to “Always Allow” browser to access those devices because why not? I’m trusting Chrome, You trust Firefox, Everyone trusts his own browser right?
BUT Trusting the browser doesn’t mean trusting the website that uses your browser to flow this amount of HTML and Javascript to you, That’s totally different that’s why lately browsers started to be aware and invest more into security even if this investment against the usability experience, Now browsers are asking the user to allow or disallow access to the previous mentioned devices per website not only per app what does that mean?
Assuming that a web-based chatting website called “A.com” and you entered this website making a video chat session, your beloved browser will ask you for permission to use Camera and Microphone ONLY for “A.com” which is an exclusive access only dedicated to this website. So what’s wrong? As a user trusts his/her own browser and “A.com” as a favorite website so why not allowing both those beloved friends a permanent access to the webcam and the microphone?
DO NOT DO THAT, JUST DON’T
Forget the PERMANENCY in granting accesses to anything because it might be granting access to a nightmare very soon and we will know why later!!!
Why it’s a bad idea to permanently allowing your trusted browser and favorite website to access your cam/mic?
In web there are a lot of vulnerabilities that can pose a threat on enduser’s safety and/or browser’s security too there is the beloved “Remote Code Execution” which may result in compromising the server hosting your lovely chat service and end up infecting the executables you use to make the chat client or infecting its update instances resulting in backdooring your machine but let’s talk about only one kind of typical vulnerabilities here that may always sounds as a low severity but “low severity” is just a contextual risk measurement, This vulnerability called “Clickjacking” so let’s dive into it:
Clickjacking
Clickjacking, also known as a “UI redress attack”, is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page. Thus, the attacker is “hijacking” clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both.
Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker.
A look into Alexa Top websites when it comes to fighting this type of vulnerabilities:
Alexa Top websites are the most visited websites in the internet and those numbers shows how many of those websites are taking care of Clickjacking issue by implementing Framebusting techniques:
Alexa Top Web Sites Uses Framebusting (%)
Source: https://blog.qualys.com/securitylabs/2012/11/29/clickjacking-an-overlooked-web-security-hole
Top 500 14%
Top 100 37%
Top 10 60%
Sounds as an overhyped vulnerability? So Why Aren’t Web Sites Taking Measures to Protect Against Clickjacking?
There could be many answers to this question, but I think three main factors contribute to ignorance of clickjacking vulnerabilities in web sites.
1. Clickjacking is not considered a serious issue because it is hard to manipulate.
I believe this is the most common reason. Some web developers consider clickjacking lower risk since it is harder to get sensitive information from an end-user, as compared with other attacks like XSS and SQL injection. However, the clickjacking attacks on Facebook in 2010 showed that harm is done even by sending spam to everyone in your address book.
Also, when a web site is vulnerable to clickjacking, it is possible for the attacker to disable cross-site request forgery (CSRF) token protection, which protects against CSRF attacks that trick browsers into doing things without the user’s knowledge or permission.
2. Countermeasures for clickjacking are not reliable.Many countermeasures have been described that help web users protect against clickjacking attacks. But currently the only way that could completely prevent clickjacking attacks is to use a web browser like Lynx, a pure text-based web browser that doesn’t support JavaScript. Not only is Lynx outdated, but it’s hard to imagine a modern web site user experience without the use of JavaScript.
According to Robert Hansen, one of the first people to discover this vulnerability, “the combination of Firefox and NoScript, an extension that blocks JavaScript, Flash and Java content, would keep you safe from ‘a very good chunk of issues, 99.99% at this point’.” But again, the trade-off is a diminished user experience because JavaScript is blocked.
3. Lack of awareness
Because clickjacking is a relatively new malicious technique, the damage caused by this vulnerability is not widely known.
Source: https://blog.qualys.com/securitylabs/2012/11/29/clickjacking-an-overlooked-web-security-hole
Why ClickJacking and Framing vulnerabilities are still dangerous in 2019?
Since we begin our question with “Why” then we admit that this vulnerability is dangerous, in fact the the above mentioned numbers showed how many websites took care of this vulnerability and how many neglected it.
A simple click to join a chat room can be a chaotic decision where you as the enduser joined a chat room controlled by the attacker without your consent and your previously access-granted beloved chat/conference/video-audio website will became your worst nightmare, A chat room controller is now hearing your surrounding voice and watching you perhaps NAKED!
Cross Site Request Forgery (CSRF)
Another player is common in this game with those attack scenarios called Cross Site Request Forgery (CSRF) A Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.
We learned that a Clickjacking vulnerability might fool the endusers into clicking on a “Join Room” button to initiate a join request to a chatting room without their consent but when it comes to CSRF it’s way dangerous because in this vulnerability you may don’t have to click on ANYTHING, all you need to do is a visit to an innocent-looking website which hosts an iframe (due to the lac of Clickjacking protection in the destination service) or just an image tag that forges the join request on your behalf to a video conferencing or chatting service and BOOM you’re in the chatting room again repeating the same explained scenario:
<img src="https://VideoConferencingWebsite.com/room/hello/join">Browser’s security is not sufficient or Why we love macOS :)?
They said “A picture is worth a thousand words” so we will let you realize why with this screenshot:
macOS starting from Mojave started focusing on all those special permissions on the OS level, They were very sure that there is always will be a threat out of the innocent user’s decision to approve or grant something so Apple developers implemented this natively in the OS level you can read more about Mojave’s Privacy features here!
We love operating systems which consider the “Secure by Design” approach, fragmentation problems makes it vey hard on OS manufacturers to suit and fulfill the demands of OEMs repeatedly changing specs and standards, Imagine Windows OS want to protect you by natively controlling all the connected devices but can’t hook the native functionalities of every Microphone or Video Cam drivers in the market that makes Apple the leading manufacturer because of their control on both OS and hardware.
In security nothing is enough and everything is not enough, It's all a trade off!— Mohamed A. Baset (@SymbianSyMoh) July 13, 2019
In security everything is a trade off, you must abandon something, you must let something go to let something comes, If you thought about “Usability” congrats, That’s right, leaving comfort zone for a greater good is something very considered when it comes to security, preventing yourself from permanently granting access to a website even if assuming it is 100% secure which there is nothing called so is a nightmare i hear you whispering it but it’s better than a bigger nightmare of your privacy evasion right?
Showcases and Researches done
We at Seekurity have done a research on the top used video-conferencing and audio/video chatting services like (Zoom.us, Rabb.it, Appear.In, Skype and many others under investigation).
The research done here started back in 2016 when i started digging into this issue in video conferencing and web-based audio/video chat apps in particular
Let’s dive into some examples:
1. Rabb.it
– Date: May 1st, 2016 (uploaded PoC video on Apr 30, 2016)
– Vulnerability: Combination of Clickjacking and CSRF
– Impact: A/V Eavesdropping
– User Interaction: Not Required
– Description:
What we found in the web-based audio/video chatting app is a CSRF vulnerability allowed us to forge a join chat request led to eavesdropping on any enduser who is a victim to this attack, what we used to weaponize this proof of concept is an framing vulnerability to have the join request to load inside our controlled iframe, then we demonstrated a Man in the Middle (MITM) attack inside our Local Area Network then we were able to automatically and without any interaction from the enduser to force join the enduser in our controlled video chatting room hence snooping on video/audio communications very easily without even asking for any cam/mic permissions. A question for you Why you think this happened?
– PoC(s):
2. Appear.in
– Date: Oct 28th, 2017 (recently uploaded PoC video)
– Vulnerability: Combination of Clickjacking and CSRF
– Impact: A/V Eavesdropping
– User Interaction: Not Required
– Description: N/A
– PoC(s):
Update: appear.in reached out to us and informed us that the service was updated a while back to block this kind of usage, so the technique demonstrated in the PoC from 2017 is no longer possible to perform.
3. Zoom.us
– Date: Jan 1st, 2018 (recently uploaded PoC image)
– Vulnerability: Combination of Clickjacking and CSRF
– Impact: A/V Eavesdropping
– User Interaction: Not Required
– Description: N/A
– PoC(s):
4. Skype
– Date: Aug 12th, 2016
– Vulnerability: Clickjacking
– Impact: User account manipulation
– User Interaction: Required
– Description: N/A
– PoC(s):
5. GoToMeeting
– Date: Jul 19th, 2019
– Vulnerability: CSRF
– Impact: GoToMeeting Voice Eavesdropping
– User Interaction: Auto use of microphone must be preconfigured
– Description: We worked closely with GoToMeeting security team to responsibly disclose this security vulnerability, fix and verify it to protect the tens of millions of users of the service around the globe.
The team was very responsive in a way that reflects how they are understanding and handling a security vulnerability in their products as they had a history of working side by side with security researchers.
The official statement from GoToMeeting official website: https://blog.gotomeeting.com/logmein-security-researchers/
– PoC(s):
6. More to come and under research…
Other vulnerable services:
– jit.si: Vulnerable to clickjacking.
– TBD
Giveaways and lessons
For Developers:
Read and apply the security best practices:
- Framekiller, Framebusting, X-Frame-Options
A framekiller is a technique used by web applications to prevent their web pages from being displayed within a frame. A frame is a subdivision of a Web browser window and can act like a smaller window. It’s usually deployed to prevent a frame from an external Web site being loaded from within a frameset without permission often as part of clickjacking attack. - Content Security Policy or CSP
Content Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context. It is a Candidate Recommendation of the W3Cworking group on Web Application Security, widely supported by modern web browsers. CSP provides a standard method for website owners to declare approved origins of content that browsers should be allowed to load on that website—covered types are JavaScript, CSS, HTML frames, web workers, fonts, images, embeddable objects such as Java applets, ActiveX, audio and video files, and other HTML5 features. - Same-Origin Policy or SOP
In computing, the same-origin policy is an important concept in the web application security model. Under the policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, host name, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page’s Document Object Model.
This mechanism bears a particular significance for modern web applications that extensively depend on HTTP cookies[1] to maintain authenticated user sessions, as servers act based on the HTTP cookie information to reveal sensitive information or take state-changing actions. A strict separation between content provided by unrelated sites must be maintained on the client-side to prevent the loss of data confidentiality or integrity.
It is very important to remember that the same-origin policy applies only to scripts. This means that resources such as images, CSS, and dynamically-loaded scripts, can be accessed across origins via the corresponding HTML tags[2] (with fonts being a notable exception[3]). Cross site request forgery attacks take advantage of the fact that the same origin policy does not apply to HTML tags.
For Normal Users:
- Stay aware, Read security news.
- Don’t click on links you don’t know.
- If you are on any OS and you’ve been asked to allow cam/mic access and you haven’t done anything requires so, run away, don’t continue and allow it, close the window, the app, the ANYTHING that led to.
- Your Mac green cam led indicator is the most important sign of your camera is being used by some other app.
For Bug Hunters:
- Look for the presence of “X-Frame-Options” response header and/or CSP rules while testing an app to check if it’s mitigating Clickjacking or not.
- Clickjacking itself is not enough attack vector and many websites which have responsible disclosure rules and/or participates in Bug Bounty Programs are very clear about Clickjacking and sometimes they are excluding it from the scope if it is not actionable or not pose a real threat, so no random reporting, focus, clear and demonstrate a real attack scenario with less user interaction.
- Test forms GET/POST against Cross Site Request Forgery and don’t celebrate if you didn’t find an Anti-CSRF token in the form request body as there are lots of ways to protect a request from being forged (eg. Referrer protection, Same Origin Policy, etc…)
- Web-based Chat/video conferencing applications are very prone to this type of attacks, test them and try to get the most of your attack scenario. Sometimes a CSRF or a Clickjacking may lead to Remote Code Execution due to a vulnerable Desktop client or leaking data in a form of a return response.
Sources and Copyrights:
– https://media.dhakatribune.com/uploads/2019/01/oped-biz-1546361616882.jpg
– https://www.pubnub.com/blog/wp-content/uploads/2018/10/webrtc-video-chat-chatengine.png
– https://blog.qualys.com/securitylabs/2012/11/29/clickjacking-an-overlooked-web-security-hole
– https://support.duolingo.com/hc/article_attachments/360008719291/mceclip3.png
– https://www.darknet.org.uk/2017/07/all-you-need-to-know-about-cross-site-request-forgery-csrf/
– https://support.duolingo.com/hc/article_attachments/360008719291/mceclip3.png
– https://media.wired.com/photos/59a755151de1ff1b1b6172d0/master/w_582,c_limit/WebcamVisitation.png
A minute if you please!
Building a website, an application or any kind of business? Or already have one? Worried about your security? Think twice before going public and let us protect your business!
Previous Next