Rogue Security > Vulnerabilities and Exploits

Vulnerabilities and Exploits

Indicators of Compromise (IOC) and How Security Professionals use them to defend against threats

By / June 27, 2021 / Open Source Intelligence, Risk Management, Vulnerabilities and Exploits / Leave a Comment

If you’ve been in a security field that involves incident response/threat hunting, you’ve probably heard of the term “indicator of compromise” (IOC). In computer forensics, an IOC is an artifact that can be observed on a network or a host that indicates, with a relatively high level of confidence, a computer intrusion.

Not all artifacts from a cyber event will be considered an IOC. Artifacts that are left during an attempted, but perhaps not successful, intrusion are known as precursors. While an IOC can help to identify an intrusion that may have already occurred, a precursor can help to identify when an intrusion may be in the process of occurring.

What Do We Consider An Indicator of Compromise?

Indicators of compromise can range from a simple string to a series of actions performed in a certain order. Here is a comprehensive list of examples of different types of IOCs.

  • IP Address
  • Domain Name
  • URL
  • Website Name
  • File Hash
  • User/Account Name
  • Service and Process Names
  • Registry Key, Path, and Value
  • Directory Path
  • Virus Signature
  • “Strings” within a file
  • DNS txt record abnormalities
  • Files referencing /etc
  • System API Call

While those pieces of data can be easily found using a variety of security tools, there are also a number of behaviours that may indicate an instrusion.

  • Unusual/Unaccounted for outbound traffic
  • Unusual/Unaccounted for traffic between client networks (subnets)
  • Privileged account anomalous usage
  • User account active from anomalous IPs
  • Excessive failed logins
  • Activity from unexpected geographic regions
  • Increased traffic to specific resource
  • Baseline changes in RDBMS activity
  • Change in web browsing requests / request habits
  • Well known port vs. application usage
  • Encryption should be used over normally encrypted ports
  • Unexplainable Registry and File system changes
  • Malformed, overy short, and anomalous DNS requests
  • Patching that didn’t follow the official Change Management schedule
  • Changes to mobile platforms
  • Unexplained file creation
  • Web Browsing spikes and anomalous traffic patterns during irregular times
  • Service changes
  • Anomalous account management activity
  • Anomalous firetransfers
  • Changes to file permissions
  • Changes outside of normal maintenance hours
  • Access to URLs outside of the Alexa Top 1 Million
  • High CPU usage

There are a number of other behaviours that I’m sure you can think of that may also be an indicator of compromise. One of the best sources for techniques that that can be used to build a larger list of behaviours is the Mitre ATT&CK Enterprise Techniques matrix.

How Is This Information Valuable to a Security Professional?

Security monitoring is not a perfect science and relies on security professionals to create, tune, and update the various security tools that are used to detect information security threats, including a tool known as the Security Information and Event Management (SIEM) system. A SIEM is a key tool for Security Operations teams that ingests, manipulates, and displays logs from various services and provides security professionals a perfect tool for investigating security incidents.

Security professionals in the monitoring and detection role can use an indicator of compromise to build alerts and detection content based on real-world events and detections. This is an essential part within any SOC program, and is a proactive approach to cyber defense. Using IOCs in your environment is also a reactive approach to cyber defense, but can help to identify threats in your environment that may have been missed initially. For example:

A security professional will take a list of IOCs related to a recent data breach performed by Darkside, and investigated by FireEye. FireEye, like many security companies, publish intelligence data for use by others.

The security professional will take that list and not only include those IOCs within existing detection content, but they'll also review historical logs for the aforementioned IOCs which can give the security team a limited amount of certainty that the environment wasn't previously impacted by a newly detectable threat.

IOC Standards

IOCs are a type of open source intelligence (OSINT) and are available from many sources in many formats. You may get something as simple as a list of IP Addresses, however, there has been some work over the years to create a standard way of creating, storing, and sharing indicators of compromise.

STIX (Structured Threat Information eXpression)
TAXII (Trusted Automated eXchange of Intelligence Information)

Essentially, both STIX and TAXI offer the same results; they just do it in different ways. STIX uses relationships between objects to build intelligence, while TAXII utilizes collections within a more standard client-server distribution model. Many SIEM tools can ingest both STIX and TAXII feeds for automated intelligence gathering and for updating IOC block lists.

A Beginner’s Guide to TLS/SSL Certificates and Website Security

By / June 19, 2021 / Business Website Hosting, Cryptography, Vulnerabilities and Exploits / Leave a Comment

Raise your hand if the company that you work for has a website, or you, yourself, run a website. That’s a lot of hands!

What Is TLS/SSL?

We often talk as if Transport Layer Security (TLS) and Secure Sockets Layer (SSL) are the same thing, however, their more like successor and predecessor. Both are cryptographic protocols that are designed for secure communications. The last version of the SSL protocol was 3.0 and was published by the IETF in 1996. A major vulnerability, given the name POODLE, was disclosed in 2014, which essentially brought an end to SSL.

TLS 1.0 was defined as an upgrade to SSL in a request for comments (RFC) in 1999. The protocols aren’t substantially different, and the name change had more to do with the fact that the IETF wanted to ensure that it was apparent that this was a fork of the protocol.

Regardless of whether we say SSL Certificates or TLS Certificates, we’re almost certainly using the TLS protocol.

Website TLS/SSL Certificates

A TLS/SSL Certificate is a pair of files where one file contains a private key that only the server knows, and a public key that is used to create a trusted relationship. A process known as a “handshake” occurs when you visit a website that uses an SSL certificate. This handshake can be a little confusing, but the below diagram does a pretty good job.

Source: https://www.entrust.com/resources/certificate-solutions/learn/how-does-ssl-work

How TLS/SSL Protects Your Website

The purpose of a TLS/SSL Certificate is to create a trusted relationship between your computer’s web browser, and the server hosting the website. Once this relationship is created, any communication between these two points, your browser and the website server, is encrypted using the private key that only the server has knowledge of. This is how TLS/SSL protects a website visitor’s financial information, such as credit card number, when they enter it into a form on your website.

Along with Encryption, the TLS/SSL protocol are ensuring a form of Authentication and Integrity. Once the relationship is established you can be sure that the communications being exchanged aren’t being manipulated and are being sent and received by the same two parties.

TLS/SSL Testing

Not all TLS/SSL Certificates are the same, and not all website servers implement these certificates in the same way. Implementing TLS/SSL incorrectly, or not configuring the web server with the appropriate settings, can lead to insecurities. Testing your TLS/SSL should be added to your annual checklist and can ensure that your TLS/SSL Certificates are in tip-top shape.

Here are some resources that you can use to easily test your websites.

  • SSL Labs by Qualys – One of our favourites; allows you to hide the results from their community boards for added privacy.
  • Mozilla Observatory – Choose to not show up in public results, and even not get scanned by third-party scanners. Observatory not only scans for TLS/SSL issues, but also for HTTP and SSH issues.
  • Wormly – Wormly gives you a simple TLS/SSL health check report.
  • CryptCheck – Something a little more technical; CryptCheck also runs tests on SSH, SMTP and XMPP.
  • SSL Checker – Visualize and verify the certificate chain.
  • TLS Version Check by Geekflare – Quickly check if your web server uses a deprecated version of TLS.
  • How’s My SSL? – They really mean, “TLS”. How’s My SSL gives you a simple report and rating on your TLS certificate. It also offers an API.
  • Digicert SSL Installation Diagnostics Tools – Diagnostics tool that also allows you to check for common vulnerabilities.
  • SSL Checker – SSL Shopper providers another tools for verifying your TLS/SSL certificate install.

Other Resources

The Mozilla wiki has a great resource that includes details on TLS cipher suites and other TLS configurations to help you improve web server security. I’d be remiss if I didn’t mention the Mozilla Developer Network (MDN) Web Docs which is rife with articles, references, and guides for better web development.

Canada Post Large Business Data Breach and Supply Chain Attacks

By / June 8, 2021 / Security News, Vulnerabilities and Exploits

Update 2021-05-31

Linking to the official announcement by Canada Post.

Update 2021-05-28

The new player in town, Lorenz, has taken credit for the attack. It also appears that Commport Communications did not pay the ransom, estimated to be between $500,000 to $700,000 for the Lorenz group according to estimates provided by BleepingComputer. Like other newer groups, Lorenz, has a public website available via the Tor network to pressure victims into paying. The data, totaling a compressed 35.3 GB, for Commport Communications is now openly available for download via that website, which suggests that Commport refused to pay the ransom.

Interesting to note is the date on the upload. Commport previously released an attack back in November of 2020, but did not believe any data to be compromised at that time. Apparently, they were wrong.

Commport Communications data available from the Lorenz public repository.

The Attack

Canada Post has announced a data breach of shipping manifest data associated with 44 of its large business users. The impact is recorded at more than 950,000 records relating customers of those businesses. Shipping manifests contain sender and recipient information that usually includes both names and addresses, and less often email addresses, and phone numbers.

According to CTV News, the data comprised of 97% names and addresses, while the final 3% of records contained an email address and/or a phone number. The attack occurred on May 19th, according to Commport Communications Inc., however, the data compromised was from between July 2016 and March 2019.

Apparently, Commport Communications Inc., notified Innovapost, Canada Post’s IT Service Provider, in November 2020, of a ransomware attack on the organization, but a review at that time determined that no customer data was leaked from Canada Post at that time. I’d be interested in seeing the lessons-learned from that attack, as well as the steps taken to prevent this time of incident from happening again.

At this time the May 19th event hasn’t been attributed to a specific attack vector and may not be related to the November, 2020 ransomware attack, at all.

Supply Chain Attacks

This very well could have been a crime opportunity as we don’t know if any other data was stolen from the Commport Communications environment. Other than Canada Post, they have reference to working with companies such as Walmart, Pepsi, Coca-Cola, P&G, Lowe’s and even Amazon on their website. Regardless of the original intent, this is what is known as a supply chain attack. A supply chain attack is an attack that targets a less-secure element of an organization’s ecosystem. This could be anything from a HVAC provider to a software vendor, or, yes, even an IT provider.

The 2020 Solarwinds attack was a series of supply chain attacks that led to, suspected, Russian-sponsored state actors, believed to be either SVR or Cozy Bear (APT29) gaining access to a number U.S. Government systems including parts of the NSA and the Cybersecurity and Infrastructure Security Agency. Not to mention a number of private and public businesses and governments that we’ll never know about.

Supply chain attacks are the real deal and they work because as business owners we often make the mistake of trusting the security and the systems of the third-parties that we do business with, and sometimes have elevated access within your businesses systems. They’re also complex when done with an intended target, and are therefore oftentimes the mark of an APT (Advanced Persistent Threat).

The National Cyber Threat Assessment 2020 by the Canadian Centre for Cyber Security lists supply chain attacks as one of seven threats to Canadian financial and economic health.

Supply Chain Attack Risk Reduction

The issue here, of course, is that if we wish to build our businesses we must rely on third-parties to provide things such as manufacturing, operations, financial services and support.  Information and Cybersecurity isn’t about making it difficult for the business to operate, it’s about creating opportunities!

A third-party risk program can be as complex or as simple as you need, but is really all about governance around your vendors and suppliers. Develop processes and procedures for every transaction between your organization and your third-parties, and ensure that staff are appropriate trained in executing and managing them.

Creating a vendor risk assessment, or by using one of the many available online, you can easily create a risk inventory of your vendors and suppliers that can give your business self-assurance that your suppliers and vendors are employing the necessary security controls. Some questions that you may find on such a form might be, “Does the 3rd party provide information security training to all employees, contractors, and vendors?”, and “Does the 3rd party employee firewalls at all points of network egress?”.

This isn’t a one-time process, unfortunately, and should be reviewed and updated annually for maximum benefit. Both, the ISO-27001 and the CyberSecure Canada Certification require reviews on an annual basis so getting into the habit, and documenting that you’re doing it, can be very beneficial in the long-term.

For further reading, the Canadian Centre for Cyber Security provides an excellent two-page PDF on Supply Chain Security.

Cross Site Scripting Attacks On Your Company Website and How to Protect Against Them

By / June 8, 2021 / SMB Security, Vulnerabilities and Exploits, Web Application Security

Your business’ website and the domain (.com, .ca, .net, etc..) that goes along with it, is an important part of the identity of your organisation and is slowly becoming the first place that consumers will go to find out more about who you are and what you do. The last thing that you want, especially during an already strained moment in the world’s economy, is for a potential client to receive an ad or get redirected to another website when visiting yours.

Cross-site Scripting Vulnerability
There are many ways for an attacker to take advantage of you through your website including a technique called Cross-Site Scripting or XSS for short-hand. A XSS vulnerability allows an attacker to insert (or inject) a piece of code into your website. One intended result from this action is that the code is then displayed to your visitors in the form of ads, malware, or just about anything else. In effect, the attacker is using your website as a median to deliver malicious content to unsuspecting visitors.

A XSS vulnerability exists when an input on your website doesn’t properly validate or sanitize the data given to it prior to that data being used in an output. These inputs might include contact forms, shopping carts, and login forms. Essentially, any point of data entry on your website can be the target of a XSS attack.

Protecting Against XSS Vulnerabilities
The most effective manor of protecting against a XSS vulnerability is by not allowing your visitors to use any special characters (<,>,/,\,,,!,&,etc) when entering data on your website. HTML encoding is the most common method for ensuring that HTML characters are converted output in safer manner. XSS vulnerabilities can be identified during development by using both Static and Dynamic Application Security Testing (DAST) techniques, and should be remediated prior to pushing code to production.

Many websites, including this one, rely on a Content Management System (CMS) to manage and display content. WordPress and Drupal are just a couple of examples of what a CMS is. When using a CMS you willl rely on plug-ins to provide functionality like contact forms, and while you can’t know with 100% certainty what security controls were used in the development of the plug-in, you do have the ability to keep them updated with the latest software patches. Your CMS will allow you to update your plug-ins through its distinct administration dashboard. WordPress 3.7 introduced the capability to turn automatic update plug-ins, but it needs to be turned on!

Resources
OWASP – Cross Site Scripting (XSS)