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