Sunday, June 11, 2017

ComTech: sites communication options and CORS

Hi everyone
Monday tech is dead, all hail the new king ComTech (which stands for Comsec-Tech).
Monday tech wasn't always published on Mondays so I rebranded it.

Today I'm going to discuss the different ways 2 websites\web servers are able to exchange data.
There are many different data transfer options between 2 domains:

  • Regular HTTP Post request – Site A sends a post request to site B and then the execution flow continues in site B only. No response is returned to site A.
    This is a plain regular HTTP POST, CORS does not apply here so it doesn’t really matters whether they define it or not in this scenario (if they define the CORS header with * it is an unrelated finding of course).
    This is a scenario that can be vulnerable to CSRF attacks.
    Regardless, Site B can later redirect the flow back to site A – for example when an online shop redirects the flow to PayPal and then after processing PayPal redirects the flow back.
  • Ajax HTTP POST request – Site A sends a post request to site B and then gets the response back and the execution flow continues is site A.
    This is plain Ajax XHR, that the request format is in POST request and all CORS rules applies.
    Ajax requests can be sent as GET or POST request, it doesn’t matter which one is used and the same rules are applied.
  • Iframe loading without data return – Site A loads site B in an Iframe and doesn’t need to get any information back. For example putting an Iframe of Youtube in your website where the movie loads in an Iframe. This obviously has no relation to CORS and the rules of it does not apply, as well as third party resource loading such as loading pictures or JavaScript from a third party website.
    BTW loading Javascript using a HTML script tag can be used in order to call 3rd party web services without XHR and bypassing all CORS restricions in a technique that is called JSONP, but this was used before web messaging was invented (see next) and is considered obsolete and should not be used.
  • Iframe loading with data return – Site A loads site B in an Iframe and needs to get information back. For example when ecommerce site processes the payment using a 3rd party payment platform that is loaded in an Iframe (not PayPal example above).
    In this case site B can either use plain Ajax requests to send the data back to site A, but then CORS rules applies and site A needs to approve site B in the CORS header – further configuring is needed.
    This is the scenario usually you can and need to define all of the calling domains in the CORS header, and not use *.

    Another option is that site B can send data to site A using web messaging:
    Web Messaging is the way for documents to separates browsing context to share the data without Dom. It overrides the cross domain communication problem in different domains, protocols or ports.
    For example you want to send the data from your page to ad container which is placed at iframe or voice-versa, in this scenario,Browser throws a security exception. With web messaging we can pass the data across as a message event”.
    AKA Iframe communication directly with no web service calls at all.
    This solves Iframe and loading site communication being blocked by CORS.

    PCI DSS standard defines Iframe loading or full website redirection using regular HTTP Post requests and full execution flow redirection (and then redirection back later on) as the recommended way to process and load 3rd party payment platforms.

Sunday, June 4, 2017

Cyber Updates - 1st June 2016

Breach at Identity Provider

Cloud based identity management provider OneLogin reported a breach. Early indications are that it was bad with customers being requested to recycle OAuth tokens, API keys, certificates, credentials, etc. They have previously released detailed “post-mortem” explanations so hopefully they will do so again. It is noteworthy that OneLogin have an extensive and detailed explanation of their security and compliance regime on their site.

Key takeaways:
  • Breaches will happen even with the best controls - make sure you have a plan for when a breach occurs at your own company or at a key supplier.
  • This is especially important for a supplier like OneLogin which provide a centralised identity management platform which could literally hold "the keys to the kingdom" for its customers.
  • When engaging with a supplier like this, make sure you have performed a risk analysis and assessed their security controls and procedures to help inform your own internal breach planning.

This week's cool hack

A bug bounty hunter called Peter Adkins was able to take a Server-side Request Forgery (SSRF) attack where the attacker can make the application make an HTTP request to an arbitrary endpoint and escalate it to achieve Remote Code Execution (RCE) on the target server. He write a nice writeup found here.

Key takeaways:
  • This was possible due to mis-configuration in an "off the shelf" product, Hashicorp Consul. Make sure you are securely configuring all products in the environment, even those which are not externally exposed.
  • Periodic reminder that several vulnerabilities which seem to be low risk could be chained to create a higher risk so it is important to consider vulnerabilities together.

More exploits to be dumped

We have previously covered the release of live and dangerous exploits by TheShadowBrokers. In a new post, they have claimed they will start releasing exploits on a monthly basis to paying "subscribers".

Key takeaways:
  • Whilst this didn't happen last time, be ready for the possibility of dangerous exploits targeting unpatched vulnerabilities.
  • Companies should be ready to install critical patches but also be ready to mitigate unpatched vulnerabilities through other protective or detective controls.
  • Company's planning should include all devices which could be active in their technology ecosystem including mobile devices and "Internet of Things" devices.

Windows SMB: "Well that was a bad few weeks!", Samba: "Hold my beer!"

Details were released this week of a nasty Remote Code Execution vulnerability in Samba (the Linux re-implementation of SMB/CIFS) and proof of concept exploit code has been released. Guardicore have a nice write-up of the issue. There is no link to the recent Windows SMB vulnerabilities aside from the timing.

Key takeaways:
  • Patch your Linux machines or use the workaround 
  • Same as the previous section :)

Josh Grossman
Senior Information Security Consultant and Team Leader

    Monday, May 15, 2017

    Introducing Comsec's Ransomware Readiness Service


    Comsec Group recently created a ransomware readiness service, which maps the gaps, validates the readiness level of an organization against ransomware attacks and provides concrete recommendations for remediation and improvement.

    The WannaCry ransomware that struck recently and exploited a vulnerability found by NSA was leaked by TheShadowBrokers hacking group about two months ago. It is the biggest and most notable example of ransomware that includes the ability to spread without further user interaction, significantly increasing the ransomware threat, and making this service a lot more relevant.

    So what is this service?

    One approach for confronting the ransomware threat, is just to pray and hope it won't hit you, and if it does, to try and recover or just pay the ransom. However, this can take time and more importantly, as was seen in WannaCry, there is no guarantee that you will get your files back even if you pay.

    But there is another way: Organizations can actively test if their infrastructure is ready to counter the threat of ransomware, either by preventing the ransomware from executing, or preventing any real damage by allowing quick recovery from backups.

    Our ransomware readiness service tests exactly that.

    Incident Response

    NIST defines a cyber framework that includes five different activities in a cyber incident:
    • Identify – Develop the institutional understanding to manage cybersecurity risk.
    • Protect – Develop and implement the appropriate safeguards, prioritized through the organization’s risk management process, to ensure delivery of critical infrastructure services. 
    • Detect – Develop and implement the appropriate activities to identify the occurrence of a  cybersecurity event.
    • Respond – Develop and implement the appropriate activities, prioritized through the organization’s risk management process (including effective planning), to take action regarding a detected cybersecurity event.
    • Recover – Develop and implement the appropriate activities, prioritized through the organization’s risk management process, to restore the capabilities or critical infrastructure services that were impaired through a cybersecurity event. 


    Details of the Ransomware Readiness Service

    The ransomware readiness service tests the organization's readiness level in each stage of the incident response process in order to understand the risk of ransomware, test the organization's protection and detection mechanisms, test the response procedures and verify the recovery process.

    The service includes the following steps.


    • Identify management awareness in the organization of the threat of ransomware 
    • Mapping the relevant response procedures for ransomware and general cyber attacks in the organization, highlight the gaps and recommending improvements for these procedures.


    • Web protection: Ensure safe internet browsing by reviewing and adjusting the organization’s web browsing policy to reduce the risk of a malicious executable (or document) being downloaded.
    • Mail protection: Ensure that an appropriate solution for inbound emails exists by reviewing and adjusting the organization’s anti-spam and malicious activity policy. This includes, amongst other things, the detection of malicious files, even if they are not detected as malicious based on anti-virus signatures.
    • User permissions: Ensure that the user workstations are hardened. This includes ensuring that malware can’t be executed by accident (for example, due to an autorun script in a USB drive), and examining any endpoint protection solutions.
    • Limit users' domain permissions: This includes reviewing servers and workstations in the domain in order to ensure that users do not have permissions to execute code remotely. In addition, this review includes restricting writable folders on the domain, to reduce the risk of malware spreading itself via network shares.
    • Servers and endpoint configuration and patching: Ensuring that servers and workstations are updated with the latest security patches in a timely manner in order to reduce the risk of ransomware exploiting known vulnerabilities.


    • Testing endpoint protection: Testing the configuration and update policy of the antivirus and EDR (Endpoint Detection and Response) in order to detect or even prevent the ransomware from executing in real-time.


    • IRT (Incident Response Team): Comsec’s IRT is always available for future support in the event of a security incident caused by ransomware (or any other malware). Comsec investigates the ransomware in order to assess the "family" which it comes from and whether there is a known method of decrypting the files without paying the ransom. Comsec has a registered bitcoin wallet to pay the ransom if needed, as a last resort, following our assessment of the likelihood of the files being decrypted even after paying. 
    • User awareness training: Perform phishing exercises with scenarios such as fake websites, malicious links, malicious files etc., including a detailed report showing statistics of the extent to which the user was susceptible, e.g. opened email, opened link, downloaded file, ran file.


    • Backups: Ensure that files are constantly backed up in order to minimize damage in the event of a ransomware attack and that regular restoration tests are carried out.



    In conclusion: In order to better mitigate the risk of ransomware and other modern cyber threats, you should test your readiness across the full chain of events and activities that can occur in such an event, in order to prevent the threat from occurring and\or to limit the damage if it does occur.

    For further details and for any question please contact us:

    Stay Safe

    Gil Cohen

    Monday, May 8, 2017

    Monday tech: WPAD Man in the middle across LANs *and* the WAN

    Hi everyone
    WPAD or Web Proxy Autodiscovery Protocol, is a protocol that is used in Windows by Internet Explorer and other web browsers that follow Window's internet configuration, that enable auto discovering of proxy server setings in order to connect to the outside, usually the Internet.

    WPAD is almost 20 years old and it's an old and unsecured protocol. When WPAD is enabled, the client asks for a DNS record with the hostname of WPAD and a file that is called a PAC file (Proxy auto-config) that contains sandboxed JavaScript code, that tells the browse the location of the proxy server or multiple proxies. If the DNS query failes, another similar protocol that operates in the LAN and called WINS (Windows Internet Naming Service) is used to search for the WPAD host, and then if this also failes, another similar protocol called LLMNR (Link-Local Multicast Name Resolution) is used. This protocol is used for peer-to-peer resolusion, and uses an entire network broadcast to ask for the resolution - not the safest and most reliable method.

    If an attacker resides in the network of the victim, he can easily respond to the LLMNR broadcast, return a PAC file and redirect the victim's trafic to his station, performing a full MITM attack.
    Moreover, if the attacker adds basic authentication to his malicious server, the victim will be prompt to enter credentials and once he does, he just gave the username and password to the attacker.

    This can be automatically executed using the famous Responder tool created by Spider Lab and now part of Kali.
    A full example can be seen here:

    But wait, the fun doesn't stop there. WPAD first issues a DNS request for WPAD hostname, and in many cases it appends the domain name to the WPAD hostname.
    So effectivly if an organization that is called Contoso has a domain with the same name, and of the domain stations enable WPAD, the DNS server will get both a WPAD hostname request and a WPAD.Contoso request.
    If WPAD.Contoso is a legal DNS hostname in the internet, this attack becomes FAR more dangerous as it nows leaks from the LAN to the WAN.
    During the last BlackHat Las Vegas conference a researcher actually registered multiple top level domains with the WPAD hostname and different suffixes such as, and, hoping to get requests from different organizations. Suprisingly (or not) - he did. A LOT.
    The most succesfull suffix was Tokyo, maybe because the upcoming olympics that will take place in the city in 2020.
    An article about this hack can be found here:
    The presentation from BlackHat can be found here:

    Have a great week!

    Saturday, May 6, 2017

    Cyber Updates - 06/05

    Hey all,
    Here are this week's cyber updates:

    (1) Intel processors remote management features were found to be vulnerable (CVE-2017-5689) to remote code execution.
    Intel’s Active Management Technology (AMT), uses a web-based control panel, which is accessible from port 16992 and 16993, and allows an administrator to remotely manage a system. The web server uses digest as its authentication mechanism, but does not properly compare the users_response digest value with the computed_response value. In particular, the website uses the strncmp function with the user_response length instead of the computed_response length.
    This means that a null value submitted as the user’s digest response, would invoke the strncmp function with a length of 0, therefore causing it to always return 0 (success). Thus, malicious users can successfully authenticate to the webserver and manage users’ computer.
    Fortunately, the AMT features are not installed by default, so not all organizations are affected by this vulnerability.

    Here are all the details:

    (2) WordPress was found to be vulnerable (CVE-2017-8295) to a logical flaw that might allow an attacker to reset users’ passwords. In particular, WordPress sends a “password reset” email from the following address:, with “” parsed from the user’s request host header. Thus, a mail can be sent from the attacker’s domain if he/she submits a password reset request with their own domain (to the victim's IP address).

    A malicious user can flood the user’s mailbox with numerous big attachments (unrelated to the WordPress platform). This would result in the user’s mailbox being flooded, and thus becoming unavailable to receive new emails. 
    The attacker can then send the "forgot password" email (from their own domain), which will cause the victim’s MX server to reply to the original email with a "552 mailbox full" error. However, since the attacker has managed to control the domain, the email would be sent to the attacker, and would contain the original email, including the token to reset the password.

    Here are all the details:

    (3) Flicker was found to be vulnerable to an account takeover vulnerability: the authentication mechanism to Flicker relies on Yahoo, where the user receives a token from Yahoo and sends it to Flicker. Due to insufficient validation on the address URL in Yahoo, a malicious user who causes their victim to invoke a call to Yahoo can receive the victim's Flicker token and login on their behalf.

    Here are all the details:

    (4) Albert Einstein once said that two things are infinite: the universe and human stupidity. A new phishing campaign proves the latter. Users have received an email from Apple iCloud, requesting them not only to provide their password, but also their credit card details, address, and government issued credit card.

    Here are all the details:

    Stay tuned for more updates,
    Dan Gurfinkel
    Head of Offensive Security & Response Uni