Check Point Research

It might be worth considering carefully how safe the practice of opening essentially random email links might be. Are you opening the links with a full suite of forensic measures in place, or are you dropping curl $URL into your terminal on your workstation? It looks like WSL isn't exactly a sandbox. It does seem to already be used by some malware: https://research.checkpoint.com/beware-bashware-new-method-malware-bypass-security-solutions/

In a world with drive-by exploits and where opening a link leaks information, it perhaps could be considered unsafe to open essentially random links from emails. I've definitely worked with developers who seem to believe that curl is magical and inures them against every possible attack.

Curiosity is a wonderful thing! It's just sometimes it can be dangerous to a person and to the people around them. It might not be a bad thing for people to learn a smidge of caution.

I'm not a reverse engineer or a white hacker but I like reading about it. Most of the malware is made for Windows OS because of the Windows' enormous market share.

Majority of information about Windows malware I get from big computer security companies' research blogs like:

https://www.trendmicro.com/en_us/research.html

https://www.proofpoint.com/us/blog

https://research.checkpoint.com/

https://blog.talosintelligence.com/

https://www.welivesecurity.com/en/

Microsoft also got good security research blog: https://www.microsoft.com/en-us/security/blog/

Majority of the research combes down to researching malware's capabilities regarding malware persistence, anti-VM techniques and anti-debugging techniques.

Here is for example good compilation of malware's anti-debugging and anti-VM techniques:

https://anti-debug.checkpoint.com/

https://github.com/CheckPointSW/Evasions

That link provides no actual information. It's like a superhero film: junk food for the mind.

Here's the actual article at Check Point, not linked from the garbage article:
https://research.checkpoint.com/simbad-a-rogue-adware-campaign-on-google-play/

Turns out the malware is delivered in the RXDrioder SDK, which developers incorporated to get ad revenue, I guess.

Check Point claims that the app developers appear to have been hoodwinked into incorporating the SDK because they are independent of the SDK developer. Which may mean that these DL numbers are not as inflated as people think.

Fuck. If that's true, our app market really is driven by 12-year-old boys. Which is why my serious technical apps with years of development behind them are selling like 3 copies. And why Apple thinks innovation equals new emojis.

That's an interesting idea.

I'd hesitate to implement it though, because of secondary risks. It would need to be thought through very carefully, and there are a whole bunch of abuse scenarios that would need to be avoided or mitigated.

As a rule, Mailpile does very little when it receives a mail - until the user has interacted with it, we have to assume the mail is junk and/or potentially hostile.

See the chapter on Oracles here: https://research.checkpoint.com/cryptographic-attacks-a-guide-for-the-perplexed/ - automatically triggering sender-controlled network access based on the contents of e-mail opens the door for such things.

This applies not only to cryptographic attacks, but also to more pedestrian exploitation of bugs in the app itself, or silly things like turning Mailpiles into DDoS attack robots.

Despite being an 'easy problem' it has led to code execution on android/ios:

https://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/

> We established that simply querying a database may not be as safe as you expect. Using our innovative techniques of Query Hijacking and Query Oriented Programming, we proved that memory corruption issues in SQLite can now be reliably exploited. As our permissions hierarchies become more segmented than ever, it is clear that we must rethink the boundaries of trusted/untrusted SQL input. To demonstrate these concepts, we achieved remote code execution on a password stealer backend running PHP7 and gained persistency with higher privileges on iOS. We believe that these are just a couple of use cases in the endless landscape of SQLite.

It's a multi-hundred-thousand line project (current count, excluding tests, is about 210,000). Like any project of a similar size, it has a history of security vulnerabilities. OpenBSD removed it because it was too much code to audit. OpenBSD dodged several issues like this RCE (https://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/) as a result.

See https://www.cvedetails.com/vulnerability-list/vendor_id-9237/Sqlite.html

Hundreds of thousands of lines of code are simply going to have vulnerabilities and bugs. It's unavoidable with that level of complexity. I'm skeptical anything that complicated is a wise choice for a general file format -- especially when smaller, simpler, and more easily debuggable and independently implementable formats exist.