IoC stands for Indicator of compromise.
Indicator of compromise (IoC) in computer forensics is an artifact observed on a network or in an operating system that, with high confidence, indicates a computer intrusion.
Links:
TTP stands for Tactics, Techniques and Procedures.
Tactics, Techniques, and Procedures (TTPs) is an essential concept in terrorism and cybersecurity studies. The role of TTPs in terrorism analysis is to identify individual patterns of behavior of a particular terrorist activity, or a particular terrorist organization, and to examine and categorize more general tactics and weapons used by a particular terrorist activity, or a particular terrorist organization.
Links:
Encrypting DNS is great! Unless it's baddies doing the encrypting.
It's an easy-to-use DDoS Howitzer AND a NoSQL database!
Memcached is an in-memory key-value store for small chunks of arbitrary data (i.e., strings, binary objects) from results of database calls, API calls, or web page rendering. Its simple design has made it wildly popular, as it promotes quick deployment and ease of development.
Project Sonar found 68,337 exposed memcached hosts, and we did a double-take when we saw that South Africa is in third place, since we don’t often find it in any other top 10 lists of exposure. Most (97%) of these SA nodes are in two autonomous systems: Icidc Network (87%) and Internet Keeper Global (10%), and a majority of hosts in each autonomous system appear to have similar exposure counts in both nginx and SSH.
As noted in our section on Redis, Amazon has a cloud “cache” service offering that can also be configured to use memcached directly or emulate the exquisitely diminutive memcached protocol, and Alibaba has a managed memcached service offering, so it is no surprise finding some in those environments, but it is somewhat disconcerting that these instances are exposed to the internet. What’s more surprising is that OVH goes out of its way to help you secure memcached and, yet, ~1,500 folks apparently did not get that rather crucial memo.
Why all the fuss about memcached? Well, way back in 2018, an “Insufficient Control of Network Message Volume” vulnerability in the UDP portion of memcached was used to launch the largest distributed denial-of-service amplification attack ever, and disrupted many major internet services. Cloudflare summed up the flaw quite well in its blog at that time:
"There are absolutely zero checks, and the data WILL be delivered to the client, with blazing speed! Furthermore, the request can be tiny and the response huge (up to 1MB)."
While we do not have a memcached honeypot, we can see connection attempts on UDP 11211 and peek at the packet captures to see if memcached commands (most often, the stats one we use, though we occasionally see what look like misconfigured clients that are connecting to what they think are their memcached servers). The daily memcached command connections we see are mostly from Shadowserver, which is (correctly) self-described as a “nonprofit security organization working altruistically behind the scenes to make the internet more secure for everyone,” despite their scary name. They also scan the internet every day to try to get a handle on exposure and help organizations (for free) get a picture of their attack surface. We heart Shadowserver.
During the first third of 2020, we saw spikes of near 80,000 data-less UDP connections on 11211 across a handful of days, but none of this appears truly malicious in nature.
IT and IT security teams should never expose memcached to the internet, and should ensure via playbooks and automation that development, test, and production memcached environments are rigidly controlled.
Cloud providers should continue to offer secure service alternatives to self-hosted memcached, ensure their provider-maintained machine images are kept patched with a default configuration of memcached only available on non-internet-exposed interfaces, and—frankly—not allow memcached to be exposed to the internet on host in their sphere of network control.
Government cybersecurity agencies should provide regular reminders about the dangers of memcached, offer guidance on how to run memcached safely, monitor for malicious use of memcached, and strongly encourage ISPs and cloud providers to block connections to memcached’s default port.
Gleaming the Kube(rnetes)
The etcd key-value service is part of the Kubernetes ecosystem and is designed to hold system/service configuration and state information. The Kubernetes API Server uses etcd's watch API to monitor the cluster and roll out critical configuration changes or simply restore any divergences of the state of the cluster back to what was declared by the deployer. It exposes a JSON API over the HTTP protocol.
We’re including etcd for completeness (since we’ve mentioned in the previous blogs on Redis and memcached), but the sample size is way too small to dig into, since we have no data on which ones are honeypots and which ones are real.
Just like the other two key-value databases, etcd should never be exposed to the internet. Unlike the previous two services, etcd tends to be purpose-driven for Kubernetes orchestration environments, which is another great reason not to expose it to the internet directly.
Links:
Everyone agrees that Incident Management is different than Vulnerability Management. But yet still people mix them up when things happen.
Recently, SolarWinds supply chain attack has becomes the hottest topic in the month of December 2020 for Cybersecurity world. With the SUNBURST or SuperNova backdoors found, it is obviously becomes an incident (rather than a vulnerability) if your company is using the affected products. With the investigation is still ongoing, more affected products might be included in the list.
But, why people try to manage the SolarWinds case with vulnerability management? Is it because everyone is more familiar with vulnerability remediation process.
Yes, both incident management and vulnerability management has the remediation process. However it is performed by different teams. The remediation process for an incident is performed by Cybersecurity team, while the remediation process for a vulnerability is performed by IT team.
I guess people just thought that the all remediation process are the same.
Why people mix them up so easy?
I think it is due to sophisticated Cybersecurity team structure. And there is monthly remediation reminder that continuously reminding us on the remediation process. People just like to engage with what they are familiar with.
If your company is using a vulnerability management process to handle the SolarWinds attack or incident, then you should start think about simplifying your Cybersecurity teams.
Today, I just found that Microsoft has stopped their ESAE strategic architecture. Microsoft has recommended new strategy to complements any existing ESAE implementation.
The Enhanced Security Admin Environment (ESAE) architecture (often referred to as red forest, admin forest, or hardened forest) is an approach to provide a secure environment for Windows Server Active Directory (AD) administrators.
In early 2018, where I first learned about ESAE. After a deep dive evaluation, my conclusion is, it is too costly to implement such a solution, in term of operating cost, for most of the company (even it is a secure strategy). This is simply because the strategies have never consider the essential security concept. #EssentialSecurity
And after 3 years, Microsoft has admitted that the ESAE architectural pattern is only valid or applicable in a limited set of scenarios. Any organization who implement ESAE architecture, must accept the increased technical complexity and operational costs of the solution.
The ESAE retirement post can be found at https://docs.microsoft.com/en-us/security/compass/esae-retirement
There is a minor bug found at the Kenna's user interface that I encounter today.
To simulate the bug, from the Dashboard, look for any Kenna meter that has zero asset count (or you can create one), click on it to explore the asset/vuln list. And you will found that most of the filters are missing at the Explore page, such as:
😞😞
Just finished watching the Youtube video on Mark's presentation. He has introduced 2 of the tools that he created for threat hunting.
Links:
The cve-2020-1472 vulnerability has been disclosed since Aug. This is an elevation of privilege vulnerability that exists when a vulnerable Netlogon secure channel connection to a domain controller, using the Netlogon Remote Protocol.
This vulnerability is more to be known as Zerologon, and received a CVSS score of 10.0. Here're the summary of the vulnerability:
Al least last point seems like a good news where a vulnerable client or DC exposed to the internet is not exploitable by itself. (whew)
There are 2 things I would like to emphasis in this post.
First, the patch released in August isn't a full fix solution. The patch only helps to protect the vulnerable servers (domain controllers) from exploit/malware attack. This is like deploying an antivirus solution that block the WannaCry malware without patching the root problem.
The root of the problem is at the RPC with Netlogon protocol (MS-NRPC). And Microsoft will release second patch slated for Q1 in 2021 to address the bug.
The NetLogon component is an important functional component to perform authentication on the intra-domain network. It is important to be used for replicating the database backup, and maintaining domain members and domains relationship with domain DC (or cross-domain DC). The worst case for this attack is, the DC can be takenover by unauthenticated attacker.
Second, this vulnerability is targeting mainly on domain controllers (DC), including Samba server. However, the default installation running Samba (as a file server) are not directly impacted.
To Samba, this vulnerability is more of a mis-configuration than bug. Samba has been insisting on a secure netlogon channel since version 4.8 (Mar 2018). This is sufficient fix against the zerologon attack. [Unless they have the smb.conf lines 'server schannel = no' or 'server schannel = auto', those Samba server is not vulnerable]
Samba versions 4.7 and below are impacted by the vulnerability unless they have ‘server schannel = yes’ in the smb.conf. “The ‘server schannel = yes’ smb.conf line is equivalent to ‘FullSecureChannelProtection=1’ registry key in Microsoft OS, the introduction of which we understand forms the core of Microsoft’s fix. ”
Link:
The development of encrypted DNS, specifically DNS-over-HTTPS (DoH), has attracted a relatively large amount of interest to a previously quiet corner of the Internet protocol world.
Here're a list of DoH client of choices:
Links:
Earlier, I created a python script that allow me to check the number of vulnerable host based on CVE.
Today I just released second version of the script that show both the vulnerable host and vulnerabilities from Kenna, based on CVE.
If you specify the verbose output option, it will show both active and
inactive count for Closed, Open, Risk_Accepted, and False_Positive
category.
 |
| kenna-cve-win.exe -h |
I also released a Win32 version that allow me to run on my Windows platform (uploaded to GitHub).
Try this and see:
c:\> kenna-cve-win.exe -v -c 2020-1337
Two simple tutorials to convert between JSON and CSV data.
Links:
Just completed my SEC573 training (since Aug 2020), and passed the GIAC Python Coder (GPYC) certification.
Syllabus:
Link: Automating Information Security with Python | SANS SEC573
Today I created a small python script that allow me to check the number of vulnerable host in Kenna based on a CVE ID.
It helps me to check on how many hosts contain a particular CVE vulnerability, whether it is Closed, or Open, or Risk_Accepted, or False_Positive.
But I'm thinking to improve the script later by including the vulnerability count for both active/inactive hosts.
What's the quick distinction among Estimation, Prediction and Forecasting.
First, Estimation Vs Prediction.
Estimation is after occurrence of the event i.e. posterior probability; while Prediction is a kind of estimation before the occurrence of the event i.e. apriori probability.
Estimation implies finding the optimal parameter using historical data whereas prediction uses the data to compute the random value of the unseen data.
Second, what is Forecasting.
Forecasting is a subset of prediction wherein both use the historical data and estimating about the future events. And the difference between forecasting and prediction is the explicit addition of temporal dimension in forecasting.
Forecasting is a time-based prediction i.e. it is more appropriate while dealing with time series data. Prediction, on the other hand, need not be time based only, it can be based on multiple casual factors that influence the target variable.
Security without intelligence is just information. Information without innovation is just data.
What is Information Security?
| Rank | CWE | NVD Count | Avg CVSS | Overall Score |
|---|---|---|---|---|
| [1] | CWE-79 | 3788 | 5.80 | 46.82 |
| [2] | CWE-787 | 2225 | 8.31 | 46.17 |
| [3] | CWE-20 | 1910 | 7.35 | 33.47 |
| [4] | CWE-125 | 1578 | 7.13 | 26.5 |
| [5] | CWE-119 | 1189 | 8.08 | 23.73 |
| [6] | CWE-89 | 901 | 8.98 | 20.69 |
| [7] | CWE-200 | 1467 | 6.01 | 19.16 |
| [8] | CWE-416 | 918 | 8.26 | 18.87 |
| [9] | CWE-352 | 866 | 8.08 | 17.29 |
| [10] | CWE-78 | 767 | 8.52 | 16.44 |
| [11] | CWE-190 | 846 | 7.70 | 15.81 |
| [12] | CWE-22 | 792 | 7.27 | 13.67 |
| [13] | CWE-476 | 529 | 6.83 | 8.35 |
| [14] | CWE-287 | 412 | 8.05 | 8.17 |
| [15] | CWE-434 | 346 | 8.50 | 7.38 |
| [16] | CWE-732 | 426 | 6.99 | 6.95 |
| [17] | CWE-94 | 295 | 8.74 | 6.53 |
| [18] | CWE-522 | 283 | 7.92 | 5.49 |
| [19] | CWE-611 | 277 | 7.88 | 5.33 |
| [20] | CWE-798 | 234 | 8.76 | 5.19 |
| [21] | CWE-502 | 217 | 8.93 | 4.93 |
| [22] | CWE-269 | 278 | 7.36 | 4.87 |
| [23] | CWE-400 | 249 | 7.09 | 4.14 |
| [24] | CWE-306 | 193 | 8.10 | 3.85 |
| [25] | CWE-862 | 236 | 6.90 | 3.77 |
Links:
In February, I created a script to show Kenna connector status.
Lately, I found that I need to check on the history for those offline connectors as well. Thus I improve the script by allowing me to check/show all connectors' history.
And the new script will allow to customize the last N history.
 |
| kenna-connectors.py -h |
I just posted some notes about KennaSecurity search at Github.
Some of them are for funs, like unmappable vulnerability; and some of them are useful for proactive vulnerability management (Pre-NVD-Chatter).
Anyway, the Kenna search syntax is powerful and flexible (based on Apache Lucene if not mistaken) while all the indexing and search optimizations are based on Elasticsearch.
Systemd is a system and service manager for modern Linux, by replacing SysVinit. It:
In traditional SysVinit, we use syslog to stores logs. Then we read and analyze those log files with 'find', 'grep', 'less' commands. However, systemd which collects logs from more sources than syslogs, and keeps the journal logs in binary format. And we need 'journalctl' to perform analysis on those log files.
journald is the daemon from systemd that collects the logs from various log sources like syslog.
journalctl is the command line tool that lets you interact with the journal logs.
With journalctl, you can read logs, monitor the logs in real time, filter the logs based on time, service, severity and other parameters.
The default location of journald logs is /var/log/journal directory. Next, in the /etc/systemd/journald.conf file make sure that the value Storage is set to either auto or persistent.
Keys used in 'journalctl'
Arrow - move by one line
Space - move to next page
b - move back one page
g/G - first/last line
100g - the 100th line
/term - search string
n/N - next/previous search term
q - quit
Command line options:
$ journalctl -r [reverse chronological order]
$ journalctl -n N [display last N lines]
$ journalctl -f [same like tail -f]
$ journalctl --utc [display the time at UTC]
$ journalctl -k [show only kernel messages]
$ journalctl -u ssh [show 'ssh' unit messages only]
To filter logs based on time interval:
$ journalctl --since=yesterday --until=now
$ journalctl --since "2020-01-01"
To filter logs based on uid/gid/pid:
$ journalctl _PID=1234
Other useful options:
$ journalctl --disk-usage [ disk space usage ]
$ journalctl -xe [view last few logs]
$ journalctl -p 3 -xb
-p 3 : filter logs based on priority 3 (which i error)
-x : additional info on the log
b : since the last boot (current session)
$ journalctl -p 4..6 -b0 [ warn .. info ]
[ 0/emerg, 1/alert, 2/crit, 3/err, 4/warn, 5/notice, 6/info, 7/debug ]
Link: How to Use journalctl Command to Analyze Logs in Linux (linuxhandbook.com)
After working on Kenna for some times, I just notice that there are too many Kenna meters (asset-groups) been created.Plus, I need a way that help me to backup all my Kenna meters' parameters.
Thus, I just start working on a python script that helps me to list all the Kenna meters including the asset count, vulnerability count, CVE, Fixes and meter meters.
I create the first version of the script in February, and I just notice I need to improve the script by allowing me to backup all the parameters.
 |
| kenna-meters.py -h |
Today, here come my first drone flight, DJI Mavic Mini quadcopter.
It is such a wonderful experience ;)
Common Vulnerability Scoring System (CVSS) version 3.0 was released in June 2015 and was superseded in June 2019 by CVSS version 3.1.
The CVSS calculator shows the components of the CVSS score for example and allows you to refine the CVSS base score. Please read the CVSS standards guide to fully understand how to score CVSS vulnerabilities and to interpret CVSS scores. The scores are computed in sequence such that the Base Score is used to calculate the Temporal Score and the Temporal Score is used to calculate the Environmental Score.
The CVSS score is commonly used for vulnerability metrics.
Links:
Single user mode, or maintenance mode, is a mode in which a multi-user computer OS boots into a single superuser. This mode is commonly know as runlevel 1 or rescue.target (rescue mode) in systems that implement Sys-V or Systemd style initialization respectively.
The single user mode allows administrators direct access to the root filesystem without a password in order to carry out system maintenance, such as
Here, I'm using Ubuntu as sample configuration.
In order to secure your system’s single user mode, you need to set the grub password. In this case we are going to generate hashed password for GRUB by running the command below.
# grub2-mkpasswd-pbkdf2
Enter password: <STRONG_PASSWORD>
Reenter password: <STRONG_PASSWORD>
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.2E76F....5334
Now, your GRUB hashed password has been generated:
grub.pbkdf2.sha512.10000.2E76F....5334 [283 bytes long ]
To enable grub password protection, you have to identify grub menu items to protect, users authorized to access the GRUB and their passwords. The users and their passwords are manually added /etc/grub.d/00_header file.
To edit the /etc/grub.d/00_header, run the command below;
# vim /etc/grub.d/00_header
Once you have opened the above file for editing, enter the superuser and its password at the end of the file in the following format.
cat << EOF
set superusers="superuser"
password_pbkdf2 superuser <STRONG_PASSWORD>
EOF
This should finally look like;
cat << EOF
set superusers="sysadm"
password_pbkdf2 sysadm grub.pbkdf2.sha512.10000.2E76F....5334 [283 bytes long]
EOF
Once you are done editing, save the file and update grub by running the following command.
# update-grub2
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.15.0-36-generic
Found initrd image: /boot/initrd.img-4.15.0-36-generic
done
When grub is updated, the user/password information is automatically added to the GRUB 2 menu configuration file, grub.cfg.
Now your grub is password protected. To verify this, reboot your system and try to boot to rescue mode or emergency mode.
Note that if you lost you both your grub password and the root password, the only way to get to the shell is by booting your system with LiveCD, mount the root partition in rw mode and remove the password in the grub configuration file.
Before rebooting the system, I usually would like to make an additional configuration here. I don't want to enter additional password every time my system is reboot or turn on. I can protect the GRUB with password for any actions, except booting existing menu entries without changing them.
Now, let's define default menu entries as --unrestricted, allowing to use them without password. Linux menu entries are defined in file /etc/grub.d/10_linux. The simpliest way to change all entries is to modify CLASS variable in the beginning of the file:
CLASS="--class gnu-linux --class gnu --class os --unrestricted"
Now to update actual /boot/grub/grub.cfg you should run update-grub2 (for Debian-based OS, like Ubuntu) or grub-mkconfig -o <path to grub.cfg> for others.
In emergency mode, all the files system of a Linux system are mounted in read-only mode. This mode is generally used in the situations where we can’t boot the system in rescue mode, may be due to some file system corruptions. Refer below steps to boot Ubuntu 20.04 in emergency mode:
Links:
This is a simple and yet useful (hidden) feature in Notepad that I learned recently.
Today, I have a colleague that asks me about a vulnerability called "TLS/SSL Server Supports The Use of Static Key Ciphers " (ssl-static-key-ciphers).
This vulnerability has CVSS 2.6 (rated by Rapid7). According to Rapid7:
The server is configured to support ciphers known as static key ciphers. These ciphers don't support "Forward Secrecy". In the new specification for HTTP/2, these ciphers have been blacklisted.
Here're the questions to me:
My answers:
Last month, I created a ruby script to list all users in Kenna. And I found that I need to list all the roles besides the user list.
Then, I notice I'm not a good ruby developer.
I just re-write a script in python to list all users (including myself) and all roles in Kenna.
 |
| kenna-users.py -h |
Short/quick notes about VMware products : ESX, ESXi, vCenter, vSphere/client.
ESX/ESXi
VMware vCenter Server
vSphere and vSphere client/HTML5
Links:
While working on Kenna data set, it is largely depends on the input from vulnerability scanning system. Sometimes, the data upload is delayed due to the Kenna connector is taking too long to upload the data.
Thus, I just created a python script that allow me to check the Kenna connector sync status.
I've been using KennaSecurity for one year. Then I found that something strange with KennaSecurity GUI.
When you try to list users in Kenna, you can't find yourself in the list even you are administrator.
Thus, I create a simple ruby script that help me to list all the users, including myself. ;)
Here, I collected some essential commands for OpenSSL.
Check the Connection:
$ openssl s_client -showcerts -connect www.microsoft.com:443
Decoding BASE64 (PEM) Certificate
Capture the output between “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–” tags, and save as a text file (i.e. cert_microsoft.com).
Run the command below to read the file, and display it in a textual format.
$ openssl x509 -noout -text -in cert_microsoft.com
Decoding Binary Certificate (DER) Certificate
DER is a binary certificate format and the content is the same as PEM (Base64).
$ openssl x509 -noout -text -inform der -in cert_microsoft.der
Convert Certificate between DER and PEM format
By the way, -inform is short for “input format”
$ openssl x509 -inform der -in cert_microsoft.der -out cert_microsoft.pem
$ openssl x509 -inform der -in cert_mirosoft.der -outform pem -out cert_microsoft.pem
$ openssl x509 -in cert_microsoft.pem -outform der -out cert_microsoft.der
$ openssl x509 -inform pem -in cert_microsoft.pem -outform der -out cert_microsoft.der
Checking the Chain of Trust
$ openssl verify -verbose cert_microsoft.pem
If you see "Error 20 at 0 depth lookup", it means that the intermediate certificate (or certificate for the Issuer of the server certificate) is missing.
$ openssl verify -untrusted cert_symantec cert_microsoft.pem
If you see "Error 20 at 1 depth lookup", it means the error is no longer on the server certificate (0 depth) but now can't find the issuer certificate for the Symantec cert.
$ openssl verify -untrusted cert_symantec -CAfile ./RootCerts.pem cert_microsoft.pem
You should see everything is "OK" now.
If you have more than 1 intermediate certificate, just concatenate both certs into one.
$ cat inter1.pem inter2.pem > inter_both.pem
Testing SSLv2/SSLv3/TLSv1/TLSv1.1/TLSv1.2/TLSv1.3
$ openssl s_client -ssl2 -connect microsoft.com:443
$ openssl s_client -ssl3 -connect microsoft.com:443
$ openssl s_client -tls1 -connect microsoft.com:443
$ openssl s_client -tls1_1 -connect microsoft.com:443
$ openssl s_client -tls1_2 -connect microsoft.com:443
$ openssl s_client -tls1_3 -connect microsoft.com:443
$ openssl s_client [-no_ssl3, -no_tls1, -no_tls1_1, -no_tls1_2, -no_tls1_3] -connect microsoft.com:443
Get the Common Name (cn) or Subject
$ openssl x509 -noout -subject -in cert_microsoft.pem
Renegotiation (by client)
$ openssl s_client -connect www.microsoft.com:443
HEAD / HTTP/1.0
R
<CRLF>
Testing Weak Ciphers
$ openssl s_client -cipher NULL,EXPORT,LOW,3DES -connect <site:port>Testing NULL Cipher
$ openssl s_client -cipher aNULL -connect <site:port>Forward Secrecy
Testing RC4 ciphers
$ openssl s_client -cipher RC4 -connect <site:port>Testing Compression (CRIME/TLS or BREACH/HTTP)
"Compression: zlib compression" and "Compression: 1 (zlib compression)"
indicate that the remote server is vulnerable to the CRIME attack. "Compression: NONE" means not vulnerable to TLS compression.
$ openssl s_client -connect <site:port>
GET / HTTP/1.1 Host: example.com Accept-Encoding: compress, gzip
<CRLF><CRLF> If the response contains encoded data, it indicates that HTTP compression is supported; therefore the remote host is vulnerable (to BREACH).