Mapping looks good to me - I was considering usage of "weak-crypto" type, but the scan seems to be concentrated on misconfiguration (default secrets). Thus, the vulnerable-system works better.
However, I have questions to the report itself:
1) badsecret_type is SecretFound or IdentifyOnly. "If only informational then it is set to IdentifyOnly. The naming convention is from the badsecret library." I'm trying to understand what IdentifyOnly means - does it still mean that the website uses a known secret? Or just identifies a technology used? My understanding is the second, what would however not justify the HIGH severity assigned to such events in the example report on the website.
I've done a quick test and the given badsecret_product in the example report do not produce any known secret using stock badsecrets library, but it is identified as signed cookie. Shouldn't it be an INFO or even omitted in this report? Having non-default secret is the correct behaviour, right? Or maybe you have a non-standard list of weak keys?
2) badsecret_product - the name is a little confusing, and it's not "secret found" as stated on your website.
Compare the example output (fromhttps://github.com/blacklanternsecurity/badsecrets/tree/main?tab=readme-ov-f...):
Known Secret Found!
Detecting Module: Generic_JWT
Product Type: JSON Web Token (JWT) Product: eyJhbGciOiJIUzI1NiJ9.eyJJc3N1ZXIiOiJJc3N1[...] Secret Type: HMAC/RSA Key Location: manual Secret: 1234
The "product" is the product of cryptography operation, e.g. signed cookie or JWT (compare also your example report). The vulnerable secret is a separated output field.
3) Would you consider sharing the detected secret value? From the receiver perspective, it's much more helpful to see: 'your cookie secret is "development key"' than an encrypted cookie you have to check why we're alerting about it. Also, including the secret type could be useful.
4) "badsecret_type" in your report seems to be a little unfortunate as it collides with two "type" fields from the library: Product Type and Secret Type. I'd suggest renaming it to "badsecret_result"
Best regards
// Kamil Mańkowski mankowski@cert.at - T: +43 676 898 298 7204 // CERT Austria - https://www.cert.at/ // CERT.at GmbH, FB-Nr. 561772k, HG Wien
On 9/6/25 19:18, elsif via IntelMQ-dev wrote:
Hello,
Below is the proposed mapping for a new report as documented at https://www.shadowserver.org/what-we-do/network-reporting/badsecrets- report/.
Please let me know if you have any changes before September 13th.
Regards,
Jason
{ "constant_fields" : { "classification.identifier" : "badsecret", "classification.taxonomy" : "vulnerable", "classification.type" : "vulnerable-system", "protocol.application" : "http" }, "feed_name" : "IPv6-Badsecrets", "file_name" : "scan6_badsecrets", "optional_fields" : [ [ "extra.", "severity", "validate_to_none" ], [ "protocol.transport", "protocol" ], [ "source.reverse_dns", "hostname" ], [ "extra.", "tag" ], [ "source.asn", "asn", "invalidate_zero" ], [ "source.geolocation.cc", "geo" ], [ "source.geolocation.region", "region" ], [ "source.geolocation.city", "city" ], [ "extra.source.naics", "naics", "invalidate_zero" ], [ "extra.", "hostname_source", "validate_to_none" ], [ "extra.source.sector", "sector", "validate_to_none" ], [ "extra.", "badsecret_location", "validate_to_none" ], [ "extra.", "badsecret_module", "validate_to_none" ], [ "extra.", "badsecret_type", "validate_to_none" ], [ "extra.", "badsecret_product", "validate_to_none" ], [ "extra.", "http", "validate_to_none" ], [ "extra.", "http_code", "convert_int" ], [ "extra.", "server", "validate_to_none" ], [ "extra.", "request_path", "validate_to_none" ], [ "extra.", "cert_serial_number", "validate_to_none" ], [ "extra.", "subject_common_name", "validate_to_none" ], [ "extra.", "issuer_common_name", "validate_to_none" ], [ "extra.", "subject_organization_name", "validate_to_none" ], [ "extra.", "issuer_organization_name", "validate_to_none" ], [ "extra.", "sha1_fingerprint", "validate_to_none" ], [ "extra.", "sha256_fingerprint", "validate_to_none" ] ], "required_fields" : [ [ "time.source", "timestamp", "add_UTC_to_timestamp" ], [ "source.ip", "ip", "validate_ip" ], [ "source.port", "port", "convert_int" ] ], "url" : "https://www.shadowserver.org/what-we-do/network-reporting/ badsecrets-report/" }
{ "constant_fields" : { "classification.identifier" : "badsecret", "classification.taxonomy" : "vulnerable", "classification.type" : "vulnerable-system", "protocol.application" : "http" }, "feed_name" : "Badsecrets", "file_name" : "scan_badsecrets", "optional_fields" : [ [ "extra.", "severity", "validate_to_none" ], [ "protocol.transport", "protocol" ], [ "source.reverse_dns", "hostname" ], [ "extra.", "tag", "validate_to_none" ], [ "source.asn", "asn", "invalidate_zero" ], [ "source.geolocation.cc", "geo" ], [ "source.geolocation.region", "region" ], [ "source.geolocation.city", "city" ], [ "extra.source.naics", "naics", "invalidate_zero" ], [ "extra.", "hostname_source", "validate_to_none" ], [ "extra.source.sector", "sector", "validate_to_none" ], [ "extra.", "badsecret_location", "validate_to_none" ], [ "extra.", "badsecret_module", "validate_to_none" ], [ "extra.", "badsecret_type", "validate_to_none" ], [ "extra.", "badsecret_product", "validate_to_none" ], [ "extra.", "http", "validate_to_none" ], [ "extra.", "http_code", "convert_int" ], [ "extra.", "server", "validate_to_none" ], [ "extra.", "request_path", "validate_to_none" ], [ "extra.", "cert_serial_number", "validate_to_none" ], [ "extra.", "subject_common_name", "validate_to_none" ], [ "extra.", "issuer_common_name", "validate_to_none" ], [ "extra.", "subject_organization_name", "validate_to_none" ], [ "extra.", "issuer_organization_name", "validate_to_none" ], [ "extra.", "sha1_fingerprint", "validate_to_none" ], [ "extra.", "sha256_fingerprint", "validate_to_none" ] ], "required_fields" : [ [ "time.source", "timestamp", "add_UTC_to_timestamp" ], [ "source.ip", "ip", "validate_ip" ], [ "source.port", "port", "convert_int" ] ], "url" : "https://www.shadowserver.org/what-we-do/network-reporting/ badsecrets-report/" }
IntelMQ-dev mailing list -- intelmq-dev@lists.cert.at To unsubscribe send an email to intelmq-dev-leave@lists.cert.at