<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Cisco on Insinuator.net - Bold Statements</title>
    <link>https://insinuator.net/tags/cisco/</link>
    <description>Recent content in Cisco on Insinuator.net - Bold Statements</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 04 Jul 2019 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://insinuator.net/tags/cisco/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Security Advisories for Cisco ACI</title>
      <link>https://insinuator.net/2019/07/security-advisories-for-cisco-aci/</link>
      <pubDate>Thu, 04 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/07/security-advisories-for-cisco-aci/</guid>
      <description>&lt;p&gt;Again, Cisco released security advisories for their software-defined networking (SDN) solution called Application Centric Infrastructure (ACI). As before (see blog post &lt;a href=&#34;https://insinuator.net/2019/05/security-advisory-for-cisco-nexus-9000-series-fabric-switches-in-aci-mode/&#34;&gt;here&lt;/a&gt;), the published advisories originated from research performed in our ACI lab.&lt;/p&gt;&#xA;&lt;p&gt;The following advisories have been published:&lt;/p&gt;&#xA;&lt;p&gt;Cisco Nexus 9000 Series Fabric Switches ACI Mode Fabric Infrastructure VLAN Unauthorized Access Vulnerability&lt;br&gt;&#xA;&lt;a href=&#34;https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190703-n9kaci-bypass&#34;&gt;https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190703-n9kaci-bypass&lt;/a&gt;&lt;br&gt;&#xA;CVSS Base Score: 7.4&lt;/p&gt;&#xA;&lt;p&gt;Cisco Application Policy Infrastructure Controller REST API Privilege Escalation Vulnerability&lt;br&gt;&#xA;&lt;a href=&#34;https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190703-ccapic-restapi&#34;&gt;https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190703-ccapic-restapi&lt;/a&gt;&lt;br&gt;&#xA;CVSS Base Score: 7.2&lt;/p&gt;</description>
    </item>
    <item>
      <title>Autonomic Network Part 3: Vulnerabilities</title>
      <link>https://insinuator.net/2017/04/autonomic-network-part-3-vulnerabilities/</link>
      <pubDate>Thu, 13 Apr 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/04/autonomic-network-part-3-vulnerabilities/</guid>
      <description>&lt;p&gt;This is the 3rd post in the series of Autonomic Network (AN), it will dedicated for discussing the vulnerabilities. I recommend reading the first 2 parts (&lt;a href=&#34;https://insinuator.net/2017/03/autonomic-network-overview/&#34;&gt;part one&lt;/a&gt;, &lt;a href=&#34;https://insinuator.net/2017/03/autonomic-network-analysis/&#34;&gt;part two&lt;/a&gt;) to be familiar with the technology and how the proprietary protocol is constructed.&lt;/p&gt;&#xA;&lt;p&gt;Initially we will discuss 2 of the reported CVEs, but later there is more CVEs to come 😉&lt;/p&gt;&#xA;&lt;p&gt;Here is a quick overview on how our network looks like for 2 CVEs&lt;/p&gt;</description>
    </item>
    <item>
      <title>Autonomic Networking – Part 2: Analysis</title>
      <link>https://insinuator.net/2017/03/autonomic-networking-part-2-analysis/</link>
      <pubDate>Mon, 20 Mar 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/03/autonomic-networking-part-2-analysis/</guid>
      <description>&lt;p&gt;This is the second part in the Autonomic Network series. We have introduced previously in our &lt;a href=&#34;https://insinuator.net/2017/03/autonomic-network-overview/&#34;&gt;first part&lt;/a&gt; the Autonomic Network (AN), took a look about the needed configuration to run it on Cisco gear and what is the expected communication flow. In this post, we will dive deeper to have a closer look on the packets and how they are composed. Cisco’s AN protocol is a proprietary one and as far as I know, the analysis provided here for the protocol is the first of its kind.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Autonomic Networking – Part 1: Overview</title>
      <link>https://insinuator.net/2017/03/autonomic-networking-part-1-overview/</link>
      <pubDate>Sun, 19 Mar 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/03/autonomic-networking-part-1-overview/</guid>
      <description>&lt;p&gt;This is a 3-part series which introduces and analyzes Cisco’s implementation for Autonomic Network. In the 1st part, the technology is introduced and we have an overview about communication flow. In the &lt;a href=&#34;https://insinuator.net/2017/03/autonomic-network-analysis/&#34;&gt;2nd part&lt;/a&gt;, Cisco’s proprietary protocol is reverse engineered ? then finally in the &lt;a href=&#34;https://insinuator.net/2017/04/autonomic-network-vulnerabilities/&#34;&gt;3rd part&lt;/a&gt;, multiple vulnerabilities will be disclosed for the first time. If you’re aware of the technology, you can skip directly to part 2 where the action begins! &lt;/p&gt;</description>
    </item>
    <item>
      <title>Follow-Up on CVE-2016-1409 – IPv6 NDP DoS Vulnerability</title>
      <link>https://insinuator.net/2016/08/follow-up-on-cve-2016-1409-ipv6-ndp-dos-vulnerability/</link>
      <pubDate>Sun, 21 Aug 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/08/follow-up-on-cve-2016-1409-ipv6-ndp-dos-vulnerability/</guid>
      <description>&lt;p&gt;This is a guest post from &lt;a href=&#34;https://twitter.com/kafetzj&#34;&gt;Jed Kafetz&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;After seeing &lt;a href=&#34;https://www.insinuator.net/2016/05/cve-2016-1409-ipv6-ndp-dos-vulnerability-in-cisco-software/&#34;&gt;Christopher’s post&lt;/a&gt; I decided to create a proof using GNS3 and Virtualbox.&lt;br&gt;&#xA;The aim is to perform the exact attacking using Antonios Atlasis’ &lt;a href=&#34;http://www.secfu.net/tools-scripts/&#34;&gt;Chiron tools&lt;/a&gt; and run a Wireshark packet capture to prove the hop limit drops below 255.&lt;/p&gt;&#xA;&lt;p&gt;The following topology is used in GNS3:&lt;/p&gt;&#xA;&lt;p&gt;&lt;img src=&#34;https://www.insinuator.net/wp-content/uploads/2016/08/nw_diagram.png&#34; alt=&#34;nw_diagram&#34;&gt;The routers used are Cisco C372 and the machine labled Ubuntu is running 14.04 LTS Ubuntu Desktop, default installation. F0/0 is on the right and F0/1 is on the left.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CVE-2016-1409 – IPv6 NDP DoS Vulnerability in Cisco Software</title>
      <link>https://insinuator.net/2016/05/cve-2016-1409-ipv6-ndp-dos-vulnerability-in-cisco-software/</link>
      <pubDate>Mon, 30 May 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/05/cve-2016-1409-ipv6-ndp-dos-vulnerability-in-cisco-software/</guid>
      <description>&lt;p&gt;Dear readers,&lt;/p&gt;&#xA;&lt;p&gt;As you may have already noticed, Cisco released an urgent &lt;a href=&#34;https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160525-ipv6&#34;&gt;security advisory&lt;/a&gt; describing an IPv6 Neighbor Discovery DoS Vulnerability in several flavors of Cisco’s operating systems. Currently IOS-XR, XE and NX-OS are affected while ASA and “classic” IOS are under investigation. At first glance, it might look like yet another IPv6 DoS vulnerability. Looking closer, Cisco is mentioning an unauthenticated, remote attacker due to insufficient processing logic for crafted IPv6 NDP packets that are sent to an affected device. Following the public discussion about the vulnerability, it seems that these packets will reach the, probably low rate-limited, &lt;a href=&#34;https://supportforums.cisco.com/document/93456/asr9000xr-local-packet-transport-services-lpts-copp&#34;&gt;LPTS&lt;/a&gt; filter/queue on IOS XR devices “crowding” out legitimate NDP packets resulting in a DoS for IPv6 traffic, or in general a high CPU load as these packets will be processed by the CPU. More details are currently not available, but this might indicate the affected systems aren’t doing proper message validation checks on NDP packets (in addition to the LPTS filter/queue problem).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Observations from the Cisco Live Europe 2016 Wifi Infrastructure</title>
      <link>https://insinuator.net/2016/02/observations-from-the-cisco-live-europe-2016-wifi-infrastructure/</link>
      <pubDate>Tue, 16 Feb 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/02/observations-from-the-cisco-live-europe-2016-wifi-infrastructure/</guid>
      <description>&lt;p&gt;Good Evening,&lt;/p&gt;&#xA;&lt;p&gt;Enno and I spent the first day on Cisco Live Europe in Berlin today attending the “Advanced Practical Knowledge for Enterprise Deploying IPv6” technical breakout held by &lt;a href=&#34;https://twitter.com/bckcntryskr&#34;&gt;Tim Martin&lt;/a&gt; and &lt;a href=&#34;https://www.ciscolive.com/online/connect/speakerDetail.ww?PERSON_ID=B87EDE562B1002BDCC3504AD38E52492&#34;&gt;Jim Bailey&lt;/a&gt;. It was a good breakout session, and thanks again Tim for the honorable mention of our work in your slides! We really appreciate it. Like &lt;a href=&#34;https://www.insinuator.net/2015/01/observations-from-the-cisco-live-europe-wifi-infrastructure/&#34;&gt;last year&lt;/a&gt;, we were curious how the Wifi network was setup this year as I face a corresponding task for &lt;a href=&#34;https://www.troopers.de/troopers16/&#34;&gt;Troopers&lt;/a&gt; in March, with some &lt;a href=&#34;https://www.insinuator.net/2016/02/tr16-ipv6-security-summit-teaser-building-a-reliable-and-secure-ipv6-wifi-network/&#34;&gt;major changes&lt;/a&gt; in comparison to the last years. The Wifi infastructure in Berlin looked very similar to the one from last year in Milan, we had the “standard” Cisco Live SSID as well as an IPv6-only (with NAT64 as translation mechanism) SSID. The standard SSID looked identical to last year with the exception that now the &lt;a href=&#34;http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/IPV6_DG.html#pgfId-76925&#34;&gt;RA Throttling&lt;/a&gt; feature on the WLC was active from the beginning! Neither the M nor the O flag are set which means that my client has to use the legacy protocol to resolve AAAA records. As I am running Windows, it does not support &lt;a href=&#34;https://tools.ietf.org/html/rfc6106&#34;&gt;RA option 25 &lt;/a&gt; but the option wasn’t included in the RAs anyway. The preference was configured to the default “medium”. One thing I noticed, but haven’t had a chance to ask &lt;a href=&#34;https://twitter.com/ayourtch&#34;&gt;Andrew Yourtchenko&lt;/a&gt;, was that for the legacy (IPv4) connection they use HSRPv2 as an FHRP protocol (indicated by the MAC address &lt;a href=&#34;http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/xe-3s/fhp-xe-3s-book/fhp-hsrp-v2.html&#34;&gt;00:00:0c:9f:f0:01&lt;/a&gt; I received from the gateway) but for IPv6 I received Router Advertisements from two different MAC addresses (which both belong to Cisco, so I don’t think anyone sent spoofed RAs).  I am curious about the reasoning for this approach 🙂&lt;br&gt;&#xA;What i also encountered was that the Peer-to-Peer Blocking feature was apparently not enabled on the SSID as I was able to enumerate approx. 1600 active clients at the time. No worries, I haven’t done anything else, just was curious whether the feature was activated or not…&lt;/p&gt;</description>
    </item>
    <item>
      <title>#TR16 IPv6 Security Summit Teaser: Building a Reliable and Secure IPv6 WiFi Network</title>
      <link>https://insinuator.net/2016/02/%23tr16-ipv6-security-summit-teaser-building-a-reliable-and-secure-ipv6-wifi-network/</link>
      <pubDate>Mon, 08 Feb 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/02/%23tr16-ipv6-security-summit-teaser-building-a-reliable-and-secure-ipv6-wifi-network/</guid>
      <description>&lt;p&gt;Hi everyone,&lt;/p&gt;&#xA;&lt;p&gt;some of you may have seen my last &lt;a href=&#34;https://www.insinuator.net/2016/02/dhcpv6-option-52-on-cisco-dhcpv6-server/&#34;&gt;blog post&lt;/a&gt; about the preparation of the Troopers network. Today I want to give you a little teaser on what to expect for the &lt;a href=&#34;https://www.troopers.de/events/ipv6-security-summit-2016/672_case_study_building_a_secure_ipv6_guest_wifi_network/&#34;&gt;talk&lt;/a&gt; I will present during the IPv6 Security Summit. As the title implies, it’s not only about building a secure IPv6 WiFi, but also a reliable one. One might think that there aren’t many differences in comparison to IPv4, but the heavy reliance on multicast of IPv6 does have implications for Wi-Fi networks in general.&lt;/p&gt;</description>
    </item>
    <item>
      <title>DHCPv6 Option 52 on Cisco DHCPv6 Server</title>
      <link>https://insinuator.net/2016/02/dhcpv6-option-52-on-cisco-dhcpv6-server/</link>
      <pubDate>Sat, 06 Feb 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/02/dhcpv6-option-52-on-cisco-dhcpv6-server/</guid>
      <description>&lt;p&gt;Hi,&lt;/p&gt;&#xA;&lt;p&gt;I am currently preparing the &lt;a href=&#34;https://www.troopers.de&#34;&gt;Troopers&lt;/a&gt; network in a lab environment to ensure that we all will have a smooth Wi-Fi experience during Troopers. I wanted to spice things up a little bit for the Wi-Fi deployment (more on that in a following blogpost) and get rid of IPv4 wherever possible. Our Wi-Fi infrastructure consists of typical Cisco Access Points (1602) and a 2504 Wireless LAN Controller. Beginning with WLC image 8.0 it is finally supported to establish the CAPWAP tunnel between the AP and the WLC over IPv6, which is awesome and I wanted to implement it right away.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Cisco and the Maintenance Operation Protocol (MOP)</title>
      <link>https://insinuator.net/2015/08/cisco-and-the-maintenance-operation-protocol-mop/</link>
      <pubDate>Tue, 25 Aug 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/08/cisco-and-the-maintenance-operation-protocol-mop/</guid>
      <description>&lt;p&gt;Howdy,&lt;/p&gt;&#xA;&lt;p&gt;this is a short write up about the Maintenance Operation Protocol (MOP), an ancient remote management protocol from the &lt;a href=&#34;https://de.wikipedia.org/wiki/DECnet&#34;&gt;DECnet&lt;/a&gt; protocol suite. It’s old, rarely used and in most cases not needed at all. But as we stumbled across this protocol in some network assessments, it seems like a lot of network admins and other users don’t know about it. Even various hardening guides we’ve seen don’t mention MOP at all.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Evasion of Cisco ACLs by (Ab)Using IPv6 – Part 2</title>
      <link>https://insinuator.net/2015/07/evasion-of-cisco-acls-by-abusing-ipv6-part-2/</link>
      <pubDate>Wed, 08 Jul 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/07/evasion-of-cisco-acls-by-abusing-ipv6-part-2/</guid>
      <description>&lt;p&gt;When we wrote our initial blogpost regarding the &lt;a href=&#34;http://www.insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-discussion-of-mitigation-techniques/&#34;&gt;evasion of Cisco ACLs by (Ab)Using IPv6&lt;/a&gt;, where we described (&lt;a href=&#34;http://www.insinuator.net/2015/01/the-persistent-problem-of-state-in-ipv6-security/&#34;&gt;known to Cisco&lt;/a&gt;) cases of Access Control Lists (ACL) circumvention, we also suggested some mitigation techniques including the blocking of some (if not all) IPv6 Extension Headers.&lt;br&gt;&#xA;Almost a month later, we got &lt;a href=&#34;http://www.insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-discussion-of-mitigation-techniques/#respond&#34;&gt;a comment&lt;/a&gt; from &lt;em&gt;Matej Gregr&lt;/em&gt; that, even if the ACLs of certain Cisco Switches are configured to block IPv6 Extension headers like Hop-by-Hop or Destination Options headers, this does not actually happen/work as expected. Of course this made us re-visit the lab in the interim ;-).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Evasion of Cisco ACLs by (Ab)Using IPv6 &amp; Discussion of Mitigation Techniques</title>
      <link>https://insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-discussion-of-mitigation-techniques/</link>
      <pubDate>Wed, 28 Jan 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-discussion-of-mitigation-techniques/</guid>
      <description>&lt;p&gt;This is a guest post of &lt;a href=&#34;https://twitter.com/antoniosatlasis&#34;&gt;Antonios Atlasis&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;During our blogpost regarding &lt;a href=&#34;http://www.insinuator.net/2015/01/dhcpv6-guard-do-it-like-ra-guard-evasion/&#34;&gt;&lt;em&gt;DHCPv6 Guard evasion&lt;/em&gt;&lt;/a&gt;, one of the side-effects was that Access Control Lists (ACLs) configured to block access to UDP ports 546 can be evaded by abusing (again) IPv6 Extension headers. Having that in mind, we decided to check the effectiveness of Cisco IPv6 ACLs under various scenarios. Our goal was to examine whether the IPv6 ACLs of Cisco routers can be evaded, as well as under which conditions this can take place. To this end, several representative scenarios from enterprise environments or other potential ones are examined.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Observations from the Cisco Live Europe Wifi Infrastructure</title>
      <link>https://insinuator.net/2015/01/observations-from-the-cisco-live-europe-wifi-infrastructure/</link>
      <pubDate>Tue, 27 Jan 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/01/observations-from-the-cisco-live-europe-wifi-infrastructure/</guid>
      <description>&lt;p&gt;Given that Enno and I are network geeks, and that I am responsible for setting up the &lt;a href=&#34;https://www.troopers.de/&#34;&gt;Troopers&lt;/a&gt; Wifi network I was curious which components might be used at Cisco Live and which IPv6 related configuration was done for the Wifi network to ensure a reliable network and reduce the chatty nature of IPv6. Andrew Yourtchenko (&lt;a href=&#34;https://twitter.com/ayourtch&#34;&gt;@ayourtch&lt;/a&gt;) already did an amazing job last year at Cisco Live Europe explaining in detail (at the time session &lt;a href=&#34;http://d2zmdbbm9feqrf.cloudfront.net/2014/eur/pdf/BRKEWN-2666.pdf&#34;&gt;BRKEWN-2666&lt;/a&gt;) the intricacies of IPv6 in Wifi networks, and how to optimize IPv6 for these networks. He was also a great inspiration for me when setting up the &lt;a href=&#34;https://www.troopers.de/media/filer_public/22/9d/229d97ec-f2de-4dac-a533-6651a493f231/troopers14-case_study-building_a_secure_ipv6_guest_wifi_network-christopher_werny.pdf&#34;&gt;Troopers Wifi network&lt;/a&gt; a couple of weeks later. Thank You!&lt;/p&gt;</description>
    </item>
    <item>
      <title>Cisco Cloud Services Router 1000V and the Virtual Matryoshka</title>
      <link>https://insinuator.net/2014/07/cisco-cloud-services-router-1000v-and-the-virtual-matryoshka/</link>
      <pubDate>Mon, 28 Jul 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/07/cisco-cloud-services-router-1000v-and-the-virtual-matryoshka/</guid>
      <description>&lt;p&gt;Recently we started playing around with Cisco’s virtual router, the CSR 1000V, while doing some protocol analysis. We found Cisco offering an BIN file for download (alternatively there is an ISO file which contains a GRUB boot loader and the BIN file, or an OVA file which contains a virtual machine description and the ISO file) and file(1) identifies it as DOS executable:&lt;/p&gt;&#xA;&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ file csr1000v-universalk9.03.12.00.S.154-2.S-std.SPA.bin &#xA;    csr1000v-universalk9.03.12.00.S.154-2.S-std.SPA.bin: DOS executable (COM)&lt;/code&gt;&lt;/pre&gt;&#xA;&lt;p&gt;We didn’t manage to get the file running, neither in a (Free-)DOS environment, nor in a wine virtual DOS environment, except using the boot loader from the ISO file. So we became curious as for the structure and ingredients of the file.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Fresh Meat From the Coding Front</title>
      <link>https://insinuator.net/2014/02/fresh-meat-from-the-coding-front/</link>
      <pubDate>Thu, 20 Feb 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/02/fresh-meat-from-the-coding-front/</guid>
      <description>&lt;p&gt;Within the last months I had some time to work on my code and today I’m releasing some of that: a new version of dizzy as well as two new loki modules.&lt;/p&gt;&#xA;&lt;h2 id=&#34;new-version-of-dizzy&#34;&gt;New version of dizzy:&lt;/h2&gt;&#xA;&lt;p&gt;Download version 0.8.2 &lt;a href=&#34;http://c0decafe.de/tools/dizzy-0.8.2.tar.bz2&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;h3 id=&#34;usb-target-support&#34;&gt;USB target support&lt;/h3&gt;&#xA;&lt;p&gt;Dizzy is able to use neighbor travis’ &lt;a href=&#34;http://goodfet.sourceforge.net/hardware/facedancer21/&#34; title=&#34;facedancer&#34;&gt;facedancer&lt;/a&gt; to emulate a client device. Two fuzzing modes are available for USB descriptor fuzzing and USB endpoint fuzzing.&lt;/p&gt;&#xA;&lt;p&gt;Here is an example cmd to start usb configuration descriptor fuzzing:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Configuring IPv6 Snooping and DHCPv6 Guard on Cisco IOS</title>
      <link>https://insinuator.net/2014/01/configuring-ipv6-snooping-and-dhcpv6-guard-on-cisco-ios/</link>
      <pubDate>Thu, 30 Jan 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/01/configuring-ipv6-snooping-and-dhcpv6-guard-on-cisco-ios/</guid>
      <description>&lt;p&gt;Hi everyone,&lt;/p&gt;&#xA;&lt;p&gt;Some of you may already know (the ones who are following Enno on &lt;a href=&#34;https://twitter.com/Enno_Insinuator&#34;&gt;Twitter&lt;/a&gt;) that Enno and I had our lab day in preparation for the &lt;a href=&#34;https://www.troopers.de/troopers14/troopers14-ipv6-security-summit-2014/index.html&#34;&gt;IPv6 Security Summit&lt;/a&gt; at &lt;a href=&#34;https://www.troopers.de&#34;&gt;Troopers&lt;/a&gt;.  We had a brand new and shiny Cat4948E as our lab device to do some testing of the current generation of Cisco’s IPv6 First Hop Security (FHS) mechanisms. The Catalyst was running the latest image available (15.1(2)SG3).&lt;/p&gt;&#xA;&lt;p&gt;In this small blog post, we will take a look at the configuration and behavior of IPv6 Snooping and DHCPv6 Guard. So let’s start with IPv6 Snooping:&lt;/p&gt;</description>
    </item>
    <item>
      <title>A Word on Cisco Jabber</title>
      <link>https://insinuator.net/2013/04/a-word-on-cisco-jabber/</link>
      <pubDate>Wed, 03 Apr 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/04/a-word-on-cisco-jabber/</guid>
      <description>&lt;p&gt;Recently we took a look on Ciscos XMPP client, called Cisco Jabber. The Client is used in combination with Ciscos Unified Communication Server (CUCM) and Ciscos Unified Presence Server (CUPS). Only the latter one is used for XMPP communication.&lt;/p&gt;&#xA;&lt;p&gt;We built a small lab setup with this components (CUCM, CUPS and the Win7 Client) and watched the client working.&lt;/p&gt;&#xA;&lt;p&gt;First the client connects to a web service at https://CUPS:8443/EPASSoap/service/v80. We intercepted this connection with the Burp Proxy and had no problems getting into the SSL. Inside we found a SOAP request containing the users authentication credentials and a SOAP response with a onetime password, which is used for authentication in the XMPP stream later on. Phew, the users credentials _and_ unlimited onetime passwords _that_ easy? Thanks Cisco!&lt;/p&gt;</description>
    </item>
    <item>
      <title>All Your Calls Are Still Belong to Us – continued</title>
      <link>https://insinuator.net/2013/01/all-your-calls-are-still-belong-to-us-continued/</link>
      <pubDate>Thu, 03 Jan 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/01/all-your-calls-are-still-belong-to-us-continued/</guid>
      <description>&lt;p&gt;Hi again and a happy new year 2013!&lt;/p&gt;&#xA;&lt;p&gt;Lets continue were I left you the last time.&lt;/p&gt;&#xA;&lt;h2 id=&#34;the-ctl&#34;&gt;The CTL&lt;/h2&gt;&#xA;&lt;p&gt;The CTL is basically a binary TLV file with 1 byte type, followed by 2 bytes length and finally the data. But as this is far to easy, some special fields omit the length field and just place the data after the type (I guess those are fields with a fixed length). Here is an example CTL file:&lt;/p&gt;</description>
    </item>
    <item>
      <title>All Your Calls Are Still Belong to Us – aka. Hacking Cisco high secure Enterprise VoIP Solution</title>
      <link>https://insinuator.net/2012/12/all-your-calls-are-still-belong-to-us-aka.-hacking-cisco-high-secure-enterprise-voip-solution/</link>
      <pubDate>Thu, 27 Dec 2012 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2012/12/all-your-calls-are-still-belong-to-us-aka.-hacking-cisco-high-secure-enterprise-voip-solution/</guid>
      <description>&lt;p&gt;Some of you may have heard the topic before, as we have spoken about on this years &lt;a href=&#34;http://www.youtube.com/watch?v=hWe5zGfsN0g&#34;&gt;BlackHat Europe&lt;/a&gt;, &lt;a href=&#34;https://www.troopers.de/archives/troopers12/agenda12/troopers12-protecting-voice-over-ip-in-2012/index.html&#34;&gt;TROOPERS12&lt;/a&gt;  and &lt;a href=&#34;http://www.ustream.tv/recorded/21808461&#34;&gt;HES12&lt;/a&gt;, so this is nothing completely new, but as we’re done with responsible disclosure (finally (-; )  and all the stuff should be fixed, we’re going to publish the code that brought us there. I will split the topic into two blog posts, this one will wrap up the setup, used components and protocols, the next one [tbd. till EOY, hopefully] will get into detail on the tools and techniques we used to break the enterprise grade security.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Groundhog Day: Don’t Pay Money for Some Else’s Calls, Still</title>
      <link>https://insinuator.net/2012/02/groundhog-day-dont-pay-money-for-some-elses-calls-still/</link>
      <pubDate>Fri, 24 Feb 2012 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2012/02/groundhog-day-dont-pay-money-for-some-elses-calls-still/</guid>
      <description>&lt;p&gt;Hi everyone,&lt;br&gt;&#xA;it’s me again with another story of a toll fraud incident at one of our customers (not the same as &lt;a href=&#34;http://www.insinuator.net/2012/02/dont-pay-money-for-someone-elses-calls-again/&#34; title=&#34;Don’t Pay Money for Someone Else’s Calls, Again&#34;&gt;the last time&lt;/a&gt; of course ;-)).&lt;br&gt;&#xA;The story began basically like the last one: We received a call with an urgent request to help investigating a toll fraud issue. Like the last time I visited the site in order to get an idea on what was going on exactly. The customer has a VoIP deployment consisting of the whole UC Suite Cisco offers: Call Manager, Unity Connection for the voice mailboxes, Cisco based Voice-Gateways and of course, IP phones.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Don’t Pay Money for Someone Else’s Calls, Again</title>
      <link>https://insinuator.net/2012/02/dont-pay-money-for-someone-elses-calls-again/</link>
      <pubDate>Thu, 02 Feb 2012 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2012/02/dont-pay-money-for-someone-elses-calls-again/</guid>
      <description>&lt;p&gt;One of our customers called us recently and asked for some support in investigating a toll fraud issue they encountered in one of their sites. Their telecommunications provider had contacted them informing them that they had accumulated a bill of 30.000€ over the last ten days.&lt;/p&gt;&#xA;&lt;p&gt;Without knowing anything more specific, I drove to the affected site to get the whole picture.&lt;/p&gt;&#xA;&lt;p&gt;They have a VoIP deployment based on Cisco Unified Communications Manager (CUCM, aka Call Manager) as Call Agent. The CUCM is connected via a H.323 trunk to a Cisco 2911 ISR G2 which is acting as a voice gateway. The ISR has a primary rate ISDN (PRI) Interface which is connected to the PBX of the telco. Furthermore they use a feature called Direct-inward Dial (DID) or Direct Dial-in (DDI) which is offered by Telco’s to enable calling parties to dial directly to an extension on a PBX or voice gateway.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
