Search This Blog

Showing posts with label Chrome. Show all posts

Users can now Use 2 Step Verification on their Chrome and Safari Browser


Google has launched a new feature for ensuring users' security. You will now be able to enroll for 2 Factor Authentication Keys from Web browsers. Google is allowing you to enroll security keys on Android and macOS devices by making it easier to register for keys. "Two-factor authentication, also called multiple-factor or multiple-step verification, is an authentication mechanism to double-check that your identity is legitimate."


When you sign in into your account it asks for a username and password, this is the first verification process. Two-factor authentication adds another security layer after this to confirm your identity. It (2FA) could be a pin, a password, a one time password, a physical device, or biometric. It should be something only you have to know. Two-factor authentication is very important as a password isn't as protective as we believe. Cyber attackers can test billions of password combinations in a second.

Two-factor authentication or two-step verification adds another layer of protection besides a password, and it is hard for cybercriminals to get this second factor and reduces their chance to succeed. Now Google is offering these 2FA authentication keys, and you can register for these on macOS devices using Safari (v. 13.0.4 and up), and Android devices running Android 7.0 “N” and up, using the Google Chrome web browser (version 70 and up). Users can register these independently or with those who have signed up for the Advanced Protection Program. It's available for all users given you're using the mentioned version of the software.

What is Security Keys? 

Security Keys are the most secure form of two-factor authentication (2FA) or two-step verification to protect against various threats like hacking and phishing. Users are provided with physical keys that they can insert into the USB port of their device, when required the user will touch the key. On Android devices, the user will have to tap the key on their NFC ( Near Field Communication) enabled device. Android users can also opt for USB and Bluetooth keys. Apple mobile users will be provided Bluetooth-enabled security keys.

Google Cuts Down Chrome's Patch-Gap in Half, from 33 to 15 Days now


Last week, Google has announced the cutting down of 'patch gap' in half for Chrome and the future plans of cutting it down further are also making the headlines.

Security Engineers at Google told that the 'patch gap' for Google Chrome which earlier was 33 days has now been successfully reduced to only 15 days. Some of you might be wondering what exactly a 'patch gap' means, it refers to the time frame it takes from when a security bug gets fixed in an open-source library to when that fix reaches in software which used that library.

These days, when the software ecosystem contains most of the apps relying upon the open-source modules, patch-gap plays a major role as it creates a potential security risk.

How Patch-Gap involve Major Security Risk?

As soon as a security bug gets fixed by someone in a particular open-source library, all the details related to that bug become available in the public domain. It is simply because of the open nature of the open-source libraries and projects. Now, the software which is largely dependent on these easily accessible components available in open source libraries, become vulnerable to the attacks and exploits that hackers can craft by exploiting the details regarding the security flaws.

How Patch-Gap will be Useful?

Considering the likeliness of the aforementioned possibility, if the software developers are releasing patches on a fixed release schedule which includes updates incoming every week or in a couple of months, the patch-gap here will allow hackers to set-off attacks that most software will have difficulty in dealing with.

A member of the Chrome Security team, Andrew R. Whalley said, "We now make regular refresh releases every two weeks, containing the latest severe security fixes,"

"This has brought down the median 'patch gap' from 33 days in Chrome 76 to 15 days in Chrome 78, and we continue to work on improving it," he further told.

Apple Engineers to Standardize the Format of the SMS Messages Containing OTPs


A proposal comes from Apple engineers working at WebKit, the core component of the Safari web browser, to institutionalize the format of the SMS messages containing one-time passwords (OTP) that users receive during the two-factor authentication (2FA) login process.

 With 2 basic goals, the proposal aims initially is to introduce a way that OTP SMS messages can be associated with a URL, which is essentially done by adding the login URL inside the SMS itself.

And the second being to institutionalize the format of 2FA/OTP SMS messages, so browsers and other mobile applications can undoubtedly distinguish the approaching SMS, perceive web domain inside the message, and afterward consequently extract the OTP code and complete the login operation moving forward without any further user interaction.

According to the new proposal, the new SMS format for OTP codes would look like below:

747723 is your WEBSITE authentication code. 
@website.com #747723 

The first line, intended for human users, permits them to decide from what site the SMS OTP code originated from and the second line is for both human users as well as for applications and browsers.

 Applications and browsers will consequently extricate the OTP code and complete the 2FA login operation. In the event that there's a 'mismatch' and the auto-complete operation falls flat, human readers will have the option to see the site's original URL, and contrast it with the site they're attempting to login.

On the off chance that the two are not similar, at that point, users will be alerted that they're very a phishing site and forsake their login activity.

When browsers will deliver components for reading SMS OTP codes in the new format, significant providers of SMS OTP codes are required to switch to utilizing it. Starting now, Twilio has already communicated its enthusiasm for actualizing the new arrangement for its SMS OTP administrations. 

Presently, while Apple (WebKit) and Google (Chromium) engineers are quite energetic about the proposition, Mozilla (Firefox) has not yet given an official criticism on the standard yet.

Vulnerability in Chrome Allows To Virtually Take Over Any Android-Based Device



A critical vulnerability in Chrome for Android apparently exploited and displayed in a quite popular hacking contest is now being known to empower anybody with specialized technical expertise to remotely take control for all intents and purposes any Android-based device. 
Found by PacSec speaker Guang Gong from Qihoo 360 at Pwn2Own the vulnerability in Google's JavaScript v8 is said to purportedly influence all renditions of Android running the latest version of Chrome. 
What makes this specific vulnerability stand out amongst the remaining of the already established hazardous and risky ones is that being a 'one shot exploit', just one is sufficient to remotely hack the device. 
At first, the user is tricked into visiting a vindictive website on Chrome and once there, an attacker effectively installs an arbitrary application into the device thusly gaining full privileges. 
"As soon as the phone accessed the website the JavaScript v8 vulnerability in Chrome was used to install an arbitrary application (in this case a BMX Bike game) without any user interaction to demonstrate complete control of the phone," it was reported.
Despite the fact that android fixed 33 vulnerabilities, in which, 9 vulnerabilities were categorized under critical severity and rest of the 24 were fixed under "high" severity.
Until now no more insights regarding the exploits have been unveiled. Google, on the other hand has purportedly been made mindful of the Chrome vulnerability, regardless of whether it has been fixed is yet to be affirmed.

Hackers Now Tricking Users with Fake Address Bars on Chrome



Hackers now take the aid of another and a rather refined phishing attack on Android Chrome only so to shroud the original address bar's screen space by showing its very own fake URL bar when the user scrolls down the site's page.

The fake address bar that relates with the phishing website page posed with real webpage URL by intercepting the original chrome bar. Typically, when users scroll down the site's page, the browser shrouds the URL bar and the page covers overlaps on it in light of the fact that the page is accessible to by means of a "trustworthy browser UI".

Here, the phishing site manhandles this procedure by displaying its very own fake URL bar that acted like an authentic one and trapped users to give away their own personal information.
Security researcher James Fisher exhibited this phishing attack by facilitating his own domain (jameshfisher.com), as he exploited the blemish in chrome browser for mobile.

Fisher used the HSBC domain (www.hsbc.com) as a fake URL bar to proceed with the said demonstration  and by utilizing a similar way the attackers resort to when they utilize any legitimate site, intercept the URL bar and steal the information.

Specialist call it as "scroll jail", when this attack gets even worse for wear, for the most part when the users look up the site page however again reach the first URL bar, here the attackers trap the users to never return on the original URL bar.

According to Fisher, the attack resembles in a dream in inception, the user believes that they're in their own browser, yet they're actually in a browser inside their browser.

 “Is this a serious security flaw? Well, even I, as the creator of the inception bar, found myself accidentally using it! So I can imagine this technique fooling users who are less aware of it, and who are less technically literate. The only time the user has the opportunity to verify the true URL is on page load, before scrolling the page. After that, there’s not much escape”, says Fisher, who is also of the believe that it might be a security flaw in Chrome browser causing the commotion.

Chrome Utilized for iOS Vulnerability by a Threat Group to Bypass the Browser's Built-In Pop-Up Blocker



eGobbler, a threat group recently targeted iOS users from the U.S. alongside various European Union Countries through numerous massive malvertising attacks for almost a week and utilized Chrome for iOS vulnerability to sidestep the browser's built-in in pop blocker.

The said threat group utilized "8 individual campaigns and more than 30 fake creatives" all through their push, with every one of the fake ad crusades having life spans of somewhere in the range of 24 and 48 hours.

As per the Confiant researchers who found and observed eGobbler's iOS-targeted attacks, approximately 500 million users' sessions were somehow exposed to this extensive scale coordinated campaign pushing counterfeit promotions i.e. fake ads.


As found by Confiant's specialists eGobbler's campaigns more often than not remain active for a maximum limit of 48 hours, quickly pursued by brief times of hibernation which unexpectedly end when the next attack begins.

Some of them are even seen to have used landing pages facilitated on .world domains utilizing pop-ups to hi-jack users' sessions and divert the unfortunate casualties to vindictive pages, as this technique helps the attackers in phishing as well as in malware dropping purposes.

Anyway this campaign was not the first of its kind designed by the eGobbler malvertising group to explicitly target iOS users, as in November 2018, Confiant observed one more campaign kept running by the ScamClub group which figured out how to capture approximately 300 million iOS user sessions and diverted them all adult content and gift voucher tricks.

Be that as it may, as Confiant said in their report, "This really was a standout campaign compared to the others that we track based not only on the unique payload, but the volumes as well?"
They later included that “With almost half a billion user sessions impacted, this is among the top three massive malvertising campaigns that we have seen in the last 18 months."