As part of our technology share program SLC Security Services LLC will be releasing intelligence information formatted for users of Tableau Desktop or Public software so you can perform your own network analysis. The information being provided will be for a 30 day period and will include several of our feeds so you can run comparisons against your own network traffic.
Some of our clients have begun running the data against firewall and server logs to identify compromised machines and host so this may be valuable to you to determine if you should hire a third party to perform a network or security analysis of your data.
The tableau data will be released to the public area of the Tableau Server and will be available to the public. The time periods of the data will be from 15 Nov - 15 Dec 2014. The purpose of the release is so you can evaluate some of the same data that we utilize in our security appliances to determine if the devices are a good fit for your organization. If you come up with other use cases please let us know. We would love to work with some new faces in 2015 and we will do profit sharing on any use case that is adopted into our commercial gateway appliance.
The SLC Secure Gateway is an appliance that acts as a firewall and gateway on networks and also collects information from workstations to include MD5 list of files, network traffic data and action logs to match indicators of compromise with known virus, malware and network security threats.
The purpose of this page is to provide awareness to individuals and organizations that are leaking information and the information of their customers. The entities listed on this site are verified to be leaking personal information sometimes without the company even being aware. SLC Security is now owned and operated by Jigsaw Security Enterprise. We are currently in process and as such this blog will eventually be taken offline and merged with Jigsaw Security resources.
Showing posts with label Technology Share Program. Show all posts
Showing posts with label Technology Share Program. Show all posts
Tuesday, December 23, 2014
Covert Listening Threats even worse than recent hacking attempts
Over the past few weeks we have been researching data from various audits on the east coast. We are noting a large increase in the identification, location and disabling of covert listening devices. In the month of November alone we have discovered 14 separate listening devices at 7 different companies. One thing we also have noticed are some similarities between the various devices that have been located.
1. In several of the cases there were multiple listening devices in the same area. We believe this is being done so that if the primary is found the backup may continue to provide useful information to the attackers.
2. Fax machines are being heavily targeted at many businesses. We have been able to locate stolen documents in 4 of the cases out of the 14 being researched.
3. Ultrasonic devices are being used to avoid detection.
4. Networks are also being attacked with malware reporting back to 194.165.134.66. These IP's are also attempting to attack SMTP servers to verify accounts at these same organizations. This was determined through log file analysis.
5. 1 of the 14 companies is a major US Military Contractor.
These are the finding for November. We are still seeing covert listening devices in December and the numbers this month even with the holiday breaks are much higher than November so we are alerting companies to look for traffic to this host and call us if you have identified any. We would like to look for accompanying planted devices to see if this pattern remains. Only 1 of the 14 entities was not bugged or we did not locate any devices during the sweep.
SLC Security customers please read bulletin 2014-141 for additional information on the network IOC's and signal identification notations for these 14 locations.
1. In several of the cases there were multiple listening devices in the same area. We believe this is being done so that if the primary is found the backup may continue to provide useful information to the attackers.
2. Fax machines are being heavily targeted at many businesses. We have been able to locate stolen documents in 4 of the cases out of the 14 being researched.
3. Ultrasonic devices are being used to avoid detection.
4. Networks are also being attacked with malware reporting back to 194.165.134.66. These IP's are also attempting to attack SMTP servers to verify accounts at these same organizations. This was determined through log file analysis.
5. 1 of the 14 companies is a major US Military Contractor.
These are the finding for November. We are still seeing covert listening devices in December and the numbers this month even with the holiday breaks are much higher than November so we are alerting companies to look for traffic to this host and call us if you have identified any. We would like to look for accompanying planted devices to see if this pattern remains. Only 1 of the 14 entities was not bugged or we did not locate any devices during the sweep.
SLC Security customers please read bulletin 2014-141 for additional information on the network IOC's and signal identification notations for these 14 locations.
Copycat Hacks Becoming Commonplace
While Government experts have pointed the finger at North Korea in the recent attack of SONY. We are still not convinced. The reason we are not convinced lies in the OSINT-X data we have archived and analyzed, the malware used in the attack and the similarities of an earlier attack on South Korean banks. One thing is for sure that the Government is not an OSINT-X customer at this time although we have had contact and interest in the product for other uses within the DOD. The FBI probably could use the system to help them in this type of case but as of yet they have not requested access or a stand alone system at any of their locations even though we have offered in the past.
One thing stinks in this whole North Korea blame game. There are misspellings in some of the code used in the first attack and the second attack does not show the same signs. We find it hard to believe that the same people are responsible based on word structure and simple elimination due to the fact that the IP addresses that were cited in an earlier report have changed hands in the botnet wars on more than four separate occasions over the past year and one of the IP's is in direct control of a known China group that would be more suited to carry out this type of attack. This same IP also is hosting malware and has been listed as a compromised system 2 times in the past 2 months.
Truth be told nobody knows exactly who has committed this act and secondly it is nearly impossible without having access to the Internet Service Providers (ISP) core networks to analyze traffic. I say show me proof and I"ll believe that it was North Korea. There are too many ways for these guys to cover their tracks than to make a connection through one of the 1024 official IP addresses that are in use in North Korea. This information is also wrong as there are over 5000 IP addresses in our systems that lead to North Korean associate entities masked as news and public information sites (most of which are hosting propaganda on servers outside of North Korea). It stands to reason based on our intelligence that the North Korean Government is responsible for these systems directly as they do not allow outside entities to utilize communications systems and have played mock games with various releases of "malware" and viruses on these same systems infecting thousands of other entities. If they were in fact responsible they would do like every other hacker and use jump servers to mask their identity.
If you really want to see something interesting look at the 194.165.134.0/24 block and look at connections going to and from the Internet via that IP block. Then you may be able to tell us something.
One thing stinks in this whole North Korea blame game. There are misspellings in some of the code used in the first attack and the second attack does not show the same signs. We find it hard to believe that the same people are responsible based on word structure and simple elimination due to the fact that the IP addresses that were cited in an earlier report have changed hands in the botnet wars on more than four separate occasions over the past year and one of the IP's is in direct control of a known China group that would be more suited to carry out this type of attack. This same IP also is hosting malware and has been listed as a compromised system 2 times in the past 2 months.
Truth be told nobody knows exactly who has committed this act and secondly it is nearly impossible without having access to the Internet Service Providers (ISP) core networks to analyze traffic. I say show me proof and I"ll believe that it was North Korea. There are too many ways for these guys to cover their tracks than to make a connection through one of the 1024 official IP addresses that are in use in North Korea. This information is also wrong as there are over 5000 IP addresses in our systems that lead to North Korean associate entities masked as news and public information sites (most of which are hosting propaganda on servers outside of North Korea). It stands to reason based on our intelligence that the North Korean Government is responsible for these systems directly as they do not allow outside entities to utilize communications systems and have played mock games with various releases of "malware" and viruses on these same systems infecting thousands of other entities. If they were in fact responsible they would do like every other hacker and use jump servers to mask their identity.
If you really want to see something interesting look at the 194.165.134.0/24 block and look at connections going to and from the Internet via that IP block. Then you may be able to tell us something.
Sunday, December 14, 2014
Wireless the Number 1 Vector
If your organization is running wireless we are advising you that this is the number one attack vector. It is recommended that you move to certificate based authentication. In 57 of 60 assessments we are reviewing wireless is by far the easiest vector to gain access to corporate networks. Even if corporate wireless networks are segregated the information sent through these networks may lead to actual compromises of legitimate network resources due to the fact that many devices will still try and authenticate to resources over the network.
When conducting penetration testing we are successful over 95% of the time in gaining credentials over guest networks so just because you think your guest network is not connected to your corporate network you should still be vigilant in monitoring.
When conducting penetration testing we are successful over 95% of the time in gaining credentials over guest networks so just because you think your guest network is not connected to your corporate network you should still be vigilant in monitoring.
EXCLUSIVE: The Top 10 Items Missed During an Audit (Article 3 of 10 in a series)
This is an exclusive provided by SLC Security Services LLC the leader in Medical, Compliance and DOD Auditing Solutions.
Number 10 on the list is attacks on your Disaster Recovery Plan or Third Parties that handle your data. We are seeing more and more third party vendors of large companies open them up to compromise due to standards not being in place and no auditing of third parties that you share data.
If you remember Target this was a perfect example whereas their air conditioning contractor failed to secure their network and malware was introduced via this path. Many times businesses open up firewalls to vendors without any auditing and verification of what data is moving through those trusted connections. Here are some recommendations to prevent your vendors from allowing a hacker to jump through a third party and gain access to unauthorized resources.
1. Even though a vendor may be "trusted" they should only be trusted to particular systems. The systems should not reside in your network. Host that data in a separate network segment that you can introduce DLP or monitoring protections such as IPS and IDS and make sure you are alerted if any attempts are made to access resources other than the destinations you have authorized.
2. Grant the least access required. Open only single IP and services in your firewall. Don't completely allow them to access any resource on your internal networks.
3. ENCRYPT YOUR DATA as it leaves your network. Ensure that information that is taken is encrypted. This prevents somebody other than your vendor from accessing data in which they are not authorized to view. Use time based encryption so that the keys are generated and discarded daily using security devices made for this purpose.
4. Require 2 factor authentication to view or access systems. Sure it may be inconvenient but so is losing your customer base to hackers.
If possible use hardware based network cards (INTEL makes a great solution) that only allows one device on your customer network to access only the single device on your internal network that they require to carry out authorized functions and processes.
Another great idea is to use an endpoint firewall solution.
If you would like to audit your third party vendors contact SLC Security at (919) 441-7353 to schedule an audit.
Number 10 on the list is attacks on your Disaster Recovery Plan or Third Parties that handle your data. We are seeing more and more third party vendors of large companies open them up to compromise due to standards not being in place and no auditing of third parties that you share data.
If you remember Target this was a perfect example whereas their air conditioning contractor failed to secure their network and malware was introduced via this path. Many times businesses open up firewalls to vendors without any auditing and verification of what data is moving through those trusted connections. Here are some recommendations to prevent your vendors from allowing a hacker to jump through a third party and gain access to unauthorized resources.
1. Even though a vendor may be "trusted" they should only be trusted to particular systems. The systems should not reside in your network. Host that data in a separate network segment that you can introduce DLP or monitoring protections such as IPS and IDS and make sure you are alerted if any attempts are made to access resources other than the destinations you have authorized.
2. Grant the least access required. Open only single IP and services in your firewall. Don't completely allow them to access any resource on your internal networks.
3. ENCRYPT YOUR DATA as it leaves your network. Ensure that information that is taken is encrypted. This prevents somebody other than your vendor from accessing data in which they are not authorized to view. Use time based encryption so that the keys are generated and discarded daily using security devices made for this purpose.
4. Require 2 factor authentication to view or access systems. Sure it may be inconvenient but so is losing your customer base to hackers.
If possible use hardware based network cards (INTEL makes a great solution) that only allows one device on your customer network to access only the single device on your internal network that they require to carry out authorized functions and processes.
Another great idea is to use an endpoint firewall solution.
If you would like to audit your third party vendors contact SLC Security at (919) 441-7353 to schedule an audit.
Friday, December 12, 2014
List of Owned Colleges and Universities
Over a weeks worth of research and sensor data has indicated a very large amount of college and universities that are infected with malware and/or viruses. In order to be listed a college would have to have been infected for a period of more than 7 days without detecting the botnet, virus, malware or compromised host. This report is only a snapshot in time but is current as of 12/12/2014. If you are in data security at these universities you can research public blacklist as we have already listed out the IP address ranges in our feed at http://www.slcsecurity.com/blocks/alert-ips.txt. Check the feed and if your in that list you might want to check your computing resources as soon as you can.
If you have trouble locating the infected boxes please reply to this post and we attempt to help you locate the infected or offending devices that we are observing.
University of Arkansas
University of Waterloo
University of California - This entity has acknowledged and is actively re-mediating the breach
University of Missouri Columbia
University of Maryland
University of Pennsylvania (PENNSTATE)
These are the universities that are currently show up in our OSINT systems. We are still working on a master list.
If you have trouble locating the infected boxes please reply to this post and we attempt to help you locate the infected or offending devices that we are observing.
University of Arkansas
University of Waterloo
University of California - This entity has acknowledged and is actively re-mediating the breach
University of Missouri Columbia
University of Maryland
University of Pennsylvania (PENNSTATE)
These are the universities that are currently show up in our OSINT systems. We are still working on a master list.
Thursday, December 11, 2014
Colleges Largely Already Owned by Hackers or Spreading Malware
During research on our analytic system this week he are noticing a bad trend concerning educational institutions. We started looking at colleges and conducted some analytic research that indicates that 52% of college and university networks currently have at least one host that is actively participating in bot or malware campaigns. What is troubling us lately is that many of the organizations we are seeing in our OSINT products have remained compromised or infected for very long periods of time.
We have scheduled an analytics job to run tonight that will look through our systems and match educational institutions to known indicators of compromise and we will be releasing the list of infected schools in the next several days once we have had a chance to analyze the results.
"These schools have students studying cyber security and forensics so it's concerning that they have not had their students take an inner look at their networks and secured these vulnerabilities".
We have scheduled an analytics job to run tonight that will look through our systems and match educational institutions to known indicators of compromise and we will be releasing the list of infected schools in the next several days once we have had a chance to analyze the results.
"These schools have students studying cyber security and forensics so it's concerning that they have not had their students take an inner look at their networks and secured these vulnerabilities".
Friday, December 5, 2014
EXCLUSIVE: The Top 10 Items Missed During an Audit (Article 2 of 10 in a series)
This is an exclusive provided by SLC Security Services LLC the leader in Medical, Compliance and DOD Auditing Solutions.
Issue 9 - Inadequate security of network path and access control systems
Yes we are jumping around a bit that's just because we have been really tied up with some clients this week. So here goes...
The number 9 issue on the top 10 list of items missed during audits is something most auditing companies never even check. When doing audits one of the items we check as part of our TSCM sweeps are the network, phone and cable paths. What we are referring to here are network cables that actually are accessible outside of your building, telephone connections in shared closets or alert system components in public areas that can be manipulated without gaining physical access to your secure space.
How many times have you been in a building and seen a closet labeled "Telecom Closet" or some similar title? These areas are troublesome for many of our clients that lease space in buildings. One of the things we have had to do at some client locations is request separate telephone lines and communications lines be brought directly into our customer space. We also insist on full metal conduits into the building as to prevent wire tapping and similar physical attacks on the lines. Full metal conduits also prevent some really neat tricks in which you don't even have to cut the phone lines to be able to monitor them.
At one bank recently we noted that in the walk in area beside the ATM was a network jack on the wall. When we tested the network jack it was connected directly to the customers network switch and the port was active. The port gave us an IP address and through passive network monitoring we are able to run wireshark and get at a ton of very sensitive information to include the domain information for network that the tellers in the branch were logging into. With some arp poisoning we were able to capture login credentials, needless to say the client disabled the port after the audit.
One important thing to note: 95% of the companies that we initially audit are not even aware of the TSCM threats that exist. Many times our audits are eye opening as we can tell who is in a building, login information to networks, etc, etc. just because they are not aware of some of these attack vectors. I can't tell you the number of wireless networks we find. It's very surprising and somewhat easy to obtain access to these networks when we do stumble upon these links.
So there you have it. Check your cable paths and make sure your devices are not going into shared space. If you really want to ensure the security of your communications here are a few other tips.
1. Do not use fax machines to send medical, PII or sensitive information over the telephone network. While most people think telephone networks are secure there are many stops along the way whereas your competition can get at your information and reconstruct your faxes, emails, etc.
2. Do not allow employees to bring personal electronic devices into areas that house PII or PHI. It has been proven that this is an attack vector that can be exploited.
3. Ensure cable paths are properly secured.
4. Do not use wireless handsets even if they are DECT "secure". DECT can be reconstructed it just takes the know how and tools to do it.
5. Do not send PII over wireless networks.
6. Do not allow third party vendors into any network that houses PII, PHI or PCI.
Have a great day folks and be sure to look for the next article in this series.
Issue 9 - Inadequate security of network path and access control systems
Yes we are jumping around a bit that's just because we have been really tied up with some clients this week. So here goes...
The number 9 issue on the top 10 list of items missed during audits is something most auditing companies never even check. When doing audits one of the items we check as part of our TSCM sweeps are the network, phone and cable paths. What we are referring to here are network cables that actually are accessible outside of your building, telephone connections in shared closets or alert system components in public areas that can be manipulated without gaining physical access to your secure space.
How many times have you been in a building and seen a closet labeled "Telecom Closet" or some similar title? These areas are troublesome for many of our clients that lease space in buildings. One of the things we have had to do at some client locations is request separate telephone lines and communications lines be brought directly into our customer space. We also insist on full metal conduits into the building as to prevent wire tapping and similar physical attacks on the lines. Full metal conduits also prevent some really neat tricks in which you don't even have to cut the phone lines to be able to monitor them.
At one bank recently we noted that in the walk in area beside the ATM was a network jack on the wall. When we tested the network jack it was connected directly to the customers network switch and the port was active. The port gave us an IP address and through passive network monitoring we are able to run wireshark and get at a ton of very sensitive information to include the domain information for network that the tellers in the branch were logging into. With some arp poisoning we were able to capture login credentials, needless to say the client disabled the port after the audit.
One important thing to note: 95% of the companies that we initially audit are not even aware of the TSCM threats that exist. Many times our audits are eye opening as we can tell who is in a building, login information to networks, etc, etc. just because they are not aware of some of these attack vectors. I can't tell you the number of wireless networks we find. It's very surprising and somewhat easy to obtain access to these networks when we do stumble upon these links.
So there you have it. Check your cable paths and make sure your devices are not going into shared space. If you really want to ensure the security of your communications here are a few other tips.
1. Do not use fax machines to send medical, PII or sensitive information over the telephone network. While most people think telephone networks are secure there are many stops along the way whereas your competition can get at your information and reconstruct your faxes, emails, etc.
2. Do not allow employees to bring personal electronic devices into areas that house PII or PHI. It has been proven that this is an attack vector that can be exploited.
3. Ensure cable paths are properly secured.
4. Do not use wireless handsets even if they are DECT "secure". DECT can be reconstructed it just takes the know how and tools to do it.
5. Do not send PII over wireless networks.
6. Do not allow third party vendors into any network that houses PII, PHI or PCI.
Have a great day folks and be sure to look for the next article in this series.
Tuesday, December 2, 2014
Leveraging Big Data in your Enterprise
You cannot possibly view every single log file, every single login, every single password change, email, forum post, blog access, etc, etc. within your organization with the limits to staffing. It's not possible. This may be why Mandiant says that it takes over 200+ days to recognize an intrusion. The reason that it takes so long is because no administrator or security engineer can possibly read everything that comes into your network. This is where big data comes into play as well as analytics and data warehousing.
If your short on staff you should look into ways to make your existing staff more effective. One very easy win for the enterprise is to utilize distributed computing and big data together to find those needles in a hay stack.
So why aren't more company's investing in big data? Don't get it wrong many companies are using big data for business processes. Only a handful are using big data for use in analytic log monitoring. You and I both know that you cannot possibly look at every single line of code, every single log file, every single email or document stored on your network, and who would want to? So how can you use big data to find security issues in your network? Build a cloud and run analytics to look at the data differently.
I will be posting more on distributed computing and cloud storage in the upcoming weeks. Stay tuned and have a great day!
If your short on staff you should look into ways to make your existing staff more effective. One very easy win for the enterprise is to utilize distributed computing and big data together to find those needles in a hay stack.
So why aren't more company's investing in big data? Don't get it wrong many companies are using big data for business processes. Only a handful are using big data for use in analytic log monitoring. You and I both know that you cannot possibly look at every single line of code, every single log file, every single email or document stored on your network, and who would want to? So how can you use big data to find security issues in your network? Build a cloud and run analytics to look at the data differently.
I will be posting more on distributed computing and cloud storage in the upcoming weeks. Stay tuned and have a great day!
Monday, December 1, 2014
EXCLUSIVE: The Top 10 Items Missed During an Audit (Article 1 of 10 in a series)
This is an exclusive provided by SLC Security Services LLC the leader in Medical, Compliance and DOD Auditing Solutions.
One of our clients recently had a discussion with our auditing team and brought up a good point. John ask us specifically what are the 10 most common items missed during an audit or that IT personnel or security personnel fail to catch when preparing or when being audited by our firm? I stood there for a minute just digesting the question that was just posed and actually listed what I thought from my perspective the top 10 items would be. Then I started thinking some more about how I could actually make something useful out of the question and present it to customers and others that could benefit from that question.
Once I returned to the office I decided that I would take a look at the last years failed items and try and generate a top 10 list of items from the data that we had from our customers. After all I wouldn't be releasing what items were failures at each customer and all of the items in the failure block have already been corrected or accepted as a risk item so little to no harm could be done by compiling stats and expounding on this question a bit.
This is the first of 10 articles that we will be writing on this topic over the next few weeks. The goal is to get this series completed by the 1st of the year.
The Number One Issue - Failure to Document
Every single audit this past year has had this issue. There was at least one system that was connected to the network that was not documented. In order to ensure that systems are patched, secured, accounts that are no longer being used are removed, etc, etc. You have to know that a system exist. And worse yet you have to know what operating system is installed on that system so you can map out what vulnerabilities may be present. A good example of this is a particularly large client. Because we are under NDA we won't name them but just know they are one of the largest companies in Internet communications. An audit was conducted and as part of the audit we identified nearly 1400 devices on the LAN (Local Area Network) for this company. Honestly this number is small but we were only dealing with a regional office so this was our number. The company could account for nearly all of the devices except 64 of them. We received valid responses to probes in our scanning software and we knew that the system work running Linux but we could not locate them anywhere. We checked everything from the security cameras, VOIP phones, etc, etc and were having a hard time locating them until we were about to give up.
I was walking from the third floor heading to the parking lot when I swiped my card to exit the building and just froze. My team mate looked at me because he could sense the rubber burning in my head and I said to him "that's it". He said "What's it?". I said right there... He looked at me confused I said it's the door access readers that are running Linux. We went back to the third floor and ask who maintains the door access system and the security manager said that's managed by corporate. After a quick 10 minute phone call we had located all of the devices and accounted for them and were able to document the finding. Guess what?! Four of these devices had been compromised and were being used as a jump point into the internal network of this "company". We were able to get on the same VLAN as the devices and we determined that each and every one of them were vulnerable to the bash bug as the readers were running Busybox. The vendor had even notified the IT department but that information never got back to the security department. This is why having a third set of eyes is important. For months information was being stolen from the company without anybody even being aware of it. Luckily it was only the reader data which included the card number and employees name and email address but it was still a significant finding. Upon additional research we noted that this information was being used in Phishing attacks against individuals within the company and two personnel's computers were compromised using data that was obtained through the card readers.
Since the company did not document these devices our counts were off during the audit and we were certainly not going to leave the company until we knew what these devices were and could ensure that they were secured. This audit was a preliminary audit that ended up getting us a major support contract with the company because the security staff realized that we would ensure that each and every connected device was accounted for and documented properly. This contract was just signed on the 22nd of November and we look forward to auditing many other locations in the upcoming year.
Make sure you are documenting every device. When a vulnerability comes along if you don't know what devices are running what operating system it is nearly impossible to ensure that your networks and connected devices are secured.
If you can't document your finding or your devices correctly make sure you hire a company that can. The sad part of this story is that this company had passed 2 previous audits in the preceding 6 months and swore they were compliant. Luckily the network in which these readers were placed were in a separate VLAN but there were problems with shared space as these devices were directly addressable from the Internet as were the controllers that connected the office back to corporate to obtain the list of authorized personnel for each location. These were the systems that were vulnerable and what caused us to fail the organization. The good news is that the issue uncovered was not reportable so the company maintained their reputation but that is not always the case. As part of our audits we report any findings if we can confirm that information has been leaked to unauthorized third parties and we follow the reporting recommendations of CMS, HIPAA, ITSG, STIG, etc, etc.
Here are the other 9 items missed on most audits. These items will be followed up on in later articles with specific and detailed examples and information.
Ask yourselves today do you know where every single connected or mobile device is that is attached to your network? Have you secured all guest networks, access networks, VLAN's? Have you patched all security systems, telephone systems, copier machines, faxes, computers, servers, routers, switches, etc.? I we audited your organization today do you know what versions of software are running on every device? Are you current with all third party vendor patches?
The answer obviously is no. No organization ever can document every single device, patch level, operating system, etc. The goal of the audit is to do just that. Provide the documentation that turns a 3 month audit into a 2 week audit. If you can answer the auditors questions the first time you may pass but don't you want to pass with flying colors? Don't you want real piece of mind? Remember Target passed their audits too but that's because the audits were only for a specific system and not how the systems interacted. It doesn't matter if a system is patched to the latest version of your guest network has vulnerabilities that can allow MITM or Malware to infect those systems. Just because you passed that audit doesn't mean you have passed an SLC Security Services LLC audit. If we don't find it, your audit is free!
The Rest of the List... (Future Articles)
2. Failure to remove old accounts or have a system in place to deactivate unused accounts.
3. Incorrect workstation settings not in line with your business need. Insecure servers and workstations.
4. Reliance on Anti-Virus and Malware Protection that is inadequate
5. No signal and propagation protection in regards to wireless, paging, cellular and other wireless technologies.
6. Inadequate email protection.
7. No ability to audit email, files leaving the enterprise or the removal of proprietary information via electronic systems.
8. Social networking succeeded at the organization leading to a compromised system.
9. Inadequate security of network path and access control systems.
10. Attacks on disaster recovery plan whereas data was stolen from a third party or a third party provider to our clients in transit.
We hope you have enjoyed this initial article. We will cover the other nine topics in future post. We hope you have all had a great holiday and now we are all back to the grind. Have a great week and remember to keep things secured!
One of our clients recently had a discussion with our auditing team and brought up a good point. John ask us specifically what are the 10 most common items missed during an audit or that IT personnel or security personnel fail to catch when preparing or when being audited by our firm? I stood there for a minute just digesting the question that was just posed and actually listed what I thought from my perspective the top 10 items would be. Then I started thinking some more about how I could actually make something useful out of the question and present it to customers and others that could benefit from that question.
Once I returned to the office I decided that I would take a look at the last years failed items and try and generate a top 10 list of items from the data that we had from our customers. After all I wouldn't be releasing what items were failures at each customer and all of the items in the failure block have already been corrected or accepted as a risk item so little to no harm could be done by compiling stats and expounding on this question a bit.
This is the first of 10 articles that we will be writing on this topic over the next few weeks. The goal is to get this series completed by the 1st of the year.
The Number One Issue - Failure to Document
Every single audit this past year has had this issue. There was at least one system that was connected to the network that was not documented. In order to ensure that systems are patched, secured, accounts that are no longer being used are removed, etc, etc. You have to know that a system exist. And worse yet you have to know what operating system is installed on that system so you can map out what vulnerabilities may be present. A good example of this is a particularly large client. Because we are under NDA we won't name them but just know they are one of the largest companies in Internet communications. An audit was conducted and as part of the audit we identified nearly 1400 devices on the LAN (Local Area Network) for this company. Honestly this number is small but we were only dealing with a regional office so this was our number. The company could account for nearly all of the devices except 64 of them. We received valid responses to probes in our scanning software and we knew that the system work running Linux but we could not locate them anywhere. We checked everything from the security cameras, VOIP phones, etc, etc and were having a hard time locating them until we were about to give up.
I was walking from the third floor heading to the parking lot when I swiped my card to exit the building and just froze. My team mate looked at me because he could sense the rubber burning in my head and I said to him "that's it". He said "What's it?". I said right there... He looked at me confused I said it's the door access readers that are running Linux. We went back to the third floor and ask who maintains the door access system and the security manager said that's managed by corporate. After a quick 10 minute phone call we had located all of the devices and accounted for them and were able to document the finding. Guess what?! Four of these devices had been compromised and were being used as a jump point into the internal network of this "company". We were able to get on the same VLAN as the devices and we determined that each and every one of them were vulnerable to the bash bug as the readers were running Busybox. The vendor had even notified the IT department but that information never got back to the security department. This is why having a third set of eyes is important. For months information was being stolen from the company without anybody even being aware of it. Luckily it was only the reader data which included the card number and employees name and email address but it was still a significant finding. Upon additional research we noted that this information was being used in Phishing attacks against individuals within the company and two personnel's computers were compromised using data that was obtained through the card readers.
Since the company did not document these devices our counts were off during the audit and we were certainly not going to leave the company until we knew what these devices were and could ensure that they were secured. This audit was a preliminary audit that ended up getting us a major support contract with the company because the security staff realized that we would ensure that each and every connected device was accounted for and documented properly. This contract was just signed on the 22nd of November and we look forward to auditing many other locations in the upcoming year.
Make sure you are documenting every device. When a vulnerability comes along if you don't know what devices are running what operating system it is nearly impossible to ensure that your networks and connected devices are secured.
If you can't document your finding or your devices correctly make sure you hire a company that can. The sad part of this story is that this company had passed 2 previous audits in the preceding 6 months and swore they were compliant. Luckily the network in which these readers were placed were in a separate VLAN but there were problems with shared space as these devices were directly addressable from the Internet as were the controllers that connected the office back to corporate to obtain the list of authorized personnel for each location. These were the systems that were vulnerable and what caused us to fail the organization. The good news is that the issue uncovered was not reportable so the company maintained their reputation but that is not always the case. As part of our audits we report any findings if we can confirm that information has been leaked to unauthorized third parties and we follow the reporting recommendations of CMS, HIPAA, ITSG, STIG, etc, etc.
Here are the other 9 items missed on most audits. These items will be followed up on in later articles with specific and detailed examples and information.
Ask yourselves today do you know where every single connected or mobile device is that is attached to your network? Have you secured all guest networks, access networks, VLAN's? Have you patched all security systems, telephone systems, copier machines, faxes, computers, servers, routers, switches, etc.? I we audited your organization today do you know what versions of software are running on every device? Are you current with all third party vendor patches?
The answer obviously is no. No organization ever can document every single device, patch level, operating system, etc. The goal of the audit is to do just that. Provide the documentation that turns a 3 month audit into a 2 week audit. If you can answer the auditors questions the first time you may pass but don't you want to pass with flying colors? Don't you want real piece of mind? Remember Target passed their audits too but that's because the audits were only for a specific system and not how the systems interacted. It doesn't matter if a system is patched to the latest version of your guest network has vulnerabilities that can allow MITM or Malware to infect those systems. Just because you passed that audit doesn't mean you have passed an SLC Security Services LLC audit. If we don't find it, your audit is free!
The Rest of the List... (Future Articles)
2. Failure to remove old accounts or have a system in place to deactivate unused accounts.
3. Incorrect workstation settings not in line with your business need. Insecure servers and workstations.
4. Reliance on Anti-Virus and Malware Protection that is inadequate
5. No signal and propagation protection in regards to wireless, paging, cellular and other wireless technologies.
6. Inadequate email protection.
7. No ability to audit email, files leaving the enterprise or the removal of proprietary information via electronic systems.
8. Social networking succeeded at the organization leading to a compromised system.
9. Inadequate security of network path and access control systems.
10. Attacks on disaster recovery plan whereas data was stolen from a third party or a third party provider to our clients in transit.
We hope you have enjoyed this initial article. We will cover the other nine topics in future post. We hope you have all had a great holiday and now we are all back to the grind. Have a great week and remember to keep things secured!
Monday, November 10, 2014
Applebee's Quietly Disabling Wifi Payment System?
Just this week we were advised that 2 of our local Applebee's no longer allowed customers to pay via the tableside tablet system that has been in place well over a year. It appears as though the retailer may be concerned about the security of the system after many highly publicized breaches. We have confirmed 3 of the 4 locations we checked indicated that the system no longer works.
If any researchers have any insight into what prompted this we would be interested in working with you.
If any researchers have any insight into what prompted this we would be interested in working with you.
Thursday, November 6, 2014
Leveraging Hadoop for Security Analysis in Networks
I have been trying to stay active on the blog but as you all can tell we have become somewhat busy over the past few weeks. This is to be expected when we are in a predictive mode instead of a reactive one. Earlier tonight I was showing another security engineer how we can pull various data points into our hadoop cluster and analyze things quicker and more efficiently than we can on a single computer. Over the past 5 years I have built cloud environments for many purposes some of which ended up being long term solutions and some of which went away when administrators realized that operating a cloud requires a specific set of skills and the right people in the right places. A single person can maintain a cloud computing environment with the right software management in place but the work can be consuming until you automate everything.
As part of our business model the cloud is an integral part of what we do. From collecting news and intelligence information for analysis, to running batch jobs to do task that would take a security engineer hour upon hour to complete manually, the cloud makes life easier. There are some tradeoffs when utilizing the cloud as you have to fully understand what each piece of software does and how they interact with one another to get a job to a completed state.
So why this article? Because as security engineers you can't possibly look at all the data in an enterprise. You can however build watch list in a cloud to notify you when certain content is being ingested into the system. This saves the engineers time. Here's an example. Say a new malware variant comes on the scene and you want to analyze how many machines are infected with the malware. You will need a few things to get the task done in a reasonable time frame. Doing task manually make take weeks or even months but leveraging hadoop, solr, cassandra, hive, pig, etc, etc. you can do these same task in under a day. I like to let the cloud work while I sleep. I wake up feeling somewhat productive if the task are completed when I start my work day. But let's get back to our example. In order to find that elusive new malware variant you need some things. Let me list them out.
Computing Power (CPU's) - Processing Gigabytes or Petabytes of data requires heavy usage of CPU's. By leveraging multicore CPU's in a cluster of machines you eliminate this problem.
Memory (RAM) - You have to have memory. Things are read and written much quicker in memory than on disc drives (think solid state drives here). If you can afford them put SSD's in your cloud. Your batch jobs will thank you.
Disc Space - You have to have the space to store things. If you can't store the Petabytes of data you can't analyze it either. You need a place to store your vectors, configurations, investigative files, etc.
Vectors - You have to have points of data to work with. In our malware example let's say we will use the MD5 hashes of the malware to detect it. That's a vector of identification. Once we identify it we need to process it.
Scripts, Parsers, Libraries and such - You have to have a consistent, and standardized way of doing things so your jobs are repeatable. You want predictable results without error. You will use a multitude of scripts, mapreduce jobs, indexes (to speed searches and queries), and parsers to find what your looking for.
Now that we have found the malware on the network what do we do with it. One of the most likely things you will do with a cloud is build statistics. In this case we want to build a list of infected IP addresses and domain names so we know what entity is infected so we can report on it (probably on a blog such as this one). However we don't want to sit and sift through Petabytes of data so we write our process out in mapreduce or some other language and let it work while we sleep.
Live Streaming Data - In order to find malware infections in near real time we need to have near real time data. Products such as sqoop and flume help in this regard. So we pull in things such as network pcaps, honeypot logs, malware submission reports, etc, etc.
So using all these various tools and data points we begin collecting statistics but that's not all we have to do. We want to identify the IP address or domain owners so we can notify them (just like we do when a patients information get's released to the public). We have to know whom to notify so it's imperative to identify.
Tracking - Once you have the information in hand you now need a way to track the outcome of your notifications. This is where old technology such as a pen and paper, an electronic notebook or hell maybe even one of those fancy trouble ticketing systems would work.
In order to make it in this fast moving world you have to do things quicker, more accurate and get the information out there before your competition. This is what a cloud does for us and what it could do for your organization.
Happy Hadooping!
About the author: Kevin Wetzel has been a leading researcher and cloud engineer since 2006. He has worked for various organizations to include the Department of Defense, Department of Homeland Security, various Health Care and Insurance organizations, business owners and politicians as well as private parties. Mr. Wetzel is a fan of cloud computing to make business processes run more efficiently. SLC Security Services LLC relies heavily on this type of technology in many of our services and products. Cloud computing can mean the difference between just getting the job done and getting the job done efficiently and before your competition. Kevin is a CCHA (yeah I got the certification before they changed it to CCAH), a licensed Investigator and Counterintelligence Specialist with SLC Security Services LLC. For more information on SLC Security you can visit the company website at www.slcsecurity.com.
As part of our business model the cloud is an integral part of what we do. From collecting news and intelligence information for analysis, to running batch jobs to do task that would take a security engineer hour upon hour to complete manually, the cloud makes life easier. There are some tradeoffs when utilizing the cloud as you have to fully understand what each piece of software does and how they interact with one another to get a job to a completed state.
So why this article? Because as security engineers you can't possibly look at all the data in an enterprise. You can however build watch list in a cloud to notify you when certain content is being ingested into the system. This saves the engineers time. Here's an example. Say a new malware variant comes on the scene and you want to analyze how many machines are infected with the malware. You will need a few things to get the task done in a reasonable time frame. Doing task manually make take weeks or even months but leveraging hadoop, solr, cassandra, hive, pig, etc, etc. you can do these same task in under a day. I like to let the cloud work while I sleep. I wake up feeling somewhat productive if the task are completed when I start my work day. But let's get back to our example. In order to find that elusive new malware variant you need some things. Let me list them out.
Computing Power (CPU's) - Processing Gigabytes or Petabytes of data requires heavy usage of CPU's. By leveraging multicore CPU's in a cluster of machines you eliminate this problem.
Memory (RAM) - You have to have memory. Things are read and written much quicker in memory than on disc drives (think solid state drives here). If you can afford them put SSD's in your cloud. Your batch jobs will thank you.
Disc Space - You have to have the space to store things. If you can't store the Petabytes of data you can't analyze it either. You need a place to store your vectors, configurations, investigative files, etc.
Vectors - You have to have points of data to work with. In our malware example let's say we will use the MD5 hashes of the malware to detect it. That's a vector of identification. Once we identify it we need to process it.
Scripts, Parsers, Libraries and such - You have to have a consistent, and standardized way of doing things so your jobs are repeatable. You want predictable results without error. You will use a multitude of scripts, mapreduce jobs, indexes (to speed searches and queries), and parsers to find what your looking for.
Now that we have found the malware on the network what do we do with it. One of the most likely things you will do with a cloud is build statistics. In this case we want to build a list of infected IP addresses and domain names so we know what entity is infected so we can report on it (probably on a blog such as this one). However we don't want to sit and sift through Petabytes of data so we write our process out in mapreduce or some other language and let it work while we sleep.
Live Streaming Data - In order to find malware infections in near real time we need to have near real time data. Products such as sqoop and flume help in this regard. So we pull in things such as network pcaps, honeypot logs, malware submission reports, etc, etc.
So using all these various tools and data points we begin collecting statistics but that's not all we have to do. We want to identify the IP address or domain owners so we can notify them (just like we do when a patients information get's released to the public). We have to know whom to notify so it's imperative to identify.
Tracking - Once you have the information in hand you now need a way to track the outcome of your notifications. This is where old technology such as a pen and paper, an electronic notebook or hell maybe even one of those fancy trouble ticketing systems would work.
In order to make it in this fast moving world you have to do things quicker, more accurate and get the information out there before your competition. This is what a cloud does for us and what it could do for your organization.
Happy Hadooping!
About the author: Kevin Wetzel has been a leading researcher and cloud engineer since 2006. He has worked for various organizations to include the Department of Defense, Department of Homeland Security, various Health Care and Insurance organizations, business owners and politicians as well as private parties. Mr. Wetzel is a fan of cloud computing to make business processes run more efficiently. SLC Security Services LLC relies heavily on this type of technology in many of our services and products. Cloud computing can mean the difference between just getting the job done and getting the job done efficiently and before your competition. Kevin is a CCHA (yeah I got the certification before they changed it to CCAH), a licensed Investigator and Counterintelligence Specialist with SLC Security Services LLC. For more information on SLC Security you can visit the company website at www.slcsecurity.com.
Wednesday, November 5, 2014
The Latest Hacking Craze - Old Attacks - New Technology
SLC Security provides an SDR course for beginners. What is an SDR you ask? SDR stands for "software defined radio". No longer is it the craze to go and buy or construct a tinfoil hat in 2014. In fact even if you did there are still ways to pickup very tiny signals, in much larger signals (trace signals) that used to be nearly impossible. OK, OK enough of the rambling.
One vector we are starting to see from hackers is definitely old technology. Remember TEMPEST? Well if you don't know anything about it, let me just say it's the unintentional transmission of signals from devices that are not properly shielded. Or in some cases that can't be shielded due to their design.
Everything with electrical energy passing through it has some sort of emission. Some devices such as transmitters are designed to emit this RF energy, some things like your computer monitor or your USB keyboard are not (but they do). Utilizing $20 USD in equipment it is possible to capture keystrokes and recover the text being typed at around 85% accuracy. It's possible to get about 80% of your monitors pixels also from the same methods and while the picture may be fuzzy it is somewhat readable.
Don't believe me? Well you don't have to. Here's something you can play with if you have a monitor and an AM radio. That's right your computer monitor likes to transmit AM radio...
Download "Tempest for Eliza" and give it a shot. I think you will have some fun with it. Then when your done call us and we can show you how we can recover your works screens during an audit from 21 feet away, through a wall from a parking lot, another floor, etc, etc. Oh and don't get us started on some of the lovely Cisco equipment out there that is inexpensive. That wireless router is leaking like you wouldn't believe (and not on the intended frequencies either).
We have so much fun doing our jobs. It's nice to take a break and get silly from time to time.
SLC Security Services LLC is licensed for Counterintelligence Service in the State of North Carolina. We operate in all 50 states and are available for TSCM related sweeps and consulting, RF engineering and Satcom Engineering work. Call (919)441-7353 and request to talk to a TSCM tech.
One vector we are starting to see from hackers is definitely old technology. Remember TEMPEST? Well if you don't know anything about it, let me just say it's the unintentional transmission of signals from devices that are not properly shielded. Or in some cases that can't be shielded due to their design.
Everything with electrical energy passing through it has some sort of emission. Some devices such as transmitters are designed to emit this RF energy, some things like your computer monitor or your USB keyboard are not (but they do). Utilizing $20 USD in equipment it is possible to capture keystrokes and recover the text being typed at around 85% accuracy. It's possible to get about 80% of your monitors pixels also from the same methods and while the picture may be fuzzy it is somewhat readable.
Don't believe me? Well you don't have to. Here's something you can play with if you have a monitor and an AM radio. That's right your computer monitor likes to transmit AM radio...
Download "Tempest for Eliza" and give it a shot. I think you will have some fun with it. Then when your done call us and we can show you how we can recover your works screens during an audit from 21 feet away, through a wall from a parking lot, another floor, etc, etc. Oh and don't get us started on some of the lovely Cisco equipment out there that is inexpensive. That wireless router is leaking like you wouldn't believe (and not on the intended frequencies either).
We have so much fun doing our jobs. It's nice to take a break and get silly from time to time.
SLC Security Services LLC is licensed for Counterintelligence Service in the State of North Carolina. We operate in all 50 states and are available for TSCM related sweeps and consulting, RF engineering and Satcom Engineering work. Call (919)441-7353 and request to talk to a TSCM tech.
Over 1000 Backoff Malware Infected Machines in the US, 2500 in Europe
Researchers at SLC Security Services LLC have been able to identify over 3500 positive infections utilizing 3 variants of the Backoff malware over the past 30 days. By capturing data over networks and comparing against known MD5 hashes we can first detect the infection. Then the infected host will start making DNS request to Google DNS servers (8.8.8.8) and then the encrypted data stream we feel as though our detection methods are accurate.
One of the interesting things to note is that of the affected hosts we published earlier this month nearly half of their networks are still sending data through 8 hub locations in which we were able to analyze traffic through one of our business partners that is a major Internet Service Provider in North America. We created and were able to get our partners to run a set of 10 snort signatures that we provided as well as a customized program to capture binary streams off the wire to analyze them for known MD5 matches without storing the data.
It seems that the vendors and corporations affected either do not have adequate detection in place or have failed to lock down their networks sufficiently to protect the infrastructure. In one case we even found a misconfigured POS system sending dns request to 1.1.1.1 in encapsulated P2P traffic which was very unusual.
If you are a vendor or operate a POS system and require an audit call us. We have more experience dealing with malware than some of the largest antivirus firms. To protect your point of sales equipment from allowing this type of activity we recommend hardware based firewall network interface cards from Intel and our OS level shim to protect the POS hardware and our X-Gateway Hardware Firewall to detect and alert you to any activity and manage your Intel cards, Switches, Firewalls and IDS/IPS systems. The X-Gateway will provide customized rule sets, ACL's and Firewall Rules for all of your network devices and allow management from a single web based interface. Our Compliance Framework ensures that you will pass your audit, the first time!
Trust the leaders in this space and find out why 98% of our clients pass their audits after initiating our security model.
SLC Security Services LLC can be reached at (919)441-7353 or www.slcsecurity.com.
One of the interesting things to note is that of the affected hosts we published earlier this month nearly half of their networks are still sending data through 8 hub locations in which we were able to analyze traffic through one of our business partners that is a major Internet Service Provider in North America. We created and were able to get our partners to run a set of 10 snort signatures that we provided as well as a customized program to capture binary streams off the wire to analyze them for known MD5 matches without storing the data.
It seems that the vendors and corporations affected either do not have adequate detection in place or have failed to lock down their networks sufficiently to protect the infrastructure. In one case we even found a misconfigured POS system sending dns request to 1.1.1.1 in encapsulated P2P traffic which was very unusual.
If you are a vendor or operate a POS system and require an audit call us. We have more experience dealing with malware than some of the largest antivirus firms. To protect your point of sales equipment from allowing this type of activity we recommend hardware based firewall network interface cards from Intel and our OS level shim to protect the POS hardware and our X-Gateway Hardware Firewall to detect and alert you to any activity and manage your Intel cards, Switches, Firewalls and IDS/IPS systems. The X-Gateway will provide customized rule sets, ACL's and Firewall Rules for all of your network devices and allow management from a single web based interface. Our Compliance Framework ensures that you will pass your audit, the first time!
Trust the leaders in this space and find out why 98% of our clients pass their audits after initiating our security model.
SLC Security Services LLC can be reached at (919)441-7353 or www.slcsecurity.com.
Wednesday, October 29, 2014
SLC Security Auditing Framework Community Edition
SLC Security Services LLC announced today that we will be releasing our auditing framework as freeware. The free version of the software will only audit systems and will not include any of the lockdown capabilities of the software. The lockdown framework can be used to check computer policies and several community supported templates will be included in the free edition.
We anticipate making the free version of the software available sometime in the next week. All that we ask is that you let us know if you find any issues with the templates or the program itself. We are releasing version 2 community edition and will continue to release the software 1 version behind our production software. The production software has additional functionality such as:
The community edition does not require any authentication or Internet access to run. The software may also be run from a thumb drive.
Users can email templates they wish to share to soc@slcsecurity.com for inclusion in the commercial product. If your template is included in a future release we will give you a licensed copy of the software for your personal or professional use.
We anticipate making the free version of the software available sometime in the next week. All that we ask is that you let us know if you find any issues with the templates or the program itself. We are releasing version 2 community edition and will continue to release the software 1 version behind our production software. The production software has additional functionality such as:
- Lockdown - The ability to apply a template to a system
- Reports - Ability to run scheduled reports
- Auditing Documentation - Ability to deviate from a lockdown policy and documentation for auditors - A requirement if you do not meet the audit policies
- History Tracking - Prompts for information when an item changes - Like after a patch may change a setting
- Unlimited Use - The community edition will only audit the local machine. The community edition when run as an Administrator can audit remote systems
- Linux Support - Not available in the community edition
The community edition does not require any authentication or Internet access to run. The software may also be run from a thumb drive.
Users can email templates they wish to share to soc@slcsecurity.com for inclusion in the commercial product. If your template is included in a future release we will give you a licensed copy of the software for your personal or professional use.
Webex Trollers on the Prowl
We have been asked by a company to determine who has been dialing into their Webex. The Webex session showed a phone number but the person on the other end failed to identify themselves on the call.
We quickly advised the client to password protect the Webex sessions. Why wouldn't you password protect your Webex sessions in the first place? It's the same reason passwords are reused. Ease of access.
Brian Krebs previously reported on companies using Webex without passwords. His research indicated several dozen large companies were hosting meetings without passwords. I have actually logged into the wrong Webex on two occasions because of fat fingering meeting numbers when connecting to Webex. When this occurred I told the person(s) on the call that I had inadvertently connected to their meeting and promptly hung up.
One of the vulnerabilities we have noted is that companies that use hosted Webex services in many cases fail to password protect their meetings and this is something you should probably check for in your organization. It's not a big deal in most cases unless your discussing patients or unless you are a financial institution. However all businesses should be wary as we are pretty sure China and Russia may also troll Webex for companies in order to clean intelligence information.
If you notice somebody on your Webex that you can't identify your best option is to terminate the meeting and send out new invitations with a password protected Webex.
We quickly advised the client to password protect the Webex sessions. Why wouldn't you password protect your Webex sessions in the first place? It's the same reason passwords are reused. Ease of access.
Brian Krebs previously reported on companies using Webex without passwords. His research indicated several dozen large companies were hosting meetings without passwords. I have actually logged into the wrong Webex on two occasions because of fat fingering meeting numbers when connecting to Webex. When this occurred I told the person(s) on the call that I had inadvertently connected to their meeting and promptly hung up.
One of the vulnerabilities we have noted is that companies that use hosted Webex services in many cases fail to password protect their meetings and this is something you should probably check for in your organization. It's not a big deal in most cases unless your discussing patients or unless you are a financial institution. However all businesses should be wary as we are pretty sure China and Russia may also troll Webex for companies in order to clean intelligence information.
If you notice somebody on your Webex that you can't identify your best option is to terminate the meeting and send out new invitations with a password protected Webex.
The Learning Series: Lesson 1 Access Control List - Be specific, Be precise!
As many of you know this blog is staffed by volunteers and various individuals that have experience in computer forensics, network forensics, malware deconstruction, operating systems and other areas of expertise. SLC Security Services LLC (the sponsor of this blog) has been working to really define some of the goals of this project and one of the main items on the to do list was to provide some tutorials and write ups for network administrators and security staff to assist them with various items that may be of help when securing their networks and infrastructure.
One of the first things we notice during audits is that many corporates fail to use ACL's (access control list) effectively. When properly used and ACL may mean the difference between simply having a single machine compromised and have customer data stolen. I think we all can agree that rebuilding a single system is a better use of company resources than rebuilding an entire site or multiple sites and ACL's are one way to ensure that a simple exploited system does not result in a much larger disclosure or compromise of PHI/PII or credit card data.
When we audit most companies one of the first things we usually notice in about 90% of our audits is that administrators rarely if ever setup the correct ACL's on their systems. ACL's are a last line of defense in ensuring that even if a box is compromised that the data residing on that system cannot leave your infrastructure without you knowing about it. In about 70% of audits we have performed over the last year we have identified either incorrectly implemented ACL's, no ACL's in place at all or a major lack of understanding of the corporate network layout so ACL's are implemented only to block specific items.
Let's take a POS example of one place that ACL's should ALWAYS be implemented. POS systems by their design only have to communicate over the network to a few different servers. You would want to allow only the communication from the POS system to only the system and services required for operation and everything else should be blocked. One recent remediation after a compromise indicated that the traffic leaving the network was being sent out over the HTTPS protocol to the Internet through a proxy server that was setup externally. There were several places in which an ACL would have stopped an automated or hacker dead in their tracks had the proper ACL's been implemented on the network switch and router that was sitting between the POS system network and the Internet. The POS system in this case had a VPN client enabled on it that was an SSL VPN so blocking HTTPS entirely would not have worked but restricting HTTPS traffic with an ACL to the single host that the POS system needed to talk to would have closed those ports and not allowed the credit card data to leave the POS network. The POS system needed only to talk to 3 other IP addresses on 2 other services for proper operation. The first question we ask was why there were no ACL's on the network switches and the customers response was we didn't feel it was neccesary.
After the audit I can tell you that every location is not secured with the proper ACL's. Had the ACL's been implemented from the start this client would not have had to notify their customers of the breach and we would not have had to go in a reverse engineer a pretty nasty attack.
Some general rules:
1. Only allow these systems to talk to known systems required for proper operation. Block everything else.
2. Use multiple layers of ACL's on switches, routers and firewalls. This will ensure that if one device is compromised that there are backups to prevent traffic from leaving the network that is not authorized.
3. Know what traffic is going where. Open up services one at a time and only for the required network destinations. There should be no blanket rules allowing HTTP for example. Why would a POS system need to access the Internet? It doesn't and if it does it would only access a vendor site for updates so only allow that single system to get to the vendor sites for updates and block HTTP access to everything else.
4. Block anything not being used. Deny should be the default rule with all ACL's. Sure it takes time to build complicated ACL's in your network but it helps to keep your network secure and your machines from talking to machines that are not authorized.
We hope you have gotten something useful out of this article. Feel free to comment or ask questions and we will try and help individuals and answer any questions you may have.
This article was written by Kevin Wetzel lead investigator for SLC Security Services LLC. Mr. Wetzel has been an investigator for over 20 years and has specialized in computer forensics, private fraud investigations and computer security services for corporations, government and individual clients. Mr. Wetzel is a member of SLC Security Services LLC and is a contributor to this blog.
One of the first things we notice during audits is that many corporates fail to use ACL's (access control list) effectively. When properly used and ACL may mean the difference between simply having a single machine compromised and have customer data stolen. I think we all can agree that rebuilding a single system is a better use of company resources than rebuilding an entire site or multiple sites and ACL's are one way to ensure that a simple exploited system does not result in a much larger disclosure or compromise of PHI/PII or credit card data.
When we audit most companies one of the first things we usually notice in about 90% of our audits is that administrators rarely if ever setup the correct ACL's on their systems. ACL's are a last line of defense in ensuring that even if a box is compromised that the data residing on that system cannot leave your infrastructure without you knowing about it. In about 70% of audits we have performed over the last year we have identified either incorrectly implemented ACL's, no ACL's in place at all or a major lack of understanding of the corporate network layout so ACL's are implemented only to block specific items.
Let's take a POS example of one place that ACL's should ALWAYS be implemented. POS systems by their design only have to communicate over the network to a few different servers. You would want to allow only the communication from the POS system to only the system and services required for operation and everything else should be blocked. One recent remediation after a compromise indicated that the traffic leaving the network was being sent out over the HTTPS protocol to the Internet through a proxy server that was setup externally. There were several places in which an ACL would have stopped an automated or hacker dead in their tracks had the proper ACL's been implemented on the network switch and router that was sitting between the POS system network and the Internet. The POS system in this case had a VPN client enabled on it that was an SSL VPN so blocking HTTPS entirely would not have worked but restricting HTTPS traffic with an ACL to the single host that the POS system needed to talk to would have closed those ports and not allowed the credit card data to leave the POS network. The POS system needed only to talk to 3 other IP addresses on 2 other services for proper operation. The first question we ask was why there were no ACL's on the network switches and the customers response was we didn't feel it was neccesary.
After the audit I can tell you that every location is not secured with the proper ACL's. Had the ACL's been implemented from the start this client would not have had to notify their customers of the breach and we would not have had to go in a reverse engineer a pretty nasty attack.
Some general rules:
1. Only allow these systems to talk to known systems required for proper operation. Block everything else.
2. Use multiple layers of ACL's on switches, routers and firewalls. This will ensure that if one device is compromised that there are backups to prevent traffic from leaving the network that is not authorized.
3. Know what traffic is going where. Open up services one at a time and only for the required network destinations. There should be no blanket rules allowing HTTP for example. Why would a POS system need to access the Internet? It doesn't and if it does it would only access a vendor site for updates so only allow that single system to get to the vendor sites for updates and block HTTP access to everything else.
4. Block anything not being used. Deny should be the default rule with all ACL's. Sure it takes time to build complicated ACL's in your network but it helps to keep your network secure and your machines from talking to machines that are not authorized.
We hope you have gotten something useful out of this article. Feel free to comment or ask questions and we will try and help individuals and answer any questions you may have.
This article was written by Kevin Wetzel lead investigator for SLC Security Services LLC. Mr. Wetzel has been an investigator for over 20 years and has specialized in computer forensics, private fraud investigations and computer security services for corporations, government and individual clients. Mr. Wetzel is a member of SLC Security Services LLC and is a contributor to this blog.
Peerblock Update
We have once again rolled out a huge update to our peerblock list. It's probably a good time to force your peerblock to force an update from our servers.
Customer have already been updated automatically.
Customer have already been updated automatically.
Friday, October 24, 2014
Today's Peerblock Update
If you are updating your peerblock from our servers you may wanna force an update today. This will protect you from several nasty malware variants. Our clients were already updated earlier today. Have a great weekend everybody!
Sunday, October 19, 2014
How external indicators can help investigators confirm an intrusion - A look at UPS
One of the worst things that we have noted recently is many companies complain when their domains and IP information shows up on blacklist. They are quick to contact you to get their entries removed but not so quick to take an in depth look at why they ended up on the blacklist in the first place.
One particular incident that comes to mind is the recent hacking that occurred at UPS store locations. About 10 days prior to the incident we started seeing UPS store locations on our blacklist. We did not know why they were showing up at first but it would become very clear much later. These host were attacking other third party entities and we started getting reports of all sorts of possible issues from port scans, spam, malware hosting, brute force attacks and other reports of malicious intent from the UPS store locations. At the time neither UPS or our organization realized what was occurring. All we noted was an uptick in activity from UPS store locations. Without hesitation we started seeing UPS and related domains showing up on blacklist and malware identification sites.
Keep in mind now that this was a full 10 days before UPS admitted that their store locations were compromised when we first noted the activity. We cannot go into the methodology we use to block or not block a domain but we can tell you that out of 174 data points we started seeing UPS on more and more our sources and our automated system finally blocked UPS domains once our threshold was met.
Immediately customers started complaining about not getting delivery notifications and not being able to access UPS resources. Many customers chose to unblock UPS not knowing that they were opening up themselves to additional threats. Some customers did not realize that farther attacks were coming. When the attacks came they were caught off guard.
This incident brought to light the problem that business owners are facing in securing their infrastructure. The balance between being able to function and being able to function during a security incident. Several of the companies that white listed UPS contacted us after the fact for information even though we have sent out an advisory prior that outlined the problem, and what was being done about it.
Predictive Algorithms
The key to knowing what is happening in advance of a threat is recognizing the symptoms. While we had no visibility into UPS directly as they are not a customer we did have visibility into 178+ other sources of information that yielded clues as to what was occurring. It seems that every time there is a breach there are certain tell-tale signs that are common. By looking for these signs we are able to easily make a determination on what the problem is at an organization that we don't have direct visibility into.
So what other companies in this space do similar things? One company that comes to mind is Cyveillance. Cyveillance is very good about scouring data sources and notifying you of information that pertains to your particular company or organization. What they are not good at is predictive analysis to determine what may happen. Cyveillance simply notifies you after the fact whereas we are notifying companies of activity prior to the issue becoming public. By noticing activity ahead of time we are able to notify the company much quicker as the indicators are coming in real-time into our intelligence platform.
One company that does have insight into predictive analysis would be Dell SecureWorks (DSW). DSW actually undertakes passive monitoring (similar to what we do) when they are alerted to an issue. They are very good at things like taking care of botnet issues, malware propagation and virus deconstruction. We do many of the same types of investigations but we do it based on data that we are able to access outside organizations. Our exact methods are not being disclosed but we will tell you that we utilize open source and do analysis on common elements such as domain names, IP addresses and MD5 hashes of suspected hackers, networks or files.
Getting notified of problems before there is an issue is what our system is designed to do. Utilizing open source software means anybody that knows how to extract entity information from feeds, build indexes on occurrences based on information of interest and creating alerting, analysis and forwarding technology to get the alerts in the hands of an analyst. The additional piece of this is providing feeds of information to your customers in which they can determine for themselves if something such as the number of news articles on a topic is high, or the number of external entities reporting problems from the companies address space has moved outside of their normal baseline.
We won't give you the secret's to how the system operates but we can tell you that it is operating based on some very unconventional analysis in advanced distributed and cloud computing environments specific to the task at hand.
So organizations we ask you to keep tabs on what others are reporting on your organization and try and understand why. There may be keys and clues to problems out there that you really should know about. Realize the the US Government contacted UPS first to alert them to an issue. The happened 9 days after UPS first appeared on our block list.
Conclusion
So understand that in the case of UPS we were correct to block them. We knew something wasn't quite right from the data that we were analyzing from our feeds. Before removing an entity from a blacklist make sure you understand the who, what, when, where and how they were put on the list in the first place. Without knowing these key indicators you can't really make an informed decision on the appropriate action to take. If all looks good you can take them off of your block list but make sure you understand the risk in doing so.
References:
http://www.cnet.com/news/the-ups-store-is-hacked-user-data-possibly-compromised/
http://www.pcmag.com/article2/0,2817,2463826,00.asp
http://www.entrepreneur.com/article/236714
One particular incident that comes to mind is the recent hacking that occurred at UPS store locations. About 10 days prior to the incident we started seeing UPS store locations on our blacklist. We did not know why they were showing up at first but it would become very clear much later. These host were attacking other third party entities and we started getting reports of all sorts of possible issues from port scans, spam, malware hosting, brute force attacks and other reports of malicious intent from the UPS store locations. At the time neither UPS or our organization realized what was occurring. All we noted was an uptick in activity from UPS store locations. Without hesitation we started seeing UPS and related domains showing up on blacklist and malware identification sites.
Keep in mind now that this was a full 10 days before UPS admitted that their store locations were compromised when we first noted the activity. We cannot go into the methodology we use to block or not block a domain but we can tell you that out of 174 data points we started seeing UPS on more and more our sources and our automated system finally blocked UPS domains once our threshold was met.
Immediately customers started complaining about not getting delivery notifications and not being able to access UPS resources. Many customers chose to unblock UPS not knowing that they were opening up themselves to additional threats. Some customers did not realize that farther attacks were coming. When the attacks came they were caught off guard.
This incident brought to light the problem that business owners are facing in securing their infrastructure. The balance between being able to function and being able to function during a security incident. Several of the companies that white listed UPS contacted us after the fact for information even though we have sent out an advisory prior that outlined the problem, and what was being done about it.
Predictive Algorithms
The key to knowing what is happening in advance of a threat is recognizing the symptoms. While we had no visibility into UPS directly as they are not a customer we did have visibility into 178+ other sources of information that yielded clues as to what was occurring. It seems that every time there is a breach there are certain tell-tale signs that are common. By looking for these signs we are able to easily make a determination on what the problem is at an organization that we don't have direct visibility into.
So what other companies in this space do similar things? One company that comes to mind is Cyveillance. Cyveillance is very good about scouring data sources and notifying you of information that pertains to your particular company or organization. What they are not good at is predictive analysis to determine what may happen. Cyveillance simply notifies you after the fact whereas we are notifying companies of activity prior to the issue becoming public. By noticing activity ahead of time we are able to notify the company much quicker as the indicators are coming in real-time into our intelligence platform.
One company that does have insight into predictive analysis would be Dell SecureWorks (DSW). DSW actually undertakes passive monitoring (similar to what we do) when they are alerted to an issue. They are very good at things like taking care of botnet issues, malware propagation and virus deconstruction. We do many of the same types of investigations but we do it based on data that we are able to access outside organizations. Our exact methods are not being disclosed but we will tell you that we utilize open source and do analysis on common elements such as domain names, IP addresses and MD5 hashes of suspected hackers, networks or files.
Getting notified of problems before there is an issue is what our system is designed to do. Utilizing open source software means anybody that knows how to extract entity information from feeds, build indexes on occurrences based on information of interest and creating alerting, analysis and forwarding technology to get the alerts in the hands of an analyst. The additional piece of this is providing feeds of information to your customers in which they can determine for themselves if something such as the number of news articles on a topic is high, or the number of external entities reporting problems from the companies address space has moved outside of their normal baseline.
We won't give you the secret's to how the system operates but we can tell you that it is operating based on some very unconventional analysis in advanced distributed and cloud computing environments specific to the task at hand.
So organizations we ask you to keep tabs on what others are reporting on your organization and try and understand why. There may be keys and clues to problems out there that you really should know about. Realize the the US Government contacted UPS first to alert them to an issue. The happened 9 days after UPS first appeared on our block list.
Conclusion
So understand that in the case of UPS we were correct to block them. We knew something wasn't quite right from the data that we were analyzing from our feeds. Before removing an entity from a blacklist make sure you understand the who, what, when, where and how they were put on the list in the first place. Without knowing these key indicators you can't really make an informed decision on the appropriate action to take. If all looks good you can take them off of your block list but make sure you understand the risk in doing so.
References:
http://www.cnet.com/news/the-ups-store-is-hacked-user-data-possibly-compromised/
http://www.pcmag.com/article2/0,2817,2463826,00.asp
http://www.entrepreneur.com/article/236714
Subscribe to:
Posts (Atom)