Package Instance

Nautobot may allows uploaded media files to be accessible without authentication
Files uploaded by users to Nautobot's `MEDIA_ROOT` directory, including DeviceType image attachments as well as images attached to a Location, Device, or Rack, are served to users via a URL endpoint that was not enforcing user authentication. As a consequence, such files can be retrieved by anonymous users who know or can guess the correct URL for a given file.

For DeviceType image attachments, a mitigating factor is that no URL endpoint exists for listing the contents of the `devicetype-images/` subdirectory, and the file names are as specified by the uploading user, so any given DeviceType image attachment can only be retrieved by correctly guessing its file name.

Similarly, for all other image attachments, while the images *can* be listed by accessing the `/api/extras/image-attachments/` endpoint *as an authenticated user only*, absent that authenticated access, accessing the files would again require guessing file names correctly.

Nautobot is a Network Source of Truth and Network Automation Platform built as a web application atop the Django Python framework with a PostgreSQL or MySQL database. In Nautobot 1.x and 2.0.x prior to 1.6.7 and 2.0.6, the URLs `/files/get/?name=...` and `/files/download/?name=...` are used to provide admin access to files that have been uploaded as part of a run request for a Job that has FileVar inputs. Under normal operation these files are ephemeral and are deleted once the Job in question runs. 

In the default implementation used in Nautobot, as provided by `django-db-file-storage`, these URLs do not by default require any user authentication to access; they should instead be restricted to only users who have permissions to view Nautobot's `FileProxy` model instances.

Note that no URL mechanism is provided for listing or traversal of the available file `name` values, so in practice an unauthenticated user would have to guess names to discover arbitrary files for download, but if a user knows the file name/path value, they can access it without authenticating, so we are considering this a vulnerability.

Fixes are included in Nautobot 1.6.7 and Nautobot 2.0.6. No known workarounds are available other than applying the patches included in those versions.

Unauthenticated views may expose information to anonymous users
A number of Nautobot URL endpoints were found to be improperly accessible to unauthenticated (anonymous) users, including the following:

- `/api/graphql/` (1)
- `/api/users/users/session/` (Nautobot 2.x only; the only information exposed to an anonymous user is which authentication backend classes are enabled on this Nautobot instance)
- `/dcim/racks/<uuid:pk>/dynamic-groups/` (1)
- `/dcim/devices/<uuid:pk>/dynamic-groups/` (1)
- `/extras/job-results/<uuid:pk>/log-table/`
- `/extras/secrets/provider/<str:provider_slug>/form/` (the only information exposed to an anonymous user is the fact that a secrets provider with the given slug (e.g. `environment-variable` or `text-file`) is supported by this Nautobot instance)
- `/ipam/prefixes/<uuid:pk>/dynamic-groups/` (1)
- `/ipam/ip-addresses/<uuid:pk>/dynamic-groups/` (1)
- `/virtualization/clusters/<uuid:pk>/dynamic-groups/` (1)
- `/virtualization/virtual-machines/<uuid:pk>/dynamic-groups/` (1)

(1) These endpoints will not disclose any Nautobot data to an unauthenticated user unless the Nautobot configuration variable `EXEMPT_VIEW_PERMISSIONS` is changed from its default value (an empty list) to permit access to specific data by unauthenticated users.

Of these endpoints, the only one that poses any significant risk of sensitive information disclosure under normal Nautobot operation with a default configuration is `/extras/job-results/<uuid:pk>/log-table/`. This endpoint returns an HTML table containing all of the logs associated with the specified JobResult; while these logs may contain sensitive information depending on the Jobs executed in Nautobot, this exposure is mitigated somewhat by the fact that any attacker would have to have prior knowledge of the existence of a JobResult with a particular UUID.

In the interest of full disclosure, the following additional endpoints were also accessible to anonymous users, but do not disclose any sensitive data when accessed (only a listing of other API endpoints).

- `/api/`
- `/api/circuits/`
- `/api/dcim/`
- `/api/extras/`
- `/api/ipam/`
- `/api/plugins/`
- `/api/tenancy/`
- `/api/users/`
- `/api/virtualization/`

All of the above endpoints have been corrected to require user authentication, with the exception of `/api/users/users/session/` which is unused at this time and therefore has been simply removed from Nautobot 2.1.9. Additionally, we have added test automation which enumerates available Nautobot URL endpoints and verifies that appropriate authentication requirements are in place; this test was instrumental in identifying the above comprehensive list.

Nautobot's BANNER_* configuration can be used to inject arbitrary HTML content into Nautobot pages
A Nautobot user with admin privileges can modify the `BANNER_TOP`, `BANNER_BOTTOM`, and `BANNER_LOGIN` configuration settings via the `/admin/constance/config/` endpoint. Normally these settings are used to provide custom banner text at the top and bottom of all Nautobot web pages (or specifically on the login page in the case of `BANNER_LOGIN`) but it was reported that an admin user can make use of these settings to inject arbitrary HTML, potentially exposing Nautobot users to security issues such as cross-site scripting (stored XSS).

Nautobot: Management of users via REST API does not apply configured password validators
### Impact

In Nautobot versions prior to 2.4.30 or prior to 3.0.10, user creation and editing via the REST API fails to apply the password validation rules defined by Django's `AUTH_PASSWORD_VALIDATORS` setting (which defaults to an empty list, i.e., no specific rules, but can be configured in Nautobot's `nautobot_config.py` to apply various rules if desired). This can potentially allow for the creation or modification of users to have passwords that are weak or otherwise do not comply with configured standards.

Management of users via the Nautobot admin UI does correctly enforce configured password validation at this time.

### Patches

The issue is resolved in Nautobot versions 2.4.30 and 3.0.10 and later.

- https://github.com/nautobot/nautobot/pull/8778
- https://github.com/nautobot/nautobot/pull/8779

### Workarounds

Review which users have been granted object permissions to create and modify user accounts as well as having access tokens for the REST API, and restrict access as appropriate.

It may be appropriate furthermore to rotate passwords for any user accounts suspected to have been given weak passwords.

### References

- https://docs.djangoproject.com/en/4.2/ref/settings/#std-setting-AUTH_PASSWORD_VALIDATORS
- http://docs.djangoproject.com/en/4.2/topics/auth/passwords/#password-validation