Nazar: Analyzing malware that was uncovered in leaked NSA files
research.checkpoint.com
research.checkpoint.com
I found malware that was installed remotely on to millions of Android users under the government "Life Line" program that also used readily available open-source code found on GitHub.
The malware used an open sourced virtualization shared object library (.so) named "VirtulApp" and also an open source software development kit called "TalkingData"
Both code sources were found on GitHub.
The malware in question hides its icon from the users screen but can be found under Settings/Apps but shows an icon for a well-known "Antivirus/Cleaner" app that has been removed from the Google Play store many times. The malware also shares much of the cleaner app's SDK's and excessive permissions.
The malicious app also contains several encrypted files in its assests directory that are decrypted into executable java .jar files to expand it's functionality.
Kaspersky Labs names this particular malware variant "Necro"
5a5ab39960d3b96be2b8bbea99477e6f
That is one conclusion. But, given that there seems to be a significant amount of code that's custom (the filesystem module), I'm not sure what that would accomplish. If that too was opensource and there was a tiny amount of glue code, then it would make some sense. Leave the most suspicious hooks(like all input device monitoring) to well known tools.
Based on the report, it is more likely that whoever group created it didn't have much knowledge. Using the Shutdown Alarm and pissing all over the system just to accomplish such a tiny task is difficult to justify, and that's what drew undue attention.
The authors call it خضر, a guardian angel type from the Quran that shares secret knowledge.
That aside, this is what drives me nuts about threat Intel: we use enough googlable Persian words and give enough hints we know Persian in our code and opsec and people have a full dossier that confirms we're Iranians? I assume there is more depth to their claims but you have to work for the reporting company to know it which makes the whole subset of the industry dubious if you ask me (but we know no one is, lol).
def path_normalize(path):
try:
path = re.sub('%(.+)%', (lambda m: ('%{0}%'.format(m.group(1)) if (m.group(1) not in datastore.ENV_VARS) else datastore.ENV_VARS[m.group(1)])), path)
except:
tedilog.error(...)
return path
return re.sub(r'%(.+)%', lambda m: datastore.ENV_VARS.get(m.group(1), m.group(0)), path) if result:
return True
return FalseIronically the most secure and cheapest thing a company could do was get compromised by a competent attacker who only wanted to launder small amounts of data or CPU cycles through your network, and in exchange keeps your servers all patched and up to date for you to keep out other attackers.
"OpenBSD co-founder Theo de Raadt, cited as a top el8 target, angrily refused to discuss the compromise in late July of a file server maintained by the open-source, Unix-based operating-system project. On Aug. 1, a dangerous Trojan horse program was discovered amid the code for OpenBSD, which is used by thousands of organizations and renowned for its security.
While de Raadt wouldn't comment on whether there were any suspects in the case, the lead article in the latest el8 newsletter, published in early July, contains an obvious smoking gun. The article begins with several lines of screen-display from what appears to be an OpenBSD.org system. The "w-command" output suggests that attackers had access to one of de Raadt's accounts."[3]
[1]https://www.redhat.com/en/about/press-releases/shelton
[2]https://www.nsa.gov/what-we-do/research/selinux/documentatio...
[3]https://www.cc.gatech.edu/computing/acmnews/msg00221.html
The cool thing is, anyone can audit the kernels any time, and even if Theo's or Linus's accounts get compromised, the backdoor will be observable by everyone.
Try that with Windows: we have no idea what's in there, we never will, and MS has zero incentive to tell us.
1. https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-...
If it is an allied partners tool, they will reach out to the other intelligence agency and deconflict. The other agency will confirm access and share with the US.
If it is a foreign toolkit (Iranian in this example), they have likely reverse engineered the tools and will piggy-back on them to access your system. Another option is 4th party collection where they use access to Iranian networks to siphon off the data the Iranians have collected on you.
If either of these turn out to be bogus, it will be treated as a false positive and they will reinfect your machine ignoring the warning.
Certainly the breakdown in influence for say your standard PC will be hard to avoid any USA input, no matter the OS due to code submissions/contributions and then that's presuming honest location actors. Let alone binary blobs for drivers.
So hardware and OS, you will be pushed to avoid any USA influence.
After all USB, Intel did that, clearly USA influence, as are many standards, so I dare say that unless you build your own CPU and everything, you will be having some USA influence upon your system, one way or another. Let alone many other countries.
Heck even all those 6502/Z80 systems - USA companies invented those, so not even the humble Sinclair ZX81 would still have USA in there.
Though I'm sure that Russia and China do have computers without any USA in them. But then, you start to see how that works.
Gets down to trust, which for some can be a choice of sandwiches they don't like but they need to eat. Most like the sandwiches, some like all three flavours and some make their own flavours, but using ingredients from all three. Some will bake their own bread and use the standard ingredients. Very few will make their own flour, bread, ingredients all by themselve. Coz they still use an over and knife made by somebody else. See, the efforts to exclude any potential influence is so deep that to completely remove them all is beyond the scope of many. So gets down to a balance, a trade off of trust.