PEN Consultants, LLC https://penconsultants.com/home Rock Solid Security - Mt. 7:24 Sun, 20 Sep 2020 21:23:26 +0000 en-US hourly 1 https://penconsultants.com/home/wp-content/uploads/2019/03/cropped-logo-32x32.png PEN Consultants, LLC https://penconsultants.com/home 32 32 Your Schema is Showing https://penconsultants.com/home/your-schema-is-showing/?utm_source=rss&utm_medium=rss&utm_campaign=your-schema-is-showing https://penconsultants.com/home/your-schema-is-showing/#respond Sun, 20 Sep 2020 21:00:34 +0000 https://penconsultants.com/home/?p=3265 Your Schema is Showing Here’s a look at the results from our recent effort analyzing GraphQL API endpoints across the web, and the percentage of those endpoints that allowed an unauthenticated user to view the query & data schema. The intent of this article is to address the implications of […]

The post Your Schema is Showing appeared first on PEN Consultants, LLC.

]]>
Your Schema is Showing

Here’s a look at the results from our recent effort analyzing GraphQL API endpoints across the web, and the percentage of those endpoints that allowed an unauthenticated user to view the query & data schema. The intent of this article is to address the implications of allowing this schema to be retrieved, similar technologies that allow access to their schema, what can be done about it, and the trend of those who have prevented such a disclosure.

What is GraphQL?

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

Source: https://graphql.org/

For more details about GraphQL, the reader is encouraged to view: https://graphql.org/learn/

The Search

During the months of August and September 2020, we scanned the top one million domains looking for GraphQL API endpoints at a few well-known paths – the most common being an HTTP POST to /graphql. Although there are many GraphQL instances with non-common paths, our common paths search still identified and successfully communicated with 3,824 GraphQL endpoints.

Introspection – Dumping the Schema

Many of the discovered GraphQL API endpoints allowed us to retrieve the schema, which describes the data types and structure, query syntax, directives, entry points, etc. It would be comparable to what one would get if dumping a MySQL DB schema along with routines (ex. stored procedures). This information was obtained by leveraging a built-in GraphQL feature known as introspection. More about introspection can be viewed here: https://graphql.org/learn/introspection/

The following is an example of a introspection query against a well-known cybersecurity organization:

Notice that we retrieved almost 2 MB of schema in the JSON response. When that JSON based schema is “beautified”, it is 140,565 lines describing, in complete detail, how to interact with the API, including default and user generated/set metadata values for every aspect of the schema, such as a description, depreciation status, etc.

Introspection Risk

By itself, an unauthenticated user gaining access to the API schema through GraphQL introspection is an informational level concern. However, without this information, it would be more difficult, maybe impossible, to formulate some requests against the GraphQL endpoint. Anything one can do to make it harder for an attacker to acquire this type of information reduces the likelihood and impact of an attack.

“Security through obscurity” is not an effective security strategy. But, obscurity, in conjunction with proper access control, adds an extra layer of burden to an attacker. There is simply no need to expose this level of detail except for the limited occasions a developer or integrator needs to see it. Just like you would not expose a database schema or network architecture diagram to an unauthenticated/unauthorized user, you should not expose this schema.

Commonality

Of the 3,824 GraphQL endpoints we found and interacted with, 94% allowed introspection! Conversely, 6% of endpoints had it disabled. Of that 6%, nearly all of them appeared to be using the Apollo GraphQL platform, which has introspection disabled by default in production. Kudos to Apollo Graph for making this the default setting!

Other Risks

Metadata: Another aspect to consider with exposed schema is the potential for future code updates to inadvertently include sensitive information in the metadata (ex. description field), or in the schema itself, that would then be publicly accessible. Data is sometimes carelessly placed in fields, such as metadata fields, by a developer who is assuming it is “server side only,” when in fact it is accessible by an external, unauthenticated user.

Field suggestions: Some GraphQL instances not only verified whether a field in our query was valid or not, but also gave suggestions to us when one was wrong (i.e. fuzzy matching).

Note: For the endpoints that did not have this field suggestion feature, common named field names were still easy to verify and enumerate.

Reduce Risks

Here’s what you can do to mitigate some of the information gathering attacks shown above:

  • Disable introspection in production or in any instance that is publicly accessible
    • As mentioned above, Apollo Graph hides the schema by default (i.e. introspection is disabled). If you are using Apollo Graph, or another platform that has a built-in capability to disable introspection, it is likely as simple as changing a boolean value in your configuration.
    • Note: Introspection can be left enabled in dev/test, where developers and integrators are working, with minimal comparative risks.
  • If possible, disable field suggestions.
    • It is unlikely a developer or integrator will benefit much from this feature, however, it gives an attacker a huge advantage.
    • Note: Some GraphQL solutions do not yet support this feature.
  • To defend against a more advanced and persistent attacker, consider changing field names to unique names that are not easily guessed through field brute force enumeration.
    • Example: Instead of “userId”, use something such as “[companyName]_userId”, or even “userId_nnnn” where “nnnn” is a unique, but static, number for each field.

Similar Technologies

GraphQL is not the only technology with these issues; there are other similar API frameworks that expose their schema and have similar risks. This list is not inclusive, but is intended to give a few examples:

Conclusion

If you interested to know how your API and web services would perform against these types of attacks, but do not have the expertise or resources to do so, we would love to speak with you. Contact us today!

Featured image is a derivative work from the following images: mcmurryjulie @ https://pixabay.com/vectors/database-schema-data-tables-schema-1895779/

The post Your Schema is Showing appeared first on PEN Consultants, LLC.

]]>
https://penconsultants.com/home/your-schema-is-showing/feed/ 0
Building a Security Testing Business https://penconsultants.com/home/building-a-security-testing-business/?utm_source=rss&utm_medium=rss&utm_campaign=building-a-security-testing-business https://penconsultants.com/home/building-a-security-testing-business/#respond Fri, 15 May 2020 23:23:32 +0000 https://penconsultants.com/home/?p=3157 Building a Security Testing Business I am often asked, “How did you get started with your security testing business?” “What are some lessons learned?” “What are your current challenges?” I have been asked enough times that I decided to post my thoughts in blog format. How did you decide it […]

The post Building a Security Testing Business appeared first on PEN Consultants, LLC.

]]>
Building a Security Testing Business

I am often asked, “How did you get started with your security testing business?” “What are some lessons learned?” “What are your current challenges?” I have been asked enough times that I decided to post my thoughts in blog format.

How did you decide it was the right time to take the step from W-2 employment to self-employment?

It was God…plain as day. Here’s the long version…

In 2009/2010, while working at NSA, I started volunteering my time to provide IT support to a few local churches and private schools. As that side hobby/community service grew, we came up with the name “PEN Consultants” in 2014, and have been doing business under that name ever since. In addition to serving the community with my spare time, I was very much involved in “research,” AKA hacking. Looking back, there are plenty of activities I would do differently now. More on that progression here: https://penconsultants.com/personalEthics

When I knew it was time to leave NSA (that’s a story for another time), we weren’t quite sure if it was good timing to pursue PEN Consultants as a fulltime job, or if it would ever be a good time. I was hesitant, so I applied to work for USAA in 2014 until we knew the direction we should go and the right timing. After receiving a CJO from USAA, and during the background check process, I disclosed the fact that I had this side company and was heavily involved in research activities on personal time. My soon-to-be-supervisor described that background check process as one of the lengthiest he could remember, due to the ethics portion of the background check. The decision finally came back, I had to agree to the following terms:

  • Could not perform side work on company time
  • Could not use company resources when performing the side work
  • Could not utilize any confidential, proprietary, or otherwise protected, information obtained exclusively from USAA outside of USAA
  • Could not “recruit” other USAA employees for the work
  • Could not perform work for other FIs (financial institutions)

Other than a small disagreement with that last stipulation, those were all no-brainers and things I would have avoided anyway. It was easy to agree to those terms, so I soon found myself working for the best FI in the industry, USAA! As time went on, USAA became less friendly to employees performing research and consulting type activities on personal time. Examples: USAA demanded patents for things done on personal time, raised strong objection to research performed against a vendor product they use (Note: USAA is large…they use all the well-known vendors), required prepub review for blogs written on personal time based on personal research, wanted to limit the hours of work outside of USAA as to not impact on-the-clock performance, etc.

To be fair to them, part of these changes were likely due to an ignorance on their part (initially agreeing to things they had no prior working knowledge of), increased regulation, being such a large company with a ton of processes and expectations, and them not knowing how to get comfortable with the security research space. I won’t speculate other reasons that may have had a factor, but I have heard a few. In 2018, I spearheaded an effort to find a reasonable middle ground between HR/legal/ethics and we, the researchers. I called the effort “Cybersecurity Moonlighting,” received feedback from all/most of the parties involved (many dozens), and grouped those into “must haves”, “like to haves”, and “things for consideration”. At the same time, my wife and I were praying – a lot – about our PEN Consultants side business, whether the timing was right to do it full-time. Because I’m hard of hearing – physically and spiritually – I asked God for a clear, unmistakable sign.

Just before my “Cybersecurity Moonlighting” effort got sent to legal/HR/ethics/etc. for final review so it could make its way into policy, USAA formally reprimanded me for work I was doing on the side. Work I had permission to do! Additionally, they set a policy that all outside activity had to be approved through legal…on an individual basis – every blog post, every code release, every voluntary consulting engagement, each bug bounty find. Everything! The policy also stated that no outside research would be authorized against any vendor USAA uses, which essentially meant nothing against any well-known vendor would be approved.

Given that I do not prefer to be reprimanded for things I have authorization to do, and that security research is not only core to my being, but also core to my ability to remain highly skilled in this field, I submitted my resignation within hours of that decision. I agreed to stay on not only for the customary two weeks, but for as long as they needed me. The only caveat I gave them for me staying on longer was that I could not maintain compliance with the new policy during that time. Interestingly enough, USAA went the other way with it – I was immediately terminated when I submitted my resignation (accounts terminated within minutes). Side note: No infoSec employee before me had been denied a 2-week period to say goodbye and close things down gracefully.  When submitting this article for prepub to USAA, I was told only one other employee has been terminated immediately after notice of resignation, and it is certainly not the standard.

I have heard it said my immediate termination was likely due to the fact that I, being the red team lead, probably knew about more vulnerabilities in USAA systems than just about anyone else and was seen as a risk if I were kept on for an additional 2 weeks. In my case, I would never consider any sort of retaliation, but given the feelings I had at that time, I would totally understand others not maintaining certain ethical (and legal) standards.

The point of this long answer is that I asked God for a very clear and direct sign, and He gave it to me. It literally could not have been a clearer answer to my “Should I go out on my own?” prayer.

Note:

  • I still have a high regard for USAA and even mentor/coach people on how to get on there.
  • The majority of the people involved had nothing against me personally, or researchers in general. For the most part, everyone was simply trying to “do the right thing”.  In fact, most everyone on the infoSec side of things (all the way up to, and including, the SVP), went to bat for me on multiple occasions, provided me with top cover for some prior events that scared legal/ethics, and engaged the corporate level policy makers on more times than I’m even aware.  I will forever be grateful to those who supported, encouraged, and mentored me while I was there..  I still have ties to people at many levels of USAA, and even eat lunch with one of the execs on a quarterly basis.
  • It’s simply a matter of USAA not being a compatible employer for those wishing to perform certain types of research activities on personal time. If you want to perform all of your infoSec/cyberSec work on-the-clock and care little about doing it on personal time, I would highly encourage you to apply for work there (https://www.usaajobs.com/). Feel free to reach out and I’ll even offer advice on how to get in and who to contact.

How did you form the legal entity you’re working under?

There are two primary places to go to for this: a lawyer or an online legal service (ex. LegalZoom, Rocket Lawyer). Due to costs, we went with the latter.

As far as going LLC vs Corporation vs some other legal entity, we went the LLC route for now since we are a small startup. The overhead and costs of going the corp route just didn’t make sense at this time, but may in the future. You certainly need to obtain legal advice on that if you are unsure.

What type of insurance coverage did you start out with?

It all depends on your risk profile which should be discussed with an insurance professional. I recommend checking here: https://www.daveramsey.com/elp/insurance

At minimum, you are going to want General Liability and Professional Liability (AKA errors and omissions). Although most minimum state requirements, if any, are likely lower, 1 million dollars per incident with 2 million aggregate for each policy seems to be typical for small firms (0-5 employees). This will run you around $2,000-3,000 per year. If you get up to 10-15 employees, you likely want to increase the aggregate as a function of the number of employees and amount of business you are performing.

You will also want to look into Cyber Liability if you plan to store any amount of client data. This will easily add another $2,000 to your policy costs (costs are increasing rapidly every year). Note: we avoid storing much more than screenshots of client data, which themselves are almost immediately redacted. I would certainly advise against exfilling client data to the greatest degree possible. During pentests and red team engagements, we even try to avoid staging client data on another internal host. If we come across credit card data, we will substitute fake CC data in before proving exfil (for example). In some cases, the data will fall under a regulation (ex. PCI, HIPAA, etc.) that specifically states data cannot be placed on an unapproved system. Assuming your attacker systems are not PCI/HIPAA/etc. certified, you would likely be in violation if you even attempted it.

There are other coverages, such as general umbrella coverages, which may be beneficial as well. So far, it hasn’t made sense for us to go with these as our risks simply are not there yet.

With all that said, one interesting thing you will occasionally come across is a client requesting more coverage than what your current risk profile requires. If it means adding another $1,000 of insurance to get a $15,000 job, that may make sense. When your client is asking for coverage that costs more than the invoiced amount for the job, that probably doesn’t make sense. What that percentage is for you may look different than ours. For us, we are willing to add additional insurance so as long as it does not cost more than 10% of the testing fee, or 20% if it’s something that another client has asked about before. Note: less than 10% of our clients even ask for proof of coverage at all, much less ask for more coverage. We are willing to lose clients in order to keep our costs low.

What is the hardest part about having your own company?

The bumps in the road are much more obvious. Working for someone else, especially a larger organization, you are nearly oblivious to those bumps as someone else is taking care of them.

On that note, you end up having to become a jack-of-all-trades, and not just a technical one. For someone with a technical and business background, this may not be a struggle. For me, a full blown introverted techy with zero business experience, the business aspects are literally some of the hardest things I’ve done in my life. What should be simple ends up becoming very complex and uncertain because everyone has their own way of doing something based on the business philosophy they were taught. I have found that trying to determine what decision is best for you is hard.

How do you find clients?

I’ll break that down into five areas:

Referrals

The best clients come by referrals, no question about it. It’s simple, clean, cost effective, efficient, a better experience (for both us and the client), etc. Before we have even heard of the client, someone is telling them about our services, how good a job we’ve done for them or someone they know, our credibility, etc. By the time the client makes it to us, they are already 99% convinced they should go with us. This is so valuable to us we give $250 cash, or $1,000 testing credit, for a referral: https://penconsultants.com/referral.

Another interesting way we have acquired clients is through other pentest vendors. It sounds odd, but what usually happens is a smaller client (ex. $100 million credit union or small startup software development company) engages a medium/large sized pentest firm for needed testing. Those firms are unable to perform even the smallest jobs for less than $10,000 to $15,000 due to their overhead and hourly rates. In many cases, that is the client’s entire IT security budget for the year. Since the large testing firms know they can never meet that need, they send them to smaller firms, like us.

Partnerships

The next best set of clients come from partnerships we have with other IT service providers – virtual CISOs, managed IT/security firms, vendors, etc.

Our preference, and the majority of our relationships, are just basic mutually beneficial referral relationships. Not only does this enable us to refer our clients to a trusted partner, but it also gives our partners a trusted security firm to refer their clients who are in need of quality security testing.

We occasionally enter into a subcontract service agreement with a prime and perform work for the client through the prime’s MSA. Our relationship with the client can be nearly identical to a direct relationship, other than the paperwork/payment is being handled through an intermediary (i.e. the prime). Subcontracted relationships can sometimes be fully subcontracted in that the client sees us as an employee of the prime and never sees “PEN Consultants” on emails, documents, etc. (i.e. white labeling). In the first 6 months, we worked under any/all types of subcontracting relationships because we needed to eat! Although we still enter into subcontract relationships on occasion, we no longer perform services under a white label relationship.

White labeling drawbacks to consider:

  • Overhead is too great (refactoring forms and reports into prime’s templates)
  • Communication is more complicated and error-prone (relaying everything through prime)
  • Our brand is never seen (a key factor in running a business is growing your brand)
  • Price is not optimal for the client (we charge for the extra overhead and the prime markups up even more)
  • Makes future work and continued retainer type work less likely (you are contractually forbidden from going direct)
  • etc.

Outsourced Sales

Another way to acquire clients is to outsource your sales efforts. In practice, this has proven difficult for the following reasons.

Cold calling: One type of outsourced sales is paying a sales firm for X hours per month (even up to full time) for an agent to call, email, connect with, etc. potential clients and try to convince them they need your services. Although we looked into this, we never went with one of these providers because everyone hates cold calls and that would just start things out on the wrong foot.

Commissioned sales: We have experimented with commissioned sales in a few different ways over the last year. The concept is simple – promise to pay someone X% for each client they get us connected with who signs a contract. The problem is, when that percentage is 10% (for example), it is impossible to find an experienced sales agent who is able to bring in a warm lead (warm lead = person has expressed interest, but no contract yet). The experienced sales agents work for 40-60% commission, just for a warm lead! I wish I was exaggerating, but I am not. We would have to double our pricing to make that work, which runs counter to our vision to remain the most affordable.

Direct Contact

Direct contact is essentially the same thing an outsourced sales team would do – a lot of cold calling and pulling on loosely connected threads to make connections with potential clients. The difference being we are doing it directly – no commission payouts, no intermediary, no sales pitches, etc.

Even though these are highly targeted, individualized, connection attempts utilizing a common bond (ex. previous employer, shared acquaintance, hobby, etc.), they have proven to be mostly ineffective at landing a client. We have made great efforts via email, phone, and LinkedIn. We are in the process of attempting mailers and in-person visits in our local region. TBH, we don’t expect that to be much more successful.

Bottom line: we are not sales and marketing people, so there’s close to zero chance of this working for us.

Marketing

Our marketing efforts are close enough to zero to say we don’t do marketing. As a techy working under management that frequently sent a “Hey, check out what I came across” message, I hated marketing, and that hate has transferred to our business. All evidence I’ve seen seems to indicate marketing is minimally effective compared to referrals and partnerships that can vouch for you.

Has the Coronavirus pandemic affected your business?

It has, for sure. It’s hard to say how much since, as of today, we are still in the middle of it. Our current estimate is about 20% client loss and 50% client postponements. We are only doing about 20-30% of the work we were before the government shut down private businesses. We are hopeful the majority of that will return.

The loss of life and people’s jobs is tragic. We can argue about what could have been avoided and who is responsible, but the bottom line is, it happened, it sucks, and people’s lives have been turned upside down. We are very fortunate to be debt free – both as a business and personally. That will enable us to ride out the storm a little better than some of the other firms.

How do you deal with an angry client?

Thankfully, we have not had an angry client as of yet. There have been a handful of occasions over the years where we negatively impacted a client’s network and it led to dropped VoIP based calls, network congestion, etc. But, because we provide real-time communication (https://penconsultants.com/informed), those types of issues are almost always identified and resolved within minutes. On one occasion, our testing knocked out the ability for the admins to gain remote VPN access until the appliance was bounced that evening. At most, a few clients may have become a little annoyed, but were understanding and forgiving.

In addition to offering a price match guarantee, we offer a satisfaction guarantee. If a client is ever unsatisfied, we would obviously do everything possible to resolve the issue.

The other part of it is we try to avoid demanding clients as demanding clients can often become angry clients. It’s pretty obvious a client will be demanding when they contact you and want a report on their desk by next week for a testing engagement that doesn’t even have a signed contract yet, much less started. Another warning sign we lookout for is a client that treats you like the proverbial red-headed stepchild from the get-go.

If we sense a bad match, we use a few undisclosed techniques to help the client realize we are not a good fit. We pour our heart and soul into what we do, and have no desire to work with someone who cannot appreciate that.

Do you have employees? How do you know when to hire?

We are a small startup family business. There are currently three people who work for PEN Consultants. Since those three people are under the same family unit from an IRS perspective, we are essentially a one-person firm.

With that said, just before the Coronavirus pandemic hit, we were already in pre-interview talks with a handful of candidates and planning to hire eminently. The future is uncertain now. It could be that we remain a small family business forever. Or, we may scale up to be a large firm. We are taking that one day at a time and seeing where it may lead.

Our metric was two full quarters of 60-80 hour per week workload before hiring. The closing of our country happened two weeks before pulling that trigger.

How hard was it to transition from red teaming back to pentesting?

This was one of the hardest things to cope with. But first, definitions: https://penconsultants.com/testingDiff

I greatly miss my five years of building and leading USAA’s red team and my nation state level exploitation at NSA. We infrequently get to perform either now due to the size and maturity of most of our clients. Social engineering (physical and remote) is about the extent of it so far, but the hope is to secure larger clients who will be in need of the level of red teaming I provided while at USAA, or the large focused research/dev effort comparable to my time at NSA.

Regardless, my experience has certainly given me a somewhat unique perspective on pentest findings. Many times a client provides previous pentest reports when we start the engagement – in some cases compliance requires it. More times than not, it is obvious the “pentester” simply ran a few tools and spit out a report without any consideration of actual likelihood of attack or considering anything outside of what the tool found.

Having been an attacker for so long, and playing the attacker at various levels, I am able to bring a much different perspective than your typical compliance-focused pentest. I feel, and we receive confirmation from clients, that we generally deliver a better prioritized list of findings. Examples: https://penconsultants.com/report

For our more mature clients, one service I like to push is our Technique Simulation service: https://penconsultants.com/redteaming. Even if the client is not ready for our Adversary Simulation service, nearly any client with even a basic detection capability can benefit from testing common attacker techniques to ensure their COTS solution is setup/configured optimally.

What percentage of testing vs consulting do you perform?

Our services are certainly weighted heavily towards testing and a detailed report. The recommendations portion of the report would obviously be a form of consulting. Approximately one-third of the hours spent on an engagement is, what I call, post-core testing. The most obvious task during that phase is writing the report, but also includes some additional adhoc testing (i.e. “oh, what if I did X”). The reason the report takes so much time is because the recommendations are custom tailored to the client. Example: depending on the level of access we have, we literally pull things like group policy and show the current config and what the config should be to prevent the attack demonstrated.

Additionally, there are often post-testing conference calls, debriefs, emails, etc. that drill into other angles of a finding and what the best route is for the client. We also provide a retainer service to our clients, branded as Cybersecurity Unlimited, which allows for those random adhoc consultations throughout the year. Details: https://penconsultants.com/cybersecurityUnlimited. Of the dozens of clients in a given year, less than a handful need/require that level of consulting. Given that I’m not a sales and marketing guy, I probably am just doing a poor job in offering that to clients. This type of service is one of the most beneficial for both us and the client – client has direct and immediate access to advice and small testing requests, and we get a more steady, albeit smaller, source of income.

Venture Capital money or loan to get started?

We are debt free – personally and as a company – and do not enter into debt for any reason. We live by the Dave Ramsey principles which are based on scripture. Since we have strong faith, we live according to the Bible’s teachings on debt – that the borrower is a slave to the lender (Proverbs 22:7).

Although it is easier, and may be perceived as more reputable to clients, to borrow millions of dollars and hit-the-ground-running is an enormous amount of risk compared to building the business slowly (debt free). Scripture aside, since a business is more likely to fail than succeed, it seems foolish to gamble on that risk.

Another benefit of growing slowly is the ability to develop your culture in a more true manner. With venture capitalist backed companies, for example, greed will inevitably drive certain decisions. We do not want to be like that. Our stated purpose is to help our clients and community…not to get rich. If we eventually make a lot of money, that might be fun. But, for now, we are just concerned with making enough to keep our family fed.

Are your rates too low?

In one word, “yes”, our prices are currently too low. They are so low, many mid (and certainly large) sized organizations question the quality of our work. Even though we post sample reports, offer client testimonials, post more details about our testing methodology than the firms they are likely using, etc., the fact that our prices, as of 2020, are still one third to half of the comparable service quality elsewhere, understandably causes concern.

Although we have been increasing our prices by 10% per quarter, we will likely never charge as much as the industry average does for comparable work. Our stated vision has been, and continues to be, “to be the most highly skilled, ethical, and effective security testing company in the industry, while remaining the most affordable”. We assure this with our price match guarantee.

Given our hourly rate (which is half of the industry average), our vast experience (more experience reduces testing time), and low costs overhead (no marketing, office, etc.), we should be able to remain the most affordable on the market forever.

Any pricing models that seem to have worked out well? Anything to avoid?

Our pricing model is something that sets us apart from most testing firms. For one, we post our pricing for typical small/mid sized engagements, which is nearly unheard of in this industry. In fact, it is rare to find a firm that is even willing to post their hourly rate. More about our pricing model, and transparency in general, can be found here: https://penconsultants.com/compare

At this time, most of our contracts are on a per engagement basis. Some firms will request a 3-engagement/3-yr contract from the get-go, or even a 3-yr with quarterly testing. Although we do offer substantial discounts for multi-year contracts, we do not feel that is fair to a client to be forced into it from the get-go. With that said, I certainly see the business benefits of doing so.

Do you talk about your faith with clients?

We certainly do not hide the fact that our business is run by Bible believing Christians. With that said, we have been the ones to bring up our faith exactly zero times in a client conversation. If a client asks a religious related question, we do not hesitate to answer it. On a handful of occasions, our client has wanted to venture off into a 30/45 minute conversation on faith, after the testing related conversations are over.

How do clients react to your faith and beliefs?

We are not aware of anyone that has been offended by our beliefs or anyone that has avoided our services due to our faith. As mentioned previously, it is not something we bring up unless a client does. If just the mere fact that we are Christian offends someone to the point they cannot do business with us, then they likely lack the tolerance of someone we would want to do business with anyway.

At the end of the day, our services are making people more secure, regardless of their religious beliefs or lack thereof. We are not a church; we are a security testing company.

Changes

  • 15 May 2020: Initial draft, sent relevant section to USAA for prepub review.
  • 16 May: A few additions based on USAA feedback – 1 (not 0) other infoSec employees have been immediately terminated after giving a 2-weeks notice, USAA’s processes and expectations were not as agile as one may hope for due to company size, and the fact that the disconnect really was not with the security team/leadership but more the corporate level policies and guidelines.
  • 16 May: Sent new version back to USAA for review.

The post Building a Security Testing Business appeared first on PEN Consultants, LLC.

]]>
https://penconsultants.com/home/building-a-security-testing-business/feed/ 0
HTTP Response Headers https://penconsultants.com/home/http-response-headers/?utm_source=rss&utm_medium=rss&utm_campaign=http-response-headers https://penconsultants.com/home/http-response-headers/#respond Wed, 06 May 2020 14:47:13 +0000 https://penconsultants.com/home/?p=3114 HTTP Response Headers While preparing for a monthly Lunch-and-Learn lesson for a client, I wanted to collect various examples of good, bad, faulty, and missing HTTP response headers. As is typical, I went a little overboard and collected all of the headers for the top one million websites. This article […]

The post HTTP Response Headers appeared first on PEN Consultants, LLC.

]]>
HTTP Response Headers

While preparing for a monthly Lunch-and-Learn lesson for a client, I wanted to collect various examples of good, bad, faulty, and missing HTTP response headers. As is typical, I went a little overboard and collected all of the headers for the top one million websites. This article will describe some interesting findings and the raw data collected, as well as provide other researchers with the script created and used.

The Script

The script is a simple multi-threaded python script that can easily collect the headers for one million websites in 24-48 hours, depending on your bandwidth and number of threads used.

Script Source: https://gitlab.com/J35u5633k/httpheaders_public

As is typical for our first-release version, there is almost no error checking or optimization. It got the job done that we needed it to do. Feel free to modify as needed – remove the allow_redirects, change the output format, etc.

In addition to the script, you will need a list of domains. I used: http://s3.amazonaws.com/alexa-static/top-1m.csv.zip

The Raw Data

The raw data from the top one million websites can be found here: https://drive.google.com/drive/folders/1gL0xTnN-12aXnPM4B0F4Mir7yXmSPk1-?usp=sharing

Before releasing the raw data, I made a few modifications:

  • removed all “Set-Cookie” values and replaced with 12-A’s
  • anonymized IPs, GEO coordinates, city names, etc.

If you need access to the data that was removed or anonymized, you will need to run the supplied script for yourself.

Interesting Findings

Most commonly seen headers

Usage of common security headers

Leaked private/internal IPs

Internal Hostnames

Sites with the most headers

Header values with one character per header

Some of the sites with 40+ headers have a misconfiguration causing a single character to be sent per line.

Debug Headers

Other sites with 40+ headers were due to debug headers.

Conclusion

If you would like PEN Consultants to provide your team with monthly training, or if you would like to discuss any of our testing services, we would love to speak with you. Contact us today!

The post HTTP Response Headers appeared first on PEN Consultants, LLC.

]]>
https://penconsultants.com/home/http-response-headers/feed/ 0
MFA Implementation Attacks https://penconsultants.com/home/mfa-implementation-attacks/?utm_source=rss&utm_medium=rss&utm_campaign=mfa-implementation-attacks https://penconsultants.com/home/mfa-implementation-attacks/#respond Sat, 25 Apr 2020 19:22:01 +0000 https://penconsultants.com/home/?p=3040 MFA Implementation Attacks Most Multi-Factor-Authentication (MFA) implementations do not protect your password from brute forcing or from account level DoS attacks. This article will demonstrate various attacks that exploit weaknesses found in nearly every industry Identity and Access Management (IAM) provider/solution as well as offer solutions on how to mitigate. […]

The post MFA Implementation Attacks appeared first on PEN Consultants, LLC.

]]>
MFA Implementation Attacks

Most Multi-Factor-Authentication (MFA) implementations do not protect your password from brute forcing or from account level DoS attacks. This article will demonstrate various attacks that exploit weaknesses found in nearly every industry Identity and Access Management (IAM) provider/solution as well as offer solutions on how to mitigate.

Note: This article builds on the previously released https://penconsultants.com/home/mfa-without-the-fud/

Remember the days when MFA protected authentication was a single step process? Your username, password, and MFA OTP were all provided on the same page, you would click Login, and either gain access or receive a generic “Login failed”.

You may still be using a system like this, but it is becoming less common. How times have changed.

Now, it is common for users to be prompted for their username and password only before clicking Login. The resultant message or page will either inform the user their credentials are incorrect, or, it will prompt them for their MFA OTP, send a push notification, or maybe require them to make physical contact with a hardware MFA token (ex. YubiKey). More user friendly, right?

The Security Implications

Since 2014, PEN Consultants has flagged this 2-step authentication process as a finding in our pentest and red team reports (in most cases), and, since 2018, I have been publicly raising awareness of the attacks it enables.

By acknowledging a pass/fail when entering a basic username/password combo, two vulnerabilities are created that allow an attacker to “bypass” MFA protection:

  • Account level DoS (Denial of Service)
  • Password compromise

Red Team

In our experience, typical MFA implementations are worthless at defending against the attacks shown here. Your mileage may vary.

Example #1 – Account DoS

The account level DoS attack should be straight forward to understand. The only prerequisites are:

  • a reachable authentication service – ex. external VPN, email portal, etc.
  • an account lockout policy – X failed logins == account lockout
  • username(s) – can typically be obtained in multiple ways (ex. timing attacks, well-known format + LinkedIn, brute forcing, etc.)
  • a script/tool – many script kiddie tools can perform this attack (ex. Hydra, Brutus, etc.) in addition easy-to-develop scripts

The attacker simply beats against the login service using known bad passwords until the account lockout threshold is reached. Once the account locks out, the legitimate user can no longer access their account until the unlock process is run (manually, or timed). Using a multi-threaded process to beat against all of the users’ accounts in parallel, an attacker can very quickly lockout all user accounts.

Insane mode: Using the same multi-threaded tool/script, and using multiple sources/proxies (ex. leased botnet), an attacker can keep the user accounts locked out by operating faster than the victim can unlock them and avoid simple nACL based mitigations that may be tried.

Insane mode++: If the external web service uses the corporate Active Directory (AD) in the back-end for authentication, the attacker can do more than just lockout the web app accounts. In many cases, all internal AD user accounts can be locked out through the external web service from an external, unauthenticated attacker! If following the attack recommendations above, the victim will not be able to stop this attack without disabling the web service. If the web service is supporting remote work operations, the victim will suffer greatly until they implement proper mitigations (see Blue Team section).

Example #2 – Password Compromise and Reuse

The attacker can leverage the 2-step authentication process by exploiting the fact that the first step verifies the user credentials (username + password). Assuming the attacker remains below any account lockout thresholds, or other brute force mitigation measures, the credentials can theoretically be compromised without knowing or having access to the MFA.

For more information on predicting passwords with a great deal of accuracy, see this article: https://penconsultants.com/home/forced-password-rotation-incrementing/

Once the password is compromised, the attacker can exploit the fact that many users use the same password across many, or even all, of their other accounts – other work related accounts, email, bank, online marketplaces, entertainment services, etc. Although the victim’s system may mitigate an account-take-over (ATO) because of MFA, the user’s other accounts may not be protected and can be accessed using those same compromised credentials!

There is a good chance the web app developer has taken the stance of, “Users should not be using the same password across all of their accounts” as a defense for their poorly configured web app. Reality is many users do reuse passwords, and there will likely be no significant change in that regard anytime soon.

Example #3 – Brute Force the MFA

Another scenario we come across often is after compromising the user’s credentials (as in Example #2) and making it to the MFA verification step, the MFA check has no brute force protections, even when the first step does. When the attacker finds this weakness, simply brute force the MFA one-time-password (OTP) and gain access to the account!

In many cases, the OTP will be a moving target (ex. changes every 60 seconds). But, when you are brute forcing at wire speed, this only prolongs the inevitable ATO.

Example #4 – Social Engineer the MFA

Instead of brute forcing the MFA OTP (as in Example #3), the attacker can simply ask the user for the OTP through some form of social engineering – phone call, SMS, etc. It is not incredibly difficult to convince a non-technical user to give up this information in practice. And, let us not forget the “user friendly” push notification forms of MFA. There is a good chance the user will hit “authorize” without the attacker even having to ask because the user is conditioned to do so when it pops up.

Blue Team

Every one of the attacks described can be virtually eliminated with one simple change – check the MFA prior to the password, especially if multiple failed login attempts result in an account lockout.

If your users use some form of SMS OTP or push notification MFA, this could introduce another problem – users being bombarded with SMS or push notifications. In this scenario, you would want to verify the password in the back-end first with these important caveats:

  • Ensure the response in the UI/API is the same regardless of whether the credentials were valid. You want to ensure the UI/API does not confirm a valid/invalid password directly or through timing differences. Example: prompt for the OTP or display the “sent notification/OTP” for both failed/valid.
  • Do not actually send the OTP or push notification to the user unless the password is valid. If it is an attacker, they will assume it is being sent. If it is the legit user, they will receive what is needed.

Whichever direction you go with, you want to ensure you have sufficient monitoring in place to detect any brute force attacks so you can respond accordingly. In addition to an admin receiving these alerts, the app should also send your user a notification. Example:

We’ve detected an usually high number of authentication attempts against your account. If you did not initiate these attempts, please contact XYZ immediately to report this malicious activity.

Hopefully these real-world scenarios will help raise the industry’s concern level and change this common but insecure practice.

If you would like PEN Consultants to evaluate your authentication processes and perform these tests, we would love to speak with you! Contact us today!

Featured image is a derivative work from the following images: Alexander Klink / CC BY (https://creativecommons.org/licenses/by/3.0)

The post MFA Implementation Attacks appeared first on PEN Consultants, LLC.

]]>
https://penconsultants.com/home/mfa-implementation-attacks/feed/ 0
Mass Call Record Collection – Cisco IP Phones https://penconsultants.com/home/mass-call-record-collection-cisco-ip-phones/?utm_source=rss&utm_medium=rss&utm_campaign=mass-call-record-collection-cisco-ip-phones https://penconsultants.com/home/mass-call-record-collection-cisco-ip-phones/#respond Fri, 24 Apr 2020 14:59:05 +0000 https://penconsultants.com/home/?p=3010 Mass Call Record Collection – Cisco IP Phones This article will demonstrate how to perform a mass collection of all phone records in an enterprise from many popular series of Cisco IP Phones and how to prevent it. Many of the Cisco IP Phone series have a built-in web server […]

The post Mass Call Record Collection – Cisco IP Phones appeared first on PEN Consultants, LLC.

]]>
Mass Call Record Collection – Cisco IP Phones

This article will demonstrate how to perform a mass collection of all phone records in an enterprise from many popular series of Cisco IP Phones and how to prevent it.

Many of the Cisco IP Phone series have a built-in web server that allows users and admins to “view the phone statistics and modify some or all the parameters”. In most modern phone series, Cisco has this web server disabled by default to “enhance security”. For those that are enabled, either by default or through a configuration change (ex. via CUCM or the phone), there is a certain level of access that is allowed without authentication.

To see a few live examples, Google: “Cisco Unified IP Phone” “Console Logs” “Current Logs In”. Note: use all three quoted phrases, after the colon, in your search and 100% of the results will be publicly accessible Cisco IP Phones.

Another example Google search: inurl:”/CGI/Java/Serviceability”.

In our experience, it is common to see this embedded web server enabled on not only Cisco IP phones, but also other brands of IP Phones.

“So what? What’s the danger?” you may ask.

There is a wealth of data that can typically be seen through these embedded web interfaces – phone number, user’s name, various system debug logs, etc. Within the debug logs, such as the Console Logs, are various system details as well as call record details.

Inside those console logs, we can see SIP/call records (ex. phones numbers and date):

Red Team

During certain engagements, PEN Consultants has the need to collect all accessible console logs across an enterprise and parse out each unique phone call record in order to demonstrate the impact of these open web interfaces. To automate the process, we created a simple script, which allows us to collect thousands of call records from hundreds of phones in just a few minutes.

We are making that script publicly available for other security professionals to use during their engagements: https://gitlab.com/J35u5633k/ipphones_public

We will continue to expand on this script during future engagements in order to collect internal user names, caller ID, call length, etc.

Blue Team

Ensure the configuration options that Cisco provides are securely configured:

  • If the web interface is not needed, disable it. If it is needed, restrict access with a password – preferably a unique password per phone/user.
  • If possible, disable the Console Log feature.
  • Depending on usage requirements, consider moving the phones to a different VLAN. This would not only help limit access, but could aide in quality of service (ex. prioritize VoIP traffic over workstation).
  • More information: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/12_5_1/cucm_b_security-guide-1251/cucm_b_security-guide-1251_chapter_01110.html

Featured image is a derivative work from the following images: ElasticComputeFarm @ https://pixabay.com/photos/telephone-technical-support-cisco-1223310/

The post Mass Call Record Collection – Cisco IP Phones appeared first on PEN Consultants, LLC.

]]>
https://penconsultants.com/home/mass-call-record-collection-cisco-ip-phones/feed/ 0
Coronavirus https://penconsultants.com/home/coronavirus/?utm_source=rss&utm_medium=rss&utm_campaign=coronavirus https://penconsultants.com/home/coronavirus/#respond Sun, 22 Mar 2020 16:00:32 +0000 https://penconsultants.com/home/?p=2697 Coronavirus The Coronavirus outbreak should be taken for what it is, an outbreak that deserves our attention and precautionary measures, but not panic. Notes: Most important: stay safe, exercise the precautions being given by your government, maintain social distancing, help your neighbors, pray, etc. Don’t panic or panic buy Avoid […]

The post Coronavirus appeared first on PEN Consultants, LLC.

]]>
Coronavirus

The Coronavirus outbreak should be taken for what it is, an outbreak that deserves our attention and precautionary measures, but not panic.

Notes:

  • Most important: stay safe, exercise the precautions being given by your government, maintain social distancing, help your neighbors, pray, etc.
  • Don’t panic or panic buy
  • Avoid any news source or person who uses words like “apocalyptic”
  • The information in this page will focus mainly on comparisons to the United States

A web search similar to “[your country] coronavirus trajectory” will reveal news articles and charts that make it seem the world is coming to an end. Here is an example chart used by many news outlets showing total number of infections and deaths, over time, since day zero (100 total infections).


Raw data source: https://www.ecdc.europa.eu/en/publications-data/download-todays-data-geographic-distribution-covid-19-cases-worldwide

Along with a chart like this, the headline and article will use a words like “apocalyptic” and phrases like “X is going to get all of us killed”.

Let’s look at a chart showing the same data, but displayed as a percentage of infections and deaths, as opposed to total infections and deaths, in those countries.


Raw data source: https://www.ecdc.europa.eu/en/publications-data/download-todays-data-geographic-distribution-covid-19-cases-worldwide

Another interesting view of the data is number of new cases per day (as a percentage of population).

Updates:

  • 2020-03-23: death rate charts posted
  • 2020-03-26: Corrected a computation error in the China data
  • 2020-04-06: Added the “new cases per day” chart
  • Daily chart updates: 2020-03-23 – 2020-04-13
  • Chart updates every 3 days: 2020-04-13 – 2020-05-01
  • Last update, 01 May 2020, the day Texas reopened. This page will no longer be updated unless there is a significant change.

The post Coronavirus appeared first on PEN Consultants, LLC.

]]>
https://penconsultants.com/home/coronavirus/feed/ 0
Forced Password Rotation == Incrementing https://penconsultants.com/home/forced-password-rotation-incrementing/?utm_source=rss&utm_medium=rss&utm_campaign=forced-password-rotation-incrementing https://penconsultants.com/home/forced-password-rotation-incrementing/#respond Mon, 10 Feb 2020 04:07:12 +0000 https://penconsultants.com/home/?p=2587 Forced Password Rotation == Incrementing Some organizations still force a user to change their password at a defined interval. This is not only ineffective, but it is also detrimental to the security of users’ accounts. This is a follow-up to another article we wrote last year, A Sensible Password Policy. […]

The post Forced Password Rotation == Incrementing appeared first on PEN Consultants, LLC.

]]>
Forced Password Rotation == Incrementing

Some organizations still force a user to change their password at a defined interval. This is not only ineffective, but it is also detrimental to the security of users’ accounts.

This is a follow-up to another article we wrote last year, A Sensible Password Policy. It might be beneficial to review it first, if you haven’t already.

When we perform penetration testing or red teaming against a client with a forced password rotation policy, there is a common and pronounced pattern to users’ passwords. That pattern is known by many as “password incrementing”.

What is password incrementing?

One form of password incrementing is when a user establishes a base password and then adds a chosen number of characters (typically numbers) to it that can be changed (or incremented) every time they are forced to change their password. Most commonly, this is one or two numbers added to the end of their base password, but sometimes can be the beginning or even somewhere in the middle. The key is the position and number of those characters are constant and predictable.

As an example, Jane sets her password to “Password01” in January, and then increments it to “Password02” in April when she is forced to change it. In our experience, “Password” is often seen as “Secret”, “Welcome”, “Letmein”, and a few other common base words. Sometimes, it’s literally the word “Password”. About a fourth of the users will be a little more unique and use the name of a child, spouse, or pet, all of which are typically easy for an attacker to discover (ex. spokeo.com)…albeit, with a few extra minutes of work.

Some users utilize a different, yet predictable, incremental pattern that would still qualify as password incrementing. Instead of a static base word, as seen in the example above, they will use a season (Spring, Summer, etc.) or month (January, February, etc.) for the base word and tack on a few predictable numbers or special characters in order to meet password complexity rules. In this scenario, the base word changes every forced update, which one would think would be more secure. On the contrary, though, the predictable nature of what and when that base password changes to makes this the least secure and most common to crack first during an attack.

As an example, John sets his password to “January2020!” in…you guessed it…January of 2020, then changes it to “April2020!” in…yep, you guessed it again…April of 2020. As mentioned above, in addition to using the month’s name, users will also use the name of seasons.

Metrics

In our experience, the two example formats above – static base name and season/month name – account for nearly three-fourths of the passwords in a typical organization which forces their users to change their password every 60-90 days. Nearly every person in the one-fourth still increment, but they use a base password that is not common or easily discoverable, and, therefore, not as easy to predict. Of course, there are those who use randomly generated passwords stored in a password manager, but those percentages are very small.

Bottom line

When an organization periodically forces a password change, only a few percent of the users come up with a truly unique password each time.

Recommendation

Please do not force periodic password changes on your users. As we pointed out in our above referenced article, an organization has but seconds or minutes to force a password change when a password is compromised, in order to do any good. Forcing a password change when there is no evidence of a compromise is not only worthless, it is probably detrimental to the security of your organization.

Conclusion

If you are interested to know how your network services and web apps would perform against these types of attacks, but do not have the expertise or resources to do so, contact PEN Consultants today!

Featured image is a derivative work from the following images: TBIT @ https://pixabay.com/illustrations/login-password-log-sign-on-turn-on-1203603/

The post Forced Password Rotation == Incrementing appeared first on PEN Consultants, LLC.

]]>
https://penconsultants.com/home/forced-password-rotation-incrementing/feed/ 0
MFA – Without the FUD https://penconsultants.com/home/mfa-without-the-fud/?utm_source=rss&utm_medium=rss&utm_campaign=mfa-without-the-fud https://penconsultants.com/home/mfa-without-the-fud/#respond Sat, 18 Jan 2020 02:50:12 +0000 https://penconsultants.com/home/?p=2548 MFA – Without the FUD Ditch SMS-based MFA now – it’s no better than single factor authentication! Have you seen headlines similar to this recently? A tip: Follow the money. The majority of those articles are paid advertisements for a hardware or software based MFA solution. Here’s an non-vendor biased […]

The post MFA – Without the FUD appeared first on PEN Consultants, LLC.

]]>
MFA – Without the FUD

Ditch SMS-based MFA now – it’s no better than single factor authentication!

Have you seen headlines similar to this recently? A tip: Follow the money. The majority of those articles are paid advertisements for a hardware or software based MFA solution. Here’s an non-vendor biased opinion from the perspective of an attacker who has contended with MFA for many years.

As a penetration tester, and more so, a red teamer, I can say with certainty that SMS based MFA solutions are one of the weaker forms of MFA. I can also say with certainty, a simple SMS based MFA solution makes it exponentially harder to gain access to an account after gaining access to the user’s password.

BLUF (Bottom Line Up Front)

SMS based MFA is still over 75% effective against even the most advanced and targeted of attacks, while remaining one of the most simple, affordable and user friendly solutions. Although users (and admins) should be encouraged to use a more secure solution, app developers should still maintain this as an option for your customers.

The Solutions

Although there are a lot of categories one could organize MFA solutions into, and MFA could include 2FA methods (ex. pin, biometrics, PKI, etc.), I typically think of the following when I talk about MFA:

  • OTC (One Time Code) tokens: Typically SMS based. Some have used email based, but that is close to worthless IMO.
  • Software tokens: Client side software that generates a OTC and/or prompts the user to confirm access. Most often, this is a mobile app. Examples: Google Authenticator, Duo, Authy, etc.
  • Hardware tokens: Devices that must be physically inserted into the computer system and typically must be activated by pressing or touching them in a certain manner. Examples: YubiKey, Titian, RSA, etc.

Attacks

Interestingly enough, based on my experience from the user and the attacker sides, the harder a MFA solution is to use, the better it seems to be in preventing an attack. As an example, the “push notification” MFA solutions are no better than SMS based at stopping my attack. In some situations, it’s actually easier to gain access to the account that utilizes a push notification solution. The middle of the road MFA solutions, in terms of security and usability, are generally the mobile app based software solutions. Hardware tokens present the biggest challenges, again, from both a user and an attacker perspective.

In addition to my experiences, several organizations have conducted, and publicly released, detailed research showing the effectiveness of various MFA solutions. Example: https://security.googleblog.com/2019/05/new-research-how-effective-is-basic.html. The common theme throughout this type of research is that SMS based MFA fairs the worst among MFA solutions, but it still prevents a significant percentage of attacks.

All tokens: There is a common attack that can affect all MFA solutions – social engineering. If the attacker can trick the user to accept the push notification, enter the one time code (OTC), or touch/activate the hardware token, MFA can be bypassed.

Hardware tokens: As mentioned, these are the hardest to use (ex. user loses token) and the hardest to bypass as an attacker. If the attacker has physical access to the user’s belongings (rare), then it is trivial for an attacker to use as they typically have no internal protections to distinguish between a legitimate or malicious user.

Software tokens: Software based tokens have many of the same weaknesses as those mentioned above. In one sense, there is actually a little more protection with a mobile app based solution compared to hardware, as a mobile phone (theoretically) will be locked and require additional work by the attacker to gain access to the token, even after gaining physical access (i.e. stealing). However, that is offset by the fact that it is also easier to remotely exploit a mobile app based solution through malicious software running on the phone that screen scrapes (for example). Great strides have been taken by both the mobile OS and MFA app developers to mitigate these types of attacks, but they do still exist.

OTC: SMS OTCs can be intercepted by the same methods as above, plus various SIM jacking/swapping and porting type attacks. Depending on the carrier, these attacks can be trivial. Even as of today, many of the prepaid carriers use well known porting PINs (ex. 0000, or last 4 of #). This is the reason there is legitimate concern with SMS based MFA. However, ask yourself the question, how many times has your phone been SIM jacked?

Side Note – Misconfigured MFA

Anyone that knows me knows that I cannot talk about MFA without mentioning this.

Using MFA is a must; it is non negotiable. PEN Consultants generates a finding and recommendation on network and web app pentests where non-MFA authentication is found. MFA is not a new thing. If your software is less than a decade old, it likely supports MFA, so there is no excuse.

Whatever MFA solution you go with, it is important to configure it properly. I see MFA misconfigured more times than not on pentests. The most common is the username and password is checked before the MFA token. This leads to two common attacks:

  • Brute force, or at minimum, drip and password spray attacks. Your solution must receive the username, password, and MFA token before giving a pass/fail and not make any distinguishment as to which failed. Once I’ve compromised the username+password, I am just one step away from an Account Take Over (ATO) on YOUR app, and possibly already have enough information to gain access to the user’s other accounts (i.e password reuse).
  • DoS. Assuming you have a lockout policy enabled (you should), if you do not verify the MFA token BEFORE checking the password, an attacker can easily DoS all of your users without ever needing to bypass MFA. Before is key – not after, not in parallel, BEFORE.

More about attacks against misconfigured MFA can be seen here: MFA Implementation Attacks

Conclusion

If you are interested to know how your network services and web apps would perform against these types of attacks, but do not have the expertise or resources to do so, contact PEN Consultants today!

Featured image is a derivative work from the following images: Geralt @ https://pixabay.com/photos/smartphone-finger-fingerprint-4562985/

The post MFA – Without the FUD appeared first on PEN Consultants, LLC.

]]>
https://penconsultants.com/home/mfa-without-the-fud/feed/ 0
Paired Visitor/Escort Proximity Badges https://penconsultants.com/home/paired-visitor-escort-proximity-badges/?utm_source=rss&utm_medium=rss&utm_campaign=paired-visitor-escort-proximity-badges https://penconsultants.com/home/paired-visitor-escort-proximity-badges/#comments Wed, 04 Dec 2019 01:30:43 +0000 https://penconsultants.com/home/?p=2514 Paired Visitor/Escort Proximity Badges How confident are you that visitors within your organization are constantly supervised by an employee? How often does an employee fail to properly hand off their escort duties to another employee? This is a solution we came up in response to a recent physical Social Engineering […]

The post Paired Visitor/Escort Proximity Badges appeared first on PEN Consultants, LLC.

]]>
Paired Visitor/Escort Proximity Badges

How confident are you that visitors within your organization are constantly supervised by an employee? How often does an employee fail to properly hand off their escort duties to another employee?

This is a solution we came up in response to a recent physical Social Engineering Assessment we preformed for a client. It is an all too common mistake in need of a solution. Our hope is this article will help us locate a provider of this (or similar) solution or spur a provider to create this solution.

Background

When a visitor is allowed into a sensitive environment, a secure organization will mandate there be an escort – an employee constantly supervising said visitor. Although this sounds easy, escorts frequently fail at their duties by “stepping away for just a second” or ineffectively transferring the duty to another employee.

Risks

When a visitor is unsupervised for a period of time, it creates a number of risks for the organization. If that visitor is a less-than-fully-trustworthy individual (ex. an unverified service tech), it could lead to a violation of Confidentiality, Integrity, or Availability of your organization’s data or systems.

A Solution

One proposed solution to help solve this problem could be the use of paired visitor/escort proximity badges. This is how the solution might work:

  1. Visitor checks in and is vetted to the extent possible/practical.
  2. Escort is assigned to supervise the visitor.
  3. The visitor is given an “Visitor” badge, and the escort is given an “Escort” badge – both are to be worn at all times. These badges are pre-paired together using a near-field wireless communication protocol (details in the next section).
  4. If the distance between the two badges becomes greater than X (ex. >20’) the escort’s badge will warn the escort through audible and/or visual alerting. This helps ensure the escort remains in proximity of the visitor…a core requirement for supervision.
  5. If the employee needs to transfer escort duties, there would be a physical transfer of the “Escort” badge, ensuring no miscommunication/understanding.
  6. When the visitor checks out, the badges would be returned (ex. to a charging station) and the employee could go on about their day.

Technical details

At minimum, the “Visitor” badge would need to be a wireless transmitter, while the Escort badge would need to be a wireless receiver. The Visitor badge would transmit on a pre-defined interval (ex. every 5 seconds), while the receiver would ensure it received that transmission without fail. If it failed to receive one of these transmissions, it would generate audible and/or visual warnings to the escort.

Obviously this technology would end up being slightly bulkier than a typical employee badge. The largest component, the battery, could end up being as much as 0.5 mm thick…the thickness of a typical RFID enabled badge. And, that doesn’t include the transmitter/receiver and housing/casing.

The next largest component would be the transmitter/receiver. There are a number of wireless technologies that could be used for this. It’s likely Bluetooth would be one of the preferred choices, but other options might include: ANT+, NFC, RFID, Wi-Fi, ZigBee, Z-Wave. Most of these wireless technologies have compact transmitters/receivers that are smaller and thinner than a US Quarter.

Conclusion

Once these two components are combined and wrapped in a nice, durable housing, it’s likely to be 2-3 times the thickness and 4-5 times the weight of a typical RFID enabled badge (ex. HID card). Even though it would be bulkier, it seems that it would be a reasonable size, given the features they come with.

Request For Information

If you know of a similar solution that already exists, please let us know. If you are a manufacturer in this industry, and are interested in creating this, please reach out to us, as we would be interested to provide additional input to the process.

Test your organization

If you are interested to know how your employees would perform against this type of physical social engineering, contact PEN Consultants today!

Featured image is a derivative work from the following images: Settergren @ https://pixabay.com/vectors/name-nameplate-badges-trailers-441078/

The post Paired Visitor/Escort Proximity Badges appeared first on PEN Consultants, LLC.

]]>
https://penconsultants.com/home/paired-visitor-escort-proximity-badges/feed/ 3
Selecting a Reputable Security Testing Company https://penconsultants.com/home/selecting-a-reputable-security-testing-company/?utm_source=rss&utm_medium=rss&utm_campaign=selecting-a-reputable-security-testing-company https://penconsultants.com/home/selecting-a-reputable-security-testing-company/#respond Sat, 19 Oct 2019 14:28:16 +0000 https://penconsultants.com/home/?p=2481 Selecting a Reputable Security Testing Company When choosing a security testing company to perform penetration testing, red teaming, etc., there are a few things you should consider to guarantee that you find the optimal company for your situation. Transparency: If you can’t answer all, or nearly all, of the following […]

The post Selecting a Reputable Security Testing Company appeared first on PEN Consultants, LLC.

]]>
Selecting a Reputable Security Testing Company

When choosing a security testing company to perform penetration testing, red teaming, etc., there are a few things you should consider to guarantee that you find the optimal company for your situation.

Transparency: If you can’t answer all, or nearly all, of the following from the company’s website, they are not transparent.

Company Size: Size does not matter. Quality matters, and there is no correlation between the two. There are plenty of solo testers and small companies we would recommend over some of the largest firms in the industry. In fact, based on experience from past employers, and as a general rule, the larger the company, the less adequate the testing service. In addition to losing a more personal touch as compared to a smaller company, the client simply becomes another number.

Methodology: Determine the specific methodologies and techniques that will be used during testing. There are growing number of fly-by-night companies and unscrupulous vendors who perform rudimentary vulnerability scanning and assessments, however, they sell it to their clients as penetration testing. In other words, the client is paying penetration testing prices for a minimally effective vulnerability assessment service. Another common thing seen in the industry is time-based engagements. If the service details simply state something such as 40 hours of penetration testing before moving to assumed breach, they are not likely focused on completing a particular methodology, and thoroughness of testing will only be as good as the speed of the tester. This will almost certainly leave gaps in what is tested. To be clear, that is not to say the service details may not include a time component as precaution against unforeseen environment complexities discovered during testing. Just be aware of the implications going into one of those agreements and question them if they “run out of time”. An experienced and respectable company will adequately project time/costs ahead of time and absorb the extra costs if testing runs over some by no fault of the client. As an example, you can see the methodology details of all of our services here: https://penconsultants.com/services

Sample Report: Download, or request, a sample findings and recommendations report. Since this is typically the largest and most significant deliverable for a security testing engagement, you want to have a good idea of the level of detail and quality of the report. The key things you should look for are: (1) a prioritized risk rating for each finding to help you focus resources on what matters most, (2) enough details and explanation in the findings to understand the risks and reproduce the attack, and (3) various detailed mitigation options in the recommendation to have one or more solutions to mitigate the risks. As an example, you can see one of our sample reports here: https://penconsultants.com/report

Research: Review the testers’ resumes, social media profiles, code repositories, blog posts, etc. Although there will always be a mix of beginner and intermediate level testers with any firm, there should be at least one tester who will have oversight that has a wealth of education, training, and experience. Focusing on one thing for a metric of a good tester is a flawed approach. Some of the smartest professionals in this industry have no college degree. Others may have a solid college education, with minimal certifications, but a wealth of industry experience. The point is, if one of these things is missing or weak, consider their strengths in other areas. If there is sufficient evidence of their knowledge and skill, don’t get hung up on a box they don’t have checked.

Communication: Ask how you are kept informed during an engagement. For example, PEN Consultants provides the name, cell phone number, and email address of each tester that is involved in the engagement. We also provide real-time testing notes that allows our clients to see the tools and commands we are running, with timestamp, from what IP address, etc. See a sample of what we provide here: https://penconsultants.com/informed

Protection: Ask about how your sensitive data is protected during testing and afterwards. If the company is sending things such as vulnerability details, findings and recommendations reports, or even the contract and statement of work in most cases, over unencrypted email, you should seek a new vendor immediately. If the company cannot follow the most basic and trivial best security practices for such overt things such as email, how likely are they to be doing a good job behind the scenes with protecting your most sensitive information from exposure, which could lead to a breach of your environment?

Insurance: Ensure the company carries liability insurance with a reputable insurance company in order to protect your business in the rare event testing causes damages or outages in your environment. These policies are relatively inexpensive, so there is no reason they should not. PEN Consultants carries all policies and coverage amounts typical for this industry.

References: Call references. In this field, it’s hard to find clients who are willing to be public references in many cases due to compliance and regulatory concerns. When there are references given, be sure to call them. As an example, you can see our list of references here: https://penconsultants.com/testimonials

Interview: That’s right, you should interview a vendor just like you would interview a potential employee. Anyone can build a flashy website and marketing. How well do they actually know the field? Is their personality compatible with yours? Are they honest about deficiencies they may have when testing your unique environment, or are they excessively boastful? No one knows everything. You will never find someone with 100% of the needed knowledge from the get-go. A good security tester has a firm grasp on the basics, though, and the ability to quickly learn on-the-fly for the rest.

Shop Around: Don’t settle with the first company you connect with. Talk to a few companies before pulling the trigger on one. Even after you select a vendor and they perform testing, reevaluate before the next engagement. If your budget allows for it, maintain relationships with at least two vendors at any given time. There’s no better way to compare results like having two vendors, at different times, perform the same testing. Drop the least effective vendor and find a replacement.

SOW: Once you to commit to go with a particular vendor, ensure the statement of work (SOW) is detailed before signing the contract. The last thing you want to do is sign a contract with an extremely vague SOW that allows the testing provider to get by with a minimum amount of testing when you expected something much more.

Price: In some cases pricing may be of concern to you. The pricing in this industry varies greatly for comparable quality levels of work. At a minimum, a security testing company should publish their hourly rate. If they do not, seek out a more transparent vendor.

Although detailed scoping is necessary to give final/fixed pricing, many companies refuse to disclose estimated or ballpark pricing until you make contact with them. If the provider you’re considering does not provide estimated pricing, they are likely going to use high pressure sales tactics in order to close the deal at the highest price they feel they can get out of you. PEN Consultants does not take advantage of our clients. We charge a fair price for the scoped service, regardless of the revenue of a client. Our ballpark pricing can be seen here: https://penconsultants.com/services

On the flip side of this, if a security testing company gives you fixed pricing based on minimal information, they are either: (1) giving you a very rudimentary testing service, such as fully automated scanning with little, if any, manual testing, or (2) they have sufficiently padded the price to cover all situations. Security testing engagements are never a one-size-fits-all. Every engagement should be custom-tailored to a client’s needs, and, because of this, pricing will almost always be unique per client.

Unique to PEN Consultants that you will not find with any other security testing company is a price match guarantee. If you have a quote from another vendor, we will guarantee to beat, or match, their price. We are committed to our vision of being the most highly skilled, ethical, and effective security testing company in the industry, while remaining the most affordable.

Corporate Social Responsibility: When selecting a vendor, the social efforts a company supports may be of concern to you. PEN Consultants’ efforts can be seen here: https://penconsultants.com/CSR.

The post Selecting a Reputable Security Testing Company appeared first on PEN Consultants, LLC.

]]>
https://penconsultants.com/home/selecting-a-reputable-security-testing-company/feed/ 0