Boni Bruno

Decreasing Incident Response Time...

2014-10-07T16:36:00.002-07:00

Seems like security incidents are occurring more often with mild to significant impact on consumers and various organizations, e.g. JP Morgan Chase, Target, Sony, etc.

Referring to the Verizon Data Breach Report year after year confirms that incident response times to such incidents are increasing, rather than decreasing, with root cause identification of the problems not occurring for months after the security incident in many cases - this can cause a pessimistic view among many security teams, however, there are a lot of good things happening in the security space that I want to share with you.

Many organizations have readily invested in various effective security technologies and personnel training to help improve security posture and minimize risk accordingly. A critical component to the incident response problem is the time associated with weeding through all the false alarms generated by various security devices, e.g. firewalls, intrusion prevention systems, security reporting agents, etc. The problem is further exacerbated by the growing speeds of networks and network virtualization, many security tools simply can't process data fast enough on 10G, 40G, or 100G network environments or simple lack visibility.

The good news is that solutions are available to help maintain visibility in such high-speed networks. Such solutions can also correlate network transactions with security alarms to help identify problems faster and decrease incident response times. The key is to integrate loss-less network recording systems with existing security tools using feature-rich application programming interfaces (APIs). The APIs help with automating security related tasks.

Security automation is key to decreasing incident response time. Imagine being able to automate the retrieval and correlation of network transactions to any security log event aggregated into a SIEM, or mapping packet data to any IPS alarm, or pinpointing application threads that trigger a specific application performance alarm - this is all possible now with high-speed loss-less recording systems and API integration with SIEMs, Firewalls, IPS devices, and Application Performance Monitoring (APM) systems. Yes, I am assuming your organization invested in these solutions...

As a side note, Real-time NetFlow generation on dedicated appliances is proving to be a good solution where full recording options are not available due to privacy policy conflicts, these solutions can provide much better network visibility than legacy NetFlow implementations that rely on network sampling, especially over 40G and 100G network environments. NetFlow is coming back in a strong way to provide security teams much needed visibility, NetFlow isn't just for Network Operations anymore.

The bottom line is this, mainstream security products are becoming more open to integration with 3rd party solutions and high-speed network recording system are becoming more affordable. As a result, the security automation described above will become more prevalent among security operation teams as time goes on and this is a very good thing in my humble opinion.

The security industry as a whole is improving, there is much more collaboration going on now than ever before, and I am seeing some significant improvements being made among hardware and software vendors that make me feel very optimistic about our capabilities to decrease our incident response time moving forward. If your interested in seeing some of the concepts discussed here in action, drop me a note, I would be glad to setup a conference call and provide you a live demonstration...

Stay well,

Boni Bruno

Heartbleed Detection

2014-04-14T13:18:00.000-07:00

On April 7, the “Heartbleed” bug was announced. It’s a serious flaw in the OpenSSL 1.0 – 1.0.1 code series which affects all applications using it for encryption. In short, it means that anyone who can connect to the server can remotely read the server’s memory – including the SSL certificate secret key, usernames and passwords, and anything else.

With the Heartbleed bug exploit code in the wild, anyone can take advantage of the critical time between public exposure of the exploit and when all organizations can patch (or take offline) vulnerable systems. So, for almost every organization in the world, there are three questions that come to mind. The first question is “which of my public facing servers is vulnerable?” The second question is “have I been exploited since this became public?” And the third question is “what have I lost?”

Having a packet capture fabric or Endace Intelligent Network Recorder (INR) in place helps answer all three questions. I'll reference INR here.

Which of my public facing servers is vulnerable?

The first step is to use your database (you DO have a database matching services, servers, and operating systems, right?) to locate those systems known to be vulnerable and that are public facing. Take them offline and patch them. Those are the knowns. Now, what about the unknowns?
You cannot use the presence of malformed heartbeat requests to confirm or deny vulnerability – that just tells you somebody is attacking, which is perhaps a common event these last few days! It is the heartbeat response that identifies whether a server is vulnerable. So what you need is to send each of your servers an exploit request and then filter on just heartbeat responses from vulnerable servers. As it turns out, that is surprisingly easy if you have an EndaceProbe INR monitoring your network.
First, download the exploit code off the Internet, set it up on a workstation running outside your firewall on a known IP address X. Have it run the exploit against every IP address in your domain. That’s what the bad guys are going to do … beat them to it! If you can’t set up your own attack system, there are websites already online that will attack for you. You just need to send them your IP addresses to attack.

Next, on the EndaceProbe INR which is monitoring traffic, set up a visualization that is filtering bi-directionally on IP address X – your attack workstation’s address. That will isolate the exploit attempts and responses. This filtering will result in a small amount of data over the length of time it takes for your exploit workstation to work through your IP address space.

From this visualization, click on the “packets” view and enter the following display filter:

(ssl.record.content_type == 24) && (ssl.record.length > 64)

The (ssl.record.content_type == 24) identifies all heartbeat requests and responses. Heartbeat requests (both valid requests and exploit requests) are typically less than 64 bytes long. Valid heartbeat responses should also be less than 64 bytes. So the (ssl.record.length > 64) should only catch responses returning lots of data back to your attacking workstation. That means every packet that matches the above display filter is probably from a server that is vulnerable. Locate the server by its IP address, pull it offline and patch it. Note: If you have SSL servers listening on different ports, Endace has a protocol identification module built in, so filtering on SSL within Vision will capture all the SSL packets of interest regardless of port number!

Have I been exploited?

Until April 7, this bug had been undiscovered (publicly), but it has existed in versions of the OpenSSL code for more than two years. It is therefore very difficult for an organization to fully determine its overall risk of having been exploited if someone discovered the bug earlier and has been using it nefariously. But what we do know is that the bad guys are most certainly monitoring vulnerability releases, especially ones that are accompanied by simple-to-use exploit code! Therefore, it stands to reason that an organization’s risk of exploit is highest between public disclosure of the exploit and time-of-patch.
So having an EndaceProbe INR with even a few days’ worth of storage allows the organization to perform an exhaustive post-mortem for those critical hours or days of maximum risk. Fortunately that EndaceProbe INR you have sitting behind your firewall will have captured 100 percent of the traffic from the last few days. Time to put it to use!
From step one above, you now (hopefully) have a short list of IP addresses for servers that are vulnerable. To make the search efficient, first look for the exploit attempt, and then for the response. This two-step process works best because:

The amount of traffic into the server is typically much less than out. It is faster to search the traffic coming in.
The exploit arrives on port 443, so is easy to filter on that port. The response can go out on any port number.

It it is therefore much faster to find the exploit than to find the response, so only look for the response, if you know the exploit has occurred.
Going through your vulnerable IP addresses one at a time, use a visualization that filters on the server’s destination IP address and destination port 443. (If you use other ports for SSL you’ll want to check that traffic too.) Now launch Endace Packets™ and enter:

((ssl.heartbeat_message.type == 1) && (ssl.heartbeat_message.payload_length > 61))

This filter might result in some false positives depending on whether or not there are legitimate clients out there that use heartbeat payloads > 61 bytes, but 61 seems to be the common number used. This filter will identify heartbeat request packets where the ssl.heartbeat_message.payload_length is larger than normal – a strong indication of an exploit attempt.

If you see any results from this filter, then it is time to look at the heartbeat response. So, back to your visualization! Filter on the attacker’s IP address as the destination. You could just stop there and look at everything sent to the attacker on any port, but depending on how much traffic that is, you might want to step through one vulnerable server at a time. If slow and steady is your style, then you will also filter on the source IP address of the vulnerable server detected above, with destination port taken from the heartbeat request packet.

Now, launch Endace Packets and enter the same exploit response filter you used before:

(ssl.record.content_type == 24) && (ssl.record.length > 64)

This will identify if the server responded to the exploit. You’ve already confirmed that server is vulnerable, so it probably sent a large amount of RAM data back to the attacker. Bad news, but at least you know for sure you’ve been exploited. Now…

What have I lost?

The heartbeat response will consist of several IP packets forming a single TCP PDU. Overall size of the PDU will depend on how large the (false) payload size was in the exploit heartbeat request. The response PDU is easy to identify in Endace Packets, but it is encrypted so you won’t be able to see what is inside. Time for Wireshark!

Use the EndaceProbe INR download capability to download the exploit session to your workstation. You’ll need to get the private SSL key from the exploited server, load it in Wireshark, decrypt the response message, and determine whether anything important is there. It’s time-consuming work, but well worth knowing what, if anything, has been lost!

What about workstations?
The SSL heartbeat is symmetrical, so, in theory, an OpenSSL client can be attacked by a malicious server just as easily as a server can be attacked by a client. This should be your next concern. Windows and Mac appear to be safe, but what about your Linux workstations? Workstations are harder to test because they won’t respond to a direct attack. They have to go to a malicious website before you will see any exploit heartbeat requests coming to them.

Good luck with your mitigation efforts, and please let us know if there’s anything we can do to help with this process.

Regards,

Boni Bruno

2013 Las Vegas Interop Network Usage

2013-07-24T09:15:00.002-07:00

Interop Las Vegas is over for another year, and as we recover from the excess that comes with every event that happens in Vegas, we’ve had a chance to look at the data captured from the pair of EndaceProbe appliances I deployed on InteropNet. And they tell a fascinating story about what people do when they’re not listening to vendor pitches! For anyone not familiar with InteropNet, it’s the network that provides the 18,000 show visitors and 285 vendors that exhibit with connectivity. Given the nature of the show, it’s become a showcase in its own right for the very latest networking, security and monitoring products. We’re proud to have been invited to deploy our EndaceProbe appliances in the network analysis and forensics product category. The EndaceProbe appliances, with 10Gb Ethernet (10GbE) interfaces and 64TB of local storage, were deployed so that they could see, capture and record every packet on the network. Between Tuesday at 4:00 p.m. and noon on Thursday, the EndaceProbe appliances recorded an incredible 72 billion packets. The dropped packet counter on the EndaceProbe recorded zero packet loss, so when I say that 72 billion packets traversed the network, I really mean 72 billion packets traversed the network and captured every single one to disk. Those 72 billion packets translate to: 68GB of metadata that can be used to generate EndaceVision visualizations. 6.1TB of packet data that can be retrieved through EndaceVision in a few short clicks for a full payload investigation in packets, or Wireshark. Users of the network consumed more than 130GB of iTunes traffic (7th highest on the list of application usage) and 100 GB of bit torrent (10th highest on the list). Whether vendors should be taking this as an insight into how interesting their presentations are is an interesting question in its own right! On the network itself, the average bandwidth utilization was just 350 Mbps, however, what’s interesting – and what few organizations understand given the lack of fidelity in their monitoring tools – is that the network was regularly bursting to 8Gbps and had frequent spikes of 10Gbps (measured in the millisecond range). The ability to see traffic spikes at such a low level of resolution is critical for understanding the behavior of the network and planning for the future. With the wrong tools, you could easily be mistaken to thinking that a 1Gbps link would be sufficient to handle InteropNet traffic. But you’d be very wrong indeed…. An interesting anecdote from the NOC that highlights the power of EndaceVision came from an escalation inside the NOC that the show wifi was slow. In a few clicks, we were able to show that the problem was coming from a single user (Silvio, we know who you are!) who decided to download more than 300GB of data over the network and saturate the resource. So, until next year, we bid Las Vegas farewell and head home for a well deserved rest.

Packet Capture Retention Policy???

2012-08-16T17:31:00.002-07:00

How long should I store packet captures? How much storage should I provision to monitor a 10Gbps link? When is NetFlow enough, and when do I need to capture at the packet level? These are questions network operations managers everywhere are asking, because unfortunately best practices for network data retention policies are hard to find. Whereas CIOs now generally have retention policies for customer data, internal emails, and other kinds of files, and DBAs generally know how to implement those policies, the right retention policy for network capture data is less obvious. The good news is that there are IT shops out there that are ahead of the curve and have figured a lot of this out. Background To begin with, it’s important to clarify for your own organization what the goals are for network history. Some common answers include: Respond faster to difficult network issues Establish root cause and long-term resolution Contain cyber-security breaches Optimize network configuration Plan network upgrades. You may notice that the objectives listed above vary in who might use them: stakeholders could include Network Operations, Security Operations, Risk Management, and Compliance groups, among others. While these different teams often operate as silos in large IT shops, in best-practice organizations these groups are cooperating to create a common network-history retention policy that cuts across these silos (and in the most advanced cases, they have even begun to share network-history infrastructure assets, a topic we discussed here). Some of your objectives may be met by keeping summary information – events, statistics, or flow records for example – and others commonly require keeping partial or full packet data as well. A good retention policy should address the different types of network history data, including: Statistics Events Flow records – sampled Flow records – 100% Enhanced flow records or metadata (such as IPFIX, EndaceVision metadata, etc.) Full packet data – control plane Full packet data – select servers, clients, or applications “Sliced” packet headers – all traffic Full packet data – all traffic. Generally speaking, the items at the top of the list are smaller and therefore cheaper to keep for long periods of time; while the items at the bottom are larger and more expensive to keep, but much more general. If you have the full packet data available you can re-create any of the other items on the list as needed; without the full packet data you can answer a subset of questions. That leads to the first principle: keep the largest objects (like full packet captures) for as long as you can afford (which is generally not very long, because the data volumes are so large), and keep summarized data for longer. Next, you should always take guidance from your legal adviser. There may be legal requirements arising from regulation (PCI, Rule 404, IEC 61850, etc.), e-discovery, or other sources; this article is not meant to be legal advice. Now that said, in the absence of specific legal requirements that supersede, here are the best practices we’re seeing in the industry. Working the list from bottom to top: Packet data for all traffic: 72 hours Full packet data or “sliced” packet headers? The choice here will depend on how tightly controlled your network is and on what level of privacy protection your users are entitled to. For highly controlled networks with a low privacy requirement, such as banking, government or public utilities, full packet capture is the norm. For consumer ISPs in countries with high privacy expectations, packet header capture may be more appropriate. General enterprise networks fall somewhere in between. Whichever type of packet data is being recorded, the goal consistently stated by best-practice organizations is a minimum of 72 hours retention, to cover a 3-day weekend. For the most tightly-controlled networks retention requirements may be 30 days, 90 days, or longer. Packet data for control plane & for select traffic: 30+ days Control plane traffic can be extremely useful in troubleshooting a wide variety of issues. It’s also a type of traffic that is owned by the network operator, not the customer, so even networks that don’t record all traffic should keep history here. Traffic types of interest include for example: Routing protocols (OSPF, IS-IS, EIGRP, BGP; plus protocols like RSVP, LDP, BFD, etc. in carriers) L2 control plane (ARP, spanning tree, etc.) ICMP DHCP DNS LDAP, RADIUS, Active Directory Signaling protocols like SIP, H.225.0, SCCP, etc. GTP-C in mobile networks In addition to control plane traffic, in every network there are particular servers, clients, subnets, or applications that are considered particularly important or particularly problematic. For both control-plane and network-specific traffic of interest, organizations are storing a minimum of 30 days of packet data. Some organizations store this kind of data for up to a year. Flow records @ 100%: 120+ days Best-practice organizations record either enhanced metadata (such as that collected by EndaceVision), or at least basic NetFlow v5/v9/IPFIX. This flow data is useful for a wide variety of diagnosis and trending purposes. Although a few router models can generate flow records on 100% of traffic, best-practice is to separate this function onto a separate probe appliance connected to the network via tap, SPAN or matrix switch. The probe appliance both offloads the router/switch and also enhances flow data with DPI / application identification information. Best-practice here is to store at least 120 days of flow data. (We have seen organizations that keep 100% flow records for as long as seven years.) Samples and summaries: 2 years or more sFlow or sampled NetFlow, using 1:100 or 1:1000 packet samples, can be useful for some kinds of trending and for detecting large-scale Denial of Service attacks. There are significant known problems with sampled NetFlow, so it’s not a replacement for 100% flow, but it does have usefulness for some purposes. Summary traffic statistics – taken hourly or daily, by link and by application – can also be helpful in understanding past trends to help predict future trends. Because this data takes relatively little space, and because it is mostly useful for trending purposes, organizations typically plan to keep it for a minimum of two years. One point to remember in maintaining history over periods of a year or longer is that network configurations may change, creating discontinuities. It’s important to record every major network topology change or configuration change alongside your traffic history data, so you don’t compare incomparable data and draw the wrong conclusions. Average vs Peak vs Worst-case? One challenge faced in sizing network-history storage capacity is the fact that well-designed networks run well below 100% capacity most of the time, but in times of stress (which is when network history is most valuable) they may run much hotter. Should you size for 72 hours of typical traffic, or 72 hours of worst-case? The best-practice we’ve seen here is to make sure your network history system can capture at worst-case rate, but has enough storage provisioned for typical rate. The reasoning here is that when the network gets very highly loaded, someone will be dragged out of bed to fix it much sooner than 72 hours, so a long duration of history is not needed; but that person will want to be able to rewind to the onset of the event and will want to see a full record of what was happening immediately before and after, so having a system that records all traffic with zero drops is crucial. Here’s an example to make it concrete: Suppose you have a 10Gbps link that averages 1Gbps over a 24-hour period, and 3Gbps over the busiest hour of the day. Then 72 hours of full packet storage at typical load would require (1Gbit/sec x 72 hours x 3600 sec/hour / 8 bits/byte) = 32400 Gbytes, or about 32 terabytes. Under worst-case load, when recording is most important, it could run at the full 10Gbps, which would fill storage 10 times as fast. The good news is: best-practice here says you do not need to provision 10x the storage capacity, but you should be using a capture system that can record at the full 10Gbps rate. That means that in a worst-case scenario your storage duration would be more like 7 hours than 70; but in that kind of scenario someone will be on the case in much less than 7 hours, and will have taken action to preserve data from the onset of the event. Of course, the same considerations apply for other types of network history: systems need to be able to process and record at the worst-case data rate, but with reduced retention duration. Other considerations The above discussion slightly oversimplifies the case; there are actually two more important considerations to keep in mind in sizing storage for network history. First, most recording systems will store some metadata along with packet captures, and this adds some overhead to the storage needed – typically around 20%, though it may vary depending on the traffic mix and on the recording product you use. Second, while we say above you should provision storage for typical load, most organizations actually use projected typical load, extrapolating the traffic trend out to 18-36 months from design time. How far ahead you look depends on how often you are willing to upgrade the disks in your network recording systems. A three-year upgrade cycle is typical, but with disk capacity and costs improving rapidly there are situations where it can be more cost-effective to provision less storage up front and plan to upgrade every 24 months. Implementing the policy When organizations first take on the challenge of standardizing network-history retention policy, they nearly always discover that their current retention regime is far away from where they think it needs to be. Typically we have seen that implementing a best-practice retention policy happens in six phases: Create the “idealized” policy describing where you want to be, without regard to current state Inventory the current state and identify how far off it is from the ideal Set targets for 3-6 months, 12 months and 24 months Over the 3-6 month horizon, take low-hanging fruit by reconfiguring existing systems to optimize for the new policy, and identify what new technologies will be needed to achieve the chosen retention policy Over the 12-month horizon, pilot any new technologies that may be required to achieve the long-term policy Over the 24-month horizon, roll out these technologies network-wide. Summary checklist Bring together stakeholders to develop a common network-history retention policy Understand everyone’s objectives Check with legal adviser Choose what types of data will be kept for what purposes Set idealized retention goals for each Inventory current state and gaps Close the gaps over 24 months.

Why Protocol Validation is Important!!!

2010-11-22T18:37:00.000-08:00

I've played with a lot of security technologies over the years and I’m quite amazed at the lack of protocol validation implemented with a majority of the commercial security solutions in the market today.

Protocol validation is really a very effective way to address zero-day attacks, application attacks, worms, and numerous other attack vectors. For example, let's say your web server receives a client request for an unknown method, before processing such a request, ask yourself what is an effective way to deal with unknown method attacks. Would signatures be an appropriate solution? Maybe trapping the requests and creating an error on the web server would be a better solution – I would do this on the server side. I would also argue, at least for network security devices, that inspecting the traffic for any method that exceeds a set number of alphanumeric characters (this should be a configurable parameter) would be a better way to go...

Say some unknown method is received over the network that is not a GET, HEAD, POST, PUT or whatever else you deem suitable for your web serving environment, instead of trying to come up with various signatures to combat an unknown method attack, simply allow a set number of methods and address the unknown methods by limiting them to say 15 characters. Any unknown method attack that exceeds 15 characters (in this example) will not be allowed to the web servers. This will save on system resources, security analysis time, and provide a nice mechanism to address various protocol issues. Yes security signatures are important, but it’s a mistake to limit your security solutions to just signature matching alone - look into protocol validation as well!

The unknown method attack I describe here is just one example I'm highlighting to show that protocol validation can capture any variant of an unknown method attack quickly and efficiently. Same is true if you implement protocol validation on various URI parameters. You can also apply protocol validation to other services like MS RPC services, MS CIFS services, DNS, SSH, SIP, etc.

Remember Conficker? Conficker is a MS RPC worm that makes changes to UUID/Stub Lengths in Microsoft’s Operating Systems. Instead of relying on signatures to catch every variant of Conficker, why not use protocol validation to protect the various UUID/Stub Lengths in the OS and allow users to customize and set maximum stub lengths for each operation number and UUID accordingly? This would provide proactive protection against a variety of MS RPC attacks without relying on any signatures.

There are many benefits to incorporating protocol validation into your security solutions and it must become an integral part of any network security device being considered today to mitigate network attacks against your systems or you will simply be too exposed.

Next time you evaluate some sort of network security device, make sure you check whether protocol validation is being enforced in a comprehensive way, if not, move on...

Stay secure!

-boni bruno

Malicious PDF documents on the rise...

2010-01-04T14:24:00.000-08:00

There are some nasty malicious PDF files (read more…) going around the Internet for which most Anti-Virus tools provide little or no detection. As a good security precaution, if you use or read PDF files, you should take the following two actions:

1. Make sure you are using the latest version of Adobe Reader (formerly known as Adobe Acrobat Reader), which as of this writing is 9.2.0 (Open Adobe Reader and choose Help->About… to see what version you have installed, and then Help->Check for Updates to get the latest version.)

2. Open Adobe Reader and disable JavaScript by choosing Edit->Preferences->JavaScript and the uncheck the checkbox next to “Enable Acrobat JavaScript” as shown below.

Wishing you a safe computing year in 2010,

-boni bruno

Physical Access Control - The New Way

2009-06-26T21:50:00.000-07:00

Historically, physical access controls have never run over IP networks, but now with Cisco in the game, the convergence for a complete physical access control solution over IP networks is now a reality.

The Cisco Physical Access Control solution is made up of both hardware and software components. The Cisco Access Gateway connects door hardware (traditional readers and locks,as well as the new Hi-O® hardware from Assa Abloy) to an IP network. In wired deployments, the device is capable of being powered by Power over Ethernet (PoE). It is also possible to connect to the gateway over a Wi-Fi 802.11a/b/g wireless link.

The diagram below depicts a typical Cisco PAC archtiecture:

Since there is a gateway for each door, access control can be deployed incrementally, door by door. There is no central panel; this simplifies system design, wiring, and planning, resulting in significant cost savings over legacy architectures. Additional modules can be connected to the gateway, allowing for extensibility. All communication from and to the gateways is encrypted.
The Cisco Physical Access Control solution offers the following modules (in addition to the Access Gateway):

* Reader module: This module can connect to a complete set of door hardware, allowing an additional door to be controlled by the same gateway.

* Input module: Eight supervised inputs can be connected to this module and controlled
through the gateway.

* Output module: Eight outputs can be connected to this module and controlled through the gateway.

Cisco Physical Security Manager (CPSM) is the software application used to manage the Cisco Access Gateways on the network. The Web-based software provisions, monitors, and controls all the access control gateways on the network. Role-based access control policies are supported for CPSM. You can create access control policies for N-person, two-door, anti-passback, etc.

CPSM also integrates with MS Active Directory, LDAP, and some HR databases.

CPSM is integrated with the Cisco Video Surveillance family of products, enabling an organization to associate cameras with doors, and to view video associated with access control events and alarms.

In addition to basic access control features, Cisco plans to integrate physical access control with network security to provide a comprehensive solution that spans both areas of security, allowing enterprises to:

* Create and enforce policies so that network and application access is granted based on the physical location of employees

* Provide wireless access only if employees have badged into a physical location.

* Terminate an employee’s active VPN connection when that employee badges into a physical location

* Change an employee’s privileges on the network based on entering or exiting a secure area

There is no question that Cisco is accelerating convergence in the physical security industry. The move to integrate physical access control and network security is something I've been preaching for a while now, it will be interesting to see how this evolves over time. I'll keep you posted...

Stay secure,

-boni bruno

DRM Free Music - Wow what a concept!!!

2009-01-07T11:53:00.000-08:00

Have you heard the news??? Apple has convinced the big music studios to let them distribute DRM Free music.

http://www.nytimes.com/2009/01/07/technology/companies/07apple.html?_r=1&hp

It's about time and something the music industry should have considered long ago.

The issue now is that Apple is the only organization with the license to do this. This gives Apple too much leverage in my opinion. We need more legitimate distribution channels and keep things competitive for the benefit of consumers, but this is definitely a move in the right direction...

Well done!

- boni bruno

What Industry Executives need to know about DRM...

2008-05-18T14:44:00.000-07:00

DRM stands for Digital Rights Management. It has also become known as Digital Restrictions Management as a backlash from all the problems and issues DRM has caused hardware manufacturers, software development companies, media distributors and consumers over the years. Consumers want on demand music, video, movies anywhere at anytime and they are willing to pay for it. I've done enough research and field tests to make this claim. This is also true for media distributors and retailers who have been yearning for the ability to manufacture media on demand to consumers. However, many current DRM policies and technologies do not facilitate this kind of media access and distribution. Until we foster and promote better DRM strategies, money will continue to be lost to the pirates...

I meet with industry executives all the time and content protection and the secure distribution of content is a very big deal. DRM is important to the Entertainment, Music and Media industries, i.e. the content producers, in that these industries want to safe guard their intellectual property and copyright protected material from piracy so their financial interests can be protected. Make sense to me.

With respect to piracy, the music industry has been hit the hardest with significant drops in sales year over year. It's still very common to see people share music files over peer-to-peer networks and not think twice about having to pay a single cent. Also, boot leg copies of the latest movies are readily available on the net or DVD just about anywhere you go. Bottom line, piracy continues to run rampant and it's an issue that needs to be better addressed moving forward.

The goal behind DRM is to ensure that copyright protected media is accessible to only the consumers that pay for it. Many of the negative connotations associated with DRM are derived from the poor designs employed by many content protection schemes as well as from the notorious Digital Millennium Copyright Act passed in the U.S. in 1998. I'll talk more about DRM technologies later, but DMCA is the entertainment and media industries strategy to make it illegal for anyone to develop and use products that circumvent DRM related technologies. This is huge and has both good and bad implications. The spirit behind the DMCA law makes sense, but the law itself as written, interpreted and legally practiced has short comings. DMCA allows content producers to license and dictate how hardware manufacturers and software development companies enforce DRM technologies in their media related products. In short, media hardware manufacturers and software companies have to support and integrate licensed DRM technologies to comply with the mandates of DMCA.

As a result, there have been a slew of licensed DRM technologies integrated and deployed by various hardware manufacturers over the years from analog protection systems, Marcovision and Dwight Cavendish, to content protection systems like CSS, DTCP, HDCP, TIVOGUARD, etc. DCMA also influence software companies to embed DRM technologies into their products, e.g. Microsoft's Windows Media DRM and Real Network's Helix DRM. There has been extensive criticism that DMCA forces all companies that make media related equipment or software to support DRM technologies that financially benefit specific organizations only and no one else which potentially inhibit innovation and good old fashion competition. DMCA also makes litigation by media companies very easy regardless of whether a direct copy right violation has occurred. This has caused many respected scientific research and security related web portals to just shut down and has provoked many heated arguments about justice and the right to compete.

As technological advancements are made with High Definition TV, IPTV, Broadband, WiFi, and Mobile technologies, new emerging DRM systems are being developed to keep up - Advance Access Content System, Broadcast Flag, MagicGate, Open Mobile Alliance, SmartRight, Video Content Protection System are emerging DRM technologies that will be licensed in many products to come.

The big question I want you to think about is whether or not we are headed down the right path. Does DRM practices have to be so nasty? A well known example is Sony's decision to integrate a rootkit to copy protect their music CD's. This turned into a huge PR nightmare and caused Sony to recall the music cd's and rethink it's whole DRM strategy and left many consumers in a outrage! There are many cases where web sites were shutdown due to DMCA violations, it’s a good thing the safe harbor provisions were put into DCMA or many ISP would be out of business and half the internet would be gone.

I offer that there is a better solution. I believe the right DRM strategy is to make things simple and easily accessible to the consumers and media distributors. I believe consumers in general are good people and will pay for copy protected media if it’s readily available, globally reachable, and fast. This is not to say we throw security technologies out the door (God knows that would impact me financially), but rather make it clear to the industry that DRM strategies needs to evolve and focus less on restricting the rights of consumers and more to promote the availability and access channels that allow consumers to pay for copy protected material.

I'm a big fan of global media distribution networks and the download-and-burn concept. The sooner we go to market with IPTV, HDTV, High Speed Broadband & Mobile Communications, easily accessible and feature rich set top boxes and media devices, and employ the use of multiple broadcast and distribution channels and just flood consumers and media distributors with every imaginable means to buy licensed content - guess what?

THEY WILL!!!

Performance Anomalies Can Be A Sign of Bigger Problems...

2008-02-06T00:37:00.000-08:00

I have a great story to tell you...I get a call from one of my clients,
they are a big real estate management and development company
with many large Oracle databases and various Unix and Microsoft
systems, a large SAN, and they run the network on the high-end
Cisco stuff. Typical architecture for a large enterprise.

These guys have a lot of vendor consultants on site helping them out
with new Oracle Apps, Unix systems, etc. The problem, I'm told by one
of their Senior Vice Presidents, is intermittent performance problems that affect the network and the Oracle Apps.

Hmmm...probing him further for more details did not give me much. He did explain to me that none of their Oracle or Unix consultants saw any problems with anything, the system administrators didn't see any problems on the systems, but the network guys were seeing intermittent network utilization problems coming from the application servers - basically they're monitoring the network with SNMP and every now and then they get alarms stating high utilization of the network. They give this info to the consultants yet they find no problems.

Their VP asks me to do my own performance assessment and I did. I arrive on site and begin speaking with the network team. They basically tell me that two particular application servers intermittently consume a large amount of bandwidth. This has been going on and off now for many months and no one knows why.

So, I take a look at these two application servers. They happen to be Solaris Unix systems. I ran some netstat commands and saw that there were some input/output errors on these systems. I then proceeded to run some process status commands, I use both the ATT and UCB versions of ps when I want to get various process info. The weird thing here is that the UCB version of ps listed some additional processes that the ATT version didn't show - this is not normal. The process tree should be the same. So I download lsof (a powerful Unix utility that didn't ship on many earlier Solaris distributions), and I found some hidden processes that the running ps commands didn't show. Hmmm. This is looking bad. I trace the processes to some hidden files and found that the system was hacked. Not only was the system hacked, it was hacked by two different groups and over a year ago!

The first hackers installed what is known as a root kit. The root kit basically installs hacked versions of many system utility programs to keep system administrators in the dark about the running hacker programs. Basically my clients systems were used as bots to run denial of service attacks against other nodes on the internet. During these attacks, the bandwidth would be consumed and the performance problems would occur. When the system administrators and consultants looked at the problem using the system utilities, they did not see the actual running programs as the root kit hid it from them.

Looking at the security of the system, they were originally breached through an Apache vulnerability. When I suggested they upgrade to a more secure version of Apache, their development team stated that would violate their Oracle support agreement! OMG!!!

Anyway, another group of hackers were also using the systems based on the time stamps I saw on their programs. These guys used a cool tool called stunnel (it was renamed and hidden in this case) which allowed them remote access into there system via IRC servers. I found the embedded irc servers and cryptic login information being used by stunnel. I was curious and logged into the irc server with the login details I uncovered and low and behold, the hacker was online and boy did I catch him off guard. I had enough info on the hacker and gave a lot of forensic data to my FBI contacts and the hacker ended up being prosecuted and convicted and had to pay restitution to my client. Nice ending to a twisted scene.

So the next time you hear you may be having a recurring performance problem, take a deeper look into the situation, you may be surprised what you find out... ;)

-boni bruno

Using Broadcast Data as an Attack Vector...

2007-07-09T22:08:00.000-07:00

It's amazing how much information you can gather from computers via the data they openly broadcast on the network. This article discusses how such information can be used as an attack vector to compromise data security and other informational assets.

First, let me begin with a true story that I was personally involved with. I was working on a new project as a network architect for a large organization that has 18B in assets and listed on the NYSE. This particular organization had a working area for consultants to use, and since I was on-site for several months, I was privy to the other projects and the other consulting companies also working for said organization. As you would expect, SOX compliance is a big deal for organizations that have their stocks traded on the NYSE, and yep, they had one of the big four accounting firms on-site with a audit team that grew to 12 auditors, 2 project managers, and 1 supervisor handling a SOX audit while I was there.

To make a long story short, the consulting area could not accommodate all the consultants so certain liberties were taken. This team of auditors had the audacity to set up their own wireless access point (open - no encryption) without telling the client. They used this AP to extend access to the team so everyone could access my client's network as well as share resources among themselves. I told upper management about this, but to my dismay, no immediate action was taken, apparently the team convinced them it was a necessity and the AP remained on the network - WOW!

Day in day out, the team would come in the morning, turn on their laptops, and proceed with their daily routines. I use various network tools to conduct my work, while using my tools I began to observe various broadcast data coming from the audit team laptops in the consulting area.

First, I saw ARP/DHCP broadcasts which exposed MAC addresses, previously used IP leases, routing information, etc. (There is a handy tool for you Unix/Linux enthusiasts called Passifist available at http://www.cqure.net ) that clearly shows how much one can gather from broadcast traffic.

Anyway, in the mornings, when the audit team came in and booted their laptops, I was able to see the DHCP request of their previous IP addresses - interestingly enough, many of these addresses came from the DHCP servers located in their corporate office. I know this by the IP addresses and NETBIOS information. In this case, some of the team members were last connected to the network back in their corporate office and I was able to learn various IP specifications just by observing their broadcast traffic. Hence, not only did they expose my clients network by installing that damn wireless AP, but the broadcast data clearly exposed information about their corporate network as well. (Mental note here - Broadcast data can tell you about multiple environments you have been connected to.)

Furthermore, NETBIOS/SMB broadcasts disclosed the teams NETBIOS names, login IDs, and various server information they typically used back in there own office. Many people I know consider broadcast traffic as harmless bits and bytes that are just part of normal day to day network communications - you should now be aware that there is more to it than that!

You should also be aware that Startup Applications can also cause additional broadcast information to be sent out on the network. Some of the team members had IM accounts that were broadcasted. I saw VPN related broadcasts, iTunes broadcasts and even virus software broadcast data for signature updates. There is definitely more to broadcast data than many people understand, and this so called audit team was just clueless...

When I turned on my wireless sniffer, I was able to see even more information. I saw all the wireless access points that were cached in the audit teams laptops being broadcasted, including the one the team put up in the consulting area. I couldn't help but imagine computer hackers sitting in airports, hotels, internet cafes collecting this kind of broadcast data.

There are a slew of tools available on the net that can easily take advantage of such broadcast information to the point that traffic can be diverted to spying machines with little effort. If you get the chance, try playing with a little tool called DSNIFF available at http://monkey.org/~dugsong/dsniff/. This tool allows you to redirect traffic to your machine so you can easily inspect data.

Another interesting tool that specifically takes advantage of broadcast data is a tool called Karma available at http://www.theta44.org/karma/index.html. With this tool you can impersonate a wireless AP, DHCP/DNS servers, email and chat servers, etc.

With tools like these available on the net, it should be very clear that broadcast data can be used as an attack vector for hackers, and with the slew of exploits available with Metasploit - see http://framework.metasploit.com/msf/, you simply need to protect yourself and enforce good security practices!

Anyway, getting back to the story, my immediate concern was to shutdown the AP since any nearby resident could hop on the network and see what was going on. Running packet captures gave me visibility into a lot of the data that was being accessed by the audit team. I ran a wireless site survey showing the range of this rogue AP (yeah, it extended to the public streets) and hit management over the head with all of the information I obtained. They finally took down the AP, but only after I had install a new switch with more ports for these clowns in the consulting area! ;)

It still amazes me how many risks you have to manage on a day to day basis and how little senior managers know and understand information security. I hope you enjoyed this article and that your information security awareness has increased as a result of reading this and the associated web links provided.

Stay well and stay secure...

-boni bruno