CISA Gives Us A Starting Point

Everyone struggles with identifying the “right” vulnerabilities to patch. It’s a near universal problem. We are all wondering, “Which vulnerabilities in my long queue are going to get me?”

Most organizations calculate a CVSS (base score or amended) which a solid body of research starting with Alloddi & Massacci, 2014, demonstrates is inadequate to the task.

Exploit Prediction Scoring System (EPSS) is based in the above research, so it could provide a solution. But the web calculator cannot score each open vulnerability in our queue over time: we need to watch the deltas, not a point in time. There’s unfortunately, no working EPSS solution, despite the promise.

CISA have listed 300 “vulnerabilities -currently- being exploited in the wild” in Binding operational directive 22-01.

Finally, CISA have given us a list that isn’t confined to a “Top 10”: Start with these!

Top 10 lists provide some guidance, but what if attackers exploit your #13?

300 is an addressable number in my experience. Besides, you probably don’t have all of them in your apps. > 300. We all can do that much.

The CISA list provides a baseline, a “fix these, now” starting point of actively exploited issues that cuts through the morass of CVSS, EPSS, your security engineer’s discomfort, total vulnerabilities ==> organization “risk”. (If you’re running a programme based upon the total number of open vulnerabilities, you’re being misled.)

https://thehackernews.com/2021/12/why-everyone-needs-to-take-latest-cisa.html

Trojan Source

Trojan Source!

I first read about Trojan Source this morning (ugh, Yet Another Branded Vulnerability: YABV).

Yes, there is a continuing fire hose of vulnerability announcements. But, new techniques are actually fairly rare: 1-3/year, in my experience.

There is nothing new about hiding attack code in source. These are the “backdoors” every software security policy forbids. Hiding attack code in unicode strings by abusing the “bidi override” IS new and important (IMVHO). Brilliant research for which I’m grateful.

I’m a bit unclear about how attack code can supposedly be hidden through bidi override in comments. Every decent compiler strips comments during the transformation from source to whatever form the compiler generates, byte code (java), object, etc. Comments are NOT part of any executable format, so far as I know. And mustn’t be (take up needed space).

Still, attacks buried in string data is bad enough to take notice: every language MUST include string data; modern languages are required to handle unicode, the many language scripts that must be represented, and methods for presenting each script (i.e., bidi override). Which means exactly what the researchers found: nearly every piece of software that parses source into something executable (19 compilers and equivalent) is going to have this problem.

The other interesting research finding is how vendors reacted to being told about Trojan Source and how quickly they are fixing, if at all.

Only 9 vendors have committed to a fix. That is really surprising to me. If you want people to trust your software security, you’ve got to be rigorously transparent and responsive. Doh! What’s wrong with the other 10 vendors/makers? Huh? Let’s get with the program. Refusing to deal, dragging feet, or worse, ignoring appears as though you don’t care about the security of your product(s).

It’ll be interesting to see whether Trojan Source technique actually gets used by attackers and how fast that occurs. I hope that one or more researchers pay attention to that piece of the puzzle. Depending upon the research findings, at least (if not more) 75% of reported vulnerabilities never get exploited. Will Trojan Source? Only time will tell.

Many thanks to Brian Krebs for the excellent write up (below)

https://krebsonsecurity.com/2021/11/trojan-source-bug-threatens-the-security-of-all-code/

Cheers,

/brook