lab.mogwaisecurity.de because sharing is caring...

Security Advisories

The following vulnerabilities were discovered and reported by Mogwai Security:

IDDescription
MSA-2014-01ManageEngine EventLog Analyzer Multiple Vulnerabilities
MSA-2014-02Typo3 Extension dmmjobcontrol Multiple Vulnerabilities
MSA-2015-01WP Pixarbay Images Multiple Vulnerabilities
MSA-2015-02Hewlett-Packard UCMDB - JMX-Console Authentication Bypass
MSA-2015-03iPass Mobile Client service local privilege escalation
MSA-2016-01PowerFolder Remote Code Execution Vulnerability

Mogwai Vulnerability Disclosure Policy

This policy outlines how Mogwai handles responsible vulnerability disclosure to product vendors and the general public. Mogwai will responsibly and promptly notify the appropriate product vendor of a security flaw with their product(s) or service(s). It is the goal of this policy to balance the need of the public to be informed of security vulnerabilities with vendors’ need for time to respond effectively.

Our policy is based on the vulnerability disclosure policy from Thierry Zoller, with slightly modified time frames.

This policy outlines how Mogwai handles responsible vulnerability disclosure to product vendors and the general public. Mogwai will responsibly and promptly notify the appropriate product vendor of a security flaw with their product(s) or service(s). It is the goal of this policy to balance the need of the public to be informed of security vulnerabilities with vendors’ need for time to respond effectively.

Our policy is based on the vulnerability disclosure policy from Thierry Zoller, with slightly modified time frames.

  1. If no security contact is known for the vendor and no security contact can be found at OSVDB, an e-mail requesting the security contact e-mail address may initially be sent to certain public e-mail addresses associated with the vendor. Online forms may only be used to request security contact information.
  2. When a security contact or other relevant e-mail address has been identified, a vendor initially receives a mail with vulnerability details along with a pre-set disclosure date (usually set to a Wednesday two week later).
  3. If the vendor does not respond to the initial mail within a week, it is resent.
  4. If no response has been received at the day of the pre-set disclosure date, the vulnerability information is published immediately without further coordination attempts.
  5. If the vendor responds to either the initial mail or the resent mail, a new disclosure date may be set in case the vendor cannot meet the pre-set date.
  6. We expect to receive continuous status updates from the vendor and a list of all affected products, should no list be given it is assumed all products are vulnerable. If none are provided by default, the vendor will be contacted about once a month with a status update request (if time permits).
  7. Should a vendor not respond to a status update request, it is resent.
  8. Should the vendor not respond to two consecutive status update requests, a mail is sent to the vendor advising that the vulnerability information will be disclosed a week later if no response is received. Has no response been received by this date, the vulnerability information is immediately published without further coordination attempts.
  9. Eventually, the vulnerability information will be published by me when:
    a) The pre-set/agreed disclosure date is reached.
    b) The vendor issues a fix and/or security advisory
    c) Information about the same vulnerability is published by a third party.
    d) A year from the initial contact date has passed
    e) the vendor denies the security nature of the bug and/or gives no credit for my work
  10. Unless the vendor asks for an extension, as will not coordinate a vulnerability disclosure for more than 6 months. After 6 months the details will be published regardless of patch availability.