Security News

SEC Consult SA-20200728-0 :: Stored Cross-Site Scripting (XSS) Vulnerability in Namirial SIGNificant SignAnyWhere

Full Disclosure - 29 July, 2020 - 14:22

Posted by SEC Consult Vulnerability Lab on Jul 29

SEC Consult Vulnerability Lab Security Advisory < 20200728-0 >
=======================================================================
title: Stored Cross-Site Scripting (XSS) Vulnerability
product: Namirial SIGNificant SignAnyWhere
vulnerable version: v6.10.60.25434 (SSP v4.22.60.25434)
v6.10.100.25817 (SSP v4.22.100.25817)
fixed version: v19.76.0.26030 (SSP v19.76.0.26030)...

Re: [EXTERNAL] WAF Metrics

Daily Dave - 17 July, 2020 - 18:25

Posted by Chuck McAuley via Dailydave on Jul 17

Isn’t using a WAF an “investment in technology to stop constant attacks?”

-chuck
From: Greg Frazier <glfrazier () alum mit edu>
Date: Friday, July 17, 2020 at 3:46 PM
To: Don Ankney <dankney () hackerco de>
Cc: John Lampe <jlampe () tenable com>, Rafal Los <Rafal () ishackingyou com>, Chuck McAuley <chuck.mcauley () keysight
com>, "dailydave () lists aitelfoundation org" <dailydave () lists...

Re: [EXTERNAL] WAF Metrics

Daily Dave - 17 July, 2020 - 18:07

Posted by Greg Frazier via Dailydave on Jul 17

I'm not parsing your argument. If you knew the bug was there, you would fix
the bug. The WAF is there to mitigate the bugs that you are not aware of.
Further, web accesses that are out of scope of your intended functionality
but do not trigger a bug may be information gathering attacks that you
would, in hindsight, have wished your WAF had blocked. I would argue that
the WAF is not a stop-gap at all--it is an integral part of your...

Re: [EXTERNAL] WAF Metrics

Daily Dave - 15 July, 2020 - 17:05

Posted by Don Ankney via Dailydave on Jul 15

So far, this conversation focuses on how effectively WAFs block malicious HTTP requests. I'd argue that this is both a
red herring and an abuse of WAF technology. A WAF only protects the enterprise when it blocks a request that would
trigger an actual bug. If there's no bug present, all that's really happening is that likely malicious requests are
being logged at a much higher costs than if it were simply allowed to sit in the...

Re: [EXTERNAL] WAF Metrics

Daily Dave - 15 July, 2020 - 09:48

Posted by Chuck McAuley via Dailydave on Jul 15

This isn’t directly related to John’s observation below, but it got me motivated to further clarify some of the
challenges involved in testing WAFs.

I’ve seen many implementations over the years that try to determine the decision making process of an IPS, WAF, or
similar device by simply interrogating it from the client side only. The realities of test of measurement is that it
requires the user to implement both a client and server...

Re: [EXTERNAL] WAF Metrics

Daily Dave - 13 July, 2020 - 19:07

Posted by John Lampe via Dailydave on Jul 13

Yeah, I guess the way I would envision it going would be:

1) web app scanner sees XSS vuln on /path/to/foo.php
2) my integration ties that web app scan into a format to pass to WAF
3) WAF sets up anti-xss rules on /path/to/foo.php (we had to actually
create a static mapping for this step)
4) measure how many hits the waf blocks to that endpoint for the XSS

John

Re: WAF Metrics

Daily Dave - 13 July, 2020 - 13:26

Posted by Chuck McAuley via Dailydave on Jul 13

We’ve released a mid-pandemic product that is designed to test production deployed WAF’s by doing exactly what
@ranger_cha is describing.

It will run tests that include both known/existing attacks that a WAF should stop and common patterns that all WAF’s
should recognize and stop. Separately and clearly, so the use can see the impact of stopping both sets of assessments
separately.

https://www.ixiacom.com/products/threat-simulator

The...

WAFs: HTTP Desynchronization as a Metric

Daily Dave - 13 July, 2020 - 10:27

Posted by Dave Aitel via Dailydave on Jul 13

So one thing people don't have any scope of measuring - (maybe as a set
diagram finite states?) - is the difference between two parsers for the
same protocol. Ten years ago a lot of the security community had a
discussion about "LangSec <http://langsec.org/>" which turns out to have
been entirely correct in retrospect.

NCCGroup's recently released analysis of the F5 bug is a key example of
this principle in action:...

Re: [EXTERNAL] WAF Metrics

Daily Dave - 13 July, 2020 - 10:02

Posted by Rafal Los via Dailydave on Jul 13

John,
Can you expand on #2? How do you measure the number of attacks stifled?

_--
Rafal
_Mobile: (404) 606-6056
_Email: Rafal.Los@Seventy7.Consulting<mailto:Rafal.Los@Seventy7.Consulting>

From: John Lampe via Dailydave <dailydave () lists aitelfoundation org>
Reply-To: John Lampe <jlampe () tenable com>
Date: Saturday, July 11, 2020 at 9:52 PM
To: Dave Aitel <dave.aitel () gmail com>
Cc: "dailydave () lists...

Re: WAF Metrics

Daily Dave - 11 July, 2020 - 21:51

Posted by Moses Frost via Dailydave on Jul 11

I guess some of us who grew up mapping ports and protocols into their neat
buckets will need to live with that fact that everything will eventually
ride over a multiplexed 443 socket, just something to think about before
the rant.

TL;DR - The answer to your question about measurement and effectiveness is
going to come down: "how long before you can see what I'm doing".

WAF's are a rather complex beast, but I guess they do...

Re: [EXTERNAL] WAF Metrics

Daily Dave - 11 July, 2020 - 21:04

Posted by John Lampe via Dailydave on Jul 11

So, I recently did an integration for a company that took their web app
scanner results and mapped those to existing WAF rules. I can think of 2
metrics based off that

1) How many real-world vulns have a corresponding check in the WAF? and
2) Once the WAF rules have been put in place to protect actually-vulnerable
endpoints, how many attacks were actually stifled?

John

WAF Metrics

Daily Dave - 11 July, 2020 - 11:42

Posted by Dave Aitel via Dailydave on Jul 11

So I'm making a video on metrics, of all things, and I wanted to post both this
question <https://twitter.com/daveaitel/status/1281629327776522242?s=20>and
the best answer so far to the list to see if anyone had any other ideas or
followups.

-dave

[image: image.png]

[image: image.png]

Re: Brad gets real!

Daily Dave - 6 July, 2020 - 19:39

Posted by Konrads Smelkovs via Dailydave on Jul 06

Linux has too many stakeholders for a sensible equities process to happen
which is why treating everyone poorly (bugs are bugs) is fairer than
coordinating disclosure. In an example, if an earth shattering Linux bug
was to emerge, why would RedHat be in the know while Russian defence
contractors who build their countries’ systems on local Linux distros would
be excluded ?

Re: Brad gets real!

Daily Dave - 6 July, 2020 - 19:13

Posted by Shawn Webb via Dailydave on Jul 06

Fully agreed with you there. I also dislike the culture of treating
security vulnerabilities as "just another bug." I feel there's some
form of newspeak with regards to security and the Linux kernel. There
is indeed a formalized method to report security-related bugs to the
Linux kernel (emailing security _AT _ kernel _DOT_ org). Yet Linux
developer culture says "all bugs are bugs, regardless of security
impact. A security bug...

Re: Brad gets real!

Daily Dave - 6 July, 2020 - 18:50

Posted by Dave Aitel via Dailydave on Jul 06

This is possibly true, although an Android vs iOS comparison here might be
more apt, from a technical perspective? But what Brad truly nails in his
talk is an overarching culture around the process of Linux kernel
development that is decidedly non-optimal when it comes to security.

For example, when proposing security features, a healthy community would
take a suggested patch and debate "What were you trying to accomplish? What
is the best...

Re: Brad gets real!

Daily Dave - 6 July, 2020 - 14:42

Posted by Shawn Webb via Dailydave on Jul 06

It's also hard to innovate without a userland that is tightly
integrated with the kernel (like the BSDs). On the BSD side, we're
able to ship an entire ecosystem with exploit mitigations applied
because a basic userland is shipped and integrated with the kernel.

The way in which the BSDs are structured enables innovation across the
entire ecosystem. We at HardenedBSD are able to test and deploy
exploit mitigations across the base...

Brad gets real!

Daily Dave - 6 July, 2020 - 13:58

Posted by Dave Aitel via Dailydave on Jul 06

https://www.youtube.com/watch?v=F_Kza6fdkSU

So I wanted to highlight this talk from Brad Spengler about the state of
Linux security. It's a damning report if you read even a little bit between
the lines. And on many levels. As Halvar points out, Android deliberately
avoided investing what they knew they needed to invest in platform security
in the effort to gather significant early market share, even knowing it
would harm their user-base in...

Data

Daily Dave - 18 June, 2020 - 14:48

Posted by Dave Aitel via Dailydave on Jun 18

I wanted to highlight something that I find funny did not make a much
bigger impact: DARPA's release of former INFILTRATE keynoter Bill Arbaugh's
dataset of endpoint behavioral data. See here for more information:
https://twitter.com/williamarbaugh/status/1273421101469753344?s=20

How else are you supposed to test if your Endpoint Protection DEEEEEEP
LEARNING works or does not work, as advertised? My only complaints are:
This is not as...

Defense in depth -- the Microsoft way (part 62): Windows shipped with end-of-life components

Bug Traq - 25 February, 2020 - 05:07

Posted by Stefan Kanthak on Feb 25

Hi @ll,

since Microsoft Server 2003 R2, Microsoft dares to ship and install the
abomination known as .NET Framework with every new version of Windows.

Among other components current versions of Windows and .NET Framework
include

C# compiler (C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe,
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\csc.exe)
J# compiler (C:\Windows\Microsoft.NET\Framework\v2.0.50727\jsc.exe,...

Local information disclosure in OpenSMTPD (CVE-2020-8793)

Bug Traq - 25 February, 2020 - 05:04

Posted by Qualys Security Advisory on Feb 25

Qualys Security Advisory

Local information disclosure in OpenSMTPD (CVE-2020-8793)

==============================================================================
Contents
==============================================================================

Summary
Analysis
Exploitation
POKE 47196, 201
Acknowledgments

==============================================================================
Summary...
Syndicate content