100kb of Unusual Code Protecting Nuclear, ATC and United Nations Systems

An anonymous reader writes: For an ex-academic security company still in the seeding round, startup Abatis has a small but interesting roster of clients, including Lockheed Martin, the Swiss military, the United Nations and customers in the civil nuclear and air traffic control sectors. The company's product, a kernel driver compatible with Windows, Linux and Unix, occupies just 100kb with no dependencies, and reportedly achieves a 100% effectiveness rate against intruders by preventing unauthorized I/O activity. The CEO of Abatis claims, "We can stop zero day malware — the known unknowns and the unknown unknowns." The software requires no use of signature files, white-listing, heuristics or sandboxing, with a separate report from Lockheed Martin confirming very significant potential for energy savings — up to £125,000 per year in a data center with 10,000 servers.

Comments

100% effectiveness against any unknown attacks

[Anonymous Coward]

Sounds legit.

Re:100% effectiveness against any unknown attacks

[AmiMoJo]

They actually admit that it's not really very effective:

"You wonâ(TM)t stop processes from running in memory, but you will stop processes writing to disk,â

Rogan admits that in server environments that may not reboot for months, or even years, HGFâ(TM)s write-prohibitions may not be so meaningful, since malign processes can do a lot of damage without writing to disk.

Even that is misleading, because if say an app has a vulnerability that allows arbitrary code execution in its process then that code will be able to write to all the places the app is allowed to write to. That can easily be enough to run numerous malware tasks, and in fact much malware runs on that basis because it doesn't require further exploits to get out of the app's process.

And its so simple its stunning!

[Anonymous Coward]

It just automatically turns the machine off whenever you power it on! Foolproof!

Re:And its so simple its stunning!

[Anubis IV]

It just automatically turns the machine off whenever you power it on! Foolproof!

That does go a long way towards explaining the power savings they were discussing...

Sounds like BS

[gweihir]

"Magic" technologies like this usually under-deliver, or do not help at all. In particular, a detection rate of 100% is simply impossible, already from purely theoretical observations and even more so in practice.

Re:Sounds like BS

[DeathToBill]

Come on, of course 100% detection rate is possible! We don't know about any threats it doesn't detect!

In other news...

[DeathToBill]

I have this explosives detector I'd like to know if you're interested in. It's used by the Iraqi government...

Re:'Numérotez vos abatis'...

[monkeyxpress]

It appears to be nothing more than a kernel mode IO monitor that allows you to assign disk IO permissions to processes. In other words, it is basically just doing what any modern kernel does anyway. I don't get the power saving thing though - that sounded very snake oil like. I mean, if your system isn't compromised, what CPU operations is it reducing exactly?

I imagine this thing started out as a legitimate third-party kernel monitor (they refer to watchdog) and then some marketing goons got involved.

Re:'Numérotez vos abatis'...

[Anonymous Coward]

Litteraly : "lèche un très gros pénis" but "suce une très grosse bite" would be a more common way to say it.

AppArmor

[ThePhilips]

From description, it sounds like the AppArmor.

Re:AppArmor

[smpoole7]

> it sounds like AppArmor

Or SE Linux, as others have noted.

It is possible to achieve high levels of security through integrity checking and behavior(al) control. It just costs a bit in performance and memory. And if you write something in very tight C, it's not going to be large.

I may have mentioned this here before; if so, I apologize. But a million years ago, back when MS DOS 5 came out, a friend and I developed something called the ARF Utilities. (To my endless amusement, you can still find it in a Google.) Our approach was integrity and behavior blocking.

One reason why DOS was so vulnerable at the time was because Microsoft kept rebuilding and reusing the same code. The entry point to the DOS kernel (the old INT21h interface) didn't change from DOS 5 through 6.22. Our integrity blocker did a simple search to find that in memory, then *patched* DOS to send all calls through the behavior blocker, which was resident in memory. We also hooked and examined a bunch of other stuff inside the kernel (including the INT 21h interface and the SHARE hooks -- the latter was a terrible security vulnerability and only the appearance of Windows 95, and the rapid demise of DOS, kept it from being exploiting widely and wildly.) The blocker was written in assembler and could fit in about 2K of memory, as I recall.

It also checked itself, and the integrity of an executed program's file, at startup, and each time a program was terminated. By "check," I mean it literally scanned its own code in memory, compared random CRCs taken of different blocks to generated values stored earlier and would instantly warn if DOS, the terminating program or itself had been tampered with. (You don't just do one "checksum" of a fixed length; you do different blocks, chosen at random, generated on the fly at system startup.)

We couldn't find a virus that could get around it. The worst we ever experienced was a hang that required a hard reboot. But the system wasn't altered. And yet, the Official Anti-Virus Community (which, at the time, was BIG business) rejected our approach, called us interlopers and marginalized us. Everyone back then wanted scanners, scanners, scanners. All of the tests were on scanners.

In sum: I have no idea if this particular company's code is snake oil or the Real Deal(tm). But don't just dismiss them. If you think outside the box, it is possible to find better ways to do something.

Just my opinion and worth every penny of what you paid for it. :)

Re:AppArmor

[KiloByte]

Sorry to break it to you, but the only reason no virus got around that is that no one bothered working around a blocker no one uses. In DOS, all it takes to duplicate OS calls is to copy their code, as every process has full access to the hardware and can do everything on its own. And then, any process can write to every location in memory, defeating any anti-virus or precaution imaginable. You would have to reimplement Bochs and interpret every opcode in software, effectively emulating a more secure platform. You can't securely run untrusted code without a MMU of some kind.

Re:AppArmor

[smpoole7]

> the only reason no virus got around that is that no one bothered working around a blocker no one uses

At the time, we actually had thousands of users of the ARF Antivirus, and we received more than one report that there were indeed efforts to hack it. :)

What you say is true *technically.* And you should change your username to "Deja Vu," because I (and my friends with similar approaches, like Zvi Netiv with Invircible) had to repeat this over and over. I finally got tired of it, and given that out of those thousands of downloads only ONE person ever bother to register/pay, it wasn't worth it. Fuggedaboutit, just use your virus scanner and we'll still be friends.

Never forget this: it's theoretically possible to do many things. But it is not always PRACTICAL. In the instant case, using your example, a virus that tried to emulate actual DOS calls, essentially duplicating the code internally, would be very large. Remember, this was back in the day of dial up modems and bulletin boards. And a virus that emulated processor opcodes would be even larger.

(And *cough* ... we also kept encrypted copies of critical system areas, and compared what we'd stored with what we found -- both on disk AND in memory -- from time to time. That made it much more difficult for the "stealth OS" hack that you describe.) (Heh.)

But I'm not going to waste time rehashing this argument. What I WILL warn against is what I saw your attitude produce, too many times to count: "since we can't guarantee 100% that a system can't be hacked, why bother?" I'm not saying that's what you believe, but I ran across that attitude too many times to count.

Sourceforge Hijacks the Nmap Sourceforge Account

[johanw]

Because /. editors seem to have inconvenient hollidays I'll just spam this topic with the bahaviour of their mother company:

From http://seclists.org/nmap-dev/2...:

From: Fyodor
Date: Wed, 3 Jun 2015 00:56:23 -0700

Hi Folks! You may have already read the recent news about Sourceforge.net
hijacking the GIMP project account to distribute adware/malware.
Previously GIMP used this Sourceforge account to distribute their Windows
installer, but they quit after Sourceforge started tricking users with fake
download buttons which lead to malware rather than GIMP. Then Sourceforge
took over GIMP's account and began distributing a trojan installer which
tries to trick users into installing various malware and adware before
actually installing GIMP. Of course this goes directly against Sourceforge
CEO Michael Schumacher's promise less than two years ago:

"we want to reassure you that we will NEVER bundle offers with any project
without the developers consent"
--http://sourceforge.net/blog/advertising-bundling-community-and-criticism/

So much for that promise! Anyway, the bad news is that Sourceforge has
also hijacked the Nmap account from me. The old Nmap project page is now
blank:

http://sourceforge.net/project...

Meanwhile they have moved all the Nmap content to their new page which only
they control:

http://sourceforge.net/project...

You can see at the top that the owners of the Nmap page are now
'sf-editor1', and 'sf-editor3'. You can click on those to see other
projects they have hijacked.

So far they seem to be providing just the official Nmap files (as long as
you don't click on the fake download buttons) and we haven't caught them
trojaning Nmap the way they did with GIMP. But we certainly don't trust
them one bit! Sourceforge is pulling the same scheme that CNet
Download.com tried back when they started circling the drain:

http://insecure.org/news/downl...

We will ask Sourceforge to remove the hijacked Nmap page, but more
importantly we want to reiterate that you should only download Nmap from
our official SSL Nmap site:

https://nmap.org/download.html

If you don't trust SSL by itself (and we don't blame you), you can also
check the GPG signatures: https://nmap.org/book/install....

Cheers,
Fyodor

PS: Ars Technica has a good article about the Sourceforge/GIMP fiasco:
http://arstechnica.com/?p=6734...

PPS: Sourceforge now claims they will stop trojaning software without the
developer's permission, but they've broken that exact promise before.

Cut the write enable line?

[Sangui5]

Chris Howden and John Plumb are the author and approver (respectively) from Lockheed..... Chris and John are lousy scientists.

The kindest way I can figure it is that the driver simply disables disk IO... hence there may be a small power savings from the lack of writes. Less kindly, they happened to measure lower power, and are reporting experimental noise as a solid result (see www-plan.cs.colorado.edu/diwan/asplos09.pdf for instance). We have no error bars (or even a # of runs), so it really isn't possible to say, but disabling disk writes could conceivably reduce power draw. The methodology section is sketchy enough to make solid conclusions impossible; the reporting of experimental details is worse.

Of course, this doesn't (and they admit it) stop me from hacking them in RAM... nor does it stop persistent firmware attacks (e.g. http://www.wired.com/2015/02/n...), nor does it stop me from trapping to ring 0, then trapping to SMM, then just ignoring their F*ING CODE BECAUSE I"'M IN SMM MODE BITCH!!! I GOTZ MY OWNZ ATA CODEZ

Or something.. I'd recommend just cutting the write-enable line on an old IDE drive, or rebooting periodically and running Tripwire from non-writable media (CD?). It's likely cheaper, and probably just as effective.

Re:'Numérotez vos abatis'...

[Mendy]

I don't get the power saving thing though - that sounded very snake oil like. I mean, if your system isn't compromised, what CPU operations is it reducing exactly?

There is a bit in the linked PDF which says...

"Abatis Hard Disk Firewall, was also tested using the same standardised environment and shown to block applications and background processes from executing; saving energy from a baseline configuration."

What they seem to have done in the test is taken a standard system and measured the power consumption. They've then tested that baseline with one of 3 3rd-party AV products and recorded the power consumption go up. They've then installed tested it with their kernel module that blocks I/O and unsurprisingly noticed that a system which isn't using the disks uses less power.

It also says...

"Between best case, HDF and worst case, AV Product 2 there is a potential annual cost saving in excess of £12 at server level, this scaling up to £125,000 in a data centre with 10,000 servers."

I would have thought that if you had 10,000 servers and wanted to avoid power I/O costs you wouldn't have specced them with physical storage in the first place and would be network booting them instead.

I can also do it with a single cable.

[Lumpy]

We used to use unidirectional ethernet cables. Basically the TX wires clipped out on the receiving end to the less secure network. You do need ethernet cards you can set to accept a link without having a full handshake going.

But it allowed us to set up the SCADA network to take the data stream we needed to get to the collection and reporting pc and UDP broadcast it. then the PC that can only receive set up to listen for and receive it, works great and is 100% hacker proof as hackers have yet to write code that can cause copper to grow back in a CAT-5e cable.

Now if we could keep the N00b SCADA programmers from bringing in their crap-tastic home laptops for programming changes and becoming the largest infection vector.

Re:'Numérotez vos abatis'...

[GoddersUK]

I'd really like to know on what principles this 'security driver' is based on

From TFS I'm going for homeopathy. It's tiny (less than 100 kb, compared to several GB for an OS installation), has no known mechanism of effectiveness ("the software requires no use of signature files, white-listing, heuristics or sandboxing"), uses meaningless techno-babble to explain how it works ("by preventing unauthorized I/O activity"), makes unrealistic claims of effectiveness ("reportedly achieves a 100% effectiveness rate against intruders ... The CEO of Abatis claims, 'We can stop zero day malware — the known unknowns and the unknown unknowns'") and also claims to save the world (" very significant potential for energy savings").

100% Effective threat detection algorithm

[John Allsup]

bool isThreatDetected(IoRequest req) {
  return true; // Caveat: may cause false positives
}

// In practice, any claims that software is this effective require detailed, convincing explanation and proof.

Re:'Numérotez vos abatis'...

[gbjbaanb]

Its a network driver that doesn't work. No network activity, ergo 100% security against network-bourne threats!

See, I should have been in marketing!

Adaptive, requiring 'training' & 'stability'?

[TheRealHocusLocus]

I'd really like to know on what principles this 'security driver' is based on

TFS I'm going for homeopathy.

If the marketing technobabble is correct the code is 100k but naught is said about data store, memory and persistent. Or whether the system satisfies these claims 'out of the box' or there is some training/learning period. Of course the pitch also does not indicate how often the Key Operator is called to investigate and override false alarms, and what the investigate/resolution process takes. Some ACs with experience might be useful...

You could have a 'train/run' switch that you flip to 'train' on first install during a period in which you do not reasonably expect intrusions, putting it through paces and trigger your software to check for updates, things like that, where it passively builds a profile of normal activity. Then flip it to 'run'. Then if it is a machine that does just a few things all day, the software has a pretty good idea of what to expect.

The payoff would come from how well you could parametrize the basic inputs --- stack state, communications endpoints and addresses, using directory hierarchy on disk --- and introduce a clever degree of fuzziness that also implements a sense of 'near' and 'far' on both class of operation and value.

Then maintain a pointer in some so-called 'phase space' and burn data into a sparse array to create a virtual landscape with erosion. In 'run' mode it is almost always hitting (or near) areas that have been populated. If the pointer strays from from the populated region we have an alarm.

For example, a process that has never accessed data outside its installed folders suddenly does so. Network addresses compared by closeness in the neighborhood.

Re:'Numérotez vos abatis'...

[TimothyLawless]

Based on the exclusions, it sounds like a Rule-based anomaly detection engine with some sort of self-training module. Ironically, this is one of the first types of IDS systems created, and is counted as one of the first works by Dorthy Denning (http://webpages.cs.luc.edu/~pld/courses/447/sum08/class9/denning.intrusion_detection_model.pdf). The most successful implementations have used the Markov chain based model. Their down side is that they require a degree of 'training' before the IDS model may go active; however, in a well understood environment like that of a windows server running windows applications, its possible the training could be done in the back-end shop and shipped to customers as part of the COTS product.