#js

This Metasploit module exploits a database credentials leak found in Oracle Demantra 12.2.1 in combination with an authentication bypass. This way an unauthenticated user can retrieve the database name, username and password on any vulnerable machine.

This Metasploit module exploits an information disclosure vulnerability in the Views module of Drupal, brute-forcing the first 10 usernames from a to z. Drupal 6 with Views module less than or equal to 6.x-2.11 are vulnerable. Drupal does not consider disclosure of usernames as a weakness.

This Metasploit module exploits a memory disclosure vulnerability in Elasticsearch 7.10.0 to 7.13.3 (inclusive). A user with the ability to submit arbitrary queries to Elasticsearch can generate an error message containing previously used portions of a data buffer. This buffer could contain sensitive information such as Elasticsearch documents or authentication details. This vulnerabilitys output is similar to heartbleed.

This Metasploit module exploits a file download vulnerability found in Oracle Demantra 12.2.1 in combination with an authentication bypass. By combining these exposures, an unauthenticated user can retrieve any file on the system by referencing the full file path to any file a vulnerable machine.

This Metasploit module enumerates wireless access points through Chromecast.

This Metasploit module queries the etcd API to recursively retrieve all of the stored key value pairs. Etcd by default does not utilize authentication.

This Metasploit module exploits an improper access control vulnerability (CVE-2023-6329) in Control iD iDSecure less than or equal to v4.7.43.0. It allows an unauthenticated remote attacker to compute valid credentials and to add a new administrative user to the web interface of the product.

ManageEngine Password Manager Pro (PMP) has an authenticated blind SQL injection vulnerability in SQLAdvancedALSearchResult.cc that can be abused to escalate privileges and obtain Super Administrator access. A Super Administrator can then use his privileges to dump the whole password database in CSV format. PMP can use both MySQL and PostgreSQL databases but this module only exploits the latter as MySQL does not support stacked queries with Java. PostgreSQL is the default database in v6.8 and above, but older PMP versions can be upgraded and continue using MySQL, so a higher version does not guarantee exploitability. This Metasploit module has been tested on v6.8 to v7.1 build 7104 on both Windows and Linux. The vulnerability is fixed in v7.1 build 7105 and above.

### Summary GeoNode is vulnerable to an XML External Entity (XXE) injection in the style upload functionality of GeoServer leading to Arbitrary File Read. ### Details GeoNode's GeoServer has the ability to upload new styles for datasets through the [`dataset_style_upload` view](https://github.com/GeoNode/geonode/blob/99b0557da5c7db23c72ad39e466b88fe43edf82d/geonode/geoserver/urls.py#L70-L72). ```py # https://github.dev/GeoNode/geonode/blob/99b0557da5c7db23c72ad39e466b88fe43edf82d/geonode/geoserver/views.py#L158-L159 @login_required def dataset_style_upload(request, layername): def respond(*args, **kw): kw['content_type'] = 'text/html' return json_response(*args, **kw) ... sld = request.FILES['sld'].read() # 1 sld_name = None try: # Check SLD is valid ... sld_name = extract_name_from_sld(gs_catalog, sld, sld_file=request.FILES['sld']) # 2 except Exception as e: respond(errors=f"The uploaded SLD file is not valid X...

# Name Updating a DID with a nym transaction will be written to the ledger if neither ROLE or VERKEY are being changed, regardless of sender. # Description A malicious DID with no particular role can ask an update for another DID (but cannot modify its verkey or role). This is bad because: 1. Any DID can write a nym transaction to the ledger (i.e., any DID can spam the ledger with nym transactions). 1. Any DID can change any other DID's alias. 1. The update transaction modifies the ledger metadata associated with a DID. # Expected vs Observed We expect that if a DID (with no role) wants to update another DID (not its own or one it is the endorser), then the nodes should refuse the request. We can see that requirements in the [Indy default auth_rules](https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md) in Section "Who is the owner" in the last point of "Endorser using". We observe that with a normal DID, we can update the field `from` for a random DID, ...