Search This Blog

Showing posts with label Google. Show all posts

Security Bug Detected in Google’s Android App

 

A vulnerability had existed in Google's eponymous Android app with over five billion downloads to date that might have enabled an attacker to stealthily steal the personal information of a victim's device. 

In a blog post-Sergey Toshin, the founder of Oversecured Mobile App Security Group, noted that it's about the way the Google app relies on code that is not packaged with the app directly. Several Android apps, notably the Google application, decrease download size and storage space by depending on code libraries installed on Android smartphones. 

However, the shortcoming in Google's code allowed the malicious application to inherit the permissions of the Google app and permit it to almost completely access data from a user. 

The malicious application could also pull the code library from a malicious app on the very same device rather than its legitimate code library. This access includes access to Google user accounts, search histories, e-mails, text messages, contacts, and call history, as well as microphone/camera triggering and user location. 

Toshin added that the malicious application will be activated once for the attack to start, but it is carried out without the knowledge or cooperation of the user. He added that removing the malicious program will not remove malicious components from the Google app. 

A Google spokesman told that last month it addressed the issue and there was no proof that the attackers would be using the flaw. The built-in malware scanner of Android, Google Protect Play, will stop the installation of harmful apps. However, there is no absolute safety feature, and malicious apps are already on the internet. 

Toshin stated that the vulnerability in Google's app is almost like a bug identified in TikTok earlier in this year that would allow an attacker to hijack a TikTok user's session tokens which are exploited to gain control of their account. 

Oversecured identified several other identical vulnerabilities, including the Google Play app for Android and more recent pre-installed apps on Samsung phones.

Tim Cook Claims Android has 47 Times the Amount of Malware as iOS

 

During a live chat, Apple CEO Tim Cook stated that Android has more malware than iOS and that "sideloading" mobile software is not in the "best interests of users." Sideloading apps entails manually downloading and installing software over the Internet rather than from an app store. Apple's security and privacy would be ruined if it were compelled to enable side-loading programmes, as Android does, he stated on June 16 while speaking remotely at the VivaTech 2021 conference in Paris, France. 

When asked about the planned European law known as the Digital Markets Act (DMA), which attempts to prohibit big digital corporations from monopolizing their market position, Cook stated that Apple opposes it because it would require the company to allow consumers to install apps outside of the App Store. Cook also stated that Android has "47 times more malware" than Apple since iOS is created with a single app store. 

Explaining the reason, Cook added, "It's because we've designed iOS in such a way that there's one app store and all of the apps are reviewed prior to going on the store. And so that keeps a lot of this malware stuff out of our ecosystem, and customers have told us very continuously how much they value that, and so we're going to be standing up for the user in the discussions." 

Cook further claimed that the DMA's present language, which will compel side-loading on the iPhone, will "destroy the security" of the smartphone and many of the App Store's privacy measures. 

DMA targets firms with a huge user base, such as Apple, Google, and Amazon, and encourages them to open up their platforms to competitors. The proposed rule also intends to provide a more level playing field for businesses and individuals who rely on large "gatekeeper" online platforms to sell their goods and services in a single market. 

“We've been focusing on privacy for over a decade,” Cook stated when asked about Apple's commitment to privacy. “We see it as a basic human right. A fundamental human right. And we've been focused on privacy for decades. Steve used to say privacy was stating in plain language what people are signing up for and getting their permission. And that permission should be asked repeatedly. We've always tried to live up to that.”

Google Meet's Server Down Globally, Twitter Flooded With Complaints

 

Since worldwide lockdown and restrictions over workplaces, schools and universities have been imposed, people are facing several problems. However, it did not stop them from working, and that has only been possible with the use of technology and social media platforms. 

We all have various meetings on Google-Meet and other similar applications owing to their reliability but on 5th June in India, Twitter witnessed many users struggled with server issues. More than 1,000 people have reported facing programs in joining their meetings links via Google-Meet. 

Users those were facing problems have started reporting their issues on many social media platform, including Twitter, requesting Google to solve the glitch as soon as possible. Users were facing server problems since 7 AM in, early morning. Many students were supposed to take classes by the service, they also reported complaints. Meanwhile, several others users have also reported issues related to the audio services. 

Following the event, many users have been found writing about the server issues on Downdetecter, an online platform that facilitates people regarding real-time information about the status of several websites and services. 

Many users are facing problems and they are still awaiting fixes. Although, from the officials, no statement has been published regarding the server down so far. Interestingly, it is about a few days back when Google Meet had introduced a new User Interface (UI) for its Web. 

Here are some glimpse of complaints that users reported; 

"Meet is not working specially for people in North India. I am getting disconnected and can't hear audio and see the presentation," wrote a user on Downdetecter. 

"Meet not working properly, disconnecting automatically and also no audio. Don't fix it's great. Thanks ?? no class today," another user said. 

Several users also took to Twitter to complain. "@GoogleIndia .Google meet not working, it's meeting Left Every time problem getting today after some updates from Microsoft Windows," tweeted a user.

Research Reveals More Than 2000 Chrome Extensions Disabled Security Headers

 

Tens of thousands of Google Chrome extensions accessible from the official Chrome Online Store manipulate security headers on major websites, posing the danger of web attacks for visitors. 

Although the security headers are little known, they are a vital aspect of the present internet ecosystem. A key component of website security is the HTTP security header. When implemented, it protects users against the kinds of attacks most probably happening on the website. These headers protect XSS, injection code, clickjacking, etc. 

In many other cases, as per the research team, they examined CSP and other security headers, deactivated Chrome extensions “to introduce additional seemingly benign functionalities on the visited web page,” and didn't even look like it was nefarious in purpose. That is because Chrome's framework forces extensions in the name of security to do that, paradoxically. Standard extension code could access the DOM page, but no scripts on the page can interact. 

If a user has access to the website, the browser requests the webpage of a server. While websites per se are presented through HTML, JavaScript, and CSS code, website owners can direct the browser to handle the provided material in various ways by adding additional parameters in the HTTP connection header. 

While not all websites have security headers, many of today's leading Web services commonly incorporate them to protect their customers against attacks, as they frequently face more web-based attacks than conventional sites, because of their larger size. 

Although website managers are configuring their security headers, this does not mean that security headers are still in existence at the client-side where such things can be detected and prevented by attackers with a mid-range attack scheme, malware executing on an operating system, or browser extensions. 

Researchers at the CISPA Helmholtz Centre stated that they were trying to evaluate the number of Chrome extensions that have been damaged by the security for the first time headers. 

The research team has studied 186,434 Chrome extensions, which were accessible last year on the official Chrome Web Store, using a custom infrastructure they particularly developed for the research. 

Their analysis discovered that 2,485 extensions intercepted and altered at least one safety header used by the most famous today's Top 100 websites. The study focused on the four most prevalent safety headers: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Frame Options, and X-Content-Type Options. 

While 2485 extensions had disabled at least one, researchers found that 553 were deactivated by all 4 safety headers studied during their investigation. 

CSP, a security header created to enable site owners to regulate what internet resources a page can charge inside a browser as well as a standard defense to prevent websites and browsers from XSS and dataset injections, was the most widely blocked header for security concerns.

Cyber Attackers Hijacked Google and Microsoft Services for Malicious Phishing Emails

 

Over recent months, the cybersecurity industry has seen a huge increase in malicious attackers exploiting the networks of Microsoft and Google to host and deliver threats through Office 365 and Azure. 

The actors who are at risk are quickly moving towards cloud-based business services during the pandemic by concealing themselves behind omnipresent, trustworthy services from Microsoft and Google to make their email phishing scams appear legitimate; and it works. 

In particular, during the first three months of the year 2021, researchers discovered that 7 million malicious e-mails were sent from Microsoft's 365, and also that 45 million were transported from Google's network. The Proofpoint team said that cyber-criminals had been able to send phishing e-mails and host attacks with Office 365, Azure, OneDrive, SharePoint, G-Suite, and Firebase. 

“The malicious message volume from these trusted cloud services exceeded that of any botnet in 2020, and the trusted reputation of these domains, including outlook.com and sharepoint.com, increases the difficulty of detection for defenders,” the report, issued on Wednesday, explained. “This authenticity perception is essential, as email recently regained its status as the top vector for ransomware; and threat actors increasingly leverage the supply chain and partner ecosystem to compromise accounts, steal credentials and siphon funds.” 

Proofpoint estimated that 95% of cloud account organizations had been attacked, and more than half of them succeeded. Additionally, more than 30% of those organizations were compromised. 

Once attackers have access to passwords, they can easily enter or exit several services and send out more, persuasive phishing emails. 

Proofpoint offered many examples of projects behind Microsoft and Google that tried to scam users to give up or deliver their details. 

Attackers exploited Gmail to host another operation throughout March, that provided them with the message of the fake benefits together with a Microsoft Excel attachment, that delivered The Trick Bank Trojan to steal credentials whenever macros were activated. 

Another Gmail-hosted February attack seeks to persuade users to use their passwords for accessing zip-on MS Word documents. Upon opening, Xorist ransomware has been delivered. 

The use of Gmail and Microsoft by attackers to give their emails a patina of credibility is part of a broader trend: threats are developing increasingly persuasive appeals. 

“Our research demonstrates that attackers are using both Microsoft and Google infrastructure to disseminate malicious messages and target people, as they leverage popular cloud-collaboration tools,” the Proofpoint report added. “When coupled with heightened ransomware, supply chain, and cloud account compromise, advanced people-centric email protection must remain a top priority for security leaders.”

Google and Mozilla Develop an API for HTML Sanitization

 

Google, Mozilla, and Cure53 engineers have collaborated to create an application programming interface (API) that offers a comprehensive solution to HTML sanitization. The API will be used in upcoming versions of the Mozilla Firefox and Google Chrome web browsers. 

HTML sanitization is the process of reviewing an HTML document and creating a new HTML document that only contains the "secure" and desired tags. By sanitizing any HTML code submitted by a user, HTML sanitization can be used to defend against attacks like cross-site scripting (XSS).

Sanitation is usually carried out using either a whitelist or a blacklist strategy. Sanitization can be done further using rules that define which operations should be performed on the subject tags. 

When rendering user-generated content or working with templates, web applications are often expected to manage dynamic HTML content in the browser. Client-side HTML processing often introduces security flaws, which malicious actors exploit to stage XSS attacks, steal user data, or execute web commands on their behalf. 

“Historically, the web has been confronted with XSS issues ever since the inception of JavaScript,” Frederik Braun, security engineer at Mozilla, said. “The web has an increase in browser capabilities with new APIs and can thus be added to the attacker’s toolbox.” 

To protect against XSS attacks, many developers use open-source JavaScript libraries like DOMPurify. DOMPurify takes an HTML string as input and sanitizes it by deleting potentially vulnerable parts and escaping them. 

“The issue with parsing HTML is that it is a living standard and thus a quickly moving target,” Braun said. “To ensure that the HTML sanitizer works correctly on new input, it needs to keep up with this standard. The failure to do so can be catastrophic and lead to sanitizer bypasses.” 

The HTML Sanitizer API incorporates XSS security directly into the browser. The API's sanitizer class can be instantiated and used without the need to import external libraries. 

“This moves the responsibility for correct parsing into a piece of software that is already getting frequent security updates and has proven successful in doing it timely,” Braun said. According to Bentkowski, browsers already have built-in sanitizers for clipboard info, so repurposing the code to extend native sanitization capabilities makes perfect sense.

Modem Vulnerabilty Attacks Android Phones, Steals Data and Records Calls

Google and Android manufacturers always aim to keep their hardware and software security robust. However, a vulnerability found in Qualcomm SoCs recently revealed by Check Point Research is quite frightening. The vulnerability can allow a harmful application to patch software with MSM Qualcomm modem chips, which gives the actor access to call logs and chat history and can even record conversations. Check Point Research's breaking down of vulnerability is quite technical. "QMI is present on approximately 30% of all mobile phones in the world but little is known about its role as a possible attack vector," the report says. 

In simple terms, it found vulnerabilities in QMI (Qualcomm Modem Interface) software modem layer and debugger service connections, that let the vulnerability to patch software dynamically and escape the general security mechanisms. General 3rd party applications do not have the safety mechanisms to gain access to QMI, however, if any more critical aspects are exploited in Android, the attack can prove beneficial. Researchers that found the vulnerabilities believe that harmful apps can secretly listen to your calls and also record them, unlock a sim card and even steal call logs and messages. 

Experts believe that the vulnerable QMI software found during the investigation might be present in around 40% of smartphones, from brands Google, LG, Xiaomi, OnePlus, Samsung, etc. Basic info regarding the methods used in the attack was explained by the experts, but the technicalities of the attack weren't mentioned in the report to prevent any malicious actor from learning how to use the vulnerabilities. Currently, no evidence suggests that the attack is being used in the open. 

Check Point Research says "we discovered a vulnerability in a modem data service that can be used to control the modem and dynamically patch it from the application processor. An attacker can use such a vulnerability to inject malicious code into the modem from Android. It gives the attacker access to the user’s call history and SMS, as well as the ability to listen to the user’s conversations. A hacker can exploit the vulnerability to unlock the SIM, thereby overcoming the limitations of the service providers imposed on the mobile device."

App Census Study Reveals that Android Devices Leak User Data Stored in Contact Tracing Applications

 

According to security experts, hundreds of third-party applications on Android devices have access to confidential information collected by Google and Apple API contact-tracking devices. The Department of Homeland Security provided about $200,000 to App Census, a U.S. start-up that specializes in data protection practices in Android applications, earlier this year for testing and validating the reliability of contact tracking apps. 

The researchers of the business observed that the primary contact tracking information inside the device's system logs are recorded by Android Phones logging data from applications that use Google and Apple's Exposure Notifications System (ENS), that is used for collecting details, and usually where applications receive usage analytics and malfunction reports data. 

In an effort to assist medical authorities around the globe to develop contact tracing apps associated with the data protection requirement underlying the Android and iOS ecosystems, Google and Apple jointly launched ENS last year. API built by Apple and Google allows governments to build decentralized Bluetooth-based contact tracking software. 

The app-equipped devices send confidential, regularly changing IDs, known as RPIs, that are diffused via Bluetooth in such a way that nearby telephones that also use the application can be "heard". 

The observations of App Census reveal that the two Tech Giants' privacy pledge has certain deficiencies. Both transmitted and heard RPIs can indeed be identified in the machine logs of Android phones – as well as the device even records the existing Bluetooth MAC address of the destination server on RPIs that have been heard. Thus App Census found many ways of using and computing datasets to conduct data protection attacks since the RPI and the Bluetooth MAC addresses are unique and anonymized.

"Of course, the information has to be logged somewhere to do the contact-tracing, but that should be internally in the ENS," Gaetan Leurent, a researcher at the French National Institute for Research in Digital Science and Technology (INRIA), stated. "It is unsettling that this information was stored in the system log. There is no good reason to put it there." 

The RPIs could have been used along with different pieces of datasets to determine that whether users checked for COVID-19 positively, whether they had contacted an infectious individual or whether two persons met each other with access to device registers from multiple users. It is meant to preserve privacy in the contact tracing process, and precisely this type of data should be avoided. Therefore, the entire defense which should form the foundation of this protocol is defeated. 

A Google spokesperson told: "We were notified of an issue where the Bluetooth identifiers were temporarily accessible to some pre-installed applications for debugging purposes. Immediately upon being made aware of this research, we began the necessary process to review the issue, consider mitigations and ultimately update the code." 

The spokesman added that these Bluetooth identifications neither disclose the location of a customer nor provide any other identifying details, and also they are not aware that they were used in any manner. As per Google, roll started many weeks ago with the upgrade on Android devices and is due to be completed in the coming days. Previous publications of the researcher have shown that irrespective of implementation, the use of digital technology for contact tracking would necessarily present a risk to privacy.

BGP Leak Causes 13x Spike in Misdirected Traffic

 

An enormous BGP routing leak that occurred on 16th April 2021 disrupted the connectivity for a great many significant organizations and sites all across the planet. Albeit the BGP routing leak happened in Vodafone's independent network (AS55410) situated in India, it has affected U.S. organizations, including Google, as indicated by sources. 
 
BGP or Border Gateway Protocol is the thing that makes the modern-day internet work. It is akin to having a "postal system" for the web that works with the redirection of traffic from one (autonomous) system of networks to another. The web is a network of networks, and for instance, a client situated in one nation needed to get to a site situated in another, there must be a system set up that understands what ways to take while diverting the client across different networked systems. And, that is the reason for BGP: to coordinate web traffic effectively over different ways and systems between the source and destination to make the internet function.

On 16th April 2021, Cisco's BGPMon detected a disparity in an internet routing system, possibly demonstrating some BGP hijacking activity taking place: "Prefix 24.152.117.0/24, is normally announced by AS270497 RUTE MARIA DA CUNHA, BR." "But beginning at 2021-04-16 15:07:01, the same prefix (24.152.117.0/24) was also announced by ASN 55410," stated BGPMon's announcement. 

Doug Madory, director of Internet analysis at Kentik further affirmed these discoveries expressing that the autonomous system ASN 55410 was seeing a 13 times spike in inbound traffic directed to it. The said autonomous system (AS55410) belongs to Vodafone India Limited.

“We have done a complete analysis of the reported matter and have not observed any issue in routing security at our end. A wrong advertising of the routing table publishing made by one of our Enterprise customers had led to this incident. This was responded to immediately and rectified,” a Vodafone Idea Ltd spokesperson said.

"This incident only affected traffic for about 10 minutes, but during that time there were likely countless internet connection problems for users around the world." "Anyone trying to reach web resources configured with the IP addresses in the routes that were leaked would have had their traffic misdirected to AS55410 in India and then dropped," Doug Madory from Kentik told BleepingComputer in an email interview.

Customers Deceived by Google for Collection of User Location Data

 

The Federal Court of Australia observed that somewhere between January 2017 and December 2018, Google LLC and Google Australia Pty Ltd (together, Google) deceived customers in a world-first compliance action by ACCC on personal location information gathered from Android mobile devices. 

As a result of the 2019 legal proceedings against Google, the Australian Competition and Consumer Commission (ACCC) has stated that the rulings represent an "important victory for consumers" over protecting online privacy. Google deceived Android users to believe that the tech giant will only collect personal information, the ACCC said. 

“This is an important victory for consumers, especially anyone concerned about their privacy online, as the Court’s decision sends a strong message to Google and others that big businesses must not mislead their customers,” ACCC Chair Rod Sims said. “Today’s decision is an important step to make sure digital platforms are upfront with consumers about what is happening with their data and what they can do to protect it.” 

The Court ruled that in the initial installation Google misrepresented the setting of 'Location History' as the only Google Account setting which impacted whether Google obtained, maintained, or used personally identifiable information on the location of a device once consumers had created a new Google Account. In reality, Google was also able to capture, store and use personal location data during activation through a different Google Account setting entitled 'Web & App Activity.' Though this setting was set by default.

Also between 9 March 2017 and 29 November 2018, customers were deceived by the fact that Google didn't bother to tell them that perhaps the configuration was related to the collection of personal location data after they had accessed the 'Web & App Activity settings on their Android system. The Court held that the actions of Google could trick the audience. 

“We are extremely pleased with the outcome in this world-first case. Between January 2017 and December 2018, consumers were led to believe that ‘Location History’ was the only account setting that affected the collection of their location data, when that was simply not true,” Mr. Sims said. He also added, “Companies that collect information must explain their settings clearly and transparently, so consumers are not misled. Consumers should not be kept in the dark when it comes to the collection of their location data.” 

The Court rejected the claims of the ACCC concerning certain declarations by Google on how users could prevent Google from obtaining and then using the location information and the purposes for which Google uses its personal location information. Though the ACCC seeks declarations, fines, instructions for publishing, and conformity orders.

Google Tricked Millions of Chrome Users in the Name of 'Privacy'

 

Google revealed last month that it is rolling out the Federated Learning of Cohorts (FLoC) program, an important part of its ‘Privacy Sandbox Project’ for Chrome. The company advertised FLoC as the latest, privacy-preserving option in Google Chrome to the third-party cookie.

But the real question is can Google truly preserve the privacy of its users? Well, the results of the FLoC trial don’t indicate that. Millions of Chrome users had no control of their involvement in the FLoC trial, they received no personal text, and, currently, they have no option to opt out from the FLoC trial. The only option to leave the trial is by blocking all third-party cookies on their Google Chrome browsers.

What is the FLoC program? 

FLoC is based on machine learning technology designed by Google and is meant to be an alternative to the kind of cookies that advertising technology firms use today to track you across the web. Instead of a personally-identifiable cookie, FLoC runs locally and examines your browsing pattern to group you into a cohort of like-minded people with similar interests (and doesn’t share your browsing history with Google). That cohort is particular enough to permit advertisers to do their thing and show you relevant ads, but without being so specific as to allow marketers to spot you personally. 

This "interest-based trial,” as Google likes to call it, allows you to hide within the crowd of users with similar interests. All the browser displays are cohort ID and all your browsing history and other data stay locally. Google has also started testing the FLoC cookie for some Chrome users which allows them to analyze the new system in an origin trial. 

Last month, Google’s FLoC trial announcement, gave Chrome users no alternative to quitting before the trial started. Instead, Google quietly started to expand its FLoC technology to Chrome users in the US, Canada, Mexico, Australia, New Zealand, Brazil, India, Japan, Indonesia, and the Philippines.

"When other browsers started blocking third-party cookies by default, we were excited about the direction, but worried about the immediate impact. Excited because we need a more private web, and we know third-party cookies aren’t the long-term answer. Overall we felt that blocking third-party cookies outright without viable alternatives for the ecosystem was responsible and even harmful, to the open and free web we all enjoy,” Marshall Vale, Google’s product manager, stated.

Chrome Blocks Port 10080 to Prevent Slipstreaming Hacks

Google Chrome has blocked HTTPS, FTP, and HTTP access to TCP (transmission control protocol) port 10080 to protect ports getting exploited from NAT Slipstreaming 2.0 attacks. In 2020, cybersecurity expert Samy Kamkar revealed a new variant of the NAT Slipstreaming vulnerability that lets scripts on illicit websites avoid a user's NAT firewall and hack into any UDP/TCP port on the target's internal network. By exploiting these vulnerabilities, hackers can deploy a variety of attacks, these include modification of router configurations and hacking into private network services. 

"NAT Slipstreaming was discovered by security researcher Samy Kamkar and it requires the victims to visit the threat actor's malicious website (or a site with maliciously crafted ads). To expose hosted services, the attack abuses certain NAT devices scanning port 5060 to create port forwarding rules when detecting maliciously-crafted HTTP requests camouflaged as valid SIP requests," reported Bleeping Computers in 2019. The flaw only works on selected ports configured by a router's ALG (Application Level Gateway), ports that don't receive much traffic are being blocked by browser developers. 

As of now, Chrome has blocked HTTPS, HTTP, and FTP access on ports 1719, 1720, 1723, 5060, 5061, 69, 137, 161, and 554. Recently, Google said that it is considering blocking TCP port 10080 in Chrome. Firefox had blocked TCP port 10080 already in November last year. But the most worrisome aspect relating to 10080 is may developers may start using it as a replacement to port 80. They may find it useful as the port ends in '80' which makes it attractive. Besides this, the port doesn't require root privileges for binding into Unix systems, said Adam Rice, developer at Google Chrome. 

For developers that want to continue using this post, Mr. Rice will add an enterprise policy that will allow the developers to use the port by overriding the block. If a port is blocked, the user is displayed a "ERR_UNSAFE_PORT" error message while trying to gain access to the port. "If you are currently hosting a website on port 10080, you may want to consider using a different port to allow Google Chrome to continue accessing the site," said Bleeping computer.

Telemetry Data is Being Shared by Google and Apple Despite the user Explicitly Opting out

 

A new study revealing Apple and Google's monitoring of mobile devices is making headlines. It discusses how, despite the fact that both companies give consumers the possibility to opt-out of sharing telemetry data, the data is still shared. Both Google's Pixel and Apple's iPhone extract data from mobile devices without the users' permission. Both iOS and Android transfer telemetry, according to Trinity College researcher Douglas Leith, “despite the user explicitly opting out.” 

The analysis is a component of a complete study titled "Mobile Handset Privacy: Measuring the Data iOS and Android Send to Apple and Google." Perhaps it comes out that Google gathers much more data than Apple, almost 20 times more data from the Android Pixel users. 

“The phone IMEI, hardware serial number, SIM serial number and IMSI, handset phone number etc. are shared with Apple and Google,” as per the report. “When a SIM is inserted, both iOS and Google Android send details to Apple/Google. iOS sends the MAC addresses of nearby devices, e.g. other handsets, and the home gateway, to Apple, together with their GPS location. Currently there are few, if any, realistic options for preventing this data sharing.” 

According to the researcher’s observations, Google Pixel transfers approximately 1MB of data to Google servers during the first ten minutes of operation. For the same duration of time, the iPhone sends about 42KB of data to Apple servers. When the Pixel is turned off, it transfers approximately 1MB of data to Google every 12 hours, whereas the iPhone sends just 52KB. The report also indicated that, whether in use or not, both operating systems link to their back-end servers every 4.5 minutes on average. 

Nevertheless, third-party software and pre-installed apps that come with both the operating system were not included in the evaluations. The study focused solely on data collected by handset features and elements at the operating system level, such as Apple's Bluetooth UniqueChipID, Secure Element ID, and the transmission of Wi-Fi MAC address. Even after not being opened or used by the user, the highlight of the study is the ability of pre-installed applications and services, which are exclusive to handset manufacturers, to connect to the network. 

According to the study, telemetry data transmission poses major privacy issues. The study does highlight the importance of sending general user data to the software manufacturer, as this provides for the creation and release of critical device and security updates for specific models.

Fleeceware apps earned over $400 million on Android and iOS

 

Researchers at Avast have found an aggregate of 204 fleece ware applications with over a billion downloads and more than $400 million in revenue on the Apple App Store and Google Play Store. The purpose of these applications is to bring clients into a free trial to "test" the application, after which they overcharge them through subscriptions which sometimes run as high as $3,432 each year. These applications have no unique functionality and are only conduits for fleece ware scams. Avast has reported the fleece ware applications to both Apple and Google for audit.

Fleece ware is a recently coined term that alludes to a mobile application that accompanies extreme subscription fees. Most applications incorporate a short free trial to attract the client. The application exploits clients who are inexperienced with how subscriptions work on cell phones, implying that clients can be charged even after they've erased the offending application.

The fleece ware applications found comprise predominantly of musical instrument apps, palm readers, image editors, camera filters, fortune tellers, QR code and PDF readers, and ‘slime simulators’. While the applications for the most part satisfy their expected purpose, it is far-fetched that a client would purposely want to pay such a significant recurring fee for these applications, particularly when there are less expensive or even free options available. 

It creates the impression that part of the fleece ware strategy is to target more youthful crowds through playful themes and catchy ads on famous social networks with guarantees of ‘free installation’ or ‘free to download’. The information is alarming: with almost a billion downloads and hundreds of millions of dollars in revenue, this model is drawing in more developers and there is proof to recommend a few famous existing applications have updated to incorporate the free trial subscription with high recurring fees.

Regardless of whether a client erases the application after they notice outgoing payments, this doesn't mean their subscription stops - which permits the developer to cash in further. Google and Apple are not answerable for refunds after a specific time-frame, and keeping in mind that the organizations may decide to refund as a goodwill gesture in some cases however they are not obliged to do so. Along these lines, the lone choices might be to attempt to contact developers directly or to demand a bank chargeback.

Hackers used 11 Zero-Days to Attack Windows, iOS, Android Users

 

Malware trackers at Google keep on pointing out a complex APT group that burned through at least 11 zero-days exploits in less than a year to conduct mass spying across a range of platforms and gadgets. The group has effectively utilized "watering hole" assaults to divert explicit targets to a couple of exploit servers conveying malware on Windows, iOS, and Android gadgets. 

The cross-platform capacities and the readiness to utilize almost a dozen zero-days in under a year signals a well-resourced threat actor with the ability to access hacking tools and exploits from related groups. In another blog post, Google Project Zero researcher Maddie Stone released additional details on the exploit chains found in the wild last October and cautioned that the most recent disclosure is attached to a February 2020 campaign that incorporated the utilization of multiple zero-days. As per Stone, the threat actor from the February 2020 campaign went dark for a couple of months but returned in October with dozens of websites redirecting to an exploit server. 

“Once our analysis began, we discovered links to a second exploit server on the same website. After initial fingerprinting (appearing to be based on the origin of the IP address and the user-agent), an iframe was injected into the website pointing to one of the two exploit servers. In our testing, both of the exploit servers existed on all of the discovered domains,” Stone explained. 

The first exploit server at first reacted distinctly to Apple iOS and Microsoft Windows user-agents and was active for at least a week after Google's researchers began recovering the hacking devices. This server included exploits for a distant code execution bug in the Google Chrome rendering engine and a v8 zero-day after the underlying bug was fixed. Stone said the first server momentarily reacted to Android user-agents, proposing exploits existed for every one of the significant platforms.

Stone noticed that the assailants utilized a special obfuscation and anti-analysis check on iOS gadgets where those exploits were encrypted with ephemeral keys, “meaning that the exploits couldn't be recovered from the packet dump alone, instead of requiring an active MITM on our side to rewrite the exploit on-the-fly.”

Malware Campaign Targets Telegram Desktop Application

 

An independent security researcher based in Basel, Switzerland, Jannis Kirschner, began to look for the widely known Telegram desktop version on the internet on Sunday. The second Google result was an advertisement, which led him directly to malware cloaked as a Telegram for Windows desktop version. At first sight, it was sufficiently convincing for Kirschner to say that "almost fell for it myself." 

Malware vendors are habituated to use the same publicity tools that online businesses use to attract people. To stop such abuse, Google patrols its advertising ecosystem, but malware advertising is still an ongoing problem. Although a visit by telegramdesktop[dot]com to one of those sites now triggered an alert from the Google Safe Browsing service, that the two sites were unsafe and potentially still active and duplicated others. These include the telegraph[dot]net and the telegram[dot]org. The websites were reported to Google by Kirschner. 

Each of these three spoofed websites is Telegram's clones. All links on cloned sites are redirected to the legitimate Telegram domain, design.telegram.com. But one link is exchanged which is supposed to be the execution for the Telegram Desktop version of Windows. 

"A repo probably was a bad choice for delivering malware since it's very verbose (download numbers, time, and other documents)," Kirschner says. "The biggest opsec mistake was that they didn't clean one of the repo's metadata, which led me to discover commit messages and their e-mail [address]."

He further adds that "I believe that it is the same threat actor or group since the TTPs [tactics, techniques, and procedures] are the same, and all sites have been established in a very close timeframe using the same hoster and certificate authority." 

At least a temporary benefit is offered to host malware on platforms such as Bitbucket: surface links are often deemed to be genuine, and attackers are subject to a malicious reservoir that needs to be removed until someone reports it. The techniques help cover a technological filtering and manual screening campaign, but don't always measure properly, says Kirschner. 

A February 2020 report by the security firm Cybereason reported over half a dozen newcomers, crypto miners, ransomware, and other malware put on Bitbucket by bad actors. 

The telegramdesktop[dot]com website seems to be shared with Moldova. Kirschner says this domain was registered on 29 December 2020. A search in the Wayback Machine of the Internet Archive, reveals that telegramdesktop[dot]com was redirected to the rightful domain telegram.org in April 2018. However, according to DomainTools records, the domain expired in October 2018. 

"I assume that domain once belonged to Telegram themselves, expired and was taken over by the criminals now," Kirschner further says.

Google Issues a Warning about Spectre Attacks using JavaScript

 

It's been over a long time since researchers uncovered a couple of security vulnerabilities, known as Spectre and Meltdown, that further revealed fundamental flaws in how most present-day PC processors handle the information to maximize efficiency. While they influence a cosmic number of computing devices, the so-called speculative execution bugs are generally hard to misuse in practice. However, presently researchers from Google have built up a proof-of-concept that shows the risk Spectre assaults pose to the browser—in hopes of motivating a new generation of defenses. 

Google in 2018 detailed two variations of Spectre, one of which – named variation 1 (CVE-2017-5753) – concerned JavaScript exploitation against browsers. Google released the PoC for engineers of web applications to comprehend why it's critical to send application-level mitigations. At a high level, as detailed in a Google document on W3C, a developer's "data must not unexpectedly enter an attacker's process". 

While the PoC shows the JavaScript Spectre assault against Chrome 88's V8 JavaScript engine on an Intel Core i7-6500U 'Skylake' CPU on Linux, Google notes it can without much of a stretch be changed for different CPUs, browser versions, and operating systems. It was even successful on Apple's M1 Arm CPU with minor alterations. The assault can leak information at a pace of 1kB each second. The chief components of the PoC are a Spectre version 1 "device" or code that triggers attacker-controlled transient execution, and a side-channel or "a way to observe side effects of the transient execution". 

"The web platform relies on the origin as a fundamental security boundary, and browsers do a pretty good job at preventing explicit leakage of data from one origin to another," explained Google's Mike West. "Attacks like Spectre, however, show that we still have work to do to mitigate implicit data leakage. The side-channels exploited through these attacks prove that attackers can read any data which enters a process hosting that attackers' code. These attacks are quite practical today, and pose a real risk to users."

Google has likewise released another prototype Chrome extension called Spectroscope that scans an application to discover assets that may require enabling additional defenses.

Google Voice Disruption Caused by Expired TLS Certificates

 

Google has affirmed that a Google Voice malfunction that had impacted the majority of telephone service users this month was triggered, in an incident report released on Friday, by expired TLS certificates. It stopped most of Google Voice users from signing into their accounts and allowing more than four hours of use of the app between 15 February and 16 February 2021. 

Google Voice is a Google voicemail service that allows users to send free texts, personalize the voicemail, read text transcripts for voicemail, and much more. The voicemail service of Google, which previously required a Google Voice invitation code for installation, is now free of charge available for all Gmail users. 

The incident report states that, "Google Voice users experienced an issue in which some new inbound or outbound Voice over Internet Protocol (VoIP) calls failed to connect, for a total duration of 4hours 22 minutes." 

In order to manage phone calls over the Internet protocol, Google Voice uses the Initiation Session Protocol (SIP). Google Voice consumer devices aim at ensuring a continuous SIP link with Google Voice services during routine operation. The customer tries to regain contact automatically after a link fails. Transport Layer Security (TLS) certificates are also rotated periodically to ensure that all Google Voice traffic is protected and linked. 

"Due to an issue with updating certificate configurations, the active certificate in Google Voice frontend systems inadvertently expired at 2021-02-15 23:51:00, triggering the issue," Google explained. "During the impact period, any clients attempting to establish or re-establish a SIP connection were unable to do so." 

Users could not access the Google Voice platform to make or accept VoIP calls following the breakdown of expired certificates. However, consumer systems with an active SIP connection were not impacted during the outage before this incident (as long as the connection was not interrupted). The technical team concluded after the analysis that the root cause was certificate configuration. The team has developed and initiated an emergency roll-out of modified credentials and configuration information to interfaces. After mitigation was enforced, the functionality of Google Voice SIP customers restored retrieval of their connections.

Publishing the incident report, the Google Workspace Team stated the steps taken by the engineers. They insisted on, setting additional constructive warnings for credential expiry incidents to come, and set up additional reactive warnings in Google Voice frontend applications for TLS errors. Alongside, enhance automatic credential rotation tooling and changes to set up and to allow the quick rollout of configuration improvements, utilizing more portable facilities. Developing emergency roll-out testing and practice examples with Google Voice interface applications and settings.

Google is committed to improving our technology and operations efficiently and consistently to avoid service disruptions. They said that “We thank your patience and excuse your company for any effects. For your company, we appreciate you.”

Google Reveals Details of a Recently Patched Windows Flaw

 

Google Project Zero team disclosed the details of a recently fixed Windows flaw, tracked as CVE-2021-24093, that can be compromised for remote code execution in the context of the DirectWrite user. Dominik Rottsches of Google and Mateusz Jurczyk of Google Project Zero discovered the flaws and reported the issue to Microsoft in November and the bug report was made public this week. 

The vulnerability was fixed with the release of February 2021 Patch Tuesday updates. Cybersecurity researchers Jurczyk and Rottsches explained CVE-2021-24093 as a DirectWrite heap-based buffer overflow linked to the processing of a specially designed TrueType font. They further explained that a hacker can trigger a memory corruption condition that can be exploited to execute arbitrary code in the context of the DirectWrite client. DirectWrite is a Windows API designed to provide supports measuring, drawing, and hit-testing of multi-format text.

This vulnerability in the Windows operating system affected the Windows graphics components and it can be compromised by luring the victim to a website containing a specially designed file set up to exploit the vulnerability. This flaw received the CVSS score of 8.8, but Microsoft has designated this flaw as ‘critical’ for all affected operating systems and the list includes Windows 10, Windows Server 2016 and 2019, and Windows Server.

Google published the report reading, “we have discovered a crash in the DWrite!fsg_ExecuteGlyph function when loading and rasterizing a malformed TrueType font with a corrupted “maxp” table. Specifically, it was triggered after changing the value of the maxPoints field from 168 to 0, and the maxCompositePoints value from 2352 to 3 in our test font. We believe that this causes an inadequately small buffer to be allocated from the heap.” 

Subsequently, cybersecurity researchers examined their exploit on a fully patched Windows 10 in all major browsers and released a proof-of-concept (POC) exploit.

Security Researchers Received More Than $6.7 MIllion by Google as Bug Bounty Rewards

 

Security experts from 62 nations were paid more than $6.7 million (nearly Rs. 49 crore) by Google for identifying susceptibilities in Google products last year. Google has successfully managed to run the Vulnerability Reward Programs (VRPs) for ten years and the company has paid nearly $28 million to the security experts for spotting the vulnerabilities in Google products.

Google stated this week that “the incredibly hard work, dedication, and expertise of our researchers in 2020 resulted in a record-breaking payout of over $6.7 million in rewards, with an additional $280,000 given to charity. Following our increase in exploit payouts in November 2019, we received a record 13 working exploit submissions in 2020, representing over $1 million in exploit reward payouts”.

According to the company, Guang Gong (@oldfresher) and the team of experts at the 360 Alpha Lab at Chinese cybersecurity firm Qihoo 360 discovered 30% of the total number of Android vulnerabilities as a part of the bug bounty program. The latest vulnerability spotted by this group is a 1-click remote root exploit in Android, Google said this team still hold the record for receiving the highest Android payout ($161,337) for spotting the vulnerability in 2019.

Last year, the tech giant paid $50,000 to the security experts for spotting the flaws in Android developer preview and introduced bounty programs for Android Auto OS, Android chipsets, and for writing fuzzers for Android code. In Google Play, Google expanded the standard for certified Android apps to incorporate apps utilizing the Exposure Notification API and executing contact tracing to fight Covid-19. 

Apart from bounty rewards, over 180 security researchers have received more than $400,000 from Google in the form of grants for submitting 200 bug reports that resulted in 100 confirmed susceptibilities in Google products and the open-source ecosystem. The other notable tech firms that have a similar bug bounty reward program are Facebook, OnePlus, Qualcomm, Mozilla, Microsoft, and Reddit.