SOLDIERX.COM Nobody Can Stop Information Insemination

Posted by Sysdream Labs on Jan 11

# [CVE-2018-10091] Stored XSS vulnerabilities in AudioCode IP phones

## Description

The AudioCodes 400HD series of IP phones is a range of easy-to-use,
feature-rich desktop devices for the service provider hosted services,
enterprise IP telephony and contact center markets.

Most of user inputs in the CGI interface are not protected against XSS
injections.

Theses vulnerabilities have only been tested on the 420HD phone.

## Vulnerability...

Posted by Henri Salo on Jan 11

Fixed in 2.15.1

https://mantisbt.org/blog/archives/mantisbt/602
https://mantisbt.org/bugs/view.php?id=24580
http://github.com/mantisbt/mantisbt/commit/4efac90ed89a5c009108b641e2e95683791a165a

Is this correct?

Posted by Henri Salo on Jan 11

Fixed in what version or commit? Did you request CVE identifier for this
vulnerability?

Posted by Daniel Bishtawi on Jan 11

Hello,

We are glad to inform you about the vulnerabilities we reported in Ampache
3.8.6

Here are the details:

Advisory by Netsparker
Name: Multiple Reflected Cross-site Scripting in Ampache 3.8.6
Affected Software: Ampache
Affected Versions: 3.8.6
Homepage: http://ampache.org
Vulnerability: Reflected Cross-site Scripting
Severity: Medium
Status: Not Fixed
CVSS Score (3.0): CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L
Netsparker Advisory...

Posted by Daniel Bishtawi on Jan 11

Hello,

We are glad to inform you about the vulnerabilities we reported in
BlogEngine 3.3.

Here are the details:

Advisory by Netsparker
Name: XML External Entity Injection Vulnerability in BlogEngine 3.3
Affected Software: BlogEngine
Affected Versions: 3.3
Homepage: https://blogengine.io/
Vulnerability: XML External Entity (XXE) Injection Vulnerability
Severity: High
Status: Not Fixed
CVE-ID: 2018-14485
CVSS Score (3.0):...

Posted by Daniel Bishtawi on Jan 11

Hello,

We are glad to inform you about the vulnerabilities we reported
in OrangeForum 1.4.0

Here are the details:

Advisory by Netsparker
Name: Open Redirection Vulnerabilities in OrangeForum 1.4.0
Affected Software: OrangeForum
Affected Versions: 1.4.0
Homepage: https://github.com/s-gv/orangeforum
Vulnerability: Open Redirection
Severity: Medium
Status: Fixed
CVE-ID: CVE-2018-14474
CVSS Score (3.0): CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N...

Posted by Nguyen Anh Quynh on Jan 11

Greetings,
We are happy to announce version 4.0.1 of Capstone disassembler framework!
This release fixes some bugs of v4.0, and introduces some improvements for
the Python binding. We encourage all users of v4.0 to upgrade.
In no particular order, we would like to thank NowSecure
<https://www.nowsecure.com/>, Verichains <https://verichains.io>& Vsec
<https://vsec.com.vn/en/>for sponsoring this release!
We also wish to...

Posted by hyp3rlinx on Jan 11

[+] Credits: John Page (aka hyp3rlinx)
[+] Website: hyp3rlinx.altervista.org
[+] Source:
http://hyp3rlinx.altervista.org/advisories/MICROSOFT-WINDOWS-VCF-FILE-INSUFFICIENT-WARNING-REMOTE-CODE-EXECUTION.txt
[+] ISR: ApparitionSec
[+] Zero Day Initiative Program

[Vendor]
www.microsoft.com

[Product]
A VCF file is a standard file format for storing contact information for a
person or business.
Microsoft Outlook supports the vCard and vCalendar...

Posted by X41 D-Sec GmbH Advisories on Jan 11

X41 D-SEC GmbH Security Advisory: X41-2018-009

ReDoS Vulnerability in UA-Parser
================================
Severity Rating: Medium
Confirmed Affected Versions: 2015-05-14 and newer, commit
6fd6c261274254bcbbacd77ef4b12534c7f9923d
Confirmed Patched Versions: v0.6.0 released 2018-12-14, commit
010ccdc7303546cd22b9da687c29f4a996990014
Vendor: UA-Parser Project
Vendor URL: https://github.com/ua-parser
Vector: HTTP request
Credit: X41 D-SEC...

Posted by Nathaniel Ferguson on Jan 11

Well that's not entirely true, a significant percentage of work comes from vendors seeking to acquire or utilize
another product or an institution going through some sort of audit wherein both cases the client is someone that
doesn't really even want to be going through it and it's something being forced on them. Those are the instances I've
encountered where the sort of negotiating down or into entire absence findings are...

Posted by Adrian Sanabria on Jan 11

Everywhere I've ever pentested, we've used a low/medium/high or
low/medium/high/critical scale - this is my first encounter with DREAD.
What you describe though - clients attempting to negotiate down the
severity of vulns on the report - was common regardless of the scoring
system used. I don't see DREAD being unique in that respect.

Reflecting, it's probably what pushed me towards the binary system I ended
up using. No score...

Posted by Adam Shostack on Jan 11

Okay, I'll respond generally about DREAD. The issue comes up when
people say "We'll treat a DREAD rating of >= 8 as critical." Then
someone looks at your discoverability of 7, and says "hmm, if this
were a 6, then DREAD would be 7.9...can we change it?" Lacking any
guidance on the difference, it's hard to say no.

Really, it's often "You're being unreasonable by making
discoverability a 7...

Posted by Adrian Sanabria on Jan 11

I probably shouldn't have brought it up - I'm not involved much on the
pentesting side. I know we've discussed replacing it, but finding little
out there to replace it with.

In my own work, I find most of my pentesting results come down to a binary
value (hackable, not hackable) and some sense of likelihood of it getting
exploited by a malicious party. Highs/mediums/lows all seem pointless when
emulating the attacker perspective....

Posted by Adrian Sanabria on Jan 11

I understand the limitations and challenges of CVSS. We already do a lot of
what you mentioned to come up with a risk score. Some of it, I'm still
trying to figure out how to do. The bottom line though, is that we find the
factors that go into the score (CIA, exploitability, exploit availability,
attack vector, etc) to be useful. The score *itself*, is what I was talking
about not being terribly useful, though it does go into our model also....

Posted by Moritz Muehlenhoff on Jan 10

-------------------------------------------------------------------------
Debian Security Advisory DSA-4365-1 security () debian org
https://www.debian.org/security/ Moritz Muehlenhoff
January 10, 2019 https://www.debian.org/security/faq
-------------------------------------------------------------------------

Package : tmpreaper
CVE ID : CVE-2019-3461

Stephen Roettger...

Posted by X41 D-Sec GmbH Advisories on Jan 10

X41 D-SEC GmbH Security Advisory: X41-2018-009

ReDoS Vulnerability in UA-Parser
================================
Severity Rating: Medium
Confirmed Affected Versions: 2015-05-14 and newer, commit
6fd6c261274254bcbbacd77ef4b12534c7f9923d
Confirmed Patched Versions: v0.6.0 released 2018-12-14, commit
010ccdc7303546cd22b9da687c29f4a996990014
Vendor: UA-Parser Project
Vendor URL: https://github.com/ua-parser
Vector: HTTP request
Credit: X41 D-SEC...

Posted by Dennis Groves on Jan 10

+1 Wim. You covered that perfectly.

Posted by Adam Shostack on Jan 10

I'm sorry, but I need to rant a little.

A decade back, I wrote a "DREAD is DEAD, please stop" blog post for
Microsoft. If you are getting consistent scoring out of DREAD, you
are not using DREAD (as described in Writing Secure Code 1, which I
think is the first public description).

You are using some derivitive that adds tools to provide for
that consistency. Those tools may be as simple as a set of examples
of each of the...

Posted by Monroe, Bruce on Jan 10

Uh no. CVSS scores a vulnerability and if it’s a vendor we’re scoring that without knowing how you have the vulnerable
software/firmware/hardware/ect deployed in your environment. It’s why the CVSS Base Score is worst case. The resulting
CVSS V3 vulnerability score is one element you can then calculate into your overall risk factoring. It’s the orgs job
consuming the CVSS V3x vulnerability score to determine their risk and set their...

Posted by Thierry Zoller on Jan 10

CVSS needs to be embedded as a parameter/criteria in a Risk Evaluation;
it is not a risk indicator in itself and should not be used for patch
prioritisation in itself.

The importance of the asset (business process it supports, revenue
generated by adjacent processes etc.) .i.e the "criticality"[1] of an
asset needs to be taken into account when risk scoring and prioritising
remediation.

[1] Of course other factors like for example...