Oracle CSO is right

The internet (or at least twitter) is exploding regarding this, now deleted, post : Mary Ann Davidson blog post

Let me start by saying that she is right. Yes, she’s right. Breaking the EULA is against the law. You can’t argue about that.

You can’t argue that they should be paying a bug bounty. You may *want* them to pay a bug bounty, but that is the companies decision. If they choose not to pay a bug bounty, that’s their prerogative.

As a consumer, you can choose to use their product (EULA and all) or not. That is something that you have control over.

As a researcher, you can choose to break the EULA or not. Arguing that someone should modify their EULA so that what you’re doing isn’t a violation is childish.

I wish Oracle had stood by their CSO and left the blog online. I understand that they don’t want additional scrutiny on their product, but the scrutiny will be there irregardless (as it has been for many years now). Leaving the post online would have shown some ‘backbone’. If INFOSEC goes PC, it’s bad for us all. I’d rather someone tell me what they really think and we can go from there.

!Dmitry
dmitry.chan@gmail.com

Play some D!

Hi there. Long-time-no-blog 🙂

If you haven’t already, go read this: https://t.co/d2hwhmzzuz

Note: this blog applies to Corporate networks. If you’re a coffee shop or a college, you’re on your own 🙂

I’ve been a network defender for many years. I currently work for a software company that builds network software which helps companies gain insight into how their network is being used and/or abused. I didn’t choose to go into network defense – it chose me. In 1997 at my first “real job” out of college, I was a part of a team that tracked down some hackers that were running around owning a bunch of Solaris servers. From that day, I was hooked.

Network defenders don’t get a lot of credit. If you do your job right, no one ever talks about it. If you do your job wrong, you’ll hear about it every day for the rest or your short-lived career. An attacker can be wrong a million times and only needs to be right once. That’s an advantage. An attacker can spend 2 years in the bowels of one software app. A defender cannot. Accept this fact and move on…we can still win. The attacker has to use your network whilst evading detection. A lot of them don’t spend a lot of time figuring out how to do this right. They don’t have to be stealthy about exfiltrating data because it hasn’t mattered – the defense has been weak. How many recent infections used the darknet as a C&C?…ummm, your network monitoring solution should be SCREAMING AT YOU if someone connects out via Tor or i2p.

The network is like a bodies immune system (though not nearly as complex). The job, if you’re up to it, is to be the immune system. You can’t stop all infections from getting in. In fact, it can be argued that infections must get in to build the immune system. Firewalls and other devices can block things that we have knowledge of; however, something that we haven’t previously encountered will eventually get in (maybe via email, hacked USB drive, 0-day, whatever). Our job is to detect the foreign body, eradicate it, and update the immune system such that that strain of virus can no longer get it. So, how can you do this?

1) know what is “normal” for each host on your network. What ports do they offer? What ports do they connect to? What do their traffic patterns look like for each port? Who do they talk to? Who talks to them? what network protocols do they speak? How long do sessions stay nailed up? If you know this sort of stuff, then an attacker exfiltrating a gig of data cannot be hidden…it’ll stick out like a clown at an IBM business meeting.

2) Method 1 will detect lateral movement, but if you employ dead space within your network, you can flag lateral movement with just a single packet. Use honeynets, host-based IDS, traffic analysis (why is engineering dept trying to talk to HR?), etc. Spray your databases with bogus data that should never be accessed. Put up fake file servers and watch for access or watermark the files and watch them if they move around the network. Be creative…make your network a hostile environment for those who would attack it. The locals know how to get around, the attacker will have to figure out how to move around the network. Make this a painful process for him/her.

3) Look for invalid use of standard ports. Have you ever seen Skype find an “out door” on a network…What about vpn, i2p, p2p, Tor,etc.? Sending outbound traffic over well known ports is very, very common on most networks I have monitored. For each outbound port allowed through your firewall, you should flag on anomalous traffic over that port. What is anomalous? If the port is 80, only valid HTTP should flow over that port. If the port is 443, only TLS/SSL should flow over that port. Find the people tunneling data or sessions out of your network and you have a short list of the folks to keep an eye on.

4) Let the users know that you are watching. If Mabel from Accounting comes in on Monday morning and uploads 2 gig of baby pictures to dropbox, you should go have a chat with her. Get the word out. User education is often overlooked…millions is spent on nifty software but you don’t even have a full time employee working on user education. Sad.

There’s a lot more that I could write, but network defense isn’t a “cookie cutter” operation. Each admin will have to be creative and come up with their own maze for the attackers to run. Good luck out there!

!Dmitry
dmitry.chan@gmail.com

OpenSSL ACCF Vulnerability (CVE-2015-1793)

A new vulnerability has been recently patched in OpenSSL:

During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and “issue” an invalid certificate.

This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication.

This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.

OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d
OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p

This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project.

The vulnerability description and its lack of a cool name (Heartbleed, POODLE, etc) makes it feel like this vulnerability is not that critical as it was believed to be.

The circumstances that are required here and the outcome, are a bit weak at the moment – though as more details come to light, the severity could be better justified.

REVIEW – “The Florentine Deception”, Carey Nachenberg

BKFLODEC.RVW   20150609

“The Florentine Deception”, Carey Nachenberg, 2015, 978-1-5040-0924-9,
U$13.49/C$18.91
%A   Carey Nachenberg http://florentinedeception.com
%C   345 Hudson Street, New York, NY   10014
%D   2015
%G   978-1-5040-0924-9 150400924X
%I   Open Road Distribution
%O   U$13.49/C$18.91 www.openroadmedia.com
%O  http://www.amazon.com/exec/obidos/ASIN/150400924X/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/150400924X/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/150400924X/robsladesin03-20
%O   Audience n+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P   321 p.
%T   “The Florentine Deception”

It gets depressing, after a while.  When you review a bunch of books on the basis of the quality of the technical information, books of fiction are disappointing.  No author seems interested in making sure that the technology is in any way realistic.  For every John Camp, who pays attention to the facts, there are a dozen Dan Browns who just make it up as they go along.  For every Toni Dwiggins, who knows what she is talking about, there are a hundred who don’t.

So, when someone like Carey Nachenberg, who actually works in malware research, decides to write a story using malicious software as a major plot device, you have to be interested.  (And besides, both Mikko Hypponen and Eugene Spafford, who know what they are talking about, say it is technically accurate.)

I will definitely grant that the overall “attack” is technically sound.  The forensics and anti-forensics makes sense.  I can even see young geeks with more dollars than sense continuing to play “Nancy Drew” in the face of mounting odds and attackers.  That a vulnerability can continue to go undetected for more than a decade would ordinarily raise a red flag, but Nachenberg’s premise is realistic (especially since I know of a vulnerability at that very company that went unfixed for seven years after they had been warned about it).  That a geek goes rock-climbing with a supermodel we can put down to poetic licence (although it may increase the licence rates).  I can’t find any flaws in the denouement.

But.  I *cannot* believe that, in this day and age, *anyone* with a background in malware research would knowingly stick a thumb/jump/flash/USB drive labelled “Florentine Controller” into his, her, or its computer.  (This really isn’t an objection: it would only take a couple of pages to have someone run up a test to make sure the thing was safe, but …)

Other than that, it’s a joy to read.  It’s a decent thriller, with some breaks to make it relaxing rather than exhausting (too much “one damn thing after another” gets tiring), good dialogue, and sympathetic characters.  The fact that you can trust the technology aids in the “willing suspension of disbelief.”

While it doesn’t make any difference to the quality of the book, I should mention that Carey is donating all author profits from sales of the book to charity:
http://florentinedeception.weebly.com/charities.html

copyright, Robert M. Slade   2015   BKFLODEC.RVW   20150609