Paessler PRTG 22.4.81.1532 security fix for Cross Site Scripting XSS

Paessler PRTG released version 22.4.81.1532 (stable) in which a PRTG the tag handling system was fixed regarding tag parameters to avoid the risk of a possible Cross Site Scripting (XSS) attack.

Updates are available for PRTG Preview 22.4.81.1504 or PRTG Stable 22.4.81.1532

• PRTG Stable 22.4.81.1532 sha256 installer exe 0DD1952B8EE8A56F77FBA968366794BFA58ABEFC38151192D378EAF35607091F
• PRTG Stable 22.4.81.1532 sha256 installer zip 64F4918CE265ED58EC98996516D59AA97BB7BBC614AAD644E2F90C9DAB22F106
• PRTG Preview 22.4.81.1504 sha256 installer exe: 28F05875EA31067881B2E04B3557F1BBC3D174D2064CCBA3E93BD4F1EC2E7839
• PRTG Preview 22.4.81.1504 sha256 installer zip A82725C7C7BBA8E116F31030857BD3DE099FF5B7C40248E04A1DB425A617318E

Source: https://www.paessler.com/prtg/history/stable

API security - How to start securing APIs

APIs are great, they are everywhere and they grow. When thinking about API security very often very basic security mechanisms are missing. This article is about the very minimum frist steps you should always take:

First steps to think about

1. Only expose the parts of the interface which are necessary, not the entire API
   
2. Only collect and publish the data which is really necessary
3. Only grant access to people/systems which need it
4. Switch sides and think like an attacker ("Write a black mirror episode about your API", Keith Casey 2019)

API gateway

Use API gateways, because they take care of:

1. Lifecycle: In which state is your API? How was it designed and built? To which gateways is it published and is it live & available?
2. Interface: What does it expose? Which resources, methods, objects and fields?
3. Access: Who can use it? Which users or groups, which authentication, which clients, which contexts?
4. Usage: How to succeed with it? API documentation, debugging and errors, tracking usage, examples & sdks?
5. Business: How does it drive business goals? Partner CRM, marketing, business analytics

API gateways like apigee, kong, apache apisix, krakenD, the list is long. Great overview about open source api gateways: https://www.predic8.de/open-source-api-management-kong-tyk-fusio-umbrella-wso2.htm

API Access

Use available standards like OpenID connect. Don't just use OAuth Core, but instead the OpenID connect, because you'd probably missing a lot of different additional important standards. A list of the few common OAuth/OIDC specifications may show why:

(Source: https://www.youtube.com/watch?v=D7AfQKxFC0U)

 

Input validation

There are so many different attack vectors. One of the most basic yet so often missing things is good input validation, which helps stopping classical attacks like XSS, injections, deserialization and so on. But it also stops breaking the programms intention or in other words its business logic. 

 

Input validation should be applied in the enforcment of correct syntax (e.g. SSN, date, currency symbol), so the syntactic level and for semantic validation to enforce correctness of their values in the specific business context (e.g. start date is before end date, price is within expected range).

There is so much more

• https://owasp.org/www-project-api-security/  
• https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
• https://attack.mitre.org/techniques/T1106/
• Regularly updating your systems of which the api is built on
• Harden your systems, applications, middleware, runtime-environment and interfaces of which the api is built on
• Do regularly penetration testing and vulnerability scanning
  
• Enhance and regularly review logging & monitoring including automized alerts based on thresholds
  

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.