RSS Security

🔒
❌ About FreshRSS
There are new available articles, click to refresh the page.
Today — October 17th 2019Your RSS feeds

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

By: Unknown

Set of tools for security testing of Internet of Things devices using protocols like: CoAP, DTLS, HTCPCP, mDNS, MQTT, SSDP.

Installation:
Simply clone code from git: https://github.com/Samsung/cotopaxi

Requirements:
Currently Cotopaxi works only with Python 2.7.x, but future versions will work also with Python 3.
If you have previous installation of scapy without scapy-ssl_tls, please remove it or use venv.
Installation of main libraries:
  1. scapy-ssl_tls (this will install also scapy in 2.4.2)
    pip install git+https://github.com/tintinweb/scapy-ssl_tls@ec5714d560c63ea2e0cce713cec54edc2bfa0833
Common problems:
  • 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.
All other required packages can be installed using requirements.txt file:
    pip install -r cotopaxi/requirements.txt
Manual installation of other required packages:
    pip install dnslib IPy hexdump pyyaml psutil enum34 configparser

Disclaimer
Cotopaxi toolkit is intended to be used only for authorized security testing!
Some tools (especially vulnerability tester and protocol fuzzer) can cause some devices or servers to stop acting in the intended way -- for example leading to crash or hang of tested entities or flooding with network traffic another entities.
Make sure you have permission from the owners of tested devices or servers before running these tools!
Make sure you check with your local laws before running these tools!

Tools in this package:
  • 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
Protocols supported by different tools:
Tool CoAP DTLS HTCPCP mDNS MQTT SSDP
service_ping yes yes yes yes yes yes
server_fingerprinter yes yes
resource_listing yes yes yes
protocol_fuzzer yes yes yes yes yes yes
client_proto_fuzzer yes yes yes yes yes yes
vulnerability_tester yes yes yes yes yes yes
client_vuln_tester yes yes yes yes yes yes
amplifier_detector yes yes yes yes

cotopaxi.service_ping
Tool for checking availability of network service at given IP and port ranges
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)

cotopaxi.server_fingerprinter
Tool for software fingerprinting of network servers at given IP and port ranges
Currently supported servers:
  • 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)

cotopaxi.resource_listing
Tool for checking availability of resource named url on server at given IP and port ranges. Sample URL lists are available in the urls directory
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)

cotopaxi.protocol_fuzzer
Black-box fuzzer for testing protocol servers
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

cotopaxi.client_proto_fuzzer
Black-box fuzzer for testing protocol clients
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)

cotopaxi.vulnerability_tester
Tool for checking vulnerability of network service at given IP and port ranges
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)

cotopaxi.client_vuln_tester
Tool for checking vulnerability of network clients connecting to server provided by this tool
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

cotopaxi.amplifier_detector
Tool for detection of network devices amplifying reflected traffic by observing size of incoming and outgoing size of packets
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)

Known issues / limitations
There are some known issues or limitations caused by using scapy as network library:
  • 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).
See more at: https://scapy.readthedocs.io/en/latest/troubleshooting.html#

Unit tests
To run all unit tests use (from directory upper than cotopaxi dir):
    sudo python -m unittest discover
Most of tests are performed against remote tests servers and require preparing test environment, providing settings in tests/test_config.ini and tests/test_servers.yaml.


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

The United States Department of Justice said today that they had arrested hundreds of criminals in a global crackdown after taking down the largest known child porn site on the dark web and tracing payments made in bitcoins. With an international coalition of law enforcement agencies, federal officials have arrested the administrator of the child sexual abuse site, 23-year-old Jong Woo Son of

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.

Le Groupe M6 a été la cible samedi matin d’une attaque informatique malveillante. L’intervention rapide et efficace de nos experts en cybersécurité a permis de continuer à assurer la bonne diffusion des programmes sur l’ensemble de nos antennes TV et radio.

— Groupe M6 (@M6Groupe) October 13, 2019

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

Humankind had come a long way from the time when the Internet became mainstream. What started as a research project ARPANET (Advanced Research Projects Agency Network) funded by DARPA has grown exponentially and has single-handedly revolutionized human behavior. When WWW (world wide web) came into existence, it was meant to share information over the Internet, from there part through natural

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.

Yesterday — October 16th 2019Your RSS feeds

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

By: Unknown
IDA PRO Auto-Renaming Plugin With Tagging Support

Features

1. Auto-renaming dummy-named functions, which have one API call or jump to the imported API

Before


After



2. Assigning TAGS to functions accordingly to called API-indicators inside
  • Sets tags as repeatable function comments and displays TAG tree in the separate view
Some screenshots of TAGS view:





How TAGs look in unexplored code:


You can easily rename function using its context menu or just pressing n hotkey:


Installation
Just copy auto_re.py to the IDA\plugins directory and it will be available through Edit -> Plugins -> Auto RE menu


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.


PCAP Analysis Basics with Wireshark [Updated 2019] was first posted on October 10, 2019 at 2:09 pm.
©2017 "InfoSec Resources". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at darren.dalasta@infosecinstitute.com

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.

Severel machines with #BSoD thanks to IDSvia64.sys.
Anyone else? Using @symantec Endpoint Protection. #SEP

— HAL_9000 ❌ (@_HAL_9OOO_) October 15, 2019

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

Symantec Endpoint Protection

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.


Red Team operations: Best practices was first posted on October 16, 2019 at 8:02 am.
©2017 "InfoSec Resources". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at darren.dalasta@infosecinstitute.com

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.


The difference between Cross-Site and Server-Side Request Forgery was first posted on October 16, 2019 at 8:01 am.
©2017 "InfoSec Resources". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at darren.dalasta@infosecinstitute.com

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.


Managing Updates and Patches in Windows 10 was first posted on October 16, 2019 at 8:00 am.
©2017 "InfoSec Resources". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at darren.dalasta@infosecinstitute.com

Phorpiex Botnet Sending Out Millions of Sextortion Emails Using Hacked Computers

A decade-old botnet malware that currently controls over 450,000 computers worldwide has recently shifted its operations from infecting machines with ransomware or crypto miners to abusing them for sending out sextortion emails to millions of innocent people. Extortion by email is growing significantly, with a large number of users recently complaining about receiving sextortion emails that

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.
Value block example for value 0x0012D687

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
Dump 1 compared to Dump 2, yellow bytes differ
Dump 2 compared Dump 3, yellow bytes differ

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:

Dump 1 with mfdread parser

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.

Credit stored on the MIFARE Value Block

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

By: Unknown

Gobuster is a tool used to brute-force:
  • URIs (directories and files) in web sites.
  • DNS subdomains (with wildcard support).
  • Virtual Host names on target web servers.

Oh dear God.. WHY!?
Because I wanted:
  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.

But it's shit! And your implementation sucks!
Yes, you're probably correct. Feel free to:
  • Not use it.
  • Show me how to do it better.

Love this tool? Back it!
If you're backing us already, you rock. If you're not, that's cool too! Want to back us? Become a backer!

All funds that are donated to this project will be donated to charity. A full log of charity donations will be available in this repository as they are processed.

Changes in 3.0
  • 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

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

Built-in Help
Help is built-in!
  • gobuster help - outputs the top-level help.
  • gobuster help <mode> - outputs the help specific to that mode.

dns Mode Help
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  

dir Mode Options
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  

vhost Mode Options
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  

Easy Installation

Binary Releases
We are now shipping binaries for each of the releases so that you don't even have to build them yourself! How wonderful is that!
If you're stupid enough to trust binaries that I've put together, you can download them from the releases page.

Using go get
If you have a Go environment ready to go, it's as easy as:
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

Building From Source
Since this tool is written in Go you need to install the Go language/compiler/etc. Full details of installation and set up can be found on the Go language website. Once installed you have two options.

Compiling
gobuster now has external dependencies, and so they need to be pulled in first:
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
This will create a gobuster binary for you. If you want to install it in the $GOPATH/bin folder you can run:
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
If you have all the dependencies already, you can make use of the build scripts:
  • 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.

Wordlists via STDIN
Wordlists can be piped into gobuster via stdin by providing a - to the -w option:
go get github.com/OJ/gobuster
Note: If the -w option is specified at the same time as piping from STDIN, an error will be shown and the program will terminate.

Examples

dir Mode
Command line might look like this:
go get && go build
Default options looks like this:
go install
Default options with status codes disabled looks like this:
hashcat -a 3 --stdout ?l | gobuster dir -u https://mysite.com -w -
Verbose output looks like this:
gobuster dir -u https://mysite.com/path/to/folder -c 'session=123456' -t 50 -w common-files.txt -x .php,.html
Example showing content length:
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
========================= ======================================
Quiet output, with status disabled and expanded mode looks like this ("grep mode"):
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
================================================== =============

dns Mode
Command line might look like this:
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
===============================================================
Normal sample run goes like this:
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
===============================================================
Show IP sample run goes like this:
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
Base domain validation warning when the base domain fails to resolve. This is a warning rather than a failure in case the user fat-fingers while typing the domain.
gobuster dns -d mysite.com -t 50 -w common-names.txt
Wildcard DNS is also detected properly:
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
===============================================================
If the user wants to force processing of a domain that has wildcard entries, use --wildcard:
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
==== ===========================================================

vhost Mode
Command line might look like this:
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
===============================================================
Normal sample run goes like this:
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

Following a series of security mishaps and data abuse through its social media platform, Facebook today expanding its bug bounty program in a very unique way to beef up the security of third-party apps and websites that integrate with its platform. Last year, Facebook launched "Data Abuse Bounty" program to reward anyone who reports valid events of 3rd-party apps collecting Facebook users'

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.

Before yesterdayYour RSS feeds

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.”

Click2Mail logo

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

By: Unknown

RITA is an open source framework for network traffic analysis.
The framework ingests Bro/Zeek Logs in TSV format, and currently supports the following major features:
  • 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

Automatic Installation
The automatic installer is officially supported on Ubuntu 16.04 LTS, Security Onion*, and CentOS 7
  • Download the latest install.sh file from the release page
  • Make the installer executable: chmod +x ./install.sh
  • Run the installer: sudo ./install.sh
* Please see the Security Onion RITA wiki page for further information pertaining to using RITA on Security Onion.

Manual Installation
To install each component of RITA by hand, check out the instructions in the docs.

Upgrading RITA
See this guide for upgrade instructions.

Getting Started

System Requirements
  • 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.

Configuration File
RITA's config file is located at /etc/rita/config.yaml though you can specify a custom path on individual commands with the -c command line flag.
❗️ IMPORTANT ❗️
  • 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.
You may also wish to change the defaults for the following option:
  • 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.
Note that any value listed in the Filtering section should be in CIDR format. So a single IP of 192.168.1.1 would be written as 192.168.1.1/32.

Obtaining Data (Generating Bro/Zeek Logs):
  • 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

Importing and Analyzing Data With RITA
After installing RITA, setting up the InternalSubnets section of the config file, and collecting some Bro/Zeek logs, you are ready to begin hunting.
Filtering and whitelisting happens at import time. These optional settings can be found alongside InternalSubnets in the configuration file.
RITA will process Bro/Zeek TSV logs in both plaintext and gzip compressed formats. Note, if you are using Security Onion or Bro's JSON log output you will need to switch back to traditional TSV output.
  • 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.

Rolling Datsets
Please see the above section for the simplest use case of rolling datasets. This section covers the various options you can customize and more complicated use cases.
Each rolling dataset has a total number of chunks it can hold before it rotates data out. For instance, if the dataset currently contains 24 chunks of data and is set to hold a max of 24 chunks then the next chunk to be imported will automatically remove the first chunk before brining the new data in. This will result in a database that still contains 24 chunks. If each chunk contains an hour of data your dataset will have 24 hours of data in it. You can specify the number of chunks manually with --numchunks when creating a rolling database but if this is omitted RITA will use the Rolling: DefaultChunks value from the config file.
Likewise, when importing a new chunk you can specify a chunk number that you wish to replace in a dataset with --chunk. If you leave this off RITA will auto-increment the chunk for you. The chunk must be 0 (inclusive) through the total number of chunks (exclusive). This must be between 0 (inclusive) and the total number of chunks (exclusive). You will get an error if you try to use a chunk number greater or equal to the total number of chunks.
All files and folders that you give RITA to import will be imported into a single chunk. This could be 1 hour, 2 hours, 10 hours, 24 hours, or more. RITA doesn't care how much data is in each chunk so even though it's normal for each chunk to represent the same amount of time, each chunk could have a different number of hours of logs. This means that you can run RITA on a regular interval without worrying if systems were offline for a little while or the data was delayed. You might get a little more or less data than you intended but as time passes and new data is added it will slowly correct itself.
Example: If you wanted to have a dataset with a week's worth of data you could run the following rita command once per day.
rita import --rolling --numchunks 7 /opt/bro/logs/current week-dataset
This would import a day's worth of data into each chunk and you'd get a week's in total. After the first 7 days were imported, the dataset would rotate out old data to keep the most recent 7 days' worth of data. Note that you'd have to make sure new logs were being added to in /opt/bro/logs/current in this example.
Example: If you wanted to have a dataset with 48 hours of data you could run the following rita command every hour.
rita import --rolling --numchunks 48 /opt/bro/logs/current 48-hour-dataset

Examining Data With RITA
  • 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


❌