Investigating in a Zimbra Environment

Now that Zimbra’s infrastructure and logs hold no secrets for you, it’s time to get practical.

Imagine you’re a forensic analyst, arriving early one morning, when suddenly: the phone rings. You’re being called because several users are reporting that emails, they didn’t send are appearing in their “Sent” folder.

Panic ensues! Users are afraid to log into their mailboxes, and some administrators start wondering whether the Zimbra infrastructure itself might be compromised.

Since you know Zimbra inside out, the team naturally turns to you to investigate this incident!

As a forensic analyst, many questions come to mind:

• Have the accounts really been compromised? If so, how and since when?
• How many users are affected?
• What is the attacker’s objective, and what malicious actions have been carried out from these accounts?
• Have the mail server or other Zimbra components been compromised?
• And, most importantly: do I have time for a coffee before the information hunt begins?

To help you in your investigation, we’ll look at how to answer these questions through Zimbra log analysis. But first, here are some tips to guide your investigation.

During incident response, it’s easy to feel overwhelmed by the amount of logs and events to analyze. Keeping a clear line of reasoning is essential. A few simple practices can help maintain focus:

• Confirm: Verify the information that triggered the incident. Before diving deeper, ensure the initial alert is accurate. This undeniable baseline will serve as the foundation for the entire investigation.
• Correlate: Cross-check suspicious IP addresses and domains with other sources (proxy, VPN, EDR, online antivirus databases). This provides additional context related to the identified indicator.
• Pivot: Use the collected information to expand your analysis. An attacker might reuse the same IP address or user-agent across multiple accounts. Conversely, a compromised account might be accessed from different IP addresses or user-agents. Pivoting can reveal other indicators that help identify the attacker.
• Compare patterns: Even without direct access to email content or attachments, certain elements can reveal similarities (file size, identical filenames, repeated sequences of actions after account compromise). This behavioral analysis approach can help identify multiple users compromised by the same attacker. Such hypotheses should be formulated and handled cautiously, but they can be valuable for confirming intuition.
• Ensure log preservation: This may seem obvious, but as soon as an incident is detected, securing the logs is critical. Collect logs immediately from the entire Zimbra infrastructure and extend their retention period to prevent automatic deletion. Because let’s be honest: logs disappearing just as the forensic team arrives is a way too common scenario… one you definitely want to avoid.

While these tips aren’t exhaustive, they provide a solid foundation for conducting an analysis that is both fast and efficient.

Post-compromise activity

Analysis of user activity  

What mastery! You have successfully traced back to the initial entry point used by the attacker to compromise user accounts. You have identified the malicious IP addresses, spotted the User-Agent used, and even uncovered other compromised accounts thanks to this information. In short, clean and efficient work. Impressive!

But… we still haven’t answered a crucial question: “What was the attacker’s objective, and what actions did they take from the compromised accounts?“

To find out, you now need to analyze the attacker’s activity within the Zimbra infrastructure. Once authenticated, an attacker can indeed:

• Launch an internal or external phishing campaign
• Send messages aimed at tricking a colleague, partner, or client into taking action (CEO fraud, fictitious urgent requests, etc.)
• Exfiltrate sensitive data from mailboxes

In this section, we will examine some examples of suspicious activities that can be identified from Zimbra logs.

Sending a large number of emails in a short amount of time

You want to determine whether compromised accounts were used to conduct additional phishing attempts by sending mass emails to internal or external recipients. Unfortunately, Zimbra does not provide a native event that allows you to retrieve this information directly. However, a simple grep command will get the job done.

The command below extracts the number of messages sent by each user over a specific period (here, from November 21 to November 27, 2025):

In this example, user25@wavestone.corp clearly stands out with a sending volume far above normal. An unusually high volume of emails sent from a mailbox over a short period constitutes suspicious activity.

In legitimate use, mass email sending is relatively rare and is generally associated with generic addresses or internal communication systems (e.g., newsletters, HR announcements). When a standard user account exhibits this type of behavior, it is important to:

• Determine whether this is normal, recurring activity for the user
• Check the sending time frame, IP address, and User-Agent
• Verify whether any suspicious attachments were associated with the emails

Mass email sending can trigger built-in protection mechanisms in Zimbra, including quota rules. These thresholds are designed to limit the volume of messages sent by an account over a given period to prevent abuse, spam, or phishing campaigns.

The two commands below allow you to retrieve events related to quota exceedances:

The appearance of error messages related to quota exceedances is a signal not to be ignored, because:

• Either the legitimate user accidentally exceeded a quota
• Or the account is being used fraudulently to send mass emails

Since this indicator can generate a large number of false positives, it is recommended to correlate it with other information in order to draw meaningful conclusions.

Sending an email to a large number of recipients

To avoid triggering a quota‑exceedance alert, a more seasoned attacker may adopt a more “subtle” strategy. Instead of sending dozens of individual emails (a noisy method), they may choose to send a single message addressed to a long list of recipients: an efficient way to optimize their phishing campaign.

Fortunately for you, Zimbra logs make it possible to identify the number of recipients associated with each sent email, which makes this type of maneuver detectable without too much effort.

The commands below allow you to identify emails sent to an unusually high number of recipients:

Here, you can observe that the user user25@wavestone.corp sent an email to 211 recipients. Such behavior is clearly suspicious.

In practice, it is rare for a personal email address to send a message to several dozen recipients simultaneously. This type of volume is usually associated with shared mailboxes or generic addresses (e.g., internal communications, HR services, institutional announcements).

When a standard user account exhibits this kind of activity, it is essential to:

• identify the usual communication practices within the organization
• determine whether this sending volume is normal or recurrent for the user in question
• examine the time window, IP address, and user agent used during the sending
• check if any potentially malicious attachments were associated with the messages

To save time, it is often relevant to confirm directly with the user whether the sending was legitimate.

The example presented here isolates sends containing more than 100 recipients. However, this threshold should be adjusted depending on:

• the usual volume within the organization
• the type of accounts involved
• and the period covered by the logs analyzed

Uploading suspicious attachments

Unlike email reception, the upload of suspicious attachments is better logged by Zimbra. Each time a user attaches a file to a new email, Zimbra carefully records the operation in its logs.

Using the commands below, you can retrieve the attachments added to emails by a potentially compromised user:

Similarly to the reception of malicious attachments, you can search in the logs for:

• the upload of attachments with suspicious extensions (e.g., .htm, .html, .exe, .js, .arj, .iso, .bat, .ps1, or Office/PDF documents containing macros);
• files already observed earlier during the initial phases of the incident (for example, a document downloaded by patient zero);
• correlating upload activities with malicious source IP addresses or accounts identified as compromised.

This list is not exhaustive; it may be relevant to search for any type of file that seems pertinent to the context of your investigation.

Removal of traces

Now that you have a clear picture of what the attacker did with the compromised accounts, you are disappointed because you cannot locate the emails in question. You suspect that the attacker erased its traces. But how can you verify this?

Indeed, after sending malicious emails, an experienced attacker may try to hide its tracks from the legitimate mailbox owner by deleting sent emails or returned messages.

Fortunately, the following commands will allow you to identify email deletions performed in Zimbra:

In legitimate use, it is not uncommon for a user to delete multiple emails (e.g., inbox cleanup, managing newsletters). However, the situation becomes suspicious when deletions occur:

• Immediately after a mass email sending
• Targeting specifically the most recently sent messages

During your investigation, keep in mind that an attacker may also attempt to delete:

• Read receipts generated by their emails
• Automatic replies (out-of-office messages, NDRs) that could alert the victim

It is therefore important not to overlook deletions and to correlate them with other indicators (suspicious authentications, mass email sending, quota exceedances, connections from malicious IPs) to assess the legitimacy of these actions.

Data exfiltration

One question still troubles you… Among the compromised accounts, some belonged to users who handled sensitive data for the company. You therefore want to determine whether the attacker attempted to exfiltrate any email they had access to.

Unfortunately for you, Zimbra does not log the direct download of emails. After all, retrieving messages via IMAP or SMTP is essentially a “download” from the server to the mail client. It is therefore difficult to distinguish a normal transfer from a malicious download. And in the Nginx logs (which expose the webmail), the same issue arises: it is impossible to precisely identify whether an email was downloaded.

As a small consolation, Zimbra does log certain internal operations, particularly copy actions performed within the mailbox. An attacker could, for example, create a folder to store sensitive emails before extraction.

The following command allows you to identify a massive copy of emails into a folder (here named “Exfiltration“) from the web client:

The following command allows you to identify a copy of a large number of emails in a folder from an IMAP thick client:

Although there are legitimate cases (e.g., manual backup by the user), this type of activity should raise attention, especially when correlated with:

• Logins from unusual IP addresses
• Suspicious authentications
• Mass email sending

However, as you can see, it is very difficult to confirm a data exfiltration. Therefore, it should be assumed that if a mailbox is compromised, the attacker potentially had the ability to download all emails of the affected user.

Detection of antivirus and antispam solutions

We haven’t really covered this until now, but it’s important to know that Zimbra natively integrates Amavis, a “central” component that orchestrates various security engines. These engines help identify suspicious files, phishing campaigns, and mass spam sending. It is therefore valuable to leverage these detection mechanisms when analyzing an attacker’s activities.

During your investigations, examining the messages generated by Amavis can help highlight:

• Messages blocked before reaching the user’s mailbox (e.g., spoofing attempts)
• Malicious attachments detected and placed in quarantine
• Violations of certain security policies defined on the platform

Amavis

It is possible to retrieve certain events generated by Amavis with the following commands:

Since Amavis generates a large number of events, it may be wise to focus your investigation on detections related to spam and phishing. Note that the identification of phishing messages has already been discussed in a previous section of this article (“Account Compromise via Phishing Attack“)

Incoming spam

It may be useful to identify messages that have triggered incoming spam detections. When a message is classified as spam, Zimbra generates logs indicating the reason for this categorization.

These events can contain several useful pieces of information:

• The affected account
• The unique identifier of the message in the mailbox
• The originating IP address of the email
• Additionally, in the case of a SpamReport:
  • The result of the analysis (isSpam field)
  • The action taken (e.g., moving the message from the Inbox to Junk)
  • Sometimes the recipient of the report used for training or reporting purposes (e.g., a dedicated address such as spam@wavestone.corp

The following command can help you identify events related to the processing of incoming spam:

Since spam detections generate a large number of false positives, it may be useful to narrow the scope of your investigation as much as possible (for example, by focusing on a specific time period or a specific set of users).

Outgoing spam

The threat does not always come from outside. Some malicious emails sent from compromised internal accounts to external recipients can leave very interesting traces in Zimbra’s logs. Indeed, if the message sent from the compromised account is blocked by the recipient mail server’s antispam solution, that server will send an error notification back to the Zimbra server to report the rejection.

Analyzing these non-delivery reports (NDRs) can therefore raise a red flag:
it may reveal that a user is compromised… or that an account has been used in an attempt to send malicious emails.

It is possible to extract these rejected messages using the following command:

Outgoing spam is generally rare. Analyzing it only becomes truly useful in cases where the attacker attempts to lateralize to external email accounts.

Remediation measures

You have conducted your investigation at full speed: compromised users identified, malicious IP addresses cataloged, suspicious activities analyzed… in short, you have traced the attack with surgical precision. It is now time to move to the next step: remediation.

The primary goal of remediation is to remove the attacker’s access to the infrastructure, implement detection mechanisms capable of preventing further compromise attempts, and strengthen user awareness to limit the impact of ongoing and future phishing campaigns.

By collecting various indicators related to the phishing campaign (compromised or suspected accounts, email addresses, malicious IPs and domains, etc.), it is recommended to implement a series of corrective and preventive actions (non-exhaustive):

• Reset passwords for suspected accounts: For any user who has been compromised or is suspected of being compromised, a password reset is required.
• Block malicious domains, IP addresses, and email addresses: Infrastructure elements used by the attacker (domains, IPs, senders) should be blocked using available network solutions (proxy, firewall, mail filters) as soon as they are detected. This will limit the risk of further propagation.
• Perform antivirus/EDR scans on compromised user workstations: Workstations of compromised users should undergo antivirus or EDR analysis to:
  • Detect and remove any potential malicious files
  • Ensure that phishing-related files are no longer present on the workstation
• Strengthen user awareness: Communication about ongoing phishing campaigns should be sent to users to prevent further compromise. Regular phishing awareness campaigns are strongly recommended, particularly for users who have already been compromised.
• Implement multi-factor authentication (MFA) for Zimbra mail access: Deploying a second authentication factor is highly recommended to secure mailbox access. While MFA can be perceived as inconvenient, using a Single Sign-On (SSO) with unified MFA can reduce friction while strengthening overall authentication security.
• Deploy a specialized phishing detection and filtering solution: It is recommended to install a specialized solution in detecting malicious activity in email environments. The solution should be able to identify:
  • Logins from unusual IP addresses
  • Brute-force attempts on user accounts
  • Mass email sending to numerous recipients
  • Use of suspicious attachments or links to untrusted domains
  • Active phishing campaigns (e.g., identified by a CTI service)
• Ensure Zimbra log retention: It is important to secure the collection and retention of logs. It is recommended to centralize logs from the entire Zimbra infrastructure on a server external to that infrastructure. This ensures that even in the event of compromise, modification, or encryption of Zimbra servers, logs remain intact and accessible, allowing reliable forensic investigations.

Although non-exhaustive, these remediation measures will help restore confidence in your Zimbra infrastructure and user accounts. Continuous monitoring and improvement of the security posture will, however, be necessary to adapt to future threats.

At the end of this little investigation, one thing is certain: while the attacker can choose the easiest path, the forensic analyst doesn’t have that luxury. Between scattered (or sometimes missing) logs, conflicting user testimonials, and limited visibility into certain Zimbra events, conducting an investigation can sometimes feel like solving a Rubik’s Cube… in the dark… with mittens on.

But with a solid methodology and a few good habits, Zimbra can reveal far more information than it might seem at first glance. Its logs are a real goldmine, provided you don’t get lost in them.

Ultimately, this article does not aim to turn every reader into a Jedi master of Zimbra forensics… but if it can save you two days of trying to decode Zimbra logs or hunt down the useful information, then the goal has been achieved!

And as is often said, in cybersecurity as elsewhere, prevention is better than cure. So harden your Zimbra infrastructure, back up your logs, raise user awareness… and above all, don’t be short on coffee supplies!

Sources

• https://wiki.zimbra.com/wiki/Log_Files
• https://wiki.zimbra.com/wiki/Troubleshooting_Course_Content_Rough_Drafts-Zimbra_Architecture_Component_Overview
• https://wiki.zimbra.com/wiki/Trouble_Shooting_Spam_Score_Changes

Cet article Zimbra Mailbox Compromise: From Analysis to Remediation (Part 2) est apparu en premier sur RiskInsight.

In most companies, webmail access portals are exposed on the internet and do not always benefit from sufficient access-control mechanisms. In addition, some messaging services offer extended features that go beyond simple email consultation, such as file sharing or access to collaborative applications.

Poorly secured messaging services therefore represent prime targets for attackers. Compromising a mailbox can then be used to launch phishing campaigns, access sensitive data, carry out fraud attempts, or even gain access to other services.

At CERT-W, we regularly deal with this type of compromise. In particular, several of our investigations in 2025 involved the compromise of Zimbra email accounts, a solution used by many public and private organizations. Faced with these incidents, we noticed a clear lack of forensic documentation specific to Zimbra infrastructures.

This article is therefore our modest contribution to filling this gap. We share a pragmatic approach and a few tips to help you save time when analyzing this type of environment, as well as some remediation measures.

The Zimbra Infrastructure

If you’re not familiar with Zimbra infrastructures, don’t worry: this section is for you! For the more experienced readers, feel free to jump straight to the investigation section (we won’t hold it against you).

The architecture

Zimbra isn’t just “another mail server“. It’s a complete open-source collaborative suite that brings together several useful components:

• A mail server: the core of the system.
• A calendar, contacts, and task manager: so you never forget that 9 AM meeting.
• A web client: accessible from any browser.
• Additional services: antispam, antivirus, mobile synchronization, and more.

But like any infrastructure used by hundreds (or even thousands) of users simultaneously, sizing and performance quickly become important topics. That’s why Zimbra can be deployed in two different ways:

• Monolithic mode: everything on a single server (simple and effective… up to a point).
• Distributed mode: multiple servers, each with a specific role, to better handle load, availability, and maintenance.

In simplified form, a distributed Zimbra infrastructure looks like this:

Although the architecture may vary, the following components are usually present:

• Proxy Server: the entry point for Web, IMAP/POP, and ActiveSync clients. Logs generated at this level provide visibility into user connections (IP addresses, user agents, timestamps, etc.).
• Web Client Server (Mailboxd UI): hosts the Webmail interface used by users to access their mailbox through a browser.
• Mailbox Server (Mailboxd): hosts user mailboxes and manages messages, folders, and calendars. This component generates the richest logs (e.g., mailbox.log, audit.log, sync.log).
• MTA Server (Message Transfer Agent): receives emails via SMTP and delivers them to the appropriate Zimbra mailbox server using the LMTP (Local Mail Transfer Protocol).

The Zimbra MTA relies on several complementary services:

• Postfix MTA: handles message routing, relaying, and filtering (including attachments).
• ClamAV: antivirus engine responsible for scanning messages and attachments.
• SpamAssassin and DSPAM: spam filters that use various mechanisms to identify unwanted emails.
• Amavis: the orchestrator that runs the configured antivirus and antispam engines, then applies processing policies to incoming messages.

The MTA server plays a key role in the Zimbra infrastructure. This is where most of the security checks applied to incoming emails are performed. The diagram below illustrates the main stages of this analysis workflow:

In the process of receiving an incoming email, the message is first handled by Postfix, which then forwards it to Amavis for analysis. Amavis invokes the various configured analysis engines and submits the email to each of them to collect their results. Based on the defined policies, Amavis returns a verdict to Postfix: deliver the message, block it, or move it to a specific folder.

Zimbra logs

Now that you’re practically a Zimbra architecture expert (or almost ), you’ve probably noticed that many services are required to handle users’ email sending and receiving. The good news is that each of these services generates its own logs, providing significant visibility into the activity of the mail infrastructure. And for us forensic analysts, that’s excellent news: we love logs!

Studying the logs generated by Zimbra allows us to reconstruct the timeline of a compromise, identify compromised mailboxes, spot malicious attachments, and even detect potential internal relays.

This wealth of information is made possible thanks to logs, which are mainly located in:

• /opt/zimbra/log/mailbox.log: main log of user activities (authentications, sending/receiving emails, managing mails, folders, contacts, calendars, etc.).
• /opt/zimbra/log/access_log: Webmail access log (IP addresses, user agents, visited URLs).
• /opt/zimbra/log/audit.log: authentication traces (successes, failures, mechanisms used).
• /opt/zimbra/log/sync.log: mobile synchronization traces (ActiveSync/EAS).
• /opt/zimbra/log/convertd.log: file conversion traces (Webmail previews, indexing).
• /opt/zimbra/log/clamd.log | /opt/zimbra/log/freshclam.log: ClamAV antivirus activity.
• /opt/zimbra/log/spamtrain.log: traces of user-initiated antispam training.
• /opt/zimbra/log/cbpolicyd.log: Postfix policy enforcement (quotas, anti-relay, restrictions).
• /var/log/mail.log: system Postfix logs (SMTP, LMTP, Amavis).
• /var/log/nginx.access.log | /var/log/nginx.log: Nginx web server logs (useful for contextualizing web sessions).

Unfortunately, in a distributed Zimbra architecture, logs are not centralized. In other words, to get a complete picture of an incident, an analyst often needs to collect logs from each node: proxy, mailstore, MTA, or any other peripheral server. Yes, it requires a bit of gymnastics (and patience).

As we mentioned, the wealth of Zimbra logs is a real goldmine for investigations… but, like any mine, you need to dig methodically, or you’ll quickly find yourself buried under tons of log lines. Some effort in sorting and correlating data is therefore necessary to extract relevant information.

And despite their undeniable usefulness, Zimbra logs have some notable limitations:

• No access to the full content of emails or their attachments.
• Email subjects are rarely available, except when intercepted by antispam or antivirus modules.
• No native visibility into the creation of forwarding rules.
• Rapid rotation of verbose logs (like log), which limits the analysis time window if logs are not centralized.

Investigating in a Zimbra Environment

Now that Zimbra’s infrastructure and logs hold no secrets for you, it’s time to get practical.

Imagine you’re a forensic analyst, arriving early one morning, when suddenly: the phone rings. You’re being called because several users are reporting that emails, they didn’t send are appearing in their “Sent” folder.

Panic ensues! Users are afraid to log into their mailboxes, and some administrators start wondering whether the Zimbra infrastructure itself might be compromised.

Since you know Zimbra inside out, the team naturally turns to you to investigate this incident!

As a forensic analyst, many questions come to mind:

• Have the accounts really been compromised? If so, how and since when?
• How many users are affected?
• What is the attacker’s objective, and what malicious actions have been carried out from these accounts?
• Have the mail server or other Zimbra components been compromised?
• And, most importantly: do I have time for a coffee before the information hunt begins?

To help you in your investigation, we’ll look at how to answer these questions through Zimbra log analysis. But first, here are some tips to guide your investigation.

During incident response, it’s easy to feel overwhelmed by the amount of logs and events to analyze. Keeping a clear line of reasoning is essential. A few simple practices can help maintain focus:

• Confirm: Verify the information that triggered the incident. Before diving deeper, ensure the initial alert is accurate. This undeniable baseline will serve as the foundation for the entire investigation.
• Correlate: Cross-check suspicious IP addresses and domains with other sources (proxy, VPN, EDR, online antivirus databases). This provides additional context related to the identified indicator.
• Pivot: Use the collected information to expand your analysis. An attacker might reuse the same IP address or user-agent across multiple accounts. Conversely, a compromised account might be accessed from different IP addresses or user-agents. Pivoting can reveal other indicators that help identify the attacker.
• Compare patterns: Even without direct access to email content or attachments, certain elements can reveal similarities (file size, identical filenames, repeated sequences of actions after account compromise). This behavioral analysis approach can help identify multiple users compromised by the same attacker. Such hypotheses should be formulated and handled cautiously, but they can be valuable for confirming intuition.
• Ensure log preservation: This may seem obvious, but as soon as an incident is detected, securing the logs is critical. Collect logs immediately from the entire Zimbra infrastructure and extend their retention period to prevent automatic deletion. Because let’s be honest: logs disappearing just as the forensic team arrives is a way too common scenario… one you definitely want to avoid.

While these tips aren’t exhaustive, they provide a solid foundation for conducting an analysis that is both fast and efficient.

Compromise and initial access

The spoofing trap

You are not fooled! You know that sometimes one might believe the attacker is already inside the system, when in reality, they are still outside (fake it until you make it). Especially when multiple users start reporting concerning incidents, such as:

• “I received an email from so-and-so, yet they claim they never sent it.“
• “I received an email from my own address, which makes no sense!“

But your experience pushes you to verify that the current confusion is not simply the result of… a spoofing attack.

Indeed, spoofing is a relatively simple identity impersonation attack used by malicious actors to falsify email header information (e.g. sender address) in order to deceive a victim. Spoofing allows an email to be sent while pretending to be from a legitimate sender (for example, an internal user of the company or the recipient themselves), when in reality the email comes from an infrastructure that has no authorization to use that email address.

The goal is to gain the recipient’s trust to prompt them to take an action (click a link, open an attachment, provide credentials, etc.) or bypass filtering mechanisms.

Mechanisms such as SPF, DKIM, and DMARC were designed to reduce the risks associated with spoofing by allowing verification of the sender domain and server authenticity.

More specifically, the Sender Policy Framework (SPF) is an email security mechanism that allows verification that the sending server of a message is indeed authorized to send emails on behalf of the domain indicated in the sender’s address. The steps of an SPF check are illustrated below:

Concretely, the domain owner publishes in the DNS records a list of IP addresses authorized to send emails on behalf of their domain. When a mail server receives an email, it can compare the sender’s IP address to this list and determine whether the message is legitimate or potentially fraudulent.

An SPF check failure indicates that the email was sent from a server not authorized by the sender’s domain. This serves as an indicator for identifying potential spoofing attempts.

In Zimbra logs, SPF check failures can be identified using the following command:

In above example, we can see that the message sent from attacker@microsoft.com to user25@wavestone.corp does not pass SPF validation (SPF_FAIL). The “Yes” field indicates that it is classified as spam. Since its score (9.172) exceeds the required threshold (4), this message will therefore not be delivered to its recipient.

However, you should not place blind trust in the antispam engine! Some emails that fail SPF checks may still be delivered. To extract only these messages, you can use the following command:

In the example below, the message fails the SPF check, but its score is negative (-2.06) and below the spam threshold (4). It is therefore considered legitimate and delivered to the recipient despite the SPF failure.

As you can see, Zimbra logs make it possible to quickly identify senders responsible for spoofing attacks. Detecting a spoofing case early in the investigation helps to quickly reduce concerns and restore a certain level of trust in the Zimbra infrastructure.

Analysis of the attacker’s initial access

Once you have confirmed that you are not dealing with a spoofing attack, it means the attacker has, in one way or another, succeeded in compromising an account or a component of the infrastructure. The first step of your investigation will be to identify the attacker’s initial point of entry. This means finding the answers to the questions “Where?”, “When?”, and “How?”. But when it comes to compromising a mailbox, several approaches are possible…

Account compromise through password brute‑forcing

One path you can explore is the possibility that the attacker attempted to compromise certain accounts through a brute‑force attack.

To do this, simply examine authentication failures in the Zimbra logs:

In the events above, we can see authentication attempts coming from the IP address 100.100.4.111 that failed for the account user25@wavestone.corp.

A large number of unsuccessful login attempts over a short period, from the same IP address or targeting the same account, is indicative of a brute‑force attempt.

An excessive number of authentication failures can also trigger automatic account lockout by Zimbra:

From a forensic perspective, the appearance of such an event in the logs may suggest that an account was potentially targeted.

Once the brute‑force attempt has been identified, it is possible to check when the attacker may have used the compromised account by analyzing the successful logins associated with that user:

Additionally, if you have identified the attacker’s IP address, you can find all successful connections from that address using the following commands:

Once malicious connections have been identified, it is necessary to analyze the account activity following these accesses in order to identify the actions performed by the attacker.

Account compromise through phishing attacks

If no brute‑force attempts have been identified, another common initial compromise vector is the way too familiar: phishing attack! In this case, the attack does not target the Zimbra infrastructure directly: the user first receives an email prompting them to visit a fraudulent page or open a malicious file. Only after clicking does the damage occur (such as credential or session token theft).

In this scenario, you should, if possible, retrieve the malicious email from the user’s mailbox for analysis. If you can obtain it, here are the key pieces of information to collect:

• Date and time of receipt
• Subject of the email
• Sender (From)
• Recipients (To, Cc)
• Reply addresses (Reply-To, Return-Path)
• IP address of the originating sending server
• Names of attachments (if any)
• Results of SPF, DKIM, and DMARC checks
• Identified phishing URLs (if present)

These elements will help reconstruct the attacker’s methodology, provide initial guidance for your investigation and define first remediation measures.

Unfortunately, if you do not have direct access to the user’s mailbox, you will need to rely primarily on Zimbra logs, specifically the events generated by Amavis when analyzing incoming emails.

Suppose you want to identify malicious attachments sent by an attacker to users. Zimbra logs are very useful in this case, as they allow you to track the files that were analyzed and extract information such as their name, size, type, and fingerprint (SHA1).

The following command allows you to identify attachments processed by Amavis during the analysis of incoming messages:

The result above shows that the file Evil.htm was analyzed by Amavis. Several useful pieces of information can be found:

• Date and time: November 12 at 11:15
• SHA‑1 signature of the file: 9d57b71f9f758a27ccd680f701317574174e82d8
• Size: 22,111 bytes
• Content-Type: text/html
• Amavis session ID associated with this analysis: 4384125-19

However, on their own, these elements do not allow you to determine which users received this attachment or who the sender was. To obtain this information, a second command must be executed to retrieve all traces associated with this Amavis session:

From this information, you can now deduce that attacker@example.com sent the file Evil.htm (22,111 bytes) to user25@wavestone.corp on November 12 at 11:15, and that its SHA‑1 signature is 9d57b71f9f758a27ccd680f701317574174e82d8. Not bad, right?

During your investigation, you can further filter the output of these commands to identify:

• Attachments with suspicious extensions (e.g., *.htm, *.html, *.exe, *.js, *.arj, *.iso, *.bat, .ps1, or Office/PDF documents containing macros)
• Files previously observed during the early stages of the incident (for example, a file downloaded by patient zero)

During a phishing campaign involving the delivery of a malicious file, attackers often tend to distribute the same file to multiple users. It is therefore possible to rely on statistical analysis to highlight abnormal values.

The following command allows you to identify identical files present in several incoming emails:

The command above allows you to retrieve, for each attachment in emails received by Zimbra, the number of times it has been observed in other emails, based on its name and SHA‑1 signature.

In this example, the file Evil.htm appears in 40 emails, which, combined with its .htm extension, makes it particularly suspicious. It would therefore be relevant to attempt to retrieve this file from the affected users to verify its legitimacy.

If the analysis of attachments did not help you identify the culprit, there is one last avenue to explore: retrieving phishing detections from SpamAssassin (an antispam engine executed by Amavis).

The following command allows you to identify messages flagged as suspected phishing by SpamAssassin:

However, this command only provides limited information: the sender, the recipient, and the detection rules that were triggered. To obtain more details on the complete analysis, you must retrieve the Amavis session ID associated with the message (here 765283-08), then execute the following command:

This second command provides access to additional information generated during the analysis of the message by Amavis.

However, SpamAssassin results should be interpreted with caution, as its detection rules can generate a significant number of false positives.

Exploiting a vulnerability on the Zimbra web server

Your experience as a forensic investigator has taught you: this is neither the first nor the last time that an application vulnerability allows an attacker to hijack user sessions. Zimbra is no exception, and its web server, which provides access to mailboxes, could very well be vulnerable to this type of attack.

Compromise of the Zimbra web server could, in theory, allow an attacker to capture credentials of users logging in. “But how can we check if Zimbra has been subjected to web intrusion attempts?” you might ask.

A first step is to inspect the proxy (nginx) logs to identify malicious or suspicious HTTP requests targeting the web interface:

Among the indicators to look for in the logs are:

• Unusual POST or PUT requests or requests to unexpected endpoints
• Injection attempts (SQLi, LFI, RCE payloads visible in URIs or parameters)
• Repeated access to non-public resources or atypical scripts
• Strange User-Agents or a high concentration of requests from the same IP
• Numerous 4xx/5xx errors on sensitive paths (indicative of scanning/enumeration)
• Signs of file uploads (attempts to access /tmp, /uploads, etc.) or hits on known web shells

If you observe malicious requests that succeeded (for example, with an HTTP 200 code), it is recommended to conduct a more in-depth investigation on the server to determine whether the exploitation was actually successful.

Compromise of the user’s workstation

If none of the previous scenarios seem to match what you are observing and the initial point of entry remains unidentified, it is possible that the attacker obtained access credentials directly from the user’s workstation.

This type of compromise can occur, for example:

• As a result of a previous phishing campaign
• Because the user executed a malicious program on their machine (cracks, software downloaded from a dubious site, connecting an infected USB drive, etc.)

Once able to execute code on the workstation, the attacker can easily extract credentials stored in the browser, retrieve session cookies, or even install a keylogger to capture keystrokes.

Detecting this type of compromise goes beyond the scope of this article. But keep this possibility in mind: if no intrusion traces appear in Zimbra, the problem may lie elsewhere .

Yes! The investigation is far from over! This first part has allowed you to master Zimbra’s architecture, understand the different sources of evidence, and observe that through Zimbra logs it is possible to identify several compromise techniques. However, the initial access is only the starting point of our research. In a second part, we will continue the post–initial-access analysis. First, we will try to identify the malicious actions carried out by the attacker after compromising an account. Second, we will review the various remediation measures to implement. Stay tuned, a follow-up article will be published soon to delve deeper into these next steps!

Sources

• https://wiki.zimbra.com/wiki/Log_Files
• https://wiki.zimbra.com/wiki/Troubleshooting_Course_Content_Rough_Drafts-Zimbra_Architecture_Component_Overview
• https://wiki.zimbra.com/wiki/Trouble_Shooting_Spam_Score_Changes

Cet article Zimbra Mailbox Compromise: From Analysis to Remediation (Part 1) est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter February 2021 est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter January 2021 est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter December 2020 est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter Novembre 2020 est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter November 2020 est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter October 2020 est apparu en premier sur RiskInsight.

Indicators of the month

Top attack – French shipping giant CMA CGM hit by ransomware cyber attack

CMA CGM announces that it has been affected by a ransomware attack, which disabled its reservation system and affected some of its Chinese offices. The RagnarLocker gang reportedly asked the company to contact them within two days “via a live chat and pay for a special decryption key”. In a statement, the company said it had shut all external accesses to their network and computer applications as a precautionary measure and that the group’s information system was gradually resuming.

Top exploit – Microsoft warns of attackers now exploiting “Zerologon” flaw

Microsoft’s Security Intelligence team says it’s monitoring new attacks that employ public exploits of the recently patched CVE-2020-1472 Netlogon EoP vulnerability, aka Zerologon. The vulnerability carries a critical severity rating from Microsoft as well as a maximum of 10 under the Common Vulnerability Scoring System as it lets anyone with a network toehold obtain domain-controller password.

Top leak – Microsoft leaks 6.5TB in Bing search data via unsecured elastic server

Microsoft earlier this month exposed a 6.5TB Elastic server to the world that included search terms, location coordinates, device ID data, and a partial list of which URLs were visited. According to a report from cyber-security outfit WizCase, the server was password-protected until around 10 September, when “the authentication was removed”.

Cybercrime watch

US CISA report shares details on web shells used by iranian hackers

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) released a malware analysis report (MAR) that includes technical details about web shells employed by Iranian hackers. According to the CISA’s report, Iranian hackers from an unnamed APT group are employing several known web shells, in attacks on IT, government, healthcare, financial, and insurance organizations across the United States. The malware used by the threat actors includes the ChunkyTuna, Tiny, and China Chopper web shells.

Two Russians charged in $17m cryptocurrency phishing spree

U.S. authorities today announced criminal charges and financial sanctions against two Russian men accused of stealing nearly $17 million worth of virtual currencies in a series of phishing attacks throughout 2017 and 2018 that spoofed websites for some of the most popular cryptocurrency exchanges.

Google Chrome bugs open browsers to attack

Google’s release of Chrome 85.0.4183.121 for Windows, Mac and Linux fixed 10 vulnerabilities. The successful exploitation of the most severe of these could allow an attacker to execute arbitrary code in the context of the browser, according to Google. Google Chrome versions prior to 85.0.4183.121 are affected.

Vulnerabilities watch

CVE-2020-1472 – Netlogon Elevation of Privilege Vulnerability

CVSS score: 10.0 CRITICAL

An elevation of privilege vulnerability exists when an attacker establishes a vulnerable Netlogon secure channel connection to a domain controller, using the Netlogon Remote Protocol (MS-NRPC). An attacker who successfully exploited the vulnerability could run a specially crafted application on a device on the network.

CVE-2020-0922 – Microsoft COM* for Windows Remote Code Execution Vulnerability

CVSS score: 8.8 HIGH

A remote code execution vulnerability exists in the way that Microsoft COM for Windows handles objects in memory. An attacker who successfully exploited the vulnerability could execute arbitrary code on a target system.

*The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM is the foundation technology for Microsoft’s OLE (compound documents), ActiveX (Internet-enabled components), as well as others.

CVE-2020-1380 – Scripting Engine Memory Corruption Vulnerability

CVSS score: 7.5 HIGH

A remote code execution vulnerability exists in the way that the scripting engine handles objects in memory in Internet Explorer. The vulnerability could corrupt memory in such a way that an attacker could execute arbitrary code in the context of the current.

Cet article Review of the current news by CERT-W – September 2020 est apparu en premier sur RiskInsight.

Cybercrime watch

The most consequent Patch Tuesday in the history of Patch Tuesday

On March, Tuesday 10th, Microsoft has released updates no less than security vulnerabilities, targeting either the Windows operating systems or associated software. 26 of these vulnerabilities are considered “critical”, which is the highest level of severity. The exploit of some of them allow remote code execution and takeover of vulnerable assets without user interaction.

Mukashi: the new variant of the famous Mirai botnet is targeting Zyxel NAS

The Mukashi botnet has been found performing bruteforce attacks on random hosts. The botnet is using various combinations of credentials in an attemps to log in and seize control of the asset. It is now targeting the Network Access Storage (NAS) from the Zyxel brand by using the recent CVE-2020-9054, which allows for remote code execution on the 5.21 version of the firmware.

Coronavirus is now the most used decoy of all times

During the sanitary crisis linked to COVID-19, the coronavirus has become the most used decoy of all times in phishing attacks. The FBI Internet Crime Complaint Center (IC3) mentions that it can either be email pretending to offer information on the virus itself, test kits, vaccines. Attackers even go to such length like posing as charities asking for donations.

Vulnerability watch

CVE-2020-0684 – Remote code execution in Microsoft Windows

A new remote code execution vulnerability has been found in the Windows operating system that is triggered when a .LNK file is processed (analyzed or executed). An attacker could gain the same privileges as the local user by exploiting this vulnerability.

CVE-2020-3946 – Denial of Service in Vmware Workstation

Some versions of Vmware Workstation and Fusion are exposed to a “use-after-free” vulnerability in the vmnetdhcp service. The successful exploit of this vulnerability currently leads to denial of service but could be used in theory to execute arbitrary code.

CVE-2020-10887 – Firewall bypass in TP-Link routers

A version of the TP-Link firmware is exposed to firewall bypass. This vulnerability originates from an insufficiant filtering when handling IPv6 SSH connections. It can be exploited without authentication and can even be used to peform privilege escalation and code execution, up to root.

Weekly top

The top leak – A 5-million record leak of Mariott’s clients

Cybercriminals have succeeded in obtaining the credentials of two employees on a third-party piece of software used in Mariott resort to provide clients with various services. They used them to access numerous information on Mariott’s clients, including names, email addresses, phone numbers, etc.
It is the second data leak in 24 months for the brand!

The top exploit – CVE-2020-0796 – Remote code execution vulnerability in the SMB protocol

SMB is a network protocol used for file sharing, printers, and for other network purposes. The Microsoft SMB 3.1.1 (SMBv3) is suject to a vulnerability in the way it handles some requests. Unauthenticated attackers can use this vulnerability to remotely execute code on SMB servers as well as clients.

The top attack – One of the largest Czech hospital hit by a cyberattack

The Brno university hospital in Czech Republic has been hit by a major cyberattack in the midst of the COVID-19 outbreak. It has been forced to shut down all IT equipment and information system. Consequently, surgical procedures have been rescheduled and newly infected patients transferred to other hospitals.

Software version watch

Cet article Review of the current news by CERT-W – March 2020 est apparu en premier sur RiskInsight.

Un besoin de défense active …

Aujourd’hui, des attaques de plus en plus sophistiquées touchent tous les secteurs d’activité et ciblent des organisations spécifiques en utilisant des techniques toujours plus complexes. Ces attaques visent à contourner le périmètre de défense existant, mais également à persister sur le SI cible sans déclencher immédiatement l’attaque. Ainsi, l’attaquant améliore sa connaissance de la cible depuis l’intérieur pour lancer ensuite une attaque aux conséquences importantes pour les métiers (vols de données, destruction du SI, usurpation d’identité…).

L’exemple le plus marquant reste l’attaque Carbanak/Anunak, qui a visé plus d’une centaine d’établissements bancaires. Les attaquants se sont introduits discrètement dans le système via du spear phishing (mail malveillant ciblé et personnalisé) puis une série de rebonds. Ils s’y sont ensuite maintenus sur le long terme, observant patiemment les actions des opérateurs bancaires pendant plus d’un mois et demi. Les systèmes de surveillance des banques n’ont pas repéré les traces de persistance laissées par les attaquants, qui ont veillé à rester en dessous des seuils de détection. Une fois les procédures internes des banques identifiées, les attaquants ont pu détourner lentement mais sûrement plusieurs dizaines de millions de dollars.

Les stratégies traditionnelles de défense passive inspirées du modèle du château fort, c’est à dire visant à se protéger (fermeture des flux, antivirus, IPS, etc.), ne suffisent plus à elles seules, et ne sont pas adaptées pour répondre à ce type de menaces.

Il est ainsi devenu nécessaire d’accepter le caractère inévitable de l’intrusion et se préparer à y faire face. Dans cette optique, la défense active vise à détecter puis réduire l’efficacité ou supprimer une attaque.

… pour 3 niveaux d’intervention

En fonction de la portée des moyens utilisés par l’attaquant, on peut identifier plusieurs niveaux de réponse active :

1)     Répondre avec les moyens propres de l’entreprise

Les actions de réponse active visent ici à tromper l’attaquant ou encore le désinformer et collecter des informations sur ses méthodes.

Dans un premier temps, pour analyser les actions des attaquants de façon proactive on pourra utiliser des serveurs honeypot, qui simulent des serveurs d’importance accessibles afin d’y attirer les attaquants et de les surveiller, ou encore des clients honeypot, des clients volontairement vulnérables pour détecter les tentatives d’attaques telles que le waterholing ou le drivebydownload en les faisant naviguer sur les sites visités par les collaborateurs de l’entreprise.

Dans un second temps, pour duper et/ou ralentir l’attaquant on pourra renvoyer de fausses informations sur le système d’exploitation lorsque l’attaquant lance des scans, ou encore simuler de faux services (en utilisant Portspoof par exemple pour simuler des ports ouverts et des services factices capables d’interagir avec l’attaquant).

L’augmentation du temps de réponse de certains services par l’utilisation de techniques de type « tarpit » (seau de goudron) permet de gêner l’attaquant sans impacter les utilisateurs légitimes. De plus, on peut réduire la fenêtre d’attaque en restaurant régulièrement les serveurs web dans un état propre connu (SCIT server) de sorte à réduire la fenêtre de temps durant laquelle l’attaquant peut compromettre le serveur.

Dans le but d’épuiser les ressources et la motivation de l’attaquant, on pourra le tromper avec de fausses vulnérabilités sur un serveur web. Enfin, bloquer les adresses IP tentant d’appeler des ports inhabituels (Artillery) jugulera ses manœuvres d’expansion dans le réseau.

La défense active permet ainsi de comprendre les attaques, de les ralentir et d’épuiser les ressources de l’attaquant. Les informations ainsi obtenues permettent d’adapter et d’optimiser les moyens de défense traditionnels pour bloquer les attaques plus efficacement.

2)     Intervenir sur les moyens entre la cible et l’attaquant

Dans la chaîne de communication utilisée par les attaquants se trouvent un certain nombre d’acteurs : des FAI, des tiers compromis par l’attaquant, des hébergeurs, des noms de domaines malveillants, etc.

Il est possible d’intervenir sur les moyens intermédiaires utilisés par l’attaquant pour juguler l’attaque, en prenant contact avec les acteurs en charge de ces moyens. On pourra par exemple contacter les FAI en cas d’attaque DDoS, pour filtrer le trafic avant l’arrivée sur le SI de l’entreprise ou encore faire saisir les noms de domaines par décision de justice (par exemple pour démanteler un botnet).

On pourra également contacter un hébergeur pour faire fermer un site malveillant ou faire disparaitre le trafic en amont avec du DNS Sinkholing (faire pointer le trafic malveillant vers un domaine inexistant).

Ces actions permettent à la fois d’obtenir des informations de façon indirecte sur l’attaquant (compte utilisé pour acheter un nom de domaine malveillant, etc.) mais aussi de le ralentir et de le contrarier dans ses plans. De plus, elles doivent être anticipées – si possible – en créant des réseaux de contacts auprès des principaux fournisseurs ou équipes de réponse à incident, en particulier pour pouvoir agir rapidement à l’étranger.

3)     Contre-attaquer directement chez l’attaquant

Il est à noter que ce type de réponse est identifié comme illégal en France par la loi Godfrain de 1988 et plus particulièrement par les articles 323-1 et suivant du Code pénal traitant des atteintes aux systèmes de traitement automatisé de données.

Il est cependant intéressant de mentionner ces méthodes car elles peuvent être utilisées par d’autres pays où elles sont autorisées mais également par les forces de l’ordre dans un certain nombre de cas bien particuliers.

On peut distinguer deux types de réponse dans ce troisième niveau :

• les actions de réponse visant à recueillir des informations sur l’attaquant ;
• les actions de réponse visant à rendre inopérant les systèmes d’attaque directement chez le cybercriminel.

Dans le premier type de réponse on pourra mentionner l’envoi de fichiers « piégés », des fichiers balisés, capables de renvoyer un beacon dès lors que celui-ci est ouvert/copié dans un endroit inhabituel ou utiliser des failles de sécurité chez l’attaquant pour prendre le contrôle du serveur de commande et de contrôle (C&C) et identifier les données exfiltrées.

Dans le second type de réponse on peut penser à injecter du code malveillant dans un fichier exfiltré par l’attaquant et par la suite détruire logiquement ses systèmes, ou encore tenter de viser sa bande passante par un DoS ciblé. Finalement on peut envisager autant de scénarios que de canaux d’attaques.

Ces méthodes doivent être manipulées par les autorités compétentes afin de se conformer aux exigences légales.

Pour conclure, les mesures de défense active ne se résument pas uniquement à contre-attaquer directement mais bien à se doter de moyens permettant de mieux comprendre, détecter et réagir aux attaques. En complément des stratégies traditionnelles de défense, l’importance de la réponse active se révèle aujourd’hui un sujet en plein développement dans les équipes de réponse à incident les plus avancées. Le paradigme à garder en tête reste inchangé : toujours avoir un coup d’avance !

Cet article Défense active : répondre activement aux attaques cybercriminelles est apparu en premier sur RiskInsight.

Indubitablement, nous sommes entrés dans l’ère des cyberconflits

Les incidents cyber ont beaucoup occupé l’espace médiatique ces dernières semaines.
Le piratage de Sony a pour sa part marqué un tournant dans la portée des attaques informatiques. Celui-ci a détruit la quasi-totalité du système d’information de l’entreprise et a contraint ses employés à revenir au papier et au crayon pour travailler. Une vaste partie des données internes de l’entreprise a également été mise en pâture sur Internet. Jusqu’alors, le but de telles attaques était généralement de dérober des capitaux ou des secrets industriels. Mais dans ce cas, l’objectif était clairement de mettre l’entreprise à genoux. L’affaire a d’ailleurs pris un tournant politique, les États-Unis ayant ouvertement accusé la Corée du Nord de l’attaque.

Les conflits cyber entre États sont largement répandus aujourd’hui. En 2007, des sites du gouvernement, de banques, médias et opérateurs téléphoniques estoniens ont été victimes d’attaques par déni de service. La Russie est fortement soupçonnée d’être à l’origine de ces offensives ayant paralysé le pays. En 2013, ce sont les systèmes d’information de banques et de chaînes de télévision sud coréennes qui ont été bloqués par des attaques émanant de Corée du Nord. Plus récemment, l’opération djihadiste #OpFrance, qui visait à défacer un maximum de sites français, a montré à tous que désormais les conflits se propagent également dans le monde virtuel.

Pour le département de la Défense des États-Unis mais aussi pour le Ministère de Défense en France, le cyberespace est d’ailleurs devenu un cinquième domaine d’intervention, après l’air, la terre, la mer et l’espace. L’espace cyber est donc clairement devenu un terrain de luttes permanentes…mais ces affrontements peuvent-ils être considérés comme des actes de guerre ?

Qu’est-ce que la cyberguerre ?

L’importance d’une définition précise du terme de « cyberguerre » n’est pas uniquement d’ordre linguistique. Derrière cette notion se cache un ensemble de questions juridiques et diplomatiques complexes. L’état de guerre impose en effet l’application de régimes légaux et de règles de rapports mutuels entre États bien spécifiques. Dans le cas de l’attaque contre Sony, Barack Obama a fait redescendre la tension en précisant qu’il ne s’agissait pas d’un acte cyberguerre mais plutôt de « cybervandalisme ». Et cette nuance n’est pas dénuée d’importance : en cas de guerre avérée, les clauses des contrats d’assurance auraient empêché toute indemnisation de l’entreprise !

La question de la contre-attaque se pose également : à partir de quand est-elle autorisée, et quelles formes peut-elle prendre ? Quels objectifs peuvent légitimement être visés par des cyberattaques ? Ce sont précisément les questions auxquelles a tenté de répondre en 2012 le Centre d’excellence de cyberdéfense coopérative de l’OTAN (CCDCOE) de Tallin, en publiant un manuel juridique de cyberguerre. La position défendue est que de manière générale, le Droit des conflits armés établi lors des conventions de La Haye et de Genève s’étend au monde cyber.

Une attaque informatique pourrait donc constituer un acte de guerre si ses conséquences sont comparables à celles d’un conflit armé traditionnel, c’est-à-dire si son but est de « de blesser ou tuer des personnes, ou d’endommager ou détruire des objets ». Cela signifie qu’une cyberattaque serait un acte de guerre à partir du moment où elle a des répercussions directes sur le monde physique.

Et c’est précisément le cas des attaques contre les systèmes d’information industriels, qui pilotent les systèmes de production de grands groupes manufacturiers, ou des infrastructures telles que des réseaux électriques ou des barrages. De telles agressions pourraient avoir un lourd coût humain et environnemental, et c’est pourquoi les États imposent souvent des mesures de sécurité strictes à leurs Opérateurs d’Importance Vitale (OIV) ou aux sites dangereux classés Seveso. En France, les travaux en cours sur la Loi de Programmation Militaire visent à préciser ces exigences. Le manuel entend également fixer des limites éthiques à la cyberguerre. Il préconise par exemple l’interdiction d’attaquer des hôpitaux ou des centrales nucléaires.

Attaques de SI industriels

Les rédacteurs du manuel de Tallinn estiment qu’« aucun incident n’a été de façon claire et publique caractérisé par la communauté internationale comme ayant atteint le seuil d’une agression armée ». Pourtant, les attaques contre les systèmes d’information industriels sont aujourd’hui une réalité. En 2013 par exemple, des pirates se sont introduits sur le réseau de production d’une aciérie allemande et ont détruit plusieurs équipements en arrêtant les hauts fourneaux de façon inopinée.

Mais c’est sans conteste l’infection de systèmes de contrôle de turbines et de centrifugeuses d’enrichissement en uranium iraniennes par le ver Stuxnet qui ressemble le plus à un acte de cyberguerre. Ce malware d’une complexité inédite aurait été mis au point par Israël et par les États-Unis, et a considérablement retardé le programme nucléaire iranien. Si le CCDCOE ne considère pas cette attaque comme un acte de guerre, les experts sont divisés sur la question et certains considèrent qu’il s’agit d’un recours à la force illégal selon le droit international.
Par ailleurs, les principes de proportionnalité des contre-attaques et de protection des populations civiles préconisés par le droit international sont difficiles à respecter en cas de cyberguerre. Les attaques sont généralement difficiles à confiner : dans le cas de Stuxnet, le ver a été retrouvé en Chine, en Allemagne et en Indonésie.

Certains considèrent qu’une nouvelle législation est à mettre en place pour cadrer les affrontements cyber. Le sommet de l’OTAN au Pays de Galles en 2014 a d’ailleurs fait ressortir des positions différentes de celles défendues dans le guide de Tallinn. Il a été affirmé que « les cyberattaques peuvent atteindre un seuil susceptible de menacer la prospérité, la sécurité et la stabilité des États et de la zone euro-atlantique [et] leur impact sur les sociétés modernes pourrait être tout aussi néfaste que celui d’une attaque conventionnelle ». Comment en effet ne pas parler de guerre dans le cas d’une attaque d’une place financière, qui pourrait provoquer une crise économique aux conséquences catastrophiques ?

Ces désaccords montrent à quel point les limites restent floues. Les lois internationales sont généralement dictées par la conduite et par les réactions des États : les véritables règles de la cyberguerre mettront du temps à être établies et risquent d’évoluer avec le temps. Quoi qu’il en soit, nous observons dès à présent que les Systèmes d’Information d’importance vitale seront des cibles privilégiés de ces conflits nouveaux. La mise en œuvre de stratégies de cyberdéfense apparaît donc comme un impératif pour les entreprises et les États, qui ne doivent pas attendre la survenue d’une véritable cyberguerre pour se protéger.

Cet article Sommes-nous entrés dans l’ère des cyberguerres ? est apparu en premier sur RiskInsight.

Face à ce constat, les entreprises se sont rapidement interrogées sur les moyens de protection possibles.  Le marché s’est adapté. Aujourd’hui, deux stratégies se dessinent, entre solutions historiques manuelles et solutions novatrices hybrides (Cloud et/ou on-premise).

Une question se pose toutefois : la mise en œuvre d’une telle solution de protection, certes adaptée aux besoins, suffit-elle pour s’assurer d’une efficacité solide en cas d’attaque avérée ? La réponse est non !

Imaginez, vous avez subi pendant plusieurs jours les effets d’une attaque DDoS, avec des conséquences inacceptables pour le maintien de vos activités. Vous décidez de mettre en place une solution de protection ad hoc. Le projet démarre, vous choisissez une solution, elle est installée et fonctionne. Vous voilà enfin équipé d’une solution d’une efficacité prometteuse. Avec un simple ordre de bascule à donner à votre équipe de production ou à un fournisseur, la solution sera mise en route. Vous êtes confiant.

Activation, surveillance, désactivation : les 3 piliers d’une stratégie de protection anti DDoS

Pour autant, vous pourriez avoir oublié de répondre à un certain nombre de questions clés.

Sur quels critères de détection et à quels seuils serez-vous en mesure de passer l’ordre d’activation de la solution ? Serez-vous assez réactif pour qu’il ne soit pas trop tard vis-à-vis des impacts business ? L’échelle du temps DDoS est proche du ¼ d’heure… Une fois la solution activée, quelles seront les premières actions à entreprendre ? Avez-vous identifié ou contrôlerez-vous les effets de bord qu’elles pourront engendrer sur votre environnement de production ? Faudra-il communiquer aux clients, au réseau commercial ? Durant l’attaque, êtes-vous certain d’être apte à communiquer efficacement avec votre prestataire en charge de la solution ? Pourrez-vous aisément constater l’efficacité de ses services ? Connait-il votre contexte, votre infrastructure ? Est-il à jour des derniers changements pour éviter une protection partielle ? Par analogie avec l’ordre d’activation, saurez-vous quand et comment décider du retour à la normale ? Enfin, avez-vous suffisamment de visibilité pour déterminer si l’attaque continue ou non en amont des barrières défensives ?

Les retours d’expérience montrent que la mise en place d’une solution protectrice seule, sans réponse à l’ensemble de ces questions, ne suffit pas.

Aussi ne faut-il pas se cantonner à la simple souscription d’un service de protection : des moyens et des processus de détection, d’activation, de communication, d’arbitrage et retour à la normale devront être élaborés et régulièrement expérimentés. Les actions majeures devront être rigoureusement formalisées : le déclenchement de la solution de protection et le retour à la normale (qui décide, qui réalise, sur quelles informations, avec quelle réactivité…). Par ailleurs, le volet surveillance et gestion de crise pendant l’attaque ne doit pas être négligé (quels moyens pour vérifier que l’attaque a toujours lieu, avec quel effet, quels seuils/indicateurs pour déclencher les escalades).

Tests et exercices : les garant de la bonne gestion d’une attaque DDoS

Au-delà de la formalisation, trois types de tests s’avèrent indispensables.

Les plus simples sont les tests de « bascule à vide » : sans contrainte de temps particulière, il s’agit de mettre en action les différents modes opératoires liés à l’activation, au maintien ou à la désactivation de la solution de protection. Au-delà de permettre la formation des équipes concernées, ces tests permettent de juger la qualité des procédures techniques ; ils permettront également leur amélioration continue afin d’assurer au mieux leur efficacité en cas d’attaque.

Des tests de « bascule en conditions réelles » sont ensuite requis : à l’opposé de la « bascule à vide », une attaque simulée sera ici commanditée auprès d’un organisme tiers afin que les équipes techniques puissent s’exercer en conditions réelles. Les mêmes modes opératoires techniques seront mis à l’épreuve, dans un objectif cependant différent : le respect des échéances théoriques.

Des exercices de « gestion de crise » sont également à prévoir. Complémentaires des deux premières séries ci-dessus, il s’agit là de se focaliser sur l’expérimentation de la gestion de crise et non sur les aspects techniques. Ces tests permettront de juger la qualité de la gestion en répondant notamment aux bonnes questions en dehors de la sphère technique et en intégrant la communication, le juridique ou encore la relation clients. Chaque tâche trouve-t-elle rapidement son porteur ? L’ordonnancement prévu est-il respecté ? Les moyens nécessaires sont-ils accessibles (matériels, salles, interlocuteurs, etc.) ? Les rôles prédéfinis de chacun sont-ils connus de tous et à l’avance ? La remontée des informations au Responsable de crise est-elle correctement réalisée ?

Les solutions techniques ne peuvent suffire à gérer toutes les composantes d’une attaque DDos. Nécessaire et complémentaire, la mise en place d’une organisation interne apte à gérer l’attaque et la crise doit être considérée par les entreprises pour se protéger correctement et efficacement.

Cet article Lutte anti-DDoS : la technique ne suffit pas, organisons-nous ! est apparu en premier sur RiskInsight.

Une vulnérabilité critique concernant l’interpréteur de commandes Bash a été publiée hier (CVE-2014-6271). Dans certaines conditions, cette vulnérabilité permet à un attaquant d’exécuter du code arbitraire. Le score CVSS indiquant la gravité de la vulnérabilité est évalué à 10, la note maximale.

Cette vulnérabilité affecte les versions 1.14 à 4.3 de Bash et des attaques sont en cours sur les services vulnérables.

Des correctifs de sécurité ont été publiés mais sont incomplets. Cette nouvelle vulnérabilité a été identifiée sous le numéro CVE-2014-7169.

Quels systèmes sont impactés ?

Les distributions Linux sont les principaux systèmes impactés par la vulnérabilité, car elles intègrent l’interpréteur de commande Bash par défaut. C’est également le cas de Mac OSX, et des utilisateurs de Cygwin sous Windows.

Cependant, de nombreux logiciels et services réalisent des appels système via Bash et sont par conséquent vulnérables.

Il est aujourd’hui confirmé que cette vulnérabilité peut s’exploiter à distance dans certains cas :

• Sur un serveur web pouvant faire appel à Bash (scripts cgi, appels systèmes Python ou PHP).
• Sur un serveur SSH (uniquement après authentification).
• Sur un service DHCP.

Plus généralement tout autre service pouvant faire appel à Bash pourrait être affecté.

Cette faille peut notamment être exploitée afin de réaliser une élévation de privilège sous Mac OSX, qui intègre également Bash par défaut.

Comment vérifier si je suis vulnérable ?

Il est possible d’identifier la vulnérabilité via l’exécution de la commande suivante :

$ env var='() { ignore this:;}; echo vulnerable’ bash -c /bin/true

Dans le cas d’un serveur vulnérable, la commande affichera « vulnerable ».

Attention : cette commande permet de vérifier la bonne application des correctifs disponibles. Cependant, il semblerait que ces correctifs ne mitigent pas l’ensemble des attaques possibles, en particulier l’exploitation locale.

Quelles sont les actions à mener ?

1-  Recenser les produits vulnérables

La plupart des systèmes d’exploitation Linux, ainsi que Mac OS X sont affectées par cette vulnérabilité.

Cependant, cette vulnérabilité pourrait également être présente sur d’autres équipements se basant sur des systèmes UNIX. On pense notamment aux appliances réseau et de sécurité, ainsi qu’aux systèmes embarqués.

Il convient de se référer aux bulletins publiés par les éditeurs, lorsqu’ils sont disponibles,  pour plus d’informations.

2- Appliquer les correctifs de sécurité

Bien que son efficacité soit partiellement remise en cause, le correctif de sécurité publié pour Bash permettra de se prémunir des attaques distantes les plus communes.

3- Détecter les attaques

Afin de compléter les mécanismes de protection mis en place, il est possible de détecter ou de bloquer les attaques les plus simples via l’utilisation d’équipements de type IDS/IPS.

Certains éditeurs proposent actuellement des signatures spécifiques à cette attaque, qui reposent sur la détection des caractères spéciaux “() {” dans les en-têtes des requêtes http.

Il est également recommandé d’analyser les logs existants pour détecter une exploitation passée de ShellShock.

Ce bulletin sera complété dans les prochains jours. Pour plus de précisions, vous pouvez contacter le CERT-SOLUCOM

Cet article Faille critique Shellshock : recommandations du CERT-Solucom est apparu en premier sur RiskInsight.

Une faille de sécurité critique Heartbleed a été identifiée dans les bibliothèques OpenSSL. Elle permet à un attaquant externe, non authentifié, de récupérer le contenu de la mémoire du serveur.

Les tests que nous avons menés ont montré qu’il était possible de récupérer les données échangées avec le serveur (dont les logins / mots de passe des utilisateurs), ainsi que des fichiers de configuration.

Recommandations

1- Nous recommandons dans un premier  temps de réaliser un inventaire des équipements utilisant ces bibliothèques, et de procéder à un test de vulnérabilité : soit par l’analyse de la version installée , soit via l’utilisation d’un script ;

2- Ensuite, d’appliquer les correctifs de sécurité ;

3- Il est également recommandé de considérer comme compromises les informations ayant transité par ces équipements, et de forcer un renouvellement des mots de passe (utilisateurs, serveurs, etc) ;

4- La clé privée du serveur pouvant également être impactée, il est recommandé de considérer la révocation et le renouvellement des certificats concernés, à minima sur les systèmes sensibles.

Produits concernés

•  OpenSSL 1.0.1 à 1.0.1f et OpenSSL 1.0.2-beta

•  Les branches 0.9.8 et 1.0.0 ne sont pas vulnérables

Attention, de nombreuses solutions packagées et appliances reposent sur ces bibliothèques et sont vulnérables : reverse proxy, passerelle VPN, etc.

Cet article sera complété dans les prochaines heures ; pour plus de précisions, vous pouvez contacter le CERT-Solucom.

Cet article Faille critique Heartbleed : recommandations du CERT-Solucom est apparu en premier sur RiskInsight.

Il est aujourd’hui nécessaire d’allier des mesures à la fois techniques et organisationnelles permettant de répondre à deux enjeux cruciaux : la détection (avant l’attaque) et la réaction (après l’attaque).

Un choix technologique et stratégique

Les mesures techniques visent à mettre en place une protection physique par le biais d’équipements de sécurité, pouvant s’opérer à deux niveaux : en amont du SI (au niveau des réseaux de l’opérateur) et directement en frontal (sur le site à protéger).

Plusieurs stratégies sont alors possibles :

• Une protection exclusivement manuelle : il s’agit de la mise en place de filtrages spécifiques par l’opérateur et de la configuration d’équipements de sécurité du SI. Cette stratégie à faible coût, pouvant être qualifiée de « protection par défaut », est aujourd’hui la plus communément utilisée.
• Un « boîtier anti-DDoS » en frontal : proche du SI, ce boîtier sert de « bouclier » et permet une protection immédiate, avec réinjection du trafic légitime. Il nécessite en revanche une expertise interne conséquente etpeut ainsi entraîner d’importants coûts récurrents, en plus des coûts liés à l’investissement . De plus, sans protection en amont du SI, le niveau de protection offert par le boîtier face aux attaques volumétriques est limité à la capacité du lien réseau qui le précède. Utilisé seul, un tel boîtier montre rapidement ses limites.

• Une protection Cloud, en amont : située dans le Cloud ou le réseau opérateur, cette protection permet de bénéficier d’un service et d’une expertise externalisés. Grâce à ses mécanismes de redirection ponctuelle ou permanente, de nettoyage du trafic et de réinjection, elle permet la gestion d’attaques à forte volumétrie. Cette solution entraîne en revanche des coûts élevés et ne permet pas de se protéger contre l’ensemble des différents types d’attaques.

• Une stratégie hybride : il s’agit ici d’allier deux des trois premières stratégies, à savoir une protection distante dite « Cloud » et un boîtier physique, en frontal du SI. Malgré un coût logiquement le plus élevé, les avantages viennent s’additionner et permettent de faire face à l’évolution de la menace. Les attaques à la fois volumétriques et par saturation de table d’état, aux niveaux réseau ou applicatif peuvent ici être maîtrisées et la continuité du service est assurée.

Ce choix de stratégie reste complexe et diffèrera évidemment d’une entreprise à l’autre en fonction des besoins en matière de sécurité. Il dépendra en effet de son niveau d’exposition à la menace et de la gravité des impacts en cas d’attaque.

Des réponses également organisationnelles

Au-delà de la protection physique, il est important d’acquérir un certain nombre de bonnes pratiques permettant une gestion de crise optimale en cas d’attaque.

Ces mesures organisationnelles peuvent être classées en trois étapes chronologiques :

Bien qu’elles soient aujourd’hui démocratisées, inévitables pour la plupart et parfois ravageuses, les attaques par déni de service distribué engendrent des impacts pouvant être relativement maîtrisés, pourvu que la question de la protection ait été traitée à temps par l’entreprise.

Malheureusement, force est de constater que peu d’entreprises ont aujourd’hui procédé à l’acquisition d’une protection adaptée à la menace cybercriminelle actuelle.

L’actualité forte dans ce domaine les sensibilise néanmoins et sera sans doute un catalyseur de la mise en place de ces mesures

Cet article DDoS, quelle stratégie de protection ? est apparu en premier sur RiskInsight.

De nouvelles formes d’attaques

Au fil des années, les débits internet ont augmenté, les performances des équipements et la répartition des charges également ; l’attaque DDoS historique visant à submerger une victime par de multiples requêtes ne suffit plus.

De ce fait, les attaques se diversifient, deviennent « plus intelligentes » et plus complexes à éviter. On distingue alors deux grandes familles :

• Les attaques volumétriques : elles visent à submerger des équipements ou liaisons stratégiques afin de les rendre indisponibles. La nouveauté est qu’elles s’opèrent tant sur la couche réseau (TCP SYN flood…) qu’applicative (par exemple HTTP GET floods…) pour épuiser les ressources des serveurs exposés sur internet.

• Les attaques « par saturation de tables d’état » : plus astucieuses, ces attaques ne requièrent pas nécessairement un grand nombre de ressources attaquantes. Leur principe est d’utiliser les limites des protocoles de communication pour commettre des méfaits. Elles visent également les couches réseau (Slow attacks…) et applicative (Slowloris…). Elles s’avèrent très efficaces et malheureusement difficiles à contrer au vu de leur comportement a priori bénin.

Pour ces deux familles, les attaques visant la couche applicative resteront de loin les plus difficiles à détecter. En effet, considérées comme des flux réseaux légitimes, elles ne pourront pas être arrêtées par les équipements de protection classiques comme les pare-feux. Une sécurité proche de la couche applicative sera donc nécessaire, en utilisant par exemple des équipements de type Web Application Firewall (WAF) ou des solutions spécifiques anti-DDOS…

Des conséquences bien réelles pour les entreprises

En cas d’attaques DDoS, l’entreprise ciblée doit faire face à des conséquences importantes.

À la fois visibles et immédiates, les conséquences directes d’une attaque DDoS recouvrent par exemple l’indisponibilité de services cruciaux (site de vente en ligne, plateforme partenaire…) entrainant une perte financière évidente, le dysfonctionnement des processus métiers mais aussi l’atteinte à l’image due à la médiatisation de l’évènement.

Moins immédiates, les conséquences indirectes n’en sont pas moins importantes : une attaque DDoS peut également être un moyen de diversion permettant d’établir une attaque ciblée plus évoluée. En effet, en jouant un rôle de « bélier » visant la mise à mal des moyens de protection du SI, une intrusion deviendra plus facile… Les attaques commises contre les sociétés RSA ou Sony en sont des exemples criants.

Comment se protéger contre ces attaques de plus en plus courantes ?

Au vu de leurs impacts immédiats et visibles de tous, les DDoS deviennent un des outils attitrés des cybercriminels. Parallèlement, en pleine montée de l’hacktivisme, des outils automatisés et simples d’usage ont fait leur apparition sur Internet (notamment « LOIC », utilisé par les Anonymous). Ces nouveaux services « clé en main », peu coûteux, ont permis une démocratisation des attaques par déni de service ; elles deviennent aujourd’hui accessibles à tout un chacun.

Après les nombreux évènements de l’année 2012 et la récente attaque record contre Spamhaus, les DDoS représentent aujourd’hui une menace évidente. La question de la « protection anti-DDoS » entre donc au cœur des décisions SSI pour l’ensemble des grandes entreprises à risque. Mais comment se protéger ? …

Cet article DDoS, les attaques se diversifient ! est apparu en premier sur RiskInsight.

Un modèle de sécurité qui atteint ses limites

La protection des informations avec les moyens conventionnels (pare-feu, antivirus, correctif, contrôle d’accès…) comporte de nombreuses limites  ;  les attaquants les connaissent et surtout, savent les contourner efficacement. Les attaques par ingénierie sociale permettent d’accéder aux informations d’utilisateurs légitimes et ce malgré de nombreuses sessions de sensibilisation en entreprise, les failles « zero-day » permettent d’attaquer des systèmes même maintenus à jour, l’encapsulation ou encore le chiffrement de trafic qui permettent de traverser les pare-feux sans être inquiétés.

Doit-on pour autant baisser les bras et reculer face aux menaces? Non, certainement pas ! Il s’agit de réorienter ses efforts différemment, accepter les risques,  et se doter des moyens permettant de limiter l’impact des attaques. La détection des attaques et l’identification de réactions appropriées sont donc à prioriser pour 2013.

 Détecter et réagir : les priorités de 2013

Ce changement d’orientation nécessite de nombreuses évolutions, tant en termes technique qu’organisationnel. Il faut réfléchir à la mise en place de nouveaux moyens, internes ou externes, afin de mieux observer le SI et d’en tirer des alertes pertinentes. Nous pensons bien évidemment aux solutions de surveillance de journaux classiques mais pas uniquement ! De nouvelles solutions, spécialisées dans les analyses statistiques permettent d’obtenir des vues pour détecter les fameux signaux fiables relatifs aux attaques. D’autres produits permettent de détecter dans les flux de données des comportements étranges, en simulant l’ouverture des pièces jointes ou des fichiers. Même si cela peut paraître démesuré, certaines organisations ont mis en place ces solutions sur 2012 et en tirent aujourd’hui des bénéfices concrets.

Et comme l’outil ne résout rien seul, certains processus seront aussi à revoir, en particulier sur la surveillance du SI et la gestion de crise. La création, ou le renfort, d’une cellule dédiée en charge de ces problématiques, le fameux CERT ou SOC, pourra être une solution. Cette cellule sera à même de piloter les crises, de prendre les bonnes décisions pour limiter les impacts et d’empêcher les propagations.

Différents scénarios de crise sont à envisager en fonction du métier et de l’exposition : attaque en déni de service, vol d’information, défacement de site, vols de données sensibles, mais aussi et peut être surtout compromission du SI… Ils devront être testés par les équipes opérationnelles mais également les métiers et la direction générale, acteurs essentiels en cas d’attaques cybercriminels.

Bien évidemment, il n’est pas question d’abandonner toutes les mesures de protection. Bien souvent, elles retarderont la réussite de l’attaque, voire même sur certains périmètres très protégés et face à des attaquants de niveau intermédiaire, elles les bloqueront. Mais aujourd’hui, se baser uniquement sur une protection est illusoire, il est indispensable de revoir sa stratégie sécurité et en 2013 d’orienter sa réflexion vers la détection et la réaction !

Cet article Une nouvelle année pour une nouvelle stratégie sécurité : priorité à la détection et la réaction est apparu en premier sur RiskInsight.

Comment se fait-on clickjacker ?

Pour mener une attaque par clickjacking, un attaquant va procéder de la manière suivante :

1- Il identifie sa cible, une page non-protégée contre ce type d’attaque, qui permet de réaliser une action en cliquant sur un lien ou un bouton.

2- Il intègre cette page dans une page malveillante qu’il maîtrise

3- Il s’arrange pour que, lorsque la victime clique sur un élément de la page, elle clique en réalité sur un bouton ou un lien provenant du site vulnérable

Par exemple, il peut utiliser les propriétés de style offerte par HTML/CSS pour rendre transparente la page vulnérable. Dans l’exemple ci-dessus, l’utilisateur verra le bouton « Jouer ! » mais cliquera en réalité sur le « Bouton 1 », provenant d’un site différent !

Les exemples les plus fréquents d’attaque par clickjacking sont les “likejacking” et “tweetbomb”. La première, ciblant le réseau social, a pour objectif de faire « liker » une page, c’est-à-dire d’augmenter sa popularité. La seconde vise à diffuser sur Twitter un message, la plupart du temps publicitaire.

Les risques se limitent-ils aux réseaux sociaux ?

Mais non ! Il est important de noter que les enjeux liés à ce type d’attaques ne s’arrêtent pas à la pollution de réseaux sociaux. De même que les attaques par rejeu de requête (XSRF),  les attaques par clickjacking permettent d’exécuter des actions à l’insu de la victime.

Il est donc tout à fait imaginable d’employer ce type d’attaque afin, par exemple, d’ajouter des articles dans le panier des clients d’un site de e-commerce. Pour cela, il suffirait à l’attaquant de reprendre le scénario précédent, mais de remplacer les boutons « like » de Facebook par le bouton « Ajouter au panier » du site e-commerce. L’attaquant pourrait augmenter grandement les ventes de son produit !

 Comment se protéger efficacement ?

La protection contre ce type d’attaques est à considérer du double point de vue de l’utilisateur et du responsable du site internet qui sert – involontairement – de support à l’attaque. La protection idéale nécessite donc sensibilisation et moyens techniques.

Pour les utilisateurs finaux en effet, se protéger implique d’avoir conscience du risque et de faire preuve de vigilance en surveillant ses fréquentations sur le web ! Il convient de rester méfiant à l’égard des liens commerciaux et des jeux ou concours qui promettent monts et merveilles.

Pour les équipes en charge de la sécurité des applications web, deux éléments sont à considérer pour mitiger le risque lié au clickjacking : l’utilisation d’en-têtes http spécifiques, et l’emploi de protections en JavaScript.

 Utiliser les en-têtes http appropriés pour se protéger

Il est d’une part possible d’utiliser l’en-tête http « X-FRAME-OPTIONS », qui va indiquer au navigateur à quelles conditions le contenu du site peut être intégré dans une iframe. Il est possible de lui spécifier trois valeurs :

• « DENY », qui va interdire l’inclusion de la page ;
• « SAMEORIGIN », qui va autoriser uniquement les sites du même domaine à inclure la page ;
• « ALLOW-FROM », qui permet de spécifier le ou les domaines autorisés à inclure la page.

Utiliser JavaScript pour s’assurer que ses pages ne sont pas dissimulées

En complément, il est possible d’utiliser du code JavaScript pour se protéger. Pour cela, ces codes vont par exemple s’assurer que la page est bien au niveau supérieur et qu’elle sera visible. Il faut néanmoins reconnaître qu’aucun de ces codes n’est totalement fiable.

Pour des informations détaillées sur les implémentations de ces protections, le site de l’OWASP propose une page dédiée à ce sujet.

La réauthentification, meilleure arme de protection pour les actions sensibles

La solution la plus efficace reste de ré-authentifier l’utilisateur pour les actions sensibles, par exemple en lui redemandant son mot de passe ou en utilisant un second facteur d’authentification, comme cela est l’usage sur les sites de banque en ligne.

Ces protections sont-elles couramment déployées ?

En un mot : non. Malheureusement, ce type d’attaque n’est toujours pas, 4 ans après leur découverte, pris au sérieux par la plupart des développeurs / testeurs / équipes de sécurité, sans doute car elles n’ont pour l’instant pas été exploitées à grande échelle en dehors des réseaux sociaux.

Selon un article publié récemment sur le blog de Qualys, les protections standards décrites ci-dessus ne sont ainsi pas encore déployées systématiquement : près de 70% des 20 sites bancaires les plus fréquentés n’implémentent pas de protection efficace contre ce type d’attaque.

Il est fort à parier que l’emploi de ce type d’attaque va augmenter et se diversifier à l’avenir.  En effet, les mesures de protection contre les attaques par rejeu de requête (XSRF) se généralisant, notamment par leur intégration dans les frameworks de développement, les attaquants se tourneront mécaniquement vers d’autres vulnérabilités, dont le clickjacking. Anticiper dès à présent  reste le moyen le plus sûr d’éviter d’en être la victime.

Cet article Clickjacking, mais qui a volé ma souris ? est apparu en premier sur RiskInsight.

Tout d’abord, les attaques ne visent plus uniquement les entités gouvernementales ou leurs sous-traitants et leurs fameux « secret défense ». Les entreprises sont aujourd’hui la cible, soit pour les données de leurs clients, soit pour leurs propres données (stratégie, R&D, accords commerciaux…). Le phénomène est mondial et la France est concernée, même si cela est moins visible. Tous les secteurs d’activités sont touchés sans distinction.

Mais au-delà de ce buzz médiatique, que retenir de l’évolution de la sécurité de l’information sur ces 12 derniers mois ? Et que doit répondre le RSSI à sa direction générale qui l’interroge de plus en plus fréquemment sur ces affaires ?

Diffuses, opportunistes ou ciblées : savoir reconnaître les attaques

L’analyse des évènements récents fait ressortir trois différents types d’attaques. La première catégorie, « historique », correspond aux habituelles infections virales ou encore au spam. Il s’agit d’attaques diffuses. Ne visant pas une organisation en particulier, ces attaques vont avoir un effet néfaste sur le SI : déni de service, perte de données utilisateurs…

Ces attaques sont souvent simples à éviter et simples à juguler. Elles ont marqué les entreprises dès les années 2000 pour connaître leur dernière itération majeure avec Conficker en 2008. Celles-ci ne seront pas abordées dans la suite de l’article.

La deuxième catégorie, l’attaque opportuniste, est à but lucratif ou idéologique. Elle vise soit à capturer de l’information facilement monnayable (données des clients, données de cartes bancaires, etc.), soit à avoir un effet médiatique important (déni de service distribué ou defacement de sites web publics, vols de données lambda ensuite publiées sur internet, etc.). Elle ne relève souvent pas d’un haut niveau de technicité et ses auteurs ne cherchent pas à nuire à tout prix à une organisation donnée. Aussi, si l’une est plus sécurisée qu’une autre, ils passeront leur chemin pour se jeter sur la proie la plus facile. Ce scénario est également majoritairement vrai pour les attaques « idéologiques ». Il s’agit pour des groupes comme Lulzsec ou Anonymous de capturer, là où c’est facile, des données perçues comme sensibles et de les rendre publiques. La quasi-totalité de leurs attaques ont été rendues possibles par des manques criants de sécurité et des failles extrêmement simples dans les systèmes des organisations visées.

La troisième catégorie correspond à l’attaque ciblée. Celle-ci vise des informations sensibles et précises dans l’organisation. Ses auteurs sont mandatés pour viser une entité en particulier avec un objectif clair. Ils disposent de temps pour comprendre et analyser l’organisation, préparent des scénarios d’attaques et utilisent tous les moyens à leur disposition, techniques comme humains, internes comme externes, simples comme complexes, afin d’atteindre leur but. Le niveau de technicité et les moyens disponibles s’élèvent drastiquement, tout comme les enjeux. La communauté sécurité évoque ainsi le terme APT ou Advanced Persistent Threat pour décrire ces menaces avancées et persistantes. Google ou RSA en ont été victimes. De nombreux autres cas ont été recensés, y compris en France. Les attaques les plus courantes reposent sur des emails piégés émis à destination de personnes clés (spear-phishing), ou encore des attaques sur des plate-formes externes (site web) permettant ensuite des rebonds multiples sur le réseau interne pour atteindre les données de l’organisation visée.

Après cette entrée en matière, deux autres tribunes vont venir compléter l’analyse.

Tribune n°2

Tribune n°3

Cet article Nouvelles menaces externes et attaques ciblées : quelle stratégie pour le RSSI ? est apparu en premier sur RiskInsight.

Il s’agit ici de situations similaires à celles observées dans le secteur de la défense depuis de nombreuses années. Mais aujourd’hui, les grandes organisations y sont confrontées au quotidien. Pour protéger les données extrêmement sensibles, il leur faut donc mettre en œuvre des moyens avancés, drastiques, similaires à ceux employés dans le secteur de la défense.

Elles devront alors créer un SI dédié, spécialisé, pour gérer le « secret entreprise » analogue au « secret défense ». Et, si aucune mesure de sécurité n’est infaillible, ces éléments permettront d’augmenter la difficulté des attaques et donneront plus de temps pour les détecter et y répondre, le cas échéant. Quatre grands chantiers doivent être envisagés :

 Créer des sanctuaires pour les données sensibles. Basés sur une infrastructure dédiée, ils associent un nombre important et varié de mesures de sécurité : filtrage, chiffrement, isolation interserveurs, authentification forte dédiée, contrôle de conformité… Mais ils disposent également de processus spécifiques de mise en production afin de s’assurer que tout nouveau système est sécurisé. Ces systèmes et leur réseau devront être différents de ceux utilisés dans l’entreprise de manière classique. Ces sanctuaires seront maintenus par des équipes dédiées internes, sans utiliser d’accès distant.

 Spécialiser les terminaux clients. Vecteur d’intrusion classique lors d’attaques ciblées, le poste de travail devra être spécialisé en fonction des usages. Si l’utilisation de postes distincts en fonction des usages est fréquemment rencontrée, elle reste complexe à généraliser. Le recours à de nouveaux OS virtualisés et isolant les machines virtuelles suivant leur sensibilité est une piste à explorer. L’utilisation de solutions de déport d’écran peut être une option temporaire intéressante avant la généralisation d’un poste de travail virtualisé. Les échanges avec la zone sanctuarisée seront bien entendu chiffrés et les postes ne permettront pas de stockage local d’informations très sensibles.

 Sensibiliser et contraindre. Les utilisateurs manipulant les données les plus critiques sont souvent les plus difficiles à convaincre de l’importance de la sécurité. L’utilisation d’exemples concrets et surtout la mise en place d’un mécanisme coercitif en cas d’écarts permettront de diminuer les solutions de contournement. Sur ces périmètres spécifiques, il ne faudra pas tolérer d’écart aux politiques de sécurité, comme cela peut aujourd’hui être le cas, et composer avec les impacts métiers consécutifs.

 Surveiller, réagir et prévoir la reconstruction : L’attaque étant très probable, elle doit pouvoir être détectée et son impact minimisé. Une équipe interne dédiée à la gestion des zones sanctuarisées et à la gestion des incidents et des crises devra être formée. La traçabilité devra être mise en place et suivie avec des moyens importants (H24, temps réel, etc.). De nouvelles générations d’outils devront être testées et déployées en particulier pour détecter les signaux faibles relatifs à la fuite d’information. Ces systèmes seront également d’une aide précieuse pour enquêter sur les fuites de données lors de l’intrusion. D’autre part, des actions de reconstruction devront être imaginées pour pouvoir repartir sur une base saine en cas de succès d’une attaque. L’utilisation du PCA/PCI peut également être envisagée. Tous ces moyens sont contraignants et ont un coût élevé. Ils doivent être limités à un nombre restreint de traitements et de données. C’est le prix à payer pour conserver un niveau de sécurité important. L’armée américaine estime que la sécurisation des projets très sensibles entraîne un surcoût de 20%, du fait des mesures additionnelles, mais aussi de la complexité et des contraintes posées sur le travail au quotidien (cloisonnement de l’information, séparation des équipes, etc.).

Certaines entreprises sont prêtes aujourd’hui à franchir ce pas à la vue des risques encourus. Il s’agit en particulier du secteur de la défense, des sociétés fournissant des systèmes de sécurité, des sociétés où l’innovation est réalisée sur des cycles longs de recherche et de développement. Pour d’autres, la sécurisation ne sera pas acceptable, soit pour des raisons de pratiques internes, soit pour des raisons budgétaires (les coûts dépassant la rentabilité du SI ou bridant la compétitivité). Il faudra alors peut-être décider de réduire le périmètre de protection, et accepter consciemment de potentielles fuites de données qu’il faudra justifier et valider avec le management.

Le rôle du RSSI, entre évaluation des risques et pouvoir de conviction

Il est évident que ces menaces sont amenées à perdurer dans le temps. C’est au RSSI de réaliser  l’évaluation des risques de sa structure face à ces menaces et de convaincre sa direction de l’importance des actions à mener.

Se protéger à tout prix contre les attaques ciblées n’est pas envisageable et n’a pas de sens. Par contre, construire un socle solide résistant aux attaques opportunistes sur lequel viennent se greffer des sanctuaires sécurisés est une orientation à évaluer chez chacun.

Cet article Du « secret défense » au « secret entreprise » : des mesures avancées à déployer pour lutter contre les attaques ciblées est apparu en premier sur RiskInsight.