Sunday, September 17, 2017

ComTech: Do's and Don'ts in production environment pentest

Hello everyone
After a short break, ComTech is back.

Today's post will talk about something that is relevant to every pentest, the do's and the don'ts of pentesting a production environments.
Let's start:
  • Don't use or use a little as possible automated scanners.
    In application PT - use non, do all manual. In infrastructure PT - use only the most needed ones. The automated scanners that should be avoided include vulnerability scanners (Nessus, OpenVas in infra PT, Burp pro scanner, Acunetix in app PT).
  • Perform as much of the test manually.
  • Especially don't use any tools in OT environment (industrial control system, SCADA). These environments are especially sensitive, and a simple port scan might crash them altogether. 
  • If you do need to use tools in infra PT, make sure you mark the "safe checks" checkbox if exist (Nessus, OpenVas).
  • Don't use payloads that can cause any damange. This include innocent looking payloads such as the classic XSS and SQLI <script>alert('xss')</script> and ' or 1=1-- in app PT.
    The first might pop up a message in a production page in a persistent XSS, that would cause embarrassment to the client, and the second, if done in the wrong place, could delete all of the records in a table (if injected to a delete command), or issue a fetch command that would get all of the records and might bring the system down.
  • Always clean up after yourself, and do the best effort to delete any testing records and data, especially any data stored in a persistent storage (DB).
  • In infra PT (and also relevant to app PT) don't send a large input to a tested interface, as it might also cause the system to crash.
  • If money is involved, always ask the client for QA credit cards. Avoid using your own credit card in PTs. 
  • Don't change any configuration in an admin interface or CMS, unless explicitly permitted by the client.
  • Open and use your test emails to make sure you won't get spammed long after the test is over.
  • Don't do online login brute-force attack without permissions, as it might lockout production users.
  • If you are testing a hosted cloud-based system, always make sure you have the appropriate permissions to do so, and that the cloud provider is aware and approves it.
  • In spite of what is written above, always talk to the client and match expectations. There might be specific production environments that you could do the don'ts mentioned above.
Stay safe

Gil Cohen

Sunday, September 10, 2017

Cyber Updates - 10th September 2017

Welcome back to Cyber Updates, apologies for hiatus over the summer.

Cisco Meraki Cloud Data Loss

Cisco Meraki is a cloud based network management system. They recently experienced a loss of customer data which it appeared was not backed up and according to accounts from one customer a significant amount of manual work would be required to recreate the relevant data.

Key takeaways:

  • If you are reliant on cloud services, what happens when they are unavailable. If you have an SLA with a provider, do you offer the same SLA to your customers? Remember that you may receive compensation if SLA your provider violates the SLA but it is unlikely to be enough if the provider is business critical to you.
  • Even if you use a cloud service, some form of local or separated backup can be beneficial.

Chrome Extension Malware

The developer of a popular Chrome Extension called "Web Developer" was phished which allowed hackers access to his Google account. They used this to submit a malicious update to his extension which was then delivered to all extension users through the Chrome Extension updates mechanism. In this case it just seems to have been adware which was incorporated into the code but it could have been much more sinister.

Key takeaways:

  • Network admins should be monitoring which chrome extensions are installed and if necessary only allowing a whitelist of extensions.
  • Endpoints should always be considered at risk and monitored accordingly
  • Sensitive credentials should always be protected using Multi-factor Authentication

HTTP sites to be marked as insecure by Chrome in October

Starting in October, the Google Chrome browser will start marking HTTP sites with a red "Not secure" warning in the URL bar as a warning to users to not enter any sensitive information.

Key takeaways:

  • Any site which processes data or has login functionality should be communicating using HTTPS throughout.
  • This move should provide a marketing impetus for companies to push this ability to their sites.

HPKP considered harmful

Scott Helme, a UK based security consultant and lecturer, wrote a blog in which he declared that he had given up on the HTTP Public Key Pinning (HPKP) standard due to the difficulty in implementing it compared to the significant risks of getting it wrong. This caused quite a stir as he has been a strong supporter of secure web standards and his blog post makes for an interesting read into security tradeoffs.

Key takeaways:

  • Make sure you understand the complexity and risks of any new security standard.
  • This decision should be part of the cost benefit analysis of implementing a new security control.

Josh Grossman
Senior Information Security Consultant and Team Leader