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: “Security for Service Oriented Architectures”, Walter Williams

BKSECSOA.RVW 20150130

“Security for Service Oriented Architectures”, Walter Williams, 2014,
978-1466584020, U$61.97
%A Walter Williams walt.williams@gmail.com
%C #300 – 6000 Broken Sound Parkway NW, Boca Raton, FL 33487-2742
%D 2014
%G 978-1466584020 1466584025
%I CRC Press
%O U$61.97 800-272-7737 http://www.bh.com/bh/
%O http://www.amazon.com/exec/obidos/ASIN/1466584025/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1466584025/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/1466584025/robsladesin03-20
%O Audience i+ Tech 2 Writing 2 (see revfaq.htm for explanation)
%P 329 p.
%T “Security for Service Oriented Architectures”

Walt Williams is one of the sporadic, but thoughtful, posting members of the international CISSP Forum. He has come up with a significant text on an important topic.

After some preface and introduction, the book starts in chapter two, defining the four kinds of architecture in computer systems: infrastructure, software, data, and security. This chapter covers foundational concepts, as well as service oriented architecture SOA), and is, alone, worth the price of the book.

Chapter three, on implementation, comprises the bulk of the space in the work, and is primarily of interest to those dealing with development, although it does have a number of points and observations of use to the manager or security practitioner. “Web 2.0” (chapter four) has some brief points on those advanced usages. A variety of additional SOA platforms are examined in chapter five. Chapter six, on the auditing of SOA applications, covers not only the how, but also notes specific types of attacks, and the most appropriate auditing tools for each case. Much the same is done, in terms of more general protection, in chapter seven. Chapter eight, simply entitled “Architecture,” finishes off with sample cases.

It is an unfortunate truism that most security professionals do not know enough about programming, and most programmers don’t care anything about security. This is nowhere truer than in service oriented architecture and “the cloud,” where speed of release and bolt-on functionality trumps every other consideration. Williams’ work is almost alone in a badly under-served field. Despite a lack of competition, it is a worthy introduction. I can recommend this book to anyone involved in either security or development, particularly those working in that nebulous concept known as “the cloud.”

copyright, Robert M. Slade 2015 BKSECSOA.RVW 20150130