Cotopaxi - Set Of Tools For Security Testing Of Internet Of Things Devices Using Specific Network IoT Protocols

1. scapy-ssl_tls (this will install also scapy in 2.4.2)

    pip install git+https://github.com/tintinweb/scapy-ssl_tls@ec5714d560c63ea2e0cce713cec54edc2bfa0833

• If you encounter error: error: [Errno 2] No such file or directory: 'LICENSE', try repeating command - surprisingly it works.
• If you encounter error: NameError: name 'os' is not defined - add missing import os to scapy/layers/ssl_tls.py.

    pip install -r cotopaxi/requirements.txt

    pip install dnslib IPy hexdump pyyaml psutil enum34 configparser

• service_ping
• server_fingerprinter
• resource_listing
• server_fingerprinter
• protocol_fuzzer (for fuzzing servers)
• client_proto_fuzzer (for fuzzing clients)
• vulnerability_tester (for testing servers)
• client_vuln_tester (for testing clients)
• amplifier_detector

usage: sudo python -m cotopaxi.service_ping [-h] [-v] [--protocol {UDP,TCP,CoAP,MQTT,DTLS,ALL}]
                       [--src-port SRC_PORT]
                       dest_ip dest_port

positional arguments:
  dest_ip               destination IP address or multiple IPs separated by
                        coma (e.g. '1.1.1.1,2.2.2.2') or given by CIDR netmask
                        (e.g. '10.0.0.0/22') or both
  dest_port             destination port or multiple ports given by list
                        separated by coma (e.g. '8080,9090') or port range
                        (e.g. '1000-2000') or both

optional arguments:
  -h, --help            show this help message and exit
  --retries RETRIES, -R RETRIES
                        number of retries
  --timeout TIMEOUT, -T TIMEOUT
                        timeout in seconds
  --verbose, -V, --debug, -D
                        Turn on verbose/debu   g mode (more messages)
  --protocol {UDP,TCP,CoAP,mDNS,SSDP,MQTT,DTLS,ALL,HTCPCP}, -P {UDP,TCP,CoAP,mDNS,SSDP,MQTT,DTLS,ALL,HTCPCP}
                        protocol to be tested (UDP includes CoAP, DTLS, mDNS,
                        and SSDP, TCP includes CoAP, HTCPCP, and MQTT, ALL
                        includes all supported protocols)
  --src-port SRC_PORT, -SP SRC_PORT
                        source port (if not specified random port will be
                        used)

• CoAP:
  • aiocoap,
  • CoAPthon,
  • FreeCoAP,
  • libcoap,
  • MicroCoAP,
  • Mongoose
  • Wakaama (formerly liblwm2m)
• DTLS:
  • GnuTLS,
  • Goldy,
  • LibreSSL,
  • MatrixSSL,
  • mbed TLS,
  • OpenSSL,
  • TinyDTLS

usage: sudo python -m cotopaxi.server_fingerprinter [-h] [--retries RETRIES] [--timeout TIMEOUT]
                               [--verbose]
                               [--protocol {CoAP,DTLS}]
                               [--src-port SRC_PORT]
                               dest_ip dest_port

positional arguments:
  dest_ip               destination IP address or multiple IPs separated by
                        coma (e.g. '1.1.1.1,2.2.2.2') or given by CIDR netmask
                        (e.g. '10.0.0.0/22') or both
  dest_port             destination port or multiple ports given by list
                        separated by coma (e.g. '8080,9090') or port range
                        (e.g. '1000-2000') or both

optional arguments:
  -h, --help            show this help message and exit
  --retries RETRIES, -R RETRIES
                        number of retries
  --timeout TIMEOUT, -T TIMEOUT
                           timeout in seconds
  --verbose, -V, --debug, -D
                        Turn on verbose/debug mode (more messages)
  --protocol {CoAP,DTLS}, -P {CoAP,DTLS}
                        protocol to be tested
  --src-port SRC_PORT, -SP SRC_PORT
                        source port (if not specified random port will be
                        used)
  --ignore-ping-check, -Pn
                        ignore ping check (treat all ports as alive)

usage: sudo python -m cotopaxi.resource_listing [-h] [-v] [--protocol {CoAP,ALL}]
                           [--method {GET,POST,PUT,DELETE,ALL}]
                           [--src-port SRC_PORT]
                           dest_ip dest_port url_filepath

positional arguments:
  dest_ip               destination IP address or multiple IPs separated by
                        coma (e.g. '1.1.1.1,2.2.2.2') or given by CIDR netmask
                        (e.g. '10.0.0.0/22') or both
  dest_port             destination port or multiple ports given by list
                        separated by coma (e.g. '8080,9090') or port range
                        (e.g. '1000-2000') or both
  url_filepath          path to file with list of URLs to be tested (each URL
                        in separated line)

optional arguments:
  -h, --help            show this help message and exit
  --retries RETRIES, -R RETRIES
                           number of retries
  --timeout TIMEOUT, -T TIMEOUT
                        timeout in seconds
  --verbose, -V, --debug, -D
                        Turn on verbose/debug mode (more messages)
  --protocol {CoAP,mDNS,SSDP}, -P {CoAP,mDNS,SSDP}
                        protocol to be tested
  --method {GET,POST,PUT,DELETE,ALL}, -M {GET,POST,PUT,DELETE,ALL}
                        methods to be tested (ALL includes all supported
                        methods)
  --src-port SRC_PORT, -SP SRC_PORT
                        source port (if not specified random port will be
                        used)
  --ignore-ping-check, -Pn
                        ignore ping check (treat all ports as alive)

usage: sudo python -m cotopaxi.protocol_fuzzer 
                          [-h] [--retries RETRIES] [--timeout TIMEOUT]
                          [--verbose] [--protocol {CoAP,mDNS,MQTT,DTLS}]
                          [--src-ip SRC_IP] [--src-port SRC_PORT]
                          [--ignore-ping-check] [--corpus-dir CORPUS_DIR]
                          dest_ip dest_port

positional arguments:
  dest_ip               destination IP address or multiple IPs separated by
                        coma (e.g. '1.1.1.1,2.2.2.2') or given by CIDR netmask
                        (e.g. '10.0.0.0/22') or both
  dest_port             destination port or multiple ports given by list
                        separated by coma (e.g. '8080,9090') or port range
                        (e.g. '1000-2000') or both

optional arguments:
  -h, --help            show this help message and exit
  --retries RETRIES, -R RETRIES
                           number of retries
  --timeout TIMEOUT, -T TIMEOUT
                        timeout in seconds
  --verbose, -V, --debug, -D
                        Turn on verbose/debug mode (more messages)
  --protocol {CoAP,mDNS,MQTT,DTLS,SSDP,HTCPCP}, -P {CoAP,mDNS,MQTT,DTLS,SSDP,HTCPCP}
                        protocol to be tested
  --hide-disclaimer, -HD
                        hides legal disclaimer (shown before starting
                        intrusive tools)
  --src-ip SRC_IP, -SI SRC_IP
                        source IP address (return result will not be
                        received!)
  --src-port SRC_PORT, -SP SRC_PORT
                        source port (if not specified random port will be
                        used)
  --ignore-ping-check, -Pn
                        ignore ping check (treat all ports as alive)
  --corpus-dir CORPUS_DIR, -C CORPUS_DIR
                        path t   o directory with fuzzing payloads (corpus) (each
                        payload in separated file)
  --delay-after-crash DELAY_AFTER_CRASH, -DAC DELAY_AFTER_CRASH
                        number of seconds that fuzzer will wait after crash
                        for respawning tested server

usage: sudo client_proto_fuzzer.py [-h] [--server-ip SERVER_IP]
                              [--server-port SERVER_PORT]
                              [--protocol {CoAP,mDNS,MQTT,DTLS,SSDP,HTCPCP}]
                              [--verbose] [--corpus-dir CORPUS_DIR]

optional arguments:
  -h, --help            show this help message and exit
  --server-ip SERVER_IP, -SI SERVER_IP
                        IP address, that will be used to set up tester server
  --server-port SERVER_PORT, -SP SERVER_PORT
                        port that will be used to set up server
  --protocol {CoAP,mDNS,MQTT,DTLS,SSDP,HTCPCP}, -P {CoAP,mDNS,MQTT,DTLS,SSDP,HTCPCP}
                        protocol to be tested
  --verbose, -V, --debug, -D
                        Turn on verbose/debug mode (more messages)
  --corpus-dir CORPUS_DIR, -C CORPUS_DIR
                        path to directory with fuzzing payloads (corpus) (each
                           payload in separated file)

usage: sudo python -m cotopaxi.vulnerability_tester [-h] [-v]
                               [--cve {ALL,CVE-2018-19417,...}]
                               [--list LIST] [--src-port SRC_PORT]
                               dest_ip dest_port

positional arguments:
  dest_ip               destination IP address or multiple IPs separated by
                        coma (e.g. '1.1.1.1,2.2.2.2') or given by CIDR netmask
                        (e.g. '10.0.0.0/22') or both
  dest_port             destination port or multiple ports given by list
                        separated by coma (e.g. '8080,9090') or port range
                        (e.g. '1000-2000') or both

optional arguments:
  -h, --help            show this help message and exit
  --retries RETRIES, -R RETRIES
                        number of retries
  --timeout TIMEOUT, -T TIMEOUT
                        timeout in seconds
  --protocol    {UDP,TCP,CoAP,mDNS,MQTT,DTLS,ALL}, -P {UDP,TCP,CoAP,mDNS,MQTT,DTLS,ALL}
                        protocol to be tested (UDP includes CoAP, mDNS and
                        DTLS, TCP includes CoAP and MQTT, ALL includes all
                        supported protocols)
  --hide-disclaimer, -HD
                        hides legal disclaimer (shown before starting
                        intrusive tools)
  --verbose, -V, --debug, -D
                        Turn on verbose/debug mode (more messages)
  --cve {ALL,CVE-2018-19417,...}
                        list of vulnerabilities to be tested (by CVE id)
  --vuln {ALL,BOTAN_000,COAPTHON3_000,...} 
                        list of vulnerabilities to be tested (by SOFT_NUM id)

  --list, -L            display lists of all vulnerabilities supported by this
                           tool with detailed description
  --src-port SRC_PORT, -SP SRC_PORT
                        source port (if not specified random port will be
                        used)
  --ignore-ping-check, -Pn
                        ignore ping check (treat all ports as alive)

usage: sudo client_vuln_tester.py [-h] [--server-ip SERVER_IP]
                             [--server-port SERVER_PORT]
                             [--protocol {CoAP,mDNS,MQTT,DTLS,SSDP,HTCPCP}]
                             [--verbose]
                             [--vuln {ALL,BOTAN_000,COAPTHON3_000,...} [{ALL,BOTAN_000,COAPTHON3_000,...} ...]]
                             [--cve {ALL,CVE-2017-12087,...} [{ALL,CVE-2017-12087,...} ...]]
                             [--list]

optional arguments:
  -h, --help            show this help message and exit
  --server-ip SERVER_IP, -SI SERVER_IP
                        IP address, that will be used to set up tester server
  --server-port SERVER_PORT, -SP SERVER_PORT
                        port that will be used to set up server
  --protocol {CoAP,mDNS,MQTT,DTLS,SSDP,HTCPCP}, -P {CoAP,mDNS,MQTT,DTLS,SSDP,HTCPCP}
                        protocol to be tested
  --verbo   se, -V, --debug, -D
                        Turn on verbose/debug mode (more messages)
  --vuln {ALL,BOTAN_000,COAPTHON3_000,...} [{ALL,BOTAN_000,COAPTHON3_000,...} ...]
                        list of vulnerabilities to be tested (by SOFT_NUM id)
  --cve {ALL,CVE-2017-12087,CVE-2017-12130,...} [{ALL,CVE-2017-12087,CVE-2017-12130,...} ...]
                        list of vulnerabilities to be tested (by CVE id)
  --list, -L            display lists of all vulnerabilities supported by this
                        tool with detailed description

usage: sudo python -m cotopaxi.amplifier_detector [-h] [--port PORT] [--nr NR] [--verbose] dest_ip

positional arguments:
  dest_ip               destination IP address

optional arguments:
  -h, --help            show this help message and exit
  --interval INTERVAL, -I INTERVAL
                        minimal interval in sec between displayed status
                        messages (default: 1 sec)
  --port PORT, --dest_port PORT, -P PORT
                        destination port
  --nr NR, -N NR        number of packets to be sniffed (default: 9999999)
  --verbose, -V, --debug, -D
                        turn on verbose/debug mode (more messages)

• testing services running on the same machine can results in issues occurred by not delivering some packets,
• multiple tools running against the same target can result in interference between them (packets may be indicated as a response to another request).

    sudo python -m unittest discover

Feds Shut Down Largest Dark Web Child Abuse Site; South Korean Admin Arrested

Graboid the first-ever Cryptojacking worm that targets Docker Hub

Security experts at Palo Alto Networks discovered a worm dubbed Graboid that spreads using Docker containers.

Palo Alto Networks researchers discovered a new Monero miner with wormable capabilities, dubbed Graboid, that spreads using Docker containers.

Experts discovered that to target new systems, the Graboid worm periodically queries the C&C for vulnerable hosts, in this way the malicious code is instructed about the next target to infect.

“Unit 42 researchers identified a new cryptojacking worm we’ve named Graboid that’s spread to more than 2,000 unsecured Docker hosts. We derived the name by paying homage to the 1990’s movie “Tremors,” since this worm behaves similarly to the sandworms in the movie, in that it moves in short bursts of speed, but overall is relatively inept.” reads the analysis published by the experts.

Graboid is the first-ever Cryptojacking worm found in images on Docker Hub, the analysis conducted by the experts shows that, on average, each miner is active 63% of the time, with the mining periods being of 250 seconds.

Palo Alto Networks found over 2,000 Docker engines unsecured online, this means that threat actors could to take full control of them and abuse their resources for malicious purposes.

The hackers first compromise an unsecured Docker daemon, then they ran the malicious container from Docker Hub, it fetches scripts and a list of vulnerable hosts from the C&C, and spread targeting the host in the list.

‘Graboid’ implements both worm-spreading and cryptojacking capabilities inside containers. The experts noticed that the malware randomly selects three targets at each iteration. It installs the worm on the first target, stops the miner on the second target, and starts the miner on the third target, leading to a very random mining behavior.

“Essentially, the miner on every infected host is randomly controlled by all other infected hosts. The motivation for this randomized design is unclear. It can be a bad design, an evasion technique (not very effective), a self-sustaining system or some other purposes.” continues the analysis.

Experts reported that the malicious Docker image (pocosow/centos) has been downloaded more than 10,000 times from Docker Hub, while the gakeaws/nginx image has been downloaded over 6,500 times.

“While this cryptojacking worm doesn’t involve sophisticated tactics, techniques, or procedures, the worm can periodically pull new scripts from the C2s, so it can easily repurpose itself to ransomware or any malware to fully compromise the hosts down the line and shouldn’t be ignored.” concludes the analysis. “If a more potent worm is ever created to take a similar infiltration approach, it could cause much greater damage, so it’s imperative for organizations to safeguard their Docker hosts.”

Pierluigi Paganini

(SecurityAffairs – Graboid, hacking)

The post Graboid the first-ever Cryptojacking worm that targets Docker Hub appeared first on Security Affairs.

M6 Group, largest France private multimedia group, hit by ransomware attack

M6, one of France’s biggest TV channels, hit by ransomware

Unlike The Weather Channel earlier this year, M6 remained on the air.

The M6 Group, the largest France private multimedia group, was the victim of ransomware over the weekend.

The systems at the M6 Group, France’s largest private multimedia group, were infected with the ransomware over the weekend, fortunately, none of the company’s TV and radio channels interrupted the broadcasts.

According to the French newspaper L’Express, the ransomware attack only impacted landlines and e-mail.

“The company’s phone lines and e-mail are unusable, so employees have to use their mobile phones and text messages to communicate,” an internal source told the newspaper. “all the office and management tools are in disruption.” 

The company revealed the incident took place on Saturday.

The cybersecurity staff at the M6 Group was able to immediately mitigate the threat preventing any downtime its TV channels, radio stations, and film studios.

“The M6 ​​Group was the target of a malicious computer attack on Saturday morning, and the quick and efficient intervention of our cyber security experts has helped to ensure the continued security of the Internet. good broadcasting of the programs on all our TV and radio antennas “.  reads the message posted through the Twitter account of the group.

In April, another broadcast suffered a similar incident, a cyber attack hit the Weather Channel and forced it off the air for at least 90 minutes.

In April 2015, the TV5Monde was hit by a severe cyber attack that compromised broadcasting of transmissions across its medium. The attackers also hijacked the Channel TV5Monde website and social media accounts of the French broadcaster.

Yves Bigot, at the time the director-general of TV5Monde told the BBC that the cyber-attack came close to destroying the network of the French TV and investigation suggested Russia-linked APT28 group.

Pierluigi Paganini

(SecurityAffairs – M6 Group, ransomware)

The post M6 Group, largest France private multimedia group, hit by ransomware attack appeared first on Security Affairs.

A Comprehensive Guide On How to Protect Your Websites From Hackers

When Card Shops Play Dirty, Consumers Win

Cybercrime forums have been abuzz this week over news that BriansClub — one of the underground’s largest shops for stolen credit and debit cards — has been hacked, and its inventory of 26 million cards shared with security contacts in the banking industry. Now it appears this brazen heist may have been the result of one of BriansClub’s longtime competitors trying to knock out a rival.

And advertisement for BriansClub that for years has used my name and likeness to peddle stolen cards.

Last month, KrebsOnSecurity was contacted by an anonymous source who said he had the full database of 26M cards stolen from BriansClub, a carding site that has long used this author’s name and likeness in its advertising. The stolen database included cards added to the site between mid-2015 and August 2019.

This was a major event in the underground, as experts estimate the total number of stolen cards leaked from BriansClub represent almost 30 percent of the cards on the black market today.

The purloined database revealed BriansClub sold roughly 9.1 million stolen credit cards, earning the site and its resellers a cool $126 million in sales over four years.

In response to questions from KrebsOnSecurity, the administrator of BriansClub acknowledged that the data center serving his site had been hacked earlier in the year (BriansClub claims this happened in February), but insisted that all of the cards stolen by the hacker had been removed from BriansClub store inventories.

However, as I noted in Tuesday’s story, multiple sources confirmed they were able to find plenty of card data included in the leaked database that was still being offered for sale at BriansClub.

Perhaps inevitably, the admin of BriansClub took to the cybercrime forums this week to defend his business and reputation, re-stating his claim that all cards included in the leaked dump had been cleared from store shelves.

The administrator of BriansClub, who’s appropriated the name and likeness of Yours Truly for his advertising, fights to keep his business alive.

Meanwhile, some of BriansClub’s competitors gloated about the break-in. According to the administrator of Verified, one of the longest running Russian language cybercrime forums, the hack of BriansClub was perpetrated by a fairly established ne’er-do-well who uses the nickname “MrGreen” and runs a competing card shop by the same name.

The Verified site admin said MrGreen had been banned from the forum, and added that “sending anything to Krebs is the lowest of all lows” among accomplished and self-respecting cybercriminals. I’ll take that as a compliment.

This would hardly be the first time some cybercriminal has used me to take down one of his rivals. In most cases, I’m less interested in the drama and more keen on validating the data and getting it into the proper hands to do some good.

That said, if the remainder of BriansClub’s competitors want to use me to take down the rest of the carding market, I’m totally fine with that.

The BriansClub admin, defending the honor of his stolen cards shop after a major breach.

Auto Re - IDA PRO Auto-Renaming Plugin With Tagging Support

• Sets tags as repeatable function comments and displays TAG tree in the separate view

PCAP Analysis Basics with Wireshark [Updated 2019]

Wireshark is a very useful tool for information security professionals and is thought of by many as the de facto standard in network packet and protocol analysis. It is a freeware tool that, once mastered, can provide valuable insight into your environment, allowing you to see what’s happening on your network. What follows is a […]

The post PCAP Analysis Basics with Wireshark [Updated 2019] appeared first on Infosec Resources.

Signature update for Symantec Endpoint protection crashed many device

Symantec rolled out an intrusion prevention signature update for its Endpoint Protection product that has caused many devices to crash and display a so-called blue screen of death (BSOD).

An intrusion prevention signature update for the Endpoint Protection product had a bad impact on the devices, in many cases it caused the devices to crash and display the blue screen of death (BSOD).

Several users reported problems through the company’s support forums and other sites online.

Customers complained about problems with Windows 7, 8 and 10.

Symantec has acknowledged the problem with the update to its Endpoint Protection Client explaining that it causes a Windows kernel exception.

The company released the version 2019/10/14 r62 to address the issue caused by the 2019/10/14 r61 update.

“After running LiveUpdate on Symantec Endpoint Protection (SEP), the computer crashes indicating IDSvix86.sys/IDSvia64.sys as the cause of the exception.” reads the security advisory published by the researchers.

Symantec recommends to download the new signature version for the Endpoint Protection or roll back to an earlier stable version.

“Please run LiveUpdate to download latest Intrusion Prevention signature 2019/10/14 r62, or rollback to an earlier known good content revision to prevent the BSOD situation. Please check How to Backdate Virus Definitions in Endpoint Protection Manager for more details on how to roll back definitions.” continues Symantec.

Customers who cannot run LiveUpdate to apply the signatures on their systems can use the following workaround:

1. Boot in Safe Mode and perform the following for x64 or x86 installations of SEP,
2. Run sc config idsvia64 start= disabled or sc config idsviax86 start=disabled from cmd,
3. Reboot in normal mode,
4. Update the IPSdefs,
5. Run sc config idsvia64 start= system or sc config idsviax86 start=system from cmd
6. Reboot.

Pierluigi Paganini

(SecurityAffairs – Symantec, BSOD)

The post Signature update for Symantec Endpoint protection crashed many device appeared first on Security Affairs.

Red Team operations: Best practices

Introduction The goal of a Red Team assessment is for the Red Team to find as many vulnerabilities as possible within the customer’s current security setup. In general, this is accomplished by a lot of lateral thinking, trying different types of attacks and considering how certain defenses can be bypassed. However, some best practices exist […]

The post Red Team operations: Best practices appeared first on Infosec Resources.

The difference between Cross-Site and Server-Side Request Forgery

Introduction to CSRF and SSRF Cross-Site Request Forgery and Server-Side Request Forgery attacks have similar names, and both take advantage of how servers process URLs. However, these attacks have very different purposes and impacts. Understanding the difference between them is an important part of penetration testing for web applications. Cross-Site Request Forgery Cross-Site Request Forgery […]

The post The difference between Cross-Site and Server-Side Request Forgery appeared first on Infosec Resources.

Managing Updates and Patches in Windows 10

Introduction Updates and patches are vital to maintain information security standards on Windows systems. They include recent changes in the threat landscape, help fix preexisting bugs and apply recent service packs to your system.  Windows 10 offers a dramatically changed approach to managing updates and patches. This article details the Windows 10 approach, including where […]

The post Managing Updates and Patches in Windows 10 appeared first on Infosec Resources.

Phorpiex Botnet Sending Out Millions of Sextortion Emails Using Hacked Computers

Approaching the Reverse Engineering of a RFID/NFC Vending Machine

Security expert Pasquale Fiorillo demonstrates how to hack n RFID/NFC Vending Machine.

The affected vendor did not answer to my responsible disclosure request, so I’m here to disclose this “hack” without revealing the name of the vendor itself.

The target vending machine uses an insecure NFC Card, MIFARE Classic 1k, that has been affected by multiple vulnerabilities so should not be used in important application.
Furthermore, the user’s credit was stored on the card enabling different attack scenarios, from double spending to potential data tamper storing an arbitrary credit.

Useful notes from MIFARE Classic 1K datasheet:

EEPROM: 1 kB is organized in 16 sectors of 4 blocks. One block contains 16 bytes.
The last block of each sector is called “trailer”, which contains two secret keys and programmable access conditions for each block in this sector.

• Manufacturer block: This is the first data block (block 0) of the first sector (sector 0). It contains the IC manufacturer data. This block is read-only.
• Data blocks: All sectors contain 3 blocks of 16 bytes for storing data (Sector 0 contains only two data blocks and the read-only manufacturer block).
  The data blocks can be configured by the access conditions bits as:
  • Read/Write blocks: fully arbitrary data, in arbitrary format
  • Value blocks: fixed data format which permits native error detection and correction and a backup management.
    A value block can only be generated through a write operation in value block format:
    • Value: Signifies a signed 4-byte value. The lowest significant byte of a value is stored in the lowest address byte. Negative values are stored in standard 2´s complement format. For reasons of data integrity and security, a value is stored three times, twice non-inverted and once inverted.
    • Adr: Signifies a 1-byte address, which can be used to save the storage address of a block, when implementing a powerful backup management. The address byte is stored four times, twice inverted and non-inverted.

Let’s start hacking:

In this post I did not show you how to crack the MIFARE Classic Keys needed to read/write the card, ’cause someone else has already disclosed it some time ago, so google is your friend.
At last, please, use this post to skill yourself about the fascinating world of reverse engineering, and not for stealing stuffs.

In order to start the analysis I need some dump to compare.
The requirements of this task are nfc-mfclassic tool included in libnfc, a NFC hardware interface like ACR122U, and a binary compare (aka binarydiff) tool like dhex.

Dumps:

• Dump 0: Virgin card (not included in the screenshot below ’cause all data bytes were 0x00, except for the sector 0 that has UID and manufacturer information. These sector is read only, so these bytes are the same across dumps)
• Dump 1: Card charged with single 0.10€ coin (Note that vending machine displays the balance with 3 decimals, 0.100€)
• Dump 2: 0.00€ after spending the entire balance with 4 transactions of 0.025€ each
• Dump 3: 0.10€ recharged with one single coin

Blurred bytes are the MIFARE keys A and B, except for the 32 bytes at 0xE0 offset of which I don’t know their purpose.
The 4 bytes between the keys are Access Condition and denotes which key must be used for read and write operation (A or B key) and the block type (“read/write block” or “value block”).

The tool mfdread is useful to decode the Access Condition bytes rapidly, and, in general, to display MIFARE Classic data divided by sectors and blocks:

Early analysis:

Note: from now on I will refer to the offsets with a [square parenthesis] and a value with no parenthesis.

• Blocks 8, 9, 10, 12 and 13 can be used also as “value block”
• Except for bytes between offsets [0x80] and [0x9F], only few bytes differ between dumps
• Some data are redundant, for example [0x60 … 0x63] has the same values of [0xA0 … 0xA3]
• Values at [0xC0], [0xD0], [0xC8], [0xD8] differ by 4 between 1st and 2nd dump (eg: 0xFE – 0xFA = 0x4) and differ by 1 between 2nd dump and 3rd dump (eg: 0xFA – 0xF9 = 0x1)
• Values at [0xC4], [0xD4] differ by 4 between 1st and 2nd dump (eg: 0x05 – 0x01 = 0x4) and differ by 1 between 2nd and 3rd dump (eg: 0x06 – 0x05 = 0x1)
  • 4 is the number of spent transaction made the first time, and 1 is the number of recharge transaction made the second time
• Sum between yellow squared and red squared offsets has 0xFF value. In other words red squared is inverse (XOR with 0xFF) of yellow squared. For example:
  • 0xFE ⊕ 0xFF = 0x01
  • 0xFF ⊕ 0xFF = 0x00
  • …
  • 0x7F ⊕ 0xFF = 0x80
• Values at [0x60 … 0x63] are a UNIX TIMESTAMP in little endian notation:
  • Dump 1: 0x4F9E2C27 -> 0x272C9E4F = 657235535 = 10/29/1990 @ 9:25pm
  • Dump 2: 0x71B62C27 -> 0x272CB671 = 657241713 = 10/29/1990 @ 11:08pm
  • Dump 3: 0x18592D27 -> 0x272D5918 = 657283352 = 10/30/1990 @ 10:42am
    • Ok, we are not in the 90ies, but the time difference between transactions is correct, maybe the vending machine doesn’t have an UPS

Early findings:

• Timestamp of the last transaction was stored as 32 bit integer at MIFARE block 6 and redundant at at MIFARE block 10
• Only MIFARE blocks 12 and 13 has “Value block” format, and they are used to store the counter of remain transaction in 32 bit format.
  This counter starts from 0x7FFFFFFF (2.147.483.647) and is decreased at each transaction
• Blocks 1, 4, and 14 contains some data that are fixed between dumps
• Blocks 8 and 9 changes entirely at each transaction
  

The credit:

If there is credit stored on the card, it was encoded at blocks 8 and 9, and the number of bytes involved between small credit difference (for example between 0.00€ and 0.10€) could indicate that some cryptographic function is involved.

At this time, a double spending attack could confirm if the credit is really stored on the card.
So, after spending all the credit, I have rewritten a previous dump on the card and I went to test it at the vending machine. The card was fully functional with the previous credit stored in that dump. Now, I’m certain that the credit is encoded (and probably encrypted) in the blocks 8 and 9.

Conclusion:

Even if the encoding format of the credit is still unknown, a double spending attack was possible.

This means that the vendor’s effort to obfuscate the credit is nullified

Adding some unique token on the card that are invalidated into back-end after each transaction, means that this token needs to be shared between all the vending machines of the vendor, but, if we add internet connection to the vending machine, there is no longer reason to store the credit on the card.

So, after all, the only remediation action that makes sense is: DO NOT STORE THE CREDIT ON THE CARD! And, more generally: DO NOT TRUST THE CLIENT!

Road to arbitrary credit:

Spending 1€ infinite times isn’t the scope of that hack. The only real scope is FUN!
To continue this analysis I need to collect a large number of dumps to advance some hypothesis so, when I have other material I will make another post.

An example of easier card:

Some vendor has more easier approach by using the MIFARE “Value block” to store the credit without obfuscation or encryption.

The above screenshot made with “MIFARE Classic Tool” on Android smartphone, represents a Value Block used to store the credit:

0x00000CE4 = 3300 is the value in Euro thousandths (3.30€).

This particular vendor do not use key A and the Key B is a default key 0xFFFFFFFFFFFFFFFF, so the attacker doesn’t need to crack anything.

Reverse engineering and cracking of a Vending Machine is always funny.

The original post was published here

About the author: Pasquale Fiorillo

I’m a Security Auditor of ISGroup and an independent Security Researcher. As Security Auditor, my job is to perform security activities like Penetration Test and Vulnerability Assessment on networks and web applications in order to identify security issues that may be exploited by an attacker to perform malicious actions on your assets.

When I was a teenager I have co-founded an underground e-zine called Italian Hard Phreaking with some friends on IRC, writing lots of papers related to hack and reverse engineering stuffs in the telecommunication world. Later, I’ve started a new adventure as a Security Researcher, discovering vulnerabilities in a commonly used software, web applications, and web sites, in collaboration with other fabulous people of U.S.H.

Pierluigi Paganini

(SecurityAffairs – hacking)

The post Approaching the Reverse Engineering of a RFID/NFC Vending Machine appeared first on Security Affairs.

Gobuster v3.0 - Directory/File, DNS And VHost Busting Tool Written In Go

• URIs (directories and files) in web sites.
• DNS subdomains (with wildcard support).
• Virtual Host names on target web servers.

1. ... something that didn't have a fat Java GUI (console FTW).
2. ... to build something that just worked on the command line.
3. ... something that did not do recursive brute force.
4. ... something that allowed me to brute force folders and multiple extensions at once.
5. ... something that compiled to native on multiple platforms.
6. ... something that was faster than an interpreted script (such as Python).
7. ... something that didn't require a runtime.
8. ... use something that was good with concurrency (hence Go).
9. ... to build something in Go that wasn't totally useless.

• Not use it.
• Show me how to do it better.

• New CLI options so modes are strictly seperated (-m is now gone!)
• Performance Optimizations and better connection handling
• Ability to bruteforce vhost names
• Option to supply custom HTTP headers

• dir - the classic directory brute-forcing mode
• dns - DNS subdomain brute-forcing mode
• vhost - virtual host brute-forcing mode (not the same as DNS!)

• gobuster help - outputs the top-level help.
• gobuster help <mode> - outputs the help specific to that mode.

Usage:    gobuster dns [flags]    Flags:    -d, --domain string      The target domain    -h, --help               help for dns    -r, --resolver string    Use custom DNS server (format server.com or server.com:port)    -c, --showcname          Show CNAME records (cannot be used with '-i' option)    -i, --showips            Show IP addresses        --timeout duration   DNS resolver timeout (default 1s)        --wildcard           Force continued operation when wildcard found    Global Flags:    -z, --noprogress        Don't display progress    -o, --output string     Output file to write results to (defaults to stdout)    -q, --quiet             Don't print the banner and other noise    -t, --threads int       Number of concurrent threads (default 10)        --delay duration    Time each thread waits between requests (e.g. 1500ms)    -v, --verbose           Verbose output (errors)    -w, --wordlist string   Path to the wordlist  

Usage:    gobuster dir [flags]    Flags:    -f, --addslash                      Append / to each request    -c, --cookies string                Cookies to use for the requests    -e, --expanded                      Expanded mode, print full URLs    -x, --extensions string             File extension(s) to search for    -r, --followredirect                Follow redirects    -H, --headers stringArray           Specify HTTP headers, -H 'Header1: val1' -H 'Header2: val2'    -h, --help                          help for dir    -l, --includelength                 Include the length of the body in the output    -k, --insecuressl                   Skip SSL certificate verification    -n, --nostatus                      Don't print status codes    -P, --password string               Password for Basic Auth    -p, --proxy string                  Proxy to use for requests [http(s)://host:port]    -s, --statuscodes string            Positive status codes (will be overwritten with statuscodesblacklist if set) (default "200,204,301,302,307,401,403")    -b, --statuscodesblacklist string   Negative status codes (will override statuscodes if set)        --timeout duration              HTTP Timeout (default 10s)    -u, --url string                    The target URL    -a, --useragent string              Set the User-Agent string (default "gobuster/3.0.1")    -U, --username string               Username for Basic Auth        --wildcard                      Force continued operation when wildcard found    Global Flags:    -z, --noprogress        Don't display progress    -o, --output string     Output file to write results to (defaults to stdout)    -q, --quiet             Don't print the banner and other noise    -t, --threads int       Number of concurrent threads (default 10)        --delay duration    Time each thread waits between requests (e.g. 1500ms)    -v, --verbose           Verbose output (errors)    -w, --wordlist string   Path to the wordlist  

Usage:    gobuster vhost [flags]    Flags:    -c, --cookies string        Cookies to use for the requests    -r, --followredirect        Follow redirects    -H, --headers stringArray   Specify HTTP headers, -H 'Header1: val1' -H 'Header2: val2'    -h, --help                  help for vhost    -k, --insecuressl           Skip SSL certificate verification    -P, --password string       Password for Basic Auth    -p, --proxy string          Proxy to use for requests [http(s)://host:port]        --timeout duration      HTTP Timeout (default 10s)    -u, --url string            The target URL    -a, --useragent string      Set the User-Agent string (default "gobuster/3.0.1")    -U, --username string       Username for Basic Auth    Global Flags:    -z, --noprogress        Don't display progress    -o, --output string     Output file to write results to (defaults to stdout)    -q, --quiet             Don't print the banner and other noise    -t, --threads int       Number of concurrent threads (default 10)        --delay duration    Time each thread waits between requests (e.g. 1500ms)    -v, --verbose           Verbose output (errors)    -w, --wordlist string   Path to the wordlist  

Usage:
  gobuster dns [flags]

Flags:
  -d, --domain string      The target domain
  -h, --help               help for dns
  -r, --resolver string    Use custom DNS server (format server.com or server.com:port)
  -c, --showcname          Show CNAME records (cannot be used with '-i' option)
  -i, --showips            Show IP addresses
      --timeout duration   DNS resolver timeout (default 1s)
      --wildcard           Force continued operation when wildcard found

Global Flags:
  -z, --noprogress        Don't display progress
  -o, --output string     Output file to write results to (defaults to stdout)
  -q, --quiet             Don't print the banner and other noise
  -t, --threads int       Number of concurrent threads (default 10)
      --delay duration    Time each thread waits between requests (e.g. 1500ms)
  -v, --verbose           Verbose output (errors)
  -w, --wordlist string   Path    to the wordlist

Usage:
  gobuster dir [flags]

Flags:
  -f, --addslash                      Append / to each request
  -c, --cookies string                Cookies to use for the requests
  -e, --expanded                      Expanded mode, print full URLs
  -x, --extensions string             File extension(s) to search for
  -r, --followredirect                Follow redirects
  -H, --headers stringArray           Specify HTTP headers, -H 'Header1: val1' -H 'Header2: val2'
  -h, --help                          help for dir
  -l, --includelength                 Include the length of the body in the output
  -k, --insecuressl                   Skip SSL certificate verification
  -n, --nostatus                      Don't print status codes
  -P, --password string               Password for Basic Auth
  -p, --proxy string                  Proxy to use for requests [http(s)://host:port]
  -s, --statuscodes string               Positive status codes (will be overwritten with statuscodesblacklist if set) (default "200,204,301,302,307,401,403")
  -b, --statuscodesblacklist string   Negative status codes (will override statuscodes if set)
      --timeout duration              HTTP Timeout (default 10s)
  -u, --url string                    The target URL
  -a, --useragent string              Set the User-Agent string (default "gobuster/3.0.1")
  -U, --username string               Username for Basic Auth
      --wildcard                      Force continued operation when wildcard found

Global Flags:
  -z, --noprogress        Don't display progress
  -o, --output string     Output file to write results to (defaults to stdout)
  -q, --quiet             Don't print the banner and other noise
  -t, --threads int       Number of concurrent threads (default 10)
      --delay duration    Time each thread waits between requests (e.g. 1500ms)
  -v, --verbose              Verbose output (errors)
  -w, --wordlist string   Path to the wordlist

Usage:
  gobuster vhost [flags]

Flags:
  -c, --cookies string        Cookies to use for the requests
  -r, --followredirect        Follow redirects
  -H, --headers stringArray   Specify HTTP headers, -H 'Header1: val1' -H 'Header2: val2'
  -h, --help                  help for vhost
  -k, --insecuressl           Skip SSL certificate verification
  -P, --password string       Password for Basic Auth
  -p, --proxy string          Proxy to use for requests [http(s)://host:port]
      --timeout duration      HTTP Timeout (default 10s)
  -u, --url string            The target URL
  -a, --useragent string      Set the User-Agent string (default "gobuster/3.0.1")
  -U, --username string       Username for Basic Auth

Global Flags:
  -z, --noprogress        Don't display progress
  -o, --output string     Output file to write results to (defaults to stdout)
  -q, --quiet             Don't print the ba   nner and other noise
  -t, --threads int       Number of concurrent threads (default 10)
      --delay duration    Time each thread waits between requests (e.g. 1500ms)
  -v, --verbose           Verbose output (errors)
  -w, --wordlist string   Path to the wordlist

• make - builds for the current Go configuration (ie. runs go build).
• make windows - builds 32 and 64 bit binaries for windows, and writes them to the build subfolder.
• make linux - builds 32 and 64 bit binaries for linux, and writes them to the build subfolder.
• make darwin - builds 32 and 64 bit binaries for darwin, and writes them to the build subfolder.
• make all - builds for all platforms and architectures, and writes the resulting binaries to the build subfolder.
• make clean - clears out the build subfolder.
• make test - runs the tests.

go get github.com/OJ/gobuster

go get && go build

go install

hashcat -a 3 --stdout ?l | gobuster dir -u https://mysite.com -w -

gobuster dir -u https://mysite.com/path/to/folder -c 'session=123456' -t 50 -w common-files.txt -x .php,.html

gobuster dir -u https://buffered.io -w ~/wordlists/shortlist.txt

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Mode         : dir
[+] Url/Domain   : https://buffered.io/
[+] Threads      : 10
[+] Wordlist     : /home/oj/wordlists/shortlist.txt
[+] Status codes : 200,204,301,302,307,401,403
[+] User Agent   : gobuster/3.0.1
[+] Timeout      : 10s
===============================================================
2019/06/21 11:49:43 Starting gobuster
===============================================================
/categories (Status: 301)
/contact (Status: 301)
/posts (Status: 301)
/index (Status: 200)
===============================================================
2019/06/21 11:49:44 Finished
=========================   ======================================

gobuster dir -u https://buffered.io -w ~/wordlists/shortlist.txt -n

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Mode         : dir
[+] Url/Domain   : https://buffered.io/
[+] Threads      : 10
[+] Wordlist     : /home/oj/wordlists/shortlist.txt
[+] Status codes : 200,204,301,302,307,401,403
[+] User Agent   : gobuster/3.0.1
[+] No status    : true
[+] Timeout      : 10s
===============================================================
2019/06/21 11:50:18 Starting gobuster
===============================================================
/categories
/contact
/index
/posts
===============================================================
2019/06/21 11:50:18 Finished
==================================================   =============

gobuster dir -u https://buffered.io -w ~/wordlists/shortlist.txt -v

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Mode         : dir
[+] Url/Domain   : https://buffered.io/
[+] Threads      : 10
[+] Wordlist     : /home/oj/wordlists/shortlist.txt
[+] Status codes : 200,204,301,302,307,401,403
[+] User Agent   : gobuster/3.0.1
[+] Verbose      : true
[+] Timeout      : 10s
===============================================================
2019/06/21 11:50:51 Starting gobuster
===============================================================
Missed: /alsodoesnotexist (Status: 404)
Found: /index (Status: 200)
Missed: /doesnotexist (Status: 404)
Found: /categories (Status: 301)
Found: /posts (Status: 301)
Found: /contact (   Status: 301)
===============================================================
2019/06/21 11:50:51 Finished
===============================================================

gobuster dir -u https://buffered.io -w ~/wordlists/shortlist.txt -l

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Mode         : dir
[+] Url/Domain   : https://buffered.io/
[+] Threads      : 10
[+] Wordlist     : /home/oj/wordlists/shortlist.txt
[+] Status codes : 200,204,301,302,307,401,403
[+] User Agent   : gobuster/3.0.1
[+] Show length  : true
[+] Timeout      : 10s
===============================================================
2019/06/21 11:51:16 Starting gobuster
===============================================================
/categories (Status: 301) [Size: 178]
/posts (Status: 301) [Size: 178]
/contact (Status: 301) [Size: 178]
/index (Status: 200) [Size: 51759]
=============================================   ==================
2019/06/21 11:51:17 Finished
===============================================================

gobuster dir -u https://buffered.io -w ~/wordlists/shortlist.txt -q -n -e
https://buffered.io/index
https://buffered.io/contact
https://buffered.io/posts
https://buffered.io/categories

gobuster dns -d mysite.com -t 50 -w common-names.txt

gobuster dns -d google.com -w ~/wordlists/subdomains.txt

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Mode         : dns
[+] Url/Domain   : google.com
[+] Threads      : 10
[+] Wordlist     : /home/oj/wordlists/subdomains.txt
===============================================================
2019/06/21 11:54:20 Starting gobuster
===============================================================
Found: chrome.google.com
Found: ns1.google.com
Found: admin.google.com
Found: www.google.com
Found: m.google.com
Found: support.google.com
Found: translate.google.com
Found: cse.google.com
Found: news.google.com
Found: music.google.com
Found: mail.google.com
Found: store.google.com
Found: mobile.google.com
Found:    search.google.com
Found: wap.google.com
Found: directory.google.com
Found: local.google.com
Found: blog.google.com
===============================================================
2019/06/21 11:54:20 Finished
===============================================================

gobuster dns -d google.com -w ~/wordlists/subdomains.txt -i

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Mode         : dns
[+] Url/Domain   : google.com
[+] Threads      : 10
[+] Wordlist     : /home/oj/wordlists/subdomains.txt
===============================================================
2019/06/21 11:54:54 Starting gobuster
===============================================================
Found: www.google.com [172.217.25.36, 2404:6800:4006:802::2004]
Found: admin.google.com [172.217.25.46, 2404:6800:4006:806::200e]
Found: store.google.com [172.217.167.78, 2404:6800:4006:802::200e]
Found: mobile.google.com [172.217.25.43, 2404:6800:4006:802::200b]
Found: ns1.google.com [216.239.32.10, 2001:4860:4802:32::a]
Found: m.google.com    [172.217.25.43, 2404:6800:4006:802::200b]
Found: cse.google.com [172.217.25.46, 2404:6800:4006:80a::200e]
Found: chrome.google.com [172.217.25.46, 2404:6800:4006:802::200e]
Found: search.google.com [172.217.25.46, 2404:6800:4006:802::200e]
Found: local.google.com [172.217.25.46, 2404:6800:4006:80a::200e]
Found: news.google.com [172.217.25.46, 2404:6800:4006:802::200e]
Found: blog.google.com [216.58.199.73, 2404:6800:4006:806::2009]
Found: support.google.com [172.217.25.46, 2404:6800:4006:802::200e]
Found: wap.google.com [172.217.25.46, 2404:6800:4006:802::200e]
Found: directory.google.com [172.217.25.46, 2404:6800:4006:802::200e]
Found: translate.google.com [172.217.25.46, 2404:6800:4006:802::200e]
Found: music.google.com [172.217.25.46, 2404:6800:4006:802::200e]
Found: mail.google.com [172.217.25.37, 2404:6800:4006:802::2005]
===============================================================
2019/06/21 11:54:55 Finished
====   ===========================================================

gobuster dns -d yp.to -w ~/wordlists/subdomains.txt -i

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Mode         : dns
[+] Url/Domain   : yp.to
[+] Threads      : 10
[+] Wordlist     : /home/oj/wordlists/subdomains.txt
===============================================================
2019/06/21 11:56:43 Starting gobuster
===============================================================
2019/06/21 11:56:53 [-] Unable to validate base domain: yp.to
Found: cr.yp.to [131.193.32.108, 131.193.32.109]
===============================================================
2019/06/21 11:56:53 Finished
===============================================================

gobuster dns -d 0.0.1.xip.io -w ~/wordlists/subdomains.txt

===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Mode         : dns
[+] Url/Domain   : 0.0.1.xip.io
[+] Threads      : 10
[+] Wordlist     : /home/oj/wordlists/subdomains.txt
===============================================================
2019/06/21 12:13:48 Starting gobuster
===============================================================
2019/06/21 12:13:48 [-] Wildcard DNS found. IP address(es): 1.0.0.0
2019/06/21 12:13:48 [!] To force processing of Wildcard DNS, specify the '--wildcard' switch.
===============================================================
2019/06/21 12:13:48 Finished
===============================================================

Facebook Now Pays Hackers for Reporting Security Bugs in 3rd-Party Apps

Chinese-speaking cybercrime gang Rocke changes tactics

Chinese-speaking cybercrime gang Rocke that carried out several large-scale cryptomining campaigns, has now using news tactics to evade detection.

Chinese-speaking cybercrime gang Rocke, that carried out several large-scale cryptomining campaigns in past, has now using news tactics to evade detection. The group has been observed using new tactics, techniques, and procedures (TTPs), it is also using updated malware to evade detection.

The cybercrime organization was first spotted in April 2018 by researchers at Cisco Talos, earlier 2019 researchers from Palo Alto Networks Unit42 found new malware samples used by the Rocke group for cryptojacking that uninstalls from Linux servers cloud security and monitoring products developed by Tencent Cloud and Alibaba Cloud.

In March, the group was using a dropper dubbed LSD that was controlled via Pastebin, but since this summer the threat actors have changed Command and Control (C2) infrastructure using a self-hosted solution.

The malicious code is used by the hackers to deliver a Moner (XMR) crypto miner that is not detected by almost any antivirus solution.

The Rocke group was also observed exploiting the CVE-2019-3396 flaw in Confluence servers to get remote code execution and deliver the miners.

“Rocke, a China-based cryptomining threat actor, has changed its Command and Control (C2) infrastructure away from Pastebin to a self-hosted solution during the summer of 2019.” reads the analysis published by the security firm Anomaly. “the actor moved away from hosting the scripts on dedicated servers and instead started to use Domain Name System (DNS) text records. These records are accessed via normal DNS queries or DNS-over-HTTPs (DoH) if the DNS query fails. In addition to the C2 change, functionality was also added to their LSD malware to exploit ActiveMQ servers vulnerable to CVE-2016-3088.”

The use of self-hosted and DNS records makes it hard to detect the group’s operations and takedowns. The new LSD sample was first spotted on September 17 as reported in the following graph.

The group also improved its LSD dropper by adding the malicious code to exploit CVE-2016-3088 in ActiveMQ servers.

In order to ensure that only its miner is running on the infected machine, the group attempt to kill any other processes with high CPU usage. The LSD malware analyzed the MD5 hash of the files to avoid killing its instance running on the system.

“Rocke keeps evolving its TTPs in attempts to remain undetected. By moving away from hosting scripts on Pastebin to self-hosted and DNS records, the threat actor is more protected against potential take-downs that could prevent ongoing malicious activity,” concludes Anomali Labs.

“It is expected that the group will continue to exploit more vulnerabilities to mine additional cryptocurrencies in the near future.”

Technical details, including Indicators of Compromise, are reported in the analysis published by Anomali.

Pierluigi Paganini

(SecurityAffairs – Rocke cybercrime gang, miner)

The post Chinese-speaking cybercrime gang Rocke changes tactics appeared first on Security Affairs.

Adobe out-of-band security updates address 82 flaws in 3 products

Adobe has released out-of-band security updates to address a total of 82 security vulnerabilities that affect three products of the company.

On Tuesday, Adobe released out-of-band security updates to address 82 flaws in Acrobat and Reader, Experience Manager, Experience Manager Forms, and Download Manager.

Out of 82 security flaws, 45 vulnerabilities affecting Adobe Acrobat and Reader have been rated critical. The exploitation of the flaws could lead to arbitrary code execution in the context of the current user.

The company also addressed 23 important-rated out-of-bounds read and cross-site scripting issues that could lead to information disclosure.

26 vulnerabilities in Adobe Acrobat and Reader reside due to use-after-free, 6 due to out-of-bounds write, 4 are type confusion bugs, 4 are untrusted pointer dereference, 3 are heap overflow bugs, one a buffer overrun and one a race condition flaw.

A majority of critical-rated vulnerabilities (i.e., 26) in Adobe Acrobat and Reader reside due to use-after-free, 6 due to out-of-bounds write, 4 are type confusion bugs, 4 due to untrusted pointer dereference, 3 are heap overflow bugs, one buffer overrun and one race condition issue.

Adobe fixed a privilege escalation flaw in Download Manager for Windows that is caused by insecure file permissions.

Adobe also addressed a dozen flaws in the Experience Manager marketing solution. An attacker could exploit the vulnerabilities to gain unauthorized access to an organization’s Experience Manager environment.

The company also fixed a XSS flaw in the Experience Manager Forms that lead to the disclosure of sensitive information.

The good news is that Adobe is not aware of any attacks exploiting the vulnerabilities in the wild.

Pierluigi Paganini

(SecurityAffairs – hacking, security updates)

The post Adobe out-of-band security updates address 82 flaws in 3 products appeared first on Security Affairs.

Click2Mail suffered a data breach that potentially impacts 200,000 registrants

Click2Mail.com, a US Postal Service affiliate partner, has suffered a data breach that exposed the personal information of its users.

The US Postal Service affiliate partner Click2Mail has suffered a data breach that exposed the personal information of its users.

The company allows its users to professionally print letters, flyers or postcards and deliver them in a business day at low prices.

It also allows users to manage mailing lists conveniently through the web browser. The company is sending out data breach notices to its impacted users.

The incident was first reported first by DataBreaches.net which was contacted by a former customer of Click2Mail who reported their suspicion that Click2Mail may have been hacked. The security breach was discovered on October 4, 2019.

Exposed users’ data include name, organization name, account mailing address, email address, and phone number. The company pointed out that it doesn’t store users’ financial data.

“We have learned that your personal information, including name, organization name, account mailing address, email address, and phone number may have been compromised.” reads the data breach notice sent to the users. “On October 4th, 2019 it was discovered that registered Click2Mail users’ names and email addresses were being used by unknown parties to send multiple spam emails. Technical analysis of our systems detected an intrusion point that was closed that same day.”

The company hired a cyber-security firm to help its staff in investigating the incident.

Lee Garvey, President and CEO of Click2Mail confirmed that the company is going to notify the incident to its 200,000 Click2Mail.com registrants.

“In a follow-up communication, Lee Garvey, President and CEO of Click2Mail, informs this site that slightly more than 200,000 Click2Mail.com registrants will be receiving notifications, which will be sent out in segments, not all at once.” states a post published on databreaches.net. “Garvey also explained that prior to receiving this site’s email inquiry, they had received an email from a helpful customer who had used a tagged email address and was getting spam.  From the description, it sounds like the same former customer who contacted this site to alert us to their suspicions that Click2Mail had been hacked.”

Pierluigi Paganini

(SecurityAffairs – hacking, data breach)

The post Click2Mail suffered a data breach that potentially impacts 200,000 registrants appeared first on Security Affairs.

RITA - Real Intelligence Threat Analytics

• Beaconing Detection: Search for signs of beaconing behavior in and out of your network
• DNS Tunneling Detection Search for signs of DNS based covert channels
• Blacklist Checking: Query blacklists to search for suspicious domains and hosts

• Download the latest install.sh file from the release page
• Make the installer executable: chmod +x ./install.sh
• Run the installer: sudo ./install.sh

• Operating System - The preferred platform is 64-bit Ubuntu 16.04 LTS. The system should be patched and up to date using apt-get.
• Processor (when installed alongside Bro/Zeek) - Two cores plus an additional core for every 100 Mb of traffic being captured. (three cores minimum). This should be dedicated hardware, as resource congestion with other VMs can cause packets to be dropped or missed.
• Memory - 16GB minimum. 64GB if monitoring 100Mb or more of network traffic. 128GB if monitoring 1Gb or more of network traffic.
• Storage - 300GB minimum. 1TB or more is recommended to reduce log maintenance.
• Network - In order to capture traffic with Bro/Zeek, you will need at least 2 network interface cards (NICs). One will be for management of the system and the other will be the dedicated capture port. Intel NICs perform well and are recommended.

• The Filtering: InternalSubnets section must be configured or you will not see any results in certain modules (e.g. beacons, long connections). If your network uses the standard RFC1918 internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) you just need uncomment the default InternalSubnets section already in the config file. Otherwise, adjust this section to match your environment. RITA's main purpose is to find the signs of a compromised internal system talking to an external system and will automatically exclude internal to internal connections and external to external connections from parts of the analysis.

• Filtering: AlwaysInclude - Ranges listed here are exempt from the filtering applied by the InternalSubnets setting. The main use for this is to include internal DNS servers so that you can see the source of any DNS queries made.

• Option 1: Generate PCAPs outside of Bro/Zeek
  
  • Generate PCAP files with a packet sniffer (tcpdump, wireshark, etc.)
  • (Optional) Merge multiple PCAP files into one PCAP file
    • mergecap -w outFile.pcap inFile1.pcap inFile2.pcap
  • Generate Bro/Zeek logs from the PCAP files
    • bro -r pcap_to_log.pcap local "Log::default_rotation_interval = 1 day"
• Option 2: Install Bro/Zeek and let it monitor an interface directly [instructions]
  
  • You may wish to compile Bro/Zeek from source for performance reasons. This script can help automate the process.
  • The automated installer for RITA installs pre-compiled Bro/Zeek binaries by default
    • Provide the --disable-bro flag when running the installer if you intend to compile Bro/Zeek from source

• Option 1: Create a One-Off Dataset
  • rita import path/to/your/bro_logs dataset_name creates a dataset from a collection of Bro/Zeek logs in a directory
  • Every log file directly in the supplied directory will be imported into a dataset with the given name
  • If you import more data into the same dataset, RITA will automatically convert it into a rolling dataset.
• Option 2: Create a Rolling Dataset
  • Rolling datasets allow you to progressively analyze log data over a period of time as it comes in.
  • You can call rita like this: rita import --rolling /path/to/your/bro_logs and make this call repeatedly as new logs are generated (e.g. every hour)
  • RITA cycles data into and out of rolling databases in "chunks". You can think of each chunk as one hour, and the default being 24 chunks in a dataset. This gives the ability to always have the most recent 24 hours' worth of data available. But chunks are generic enough to accommodate non-default Bro logging configurations or data retention times as well.

rita import --rolling --numchunks 7 /opt/bro/logs/current week-dataset

rita import --rolling --numchunks 48 /opt/bro/logs/current 48-hour-dataset

• Use the show-X commands
  • show-databases: Print the datasets currently stored
  • show-beacons: Print hosts which show signs of C2 software
  • show-bl-hostnames: Print blacklisted hostnames which received connections
  • show-bl-source-ips: Print blacklisted IPs which initiated connections
  • show-bl-dest-ips: Print blacklisted IPs which received connections
  • show-exploded-dns: Print dns analysis. Exposes covert dns channels
  • show-long-connections: Print long connections and relevant information
  • show-strobes: Print connections which occurred with excessive frequency
  • show-useragents: Print user agent information
• By default RITA displays data in CSV format
  • -H displays the data in a human readable format
  • Piping the human readable results through less -S prevents word wrapping
    • Ex: rita show-beacons dataset_name -H | less -S
• Create a html report with html-report