Slashdot Mirror

It can be done. In practical terms, it means you need to find more than one bug to exploit it and get around the protections.

Let's skip the CSO mumbo-jumbo... Here's the proper link: http://www.coresecurity.com/ad...

You buy/use the product for the sake of the product.

"Buying" an OS is not like buying a lawn chair. No matter how secure you think your OS is. You have to update systems. OpenBSD had remote holes in the default install in 1997, 2002, and 2007. We're about due for another, huh?

But more to the point, the mentality of the leader sets the mentality of the group and it affects membership. Operating systems don't spring up out of nothing. They're made by groups of people, and those people determine how the OSs turn out. You can't divorce the two.

Look at the late February part of the exchange during the disclosure process for OpenBSD's last remote hole. They say their focus is security, but, I suspect, their attitudes kept them from taking the right steps until their noses were pushed into the problem. This reflexive rejection of fault is an understandable attitude when you live in a contemptuous, dog-eat-dog social environment. You can't have humility when you get attacked. But you need humility when you're doing security.

And that's just the more direct impact on security effects. What about viability of the project at large? To join the project, you need expertise and thick skin already formed. Similarly for the community. Not exactly newbie friendly. The focus should not be on having skill, scorning ignorance, because skill doesn't come fully-formed from the head of Zeus. The focus should be on gaining skill. Because only by gaining will you have it.

As you learn the ins and outs of an OS you want to administer, you're investing time and effort that you're hoping will pay off in the future by being able to apply your skill with later, improved versions of the OS. You don't say "I'm learning OpenBSD 5.1", thinking you won't use anything else. You're banking on the developers and community to continue making that OS. I have several times looked at competing incipient open source projects and decided which app I wanted to use based on the strength of the community associated with it. They were going to teleport me a new lawn chair every year.

Not being able to see how corrosive Theo's attitude is to the people and the "product", not being able to understand how disdain weakens a community, increases inefficiency, and increases errors, means you're an ignorant worthless shit.

(That last bit there is kind of a ballsy rhetorical device, innit? I don't actually hate you, even if you don't understand. *hug*)

The system requirements are actually for the agent software. The firmware embedding is a persistence module that "self-heals" the agent software. The references to it surviving through reformatting and hard-drive replacement is the fact that the BIOS will re-install the agent on the new OS / Hard Drive. Black Hat 2009 had some research presented on the shortcomings of this technique, which is summarized on coresecurity: http://blog.coresecurity.com/2009/08/11/the-bios-embedded-anti-theft-persistant-agent-that-couldnt-response-handling-the-ostrich-defense/

That being said, preventing the agent from calling in when you know it should be calling in would be cause enough for an employer to be suspicious.

http://www.coresecurity.com/index.php5?module=ContentMod&action=item&id=1703

Read the timeline. Happy to help.

I run OpenBSD and I appreciate how (relatively) maintenance free it is, but that claim has *always* bugged me.

Two remote vulnerabilities in an install that leaves no services running in ~12 years, huh. Fascinating. Nevermind that almost nobody actually runs a system without services, or that a glance at the errata page shows that basically any non-root bug on OpenBSD can be escalated to give root privs. I dunno where you've been, but Linux distros stopped shipping with every service under the sun running a long time ago, and I can't remember the last time there was a remote root in a stock FreeBSD install either. Enlighten me as to the remote exploit I'm vulnerable to in my CentOS CD from 2 weeks ago, or my Debian disc, or is that just hyperbole?

To be fair, OpenBSD devs put effort into finding and eliminating common classes of vulnerabilities, but they fuck up (and succumb to the "I can't see it so it isn't there" mentality that most devs do) just like everyone else. I've always loved the timeline in the remote root advisory for OpenBSD's IPv6 code.

I'm not claiming Linux, FreeBSD, or anything else in particular is any better. Just that OpenBSD's security record no longer makes it unique or special. Y'all can stop now.

Bios, SMM. See Abstracts: http://corelabs.coresecurity.com/index.php?module=Wiki&action=view&type=publication&name=Persistent_BIOS_Infection http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.153.9106&rep=rep1&type=pdf (warning, pdf!)

I'm sure people are familar with LoJack for Laptops, where either due to a hook in BIOS (Dells and HPs have an option that will reinstall the LoJack software even if the BIOS is reflashed and all disks are zapped) or other means it gets loaded.

It's not a hook, LoJack comes with every BIOS. That's why it survives reflashing, you don't have the option of a BIOS without it. I co-wrote some article about this not long ago.

How to fix? The obvious fix would be signing the flash BIOS, but this completely locks out homebrewers wanting to do something different. Another fix would be having the flash process be offline, such as only though a USB port with a usb flash drive. However, NICs won't have USB ports present. Still another possible avenue would be a slot for a MicroSD card, but that adds complexity to the device. So, this isn't something easy to deal with. The only thing that might come close would be a DIP switch toggle to allow for unsigned images to be flashed (which is shipped off), and all updates signed.

None of this would work. Maybe it will make it more difficult, but can't protect you against a logical flaw in the firmware that allows you to execute code. Firmware is like any other software, what happens if you sign code that executes any code? then all code is automatically "signed".

The solution IMHO is complex, expensive and involves signing+software protections in the NIC and in the OS (I.E. iommu, etc.) and WILL fail with a sufficiently resourceful attacker.

BTW, awesome work.

I can't believe you got modded up. MAC is not bolted on at all, it is a kernel patch. This means you end up with a different kernel, where MAC is implemented from the ground up.

Equating MAC to jails also shows you simply don't understand what MAC is.

• If your webserver is compromised in a jail, can the webpages still be defaced? Yep. Not with a proper MAC policy.
• Running third party software that the OpenBSD team did not audit themselves which gets pwned? Far less likely with MAC. If the machine is exploited, minimal damage can be done.
• Need to restrict access from root to satisfy legal or policy requirements? Not possible with the outdated root = god model. It is possible with MAC.
• Want to restrict the permission a process has, instead of automatically granting it the same full permissions your user account has? Not possible on OpenBSD, possible with MAC. No, systrace doesn't cut it.

The industry is slowly heading in implementing MAC in some form, because DAC (Discretionary Access Control, the current standard) is simply inadequate. It's not all SELinux, Microsoft have Windows Integrity Levels where low privileged processes can't write to higher level processes, Ubuntu has AppArmor etc. The industry is heading in this direction because we realize that allowing all programs to have the full set of permissions equal to the user it is running as is not ideal.

The OpenBSD team stand out in their flat our rejection of the very idea, considering it to be too complex (does not have to bee, see SMACK, Tomoko or AppArmor), or horribly understanding it to the point they equate it with an ACL. IIRC Theo has said in several interviews it is basically security theater and not useful, which is just ignorant. Given they tend to actually ignore security vulnerabilities and argue rather than admit and fix them, the project doesn't seem that security focused to me.

Sorry, but I will take a fairly secure system that grants me the granularity to protect myself in the case of an attack, as opposed to a system which claims awesome security because it comes with almost no current software and nothing running by default.

I have to admit I was surprised reading this report and the attitude of the OpenBSD team to it, including trying to change the terms of what everyone considers a vulnerability. Since I'm not an OpenBSD guy and only know of them by their "secure by design" rep I gotta ask: Is this SOP with them? Is this their normal attitude? If so that is really not good and whether you hate OSNews or not I think their post deserves discussion. Because if it takes having a PoC attack in the wild before they'll do anything about a bug? I'm sorry but that is seriously not the attitude the team needs to have with so many devices in corporate settings running OpenBSD.

Thank God (and Torvalds) for Linux. There won't be any spyware on my machine.

Only if you're not installing binary blobs, i.e. drivers (*cough* nVidia *cough*) in the kernel and closed source programs (*cough* Flashplayer *cough*). And who knows what's lurking inside your closed-source BIOS (both on the motherboard and in network adapters)? I'm not saying that those binary blogs contain spyware, but I have no way (short of reverse-engineering them) to be sure they don't... and never will on subsequent updates.

Lots of notebooks come with a rootkit in their BIOS that receives instructions from a website. For details check the work of Alfredo Ortega and Anibal Sacco here and here. Disclaimer: I work with them at Core Security Technologies.

Thank God (and Torvalds) for Linux. There won't be any spyware on my machine.

Only if you're not installing binary blobs, i.e. drivers (*cough* nVidia *cough*) in the kernel and closed source programs (*cough* Flashplayer *cough*). And who knows what's lurking inside your closed-source BIOS (both on the motherboard and in network adapters)? I'm not saying that those binary blogs contain spyware, but I have no way (short of reverse-engineering them) to be sure they don't... and never will on subsequent updates.

Lots of notebooks come with a rootkit in their BIOS that receives instructions from a website. For details check the work of Alfredo Ortega and Anibal Sacco here and here. Disclaimer: I work with them at Core Security Technologies.

An exploit writer at Core Security Technologies has discovered a serious vulnerability that exposes users of Microsoft's Virtual PC virtualization software to malicious hacker attacks.

I would like to add that the exploit writer at Core Security Technologies that discovered this vulnerability is Nicolás Economou and congratulate him on the great work he has made.

Disclaimer: I also work at Core

Can anyone else confirm that Foxit has known security problems?

Sadly, yes. Foxit isn't happy with just doing basic rendering on PDF's, but wants to be a more completely alternative to Adobe's Reader. This includes things like running PDF's scripting, and makes it harder to implement securely.

I'm not saying a secure, full-featured PDF reader can't be made, so much as that you're a lot safer using a program that only does the basic rendering. Foxit doesn't fit the bill. It's also closed source >.>

Core Security Advisory FTW

It would be naive to think that only Acrobat Reader has vulnerabilities. Foxit Reader has some, too.

Anyway, it's probably still a good solution since Acrobat Reader is unnecessarily bloated, and I totally agree to disable Java.

http://oss.coresecurity.com/projects/pshtoolkit.htm

'nuff said

1. Download and install Python 2.6.1: http://www.python.org/ftp/python/2.6.1/python-2.6.1.msi
2. Download Impacket from http://oss.coresecurity.com/repo/Impacket-stable.zip (or maybe http://pypi.zestsoftware.nl/impacket/ or some other mirror)
3. Download the scanner from http://iv.cs.uni-bonn.de/uploads/media/scs.zip
4. Unpack Impacket into a folder, then install Impacket from a command line with c:\python26\python setup.py install
5. Run the scanner with the command c:\python26\python scs.py [start_ip] [end_ip]

(Hat tip to an AC comment at El Reg). Just a warning - it runs like a dog. I found that a passive Honeypot like Honeybot works well and is easier to install.

Here's a link to the actual Core Security vulnerability advisory on the CoreLabs homepage: http://www.coresecurity.com/content/adobe-reader-buffer-overflow .

and there's no need to crack the password if you want to connect to services using NTLM authentication: take a look at this tool: http://oss.coresecurity.com/projects/pshtoolkit.htm http://oss.coresecurity.com/pshtoolkit/doc/index.html

and there's no need to crack the password if you want to connect to services using NTLM authentication: take a look at this tool: http://oss.coresecurity.com/projects/pshtoolkit.htm http://oss.coresecurity.com/pshtoolkit/doc/index.html

Hi, There's no need to crack the LM&NT hashes of a password, you can use the hash directly on windows using this tool: http://oss.coresecurity.com/projects/pshtoolkit.htm basically you can impersonate on your own windows machine any user if you have the hash, and then use your Windows machine to authenticate to services using that user's credentials. There's no need to know the cleartext password, unless you explicitly want to know the cleartext password to test it on other services that do not use NTLM authentication.

Or you could use Core Force (Wikipedia article) where the full version is free as in beer and supports per application file system and registry checks as well as network connections. And also can be uninstalled if you wish unlike ZoneAlarm.

Bullshit. Core Security has some exploits for OS/X on their Impact product. Metasploit sure have some too.

Disclaimer: I do work for them.

The OpenBSD folk treat pretty much every bug as a security hole.

Unfortunately, that wasn't the case this time. As detaild in the advisory from CoreLabs, in fact, the OpenBSD folk refused to term this as anything but a denial of service issue and issued the patch as a "reliability fix" instead of a "security fix". This was done even after Core had provided proof-of-concept exploit code to the OpenBSD team. It wasn't until several days later that the proper categorization was done.

Now, maybe Core is spinning things innappropriately. And maybe the OpenBSD folks will want to correct the record. But right now, this doesn't look good at all...

Core's not a vulnerability scanner.

Don't get me wrong, it's a great product, but Core Impact and Immunity's Canvas are in a class of their own (well, along with Metasploit of course). Different focus for the product, so an entirely different set of requirements you'd compare them against. They're built specifically for penetration testing. They don't just look for vulnerabilities, they actually try to exploit those vulnerabilities and use them to exploit other vulnerabilities.

So if, for example, you were to compare the above three products with the 12 (11?) in the review, they'd look pathetic in terms of total number of exploit checks. That's a pretty important comparison for VA products, but not so much for pen-testing. For pen-testing, you want checks that you know you can actually use. For VA, you don't really care, you just want checks for things that someone might be able to use, even if you can't.

Of course, for the attacks they do have pen-test products can do much more with them, but again, just a different focus for the products.

Guys, you missed Core Security; it's one of the most solid vulnerability assessment tools I've used in 2006. http://www.coresecurity.com/ Its BY FAR one of the best-of-breed tools out there.

The product I used for a long time, Outpost, is there. It's good but it has too many issues. However where's Core Force? It's not a decent roundup if they didn't test that.

Wow, hadn't heard of it but it definitely sounds very interesting. Will have to check it out. For anyone else who hadn't heard of it let me add two quick details: it's free (apache license according to FAQ) and it's available here.

http://force.coresecurity.com/index.php

2. Regular folk should only install software from reasonably trusted sources.

I submit that, in _practice_, there are no "trustable source other than source, and even source has its limits.

If it is possible even the source isn't trustable, how can you begin to trust a pre-built binary -- yes, it is signed, but by who? MS? The government?

It seems the alternative to not installing untrusted sources is [practically] to not install anything, and that's just not very practical. :-(

-l

CORE FORCE provides inbound and outbound stateful packet filtering for TCP/IP protocols using a Windows port of OpenBSD's PF firewall, granular file system and registry access control and programs' integrity validation. These capabilities can be configured and enforced system-wide or on a per-application basis for specific programs such as email readers, Web browsers, media players, messaging software, etc.

Yes, it's lame. And I'll attempt to hijack this article by posting something actually useful which was rejected as a story in favor of this bullshit.

Core Force is a free (as in beer) application which provides inbound and outbound stateful packet filtering for TCP/IP protocols using a Windows port of OpenBSD's PF firewall, granular file system and registry access control and programs' integrity validation. These capabilities can be configured and enforced system-wide or on a per-application basis for specific programs such as email readers, Web browsers, media players, messaging software, etc.

Screenshots here.

Basically, the way it works by default is much like ZoneAlarm. If an application hasn't been configured, you get an alert saying "XYZ.exe is trying to access 87.65.43.21... allow/deny?" And you have the option to add it as a permanent rule. Unlike ZoneAlarm, however, it's not an all-or-nothing option. You can choose to allow only outbound port 80 traffic to 12.34.56.0/24 from source port 10431 with certain TCP flags and on the 2nd network interface if you choose.

This also applies to the filesystem. Grant read/write/execute access anywhere from an entire drive, to directories, down to the individual file level. Choose whether or not permissions propogate to child files/directories. Ditto for the registry. As the about page describes, it's a powerful firewall for not just tcp/ip, but also for the filesystem and the registry.

I ran Core Force on my old machine and it was really interesting to watch just how many times Windows phones home. After a while, I just setup default deny rules for all Microsoft IP addresses. But damn if there wasn't a ton of background communication going on for all sorts of applications. It takes a while to get the configuration right and for trusted applications that you don't want to go through the hassle of configuration everything in minute detail (eg: games where you don't want to have a popup right in the middle of fragging someone), you can just assign it full rights to the system as if you're running without Core Force.

Yes, it's lame. And I'll attempt to hijack this article by posting something actually useful which was rejected as a story in favor of this bullshit.

Core Force is a free (as in beer) application which provides inbound and outbound stateful packet filtering for TCP/IP protocols using a Windows port of OpenBSD's PF firewall, granular file system and registry access control and programs' integrity validation. These capabilities can be configured and enforced system-wide or on a per-application basis for specific programs such as email readers, Web browsers, media players, messaging software, etc.

Screenshots here.

Basically, the way it works by default is much like ZoneAlarm. If an application hasn't been configured, you get an alert saying "XYZ.exe is trying to access 87.65.43.21... allow/deny?" And you have the option to add it as a permanent rule. Unlike ZoneAlarm, however, it's not an all-or-nothing option. You can choose to allow only outbound port 80 traffic to 12.34.56.0/24 from source port 10431 with certain TCP flags and on the 2nd network interface if you choose.

This also applies to the filesystem. Grant read/write/execute access anywhere from an entire drive, to directories, down to the individual file level. Choose whether or not permissions propogate to child files/directories. Ditto for the registry. As the about page describes, it's a powerful firewall for not just tcp/ip, but also for the filesystem and the registry.

I ran Core Force on my old machine and it was really interesting to watch just how many times Windows phones home. After a while, I just setup default deny rules for all Microsoft IP addresses. But damn if there wasn't a ton of background communication going on for all sorts of applications. It takes a while to get the configuration right and for trusted applications that you don't want to go through the hassle of configuration everything in minute detail (eg: games where you don't want to have a popup right in the middle of fragging someone), you can just assign it full rights to the system as if you're running without Core Force.

CORE FORCE provides inbound and outbound stateful packet filtering for TCP/IP protocols using a Windows port of OpenBSD's PF firewall, granular file system and registry access control and programs' integrity validation. These capabilities can be configured and enforced system-wide or on a per-application basis for specific programs such as email readers, Web browsers, media players, messaging software, etc.

http://force.coresecurity.com/ TCP/IP, File and Registery ACL's

Compared to deleting your entire system?

Nobody cares about system files that can be replaced within hours. The important stuff generally does not require write access to do it.

All in all, this system that I use is fairly immune to viruses. I'm sorry yours is not, but at least you have the ability to make it so on a Unixish system.

Well done, you have bent over backwards to lower privileges. Most users won't, and so, this point doesn't really prove anything.

You simply don't on a Windows system.

Incorrect. Look at CoreLabs Core Force. What's that you say? Not many people know about CoreForce? No, well, not many people know how to do what you have done either.

Regular users rarely install programs, and I never do.

Often in security discussions I see lots of uninformed speculation as to what "regular users" do. Suffice it to say that "regular users" do install software in large enough numbers that simply ignoring the issue is not enough.

Basically you've put together a badly hacked up version of what toolkits like SELinux, AppArmor or CoreForce give you in a much cleaner and more elegant way, which is commendable but not a route I'd recommend nor would I expect others to follow it. And don't get me started on trusted GUI paths. No consumer OS today gets this right - none. Just go read a usability study of trusted path systems to see what fun we're going to have integrating this into mainstream technology.

Why wait?

. 2004-08-23: Notification to vendor
. 2004-08-23: Notification acknowledgment received from vendor
. 2005-02-08: Publication of fixes and advisories

...as you can see here

Now I can understand why only 15 patch... they wait (need?) 6 months to patch only one...

But I can't think of a free equivalent of

Core Impact http://www.coresecurity.com/products/coreimpact/in dex.php

It's so easy, an AOL subscribing, Mac using, chimpanzee could figure out the GUI, yet its an extremely powerful tool for any security consultant or script kiddie with a lot of cash. It scans for exploits Nessus style, then tries to exploit them so you don't get all the false posatives Nessus does. It also has the ability to give you a shell on an exploited host and use that to further penitrate a network. It has a built in library of exploits and new ones can be added via a python API. It totally automates the penitration process! (No I do not work for Core Security Technologies)

I've written a few small, text only, c++ programs that would basically grep nmap logs to find potentially vulnerable systems, automatically test exploits on them and then attempt to continue the process recursivly through a nework.. by scanning off the exploited host (new version of scanner/expoiter is uploaded/executed by the original exploit's shellcode). It was buggy, CLI only, and only worked on a small scale with a couple exploits...more proof of concept then usable tool. I wonder if anyone would want to make a core impact style system by extending Nessus?

Core Impact. Just that its commercial doesn't mean it's not the same issue.
Good pals.
Flash movie with sample attack

Core Impact. Just that its commercial doesn't mean it's not the same issue.
Good pals.
Flash movie with sample attack

No, I tell a lie, sorry. The Core advisory does mention it: we were notified on 2004-07-28 and published a fix on 2004-08-03.

We need more of metasploit like project...
We need a core impact clone!