The Massachusetts Privacy Law (AKA 201 CMR 17.00) is on the horizon with the deadline for compliance is 6 months away. While many states have instituted privacy laws, this one is a game changer and affects companies beyond those geographically located in Massachusetts. Why is that? I'm glad you asked. Here are some things you need to know:
Q: Who does the law apply to?
The law applies to any person or business who owns, licenses, stores or maintains personal information about a resident of the Commonwealth of Massachusetts. Keep in mind, this is not limited to Massachusetts-based companies. Technically, a company based on California that has personal information about a Massachusetts resident must comply.
Q: What is the purpose of the law?
The law establishes minimum standards for safeguarding personal information in both paper and electronic form.
Q: When does the law go into effect?
Organizations must be in full compliance with the law on or before January 1, 2010.
Q: What is “personal information”?
The law defines personal information as a first and last name or a first initial and last name in combination with any of the following:
- Social security number
- Driver’s license number
- State-issued identification card number
- Financial account number
- Credit or debit card number (with our without access code or PIN)
Q: What does this law require?
The law places a number of requirements on every person or organization “covered entities” that owns, licenses, stores or maintains personal information about a resident of the Commonwealth of Massachusetts. To comply with this law, covered entities must:
- Develop, implement, maintain and monitor a comprehensive, written information security program. Such a program must contain administrative, technical and physical safeguards to ensure the confidentiality of personal information.
- Designate one or more employees to maintain the comprehensive information security program.
- Identify and assess foreseeable internal and external risks
- Evaluate and seek to improve the effectiveness of existing safeguards on an ongoing basis including; (1) Performing ongoing employee (including temporary and contract employee) training, (2) Verifying employee compliance and (3) Implementing a means for detecting and preventing security system failures
- Develop security policies
- Impose disciplinary measures for violations of security program rules
- Prevent terminated employees from accessing records containing personal information.
- Take all reasonable steps to verify that any third-party service provider with access to personal information will protect it
- Limit the amount of personal information collection to the greatest extent possible, limiting the time such information is retained and limiting access to that information as possible.
- Identify paper, electronic and other records, computing systems, storage media (incl. laptops and portable devices) used to store personal information.
- Implement restrictions to physical access to personal information records including a written procedure that defines the manner in which physical access is restricted.
- Perform regular monitoring to ensure that the security program is operating in the manner designed.
- Review the scope of security measures at least annually or whenever there is a significant change in business practices.
- Develop an incident response plan.
- Implement reasonably strong user authentication
- Implement access controls to restrict access to personal information
- Encrypt all transmitted records or files containing personal information that will travel across public or wireless networks
- Perform monitoring of systems for unauthorized use of or access to personal information
- Encryption of all personal information stored on laptops or other portable devices
- Provide firewall protection, up-to-date patching and up-to-date anti-malware signatures of all systems containing personal information that are connected to the Internet
- Conduct regular education and training of employees
Q: Wow, that's a long list. Can you summarize all of that?
Sure. Basically organizations need to:
- Perform an assessment to identify internal and external risks.
- Develop a formal, documented information security program based on the results of the risk assessment.
- Document the program via a suite of information security policies.
- Utilized strong authentication methods and strict access controls
- Ensure effective patch and configuration management
- Implement physical access controls
- Incorporate risk assessment into daily operations
- Perform regular internal audits to verify compliance
- Use secure, encrypted communications protocols
- Perform security monitoring and maintain an incident response program
Q: What can be done to comply with this law? What are the next steps?
First, and most importantly, it is critical to perform of an initial compliance/risk assessment. During such a project you would ideally accomplish two simultaneous goals; assess your current security posture to identify any compliance gaps and perform the initial risk assessment dictated by 201 CMR 17.00.
Based on the outcome of the assessment, there are a number of initiatives that will commonly be required:
- Development of information security policies
- Development of an internal audit program
- Performance of periodic security reviews
- Penetration testing & web application security testing
- Development of an incident response plan
- Configuration of technologies to provide encrypted communications protocols
One final thought. Keep in mind that the law specifically states that compliance will factor the size of the business, the resources available, the amount of stored data and the need for confidentiality of both customer and employee information. Because of this, our recommendations to any customer will only be based on the outcome of a risk assessment.
All of that said, if you are a company that "does business" in the Commonwealth of Massachusetts, you should take a hard look at your security posture and your level of compliance with the requirements of this law. Failure to do so could mean failure to comply with the law and that could open you up to legal liability risks, public relations problems and a host of other nastiness that nobody wants.
Thursday, July 9, 2009
Tuesday, July 7, 2009
10 Most Dangerous Infosec Mistakes
I have had the opportunity over the past couple of months to perform security assessments for a bunch of different organizations including hospitals, universities, manufacturing companies and real estate companies. While the results of these assessments are as unique as the companies for which they were performed, I have noticed some common trends. I thought it would be interesting to try to condence them down into a "top 10" list.
1. Ignoring web application security
2. Poor patch management (expecially internal systems and workstations)
3. Lack of a risk basis to security decisions (or making decisions based on fear uncertainty and doubt)
4. Relying solely on the perimeter for protection
5. Ignoring the operational aspects of security (e.g. IDS tuning, maintenance, incident response, etc.)
6. Poor password management (Is 8 characters with an upper, lower, numeric and special char. changed every 90 days really strong?)
7. Ignoring detection - focusing solely on attempts at protection
8. Failing to account for users (who will always find a way to break security)
9. Failing to implement a DMZ, allowing external access directly to the internal network
10. Focusing exclusively on completing regulatory "checkboxes" - compliance does not equal security
As you read this list, ask yourself, is this you? Have you adequately tested the security of your web applications? Have you conducted a web application penetration test that is complete and comprehensive? If not, how do you now your web applications are secure?
What about patch management? Cross site scripting, email-based links and malicious Javascript make your end users direct targets. If an end user workstation gets compromised the attacker can continue their attacks from within your network perimeter. What will they be able to do? Are you expecting your firewall and other perimeter devices to provide protection in this scenario? Is your network resistant to attack from within? Have you implemented proper network segmentation and implemented strong access controls between internal segments?
If an attacker were to get in, are you ready? Do you have sufficient detective capabilities to identify the attack in its early stages or will you wait until a partner, customer or other third party notifies you of the breach? If you notice the attack, do you have a formal, approved incident response plan in place? What are your incident response goals? Do you want to conduct a forensics investigation or simply get the system back up and running? What about notifying law enforcement?
What about regulatory compliance and risk? Does your security plan focus exclusively on meeting regulatory compliance requirements or are you making security decisions based on assessed risk? One way will cost a lot and achieve little with respect to actual risk reduction. The other reduces costs, achieves compliance in the face of a dynamic regulatory landscape and reduces business risk to an acceptable level. Which are you doing.
I have put together a podcast that covers each of the items on this top 10 list so if you are interested, give it a listen. If you want to discuss this in more detail, please reach out to me. Also, don't forget to follow me on twitter - http://www.twitter.com/nwnsecurity - and on facebook (kevinfiscus).
Take care!
Kevin
1. Ignoring web application security
2. Poor patch management (expecially internal systems and workstations)
3. Lack of a risk basis to security decisions (or making decisions based on fear uncertainty and doubt)
4. Relying solely on the perimeter for protection
5. Ignoring the operational aspects of security (e.g. IDS tuning, maintenance, incident response, etc.)
6. Poor password management (Is 8 characters with an upper, lower, numeric and special char. changed every 90 days really strong?)
7. Ignoring detection - focusing solely on attempts at protection
8. Failing to account for users (who will always find a way to break security)
9. Failing to implement a DMZ, allowing external access directly to the internal network
10. Focusing exclusively on completing regulatory "checkboxes" - compliance does not equal security
As you read this list, ask yourself, is this you? Have you adequately tested the security of your web applications? Have you conducted a web application penetration test that is complete and comprehensive? If not, how do you now your web applications are secure?
What about patch management? Cross site scripting, email-based links and malicious Javascript make your end users direct targets. If an end user workstation gets compromised the attacker can continue their attacks from within your network perimeter. What will they be able to do? Are you expecting your firewall and other perimeter devices to provide protection in this scenario? Is your network resistant to attack from within? Have you implemented proper network segmentation and implemented strong access controls between internal segments?
If an attacker were to get in, are you ready? Do you have sufficient detective capabilities to identify the attack in its early stages or will you wait until a partner, customer or other third party notifies you of the breach? If you notice the attack, do you have a formal, approved incident response plan in place? What are your incident response goals? Do you want to conduct a forensics investigation or simply get the system back up and running? What about notifying law enforcement?
What about regulatory compliance and risk? Does your security plan focus exclusively on meeting regulatory compliance requirements or are you making security decisions based on assessed risk? One way will cost a lot and achieve little with respect to actual risk reduction. The other reduces costs, achieves compliance in the face of a dynamic regulatory landscape and reduces business risk to an acceptable level. Which are you doing.
I have put together a podcast that covers each of the items on this top 10 list so if you are interested, give it a listen. If you want to discuss this in more detail, please reach out to me. Also, don't forget to follow me on twitter - http://www.twitter.com/nwnsecurity - and on facebook (kevinfiscus).
Take care!
Kevin
Tuesday, June 30, 2009
Cisco Security Advisories
Wow! Late June saw a lot of action on the Cisco front when it comes to security advisories. Over the course of 3 days, June 24th, 25th and 26th, there were 8 updates. Of these, 2 were new while the other 8 were updates to advisories published on March 25th of this year. The two new advisories were focused on vulnerabilities in Cisco's physcial security technologies.
Cisco Physical Access Gateway
The first is a denial of service vulnerability in the Cisco Physical Access Gateway product. An attacker sending specially crafted packets can create a memory leak. If this happens, connected door hardware (card readers, locks, etc.) may not function causing the door to remain locked or to remain open. Products affected include software versions prior to 1.1. There are no workarounds however free software updates are available. Additional detail about this vulnerability can be found at - http://www.cisco.com/warp/public/707/cisco-sa-20090624-gateway.shtml
As a penetration tester, physical security is paramount and the closer I can get to your critical assets, the better. If I can open your locked doors using some crafted packets, I can access your facility. At a minimum, I can plug in to your network and that's bad. The flip side of this is also bad. If I can cause your doors to lock and stay locked, I can stop security guards from making their rounds and stop people from getting to work. If these locks are used for egress as well as ingress, there may also be life safety issues as well.
Cisco Video Surveillance Stream Manager
The next advisory relates to the Cisco Video Surveillance Stream Manager firmware for the Cisco Video Surveillance Services Platforms and Cisco Video Surveillance Integrated Services Platforms. A crafted packed can cause a reboot of the system. There is also a vulnerability in the Cisco Video Surveillance 2500 Series IP Camera that could allow an authenticated user to view any file on a vulnerable camera. Cisco has released free software to remediate these vulnerabilities. Detailed information can be found at - http://www.cisco.com/warp/public/707/cisco-sa-20090624-video.shtml
If you have deployed these technologies then you must have determined that video surveillance is an important component of your security program. The DoS vulnerability in Cisco Video Surveillance Stream Manager could result in an extended DoS condition which would effectively blind you. The vulnerability in the cameras could allow a non-privileged user to gain privileged access.
Updates
As I stated previously, the remaining issues are updates to previous advisories. They all relate to Cisco IOS and include a vulnerability with Mobile IP and Mobile IPv6, a cTCP DoS vulnerability, a Session Initiation Protocol DoS vulnerability, a crafted UDP packet vulnerability that affects several IOS features, vulnerabilities with WebVPN and SSLVPN, a privilege escalation vulnerability in Cisco IOS secure copy and a crafted TCP packet vulnerability that affects multiple IOS features. Links to additional information have been included below.
http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml
Summary
Now that I've thrown a bunch of information at you, I want to put all of this in terms of risk and risk assessment. When I started writing this post, I had a couple of statements about patching and installing updates along the lines of "Please patch". I pulled them out because I realized that I was going against the normal advise that I give. Should you patch or upgrade your software to fix these problems? The short answer is probably yes but that is not the whole story. Simply deploying each and every patch because the vendor says it is a problem is not risk-based security.
I recommend that you take a look at these vulnerabilities. If you are using this technology and if you are affected by the vulnerabilit you need to ask yourselves "what would the impact be to the business if....". For example, the vulnerability with the Cisco IP Cameras would allow an authenticated but non-privileged user to gain privileged access. Do you have non-priveleged users? If not, does it make sense to install the patch? If you do have non-privileged users, what would happen if they gained priviliged access? What do you believe is the likelihood that that particular vulnerability could be expanded to allow unauthenticated users access?
I understand that this seems more complicated than simply deploying the patch and in some cases, it may be but consider an environment with 500 cameras. How many man hours will be requred to push out the patch to that many cameras? If it will take 1 hour to deploy each patch, that's 500 man-hours. Assuming a simple per man-hour cost of $100, that is a cost to deploy the patch of $50,000. Would the potential impact of the vulnerability cost the orgnization more or less than $50,000. What about other technologies. Deploying a patch on a purpose-built device like a camera may have little down side but what about deploying a similar patch to a critical application or a core operating sytem. Way back when SQL Slammer came out I had a customer who relied on SQL databases. They were unaffected by the worm but the patch caused days of downtime because it broke other applications.
I know I am over simplifying things but the concept is sound. When it comes to security, it is important to understand the potential negative impact to the business, the likelihood of a problem and the costs/risks associated with remediation.
Cisco Physical Access Gateway
The first is a denial of service vulnerability in the Cisco Physical Access Gateway product. An attacker sending specially crafted packets can create a memory leak. If this happens, connected door hardware (card readers, locks, etc.) may not function causing the door to remain locked or to remain open. Products affected include software versions prior to 1.1. There are no workarounds however free software updates are available. Additional detail about this vulnerability can be found at - http://www.cisco.com/warp/public/707/cisco-sa-20090624-gateway.shtml
As a penetration tester, physical security is paramount and the closer I can get to your critical assets, the better. If I can open your locked doors using some crafted packets, I can access your facility. At a minimum, I can plug in to your network and that's bad. The flip side of this is also bad. If I can cause your doors to lock and stay locked, I can stop security guards from making their rounds and stop people from getting to work. If these locks are used for egress as well as ingress, there may also be life safety issues as well.
Cisco Video Surveillance Stream Manager
The next advisory relates to the Cisco Video Surveillance Stream Manager firmware for the Cisco Video Surveillance Services Platforms and Cisco Video Surveillance Integrated Services Platforms. A crafted packed can cause a reboot of the system. There is also a vulnerability in the Cisco Video Surveillance 2500 Series IP Camera that could allow an authenticated user to view any file on a vulnerable camera. Cisco has released free software to remediate these vulnerabilities. Detailed information can be found at - http://www.cisco.com/warp/public/707/cisco-sa-20090624-video.shtml
If you have deployed these technologies then you must have determined that video surveillance is an important component of your security program. The DoS vulnerability in Cisco Video Surveillance Stream Manager could result in an extended DoS condition which would effectively blind you. The vulnerability in the cameras could allow a non-privileged user to gain privileged access.
Updates
As I stated previously, the remaining issues are updates to previous advisories. They all relate to Cisco IOS and include a vulnerability with Mobile IP and Mobile IPv6, a cTCP DoS vulnerability, a Session Initiation Protocol DoS vulnerability, a crafted UDP packet vulnerability that affects several IOS features, vulnerabilities with WebVPN and SSLVPN, a privilege escalation vulnerability in Cisco IOS secure copy and a crafted TCP packet vulnerability that affects multiple IOS features. Links to additional information have been included below.
http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml
Summary
Now that I've thrown a bunch of information at you, I want to put all of this in terms of risk and risk assessment. When I started writing this post, I had a couple of statements about patching and installing updates along the lines of "Please patch". I pulled them out because I realized that I was going against the normal advise that I give. Should you patch or upgrade your software to fix these problems? The short answer is probably yes but that is not the whole story. Simply deploying each and every patch because the vendor says it is a problem is not risk-based security.
I recommend that you take a look at these vulnerabilities. If you are using this technology and if you are affected by the vulnerabilit you need to ask yourselves "what would the impact be to the business if....". For example, the vulnerability with the Cisco IP Cameras would allow an authenticated but non-privileged user to gain privileged access. Do you have non-priveleged users? If not, does it make sense to install the patch? If you do have non-privileged users, what would happen if they gained priviliged access? What do you believe is the likelihood that that particular vulnerability could be expanded to allow unauthenticated users access?
I understand that this seems more complicated than simply deploying the patch and in some cases, it may be but consider an environment with 500 cameras. How many man hours will be requred to push out the patch to that many cameras? If it will take 1 hour to deploy each patch, that's 500 man-hours. Assuming a simple per man-hour cost of $100, that is a cost to deploy the patch of $50,000. Would the potential impact of the vulnerability cost the orgnization more or less than $50,000. What about other technologies. Deploying a patch on a purpose-built device like a camera may have little down side but what about deploying a similar patch to a critical application or a core operating sytem. Way back when SQL Slammer came out I had a customer who relied on SQL databases. They were unaffected by the worm but the patch caused days of downtime because it broke other applications.
I know I am over simplifying things but the concept is sound. When it comes to security, it is important to understand the potential negative impact to the business, the likelihood of a problem and the costs/risks associated with remediation.
Monday, June 15, 2009
Netgear Vulnerability - Disclosure Notification
Today the members of the Bugtraq mailing list received a notification about an email in a Netgear DG623 router. The text of this email reads as follows:
Product Name: Netgear DG632 Router
Vendor: http://www.netgear.com
Date: 15 June, 2009
Author: tom@tomneaves.co.uk
Original URL: http://www.tomneaves.co.uk/Netgear_DG632_Remote_DoS.txt
Discovered: 18 November, 2006
Disclosed: 15 June, 2009
I. DESCRIPTION
The Netgear DG632 router has a web interface which runs on port 80. This allows an admin to login and administer the device's settings. However, a Denial of Service (DoS) vulnerability exists that causes the web interface
to crash and stop responding to further requests.
II. DETAILS
Within the "/cgi-bin/" directory of the administrative web interface exists a file called "firmwarecfg". This file is used for firmware upgrades. A HTTP POST request for this file causes the web server to hang. The web server will stop responding to requests and the administrative interface will become inaccessible until the router is physically restarted.
While the router will still continue to function at the network level, i.e. it will still respond to ICMP echo requests and issue leases via DHCP, an administrator will no longer be able to interact with the administrative web interface.
This attack can be carried out internally within the network, or over the Internet if the administrator has enabled the "Remote Management" feature on the router.
Affected Versions: Firmware V3.4.0_ap (others unknown)
III. VENDOR RESPONSE
12 June, 2009 - Contacted vendor.
15 June, 2009 - Vendor responded. Stated the DG632 is an end of life product and is no longer supported in a production and development sense, as such, there will be no further firmware releases to resolve this issue.
IV. CREDIT
Discovered by Tom Neaves
This posting elicits so may comments that I don't really know where to start so I've tried to break things down a bit to make the discussion easier to follow.
Vulnerability Severity
First I'd like to address the perceived severity of this vulnerability. It is a denial of service attack against a platform that is most commonly used in the home or SOHO environments. This combination means that most mid sized or larger organizations will likely pay little attention to it. This is a mistake for a few reasons. First, and speaking to small, medium and large organizaiton, you may not used SOHO devices but your users do and they, in turn, connect to your network. This may be via VPN (through the SOHO router), directly using various protocols, or simply by bringing ther laptop from their vulnerable home environment to your "protected" work environment. In short, problems with these devices affect you directly.
Now you may say that this is "just" a DoS problem and isn't going to have an effect. At a minimum, it can effect the productivity of your users. Let's consider an extremely situation - you have a user who is working on a proposal that needs to be turned in on a specific date and time. If their router gets nailed it may delay the proposal causing you to lose the business. From a more day-to-day perspective, many organizations allow teleworking. If they cannot connect to the business network, their productivity will be impacted costing your organization money. If your corporate network, or even a single switch on that network, went down, you'd ensure the problem was addressed ASAP. From the perspective of a teleworker, a DoS attack against their SOHO router are exactly the same as the loss of a corporate switch.
Finally, DoS attacks have a way of turning into other types of attacks - possibly allowing the attacker to gain control over the SOHO router. if that happens, it results in a whole new set of problems for business with users who rely on these systems.
Vulnerability Disclosure
OK, now that we've covered the fact that we should care about this kind of problem, I want to talk a bit about vulnerability disclosure. In this case, that problem was identified in November of 2006 and was posted on Bugtraq on June 15th of 2009 - 2 years and 7 months later. This means that people have been using vulnerable equipment for all that time without knowing it or having any ability to do something about it. That, to me, is a problem. Even now, becuse the product is "end of life" there is not patch available but purchasing a new box - again, a scary situation.
I don't want to come across as an alarmist. The issues affecting this particular device are unlikely to represent a significant security risk to any organization but this problem of vulnerability disclosure is multiplied throughout the industry on virtually every singel technology in existence making it a situation that is relevant to everyone. Now comes the point where I outline a bunch of questions with few answers:
Security researches spend time "hacking" technology. By hacking, I'm referring to the term in the original context, not the media driven "attacker" definition. These researches hack technology for a variety of reasons. It may be part of an authorized penetration test or they may work for a company with a vested interest in vulnerability identification (e.g. a security product vendor, etc.). Often, they just do it for fun. In any case, they discover a vulnerability. This leads them to the first question. Do they notify the vendor, disclose the problem to the public, sell it to the highest bidder......?
If they notify the vendor, they may get a positive response. They may also get brushed off and ignored. They may get critisized or, in rare situations, they may be the target of legal actions or "illegal reverse engineering" or similar "crime". In any of these cases, vendor notification resulting in positive, short term actions by the vendor are not the majority leaving the users of the technoloy vulnerable and ignorant.
If they decide to publish the problem on the Internet making it available to the public the will likely be contacted by the vendor, and/or the vendor's lawyers. The public may be able to, if they are made aware of the problem, implement some controls to reduce their risk level but the security researcher is also putting their discovery in the hands of the bad guys also. In effect, they take off the white hat and put on the grey one.
There are also organizaitons out there who will buy vulnerabilities. This puts some money in the pockets of the reseachers but comes really close to "black hat" work.
This is a bit of a sticky situation and gets more so when you look at the concept of pay. Many vulnerability researchers are either independent consultants or do this type of work as a hobby in addition to their normal 9-to-5. They spend countless hours performing quality analysis for some vendor for free. When they do identify something and turn it in to the vendor, the vendor in turn has the opportunity to make their product better. Shouldn't the researches receive some compensation for the QA work that should have been done by the vendor in the first place? Like I said, this is a sticky subject.
Attack Vectors
The last thing I want to talk about is the way this vulnerability can be attacked. According to the article - "This attack can be carried out internally within the network, or over the Internet if the administrator has enabled the "Remote Management" feature on the router." This seems to imply that if "Remote Management" has not been enabled, this attack is not exploitable from the Internet. While I haven't tested it, I would suspect that Cross-site scripting (XSS) and Cross-site request forgery (CSRF) attacks may also be used to attack the system even of the direct external access is not possible.
Product Name: Netgear DG632 Router
Vendor: http://www.netgear.com
Date: 15 June, 2009
Author: tom@tomneaves.co.uk
Original URL: http://www.tomneaves.co.uk/Netgear_DG632_Remote_DoS.txt
Discovered: 18 November, 2006
Disclosed: 15 June, 2009
I. DESCRIPTION
The Netgear DG632 router has a web interface which runs on port 80. This allows an admin to login and administer the device's settings. However, a Denial of Service (DoS) vulnerability exists that causes the web interface
to crash and stop responding to further requests.
II. DETAILS
Within the "/cgi-bin/" directory of the administrative web interface exists a file called "firmwarecfg". This file is used for firmware upgrades. A HTTP POST request for this file causes the web server to hang. The web server will stop responding to requests and the administrative interface will become inaccessible until the router is physically restarted.
While the router will still continue to function at the network level, i.e. it will still respond to ICMP echo requests and issue leases via DHCP, an administrator will no longer be able to interact with the administrative web interface.
This attack can be carried out internally within the network, or over the Internet if the administrator has enabled the "Remote Management" feature on the router.
Affected Versions: Firmware V3.4.0_ap (others unknown)
III. VENDOR RESPONSE
12 June, 2009 - Contacted vendor.
15 June, 2009 - Vendor responded. Stated the DG632 is an end of life product and is no longer supported in a production and development sense, as such, there will be no further firmware releases to resolve this issue.
IV. CREDIT
Discovered by Tom Neaves
This posting elicits so may comments that I don't really know where to start so I've tried to break things down a bit to make the discussion easier to follow.
Vulnerability Severity
First I'd like to address the perceived severity of this vulnerability. It is a denial of service attack against a platform that is most commonly used in the home or SOHO environments. This combination means that most mid sized or larger organizations will likely pay little attention to it. This is a mistake for a few reasons. First, and speaking to small, medium and large organizaiton, you may not used SOHO devices but your users do and they, in turn, connect to your network. This may be via VPN (through the SOHO router), directly using various protocols, or simply by bringing ther laptop from their vulnerable home environment to your "protected" work environment. In short, problems with these devices affect you directly.
Now you may say that this is "just" a DoS problem and isn't going to have an effect. At a minimum, it can effect the productivity of your users. Let's consider an extremely situation - you have a user who is working on a proposal that needs to be turned in on a specific date and time. If their router gets nailed it may delay the proposal causing you to lose the business. From a more day-to-day perspective, many organizations allow teleworking. If they cannot connect to the business network, their productivity will be impacted costing your organization money. If your corporate network, or even a single switch on that network, went down, you'd ensure the problem was addressed ASAP. From the perspective of a teleworker, a DoS attack against their SOHO router are exactly the same as the loss of a corporate switch.
Finally, DoS attacks have a way of turning into other types of attacks - possibly allowing the attacker to gain control over the SOHO router. if that happens, it results in a whole new set of problems for business with users who rely on these systems.
Vulnerability Disclosure
OK, now that we've covered the fact that we should care about this kind of problem, I want to talk a bit about vulnerability disclosure. In this case, that problem was identified in November of 2006 and was posted on Bugtraq on June 15th of 2009 - 2 years and 7 months later. This means that people have been using vulnerable equipment for all that time without knowing it or having any ability to do something about it. That, to me, is a problem. Even now, becuse the product is "end of life" there is not patch available but purchasing a new box - again, a scary situation.
I don't want to come across as an alarmist. The issues affecting this particular device are unlikely to represent a significant security risk to any organization but this problem of vulnerability disclosure is multiplied throughout the industry on virtually every singel technology in existence making it a situation that is relevant to everyone. Now comes the point where I outline a bunch of questions with few answers:
Security researches spend time "hacking" technology. By hacking, I'm referring to the term in the original context, not the media driven "attacker" definition. These researches hack technology for a variety of reasons. It may be part of an authorized penetration test or they may work for a company with a vested interest in vulnerability identification (e.g. a security product vendor, etc.). Often, they just do it for fun. In any case, they discover a vulnerability. This leads them to the first question. Do they notify the vendor, disclose the problem to the public, sell it to the highest bidder......?
If they notify the vendor, they may get a positive response. They may also get brushed off and ignored. They may get critisized or, in rare situations, they may be the target of legal actions or "illegal reverse engineering" or similar "crime". In any of these cases, vendor notification resulting in positive, short term actions by the vendor are not the majority leaving the users of the technoloy vulnerable and ignorant.
If they decide to publish the problem on the Internet making it available to the public the will likely be contacted by the vendor, and/or the vendor's lawyers. The public may be able to, if they are made aware of the problem, implement some controls to reduce their risk level but the security researcher is also putting their discovery in the hands of the bad guys also. In effect, they take off the white hat and put on the grey one.
There are also organizaitons out there who will buy vulnerabilities. This puts some money in the pockets of the reseachers but comes really close to "black hat" work.
This is a bit of a sticky situation and gets more so when you look at the concept of pay. Many vulnerability researchers are either independent consultants or do this type of work as a hobby in addition to their normal 9-to-5. They spend countless hours performing quality analysis for some vendor for free. When they do identify something and turn it in to the vendor, the vendor in turn has the opportunity to make their product better. Shouldn't the researches receive some compensation for the QA work that should have been done by the vendor in the first place? Like I said, this is a sticky subject.
Attack Vectors
The last thing I want to talk about is the way this vulnerability can be attacked. According to the article - "This attack can be carried out internally within the network, or over the Internet if the administrator has enabled the "Remote Management" feature on the router." This seems to imply that if "Remote Management" has not been enabled, this attack is not exploitable from the Internet. While I haven't tested it, I would suspect that Cross-site scripting (XSS) and Cross-site request forgery (CSRF) attacks may also be used to attack the system even of the direct external access is not possible.
Tuesday, June 9, 2009
New Podcast
I have just taken my first step into podcasting. In this case, I recorded a discussion about the 10 most dangerous security mistakes I see organizations making when I conduct security assessments. Unfortunately, these mistakes occur far too often and make real security exceptionally difficult. I'll apologize in advance for the quality of the audio editing. I'll get better. I promise.
Wednesday, June 3, 2009
Cyber Security Czar
The White House continues to talk about creating a cyber security coordinator or cyber security czar. Comments from the administration talk about the threat of cyber attacks on our critical infrastructure and of cyber terrorism. My first response - FINALLY! Finally someone is taking the threat seriously. That said, I do not understand what a cyber security czar would actually do.
Many of the articles I have read on the subject talk about the administration's "plan to keep government and commercial information on the Internet safe from cyber criminals or terrorists." They talk about forming partnerships with state and local governments as well as with the private sector and about focusing on training and education. These are all good things but they won't really help make things more secure.
The only way for the federal government to make things more secure is to pass laws or set policy that everyone must comply with. Education won't do it because there are too many organizations that, as a result of ignorance, incompetence or arrogance, won't do the right things. That's why the government has put in place regulations like HIPAA, 21 CFR Part 11, GLBA and Sarbanes-Oxley. That's why the credit card companies put in place PCI DSS. The problem is that these measures just don't work. The minute you think you have created a checklist of minimum mandatory requirements, you have really created the only list of requirements that many organizations will follow. You have also given the bad guys a template of what your securty will look like. In effect, you have made security weaker.
Federal regulations and PCI have taken the wrong approach when it comes to cyber security. This is because they are trying to define the controls that need to be put in place. Unfortunately, information technology is too complex, companies are too diverse and the threat landscape is too dynamic for that to work. The minute you define a control requirement, bad guys find a way around it. The regulations then have to change but that process takes much too much time. Control focused regulatory requirements also create the impression that compliance equals security. That is simply not the case.
So, if the current regulatory requirements are the wrong approach, what is the right one? I'm glad you asked. The short answer is - responsibility. Organizations should be held responsible for the results of their security mesures, not on the measures themselves. If an organization has really bad security but never suffers a breach or compromise, is there a problem? If an organziation is 100% compliant with all regulations but they suffer a compromise that discloses credit card numbers and results in identity theft for thousands did being compliant help? The answers to these questions should be self evident. Unfortunatley, our current regulatory climate would praise the second organization while punishing the first. My thoughts are simple. Hold organizations accountable for effectively securing sensitive data - or more specifically, data that if modified, altered or destroyed, would negatively affect others. Many of the various state privacy laws to this. Let organziations secure their environments as the see fit but hold them accountable for failure. It doesn't take a cyber security czar or a Cybersecurity Act of 2009 to do this. It take a couple of things. First, it requires a national description of what "sensitive" data is. This list doesn't need to be that large but would include personal information that could be used for identity theft, personal medical records, personal financial records (including credit card data), classified government information and the like. Once this definition has been established, two things need to happen; a law needs to be passed that would result in penalties should these data be disclosed and a law needs to be passed (perhaps an expansion of the Computer Fraud and Abuse Act) that makes it a crime to access these data without authorization.
What would the effect of this be? Of course I don't know for sure but here's my guess. Nothing would happen initially until the first few public cases of fines or other penalties levied against organizations who let their sensitive data be compromised were on the nightly news. This would serve as a wake up call (hopefully) making organizations approach security as a matter of risk management rather than as a checkbox that needs to be checked. Would it work? I don't know but I believe it would be better than what is happening today.
Many of the articles I have read on the subject talk about the administration's "plan to keep government and commercial information on the Internet safe from cyber criminals or terrorists." They talk about forming partnerships with state and local governments as well as with the private sector and about focusing on training and education. These are all good things but they won't really help make things more secure.
The only way for the federal government to make things more secure is to pass laws or set policy that everyone must comply with. Education won't do it because there are too many organizations that, as a result of ignorance, incompetence or arrogance, won't do the right things. That's why the government has put in place regulations like HIPAA, 21 CFR Part 11, GLBA and Sarbanes-Oxley. That's why the credit card companies put in place PCI DSS. The problem is that these measures just don't work. The minute you think you have created a checklist of minimum mandatory requirements, you have really created the only list of requirements that many organizations will follow. You have also given the bad guys a template of what your securty will look like. In effect, you have made security weaker.
Federal regulations and PCI have taken the wrong approach when it comes to cyber security. This is because they are trying to define the controls that need to be put in place. Unfortunately, information technology is too complex, companies are too diverse and the threat landscape is too dynamic for that to work. The minute you define a control requirement, bad guys find a way around it. The regulations then have to change but that process takes much too much time. Control focused regulatory requirements also create the impression that compliance equals security. That is simply not the case.
So, if the current regulatory requirements are the wrong approach, what is the right one? I'm glad you asked. The short answer is - responsibility. Organizations should be held responsible for the results of their security mesures, not on the measures themselves. If an organization has really bad security but never suffers a breach or compromise, is there a problem? If an organziation is 100% compliant with all regulations but they suffer a compromise that discloses credit card numbers and results in identity theft for thousands did being compliant help? The answers to these questions should be self evident. Unfortunatley, our current regulatory climate would praise the second organization while punishing the first. My thoughts are simple. Hold organizations accountable for effectively securing sensitive data - or more specifically, data that if modified, altered or destroyed, would negatively affect others. Many of the various state privacy laws to this. Let organziations secure their environments as the see fit but hold them accountable for failure. It doesn't take a cyber security czar or a Cybersecurity Act of 2009 to do this. It take a couple of things. First, it requires a national description of what "sensitive" data is. This list doesn't need to be that large but would include personal information that could be used for identity theft, personal medical records, personal financial records (including credit card data), classified government information and the like. Once this definition has been established, two things need to happen; a law needs to be passed that would result in penalties should these data be disclosed and a law needs to be passed (perhaps an expansion of the Computer Fraud and Abuse Act) that makes it a crime to access these data without authorization.
What would the effect of this be? Of course I don't know for sure but here's my guess. Nothing would happen initially until the first few public cases of fines or other penalties levied against organizations who let their sensitive data be compromised were on the nightly news. This would serve as a wake up call (hopefully) making organizations approach security as a matter of risk management rather than as a checkbox that needs to be checked. Would it work? I don't know but I believe it would be better than what is happening today.
Tuesday, April 28, 2009
Cyber Security Kill Switch Bill
On April 1st, Sen. John D. Rockefeller IV (D-W.Va.) and Sen. Olympia Snowe (R-Me.) introduced Senate Bill 773, also known as the Cybersecurty Act of 2009. This bill seeks to provide increased protections to United States critical infrastructure from the threat of a cyber attack. In the abstract, I think that is a good idea. The specific implementation of this bill however, has some problems. I won't go through the entire bill but I'll provide some highlights.
This bill calls for a Cybersecurity Advisory Panel that will be created by the President to track the state of security of critical infrastructure. The panel will report to Congress "not less frequently than once every two years".
The bill calls for the creation of a cybersecurity dashboard that can track the state of security of all critical infrastructure assets in real time.
It calls for the creation of regional cybersecurity centers who will "transfer" standards to the private sector with a focus on small to mid-sized businesses. These regional centers will also have funding to make loans to small businesses to promote enhanced security.
The bill tasks NIST with the task of creating much more robust standards including standards for secure coding and software configuration.
It also calls for the implementation of a "secure" DNS solution.
The bill will also make it illegal for "any individual to
engage in business in the United States, or to be employed in the United States, as a provider of cybersecurity services to any Federal agency or an information system or network designated by the President, or the President's designee, as a critical infrastructure information system or network, who is not licensed and certified under the program."
The bill establishes the "Department of Commerce as the clearinghouse of cybersecurity threat and vulnerability information to Federal Government and private sector owned critical infrastructure information systems and networks." In this role, the Dept. of Commerce "shall have access to all relevant data concerning such networks without regard to any provision of law, regulation, rule, or policy restricting such access".
The bill requires that "within 1 year after the date of enactment of this Act, the President, or the President's designee, shall review, and report to Congress,
on the feasibility of an identity management and authentication program, with the appropriate civil liberties and privacy protections, for government and critical infrastructure information systems and networks."
The bill gives the President the authority to "declare a cybersecurity emergency and order the limitation or shutdown of Internet traffic to and from any compromised
Federal Government or United States critical infrastructure information system or network" and to "order the disconnection of any Federal Government or United States critical infrastructure information systems or networks in the interest of national security"
You will note that throughout these summary points, the phrase "critical infrastructure" is stated frequently. Whether any specific organization or network is "critical infrastructure" will determine if it falls under the purview of this bill. According to the bill, the President will determine what makes up "critical infrastructure".
I'm going to avoid any purely political analysis of this bill. Whether you think the federal government should be responsible for cybersecurity of private industry is for you to decide. I want to comment on whether this bill will achieve the desired objectives of making our critical infrastructure more secure. In short, I believe that not only will our critical infrastructure not be more secure, it will in fact become less so.
I have done a lot of work with regulated companies; health care, pharma, financial, retail, etc. While the regulations covering them are different, I have seen one common factor - something I call the checklist syndrome. When organizations are forced to comply with a security regulation, they start by developing a checklist of what is required. They then audit themselves to determine where their gaps are. Finally, they work to fill the gaps and believe themselves secure. In taking this approach, I have seen more than one organization intentionally ignore a good security measure because it was not required for compliance. I have seen companies re-word strong policies so they will only apply to the subset of their systems required for compliance. Guess what?!?!? The attackers also have access to the compliance standards. Setting up a security program that is precisely and only what is required for compliance is giving the attackers a picture of your strengths and weaknesses.
Imagine if we were required by law to secure our homes. The law states that we must lock all doors and windows when we are away. It also requires that sensors be installed on all ground floor doors and windows to detect unauthorized access. It also requires that motion sensors be installed on the ground floor. In theory, homes adhering to these standards would be more secure but let's now assume that people forced to comply with this do so by adhering to the principles of checklist syndrome. They do exactly what is listed in the law and consider themselves secure. Attackers, knowing this, take advantage of the lack of exterior lighting (not required by the law) to provide cover as they climb to the second story, break a window and steal what they can find. Because they never go to the first floor, they never trip the sensors but the victims are still victims. I understand that my example is overly simplistic but Hannaford Supermarkets was "PCI DSS compliant" up until they suffered a massive compromise.
Aside from the checklist syndrome problems, there are a number of other problems I see with this bill.
The Cybersecurity Advisory Panel is only required to report every two years. How much changes in the world of information security in two years. The state of cybersecurity could go from "outstanding" to "epic fail" in two days under the right circumstances, let alone two years.
Requiring cypersecurity professionals to be licensed and certified sounds nice but has some dramatic potential impacts. Who will create the certification and licensing process and how much will it cost? If infosec people need to invest time and money into this licensing/certification, what will that do to all of the existing certification organizations (e.g. SANS, (ISC)2, ISACA, etc.? As these licensing requirements get put in place, those who are licensed will become more valuable and thus will demand higher pay. Many organizations already struggle trying to maintain infosec expertise on staff. This may make it far more difficult. What about consulting firms who do security related but not security specific work? Is deploying Active Directory or a Cisco router security work? What about a firewall? Will the folks that do this type of work also need to be cybersecurity certified.
I'm entirely in favor of better security but I'm not sure this is the way to go about it. If it were up to me and I was inclined to draft legislation about cybersecurity, I think I might keep it far more simple:
1) Thou shalt incorporate risk assessment into strategic and operational business decisions.
2) Thou shalt make security decisions based on assessed risk such that (a)unacceptable risk shall be mitigated and (b)acceptable risk shall be documented.
3) Thou shalt establish proper standards for security; the standards shall be implemented based on assessed risk and thou shalt regularly audit for compliance with established standards.
4) Thou shalt establish roles and responsibilities for promoting security and one such roll shall be responsible for maintaining a current understanding of security threats, techniques, technologies and trends.
5) Security shall be prioritized equally with performance and functionality and a lack of any of these shall not be accepted.
6) Failing to implement reasonable controls to protect against commonly understood threats is negligence.
7) Security is not a technology issue; rather it is a business issues that involves technology, people, policy and process. Similarly, technology does not provide the full security solution.
8) Computing hardware and software is extremely complex and will have vulnerabilities. Expect them and build security around that fact.
9) Security is not about protection only; rather it involves protection, detection, response and recovery; the ratios of which are determined by by assessing risk.
10) Security can never be 100% effective as long as people are involved.
Another approach would be to make getting compromised illegal. Perhaps that would get organizations to pay security proper attention. (wink, wink, nudge, nudge)
This bill calls for a Cybersecurity Advisory Panel that will be created by the President to track the state of security of critical infrastructure. The panel will report to Congress "not less frequently than once every two years".
The bill calls for the creation of a cybersecurity dashboard that can track the state of security of all critical infrastructure assets in real time.
It calls for the creation of regional cybersecurity centers who will "transfer" standards to the private sector with a focus on small to mid-sized businesses. These regional centers will also have funding to make loans to small businesses to promote enhanced security.
The bill tasks NIST with the task of creating much more robust standards including standards for secure coding and software configuration.
It also calls for the implementation of a "secure" DNS solution.
The bill will also make it illegal for "any individual to
engage in business in the United States, or to be employed in the United States, as a provider of cybersecurity services to any Federal agency or an information system or network designated by the President, or the President's designee, as a critical infrastructure information system or network, who is not licensed and certified under the program."
The bill establishes the "Department of Commerce as the clearinghouse of cybersecurity threat and vulnerability information to Federal Government and private sector owned critical infrastructure information systems and networks." In this role, the Dept. of Commerce "shall have access to all relevant data concerning such networks without regard to any provision of law, regulation, rule, or policy restricting such access".
The bill requires that "within 1 year after the date of enactment of this Act, the President, or the President's designee, shall review, and report to Congress,
on the feasibility of an identity management and authentication program, with the appropriate civil liberties and privacy protections, for government and critical infrastructure information systems and networks."
The bill gives the President the authority to "declare a cybersecurity emergency and order the limitation or shutdown of Internet traffic to and from any compromised
Federal Government or United States critical infrastructure information system or network" and to "order the disconnection of any Federal Government or United States critical infrastructure information systems or networks in the interest of national security"
You will note that throughout these summary points, the phrase "critical infrastructure" is stated frequently. Whether any specific organization or network is "critical infrastructure" will determine if it falls under the purview of this bill. According to the bill, the President will determine what makes up "critical infrastructure".
I'm going to avoid any purely political analysis of this bill. Whether you think the federal government should be responsible for cybersecurity of private industry is for you to decide. I want to comment on whether this bill will achieve the desired objectives of making our critical infrastructure more secure. In short, I believe that not only will our critical infrastructure not be more secure, it will in fact become less so.
I have done a lot of work with regulated companies; health care, pharma, financial, retail, etc. While the regulations covering them are different, I have seen one common factor - something I call the checklist syndrome. When organizations are forced to comply with a security regulation, they start by developing a checklist of what is required. They then audit themselves to determine where their gaps are. Finally, they work to fill the gaps and believe themselves secure. In taking this approach, I have seen more than one organization intentionally ignore a good security measure because it was not required for compliance. I have seen companies re-word strong policies so they will only apply to the subset of their systems required for compliance. Guess what?!?!? The attackers also have access to the compliance standards. Setting up a security program that is precisely and only what is required for compliance is giving the attackers a picture of your strengths and weaknesses.
Imagine if we were required by law to secure our homes. The law states that we must lock all doors and windows when we are away. It also requires that sensors be installed on all ground floor doors and windows to detect unauthorized access. It also requires that motion sensors be installed on the ground floor. In theory, homes adhering to these standards would be more secure but let's now assume that people forced to comply with this do so by adhering to the principles of checklist syndrome. They do exactly what is listed in the law and consider themselves secure. Attackers, knowing this, take advantage of the lack of exterior lighting (not required by the law) to provide cover as they climb to the second story, break a window and steal what they can find. Because they never go to the first floor, they never trip the sensors but the victims are still victims. I understand that my example is overly simplistic but Hannaford Supermarkets was "PCI DSS compliant" up until they suffered a massive compromise.
Aside from the checklist syndrome problems, there are a number of other problems I see with this bill.
The Cybersecurity Advisory Panel is only required to report every two years. How much changes in the world of information security in two years. The state of cybersecurity could go from "outstanding" to "epic fail" in two days under the right circumstances, let alone two years.
Requiring cypersecurity professionals to be licensed and certified sounds nice but has some dramatic potential impacts. Who will create the certification and licensing process and how much will it cost? If infosec people need to invest time and money into this licensing/certification, what will that do to all of the existing certification organizations (e.g. SANS, (ISC)2, ISACA, etc.? As these licensing requirements get put in place, those who are licensed will become more valuable and thus will demand higher pay. Many organizations already struggle trying to maintain infosec expertise on staff. This may make it far more difficult. What about consulting firms who do security related but not security specific work? Is deploying Active Directory or a Cisco router security work? What about a firewall? Will the folks that do this type of work also need to be cybersecurity certified.
I'm entirely in favor of better security but I'm not sure this is the way to go about it. If it were up to me and I was inclined to draft legislation about cybersecurity, I think I might keep it far more simple:
1) Thou shalt incorporate risk assessment into strategic and operational business decisions.
2) Thou shalt make security decisions based on assessed risk such that (a)unacceptable risk shall be mitigated and (b)acceptable risk shall be documented.
3) Thou shalt establish proper standards for security; the standards shall be implemented based on assessed risk and thou shalt regularly audit for compliance with established standards.
4) Thou shalt establish roles and responsibilities for promoting security and one such roll shall be responsible for maintaining a current understanding of security threats, techniques, technologies and trends.
5) Security shall be prioritized equally with performance and functionality and a lack of any of these shall not be accepted.
6) Failing to implement reasonable controls to protect against commonly understood threats is negligence.
7) Security is not a technology issue; rather it is a business issues that involves technology, people, policy and process. Similarly, technology does not provide the full security solution.
8) Computing hardware and software is extremely complex and will have vulnerabilities. Expect them and build security around that fact.
9) Security is not about protection only; rather it involves protection, detection, response and recovery; the ratios of which are determined by by assessing risk.
10) Security can never be 100% effective as long as people are involved.
Another approach would be to make getting compromised illegal. Perhaps that would get organizations to pay security proper attention. (wink, wink, nudge, nudge)
Subscribe to:
Posts (Atom)
Posts
