Kategorie

Posted by Brian Claire Young and Shawn Willden, Android Security; and Frank Salim, Google Pay

[Cross-posted from the Android Developers Blog]

New Android Pie Keystore FeaturesThe Android Keystore provides application developers with a set of cryptographic tools that are designed to secure their users' data. Keystore moves the cryptographic primitives available in software libraries out of the Android OS and into secure hardware. Keys are protected and used only within the secure hardware to protect application secrets from various forms of attacks. Keystore gives applications the ability to specify restrictions on how and when the keys can be used.
Android Pie introduces new capabilities to Keystore. We will be discussing two of these new capabilities in this post. The first enables restrictions on key use so as to protect sensitive information. The second facilitates secure key use while protecting key material from the application or operating system.
Keyguard-bound keysThere are times when a mobile application receives data but doesn't need to immediately access it if the user is not currently using the device. Sensitive information sent to an application while the device screen is locked must remain secure until the user wants access to it. Android Pie addresses this by introducing keyguard-bound cryptographic keys. When the screen is locked, these keys can be used in encryption or verification operations, but are unavailable for decryption or signing. If the device is currently locked with a PIN, pattern, or password, any attempt to use these keys will result in an invalid operation. Keyguard-bound keys protect the user's data while the device is locked, and only available when the user needs it.
Keyguard binding and authentication binding both function in similar ways, except with one important difference. Keyguard binding ties the availability of keys directly to the screen lock state while authentication binding uses a constant timeout. With keyguard binding, the keys become unavailable as soon as the device is locked and are only made available again when the user unlocks the device.
It is worth noting that keyguard binding is enforced by the operating system, not the secure hardware. This is because the secure hardware has no way to know when the screen is locked. Hardware-enforced Android Keystore protection features like authentication binding, can be combined with keyguard binding for a higher level of security. Furthermore, since keyguard binding is an operating system feature, it's available to any device running Android Pie.
Keys for any algorithm supported by the device can be keyguard-bound. To generate or import a key as keyguard-bound, call setUnlockedDeviceRequired(true) on the KeyGenParameterSpec or KeyProtection builder object at key generation or import.
Secure Key ImportSecure Key Import is a new feature in Android Pie that allows applications to provision existing keys into Keystore in a more secure manner. The origin of the key, a remote server that could be sitting in an on-premise data center or in the cloud, encrypts the secure key using a public wrapping key from the user's device. The encrypted key in the SecureKeyWrapper format, which also contains a description of the ways the imported key is allowed to be used, can only be decrypted in the Keystore hardware belonging to the specific device that generated the wrapping key. Keys are encrypted in transit and remain opaque to the application and operating system, meaning they're only available inside the secure hardware into which they are imported.

Secure Key Import is useful in scenarios where an application intends to share a secret key with an Android device, but wants to prevent the key from being intercepted or from leaving the device. Google Pay uses Secure Key Import to provision some keys on Pixel 3 phones, to prevent the keys from being intercepted or extracted from memory. There are also a variety of enterprise use cases such as S/MIME encryption keys being recovered from a Certificate Authorities escrow so that the same key can be used to decrypt emails on multiple devices.
To take advantage of this feature, please review this training article. Please note that Secure Key Import is a secure hardware feature, and is therefore only available on select Android Pie devices. To find out if the device supports it, applications can generate a KeyPair with PURPOSE_WRAP_KEY.

The trojan purports to be a battery optimization app - and then steals up to 1,000 euro from victims' PayPal accounts.

Posted by Natalie Silvanovich, Project Zero
Not every attempt to find bugs is successful. When looking at WhatsApp, we spent a lot of time reviewing call signalling hoping to find a remote, interaction-less vulnerability. No such bugs were found. We are sharing our work with the hopes of saving other researchers the time it took to go down this very long road. Or maybe it will give others ideas for vulnerabilities we didn’t find.
As discussed in Part 1, signalling is the process through which video conferencing peers initiate a call. Usually, at least part of signalling occurs before the receiving peer answers the call. This means that if there is a vulnerability in the code that processes incoming signals before the call is answered, it does not require any user interaction.
WhatsApp implements signalling using a series of WhatsApp messages. Opening libwhatsapp.so in IDA, there are several native calls that handle incoming signalling messages.
Java_com_whatsapp_voipcalling_Voip_nativeHandleCallOfferJava_com_whatsapp_voipcalling_Voip_nativeHandleCallOfferAckJava_com_whatsapp_voipcalling_Voip_nativeHandleCallGroupInfoJava_com_whatsapp_voipcalling_Voip_nativeHandleCallRekeyRequestJava_com_whatsapp_voipcalling_Voip_nativeHandleCallFlowControlJava_com_whatsapp_voipcalling_Voip_nativeHandleCallOfferReceiptJava_com_whatsapp_voipcalling_Voip_nativeHandleCallAcceptReceiptJava_com_whatsapp_voipcalling_Voip_nativeHandleCallOfferAcceptJava_com_whatsapp_voipcalling_Voip_nativeHandleCallOfferPreAcceptJava_com_whatsapp_voipcalling_Voip_nativeHandleCallVideoChangedJava_com_whatsapp_voipcalling_Voip_nativeHandleCallVideoChangedAckJava_com_whatsapp_voipcalling_Voip_nativeHandleCallOfferRejectJava_com_whatsapp_voipcalling_Voip_nativeHandleCallTerminateJava_com_whatsapp_voipcalling_Voip_nativeHandleCallTransportJava_com_whatsapp_voipcalling_Voip_nativeHandleCallRelayLatencyJava_com_whatsapp_voipcalling_Voip_nativeHandleCallRelayElectionJava_com_whatsapp_voipcalling_Voip_nativeHandleCallInterruptedJava_com_whatsapp_voipcalling_Voip_nativeHandleCallMutedJava_com_whatsapp_voipcalling_Voip_nativeHandleWebClientMessage
Using apktool to extract the WhatsApp APK, it appears these natives are called from a loop in the com.whatsapp.voipcalling.Voip class. Looking at the smali, it looks like signalling messages are sent as WhatsApp messages via the WhatsApp server, and this loop handles the incoming messages.
Immediately, I noticed that there was a peer-to-peer encrypted portion of the message (the rest of the message is only encrypted peer-to-server). I thought this had the highest potential of reaching bugs, as the server would not be able to sanitize the data. In order to be able to read and alter encrypted packets, I set up a remote server with a python script that opens a socket. Whenever this socket receives data, the data is displayed on the screen, and I have the option of either sending the unaltered packet or altering the packet before it is sent. I then looked for the point in the WhatsApp smali where messages are peer-to-peer encrypted.
Since WhatsApp uses libsignal for peer-to-peer encryption, I was able to find where messages are encrypted by matching log entries. I then added smali code that sends a packet with the bytes of the message to the server I set up, and then replaces it with the bytes the server returns (changing the size of the byte array if necessary). This allowed me to view and alter the peer-to-peer encrypted message. Making a call using this modified APK, I discovered that the peer-to-peer message was always exactly 24 bytes long, and appeared to be random. I suspected that this was the encryption key used by the call, and confirmed this by looking at the smali.
A single encryption key doesn’t have a lot of potential for malformed data to lead to bugs (I tried lengthening and shortening it to be safe, but got nothing but unexploitable null pointer issues), so I moved on to looking at the peer-to-server encrypted messages. Looking at the Voip loop in smali, it looked like the general flow is that the device receives an incoming message, it is deserialized and if it is of the right type, it is forwarded to the messaging loop. Then certain properties are read from the message, and it is forwarded to a processing function based on its type. Then the processing function reads even more properties, and calls one of the above native methods with the properties as its parameters. Most of these functions have more than 20 parameters.
Many of these functions perform logging when they are called, so by making a test call, I could figure out which functions get called before a call is picked up. It turns out that during a normal incoming call, the device only receives an offer and calls Java_com_whatsapp_voipcalling_Voip_nativeHandleCallOffer, and then spawns the incoming call screen in WhatsApp. All the other signal types are not used until the call is picked up.
An immediate question I had was whether other signal types are processed if they are received before a call is picked up. Just because the initiating device never sends these signal types before the call is picked up doesn’t mean the receiving device wouldn’t process them if it received them.
Looking through the APK smali, I found the class com.whatsapp.voipcalling.VoiceService$DefaultSignalingCallback that has several methods like sendOffer and sendAccept that appeared to send the messages that are processed by these native calls. I changed sendOffer to call other send methods, like sendAccept instead of its normal messaging functionality. Trying this, I discovered that the Voip loop will process any signal type regardless of whether the call has been answered. The native methods will then parse the parameters, process them and put the results in a buffer, and then call a single method to process the buffer. It is only at that point processing will stop if the message is of the wrong type.I then reviewed all of the above methods in IDA. The code was very conservatively written, and most needed checks were performed. However, there were a few areas that potentially had bugs that I wanted to investigate more. I decided that changing the parameters to calls in the com.whatsapp.voipcalling.VoiceService$DefaultSignalingCallback was too slow to test the number of cases I wanted to test, and went looking for another way to alter the messages.
Ideally, I wanted a way to pass peer-to-server encrypted messages to my server before they were sent, so I could view and alter them. I went through the WhatsApp APK smali looking for a point after serialization but before encryption where I could add my smali function that sends and alters the packets. This was fairly difficult and time consuming, and I eventually put my smali in every method that wrote to a non-file ByteArrayOutputStream in the com.whatsapp.protocol and com.whatsapp.messaging packages (about 10 total) and looked for where it got called. I figured out where it got called, and fixed the class so that anywhere a byte array was written out from a stream, it got sent to my server, and removed the other calls. (If you’re following along at home, the smali file I changed included the string “Double byte dictionary token out of range”, and the two methods I changed contained calls to toByteArray, and ended with invoking a protocol interface.) Looking at what got sent to my server, it seemed like a reasonably comprehensive collection of WhatsApp messages, and the signalling messages contained what I thought they would.
WhatsApp messages are in a compressed XMPP format. A lot of parsers have been written for reverse engineering this protocol, but I found the whatsapp-reveng parser worked the best. I did have to replace the tokens in whatsapp_defines.py with a list extracted from the APK for it to work correctly though. This made it easier to figure out what was in each packet sent to the server.
Playing with this a bit, I discovered that there are three types of checks in WhatsApp signalling messages. First, the server validates and modifies incoming signalling messages. Secondly, the messages are deserialized, and this can cause errors if the format is incorrect, and generally limits the contents of the Java message object that is passed on. Finally, the native methods perform checks on their parameters.
These additional checks prevented several of the areas I thought were problems from actually being problems. For example, there is a function called by Java_com_whatsapp_voipcalling_Voip_nativeHandleCallOffer that takes in an array of byte arrays, an array of integers and an array of booleans. It uses these values to construct candidates for the call. It checks that the array of byte arrays and the array of integers are of the same length before it loops through them, using values from each, but it does not perform the same check on the boolean array. I thought that this could go out of bounds, but it turns out that the integer and booleans are serialized as a vector of <int,bool> pairs, and the arrays are then copied from the vector, so it is not actually possible to send arrays with different lengths.
One area of the signalling messages that looked especially concerning was the voip_options field of the message. This field is never sent from the sending device, but is added to the message by the server before it is forwarded to the receiving device. It is a buffer in JSON format that is processed by the receiving device and contains dozens of configuration parameters.
{"aec":{"offset":"0","mode":"2","echo_detector_mode":"4","echo_detector_impl":"2","ec_threshold":"50","ec_off_threshold":"40","disable_agc":"1","algorithm":{"use_audio_packet_rate":"1","delay_based_bwe_trendline_filter_enabled":"1","delay_based_bwe_bitrate_estimator_enabled":"1","bwe_impl":"5"},"aecm_adapt_step_size":"2"},"agc":{"mode":"0","limiterenable":"1","compressiongain":"9","targetlevel":"1"},"bwe":{"use_audio_packet_rate":"1","delay_based_bwe_trendline_filter_enabled":"1","delay_based_bwe_bitrate_estimator_enabled":"1","bwe_impl":"5"},"encode":{"complexity":"5","cbr":"0"},"init_bwe":{"use_local_probing_rx_bitrate":"1","test_flags":"982188032","max_tx_rott_based_bitrate":"128000","max_bytes":"8000","max_bitrate":"350000"},"ns":{"mode":"1"},"options":{"connecting_tone_desc": "test","video_codec_priority":"2","transport_stats_p2p_threshold":"0.5","spam_call_threshold_seconds":"55","mtu_size":"1200","media_pipeline_setup_wait_threshold_in_msec":"1500","low_battery_notify_threshold":"5","ip_config":"1","enc_fps_over_capture_fps_threshold":"1","enable_ssrc_demux":"1","enable_preaccept_received_update":"1","enable_periodical_aud_rr_processing":"1","enable_new_transport_stats":"1","enable_group_call":"1","enable_camera_abtest_texture_preview":"1","enable_audio_video_switch":"1","caller_end_call_threshold":"1500","call_start_delay":"1200","audio_encode_offload":"1","android_call_connected_toast":"1"}Sample voip_options (truncated)
If a peer could send a voip_options parameter to another peer, it would open up a lot of attack surface, including a JSON parser and the processing of these parameters. Since this parameter almost always appears in an offer, I tried modifying an offer to contain one, but the offer was rejected by the WhatsApp server with error 403. Looking at the binary, there were three other signal types in the incoming call flow that could accept a voip_options parameter. Java_com_whatsapp_voipcalling_Voip_nativeHandleCallOfferAccept and Java_com_whatsapp_voipcalling_Voip_nativeHandleCallVideoChanged were accepted by the server if a voip_options parameter was included, but it was stripped before the message was sent to the peer. However, if a voip_options parameter was attached to a Java_com_whatsapp_voipcalling_Voip_nativeHandleCallGroupInfo message, it would be forwarded to the peer device. I confirmed this by sending malformed JSON looking at the log of the receiving device for an error.
The voip_options parameter is processed by WhatsApp in three stages. First, the JSON is parsed into a tree. Then the tree is transformed to a map, so JSON object properties can be looked up efficiently even though there are dozens of them. Finally, WhatsApp goes through the map, looking for specific parameters and processes them, usually copying them to an area in memory where they will set a value relevant to the call being made.
Starting off with the JSON parser, it was clearly the PJSIP JSON parser. I compiled the code and fuzzed it, and only found one minor out-of-bounds read issue.
I then looked at the conversion of the JSON tree output from the parser into the map. The map is a very efficient structure. It is a hash map that uses FarmHash as its hashing algorithm, and it is designed so that the entire map is stored in a single slab of memory, even if the JSON objects are deeply nested. I looked at many open source projects that contained similar structures, but could not find one that looked similar. I looked through the creation of this structure in great detail, looking especially for type confusion bugs as well as errors when the memory slab is expanded, but did not find any issues.
I also looked at the functions that go through the map and handle specific parameters. These functions are extremely long, and I suspect they are generated using a code generation tool such as bison. They mostly copy parameters into static areas of memory, at which point they become difficult to trace. I did not find any bugs in this area either. Other than going through parameter names and looking for value that seemed likely to cause problems, I did not do any analysis of how the values fetched from JSON are actually used. One parameter that seemed especially promising was an A/B test parameter called setup_video_stream_before_accept. I hoped that setting this would allow the device to accept RTP before the call is answered, which would make RTP bugs interaction-less, but I was unable to get this to work.
In the process of looking at this code, it became difficult to verify its functionality without the ability to debug it. Since WhatsApp ships an x86 library for Android, I wondered if it would be possible to run the JSON parser on Linux.
Tavis Ormandy created a tool that can load the libwhatsapp.so library on Linux and run native functions, so long as they do not have a dependency on the JVM. It works by patching the .dynamic ELF section to remove unnecessary dependencies by replacing DT_NEEDED tags with DT_DEBUG tags. We also needed to remove constructors and deconstructors by changing the DT_FINI_ARRAYSZ and DT_INIT_ARRAYSZ to zero. With these changs in place, we could load the library using dlopen() and use dlsym() and dlclose() as normal.
Using this tool, I was able to look at the JSON parsing in more detail. I also set up distributed fuzzing of the JSON binary. Unfortunately, it did not uncover any bugs either.
Overall, WhatsApp signalling seemed like a promising attack surface, but we did not find any vulnerabilities in it. There were two areas where we were able to extend the attack surface beyond what is used in the basic call flow. First, it was possible to send signalling messages that should only be sent after a call is answered before the call is answered, and they were processed by the receiving device. Second, it was possible for a peer to send voip_options JSON to another device. WhatsApp could reduce the attack surface of signalling by removing these capabilities.
I made these suggestions to WhatsApp, and they responded that they were already aware of the first issue as well as variants of the second issue. They said they were in the process of limiting what signalling messages can be processed by the device before a call is answered. They had already fixed other issues where a peer can send voip_options JSON to another peer, and fixed the method I reported as well. They said they are also considering adding cryptographic signing to the voip_options parameter so a device can verify it came from the server to further avoid issues like this. We appreciate their quick resolution of the voip_options issue and strong interest in implementing defense-in-depth measures.
In Part 5, we will discuss the conclusions of our research and make recommendations for better securing video conferencing.

Consumers are much more likely to fall for spam during the season of giving.

The use of the cloud continues to grow as private citizens and businesses see the benefits of offsite storage and shared services. Many companies are coming to rely on this technology, as it allows them to scale resources and allow remotely-located employees to access applications and work via the Internet. Many options are available today […]

The post CompTIA Cloud+ Certification: An Overview appeared first on InfoSec Resources.

CompTIA Cloud+ Certification: An Overview was first posted on December 12, 2018 at 9:59 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

Operation Sharpshooter uses a new implant to target mainly English-speaking nuclear, defense, energy and financial companies.

The news comes amid reports that a Chinese intelligence-gathering effort was behind the massive Marriott hotel data breach.

This phase is the first of several where the red team actively interacts with the target’s environment. Some of these phases tend to blend together, as the line between gaining initial access and establishing a foothold on the target network can be a fine one. In the gaining access phase, the red team takes steps […]

The post Red Team Assessment Phases: Gaining Access appeared first on InfoSec Resources.

Red Team Assessment Phases: Gaining Access was first posted on December 12, 2018 at 8:28 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

Experts sound off on how companies can work with their third-party suppliers and partners to secure the end-to-end supply chain.

Flaws in the mobile site were leaving users vulnerable to attackers who could have reset their user passwords and hijacked their accounts.

Google has disclosed the second security hole in its Google+ social network in three months.

Waymo už spustilo provoz autonomních vozidel a Tesla se k tomu postupnými kroky chystá také. S tím jak budou vozidla umět řídit bez lidského řidiče, ale nastává několik nových problémů, které se netýkají samotné jízdy. Elon Musk totiž na otázku nebezpečí autonomních vozidel odpověděl, že to ...

As CAPTCHA-haters know to their frequent irritation, the death of the text-based Completely Automated Procedures for Telling Computers and Humans Apart tends to be exaggerated.

Data brokers are tracking 200 million mobile devices in the US, updating locations up to 14,000 times a day, the New York Times has found.

Adobe is closing out this year with its December Patch Tuesday update to address a massive number of security vulnerabilities for just its two PDF apps—more than double the number of what Microsoft patched this month for its several products. Adobe today released patches for 87 vulnerabilities affecting its Acrobat and Reader software products for both macOS and Windows operating systems, of

LinuxSecurity.com: Google has disclosed the second security hole in its Google+ social network in three months. This one exposed private information from 100 times as many users as the first, and has prompted the company to hasten the service's demise.

LinuxSecurity.com: A recently patched trio of flaws in Samsung's mobile site was leaving users vulnerable to attackers who could have reset their user passwords and hijacked their accounts, The Register reports.

Notebook, miniaturní počítač o velikosti platební karty Raspberry Pi a Bash Bunny, tedy speciálně navržený nástroj pro provedení a automatizaci útoků prostřednictvím USB. To jsou tři nástroje, které využívali hackeři nejčastěji k útokům na banky v posledních dvou letech. Detaily útoků označovaných jako DarkVishnya, které byly zacílené především na finanční organizace ve východní Evropě, odkryli bezpečnostní experti z antivirové společnosti Kaspersky Lab.

Microsoft today, on its year-end December Patch Tuesday, released security updates to patch a total 39 vulnerabilities its Windows operating systems and applications—10 of which are rated as critical and other important in severity. One of the security vulnerabilities patched by the tech giant this month is listed as publicly known at the time of release, and one is a zero-day reported as being

Executive summary

In October 2018, our AEP (Automatic Exploit Prevention) systems detected an attempt to exploit a vulnerability in the Microsoft Windows operating system. Further analysis led us to uncover a zero-day vulnerability in ntoskrnl.exe. We reported it to Microsoft on October 29, 2018. The company confirmed the vulnerability and assigned it CVE-2018-8611. Microsoft just released a patch, part of its December update, crediting Kaspersky Lab researchers Boris Larin (Oct0xor) and Igor Soumenkov (2igosha) with the discovery.

This is the third consecutive exploited Local Privilege Escalation vulnerability in Windows we discovered this autumn using our technologies. Unlike the previously reported vulnerabilities in win32k.sys (CVE-2018-8589 and CVE-2018-8453), CVE-2018-8611 is an especially dangerous threat – a vulnerability in the Kernel Transaction Manager driver. It can also be used to escape the sandbox in modern web browsers, including Chrome and Edge, since syscall filtering mitigations do not apply to ntoskrnl.exe system calls.

Just like with CVE-2018-8589, we believe this exploit is used by several threat actors including, but possibly not limited to, FruityArmor and SandCat. While FruityArmor is known to have used zero-days before, SandCat is a new APT we discovered only recently. In addition to this zero-day and CHAINSHOT, SandCat also uses the FinFisher / FinSpy framework.

Kaspersky Lab products detected this exploit proactively through the following technologies:

1. Behavioral detection engine and Automatic Exploit Prevention for endpoint products
2. Advanced Sandboxing and Anti Malware engine for Kaspersky Anti Targeted Attack Platform (KATA)

Kaspersky Lab verdicts for the artifacts used in this and related attacks are:

• HEUR:Exploit.Win32.Generic
• HEUR:Trojan.Win32.Generic
• PDM:Exploit.Win32.Generic

Brief details – CVE-2018-8611 vulnerability

CVE-2018-8611 is a race condition that is present in the Kernel Transaction Manager due to improper processing of transacted file operations in kernel mode.

This vulnerability successfully bypasses modern process mitigation policies, such as Win32k System call Filtering that is used, among others, in the Microsoft Edge Sandbox and the Win32k Lockdown Policy employed in the Google Chrome Sandbox. Combined with a compromised renderer process, for example, this vulnerability can lead to a full Remote Command Execution exploit chain in the latest state-of-the-art web-browsers.

We have found multiple builds of exploit for this vulnerability. The latest build includes changes to reflect the latest versions of the Windows OS.

A check for the latest build at the time of discovery: Windows 10 Redstone 4 Build 17133

Similarly to CHAINSHOT, this exploit heavily relies on the use of C++ exception handling mechanisms with custom error codes.

To abuse this vulnerability exploit first creates a named pipe and opens it for read and write. Then it creates a pair of new transaction manager objects, resource manager objects, transaction objects and creates a big number of enlistment objects for what we will call “Transaction #2”. Enlistment is a special object that is used for association between a transaction and a resource manager. When the transaction state changes associated resource manager is notified by the KTM. After that it creates one more enlistment object only now it does so for “Transaction #1” and commits all the changes made during this transaction.
After all the initial preparations have been made exploit proceeds to the second part of vulnerability trigger. It creates multiple threads and binds them to a single CPU core. One of created threads calls NtQueryInformationResourceManager in a loop, while second thread tries to execute NtRecoverResourceManager once. But the vulnerability itself is triggered in the third thread. This thread uses a trick of execution NtQueryInformationThread to obtain information on the latest executed syscall for the second thread. Successful execution of NtRecoverResourceManager will mean that race condition has occurred and further execution of WriteFile on previously created named pipe will lead to memory corruption.

Proof of concept: execution of WriteFile with buffer set to 0x41

As always, we provided Microsoft with a proof of concept for this vulnerability, along with source code. And it was later shared through Microsoft Active Protections Program (MAPP).

More information about SandCat, FruityArmor and CVE-2018-8611 is available to customers of Kaspersky Intelligence Reports. Contact: intelreports@kaspersky.com