Kategorie

New research disclosed a string of severe security vulnerabilities in the 'Find My Mobile'—an Android app that comes pre-installed on most Samsung smartphones—that could have allowed remote attackers to track victims' real-time location, monitor phone calls, and messages, and even delete data stored on the phone. Portugal-based cybersecurity services provider Char49 revealed its findings on

As software eats the world, the world faces a software security crisis. The movement to modern software such as cloud technologies and microservice architectures is essential to innovate quickly. Yet, nearly three in four developers say that security slows down Agile and DevOps. Neither developers nor security teams are to blame. DevOps speed is held back by a 15-year-old, scan-based

Executive summary

In May 2020, Kaspersky technologies prevented an attack on a South Korean company by a malicious script for Internet Explorer. Closer analysis revealed that the attack used a previously unknown full chain that consisted of two zero-day exploits: a remote code execution exploit for Internet Explorer and an elevation of privilege exploit for Windows. Unlike a previous full chain that we discovered, used in Operation WizardOpium, the new full chain targeted the latest builds of Windows 10, and our tests demonstrated reliable exploitation of Internet Explorer 11 and Windows 10 build 18363 x64.

On June 8, 2020, we reported our discoveries to Microsoft, and the company confirmed the vulnerabilities. At the time of our report, the security team at Microsoft had already prepared a patch for vulnerability CVE-2020-0986 that was used in the zero-day elevation of privilege exploit, but before our discovery, the exploitability of this vulnerability was considered less likely. The patch for CVE-2020-0986 was released on June 9, 2020.

Microsoft assigned CVE-2020-1380 to a use-after-free vulnerability in JScript and the patch was released on August 11, 2020.

We are calling this and related attacks ‘Operation PowerFall’. Currently, we are unable to establish a definitive link with any known threat actors, but due to similarities with previously discovered exploits, we believe that DarkHotel may be behind this attack. Kaspersky products detect Operation PowerFall attacks with verdict PDM:Exploit.Win32.Generic.

Internet Explorer 11 remote code execution exploit

The most recent zero-day exploits for Internet Explorer discovered in the wild relied on the vulnerabilities CVE-2020-0674, CVE-2019-1429, CVE-2019-0676 and CVE-2018-8653 in the legacy JavaScript engine jscript.dll. In contrast, CVE-2020-1380 is a vulnerability in jscript9.dll, which has been used by default starting with Internet Explorer 9, and because of this, the mitigation steps recommended by Microsoft (restricting the usage of jscript.dll) cannot protect against this particular vulnerability.

CVE-2020-1380 is a Use-After-Free vulnerability that is caused by JIT optimization and the lack of necessary checks in just-in-time compiled code. A proof-of-concept (PoC) that triggers vulnerability is demonstrated below:

function func(O, A, F, O2) { arguments.push = Array.prototype.push; O = 1; arguments.length = 0; arguments.push(O2); if (F == 1) { O = 2; } // execute abp.valueOf() and write by dangling pointer A[5] = O; }; // prepare objects var an = new ArrayBuffer(0x8c); var fa = new Float32Array(an); // compile func func(1, fa, 1, {}); for (var i = 0; i < 0x10000; i++) { func(1, fa, 1, 1); } var abp = {}; abp.valueOf = function() { // free worker = new Worker('worker.js'); worker.postMessage(an, [an]); worker.terminate(); worker = null; // sleep var start = Date.now(); while (Date.now() - start < 200) {} // TODO: reclaim freed memory return 0 }; try { func(1, fa, 0, abp); } catch (e) { reload() }

To understand this vulnerability, let us take a look at how func() is executed. It is important to understand what value is set to A[5]. According to the code, it should be an O argument. At function start, the O argument is re-assigned to 1, but then the function arguments length is set to 0. This operation does not clear function arguments (as it would normally do with regular array) but allows to put argument O2 into the arguments list at index zero using Array.prototype.push, meaning O = O2 now. Besides that, if the argument F is equal to 1, then O will be re-assigned once again, but to the integer number 2. It means that depending on the value of the F argument, the O argument is equal to either the value of the O2 argument or the integer number 2. The argument A is a typed array of 32-bit floating point numbers, and before assigning a value to index 5 of the array, this value should be converted to a float. Converting an integer to a float is a relatively simple task, but it become less straightforward when an object is converted to a float number. The exploit uses the object abp with an overridden valueOf() method. This method is executed when the object is converted to a float, but inside the method there is code that frees ArrayBuffer, which is viewed by Float32Array and where the returned value will be set. To prevent the value from being stored in the memory of the freed object, the JavaScript engine needs to check the status of the object before storing the value in it. To convert and store the float value safely, JScript9.dll uses the function Js::TypedArray<float,0>::BaseTypedDirectSetItem(). You can see decompiled code of this function below:

int Js::TypedArray<float,0>::BaseTypedDirectSetItem(Js::TypedArray<float,0> *this, unsigned int index, void *object, int reserved) { Js::JavascriptConversion::ToNumber(object, this->type->library->context); if ( LOBYTE(this->view[0]->unusable) ) Js::JavascriptError::ThrowTypeError(this->type->library->context, 0x800A15E4, 0); if ( index < this->count ) { *(float *)&this->buffer[4 * index] = Js::JavascriptConversion::ToNumber( object, this->type->library->context); } return 1; } double Js::JavascriptConversion::ToNumber(void *object, struct Js::ScriptContext *context) { if ( (unsigned char)object & 1 ) return (double)((int)object >> 1); if ( *(void **)object == VirtualTableInfo<Js::JavascriptNumber>::Address[0] ) return *((double *)object + 1); return Js::JavascriptConversion::ToNumber_Full(object, context); }

This function checks the view[0]->unusable and count fields of the typed float array and when ArrayBuffer is freed during execution of the valueOf() method, both of these checks will fail because view[0]->unusable will be set to 1 and count will be set to 0 during the first call to Js::JavascriptConversion::ToNumber(). The problem lies in the fact that the function Js::TypedArray<float,0>::BaseTypedDirectSetItem() is used only in interpretation mode.

When the function func() is compiled just in time, the JavaScript engine will use the vulnerable code below.

if ( !((unsigned char)floatArray & 1) && *(void *)floatArray == &Js::TypedArray<float,0>::vftable ) { if ( floatArray->count > index ) { buffer = floatArray->buffer + 4*index; if ( object & 1 ) { *(float *)buffer = (double)(object >> 1); } else { if ( *(void *)object != &Js::JavascriptNumber::vftable ) { Js::JavascriptConversion::ToFloat_Helper(object, (float *)buffer, context); } else { *(float *)buffer = *(double *)(object->value); } } } }

And here is the code of the Js::JavascriptConversion::ToFloat_Helper() function.

void Js::JavascriptConversion::ToFloat_Helper(void *object, float *buffer, struct Js::ScriptContext *context) { *buffer = Js::JavascriptConversion::ToNumber_Full(object, context); }

As you can see, unlike in interpretation mode, in just-in-time compiled code, the life cycle of ArrayBuffer is not checked, and its memory can be freed and then reclaimed during a call to the valueOf() function. Additionally, the attacker can control at what index the returned value is written. However, in the case when “arguments.length = 0;”and “arguments.push(O2);” are replaced in PoC with “arguments[0] = O2;” then Js::JavascriptConversion::ToFloat_Helper() will not trigger the bug because implicit calls will be disabled and it will not perform a call to the valueOf() function.

To ensure that the function func() is compiled just in time, the exploit executes this function 0x10000 times, performing a harmless conversion of the integer, and only after that func() is executed once more, triggering the bug. To free ArrayBuffer, the exploit uses a common technique abusing the Web Workers API. The function postMessage() can be used to serialize objects to messages and send them to the worker. As a side effect, transferred objects are freed and become unusable in the current script context. When ArrayBuffer is freed, the exploit triggers garbage collection via code that simulates the use of the Sleep() function: it is a while loop that checks for the time lapse between Date.now() and the previously stored value. After that, the exploit reclaims the memory with integer arrays.

for (var i = 0; i < T.length; i += 1) { T[i] = new Array((0x1000 - 0x20) / 4); T[i][0] = 0x666; // item needs to be set to allocate LargeHeapBucket }

When a large number of arrays is created, Internet Explorer allocates new LargeHeapBlock objects, which are used by IE’s custom heap implementation. The LargeHeapBlock objects will store the addresses of buffers allocated for the arrays. If the expected memory layout is achieved successfully, the vulnerability will overwrite the value at the offset 0x14 of LargeHeapBlock with 0, which happens to be the allocated block count.

LargeHeapBlock structure for jscript9.dll x86

 After that, the exploit allocates a huge number of arrays and sets them to another array that was prepared at the initial stage of the exploitation. Then this array is set to null, and the exploit makes a call to the CollectGarbage() function. This results in defragmentation of the heap, and the modified LargeHeapBlock will be freed along with its associated array buffers. At this stage, the exploit creates a large amount of integer arrays in hopes of reclaiming the previously freed array buffers. The newly created arrays have a magic value set at index zero, and this value is checked through a dangling pointer to the previously freed array to detect if the exploitation was successful.

for (var i = 0; i < K.length; i += 1) { K[i] = new Array((0x1000 - 0x20) / 4); K[i][0] = 0x888; // store magic } for (var i = 0; i < T.length; i += 1) { if (T[i][0] == 0x888) { // find array accessible through dangling pointer R = T[i]; break; } }

As a result, the exploit creates two different JavascriptNativeIntArray objects with buffers pointing to the same location. This makes it possible to retrieve the addresses of the objects and even create new malformed objects. The exploit takes advantage of these primitives to create a malformed DataView object and get read/write access to the whole address space of the process.

After the building of the arbitrary read/write primitives, it is time to bypass Control Flow Guard (CFG) and get code execution. The exploit uses the Array’s vftable pointer to get the module base address of jscript9.dll. From there, it parses the PE header of jscript9.dll to get the address of the Import Directory Table and resolves the base addresses of the other modules. The goal here is to find the address of the function VirtualProtect(), which will be used to make the shellcode executable. After that, the exploit searches for two signatures in jscript9.dll. Those signatures correspond to the address of the Unicode string “split” and the address of the function: JsUtil::DoublyLinkedListElement<ThreadContext>::LinkToBeginning<ThreadContext>(). The address of the Unicode string “split” is used to get a code reference to the string and with its help, to resolve the address of the function Js::JavascriptString::EntrySplit(), which implements the string method split(). The address of the function LinkToBeginning<ThreadContext>() is used to obtain the address of the first ThreadContext object in the global linked list. The exploit locates the last entry in the linked list and uses it to get the location of the stack for the thread responsible for the execution of the script. After that comes the final stage. The exploit executes the split() method and an object with an overridden valueOf() method is provided as a limit argument. When the overridden valueOf() method is executed during the execution of the function Js::JavascriptString::EntrySplit(), the exploit will search the thread’s stack to find the return address, place the shellcode in a prepared buffer, obtain its address, and finally build a return-oriented programming (ROP) chain to execute the shellcode by overwriting the return address of the function.

Next stage

The shellcode is a reflective DLL loader for the portable executable (PE) module that is appended to the shellcode. The module is very small in size, and the whole functionality is located inside a single function. It creates a file within a temporary folder with the name ok.exe and writes to it the contents of another executable that is present in the remote code execution exploit. After that, ok.exe is executed.

The ok.exe executable contains is an elevation of privilege exploit for the arbitrary pointer dereference vulnerability CVE-2020-0986 in the GDI Print / Print Spooler API. Initially, this vulnerability was reported to Microsoft by an anonymous user working with Trend Micro’s Zero Day Initiative back in December 2019. Due to the patch not being released for six months since the original report, ZDI posted a public advisory for this vulnerability as a zero-day on May 19, 2020. The next day, the vulnerability was exploited in the previously mentioned attack.

The vulnerability makes it possible to read and write the arbitrary memory of the splwow64.exe process using interprocess communication, and use it to achieve code execution in the splwow64.exe process, bypassing the CFG and EncodePointer protection. The exploit comes with two executables embedded in its resources. The first executable is written to disk as CreateDC.exe and is used to create a device context (DC), which is required for exploitation. The second executable has the name PoPc.dll and if the exploitation is successful, it is executed by splwow64.exe with a medium integrity level. We will provide further details on CVE-2020-0986 and its exploitation in a follow-up post.

Execution of a malicious PowerShell command from splwow64.exe

The main functionality of PoPc.dll is also located inside a single function. It executes an encoded PowerShell command that proceeds to download a file from www[.]static-cdn1[.]com/update.zip, saves it to the temporary folder as upgrader.exe and executes it. We were unable to analyze upgrader.exe because Kaspersky technologies prevented the attack before the executable was downloaded.

IoCs

www[.]static-cdn1[.]com/update.zip
B06F1F2D3C016D13307BC7CE47C90594
D02632CFFC18194107CC5BF76AECA7E87E9082FED64A535722AD4502A4D51199
5877EAECA1FE8A3A15D6C8C5D7FA240B
7577E42177ED7FC811DE4BC854EC226EB037F797C3B114E163940A86FD8B078B
B72731B699922608FF3844CCC8FC36B4
7765F836D2D049127A25376165B1AC43CD109D8B9D8C5396B8DA91ADC61ECCB1
E01254D7AF1D044E555032E1F78FF38F
81D07CAE45CAF27CBB9A1717B08B3AB358B647397F08A6F9C7652D00DBF2AE24

The RAT is surging in 2020, becoming more prevalent than even the infamous TrickBot or Emotet malware.

One of the two zero-day bugs is rated ‘critical’ and is classified as a remote code-execution bug impacting Microsoft’s Internet Explorer.

Citrix today released patches for multiple new security vulnerabilities affecting its Citrix Endpoint Management (CEM), also known as XenMobile, a product made for enterprises to help companies manage and secure their employees' mobile devices remotely. Citrix Endpoint Management offers businesses mobile device management (MDM) and mobile application management (MAM) capabilities. It allows

A critical privilege-escalation flaw affects several popular Intel motherboards, server systems and compute modules.

Adobe patched critical and important-severity flaws tied to 26 CVEs in Acrobat and Reader.

"Something needs to be done," said the court. Where do you stand? For or against, have your say in our comments.

The fundamental causes for the skill gap are myriad, starting with a lack of training and career-development opportunities.

If you haven't recently updated your Chrome, Opera, or Edge web browser to the latest available version, it would be an excellent idea to do so as quickly as possible. Cybersecurity researchers on Monday disclosed details about a zero-day flaw in Chromium-based web browsers for Windows, Mac and Android that could have allowed attackers to entirely bypass Content Security Policy (CSP) rules

Posted by Platform Hardening Team

In Android 11 we continue to increase the security of the Android platform. We have moved to safer default settings, migrated to a hardened memory allocator, and expanded the use of compiler mitigations that defend against classes of vulnerabilities and frustrate exploitation techniques.

Initializing memory

We’ve enabled forms of automatic memory initialization in both Android 11’s userspace and the Linux kernel. Uninitialized memory bugs occur in C/C++ when memory is used without having first been initialized to a known safe value. These types of bugs can be confusing, and even the term “uninitialized” is misleading. Uninitialized may seem to imply that a variable has a random value. In reality it isn’t random. It has whatever value was previously placed there. This value may be predictable or even attacker controlled. Unfortunately this behavior can result in a serious vulnerability such as information disclosure bugs like ASLR bypasses, or control flow hijacking via a stack or heap spray. Another possible side effect of using uninitialized values is advanced compiler optimizations may transform the code unpredictably, as this is considered undefined behavior by the relevant C standards.

In practice, uses of uninitialized memory are difficult to detect. Such errors may sit in the codebase unnoticed for years if the memory happens to be initialized with some "safe" value most of the time. When uninitialized memory results in a bug, it is often challenging to identify the source of the error, particularly if it is rarely triggered.

Eliminating an entire class of such bugs is a lot more effective than hunting them down individually. Automatic stack variable initialization relies on a feature in the Clang compiler which allows choosing initializing local variables with either zeros or a pattern.

Initializing to zero provides safer defaults for strings, pointers, indexes, and sizes. The downsides of zero init are less-safe defaults for return values, and exposing fewer bugs where the underlying code relies on zero initialization. Pattern initialization tends to expose more bugs and is generally safer for return values and less safe for strings, pointers, indexes, and sizes.

Initializing Userspace:

Automatic stack variable initialization is enabled throughout the entire Android userspace. During the development of Android 11, we initially selected pattern in order to uncover bugs relying on zero init and then moved to zero-init after a few months for increased safety. Platform OS developers can build with `AUTO_PATTERN_INITIALIZE=true m` if they want help uncovering bugs relying on zero init.

Initializing the Kernel:

Automatic stack and heap initialization were recently merged in the upstream Linux kernel. We have made these features available on earlier versions of Android’s kernel including 4.14, 4.19, and 5.4. These features enforce initialization of local variables and heap allocations with known values that cannot be controlled by attackers and are useless when leaked. Both features result in a performance overhead, but also prevent undefined behavior improving both stability and security.

For kernel stack initialization we adopted the CONFIG_INIT_STACK_ALL from upstream Linux. It currently relies on Clang pattern initialization for stack variables, although this is subject to change in the future.

Heap initialization is controlled by two boot-time flags, init_on_alloc and init_on_free, with the former wiping freshly allocated heap objects with zeroes (think s/kmalloc/kzalloc in the whole kernel) and the latter doing the same before the objects are freed (this helps to reduce the lifetime of security-sensitive data). init_on_alloc is a lot more cache-friendly and has smaller performance impact (within 2%), therefore it has been chosen to protect Android kernels.

Scudo is now Android's default native allocator

In Android 11, Scudo replaces jemalloc as the default native allocator for Android. Scudo is a hardened memory allocator designed to help detect and mitigate memory corruption bugs in the heap, such as:

• Double free,
• Arbitrary free,
• Heap-based buffer overflow,
• Use-after-free

Scudo does not fully prevent exploitation but it does add a number of sanity checks which are effective at strengthening the heap against some memory corruption bugs.

It also proactively organizes the heap in a way that makes exploitation of memory corruption more difficult, by reducing the predictability of the allocation patterns, and separating allocations by sizes.

In our internal testing, Scudo has already proven its worth by surfacing security and stability bugs that were previously undetected.

Finding Heap Memory Safety Bugs in the Wild (GWP-ASan)

Android 11 introduces GWP-ASan, an in-production heap memory safety bug detection tool that's integrated directly into the native allocator Scudo. GWP-ASan probabilistically detects and provides actionable reports for heap memory safety bugs when they occur, works on 32-bit and 64-bit processes, and is enabled by default for system processes and system apps.

GWP-ASan is also available for developer applications via a one line opt-in in an app's AndroidManifest.xml, with no complicated build support or recompilation of prebuilt libraries necessary.

Software Tag-Based KASAN

Continuing work on adopting the Arm Memory Tagging Extension (MTE) in Android, Android 11 includes support for kernel HWASAN, also known as Software Tag-Based KASAN. Userspace HWASAN is supported since Android 10.

KernelAddressSANitizer (KASAN) is a dynamic memory error detector designed to find out-of-bound and use-after-free bugs in the Linux kernel. Its Software Tag-Based mode is a software implementation of the memory tagging concept for the kernel. Software Tag-Based KASAN is available in 4.14, 4.19 and 5.4 Android kernels, and can be enabled with the CONFIG_KASAN_SW_TAGS kernel configuration option. Currently Tag-Based KASAN only supports tagging of slab memory; support for other types of memory (such as stack and globals) will be added in the future.

Compared to Generic KASAN, Tag-Based KASAN has significantly lower memory requirements (see this kernel commit for details), which makes it usable on dog food testing devices. Another use case for Software Tag-Based KASAN is checking the existing kernel code for compatibility with memory tagging. As Tag-Based KASAN is based on similar concepts as the future in-kernel MTE support, making sure that kernel code works with Tag-Based KASAN will ease in-kernel MTE integration in the future.

Expanding existing compiler mitigations

We’ve continued to expand the compiler mitigations that have been rolled out in prior releases as well. This includes adding both integer and bounds sanitizers to some core libraries that were lacking them. For example, the libminikin fonts library and the libui rendering library are now bounds sanitized. We’ve hardened the NFC stack by implementing both integer overflow sanitizer and bounds sanitizer in those components.

In addition to the hard mitigations like sanitizers, we also continue to expand our use of CFI as an exploit mitigation. CFI has been enabled in Android’s networking daemon, DNS resolver, and more of our core javascript libraries like libv8 and the PacProcessor.

The effectiveness of our software codec sandboxPrior to the Release of Android 10 we announced a new constrained sandbox for software codecs. We’re really pleased with the results. Thus far, Android 10 is the first Android release since the infamous stagefright vulnerabilities in Android 5.0 with zero critical-severity vulnerabilities in the media frameworks.

Thank you to Jeff Vander Stoep, Alexander Potapenko, Stephen Hines, Andrey Konovalov, Mitch Phillips, Ivan Lozano, Kostya Kortchinsky, Christopher Ferris, Cindy Zhou, Evgenii Stepanov, Kevin Deus, Peter Collingbourne, Elliott Hughes, Kees Cook and Ken Chen for their contributions to this post.

Posted by Charmaine D'Silva, Product Lead, Android Privacy and Framework, Narayan Kamath, Engineering Lead, Android Privacy and Framework, Stephan Somogyi, Product Lead, Android Security and Sudhi Herle, Engineering Lead, Android Security

This blog post is part of a weekly series for #11WeeksOfAndroid. For each #11WeeksOfAndroid, we’re diving into a key area so you don’t miss anything. This week, we spotlighted Privacy and Security; here’s a look at what you should know.

Privacy and security is core to how we design Android, and with every new release we increase our investment in this space. Android 11 continues to make important strides in these areas, and this week we’ll be sharing a series of updates and resources about Android privacy and security. But first, let’s take a quick look at some of the most important changes we’ve made in Android 11 to protect user privacy and make the platform more secure.

As shared in the “All things privacy in Android 11” video, we’re giving users even more control over sensitive permissions. Throughout the development of this release, we have engaged deeply and frequently with our developer community to design these features in a balanced way - amplifying user privacy while minimizing developer impact. Let’s go over some of these features:

One-time permission: In Android 10, we introduced a granular location permission that allows users to limit access to location only when an app is in use (aka foreground only). When presented with the new runtime permissions options, users choose foreground only location more than 50% of the time. This demonstrated to us that users really wanted finer controls for permissions. So in Android 11, we’ve introduced one time permissions that let users give an app access to the device microphone, camera, or location, just that one time. As an app developer, there are no changes that you need to make to your app for it to work with one time permissions, and the app can request permissions again the next time the app is used. Learn more about building privacy-friendly apps with these new changes in this video.

Background location: In Android 10 we added a background location usage reminder so users can see how apps are using this sensitive data on a regular basis. Users who interacted with the reminder either downgraded or denied the location permission over 75% of the time. In addition, we have done extensive research and believe that there are very few legitimate use cases for apps to require access to location in the background.

In Android 11, background location will no longer be a permission that a user can grant via a run time prompt and it will require a more deliberate action. If your app needs background location, the system will ensure that the app first asks for foreground location. The app can then broaden its access to background location through a separate permission request, which will cause the system to take the user to Settings in order to complete the permission grant.

In February, we announced that Google Play developers will need to get approval to access background location in their app to prevent misuse. We're giving developers more time to make changes and won't be enforcing the policy for existing apps until 2021. Check out this helpful video to find possible background location usage in your code.

Permissions auto-reset: Most users tend to download and install over 60 apps on their device but interact with only a third of these apps on a regular basis. If users haven’t used an app that targets Android 11 for an extended period of time, the system will “auto-reset” all of the granted runtime permissions associated with the app and notify the user. The app can request the permissions again the next time the app is used. If you have an app that has a legitimate need to retain permissions, you can prompt users to turn this feature OFF for your app in Settings.

Data access auditing APIs: Android encourages developers to limit their access to sensitive data, even if they have been granted permission to do so. In Android 11, developers will have access to new APIs that will give them more transparency into their app’s usage of private and protected data. The APIs will enable apps to track when the system records the app’s access to private user data.

Scoped Storage: In Android 10, we introduced scoped storage which provides a filtered view into external storage, giving access to app-specific files and media collections. This change protects user privacy by limiting broad access to shared storage in many ways including changing the storage permission to only give read access to photos, videos and music and improving app storage attribution. Since Android 10, we’ve incorporated developer feedback and made many improvements to help developers adopt scoped storage, including: updated permission UI to enhance user experience, direct file path access to media to improve compatibility with existing libraries, updated APIs for modifying media, Manage External Storage permission to enable select use cases that need broad files access, and protected external app directories. In Android 11, scoped storage will be mandatory for all apps that target API level 30. Learn more in this video and check out the developer documentation for further details.

Google Play system updates: Google Play system updates were introduced with Android 10 as part of Project Mainline. Their main benefit is to increase the modularity and granularity of platform subsystems within Android so we can update core OS components without needing a full OTA update from your phone manufacturer. Earlier this year, thanks to Project Mainline, we were able to quickly fix a critical vulnerability in the media decoding subsystem. Android 11 adds new modules, and maintains the security properties of existing ones. For example, Conscrypt, which provides cryptographic primitives, maintained its FIPS validation in Android 11 as well.

BiometricPrompt API: Developers can now use the BiometricPrompt API to specify the biometric authenticator strength required by their app to unlock or access sensitive parts of the app. We are planning to add this to the Jetpack Biometric library to allow for backward compatibility and will share further updates on this work as it progresses.

Identity Credential API: This will unlock new use cases such as mobile drivers licences, National ID, and Digital ID. It’s being built by our security team to ensure this information is stored safely, using security hardware to secure and control access to the data, in a way that enhances user privacy as compared to traditional physical documents. We’re working with various government agencies and industry partners to make sure that Android 11 is ready for such digital-first identity experiences.

Thank you for your flexibility and feedback as we continue to build an increasingly more private and secure platform. You can learn about more features in the Android 11 Beta developer site. You can also learn about general best practices related to privacy and security.

Please follow Android Developers on Twitter and Youtube to catch helpful content and materials in this area all this week.

Resources

You can find the entire playlist of #11WeeksOfAndroid video content here, and learn more about each week here. We’ll continue to spotlight new areas each week, so keep an eye out and follow us on Twitter and YouTube. Thanks so much for letting us be a part of this experience with you!

Posted by Eugene Liderman and Xevi Miro Bruix, Android Security and Privacy Team

Trust is very important when it comes to the relationship between a user and their smartphone. While phone functionality and design can enhance the user experience, security is fundamental and foundational to our relationship with our phones.There are multiple ways to build trust around the security capabilities that a device provides and we continue to invest in verifiable ways to do just that.

Pixel 4a ioXt certification

Today we are happy to announce that the Pixel 4/4 XL and the newly launched Pixel 4a are the first Android smartphones to go through ioXt certification against the Android Profile.

The Internet of Secure Things Alliance (ioXt) manages a security compliance assessment program for connected devices. ioXt has over 200 members across various industries, including Google, Amazon, Facebook, T-Mobile, Comcast, Zigbee Alliance, Z-Wave Alliance, Legrand, Resideo, Schneider Electric, and many others. With so many companies involved, ioXt covers a wide range of device types, including smart lighting, smart speakers, webcams, and Android smartphones.

The core focus of ioXt is “to set security standards that bring security, upgradability and transparency to the market and directly into the hands of consumers.” This is accomplished by assessing devices against a baseline set of requirements and relying on publicly available evidence. The goal of ioXt’s approach is to enable users, enterprises, regulators, and other stakeholders to understand the security in connected products to drive better awareness towards how these products are protecting the security and privacy of users.

ioXt’s baseline security requirements are tailored for product classes, and the ioXt Android Profile enables smartphone manufacturers to differentiate security capabilities, including biometric authentication strength, security update frequency, length of security support lifetime commitment, vulnerability disclosure program quality, and preloaded app risk minimization.

We believe that using a widely known industry consortium standard for Pixel certification provides increased trust in the security claims we make to our users. NCC Group has published an audit report that can be downloaded here. The report documents the evaluation of Pixel 4/4 XL and Pixel 4a against the ioXt Android Profile.

Security by Default is one of the most important criteria used in the ioXt Android profile. Security by Default rates devices by cumulatively scoring the risk for all preloads on a particular device. For this particular measurement, we worked with a team of university experts from the University of Cambridge, University of Strathclyde, and Johannes Kepler University in Linz to create a formula that considers the risk of platform signed apps, pregranted permissions on preloaded apps, and apps communicating using cleartext traffic.

Screenshot of the presentation of the Android Device Security Database at the Android Security Symposium 2020

In partnership with those teams, Google created Uraniborg, an open source tool that collects necessary attributes from the device and runs it through this formula to come up with a raw score. NCC Group leveraged Uraniborg to conduct the assessment for the ioXt Security by Default category.

As part of our ongoing certification efforts, we look forward to submitting future Pixel smartphones through the ioXt standard, and we encourage the Android device ecosystem to participate in similar transparency efforts for their devices.

Acknowledgements: This post leveraged contributions from Sudhi Herle, Billy Lau and Sam Schumacher

Four critical-severity flaws were recently disclosed in the Find My Mobile feature of Samsung Galaxy smartphones, which if exploited could allow attackers to force a factory reset on the phones or spy on users.

A security researcher earlier today publicly revealed details and proof-of-concept exploit code for an unpatched, critical zero-day remote code execution vulnerability affecting the widely used internet forum software vBulletin that's already under active exploitation in the wild. vBulletin is a widely used proprietary Internet forum software package based on PHP and MySQL database server that

The growing interest in third-party collaboration apps The growing trend toward remote work is changing how people communicate in the workplace. Cloud-based collaboration apps and videoconferencing tools are making life easier for employees while helping businesses quickly adapt to this new digital world. But now that potentially sensitive conversations are happening via third-party services, what […]

The post How privacy agreements impact data privacy for business users: Slack, Zoom and Microsoft Teams appeared first on Infosec Resources.

How privacy agreements impact data privacy for business users: Slack, Zoom and Microsoft Teams was first posted on August 11, 2020 at 8:05 am.
©2017 "InfoSec Resources". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at darren.dalasta@infosecinstitute.com

Introduction It’s not every day that governments of different countries draft guidance rules about any subject together. It is even rarer that they create joint guidance for cybersecurity reasons. It may come as a surprise to many that the United States government (NSA) and the Australian government (Australian Signals Directorate or ASD) have issued joint […]

The post How to detect and prevent web shells: New guidance from the NSA and the Australian government appeared first on Infosec Resources.

How to detect and prevent web shells: New guidance from the NSA and the Australian government was first posted on August 11, 2020 at 8:03 am.
©2017 "InfoSec Resources". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at darren.dalasta@infosecinstitute.com

Introduction Pentesters are apparently huge fans of colors. Different roles within pentesting assignments are designated as Red Team, Blue Team, Purple Team and others. Given this, it’s not surprising that different types of pentests are designated by color as well. You may have heard of white-box, black-box, and even gray-box pentesting but may be wondering […]

The post What are Black Box, Grey Box, and White Box Penetration Testing? [Updated 2020] appeared first on Infosec Resources.

What are Black Box, Grey Box, and White Box Penetration Testing? [Updated 2020] was first posted on August 11, 2020 at 8:00 am.
©2017 "InfoSec Resources". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at darren.dalasta@infosecinstitute.com

Three separate proof-of-concepts on Bash, Python and Ruby posted to outsmart fix issued last year to remedy pre-auth RCE bug.