11-02-2017 01:14 AM
Hi,
played around with the API with 7000 devices and 200 IOSes from my customers.
I get some strange answers from the API what makes me start thinking about the Quality of the received data.
Maybe someone can tell me why this happens, when i want to read the advisories for 3.8.5E error 406 is returned, all other IOS work:
02.11.2017 08:48:38 API Call -> https://api.cisco.com/security/advisories/ios?version=3.7.0E
02.11.2017 08:48:58 API Call -> https://api.cisco.com/security/advisories/ios?version=3.8.5E
02.11.2017 08:49:00 -> HTTP HTTP/1.1 406 Not Acceptable
02.11.2017 08:49:01 API Call -> https://api.cisco.com/security/advisories/ios?version=3.8.5E
02.11.2017 08:49:02 -> HTTP HTTP/1.1 406 Not Acceptable
02.11.2017 08:49:03 API Call -> https://api.cisco.com/security/advisories/ios?version=3.8.5E
02.11.2017 08:49:08 -> HTTP HTTP/1.1 406 Not Acceptable
02.11.2017 08:49:08 API Call -> https://api.cisco.com/security/advisories/ios?version=3.8.4E
02.11.2017 08:49:14 API Call -> https://api.cisco.com/security/advisories/ios?version=3.7.4E
02.11.2017 08:49:24 API Call -> https://api.cisco.com/security/advisories/ios?version=3.7.5E
02.11.2017 08:49:32 API Call -> https://api.cisco.com/security/advisories/ios?version=3.7.3E
02.11.2017 08:49:46 API Call -> https://api.cisco.com/security/advisories/ios?version=3.7.2E
02.11.2017 08:50:03 API Call -> https://api.cisco.com/security/advisories/ios?version=3.7.1E
When reading the coverage for Serial numbers one percent of them are not returning data, when using the coverage checker Webpage they work, for example:
02.11.2017 08:53:08 API Call -> https://api.cisco.com/sn2info/v2/coverage/summary/serial_numbers/JAD071605JG
02.11.2017 08:53:26 Serialnumber Error -> JAD071605JG
API Call -> https://api.cisco.com/sn2info/v2/coverage/summary/serial_numbers/JAD071605JG
{"pagination_response_record":{"last_index":1,"page_index":1,"page_records":1,"self_link":"https://api.cisco.com/sn2info/v2/coverage/summary/serial_numbers/JAD071605JG?page_index=1","title":"Get Coverage Summary by Serial Numbers - SN2INFO API","total_records":1},"serial_numbers":[{"base_pid_list":[{"base_pid":"CISCO2651XM="}],"contract_site_customer_name":"","contract_site_address1":"","contract_site_city":"","contract_site_state_province":"","contract_site_country":"","covered_product_line_end_date":"","id":"1","is_covered":"NO","orderable_pid_list":[{"item_description":"","item_position":"","item_type":"","orderable_pid":"","pillar_code":""}],"parent_sr_no":"","service_contract_number":"","service_line_descr":"","sr_no":"JAD071605JG","warranty_end_date":"","warranty_type":"","warranty_type_description":"","ErrorResponse":{"APIError":{"ErrorCode":"NO_RECORDS_FOUND","ErrorDescription":"No records found with the specified serial number","SuggestedAction":"Please check given serial number"}}}]}
Kind regards,
Kai
11-02-2017 06:01 AM
Hi Kai,
Thank you for reaching out. I can only comment for the openVuln API. The reason that you are getting those issues with the openVuln API, is because you are entering IOS-XE versions in the IOS URI.
In your example above:
02.11.2017 08:50:03 API Call -> https://api.cisco.com/security/advisories/ios?version=3.7.1E
For IOS-XE versions, please try:
https://api.cisco.com/security/advisories/iosxe?version=<<IOS XE version>>
In the following example, I am using the openVulnQuery python client.
omar@omar:~$ openVulnQuery --ios_xe 3\.7\.0E -f advisory_id sir cves [ { "advisory_id": "cisco-sa-20170927-dhcp", "cves": [ "CVE-2017-12240" ], "sir": "Critical" }, { "advisory_id": "cisco-sa-20170927-ike", "cves": [ "CVE-2017-12237" ], "sir": "High" }, { "advisory_id": "cisco-sa-20170927-pnp", "cves": [ "CVE-2017-12228" ], "sir": "High" }, { "advisory_id": "cisco-sa-20170727-ospf", "cves": [ "CVE-2017-6770" ], "sir": "Medium" }, { "advisory_id": "cisco-sa-20170726-aniacp", "cves": [ "CVE-2017-6665" ], "sir": "High" }, { "advisory_id": "cisco-sa-20170726-anidos", "cves": [ "CVE-2017-6663" ], "sir": "High" }, { "advisory_id": "cisco-sa-20170629-snmp", "cves": [ "CVE-2017-6736", "CVE-2017-6737", "CVE-2017-6738", "CVE-2017-6739", "CVE-2017-6740", "CVE-2017-6741", "CVE-2017-6742", "CVE-2017-6743", "CVE-2017-6744" ], "sir": "High" }, { "advisory_id": "cisco-sa-20170419-energywise", "cves": [ "CVE-2017-3860", "CVE-2017-3861", "CVE-2017-3862", "CVE-2017-3863" ], "sir": "High" }, { "advisory_id": "cisco-sa-20170322-dhcpc", "cves": [ "CVE-2017-3864" ], "sir": "High" }, { "advisory_id": "cisco-sa-20170320-ani", "cves": [ "CVE-2017-3849" ], "sir": "High" }, { "advisory_id": "cisco-sa-20170320-aniipv6", "cves": [ "CVE-2017-3850" ], "sir": "High" }, { "advisory_id": "cisco-sa-20170317-cmp", "cves": [ "CVE-2017-3881" ], "sir": "Critical" }, { "advisory_id": "cisco-sa-20160928-aaados", "cves": [ "CVE-2016-6393" ], "sir": "High" }, { "advisory_id": "cisco-sa-20160928-dns", "cves": [ "CVE-2016-6380" ], "sir": "High" }, { "advisory_id": "cisco-sa-20160928-ios-ikev1", "cves": [ "CVE-2016-6381" ], "sir": "High" }, { "advisory_id": "cisco-sa-20160928-msdp", "cves": [ "CVE-2016-6382", "CVE-2016-6392" ], "sir": "High" }, { "advisory_id": "cisco-sa-20160928-smi", "cves": [ "CVE-2016-6385" ], "sir": "High" }, { "advisory_id": "cisco-sa-20160928-frag", "cves": [ "CVE-2016-6386" ], "sir": "High" }, { "advisory_id": "cisco-sa-20160916-ikev1", "cves": [ "CVE-2016-6415" ], "sir": "High" }, { "advisory_id": "cisco-sa-20160525-ipv6", "cves": [ "CVE-2016-1409" ], "sir": "High" }, { "advisory_id": "cisco-sa-20160323-dhcpv6", "cves": [ "CVE-2016-1348" ], "sir": "High" }, { "advisory_id": "cisco-sa-20160323-ios-ikev2", "cves": [ "CVE-2016-1344" ], "sir": "High" }, { "advisory_id": "cisco-sa-20160323-smi", "cves": [ "CVE-2016-1349" ], "sir": "High" }, { "advisory_id": "cisco-sa-20151021-ntp", "cves": [ "CVE-2015-7691", "CVE-2015-7692", "CVE-2015-7701", "CVE-2015-7702", "CVE-2015-7703", "CVE-2015-7704", "CVE-2015-7705", "CVE-2015-7848", "CVE-2015-7849", "CVE-2015-7850", "CVE-2015-7851", "CVE-2015-7852", "CVE-2015-7853", "CVE-2015-7854", "CVE-2015-7855", "CVE-2015-7871" ], "sir": "Medium" }, { "advisory_id": "cisco-sa-20150923-fhs", "cves": [ "CVE-2015-6278", "CVE-2015-6279" ], "sir": "High" }, { "advisory_id": "cisco-sa-20150923-sshpk", "cves": [ "CVE-2015-6280" ], "sir": "Critical" }, { "advisory_id": "cisco-sa-20150408-ntpd", "cves": [ "CVE-2015-1798", "CVE-2015-1799" ], "sir": "Medium" }, { "advisory_id": "cisco-sa-20150325-ikev2", "cves": [ "CVE-2015-0642", "CVE-2015-0643" ], "sir": "High" }, { "advisory_id": "cisco-sa-20150320-openssl", "cves": [ "CVE-2015-0207", "CVE-2015-0209", "CVE-2015-0285", "CVE-2015-0287", "CVE-2015-0288", "CVE-2015-0289", "CVE-2015-0290", "CVE-2015-0291", "CVE-2015-0292", "CVE-2015-0293", "CVE-2015-1787" ], "sir": "High" }, { "advisory_id": "cisco-sa-20150310-ssl", "cves": [ "CVE-2014-3569", "CVE-2014-3570", "CVE-2014-3571", "CVE-2014-3572", "CVE-2014-8275", "CVE-2015-0204", "CVE-2015-0205", "CVE-2015-0206" ], "sir": "Medium" }, { "advisory_id": "Cisco-SA-20150113-CVE-2015-0204", "cves": [ "CVE-2015-0204" ], "sir": "Medium" } ]
Regards,
Omar
11-03-2017 01:01 AM
Hello Omar,
thanks for the reply, i'm still working on the application so the logging is not perfect.
I'm trying both URLs and use the Response that is positive, and both replies are 406.
Keith wrote i get the response because there are no SAs or CVEs, i think 406 is not the perfect response for that, a 200 with the Response that there are no SAs would be better. When i get 406 i think i did something wrong.
This is how my log looks like now:
03.11.2017 08:39:54 API Call -> https://api.cisco.com/security/advisories/ios?version=3.8.5E
03.11.2017 08:39:58 -> HTTP HTTP/1.1 406 Not Acceptable
03.11.2017 08:39:58 API Call -> https://api.cisco.com/security/advisories/iosxe?version=3.8.5E
03.11.2017 08:40:01 -> HTTP HTTP/1.1 406 Not Acceptable
Any Suggestion how my app can decide which URL to use ?
How do i know if 16.1.2 is a XE ?
I thought when the first letter is a 1 or 2 use IOS, 3 to 9 use XE, does that work ?
The list of the customer's devices contains 7000 devices and i want the app to decide which URL to use...
Thanks,
Kai
11-02-2017 06:09 AM
Hi Kai,
The best place for questions about the PSIRT API is their discussion forum at Cisco Product Security Incident Response Team (PSIRT). But I think the reason you are getting the 406 is that there are no advisories for 3.8.5E. (And you may want to check your logging routine - I am pretty sure you are calling /advisories/iosxe?version=3.8.5E - the message above says ..../ios?version....)
As for SN2Info, it doesn't look like JAD071605JG was ever placed under a service contract, so it wasn't found when the API went looking for coverage info.
Regards,
Keith
11-03-2017 01:05 AM
Hello Keith,
thanks for the response, i updated the logging so now it is correct.
Anyway i get the 406 when using the XE URL too, no SAs is great but when i get 406 i think it is my fault.
Regarding the serial numbers i can live with that, was just thinking that some info like the PID and the warranty (which is always there i think) would be returned.
Thanks,
Kai
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide