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/" }
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
Hello,
1) The report will only include SecretFound events.
2) The badsecret_product is the product of the cryptography operation: eyJhbGciOiJIUzI1NiJ9.eyJJc3N1ZXIiOiJJc3N1[...].
3) Yes.
4) The badsecret_type is copied directly from the outer "type" field in the source record:
[ { "description" : { "product" : "ASP.NET Viewstate", "secret" : "ASP.NET MachineKey", "severity" : "CRITICAL" }, "detecting_module" : "ASPNET_Viewstate", "hashcat" : null, "location" : "body", "product" : "Qm5gWpJWit2/uOIIbBGCOpOMejP746lqyUGc+fLuPAk4kas8HDUpRhIZk+4WFBB1+TUiT+H7dHbK73nEAuy6cdMWOospfHsXgX6h5m6eNlbpShAOAllMnrnDMz6jAtASi15KzSnP9N92jnFXSfzYkhY4KS8sf48P7KTCDSc6VHXDiyUB8FRsmW/FvDbNEmkrqTNgZD0TMByBdCqZ8LG5IBtAhXvXEJP0v0aOt1vDJXed453/3MbQ1KWynq4+6p0j474l1XKLVS/qKCfZ8A6VEpHjOrChBdrgpXc9jqtrf3SriDyBqRsU6Rcv+ertYOWGmYVc7U9kohdO2Eu/SjWWjGD0oa65o3W2aQzNaqktpYtnapDw/EF5WJUC1eO3Ippfj61T5VuUKzuCuvf0Pepqy+gZZnOM6ws0jLiKIOrrDVxKHrzedwDogCtYm5ffoNQi", "type" : "IdentifyOnly" } ]
The website is in the process of being updated. The revised schema is below.
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" ], [ "extra.", "badsecret_secret", "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" ], [ "extra.", "badsecret_secret", "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/" }
On 9/8/25 1:03 AM, Kamil Mankowski via IntelMQ-dev wrote:
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:
- 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?
- 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.
- 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.
- "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 08/09/2025 10:03, Kamil Mankowski via IntelMQ-dev wrote:
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.
Most weak cryptography is bad configuration and to some extent every vulnerability is also bad configuration (reach-ability from the internet, no updates etc.). IMHO this feed perfectly fits the definition of weak-crypto. Its description is: "Publicly accessible services offering weak cryptography, e.g., web servers susceptible to POODLE/FREAK attacks."
I'm wondering more if the term "badsecrets" (used as classification.identifier) is widely known in the industry or if it is otherwise self-explanatory. To me it seems to be very generic and nondescript.
Feedback on the field naming:
On 08/09/2025 17:01, elsif via IntelMQ-dev wrote:
[ "extra.", "http", "validate_to_none" ],
According to your website this is the HTTP version used, so better: "http_version"
[ "extra.", "server", "validate_to_none" ],
The website says "HTTP Server type", so the wording here is very ambiguous. What about http_server_version?
In the next IntelMQ version the correct field will be product.full_name (https://github.com/certtools/intelmq/pull/2574). So, we will need different schemas per IntelMQ version 🤔️
[ "extra.", "request_path", "validate_to_none" ],
Other Shadowserver Feeds use http_path. Another common name is urlpath (parsers fireeye and ctip).
Hello,
Please advise if the classification should be changed.
The updated field mappings are below.
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.http_version", "http", "validate_to_none" ], [ "extra.http_server_version", "server", "validate_to_none" ], [ "extra.http_path", "request_path", "validate_to_none" ], [ "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_code", "convert_int" ], [ "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" ], [ "extra.", "badsecret_secret", "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.http_version", "http", "validate_to_none" ], [ "extra.http_server_version", "server", "validate_to_none" ], [ "extra.http_path", "request_path", "validate_to_none" ], [ "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_code", "convert_int" ], [ "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" ], [ "extra.", "badsecret_secret", "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/" }
On 9/8/25 12:13 PM, Sebix wrote:
On 08/09/2025 10:03, Kamil Mankowski via IntelMQ-dev wrote:
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.
Most weak cryptography is bad configuration and to some extent every vulnerability is also bad configuration (reach-ability from the internet, no updates etc.). IMHO this feed perfectly fits the definition of weak-crypto. Its description is: "Publicly accessible services offering weak cryptography, e.g., web servers susceptible to POODLE/FREAK attacks."
I'm wondering more if the term "badsecrets" (used as classification.identifier) is widely known in the industry or if it is otherwise self-explanatory. To me it seems to be very generic and nondescript.
Feedback on the field naming:
On 08/09/2025 17:01, elsif via IntelMQ-dev wrote:
[ "extra.", "http", "validate_to_none" ],
According to your website this is the HTTP version used, so better: "http_version"
[ "extra.", "server", "validate_to_none" ],
The website says "HTTP Server type", so the wording here is very ambiguous. What about http_server_version?
In the next IntelMQ version the correct field will be product.full_name (https://github.com/certtools/intelmq/pull/2574). So, we will need different schemas per IntelMQ version 🤔️
[ "extra.", "request_path", "validate_to_none" ],
Other Shadowserver Feeds use http_path. Another common name is urlpath (parsers fireeye and ctip). -- Institute for Common Good Technology gemeinnütziger Kulturverein - nonprofit cultural society https://commongoodtechnology.org/ ZVR 1510673578
Thanks for changes and clarifying the report, Jason!
@Sebix:
Most weak cryptography is bad configuration and to some extent every vulnerability is also bad configuration (reach-ability from the internet, no updates etc.). IMHO this feed perfectly fits the definition of weak-crypto. Its description is: "Publicly accessible services offering weak cryptography, e.g., web servers susceptible to POODLE/FREAK attacks."
I'd like to ask for opinion from others as I understand this a little different. My understanding of the "weak crypto" is that it pushes on the cryptographic algorithms or implementations itself.
The "badsecret" library makes the focus on basically leaving default or copy-pasted secrets (...I have never seen this... ;)), while the cryptography algorithms and their configuration are not checked (as far as I see in the current version).
I belive it could match both categories, so the question to others - what suits better from the operators' perspective?
re: badsecret as identifier - while it's not an established name, I believe it immediately points to the issue of "bad secrets" being used, so it should be a good name.
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/8/25 21:37, elsif via IntelMQ-dev wrote:
Hello,
Please advise if the classification should be changed.
The updated field mappings are below.
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.http_version", "http", "validate_to_none" ], [ "extra.http_server_version", "server", "validate_to_none" ], [ "extra.http_path", "request_path", "validate_to_none" ], [ "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_code", "convert_int" ], [ "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" ], [ "extra.", "badsecret_secret", "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.http_version", "http", "validate_to_none" ], [ "extra.http_server_version", "server", "validate_to_none" ], [ "extra.http_path", "request_path", "validate_to_none" ], [ "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_code", "convert_int" ], [ "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" ], [ "extra.", "badsecret_secret", "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/" }
On 9/8/25 12:13 PM, Sebix wrote:
On 08/09/2025 10:03, Kamil Mankowski via IntelMQ-dev wrote:
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.
Most weak cryptography is bad configuration and to some extent every vulnerability is also bad configuration (reach-ability from the internet, no updates etc.). IMHO this feed perfectly fits the definition of weak-crypto. Its description is: "Publicly accessible services offering weak cryptography, e.g., web servers susceptible to POODLE/FREAK attacks."
I'm wondering more if the term "badsecrets" (used as classification.identifier) is widely known in the industry or if it is otherwise self-explanatory. To me it seems to be very generic and nondescript.
Feedback on the field naming:
On 08/09/2025 17:01, elsif via IntelMQ-dev wrote:
[ "extra.", "http", "validate_to_none" ],
According to your website this is the HTTP version used, so better: "http_version"
[ "extra.", "server", "validate_to_none" ],
The website says "HTTP Server type", so the wording here is very ambiguous. What about http_server_version?
In the next IntelMQ version the correct field will be product.full_name (https://github.com/certtools/intelmq/pull/2574). So, we will need different schemas per IntelMQ version 🤔️
[ "extra.", "request_path", "validate_to_none" ],
Other Shadowserver Feeds use http_path. Another common name is urlpath (parsers fireeye and ctip). -- Institute for Common Good Technology gemeinnütziger Kulturverein - nonprofit cultural society https://commongoodtechnology.org/ ZVR 1510673578
IntelMQ-dev mailing list -- intelmq-dev@lists.cert.at To unsubscribe send an email to intelmq-dev-leave@lists.cert.at
On 09.09.25 09:25, Kamil Mankowski via IntelMQ-dev wrote:
I belive it could match both categories, so the question to others - what suits better from the operators' perspective?
I think "weak-crypto" perfectly fits here and the classification.type should also be changed to "weak-crypto" for ssl-poodle and ssl-freak.
"extra.http_server_version", "server", "validate_to_none"
The value of "server" is not only a version number but also includes the product name (like Apache or nginx). So how about writing this to "extra.http_server" (without "_version")?
Btw, I think the term "product" is quite confusing here. While the authors of the badsecrets library use it for "cryptographic product" I think most people will associate the name of an affected product like "Django" or "Rails" with "product".
So I wonder if something like "extra.badsecret_value" would be a better place to store the value of "badsecret_product" to avoid confusions?
I also wonder why the value of "badsecret_secret" is empty in most cases in the reports. Shouldn't this value always be available if a known secret has been detected?
- Thomas
The revised mapping is attached below.
The 'badsecret_secret' was added late in the day yesterday, so it was only partially populated.
Regards,
Jason
--
{ "constant_fields" : { "classification.identifier" : "badsecret", "classification.taxonomy" : "vulnerable", "classification.type" : "weak-crypto", "protocol.application" : "http" }, "feed_name" : "IPv6-Badsecrets", "file_name" : "scan6_badsecrets", "optional_fields" : [ [ "extra.badsecret_value", "badsecret_product", "validate_to_none" ], [ "extra.http_version", "http", "validate_to_none" ], [ "extra.http_server", "server", "validate_to_none" ], [ "extra.http_path", "request_path", "validate_to_none" ], [ "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.", "http_code", "convert_int" ], [ "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" ], [ "extra.", "badsecret_secret", "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" : "weak-crypto", "protocol.application" : "http" }, "feed_name" : "Badsecrets", "file_name" : "scan_badsecrets", "optional_fields" : [ [ "extra.badsecret_value", "badsecret_product", "validate_to_none" ], [ "extra.http_version", "http", "validate_to_none" ], [ "extra.http_server", "server", "validate_to_none" ], [ "extra.http_path", "request_path", "validate_to_none" ], [ "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.", "http_code", "convert_int" ], [ "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" ], [ "extra.", "badsecret_secret", "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/" }
On 9/9/25 2:44 AM, Thomas Hungenberg via IntelMQ-dev wrote:
On 09.09.25 09:25, Kamil Mankowski via IntelMQ-dev wrote:
I belive it could match both categories, so the question to others - what suits better from the operators' perspective?
I think "weak-crypto" perfectly fits here and the classification.type should also be changed to "weak-crypto" for ssl-poodle and ssl-freak.
"extra.http_server_version", "server", "validate_to_none"
The value of "server" is not only a version number but also includes the product name (like Apache or nginx). So how about writing this to "extra.http_server" (without "_version")?
Btw, I think the term "product" is quite confusing here. While the authors of the badsecrets library use it for "cryptographic product" I think most people will associate the name of an affected product like "Django" or "Rails" with "product".
So I wonder if something like "extra.badsecret_value" would be a better place to store the value of "badsecret_product" to avoid confusions?
I also wonder why the value of "badsecret_secret" is empty in most cases in the reports. Shouldn't this value always be available if a known secret has been detected?
- Thomas
IntelMQ-dev mailing list -- intelmq-dev@lists.cert.at To unsubscribe send an email to intelmq-dev-leave@lists.cert.at