A flaw was found in automation-controller (AWX). Four compounding issues let a
holder of object-level NotificationTemplate admin recover the plaintext of
notification credentials for fixed-endpoint backends:
(1) NotificationTemplate.display_notification_configuration() (awx/main/models/
notifications.py) masks only password subfields of the CURRENT notification type,
so after a type change the previous type's password subfield is returned with its
full Fernet ciphertext; (2) NotificationTemplateSerializer.validate() (awx/api/
serializers.py) returns early when notification_configuration is absent from the
request body, allowing a type-only change that keeps the stale ciphertext; (3)
NotificationTemplate.save() skips re-encryption of any value beginning with
"$encrypted$" and the serializer's forward sentinel tests exact equality with
"$encrypted$", so a full ciphertext replanted into a different password subfield
is stored verbatim; (4) get_encryption_key() (awx/main/utils/encryption.py)
derives the Fernet key from the secret key, primary key, and field name only --
not the subfield -- so a ciphertext produced for one subfield decrypts as any
other subfield of the same object. Chaining these, an attacker switches the
template type to leak the ciphertext, replants it into a webhook password with an
attacker-controlled URL, and triggers /test/; the controller decrypts and sends
the plaintext to the attacker in an HTTP Basic auth header. Verified live on AAP
2.7 / automation-controller 4.8.1; still present on devel.
    Upstream: github.com/ansible/awx (awx/main/models/notifications.py;
              awx/api/serializers.py; awx/main/utils/encryption.py;
              awx/main/notifications/webhook_backend.py)