{
"componentChunkName": "component---src-templates-about-blog-template-js",
"path": "/blogs/modern-techniques-to-prevent-malware-instead-of-detecting-it",
"result": {"data":{"blog":{"content":"**Though we would not argue against the importance of detecting malware, there should also be a cheap and effective step before detection, namely prevention. A malicious email that is never delivered to the recipients will never cause security issues. [According to CSO](https://www.csoonline.com/article/3153707/top-cybersecurity-facts-figures-and-statistics.html), 94% of malware in 2020 was spread through the email system. Email, which remains an essential tool and still forms the basis of many business processes, uses one of the oldest and least secure communication protocols on the internet. Even though there are several ways to apply security policies on the mail transfer protocol to prevent the delivery of suspicious mail, these methods are not nearly as widely declared and enforced as they should be.**\n\nThe security of the other commonplace, older protocol, HTTP, the basis for the World Wide Web, has been in focus for more than ten years, leading to significant progress in this area. It is enough to mention the fact that HTTP has been almost completely replaced by HTTPS, an encrypted version of the same protocol that provides confidentiality, integrity and authenticity during data transfer. It should not be forgotten that just a few years ago, several sites sent credentials, customer data, or payment information on the internet without any kind of encryption. Post CCPA, GDPR, and other similar regulations, this is now almost unimaginable. A simple news site without any kind of authentication now uses HTTPS, quite rightly to avoid modification of content during transfer, just for instance. Try to imagine the potential consequences of a [man-in-the-middle attack](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) on one of the most popular news sites. As many business processes use the web and the protocol itself could not be improved, the ecosystem as a whole had to be improved to prevent downgrade attacks, clickjacking, cross-site scripting, and other malicious activities. But how secure is the transfer of electronic mail? Email is unquestionably still the basis of many formal and informal business processes, and so as long as this is the case, it is going to be the target of malicious parties. The answer to the issue of email security is a simple one, but not so encouraging. The state of mail transfer security is not nearly as good as in the domain of web page transfers.\n\nThere are significant differences between mail transfer and web page transfer. Web page transfer is usually performed between a web client (browser) and a web server. Mail, on the other hand, is not usually transferred to the recipients by a mail client, but instead to the server of the sender’s mail provider. It then passes the mail to the mail server of the recipient’s email provider, and then finally the recipient will download it asynchronously from that server. As you can see, there is a server-server communication that cannot be influenced by either of the clients. The details of that communication are determined by the participant servers and the simple mail transfer protocol (SMTP), which was designed at the beginning of the 1980s to be simple, not secure. \n\n[Originally](https://datatracker.ietf.org/doc/html/rfc821), the protocol did not contain any encryption capability. However, the [opportunistic use of TLS](https://en.wikipedia.org/wiki/Opportunistic_encryption) was introduced in 1999, though only as an optional extension. Twenty years on, a publicly referenced server still must not be required to use the mechanism to deliver mail locally according to the related [RFC](https://datatracker.ietf.org/doc/html/rfc3207#section-4). It means that the owner of a recipient domain, notwithstanding a legitimate interest, is not allowed to require encryption during the mail delivery process. It depends on the sender’s goodwill to initiate encryption. Without it, both client and server are exposed to a malicious third party with [man-in-the-middle](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) capability that can enforce a lack of encryption, independently from the fact that both parties intend to encrypt. Without initiating encryption, the recipient cannot authenticate the sender and vice versa and beyond this, the mail transfer is vulnerable to eavesdropping and also content modification. Under such circumstances, the recipient may believe a sender is trusted and therefore believe that the attachment is trusted. However, the attachment could potentially be malware forged into the mail by a malicious third party.\n\n\n## Possible Solutions\n\nThere are several mechanisms like [BIMI](https://en.wikipedia.org/wiki/Brand_Indicators_for_Message_Identification), [DANE](https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities), [DKIM](https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail), [DMARC](https://en.wikipedia.org/wiki/DMARC), [DNSSEC](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions), [MTA-STS](https://datatracker.ietf.org/doc/html/rfc8461), [SPF](https://en.wikipedia.org/wiki/Sender_Policy_Framework), [TLS-RPT](https://datatracker.ietf.org/doc/html/rfc8460), which have aimed to remedy the situation, with a greater or lesser degree of success. We will examine the theories behind these mechanisms, their practical limitations, configuration difficulties, and the achieved effect. \n\n\n\nIn general, it can be said that the most important limitations are prevalence and enforceability. As can be seen from the chart, there are significant differences in prevalence if we compare the top 1,000, 100,000, and one million domains of the [Majestic Million](https://majestic.com/reports/majestic-million). The prevalence is much higher among the most popular domains than the others. The reason cannot be only the fact that the Fortune 1,000 companies enjoy much better financial conditions, as these mechanisms can be implemented without significant cost. The lack of knowledge could be one reason, even though there are several guides and easy-to-use tools available to get the necessary configurations to enable these mechanisms. Another reason might be the fact that there is no regulatory body that can enforce the usage of these mechanisms or the execution of the policies declared by these mechanisms, only recommend them, as [NIST does](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-177r1.pdf). The last reason to mention is that domain owners also have no power to force the execution of the declared policies on the mail systems owners of the recipient side. In any case, big tech companies like Google, which has a significant market share of the mail service market, have begun to put pressure on domain owners who want to provide mail service for their domain to publish policies, although [they do not necessarily strictly comply](https://security.stackexchange.com/questions/239152/does-gmail-still-ignore-dkim-if-spf-passes-dmarc-style) with them.\n\nIn summary, the lack of these mechanisms on the sender side means a relatively high risk that emails sent from the domain are going to be put in a spam folder or rejected, at least by the biggest mail providers. The lack of checking of the policies declared through these mechanisms on the recipient side may mean a relatively high risk of incoming mails coming from unauthorized, or even malicious actors who can impersonate trusted parties. Usually, impersonation is the first step of a targeted attack where fraudsters can inject misinformation or bogus content such as scams, viruses, spyware, and malware into the organization.\n\n\n### Sender Policy Framework (SPF)\n\n\n#### Concept\n\nThe sender side can publish a policy through this mechanism, declaring which servers are allowed to send mail in the name of the given domain. The recipient side can use the published policies to check that the incoming mail is actually sent by an authoritative server. The policy itself is published in a TXT record of the given domain (e.g. example.com) and the servers can be declared by their IP addresses or indirectly, referring to other DNS records. The simplest case, at least in this respect, is that the domain owner maintains its email server and the MX record of the domain contains the IP address(es) of the mail server(s), so only the MX record should be referred to. From other points of view, it may seem easier to use a software-as-a-service solution to implement your mail service. In that case, you can include the policy of the SaaS provider or you can simply redirect to it.\n\n```\nexample.com. IN TXT “v=spf1 mx -all”\nexample.com. IN TXT “v=spf1 include:_spf.google.com -all”\nexample.com. IN TXT “v=spf1 redirect:spf.protection.outlook.com -all”\n```\n\n#### Threats\n\nThe tricky part of a sender policy framework is not the explicit declaration of the servers, but the declaration of the default action. Default action answers the question of what should be done when the recipient realizes that there is no explicit rule that matches the IP address of the actual sender. For this, a special [mechanism](https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.2) (`all`) can be used optionally with a qualifier. All the examples above use the fail (`-`) qualifier, so the evaluation result of the Sender Policy Framework will [fail](https://datatracker.ietf.org/doc/html/rfc7208#section-2.6.4) for clients not explicitly stated in the policy, meaning that they are not authorized to use the domain.\n\n\n\nAlthough default fail is considered the most secure method, only less than one-third of the SPF records use it. This may be because this is not the most convenient method from the perspective of maintenance, as the lack of an IP address may cause failure in delivery.\n\nThere are two other options to avoid this problem. Domain owners can explicitly state that they are not asserting whether the IP address is authorized or not. This can be done by adding the [neutral](https://datatracker.ietf.org/doc/html/rfc7208#section-2.6.2) (`?`) modifier. This might seem convenient in terms of the maintenance side, but has almost no added value on the security side. The result will be the same if the default is missing and the case is similar when the whole SPF record is missing. Counting all the MX records, not only the ones which have SPF TXT records, the ratio of neutral modifiers with a default value (all) is more than one-third. More than half of the SPF records use the soft fail modifier (`~`) when declaring the default behavior, meaning that the host is probably not authorized. From a security perspective, this is just a little more than if it were neutral.\n\nWhy is default action so important? Just imagine a firewall policy that contains a default rule declaring what should happen when no rule matches on the traffic explicitly when it could say that the traffic is not asserting or probably not authorized. It would be a security nightmare. Domain owners should know which servers are authoritative and should declare it strictly. In that case, the recipient can be sure that the sender is authoritative and the mail from a representative of a trusted company really comes from them, and as a result, avoid being a victim of a [phishing](https://en.wikipedia.org/wiki/Phishing) or [social engineering](https://en.wikipedia.org/wiki/Social_engineering_(security)) attack. Though strict rules may affect business continuity – something which must be taken into consideration – this issue should be handled by another mechanism, like DMARC, not by making the policy more permissive.\n\nA severe limitation of the Sender Policy Framework is that servers are authorized by their IP address(es), which is vulnerable to [IP spoofing](https://en.wikipedia.org/wiki/IP_address_spoofing), and they could be declared indirectly referring to IP addresses by hostnames or other DNS records which are vulnerable to [DNS spoofing](https://en.wikipedia.org/wiki/DNS_spoofing). As the policy is stored in a DNS record, it should be transferred in a way that can guarantee the integrity of the data: without [DNSSec](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) or at least DNS over [TLS](https://en.wikipedia.org/wiki/DNS_over_TLS)/[HTTPS](https://en.wikipedia.org/wiki/DNS_over_HTTPS), the policy information is vulnerable to tampering and altering. The most serious issue with the Sender Policy Framework is that while its prevalence is relatively high, the really important question is what the ratio of the enforcer servers is. In any case, though the Sender Policy Framework can improve the level of security, publishing a policy has only a modest effect, which means that it should be combined with other mechanisms as it can prove neither the integrity nor the confidentiality of a mail.\n\n\n### DomainKeys Identified Mail (DKIM)\n\n\n#### Concept\n\nIn comparison, a Sender Policy Framework makes it possible to determine whether the server is authoritative to send an email in the name of the given domain, whereas the DomainKey Identified Mail method can be used to authenticate the mail itself independently from what the IP address of the sender was. The sender inserts a header (`DKIM-Signature`) into the mail which contains at least the hash of the body (`bh`), the signature of the content (`b`), the list of the headers (`h`) included when the signature is computed, the algorithm (`a`) used to create the signature and location (`d`, `s`) of the public key which can be used to verify the signature.\n\n\n```\nDKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;\n c=relaxed/simple; q=dns/txt; t=1117574938; x=1118006938;\n h=from:to:subject:date:keywords:keywords;\n bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;\n b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR\n```\n\n\nThe recipient mail server simply decrypts the signature with the public key found in the given location. The fact of the success of the decryption proves that the mail was signed by an actor who owns the private key related to the public key used to decrypt the signature. The decrypted value is the hash of the original mail that has been computed by the signer module of the sender server. The recipient server recomputes the hash and compares it with the result of the decryption. If the two hashes are identical, the mail body (including the attachments) and the listed headers are guaranteed not to have been altered by a third party. This essentially means that there is no malicious attachment in the mail unless the sender has attached it and nobody has modified any data in the mail, for instance, an account number, committing an [email fraud](https://en.wikipedia.org/wiki/Email_fraud).\n\n\n#### Weaknesses\n\nChoosing the appropriate signature algorithm and public key size requires care with this mechanism, as a not-so-wise decision may make the efforts so far meaningless. The traditional RSA public key type, with at least a 2048 bit key size or any elliptic curve-based key with at least a 224 bit key size can meet expectations, according to NIST. As multiple keys can be set, you can configure either an RSA key for compatibility and an ECDSA for modernity and to enjoy the benefits of elliptic curve-based cryptography, like smaller key sizes. Signature algorithm SHA-2 with any message digest size could be suitable. However, SHA-1 is strongly contraindicated as [there is](https://sha-mbles.github.io/) a [chosen-prefix collision attack](https://en.wikipedia.org/wiki/Collision_attack) against this algorithm. It needs a high amount of computational power, which makes a real-time break almost impossible, even taking into account the average delay time of a mail, though there is an opportunity of a [replay attack](https://en.wikipedia.org/wiki/Replay_attack), where the attacker can send almost the same mail later with a modified bank account number and payment deadline while the signature is still valid. The weak point of the DKIM mechanism is not the cryptography, but the fact that DKIM cannot provide confidentiality. \n\n\n### MTA Strict Transport Security (MTA-STS)\n\n\n#### Concept\n\nMTA Strict Transport Security is intended to solve the confidentiality issue of mail sending. Though the SMTP protocol originally did not contain any encryption capability, later an optional encryption capability was added as an extension, which is still not required. The situation is similar in relation to the unencrypted HTTP and the encrypted HTTPS protocols. An attacker with man-in-the-middle capability is able to force a client to use the unencrypted HTTP if the connection to the server was initiated with that protocol independently of whether the server supports the encrypted HTTPS protocol or not. It means that all the traffic communicated between the parties, which may contain sensitive information, can be intercepted by the attacker. There is a condition that must be met for a successful attack to be carried out, namely that the server must support the unencrypted version of the protocol. HTTP is not necessarily present, but SMTP always is, which means the information that encryption can be used must reach the client. This is the Strict Transport Security, which is implemented as a header in case of HTTP and a DNS record publication in case of SMTP.\n\n```\n_mta-sts.example.com. IN TXT \"v=STSv1; id=20210602165800Z;\"\n```\n\nDuring our investigation, we identified that most of the MTA-STS supporting domains use date in the id field. Assuming that the date in the id field is the publication date of the latest policy, and also assuming that the policies are not changing very often, a diagram can be drawn, in a cumulative manner, that shows how many MTA-STS policies were published. Though the curve may suggest a rise, the current prevalence does not even reach one percent.\n\n\n\nUnlike the HTTP protocol, the SMTP protocol cannot be redirected to an encrypted channel, as SMTP protocol does not contain something like the “[moved permanently](https://en.wikipedia.org/wiki/HTTP_301)” [response status code](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes) in HTTP, so the information that the server wants to use encrypted communication must reach the client on an independent channel. In this case, DNS is used, just like in Sender Policy Framework or DomainKey Identified Mail. Similar to the earlier mechanisms, MTA Strict Transport Security is published in a TXT record. The difference is that only the fact of presence and current version are indicated by TXT records, but the policy itself is distributed via HTTPS from a ‘[well-known](https://tools.ietf.org/html/rfc5785)’ source. The DNS record contains a short string(`id`) that uniquely identifies a given instance of a policy so that senders can determine when the policy has been updated.\n\n```\nversion: STSv1\nmode: enforce\nmx: mail1.example.com\nmx: mail2.example.com\nmax_age: 86400\n```\n\n\nThe policy is similar to the [Strict Transport Security header](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) in the case of HTTP. It contains a list (`mx`) of servers by which mails for this domain might be handled, with a lifetime value (`max_age`) for the policy, meaning that a client can cache a policy for up to this value and a mode (`mode`) indicating the expected behavior of the sending server in the case of a policy validation failure. The policy may declare that the sending server must not deliver (`enforce`) the message to a server which fails hostname matching or certificate validation, or has no TLS capability. For testing purposes, there is a mode (`testing`) that makes it possible to deliver mails despite the fact that there was validation failure, but a sending server can send a report about the failure (see TLS-RPT later). There is also a mode (`none`) indicating that there is no active policy. Today, just over half of the owners of MTS-STS publishing domains want to enforce the policy, while the other half is presumably in a testing phase. However, it should be noted that the ratio of domains supporting MTA-STS in the top one million is only 0.7%.\n\n\n\n#### Threats\n\nPublishing MTA-STS policy is necessary, but far from sufficient. It should be enforced to minimize the risk of a MITM attack to ensure the unencrypted method of SMTP communication. Nonetheless, the existence and enforcement of the TLS protocol do not necessarily guarantee confidentiality. The quality and performance of the encryption is highly dependent on the details of the TLS settings. They should be determined and reviewed regularly with due care, bearing in mind the requirements of the related compliances ([NIST](https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final), [PCI DSS](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf), [HIPAA](https://www.hhs.gov/hipaa/for-professionals/breach-notification/guidance/index.html)) if necessary.\n\n\n#### Weaknesses\n\nTLS has a significant benefit, namely that it solves not only the problem of confidentiality but also the problem of integrity targeted by DKIM. However, it should be noted that the MTS-STS cannot guarantee confidentiality and integrity throughout the entire process of mail sending, despite [Pretty Good Privacy](https://en.wikipedia.org/wiki/Pretty_Good_Privacy) (PGP) or [Secure/Multipurpose Internet Mail Extensions](https://en.wikipedia.org/wiki/S/MIME) (S/MIME) – just in respect of MTA communication, as the name suggests, so in the case of client (MUA) server communication, the same issues exist when a protocol has only opportunist TLS capability, just like IMAP and POP3. Disadvantages of the mechanism include the fact that it requires the maintenance of a web server to publish the MTA-STS policy independently of whether the domain owner intends to publish a web page or not, and also that it requires the maintenance of an X.509 certificate for that web server, as only HTTPS is allowed to download the policy.\n\n\n### SMTP TLS Reporting (TLS-RPT)\n\n\n#### Concept\n\nThough the topics discussed so far have been strictly related to security, we should also consider business continuity. Introducing the discussed mechanisms carries a risk in terms of mail delivery. The risk cannot be transferred and should not be accepted, as it can be reduced by the SMTP TLS Report mechanism declaring reporting endpoints where the sending servers can report when experiencing policy validation failures. The policy can be published in one or more TXT records that contain the aggregate report URI (`rua`), which can either be an email address or an HTTPS endpoint. \n\n\n```\n_smtp._tls.example.com. IN TXT \"v=TLSRPTv1; rua=mailto:reports@example.com\"\n_smtp._tls.example.com. IN TXT \"v=TLSRPTv1; rua=https://reporting.example.com/v1/tlsrpt\"\n```\n\n\n\n#### Weaknesses\n\nOne advantage of the mechanism is that it makes it possible to receive information about MTA-STS verification failures of sending mail servers, something which can be either a simple technical issue or an active attack. The disadvantage of the mechanism is that it may be necessary for the mail servers to use a protocol (HTTPS) that is unrelated to the mail sending and therefore requires extra functionality in the mail server implementation. Furthermore, the protocol has its own security mechanisms ([HSTS](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security), [Report-To](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/report-to), [Network Error Logging](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/NEL), [Expect-CT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect-CT), …) which should be supported as an HTTP client in a mail server to provide the highest available security level. Policy violation reporting based on mails requires properly configured DomainKey Identified Mail (DKIM) on the report sending mail server side. If DKIM verification fails on the side of the report recipient mail server, the report can be ignored, according to the RFC. However, the RFC does not discuss the fact that the Sender Policy Framework can also be checked, as the report is actually sent by a mail server in the name of a given domain. With these checks, the reporter can be authenticated in a slightly weak way though, as an attacker can buy a domain and can apply proper DKIM and SPF settings and to send misinforming reports. However, with that activity there is a risk that the mail server is going to be added to a blacklist. The other option, sending the report via HTTPS, provides a much better opportunity to the attacker to send misleading reports, as it is much harder for the recipient to authenticate the sender of the report. Maybe this is the reason why the vast majority of the domain owners have chosen reporting MTA-STS violation in mail, not via HTTPS. This means there is a risk that spoof reports will be sent by an attacker to generate false positive alerts, thus undermining the trust in these kinds of reports, which could indicate man-in-the-middle attacks against our mailing system.\n\n\n\n#### Threats\n\nAnother problem of the reporting is the fact that it is completely voluntary. Publishing a TLSRPT policy with an appropriate aggregate report URI (`rua`) value does not necessarily mean that you will actually receive any reports, as the recipient may or may not support the TLSRPT mechanism. Even if the recipient supports the mechanism, it is far from sure that the recipient supports report sending and also intends to send reports, as configuration and a certain amount of resources are required to do so. \n\n\n### Domain-based Message Authentication, Reporting and Conformance (DMARC)\n\n\n#### Concept\n\nThe relation between the previously discussed TLS-RPT and the MTA-STS is the same as the relations between DMARC and the Sender Policy Framework (SPF) or DomainKey Identified Mail (DKIM). When the verification of SPF or DKIM fails, the recipient mail server can send a failure report to the domain owner defined in the DMARC TXT record. Compared to TLS-RPT it can be noted that there are more sophisticated settings here. Not only a single type of reporting endpoint can be set, but one for aggregate feedback (`rua`) and another for message-specific failure information (`ruf`). Report interval (`ri`) can also be set to indicate a request to mail receivers to generate aggregate reports separated by no more than the requested amount of time, and last but not least a policy is published as part of DMARC applies to the domain and can also apply to subdomains. The domain owner may request mail receivers to take no specific action (`none`) to treat mail that fails the DMARC check suspicious (`quarantine`) and place them into a spam folder, for instance, or to reject (`reject`) email that fails the DMARC check.\n\n```\n_dmarc.example.com. IN TXT \"v=DMARC1; p=reject; rua=mailto:rua@example.com; ruf=mailto:ruf@example.com\"\n```\nThe ratio of the required actions dramatically shows how heavily the business depends on the email systems and how much more important the business continuity is than the security. Using a security first mindset any mail that fails the DMARC check would be treated as suspicious and should be quarantined or rejected. Except for the top 1,000 domain owners, only the minority are brave enough to ask the mail receivers to quarantine or reject. In other cases, the majority asks the mail receivers to take no action which questions the usage of DMARC has any sense.\n\n\n\n#### Weaknesses\n\nAuthenticating the issuer of the report is as hard as it is in the case of SMTP TLS Reporting (TLS-RPT), so there is a risk that the reports will be spoofed. Despite the TLS-RPT, DMARC supports only delivering reports by mail, so authentication of the sender is possible, but only in a limited manner.\n\n\n#### Threats\n\nIncidentally, a situation is conceivable when there are two servers which support DMARC and intend to send reports when experiencing an issue, but the DMARC fails mutually during the check of the reporting mail due to a DMARC configuration or DMARC check implementation issue. In that case, the DMARC report send is triggered mutually by the DMARC report of the other server, which could potentially cause an endless loop. There are also limits to DMARC specification, like percentage (`pct`) of messages to which the DMARC policy is to be applied, or the earlier mentioned report interval (`ri`), but these options are designed to help the introduction of DMARC, not to avoid attacks. \n\n\n### Brand Indicators for Message Identification (BIMI)\n\nThe mechanisms discussed above are about machine-to-machine (M2M) communication. There are no – or no well-declared – user-facing consequences of success and failure. BIMI seeks to fill this gap, and makes the result of the earlier mechanisms visible to the user. BIMI enables the display of brand-controlled logos within supporting email clients (MUA) only if the email is well authenticated. This essentially means that the sender domain must publish DMARC for the domain and the subdomains, where the policy must be set to either quarantine or reject and where the percentage subdomain policy cannot be set to anything less than 100. For the brand’s logo to be displayed in the email client, the email must pass DMARC authentication and BIMI validation checks, ensuring that the organization’s domain has not been impersonated and the brand indicator is valid.\n\n```\ndefault._bimi.example.com. IN TXT \"v=BIMI1; l=https://example/bimi/logo.svg\"\n```\n\n#### Weaknesses\n\nThe configuration is relatively simple compared to the previously described mechanisms, but it must be noted that there could also be a relatively simple attack against it. Once the logo is published, a malicious actor could register a lookalike domain, configure DKIM, DMARC and copy the indicator to mimic the attackable domain and publish it as if it were its own. In that case, the same logo would appear in the email client of the recipient as the email coming from either the attacked or the attacker domain, so for the recipient it is just as hard to distinguish the two domains as it was before. The situation is much worse when the attacked domain does not publish BIMI, just the attacker one, so the latter may seem more trustworthy than the former. This weakness is targeted by the Verified Mark Certificates (VMC), which provide digitally signed evidence that the organization is allowed to use the brand indicator, like the extended validation where not only the domain but the organization name and other descriptive data are certified. The mechanism is based on X.509, so it carries all the complexity and difficulties of it, including validation, revocations checking and certificate transparency. Verified Mark Certificates can only be purchased by an organization if their logo is trademarked, so it is feared that the VMC part of BIMI takes us back to pre-Let’s Encrypt times, when there was no chance of signing a certificate with a widely accepted certificate authority for free, meaning it cannot reach high prevalence, just like extended validation.\n\n\n### Domain Name System Security Extensions (DNSSEC)\n\n\n#### Concept\n\nDNSSEC is a suite of extension specifications for securing data exchanged using the DNS protocol in untrusted networks, just like the internet. DNSSEC ensures the authenticity and integrity of data, but not confidentiality. As the information stored in DNS records related to the previously discussed mechanisms (SPF, DMARC, DKIM…) are public, confidentiality is not required, but authenticity and integrity are, meaning that we need to be sure that the information is not compromised by an attacker. [DNS over TLS](https://en.wikipedia.org/wiki/DNS_over_TLS) (DoT) and [DNS over HTTPS](https://en.wikipedia.org/wiki/DNS_over_HTTPS) also provide authenticity and integrity in addition to confidentiality, but DNSSEC has a significant advantage over them, namely it can ensure authenticity and integrity during the potentially recursive name resolution procedure. DoT and DoH can provide confidentiality, integrity and authenticity between the DNS client and the DNS resolver, but it is not possible to ensure that all DNS servers use DoT/DoH when serving the request and the client has no information about whether they used DoT/DoH or not. It must be noted that these two protocols were never intended to achieve that goal, but instead to provide confidentiality and also privacy to the end-user. \n\n\n#### Weaknesses\n\nIn the case of DNSSEC, integrity and authenticity are ensured by digital signatures. Answers from DNSSEC-protected zones are digitally signed by a key whose public part can be found in the DNSKEY record of the given domain. Using this public key, a DNS client can check the integrity and authenticity of the answer. Just like any other cases where integrity and authenticity are ensured by digital signatures, the key issue is the [chain of trust](https://en.wikipedia.org/wiki/Chain_of_trust) and also key types, sizes, and digest algorithms used in the chain. Public keys found in DNSKEY records are signed by the DNSKEY of the upper level domain up to the top level (TLD) and the root domain. The parameters of these keys determine the security level. As DNSSEC is a relatively old protocol of the internet, and the earlier versions did not support strong encryption algorithms and large key sizes, so backward compatibility leads to the fact that small key sizes are still in use, however, large ones are also supported.\n\n\n\nOnly an insignificant minority of the top-level domains currently use the 1024-bit RSA key as the strongest key. Mostly, 2048-bit RSA keys are used, though it must be noted that RSA keys with lesser key sizes are also used. The prevalence of [elliptic-curve](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography)-based public keys (ECDSA), despite all their advantages, is particularly low among the top-level domains. Only 256-bit keys are used, where the RSA equivalent key size is 3072, neither greater key sizes, nor Edwards-curve Digital Signature Algorithm (EdDSA) curves are used, though the latter is now recommended. Digest algorithms do not follow the same pattern as key types and sizes did: backward compatibility has no significant effect. Only an insignificant minority offer the weekend SHA-1 algorithm. The majority of the top-level domains offer strong digest algorithms.\n\n\n\nIt should be noted that the prevalence of DNSSEC is unfortunately low despite NIST declaring that organizations should deploy DNSSEC for all DNS name servers and validate DNSSEC responses on all systems that receive emails to provide authentication and integrity protection to the DNS resource records discussed above.\n\n\n### DNS-based Authentication of Named Entities (DANE)\n\n\n#### Concept\n\nDANE is a protocol that allows binding X.509 certificates to domain names using the previously discussed DNSSEC. The most important result of binding domain names and X.509 certificates is that it makes any [certificate authority](https://en.wikipedia.org/wiki/Certificate_authority) (CA) needless, as it can declare an X.509 certificate or public key used on a specific service (for instance an email server) of the domain. In this case, an X.509 public key does not need to be certified by a third party (CA) that the X.509 public-key relates to a specific domain. As part of the issuance of a [domain validated certificate](https://en.wikipedia.org/wiki/Domain-validated_certificate), the domain owner must prove its authority to the certification, mostly by creating a DNS record with a specified value. However, in the case of DANE, a TLSA record has already been created to store the public key or its hash, so the authority is proven by matching the public key or X.509 certificate in the DNS record and provided by the service. The mechanism also makes certificate common name and subject alternative name (SAN) matching needless, as the certificate and the domain name are bound by a DNS record related definitely to the domain name. This means there is no need to certify the binding by a certificate authority as it is cryptographically proven by DNSSEC. Certificate revocation check, which is the [Achilles heel of the complete Public Key Infrastructure](https://coroner.medium.com/why-do-certificate-revocation-checking-mechanisms-never-work-f9b7a4ee1a61) ([PKI](https://en.wikipedia.org/wiki/Public_key_infrastructure)), also becomes needless, as the validity of a certificate has no sense in this environment: there is no certification by a third party that could expire, and the domain owner simply stops publishing a key if it is suspected to be compromised. The situation is the same when the domain owner just wants to regularly change keys to decrease their validity period, as it would be strongly recommendable, and now [blocked by the certificate authorities](https://www.thesslstore.com/blog/ssl-certificates-one-year-max-validity-ballot-fails-at-the-ca-b-forum/) despite the several weaknesses of revocation check mechanisms. \n\n\n```\n_25._tcp.mail.example.com. IN TLSA 2 0 1 ( E8B54E0B4BAA815B06D3462D65FBC7C0 CF556ECCF9F5303EBFBB77D022F834C0 )\n```\n\n\nThe previously emphasized way of working does not mean that DANE cannot work together with PKI. TLSA records have four data fields: certificate usage (2), selector (0), matching type (1), and certificate association data respectively. Certificate usage specifies that certificate association data contains a leaf certificate (end entity or EE) or a CA (trusted anchor or TA) and also specifies whether the certificate given by the server should be issued by a CA trusted by the application doing the verification (PKIX) or not (DANE). Certificate usage can take the following four values, where the certificate provided by the server during the TLS handshake must:\n\n1. be issued by an already trusted CA whose certificate published in the certificate association data (CA constraint or PKIX-TA)\n2. be issued by an already trusted CA whose certificate must match exactly the certificate published in the certificate association data (Service certificate constraint or PKIX-EE)\n3. be issued by the CA published in the certificate association data (Trusted anchor assertion or DANE-TA)\n4. match exactly the certificate published in the certificate association data and it can be a self-signed certificate (Domain issued certificate or DANE-EE)\n\nSelector specifies whether the full certificate (0) or the subject public key info are part of the certificate sent by the server should be matched against the association data, while matching type specifies how the certificate association data is presented. The entire selected data can be presented either in the certificate association data (0) or by a hash (1/2).\n\nDANE would mean a giant leap in the direction of a decentralized internet that preserves the support of the traditional PKI by providing some kind of digital self-determination for the domain owner. At the same time, it would also solve the problem that clients now trust in a predefined group of root CAs, where the members of the group depend on the vendor of the client application, independently from the fact that the domain owner trusts in only one CA that actually issued the certificate used by a server. Supporting DANE constraints could be applied to a number of trusted CAs – including the number zero, meaning that a domain owner could decide to skip CAs entirely.\n\n\n#### Weaknesses\n\nDespite all the advantages of DANE, there is one unavoidable disadvantage, namely the [lack of client application support](https://caniuse.com/dnssec), something which makes DANE a theoretical solution only to several serious practical issues.\n\n\n## Conclusions\n\nGiven the serious shortcoming of the old fashioned mail transfer protocol, it is strongly recommended to arm email systems with as many additional security mechanisms as possible, according to NIST which recommends organizations to deploy SPF, MTA-STS, DANE, and DNSSEC in order to avoid receiving mail from unauthenticated sources on an unreliable channel. There are, however, overlaps between the discussed mechanisms, all of them are needed to ensure the complete confidentiality, integrity, and authenticity of the received mails and also to be aware of whether senders are experiencing any suspicious behavior. The discussed mechanisms have no significant introduction or maintenance costs, especially given their undoubted benefit. Organizations should declare policies to help each other make informed decisions. These policies are about what servers are authoritative to send emails by the name of their domains (SPF) and whether they want to use encryption (MTA-STS, DANE) to ensure confidentiality when receiving mails, what the evidence is that a received mail has factually been sent by sender (DKIM), and how parties can inform each other when they experience errors or suspicious behaviors (DMARC, TLS-RPT). They also have to prove the integrity and authenticity of these policies (DNSSEC). This means that the “never trust, always verify” principle of the [Zero Trust Security Model](https://en.wikipedia.org/wiki/Zero_trust_security_model) is essential to filter out any suspicious senders and their deceptive content and malicious attachments, ideally before such content can cause a business email compromise.","title":"Modern Techniques to Prevent Malware instead of Detecting It","short_description":"Google lists 12,400,000 results to the search of \"malware detection tools.\" Is malware detection a silver bullet, or is there a smarter method to prevent malware attacks? We believe there is one.","author":"Szilárd Pfeiffer, Security Evangelist & Engineer, Balasys","date":"2022-01-18","hero":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/zt_blog_header01_07020d606e.jpg"},"SEO":{"title":"Modern Techniques to Prevent Malware instead of Detecting It","isIndexable":true,"description":"Google lists 4,840,000 results to the search of \"malware detection tools.\" Is malware detection a silver bullet, or is there a smarter method to prevent malware attacks? We believe there is one.","keywords":"smtp,Sender Policy Framework,SPF,DomainKeys Identified Mail,DKIM,MTA Strict Transport Security,MTA-STS,SMTP TLS Reporting,TLS-RPT,Domain-based Message Authentication, Reporting and Conformance,DMARC,Brand Indicators for Message Identification,BIMI,Domain Name System Security Extensions,DNSSEC,DNS-based Authentication of Named Entities,DANE","preview":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/zt_blog_header01_07020d606e.jpg"}}},"related":{"nodes":[{"author":"Szilárd Pfeiffer","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/jievani_weerasinghe_NHRM_1u4_GD_A_unsplash_5998edbcc5.jpg"},"content":"**Researchers at **[Kudelski Security](https://kudelskisecurity.com/)** have **[managed to break](https://research.kudelskisecurity.com/2023/03/06/polynonce-a-tale-of-a-novel-ecdsa-attack-and-bitcoin-tears/)** Bitcoin and Ethereum wallets using a novel attack against one of the most popular asymmetric key algorithms of modern cryptography. Although **[Satoshi Nakamoto](https://en.wikipedia.org/wiki/Satoshi_Nakamoto)**’s wallet was not among the 764 wallets they were able to break, it is quite worrying to see that a software issue can make such a modern cryptographic algorithm like ECDSA vulnerable. Analysis of data that comes purely from open sources could reveal a practical weakness of an algorithm that is the fundamental basis of secure internet communication, public key infrastructures, and cryptocurrency transactions.**\n\n\n## Software Issue Behind the Scenes\n\nAs with many other times in the history of attacks against cryptographic algorithms, the cause of a successful attack is not a vulnerability in the algorithm itself, but the fact that poor-quality software used an algorithm with insufficient care. It is crucial to obtain “high-quality” random numbers during the calculation of many cryptographic operations. Such operations store passwords using [salt](https://en.wikipedia.org/wiki/Salt_(cryptography))ed [hash](https://en.wikipedia.org/wiki/Cryptographic_hash_function)es, the generation of cryptographic keys used to authenticate web servers on the internet, or an employee before access is given to the company’s private network using a virtual private network (VPN) service. The generation of [digital signature](https://en.wikipedia.org/wiki/Digital_signature)s – which is necessary for the verification of the transactions – also requires a cryptographically strong random value. In the absence of strong random values, there would be a relation between the random and the private part of the signing key. This property could be exploited, and the private key can be acquired by an attacker. In the possession of the private key, any transaction related to the key can be verified, meaning that the balance of the wallet can be transferred.\n\n\n## Not a New Idea, but a New Method\n\nThough the attack itself is novel, the idea behind the attack is not so new. The lack of high-quality random numbers has caused serious vulnerabilities in the past. In 2002, a researcher found an [issue](https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2008-0166) in the version of the [OpenSSL](https://www.openssl.org/) distributed with [Debian](https://www.debian.org/) Linux and its derivatives that reduced the entropy of generated random values. The issue caused SSH, VPN, and X.509 keys generated by the affected versions of OpenSSL to become vulnerable. Services still used a key generated by the affected version of the code which meant they remained vulnerable until the regeneration of the key. In 2010, a group called _fail0verflow _compromised an ECDSA key [Sony](https://en.wikipedia.org/wiki/Sony) used to sign software for the [PlayStation 3](https://en.wikipedia.org/wiki/PlayStation_3) game console. The root cause of the attack was almost the same as it is now, namely Sony did not use different random numbers when digitally signing different software. The novelty of the current attack is that it exploits the high-degree relationships among the random values ([nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce)s) used to generate digital signatures. It means if the nonce was not generated by a cryptographically secure random number generator but using a weak [pseudo-random number generator](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) (PRNG), it would allow the attacker to retrieve the private part of the key used to generate the signatures.\n\n\n## Special Kind of Open-source Intelligence\n\nThree prerequisites must be met to successfully retrieve the signer’s private key from signatures. The first one is that the random value used to generate the signature should come from a weak PRNG. The second one is to have a batch of consecutive digital signatures generated by using the same PRNG. The third one is that the signatures can be ordered, meaning that we know which signatures have been generated after which one. It could be assumed that there are implementations that use weak PRNGs as it is not basic knowledge whether random number generators are adequate for cryptographic purposes and some legacy software may follow older guidelines. The question is: where can an attacker find a consecutive and ordered list of signatures? The answer is: in several places. Digital signatures are part of each cryptographic protocol, so they can be collected from open sources. The best examples are [cryptocurrencies](https://en.wikipedia.org/wiki/Cryptocurrency), where the transfers are validated by digital signatures. These digital signatures must be published to allow each party to validate the transactions. Basically, cryptocurrency [blockchain](https://en.wikipedia.org/wiki/Blockchain)s are huge collections of the necessary signatures. For instance, researchers could collect 763 million unique signatures from the Bitcoin blockchain which were generated by 424 million unique public keys. Most of the time a key was used to generate only a few signatures, but millions of keys generated at least four signatures, which is the minimum requirement of the attack.\n\n\n## Someone Got Ahead of the Researchers\n\nResearchers ran their attack for two days and 19 hours with an estimated cost of USD 265, resulting in 762 unique broken wallets, but someone may have gotten ahead of them, as all the wallets had zero balance. The researchers suspect that these wallets have already been hacked in the past. If they had not been hacked, 484 BTC could have been stolen from these wallets, which means almost 12 million USD. However, 484 BTC was worth 31 million USD at Bitcoin’s peak. The question arises, where did the money go? The researchers obtained that the recipients were addressed by the latest transactions of the broken wallets. They identified 466 different recipient addresses, where the top 1 received 75 BTC, and the top 5 received 140 BTC, meaning more than USD 1.5 million, and almost USD 3 million, respectively. They counted 144 BTC in total, which is far from the theoretical 484 BTC, but it still sounds like a profitable business, worth the aforementioned USD 265 cost of the investigation. After the first transaction to the top address in 2018, several transactions were initiated from that address to several recipients for 0.5 or 1 BTC, although the account still had a balance of 63.5 BTC. Researchers also found public conversations about accounts that were swept exploiting repeated nonces. A forum member called _johoe_ [claimed](https://bitcointalk.org/index.php?topic=1431060.0) that he had collected 135 addresses that can be compromised using that technique, and 82 had been compromised already at the time of his post. He also stated that he collected 7 BTC from the broken accounts. He was willing to send the funds back to the owner after proving ownership. The researchers repeated their attack against Ethereum after collecting more than 1.7 billion ECDSA signatures. They managed to break 2 unique wallets processing 22% of their signature collection. They decided to stop the attack, considering that the cost-benefit ratio was too low.\n\n\n## Is This Still a Real Issue Now?\n\nConsidering only the results related to the Bitcoin wallets, I would say this might not be an issue anymore. The exploitable signatures were generated several years ago, perhaps with the same software that had a serious flaw, which may have already been fixed. The signatures were exploitable not because they used a pseudo-random generator during signature generation, but due to repeated nonce values. At the same time, given that digital signatures are used in so many cases, such as during a cryptographic handshake, this may still be a significant issue. Exploiting the vulnerability indeed requires getting consecutive signatures from a potentially affected server, which is not a trivial problem in the case of a busy server, as many other clients connect to a server between our consecutive connections. Even so, if an attacker manages to exploit a server, the server certificate is compromised without any sign on the server. For as much as the [certificate revocation is one of the weakest points of X.509](https://pfeifferszilard.hu/2020/09/09/why-do-certificate-revocation-checking-mechanisms-never-work.html), it is troubling that such a simple flow in an implementation can cause certificate compromise. The case would be even more worrying if there were a similar flow in certificate issuance, as this would compromise a CA, which could result in unpredictable consequences.\n\nPhoto by[ Jievani Weerasinghe](https://unsplash.com/@jievani?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on[ Unsplash](https://unsplash.com/photos/NHRM1u4GD_A?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n","date":"2023-03-16","id":"Blogposts_36","short_description":"Researchers at Kudelski Security have managed to break Bitcoin and Ethereum wallets using a novel attack against one of the most popular asymmetric key algorithms of modern cryptography, ECDSA.","slug":"bitcoin-account-hijacking-ecdsa-nonce-break","title":"Bitcoin account hijacking using OSINT techniques"},{"author":"Szilárd Pfeiffer","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/christian_lendl_Zytt_G_Su_o2_E_unsplash_76adf1b110.jpg"},"content":"**Quantum computing not only poses a great opportunity, but also a great threat to internet security. According to the promises of quantum computers, certain mathematical problems that form the basis of today’s most popular cryptographic algorithms will be much easier to solve with them than with classical computers. In a recent publication, Chinese researchers claim that there is an existing algorithm that, even with today's quantum computers, makes it possible to break the RSA algorithm, which is the fundamental basis of secure internet communication. At the same time, there are doubts about the reliability of the publication. However, even if these doubts are confirmed, it does not change the fact that the security threat posed by quantum computers remains with us.**\n\nThe basic claim of the [paper](https://arxiv.org/pdf/2212.12372.pdf), published last Christmas by 24 Chinese researchers, is that they have found an algorithm that enables 2,048-bit RSA keys to be broken even with the relatively low-power quantum computers available today. There is nothing really new in the fact that quantum computers pose a general risk to the reliability of cryptographic procedures that guarantee secure internet communications, such as [RSA open-key cryptography](https://en.wikipedia.org/wiki/RSA_(cryptosystem)) or the Diffie-Hellman key exchange algorithm. These procedures are based on mathematical problems that are practically unsolvable with conventional computers, but which can be solved in a few hours with sufficiently powerful quantum computers. Sufficiently large means 20 million [quantum bits](https://en.wikipedia.org/wiki/Qubit) (qubit) in this case. The problem with this figure of 20 million is that IBM's quantum computer – the largest quantum computer known today – can only render 433 of these 20 million qubits. It is not an exaggeration to say that the Chinese researchers chose one of the steepest hills to climb. But can they really overcome this challenge?\n\n> [Integer factorization](https://en.wikipedia.org/wiki/Integer_factorization) is the most widely used infeasible mathematical problem to guarantee that the cryptographic algorithms are practically unbreakable. Factorizing a number consisting of only a few digits is trivial (15 = 3 * 5), but the required computational capacity grows exponentially along with the number of digits. For hundreds or even thousands of digits, the computational effort required is so enormous that even using the highest performance supercomputers, the time required to do the calculation would be similar to the lifetime of the universe. According to the [recommendation](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf) of the [National Institute of Standards and Technology](https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology) (NIST), the smallest RSA key size that can be considered secure is 2,048 bits. This means approximately 600 digits, but in many cases larger keys of 3,072 or 4,096 bits are also used. There, the number of digits expressed in the decimal number system already exceeds a thousand, meaning that these keys are practically infeasible with traditional methods. At the same time, in 1994 [Peter Shor](https://en.wikipedia.org/wiki/Peter_Shor) already came up with an [algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm) that – on a quantum computer only existing in theory at the time – would be able to perform the prime factorization with much greater efficiency than before. This breakthrough would imply that a significant part of our encryption procedures would no longer be resistant to breaking, including, among other things, HTTPS, which ensures the security of browsing, or VPN protocols, one of the foundations of remote work.\n\n## Has Cryptographic Apocalypse Now arrived?\n\nThe Chinese researchers could only provide a theoretical answer to this question, since the solution and the techniques outlined by them require a 372-qubit computer. Though this does exist within the walls of IBM, the Chinese researchers did not have this machine at their disposal. However, they did succeed in factoring a 48-bit (15-digit) number with a 10-qubit computer. At first sight, this may not seem like much of a breakthrough, but it should be noted that this is the largest number that has ever been factored using a generic algorithm. Not to mention the fact that it was possible to put a theory into practice. The question is whether it was possible to bridge the aforementioned gap. As the correspondence between [Bruce Schneier](https://en.wikipedia.org/wiki/Bruce_Schneier) – one of the iconic figures of IT security – and [Roger A. Grimes](https://www.amazon.com/stores/Roger-A.-Grimes/author/B001IQUMT4) – the author of several books on cryptography – revealed:\n\n>“Apparently what happened is another guy who had previously announced he was able to break traditional asymmetric encryption using classical computers…but reviewers found a flaw in his algorithm and that guy had to retract his paper. But this Chinese team realized that the step that killed the whole thing could be solved by small quantum computers. So they tested and it worked.”\n\nYou might think that the cryptographic apocalypse is here.\n\n## Keep Calm and Dig Deep\n\nThe basis of the Chinese researchers’ algorithm relies on [Claus Schnorr](https://en.wikipedia.org/wiki/Claus_P._Schnorr)'s factorization algorithm (not to be confused with [Shor’s algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm)). The aforementioned algorithm works well with smaller numbers – with which the researchers themselves tested it – but falls apart with larger values. It is precisely this limitation that the Chinese researchers claim to have overcome. However, they do not mention any details, and they have not been able to prove the complete theory in practice due to the lack of a quantum computer with sufficient capacity. As Schneier cited the situation on his blog:\n\n> “So if it’s true that the Chinese paper depends on this Schnorr technique that doesn’t scale, the techniques in this Chinese paper won’t scale, either. (On the other hand, if it does scale then I think it also breaks a bunch of lattice-based public-key cryptosystems.)”\n\nDoes the uncertainty remain until someone tries the algorithm on a sufficiently large-capacity quantum computer? Partially.\n\nThere are, in fact, some signs that cast doubt on the whole story. One of these is that the Chinese researchers failed to win the $200,000 prize offered by the [RSA Factoring Challenge](https://en.wikipedia.org/wiki/RSA_Factoring_Challenge), which goes to whoever can successfully crack a 2048-bit RSA key. Of course, you could say that they did not have the necessary hardware, but a letter to IBM to get the prize, even if it is shared, would have been certainly worthwhile. People drawn to conspiracy theories may ask why the Chinese state did not keep the discovery for itself and started pouring money into the development of a suitable quantum computer. This would obviously cost a very substantial amount, but would also bring a very substantial benefit. At the same time, there is also strong skepticism from the scientific side. [Scott Aaronson](https://en.wikipedia.org/wiki/Scott_Aaronson) – former researcher at MIT, now at the University of Texas – made a [devastating statement on his blog](https://scottaaronson.blog/?p=6957) about the Chinese paper. Aaronson, in his pieces of research, primarily focuses on quantum computing and complexity theory, perhaps the most important fields of science concerning our topic. His three-word review about the content of the publication was: “No. Just no.” He criticized the publication in a firm tone:\n\n\n> “Then, finally, they come clean about the one crucial point in a single sentence of the Conclusion section:\n> It should be pointed out that the quantum speedup of the algorithm is unclear due to the ambiguous convergence of QAOA.\n> “Unclear” is an understatement here. It seems to me that a miracle would be required for the approach here to yield any benefit at all, compared to just running the classical Schnorr’s algorithm on your laptop. And if the latter were able to break RSA, it would’ve already done so.\n> All told, this is one of the most actively misleading quantum computing papers I’ve seen in 25 years, and I’ve seen … many.”\n\nAaronson is not alone in his opinion: [many](https://www.linkedin.com/feed/update/urn:li:activity:7016808281847336960/) [others](https://www.linkedin.com/feed/update/urn:li:activity:7017366747691241472/) criticize the research on the same basis, including Peter Shor, who says:\n\n> “There are apparently possible problems with this paper.”\n\nIt should also be highlighted that the research-sharing platform ([arχiv](https://arxiv.org/)), where the Chinese study was published, [does not perform peer reviews](https://arxiv.org/about), meaning that the mere fact of publication does not mean much, especially in such popular fields as quantum computing and cryptography. \n\n## So, are we off the hook or not?\n\nEven if we are able to recognize all the [research paper mills](https://en.wikipedia.org/wiki/Research_paper_mill) – which must necessarily be expected in a popular and highly regarded discipline such as cryptography or quantum computing – the harsh reality remains. Any encrypted data recorded today that uses a cryptographic process that does not withstand the challenges posed by quantum computers could become compromised in the not-too-distant future. As a result, it would be necessary to use algorithms that are thought to be secure against a cryptoanalytic attack by a quantum computer to mitigate the effect of the harvest-now-decrypt-later technique, as it cannot be eliminated. In the case of a cryptographic problem that received great publicity, such as Heartbleed in 2014, the market reacted relatively quickly, although it was weeks before the error disappeared from the 100,000 most-visited pages. In other cases, which have not received as much publicity, it can take years, according to statistics from [Qualys Pulse](https://www.ssllabs.com/ssl-pulse/) . In other words, we cannot expect the introduction of post-quantum cryptography to happen much faster than this.\n\nThis is just like global warming: a problem that cannot be dealt with in the future when it becomes critical. It should be dealt with in the present. The similarity is striking if we consider the fact that scientists have been scaring people with horror stories about quantum computers for decades. What seemed like a theory for a while, has now become the reality. [IBM promises a one-thousand-qubit computer](https://www.science.org/content/article/ibm-promises-1000-qubit-quantum-computer-milestone-2023) by the end of the year, and [Google a one-million-qubit one](https://www.cnet.com/tech/computing/google-plans-to-build-a-practical-quantum-computer-by-2029-at-new-center/) by the end of the decade. The latter does not promise anything good, since it is only a question of data storage capacity – how much data can be accessed after RSA becomes breakable. The first to have machines with sufficient capacity will presumably be the still much-criticized technology giants, and the most powerful states. Lawmakers still call for encryption backdoors [from time](https://www.helpnetsecurity.com/2017/06/20/eu-encryption-law/) [to time](https://www.helpnetsecurity.com/2021/04/05/weak-encryption/), despite the [warnings](https://balasys.eu/blogs/weakened-encryption-is-a-silver-bullet-not-just-for-law-enforcement-agencies-but-for-cybercriminals) about the [serious risks involved](https://pfeifferszilard.hu/2021/02/25/cryptography-weakening-a-tale-of-the-law-abiding-criminal.html), but with such a technical breakthrough, they would not necessarily need to do so. However, this may have consequences that are difficult to foresee both for privacy and the outcomes of conflicts that are increasingly transferred to cyberspace.","date":"2023-02-20","id":"Blogposts_35","short_description":"In a recent publication, Chinese researchers claim that there is an existing algorithm that, even with today's quantum computers, makes it possible to break the RSA algorithm, which is the fundamental basis of secure internet communication. At the same time, there are doubts about the reliability of the publication.","slug":"chinese-researchers-rsa-is-breakable-others-do-not-panic","title":"Chinese researchers: RSA is breakable. Others: Do not panic! "},{"author":"László Horváth, Pre-Sales Engineer at Balasys","avatar":{"url":"https://balasysmediastorage.blob.core.windows.net/websiteimages/uploads/code_1839406_1280_48de8cd8f8.jpg"},"content":"*WAF-as-a-service solutions are becoming an increasingly popular method for protecting websites and services running in the cloud. One significant advantage is the vendors' claim that security settings can be updated in time based on the data from incoming attacks that are caught. However, the question arises: how effective and inevitable are current WAFs and WAF-as-a-service solutions?*\n\nIt is essential to address this issue as injection attacks are a prominent feature in the periodic OWASP Top 10 list, ranking 1st in 2013 and 2017 and 3rd in 2021, after broken access control and cryptographic failures. \n\n\n## Autospear: the new generation of SQL attacks \n\nAt the Black Hat Asia conference in May, researchers from Zhejiang University in China presented a new automated SQLi method for testing and bypassing signature-based WAFs. The method consists of using algorithms to modify the code originally intended to be injected – which is detected and blocked by firewalls by default – until it cannot be detected using the negative security model. \n\nThe modifications were as follows: \n\n| MODIFICATION | EXAMPLE |\n| --- | --- |\n| Case Swapping | or 1 = 1 → oR 1 = 1 |\n| Whitespace Substitution | or 1 = 1 → \\tor1\\n=1 |\n| Comment Injection | or 1 = 1 → /\\*foo\\*/or 1 =/\\*bar\\*/1 |\n| Comment Rewriting | /\\*foo\\*/or 1 = 1 → /\\*1.png\\*/or 1 = 1 |\n| Integer Encoding | or 1 = 1 → or 0x1 = 1 |\n| Operator Swapping | or 1 = 1 → or 1 like 1 |\n| Logical Invariant | or 1 = 1 → or 1 = 1 and 'a' = 'a' |\n| Inline Comment | or 1 = 1 → /\\*!or/ 1 = 1
union select → /\\*!union\\*/ /\\*!50000select\\*/ |\n| Where Rewriting | where xxx → where xxx and True
where xxx → where (select 0) or xxx |\n| DML Substitution | or 1 = 1 → \\|\\| 1 = 1
and name = 'foo‘ → && name = 'foo' |\n| Tautology Substitution | 1 = 1 → ‘foo’ = ‘foo’
‘1’ = ‘1‘ → 2 <> 3
1 = 1 → (select ord(’r’) regexp 114) = 0x1 |\n\nThe point of the modifications, in this case, is that the SQL command will not change semantically, and the database server will be able to process it, but the signature-based protection can be bypassed. To do this, an algorithm is used that systematically maps which modifications can be run by trial and error and uses the feedback to design the code for the final attack. \n\nThe researchers tested the method on seven popular web application firewalls, four of which are available on Amazon Web Services as WAF-as-a-service. They focused on four types of requests (GET / GET(JSON) / POST / POST(JSON) and generated 10,000 unique codes from 100 known SQLi expressions. \n\nThe results suggest that WAF-as-a-service solutions can be attacked with high effectiveness, as there were vendors with 89% or more success using JSON payload. \n \n\n## Positive security model: protection against Autospear and other attacks\n\nThe positive security model has often been criticized for being more time-consuming and complex – and therefore more costly – to develop than the signature-based model. Still, it can provide much more effective protection against Autospear and similar attacks. With a properly designed and maintained API schema, the acceptable incoming data in a given field can be limited to the point where any modification that does not contain the expected data will immediately block the call. For example, in a userid field, you can specify precisely where and what characters are expected, their length, and composition. \n\nThis takes time and expertise, and needs to be tailored to the specific API in each case. It is not a switch that, when flipped, can give a false sense of security that you are protected against OWASP Top10 vulnerabilities. \n\nAnother severe criticism is that the positive security model gives too many false positives, though this problem can be avoided using expert-created and maintained templates and continuous feedback during testing. \n\nHowever, a proper API security solution can help you to build your positive security model effectively. It is essential to ensure proper logging is in place during the development and testing phase. This can help you picture what your core traffic consists of and what vulnerabilities exist. A positive security model also enables you to test existing – or possibly missing – traffic-based schemes under controlled conditions. You can provide appropriate feedback to your developers by filtering out any calls that may occur that do not conform to the scheme. This can be recorded in log files in a developer environment with accurate feedback without interrupting the call. In a live system, you can immediately cut off the call without feedback or send a misleading message to the attacker. ","date":"2022-11-30","id":"Blogposts_33","short_description":"Web Application Firewalls (WAFs) are widely used to protect websites and APIs against various attacks, such as SQL injection (SQLi) and cross-site-scripting (XSS). ","slug":"weaknesses-of-signature-based-api-protection","title":"Weaknesses of signature-based API protection"}]}},"pageContext":{"slug":"modern-techniques-to-prevent-malware-instead-of-detecting-it"}},
"staticQueryHashes": ["3233329270","3621970722","521397250","585144119"]}