Important Splunk update for timestamp issue starting 01.01.2020

Splunk has identified an issue regarding timestamps, which are intensivly used for data correlation in many Splunkbased logging and SIEM systems. Affected versions are Splunk Enterprise, Splunk Light and Splunk Cloud. This issue has potential significant impact on data ingestion - including causing inaccurate, unsearchable, or prematurely-deleted data - starting January 1, 2020.

Cause of the issue: Timestamps using two-digit years will stop being correctly recognized. Full details around this issue, including workarounds and product fixes, are documented in Release Notes for each Splunk Version: https://docs.splunk.com/Documentation/Splunk/latest/ReleaseNotes/FixDatetimexml2020
 

Possible Solutions:

1. Manual Change of "datetimes.xml"

Change on all Splunk systems (search heads, indexers, heavy forwards etc) the file "datetimes.xml" with the following file: http://download.splunk.com/products/ingest2020/datetime.zip
In order to do that, put the downloaded in $SPLUNK_HOME/etc. (mostly found in /opt/splunk/etc). Then restart the system (in a Indexer Cluster a rolling-restart is possible). Until a splunk patch is available, the warning will be shown, that this file is not part of the splunk manifest. This will be fixed in the future splunk versions.

2. Update to a version with a fix

Splunk will ship minor releases with fixes, soon:

Major Release --- Minor Release with patch
6.6 --- 6.6.12.1 (not yet released)
7.0 --- 7.0.13.1 (not yet released)
7.1 --- 7.1.10 (not yet released)
7.2 --- 7.2.9.1 (not yet released)
7.3 --- 7.3.3 (Installationguide)
8.0 --- 8.0.1 (not yet released)

FortiOS XSS in DHCP-Monitor

Fortinet has released PSIRT FG-IR-19-184 (CVE-2019-6697) about a vulnerability in FortiOS of the FortiGate firewall. A DHCP packet may contain a stored XSS in the hostname parameter field.

Affected Versions and Update

Affected Products are FortiOS 6.2.1 and below & FortiOS 6.0.6 and below.

FortiOS 6.2.2 and FortiOS 6.0.7 fix the vulnerability

PoC/Vulnerability Details from ssd-disclosure.com

Source: https://ssd-disclosure.com/archives/3987/ssd-advisory-fortigate-dhcp-stored-xss

An unauthenticated attacker can trigger a Stored XSS Vulnerability via a malicious DHCP packet in the Fortigate DHCP Monitor.

This can happen if Device Detection is enabled through Network >Interface > Edit Interface > Device Detection

  


 When this option is enabled the attacker may perform the following steps in order to exploit the vulnerability:

1. Install dhtest or any other tool that can send arbitrary DHCP packets.
   (https://sargandh.wordpress.com/2012/02/23/linux-dhcp-client-simulation-tool/)
2. Send a malicious DHCP packet. For example:
   
   #./dhtest-master/dhtest -i eth0 -m 12:34:56:78:90:12 -h "x<svg onload=alert();)>x" [Option] -m : mac address -h : hostname(dhcp option 12). The attacker can inject malicious scripts.

   1 2 3 4

   #./dhtest-master/dhtest -i eth0 -m 12:34:56:78:90:12 -h "x<svg onload=alert();)>x"     [Option]     -m : mac address     -h : hostname(dhcp option 12). The attacker can inject malicious scripts.

Linux show all cronjobs of all users

How to Linux show all cronjobs of all users (not ldap or nis users): Use the following command as root:

for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done

Example:

linuxhost001:~ # for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done
no crontab for bin
no crontab for daemon
no crontab for ftp
no crontab for lp
no crontab for mail
no crontab for man
no crontab for messagebus
no crontab for news
no crontab for nobody
no crontab for nscd
no crontab for openslp
no crontab for polkitd
no crontab for postfix
no crontab for root
no crontab for rpc
no crontab for sshd
no crontab for statd
no crontab for systemd-bus-proxy
no crontab for systemd-timesync
no crontab for uucp
no crontab for wwwrun
no crontab for ntp
no crontab for nagios
no crontab for radiusd 

Intel NUC running VMware ESXi 6.5.3

Because there are some people on the internet asking for experience on "is my Intel NUC supporting ESXi version x.y.z?", so I will provide short feedback regarding that: Using an Intel NUC NUC7i7DNHE "Intel NUC 8th Gen Commercial" (https://www.intel.de/content/www/de/de/products/boards-kits/nuc.html) I'm running VMware ESXi 6.5 update 3 without any additional drivers necessary.

VMware updates can be found here: http://www.vmware.com/patchmgr/download.portal

Apple iPhone/iPad iOS IPSec IKEv2 Proposals

When setting up VPN-tunnel from an Apple iPhone or iPad running iOS using IPSec with IKEv2 you need to know, which IPSec proposals the iPhone/iPad/iOS device are supporting/offering:

Offered proposals from iOS

Testing with an iPhone running iOS 12.4.1 and iPad 13.1.2:

• AES256-SHA256-DH14 (2048-bit MODP Group) <------ (✔ okay)
• AES256-SHA256-DH19 (256-bit random ECP group) <------ (✅ recommended)
• AES256-SHA256-DH5 (1536-bit MODP Group) <------ (❌not recommended)
• AES128-SHA1-DH2 (1024-bit MODP Group) <------ (❌not recommended)
• 3DES-SHA1-DH2 (1024-bit MODP Group) <------ (❌not recommended)

Recommendation

Therefore I recommened 🔒✅ to use for your IPSec IKEv2 proposals:

• IKEv2 Phase1: AES-CBC-256 with SHA2-256 and DH-Grp 19 (ECP 256bit)
• IKEv2 Phase2: AES-CBC-256 with SHA2-256 and DH-Grp 19 (ECP 256bit)

DH-Grp 19 ECP 256Bit > DH-Grp 14 RSA 2048Bit
-> For example see BSI recommendation for crypto IPSec page 13 section 3.2.4  or NIST recommendation page 9 line 264

-> Details for ECP (Elliptic Curve from NIST) for IKEv1/v2 see RFC5903 or IANA ipsec registry

Details to reverse engineering

iPhone iOS 12.4.1 IKEv2 RAW output:

2019-10-27 16:25:15.519164 ike 4: incoming proposal:
2019-10-27 16:25:15.519176 ike 4: proposal id = 1:
2019-10-27 16:25:15.519185 ike 4:   protocol = IKEv2:
2019-10-27 16:25:15.519195 ike 4:      encapsulation = IKEv2/none
2019-10-27 16:25:15.519205 ike 4:         type=ENCR, val=AES_CBC (key_len = 256)
2019-10-27 16:25:15.519215 ike 4:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
2019-10-27 16:25:15.519224 ike 4:         type=PRF, val=PRF_HMAC_SHA2_256
2019-10-27 16:25:15.519234 ike 4:         type=DH_GROUP, val=MODP2048.
2019-10-27 16:25:15.519246 ike 4: proposal id = 2:
2019-10-27 16:25:15.519255 ike 4:   protocol = IKEv2:
2019-10-27 16:25:15.519264 ike 4:      encapsulation = IKEv2/none
2019-10-27 16:25:15.519274 ike 4:         type=ENCR, val=AES_CBC (key_len = 256)
2019-10-27 16:25:15.519283 ike 4:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
2019-10-27 16:25:15.519293 ike 4:         type=PRF, val=PRF_HMAC_SHA2_256
2019-10-27 16:25:15.519303 ike 4:         type=DH_GROUP, val=ECP256.
2019-10-27 16:25:15.519314 ike 4: proposal id = 3:
2019-10-27 16:25:15.519323 ike 4:   protocol = IKEv2:
2019-10-27 16:25:15.519332 ike 4:      encapsulation = IKEv2/none
2019-10-27 16:25:15.519342 ike 4:         type=ENCR, val=AES_CBC (key_len = 256)
2019-10-27 16:25:15.519353 ike 4:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
2019-10-27 16:25:15.519365 ike 4:         type=PRF, val=PRF_HMAC_SHA2_256
2019-10-27 16:25:15.519374 ike 4:         type=DH_GROUP, val=MODP1536.
2019-10-27 16:25:15.519384 ike 4: proposal id = 4:
2019-10-27 16:25:15.519392 ike 4:   protocol = IKEv2:
2019-10-27 16:25:15.519400 ike 4:      encapsulation = IKEv2/none
2019-10-27 16:25:15.519408 ike 4:         type=ENCR, val=AES_CBC (key_len = 128)
2019-10-27 16:25:15.519416 ike 4:         type=INTEGR, val=AUTH_HMAC_SHA_96
2019-10-27 16:25:15.519424 ike 4:         type=PRF, val=PRF_HMAC_SHA
2019-10-27 16:25:15.519432 ike 4:         type=DH_GROUP, val=MODP1024.
2019-10-27 16:25:15.519443 ike 4: proposal id = 5:
2019-10-27 16:25:15.519451 ike 4:   protocol = IKEv2:
2019-10-27 16:25:15.519459 ike 4:      encapsulation = IKEv2/none
2019-10-27 16:25:15.519466 ike 4:         type=ENCR, val=3DES_CBC
2019-10-27 16:25:15.519474 ike 4:         type=INTEGR, val=AUTH_HMAC_SHA_96
2019-10-27 16:25:15.519482 ike 4:         type=PRF, val=PRF_HMAC_SHA
2019-10-27 16:25:15.519490 ike 4:         type=DH_GROUP, val=MODP1024.