Trojan Family Ties | TechSNAP 230 | Jupiter Broadcasting

Rooting your Android device might be more dangerous than you realize, why the insurance industry will take over InfoSec & the NSA prepares for Quantum encryption.

Plus some great questions, a fantastic roundup & more!

Thanks to:

Get Paid to Write for DigitalOcean

Direct Download:

RSS Feeds:

Become a supporter on Patreon:

— Show Notes: —

Taking Root – Malware on Mobile Devices

Since June 2015, we have seen a steady growth in the number of mobile malware attacks that use superuser privileges (root access) on the device to achieve their goals.
Root access is incompatible with the operating system’s security model because it violates the principle that applications should be isolated from each other and from the system. It gives an application using root access a virtually unlimited control of the device, which is completely unacceptable in the case of a malicious application.
Malicious use of superuser privileges is not new in itself: in regions where smartphones are sold with privilege escalation tools preinstalled on them, malware writers have long been using this technique. There are also known cases of Trojans gaining such privileges after the user ‘rooted’ the device, i.e. used vulnerabilities to install applications that give superuser privileges on the phone.
They analyzed the statistics collected from May to August 2015 and identified “Trojan families” that use root privileges without the user’s knowledge: Trojan.AndroidOS.Ztorg, Trojan-Dropper.AndroidOS.Gorpo (which operates in conjunction with Trojan.AndroidOS.Fadeb) and Trojan-Downloader.AndroidOS.Leech. All these mobile malware families can install programs; their functionality is in effect limited to providing the capability to download and install any applications on the phone without the user’s knowledge.
A distinctive feature of these mobile Trojans is that they are packages built into legitimate applications but not in any way connected with these applications’ original purpose. Cybercriminals simply take popular legit apps and add malicious code without affecting the main functionality.
After launching, the Trojan attempts to exploit Android OS vulnerabilities known to it one after another in order to gain superuser privileges. In case of success, a standalone version of the malware is installed in the system application folder (/system/app). It regularly connects to the cybercriminals’ server, waiting for commands to download and install other applications.
There are popular “families” of Android malware.
Leech Family
This malware family is the most advanced of those described.
Some of its versions can bypass dynamic checks performed by Google before applications can appear in the official Google Play Store. Malware from this family can obtain (based on device IP address, using a resource called ipinfo.io) a range of data, including country of registration, address, and domain names matching the IP address. Next, the Trojan checks whether the IP address is in the IP ranges used by Google.
The malware also uses a dynamic code loading technique, which involves downloading all critically important modules and loading them into its context at run time. This makes static analysis of the application difficult. As a result of using all the techniques described above, the Trojan made it to the official Google Play app store as part of an application named “How Old Camera” – a service that attempts to guess people’s ages from their photos.
Ztorg family
On the whole, Trojans belonging to this family have the same functionality as the previous described.
The distribution techniques used also match those employed to spread Trojans from the Gorpo (plus Fadeb) and Leech families – malicious code packages are embedded in legitimate applications. The only significant difference is that the latest versions of this malware use a protection technique that enables them to completely hide code from static analysis.
The attackers use a protector that replaces the application’s executable file with a dummy, decrypting the original executable file and loading it into the process’s address space when the application is launched.
Additionally, string obfuscation is used to make the task of analyzing these files, which is quite complicated as it is, even more difficult.
It is not very common for malicious applications to be able to gain superuser privileges on their own. Such techniques have mainly been used in sophisticated malware designed for targeted attacks.

Will the insurance industry take over InfoSec?

“Insurance is a maturity indicator“
When insurance comes, full scale, to the InfoSec industry, maybe that means we have finally gotten to the point where we understand the risks enough to start putting money on it
While I can definitely see the argument that insurance companies are in a position to force their clients into certain minimum security practises, either to qualify for insurance, or for a reduced rate
At the same time, I foresee a bunch of useless certifications, extra bureaucracy, and more things like PCI-DSS audits that miss the point entirely
“People see insurance entering into security as a bad thing, and maybe it is, but it should not be unexpected. If something involves both risk and significant quantities of money, there are likely people trying to buy or sell insurance around it. The car industry is informative here. As is healthcare, and countless other industries.”
The article points points out the three basic requirements for insurance companies to be interested:
Significant risk associated with the space, e.g., dying in surgery, getting into a car wreck, etc.
Adequate money in the form of a population able to pay premiums.
Sufficient actuarial data on which to base the pricing and payout models.
I don’t know that that last measure can be met yet. Unlike with car insurance, it is much harder to predict what a company’s chances of getting breached are.
Considering factors like how high profile they are (fancier cars get stolen more), what infrastructure they use (newer cars are safer), how often they patch (this can be hard to measure, like how often you service your car, it might not work), doesn’t really give you enough information in order to price the insurance
In the end, pretty much every company has a 100% change to be breached, it can come down to how quickly it will be detected, and how much damage will be done
At this point, I don’t think the insurance industry is qualified, and we’ll either see them making so many payouts that they are losing money, or writing loopholes into insurance with vague sentiments like “industry standard security practises”, to weasel out of paying up
Predictions from the article:
Insurance companies will have strict InfoSec standards that will be used to determine how much insurance, of what type, they will extend to a customer, as well as how much they will charge for it
- As you would expect, companies who are deemed to be in poor security health will either pay exorbitant premiums or will be ineligible for coverage altogether
- In this world, auditors become the center of the InfoSec universe. Either working for the insurance companies themselves, or being private contractors that are hired by the insurance companies, these auditors will be paid to thoroughly assess companies’ security posture in order to determine what coverage they’ll be eligible for, and how much it will cost
- Insurance companies become, in other words, a dedicated entity that uses evidence-based decision making to incentivize improved security
- For both internal and audit companies, those certifications will have to be maintained the same way medical professionals have to maintain their knowledge. Not like a CISSP where you lose a credential if you don’t renew it, but where you’re just instantly fired if it lapses
“When you think about it, it’s not really insurance that’s making this happen, it’s industry maturity as a whole. It’s InfoSec becoming just like every other serious profession.”
“Think about a hospital, or an architecture firm. You can’t hire nurses who have an aptitude for caring, and who helped this guy this one time. Nope—have a credential or you can’t work there. Same with accountants, and architects, and electricians, and civil engineers.”
Insurance won’t fix everything (or anything?)
“We also need to accept that the standardization and insurance agencies won’t fix everything. Auditors make mistakes, companies can and will successfully lie about their controls, certifications only get you so far, and the insurance companies have their own interests that are often in conflict with the goal of increased security.”

The NSA books crypto recommendations

The NSA, in its role as the organization that sets cryptography standards used by the entire government, has updated its recommendations on what algorithms and key sizes to use
Currently, Suite B cryptographic algorithms are specified by the National Institute of Standards and Technology (NIST) and are used by NSA’s Information Assurance Directorate in solutions approved for protecting classified and unclassified National Security Systems (NSS).
A look at the site from a few months ago highlights some of the differences
- AES 128 was dropped. Former used for ‘SECRET’ with AES 256 for ‘TOP Secret’, AES 256 is recommended for both now
- ECDH and ECDSA P-256 were also dropped for ‘less’ secret information in favour of P-384
- SHA256 was also dropped. Surprisingly, SHA-384 remained the recommendation over SHA-512
- Additionally, new requirements that were not specified before were added
- Diffie-Hellman Key Exchange requires at least 3072-bit keys
- RSA for Key Establishment and Digital Signatures also now requires 3072 bit keys
IAD will initiate a transition to quantum resistant algorithms in the not too distant future. Based on experience in deploying Suite B, we have determined to start planning and communicating early about the upcoming transition to quantum resistant algorithms.
We are working with partners across the USG, vendors, and standards bodies to ensure there is a clear plan for getting a new suite of algorithms that are developed in an open and transparent manner that will form the foundation of our next Suite of cryptographic algorithms.
Until this new suite is developed and products are available implementing the quantum resistant suite, we will rely on current algorithms.
With respect to IAD customers using large, unclassified PKI systems, remaining at 112 bits of security (i.e. 2048-bit RSA) may be preferable (or sometimes necessary due to budget constraints) for the near-term in anticipation of deploying quantum resistant asymmetric algorithms upon their first availability.

Trojan Family Ties | TechSNAP 230