# MediaChunks

chunk_id: 153_chunk_48
chunk_text:
top, there's that black box. 1838.32s - 1840.32s | That's the laser driver. 1840.32s - 1842.32s | There's also the RF mixer built 1842.32s - 1844.32s | into that. I use a collimating lens. 1844.32s - 1846.32s | So what collimation means is 1846.32s - 1848.32s | collimation means it just takes light and 1848.32s - 1850.32s | tries to make it into a single dot. 1850.32s - 1852.32s | Or a straight... 1852.32s - 1854.32s | If you take a flashlight, you typically have 1854.32s - 1856.32s | an unfocused beam of light. A collimated 1856.32s - 1858.32s | beam is a beam that does not focus 1858.32s - 1860.32s | or defocus. I used to think a laser, 1860.32s - 1862.32s | what made a laser a laser 1862.32s - 1864.32s | was that it was collimated, that it was a straight line. 1864.32s - 1866.32s | And that's not true. It's not 1866.32s - 1868.32s | collimation. What makes a laser 1868.32s - 1870.32s | a laser is that it's coherent. And all 1870.32s - 1872.32s | that means is that the phase of light coming out 1872.32s - 1874.32s | is always the same. It always starts at the same 1874.32s - 1876.32s | place. It's not important for this attack. 1876.32s - 1878.32s | Just something I thought that was interesting for 1878.32s - 1880.32s | me to understand what a laser 1880.32s - 1882.32s | is. The flexor, that just lets 1882.32s - 1884.32s | us actually direct 1884.32s - 1886.32s | the light up and down very easily. 1886.32s - 1888.32s | A shutter is to really tighten our 1888.32s - 1890.32s | beam. So even though we have a collimation 1890.32s - 1892.32s | and we're collimating this laser beam, we want 1892.32s - 1894.32s | to get a really tight beam. So a shutter just 1894.32s - 1896.32s | lets us close that even further. 1896.32s - 1898.32s | And behind the lens, there's 1898.32s - 1900.32s | a laser diode. And all of these you can 1900.32s - 1902.32s | buy separately. And the nice thing is that with a laser 1902.32s - 1904.32s | diode, I can use a red light normally 1904.32s - 1906.32s | when testing, but then I can move to 1906.32s - 1908.32s | the infrared where we don't see it. 1908.32s - 1910.32s |


chunk_id: 153_chunk_49
chunk_text:
starts at the same 1874.32s - 1876.32s | place. It's not important for this attack. 1876.32s - 1878.32s | Just something I thought that was interesting for 1878.32s - 1880.32s | me to understand what a laser 1880.32s - 1882.32s | is. The flexor, that just lets 1882.32s - 1884.32s | us actually direct 1884.32s - 1886.32s | the light up and down very easily. 1886.32s - 1888.32s | A shutter is to really tighten our 1888.32s - 1890.32s | beam. So even though we have a collimation 1890.32s - 1892.32s | and we're collimating this laser beam, we want 1892.32s - 1894.32s | to get a really tight beam. So a shutter just 1894.32s - 1896.32s | lets us close that even further. 1896.32s - 1898.32s | And behind the lens, there's 1898.32s - 1900.32s | a laser diode. And all of these you can 1900.32s - 1902.32s | buy separately. And the nice thing is that with a laser 1902.32s - 1904.32s | diode, I can use a red light normally 1904.32s - 1906.32s | when testing, but then I can move to 1906.32s - 1908.32s | the infrared where we don't see it. 1908.32s - 1910.32s | So these are the 1910.32s - 1912.32s | actual components I'm using. 1912.32s - 1914.32s | The obligatory turn on the fog 1914.32s - 1916.32s | and check out the cool red laser 1916.32s - 1918.32s | beam. 1918.32s - 1920.32s | Then we want to actually receive that 1920.32s - 1922.32s | information. So how do we receive it? The typical 1922.32s - 1924.32s | setup is we have a photo diode and a sound card. 1924.32s - 1926.32s | But what we're doing is we're 1926.32s - 1928.32s | modulating. So with a signal generator, we start 1928.32s - 1930.32s | modulating this thing at hundreds of 1930.32s - 1932.32s | thousands of times 1932.32s - 1934.32s | per second. So the sound, 1934.32s - 1936.32s | humans can hear between 20 hertz and 20 1936.32s - 1938.32s | kilohertz. So I want that sound. 1938.32s - 1940.32s | But I want 1940.32s - 1942.32s | to then get away from those low frequencies 1942.32s - 1944.32s | because there's so much electromagnetism 1944.32s - 1946.32s | at those frequencies that it's 1946.32s - 1948.32s | disrupting the signal I'm getting. 1948.32s - 1950.32s | Because we're getting


chunk_id: 153_chunk_50
chunk_text:
So these are the 1910.32s - 1912.32s | actual components I'm using. 1912.32s - 1914.32s | The obligatory turn on the fog 1914.32s - 1916.32s | and check out the cool red laser 1916.32s - 1918.32s | beam. 1918.32s - 1920.32s | Then we want to actually receive that 1920.32s - 1922.32s | information. So how do we receive it? The typical 1922.32s - 1924.32s | setup is we have a photo diode and a sound card. 1924.32s - 1926.32s | But what we're doing is we're 1926.32s - 1928.32s | modulating. So with a signal generator, we start 1928.32s - 1930.32s | modulating this thing at hundreds of 1930.32s - 1932.32s | thousands of times 1932.32s - 1934.32s | per second. So the sound, 1934.32s - 1936.32s | humans can hear between 20 hertz and 20 1936.32s - 1938.32s | kilohertz. So I want that sound. 1938.32s - 1940.32s | But I want 1940.32s - 1942.32s | to then get away from those low frequencies 1942.32s - 1944.32s | because there's so much electromagnetism 1944.32s - 1946.32s | at those frequencies that it's 1946.32s - 1948.32s | disrupting the signal I'm getting. 1948.32s - 1950.32s | Because we're getting very little light back from 1950.32s - 1952.32s | the laser that's reflecting 1952.32s - 1954.32s | off a window or off 1954.32s - 1956.32s | a computer. 1956.32s - 1958.32s | So first, and the sound 1958.32s - 1960.32s | card can only listen to, say, 48 1960.32s - 1962.32s | kilohertz or 192 kilohertz. 1962.32s - 1964.32s | To get away from all that sound, 1964.32s - 1966.32s | we modulate the laser. We turn the laser 1966.32s - 1968.32s | on and off 400,000 times per second 1968.32s - 1970.32s | so that we're at 400 kilohertz. 1970.32s - 1972.32s | So we need something other than a sound card 1972.32s - 1974.32s | that can actually accept this. 1974.32s - 1976.32s | So first, I thought, okay, 1976.32s - 1978.32s | well, I can use a bunch of analog components. 1978.32s - 1980.32s | The problem with analog components and electronic circuitry 1980.32s - 1982.32s | is it's a huge pain. So as you're 1982.32s - 1984.32s | putting these little components on a circuit board, for one, 1984.32s - 1986.32s | you're dealing with high frequencies. So as you're 1986.32s - 1988.32s | trying to


chunk_id: 153_chunk_51
chunk_text:
very little light back from 1950.32s - 1952.32s | the laser that's reflecting 1952.32s - 1954.32s | off a window or off 1954.32s - 1956.32s | a computer. 1956.32s - 1958.32s | So first, and the sound 1958.32s - 1960.32s | card can only listen to, say, 48 1960.32s - 1962.32s | kilohertz or 192 kilohertz. 1962.32s - 1964.32s | To get away from all that sound, 1964.32s - 1966.32s | we modulate the laser. We turn the laser 1966.32s - 1968.32s | on and off 400,000 times per second 1968.32s - 1970.32s | so that we're at 400 kilohertz. 1970.32s - 1972.32s | So we need something other than a sound card 1972.32s - 1974.32s | that can actually accept this. 1974.32s - 1976.32s | So first, I thought, okay, 1976.32s - 1978.32s | well, I can use a bunch of analog components. 1978.32s - 1980.32s | The problem with analog components and electronic circuitry 1980.32s - 1982.32s | is it's a huge pain. So as you're 1982.32s - 1984.32s | putting these little components on a circuit board, for one, 1984.32s - 1986.32s | you're dealing with high frequencies. So as you're 1986.32s - 1988.32s | trying to change, as you're trying different 1988.32s - 1990.32s | filters and amplifiers, all of this 1990.32s - 1992.32s | is very difficult. And think, man, 1992.32s - 1994.32s | I really wish I could use GNU Radio. 1994.32s - 1996.32s | GNU Radio is open source signal processing software. 1996.32s - 1998.32s | And with that, then I can drag and drop 1998.32s - 2000.32s | and life is just great. I can, like, sit back 2000.32s - 2002.32s | in my chair, drink some caffeine, 2002.32s - 2004.32s | and just play with these little blocks 2004.32s - 2006.32s | and just test different things to see what works. 2006.32s - 2008.32s | The problem, the challenge 2008.32s - 2010.32s | with using GNU Radio is that I need, then, 2010.32s - 2012.32s | a software-defined radio to pull that data in. 2012.32s - 2014.32s | The sound card won't work because I need something 2014.32s - 2016.32s | that can listen to not only 400 kilohertz, 2016.32s - 2018.32s | I need to go at least double that. 2018.32s - 2020.32s | It's called Nyquist theorem. I need to go to at least 2020.32s - 2022.32s | 800


chunk_id: 153_chunk_52
chunk_text:
change, as you're trying different 1988.32s - 1990.32s | filters and amplifiers, all of this 1990.32s - 1992.32s | is very difficult. And think, man, 1992.32s - 1994.32s | I really wish I could use GNU Radio. 1994.32s - 1996.32s | GNU Radio is open source signal processing software. 1996.32s - 1998.32s | And with that, then I can drag and drop 1998.32s - 2000.32s | and life is just great. I can, like, sit back 2000.32s - 2002.32s | in my chair, drink some caffeine, 2002.32s - 2004.32s | and just play with these little blocks 2004.32s - 2006.32s | and just test different things to see what works. 2006.32s - 2008.32s | The problem, the challenge 2008.32s - 2010.32s | with using GNU Radio is that I need, then, 2010.32s - 2012.32s | a software-defined radio to pull that data in. 2012.32s - 2014.32s | The sound card won't work because I need something 2014.32s - 2016.32s | that can listen to not only 400 kilohertz, 2016.32s - 2018.32s | I need to go at least double that. 2018.32s - 2020.32s | It's called Nyquist theorem. I need to go to at least 2020.32s - 2022.32s | 800 kilohertz of a sample rate, 2022.32s - 2024.32s | how fast I'm listening to that data. 2024.32s - 2026.32s | And I can use a software-defined radio, 2026.32s - 2028.32s | but software-defined radios don't ever go that low. 2028.32s - 2030.32s | So, the RTL-SDR, 2030.32s - 2032.32s | I'm not sure where that goes, maybe 100 megahertz. 2032.32s - 2034.32s | Excuse me. 2034.32s - 2036.32s | The HAKR-F, amazing. I love the HAKR-F, 2036.32s - 2038.32s | but the minimum frequency 2038.32s - 2040.32s | it can listen to is 2040.32s - 2042.32s | at about, let's see, 2042.32s - 2044.32s | 1 megahertz, and we're at 400 kilohertz. 2044.32s - 2046.32s | The USRP, 2046.32s - 2048.32s | it also has a very low bit rate, 2048.32s - 2050.32s | so it's about, the analog-to-digital converter 2050.32s - 2052.32s | has an 8-bit sample rate. 2052.32s - 2054.32s | And we want higher samples. We want higher resolution 2054.32s - 2056.32s | so we can extract more signal. 2056.32s - 2058.32s | The USRP-B210 2058.32s - 2060.32s | has 12 bits, 2060.32s - 2062.32s | which is good, but it requires 2062.32s - 2064.32s | 70


chunk_id: 153_chunk_53
chunk_text:
kilohertz of a sample rate, 2022.32s - 2024.32s | how fast I'm listening to that data. 2024.32s - 2026.32s | And I can use a software-defined radio, 2026.32s - 2028.32s | but software-defined radios don't ever go that low. 2028.32s - 2030.32s | So, the RTL-SDR, 2030.32s - 2032.32s | I'm not sure where that goes, maybe 100 megahertz. 2032.32s - 2034.32s | Excuse me. 2034.32s - 2036.32s | The HAKR-F, amazing. I love the HAKR-F, 2036.32s - 2038.32s | but the minimum frequency 2038.32s - 2040.32s | it can listen to is 2040.32s - 2042.32s | at about, let's see, 2042.32s - 2044.32s | 1 megahertz, and we're at 400 kilohertz. 2044.32s - 2046.32s | The USRP, 2046.32s - 2048.32s | it also has a very low bit rate, 2048.32s - 2050.32s | so it's about, the analog-to-digital converter 2050.32s - 2052.32s | has an 8-bit sample rate. 2052.32s - 2054.32s | And we want higher samples. We want higher resolution 2054.32s - 2056.32s | so we can extract more signal. 2056.32s - 2058.32s | The USRP-B210 2058.32s - 2060.32s | has 12 bits, 2060.32s - 2062.32s | which is good, but it requires 2062.32s - 2064.32s | 70 megahertz, and we're just down at 2064.32s - 2066.32s | 400 kilohertz. 2066.32s - 2068.32s | But, then I started looking, and there was something 2068.32s - 2070.32s | called an up-converter that we can get. 2070.32s - 2072.32s | So, the up-converter actually adds 125 megahertz 2072.32s - 2074.32s | to a signal, as long as it's at least 2074.32s - 2076.32s | 100 kilohertz. So, we're at 400 kilohertz. 2076.32s - 2078.32s | So, ultimately, what I use is a 2078.32s - 2080.32s | photodiode. I go into an amplifier. 2080.32s - 2082.32s | That amplifier then goes into a 2082.32s - 2084.32s | Hammond-up V2. 2084.32s - 2086.32s | That adds 125 megahertz to our 400 2086.32s - 2088.32s | kilohertz, so now we're at 125.4 2088.32s - 2090.32s | megahertz. Then I go into 2090.32s - 2092.32s | the USRP. Now 2092.32s - 2094.32s | that can go into my computer. Here's the 2094.32s - 2096.32s | physical setup. This is the receiving 2096.32s - 2098.32s | side. Lens, to capture 2098.32s - 2100.32s | light, into a photodiode, into the amp, 2100.32s - 2102.32s | into the USRP-B210, 2102.32s - 2104.32s | into the computer.


chunk_id: 153_chunk_54
chunk_text:
megahertz, and we're just down at 2064.32s - 2066.32s | 400 kilohertz. 2066.32s - 2068.32s | But, then I started looking, and there was something 2068.32s - 2070.32s | called an up-converter that we can get. 2070.32s - 2072.32s | So, the up-converter actually adds 125 megahertz 2072.32s - 2074.32s | to a signal, as long as it's at least 2074.32s - 2076.32s | 100 kilohertz. So, we're at 400 kilohertz. 2076.32s - 2078.32s | So, ultimately, what I use is a 2078.32s - 2080.32s | photodiode. I go into an amplifier. 2080.32s - 2082.32s | That amplifier then goes into a 2082.32s - 2084.32s | Hammond-up V2. 2084.32s - 2086.32s | That adds 125 megahertz to our 400 2086.32s - 2088.32s | kilohertz, so now we're at 125.4 2088.32s - 2090.32s | megahertz. Then I go into 2090.32s - 2092.32s | the USRP. Now 2092.32s - 2094.32s | that can go into my computer. Here's the 2094.32s - 2096.32s | physical setup. This is the receiving 2096.32s - 2098.32s | side. Lens, to capture 2098.32s - 2100.32s | light, into a photodiode, into the amp, 2100.32s - 2102.32s | into the USRP-B210, 2102.32s - 2104.32s | into the computer. 2104.32s - 2106.32s | If you see this outside of your window, 2106.32s - 2108.32s | it is super sketchy. 2108.32s - 2110.32s | Maybe, like, shut the blinds, 2110.32s - 2112.32s | call the police. 2112.32s - 2114.32s | But, once you actually point this laser 2114.32s - 2116.32s | at a computer, now there 2116.32s - 2118.32s | are some big challenges here. Actually, 2118.32s - 2120.32s | performing alignment is very, very, 2120.32s - 2122.32s | very challenging. Getting sound 2122.32s - 2124.32s | is actually not so challenging, because 2124.32s - 2126.32s | our ears, we're pretty good at listening to 2126.32s - 2128.32s | just one kilohertz of sound. Although 2128.32s - 2130.32s | we can hear up to 20 kilohertz, just 2130.32s - 2132.32s | one kilohertz, we can usually make out 2132.32s - 2134.32s | what someone is saying. 2134.32s - 2136.32s | Getting above, I'd say, 2136.32s - 2138.32s | four kilo, like, the best I was able to get 2138.32s - 2140.32s | above was four to five 2140.32s - 2142.32s | kilohertz of sound. And I found 2142.32s - 2144.32s | for keystroke extraction, I needed to get to 2144.32s


chunk_id: 153_chunk_55
chunk_text:
2104.32s - 2106.32s | If you see this outside of your window, 2106.32s - 2108.32s | it is super sketchy. 2108.32s - 2110.32s | Maybe, like, shut the blinds, 2110.32s - 2112.32s | call the police. 2112.32s - 2114.32s | But, once you actually point this laser 2114.32s - 2116.32s | at a computer, now there 2116.32s - 2118.32s | are some big challenges here. Actually, 2118.32s - 2120.32s | performing alignment is very, very, 2120.32s - 2122.32s | very challenging. Getting sound 2122.32s - 2124.32s | is actually not so challenging, because 2124.32s - 2126.32s | our ears, we're pretty good at listening to 2126.32s - 2128.32s | just one kilohertz of sound. Although 2128.32s - 2130.32s | we can hear up to 20 kilohertz, just 2130.32s - 2132.32s | one kilohertz, we can usually make out 2132.32s - 2134.32s | what someone is saying. 2134.32s - 2136.32s | Getting above, I'd say, 2136.32s - 2138.32s | four kilo, like, the best I was able to get 2138.32s - 2140.32s | above was four to five 2140.32s - 2142.32s | kilohertz of sound. And I found 2142.32s - 2144.32s | for keystroke extraction, I needed to get to 2144.32s - 2146.32s | three kilohertz. If I got to 2.5 2146.32s - 2148.32s | kilohertz, I could not convert anything to keystrokes. 2148.32s - 2150.32s | If I got to three kilohertz, 2150.32s - 2152.32s | I could start converting to keystrokes. 2152.32s - 2154.32s | Here's the hardware on the 2154.32s - 2156.32s | transmit side, just the actual components, 2156.32s - 2158.32s | just so you know. 2158.32s - 2160.32s | Here is the RX side. 2160.32s - 2162.32s | This will all be online, so if you want to know 2162.32s - 2164.32s | the exact components I used. And one 2164.32s - 2166.32s | of the other improvements that I wanted to make here, 2166.32s - 2168.32s | for one, now that we're getting into the RF 2168.32s - 2170.32s | domain, we get away from all this noise. 2170.32s - 2172.32s | And we can actually filter out that noise. 2172.32s - 2174.32s | Another cool thing is I wanted to do this in 2174.32s - 2176.32s | infrared. I don't want someone seeing 2176.32s - 2178.32s | me standing outside pointing a laser into 2178.32s - 2180.32s | their window. That's just too obvious.


chunk_id: 153_chunk_56
chunk_text:
- 2146.32s | three kilohertz. If I got to 2.5 2146.32s - 2148.32s | kilohertz, I could not convert anything to keystrokes. 2148.32s - 2150.32s | If I got to three kilohertz, 2150.32s - 2152.32s | I could start converting to keystrokes. 2152.32s - 2154.32s | Here's the hardware on the 2154.32s - 2156.32s | transmit side, just the actual components, 2156.32s - 2158.32s | just so you know. 2158.32s - 2160.32s | Here is the RX side. 2160.32s - 2162.32s | This will all be online, so if you want to know 2162.32s - 2164.32s | the exact components I used. And one 2164.32s - 2166.32s | of the other improvements that I wanted to make here, 2166.32s - 2168.32s | for one, now that we're getting into the RF 2168.32s - 2170.32s | domain, we get away from all this noise. 2170.32s - 2172.32s | And we can actually filter out that noise. 2172.32s - 2174.32s | Another cool thing is I wanted to do this in 2174.32s - 2176.32s | infrared. I don't want someone seeing 2176.32s - 2178.32s | me standing outside pointing a laser into 2178.32s - 2180.32s | their window. That's just too obvious. 2180.32s - 2182.32s | So I got an infrared 2182.32s - 2184.32s | laser diode. And how do I 2184.32s - 2186.32s | actually align to the infrared? Because I can't see 2186.32s - 2188.32s | it. So I got this infrared camera. 2188.32s - 2190.32s | It's the X-Nite USB 2S 2190.32s - 2192.32s | M. It's around $120. It's 2192.32s - 2194.32s | very cool. It's actually very exciting to be able to see 2194.32s - 2196.32s | infrared just around 2196.32s - 2198.32s | you. And it's 2198.32s - 2200.32s | maybe hard to tell, but I have the laser 2200.32s - 2202.32s | diode going and just 2202.32s - 2204.32s | hitting a white square. 2204.32s - 2206.32s | And you can't see it on my camera, my phone 2206.32s - 2208.32s | camera, because my phone camera also can't see 2208.32s - 2210.32s | IR. And my eyes can't see IR. 2210.32s - 2212.32s | And then here, just so we can see, 2212.32s - 2214.32s | I made a recording with that 2214.32s - 2216.32s | camera pointing the laser at 2216.32s - 2218.32s | my laptop. And you can kind of see the


chunk_id: 153_chunk_57
chunk_text:
2180.32s - 2182.32s | So I got an infrared 2182.32s - 2184.32s | laser diode. And how do I 2184.32s - 2186.32s | actually align to the infrared? Because I can't see 2186.32s - 2188.32s | it. So I got this infrared camera. 2188.32s - 2190.32s | It's the X-Nite USB 2S 2190.32s - 2192.32s | M. It's around $120. It's 2192.32s - 2194.32s | very cool. It's actually very exciting to be able to see 2194.32s - 2196.32s | infrared just around 2196.32s - 2198.32s | you. And it's 2198.32s - 2200.32s | maybe hard to tell, but I have the laser 2200.32s - 2202.32s | diode going and just 2202.32s - 2204.32s | hitting a white square. 2204.32s - 2206.32s | And you can't see it on my camera, my phone 2206.32s - 2208.32s | camera, because my phone camera also can't see 2208.32s - 2210.32s | IR. And my eyes can't see IR. 2210.32s - 2212.32s | And then here, just so we can see, 2212.32s - 2214.32s | I made a recording with that 2214.32s - 2216.32s | camera pointing the laser at 2216.32s - 2218.32s | my laptop. And you can kind of see the reflection. 2218.32s - 2220.32s | I'm sitting below the 2220.32s - 2222.32s | laptop with a steam iron. 2222.32s - 2224.32s | And I'm just like steaming my 2224.32s - 2226.32s | laptop until, I think it was 2226.32s - 2228.32s | the first time I ever used a steam iron, 2228.32s - 2230.32s | until boiling water boiled 2230.32s - 2232.32s | down on me. And I was like, ah. So I got maybe 2232.32s - 2234.32s | a few seconds before I burnt myself. 2234.32s - 2236.32s | But while I was doing this testing, I also saw 2236.32s - 2238.32s | something else interesting. I pulled out my 2238.32s - 2240.32s | phone, and I wanted to change 2240.32s - 2242.32s | the song, because Spotify was playing. 2242.32s - 2244.32s | And when I unlocked my phone, 2244.32s - 2246.32s | I saw these dots, not on the 2246.32s - 2248.32s | wall, but I saw it on the IR 2248.32s - 2250.32s | recording. 2250.32s - 2252.32s | And I'm like, wait, what's happening? 2252.32s - 2254.32s | When my phone, when I pulled out my phone, 2254.32s - 2256.32s | I realized, this is


chunk_id: 153_chunk_58
chunk_text:
reflection. 2218.32s - 2220.32s | I'm sitting below the 2220.32s - 2222.32s | laptop with a steam iron. 2222.32s - 2224.32s | And I'm just like steaming my 2224.32s - 2226.32s | laptop until, I think it was 2226.32s - 2228.32s | the first time I ever used a steam iron, 2228.32s - 2230.32s | until boiling water boiled 2230.32s - 2232.32s | down on me. And I was like, ah. So I got maybe 2232.32s - 2234.32s | a few seconds before I burnt myself. 2234.32s - 2236.32s | But while I was doing this testing, I also saw 2236.32s - 2238.32s | something else interesting. I pulled out my 2238.32s - 2240.32s | phone, and I wanted to change 2240.32s - 2242.32s | the song, because Spotify was playing. 2242.32s - 2244.32s | And when I unlocked my phone, 2244.32s - 2246.32s | I saw these dots, not on the 2246.32s - 2248.32s | wall, but I saw it on the IR 2248.32s - 2250.32s | recording. 2250.32s - 2252.32s | And I'm like, wait, what's happening? 2252.32s - 2254.32s | When my phone, when I pulled out my phone, 2254.32s - 2256.32s | I realized, this is 2256.32s - 2258.32s | LiDAR. So my phone is using 2258.32s - 2260.32s | LiDAR on the back. I'm like, why? Why is it 2260.32s - 2262.32s | projecting all of these infrared dots that we cannot 2262.32s - 2264.32s | see with our eyes? And it only happens when 2264.32s - 2266.32s | the camera app is open. 2266.32s - 2268.32s | And it's actually very cool. It's figuring out 2268.32s - 2270.32s | how far is the object, 2270.32s - 2272.32s | how far is it? And if it's 2272.32s - 2274.32s | close, it's going to use the close camera. 2274.32s - 2276.32s | You have a bunch of cameras on the back of your phone. 2276.32s - 2278.32s | So it's deciding which camera to 2278.32s - 2280.32s | use. So when you go closer to an object, 2280.32s - 2282.32s | it will automatically switch to a different camera. 2282.32s - 2284.32s | And I thought, that's really cool, but 2284.32s - 2286.32s | what if I can actually measure this? 2286.32s - 2288.32s | So I put this in my spectrometer just to see 2288.32s - 2290.32s | what wavelength of infrared 2290.32s -


chunk_id: 153_chunk_59
chunk_text:
2256.32s - 2258.32s | LiDAR. So my phone is using 2258.32s - 2260.32s | LiDAR on the back. I'm like, why? Why is it 2260.32s - 2262.32s | projecting all of these infrared dots that we cannot 2262.32s - 2264.32s | see with our eyes? And it only happens when 2264.32s - 2266.32s | the camera app is open. 2266.32s - 2268.32s | And it's actually very cool. It's figuring out 2268.32s - 2270.32s | how far is the object, 2270.32s - 2272.32s | how far is it? And if it's 2272.32s - 2274.32s | close, it's going to use the close camera. 2274.32s - 2276.32s | You have a bunch of cameras on the back of your phone. 2276.32s - 2278.32s | So it's deciding which camera to 2278.32s - 2280.32s | use. So when you go closer to an object, 2280.32s - 2282.32s | it will automatically switch to a different camera. 2282.32s - 2284.32s | And I thought, that's really cool, but 2284.32s - 2286.32s | what if I can actually measure this? 2286.32s - 2288.32s | So I put this in my spectrometer just to see 2288.32s - 2290.32s | what wavelength of infrared 2290.32s - 2292.32s | this was, because now we can just monitor 2292.32s - 2294.32s | for this wavelength of light. 2294.32s - 2296.32s | So imagine you have a little device with a photo 2296.32s - 2298.32s | diode, a photo sensor 2298.32s - 2300.32s | on you, so that whenever someone points 2300.32s - 2302.32s | their phone camera at you, you get 2302.32s - 2304.32s | a little vibration. Because you 2304.32s - 2306.32s | can just measure for that frequency of light, and for 2306.32s - 2308.32s | that on and off path. And now 2308.32s - 2310.32s | you can know when someone points their phone 2310.32s - 2312.32s | camera at you before they're even recording. 2312.32s - 2314.32s | And it only will show, 2314.32s - 2316.32s | you can see that sort of rectangle 2316.32s - 2318.32s | that's exactly the same path. 2318.32s - 2320.32s | That means I could just 2320.32s - 2322.32s | make all of you vibrate right now. 2322.32s - 2324.32s | How fun would that be? 2324.32s - 2326.32s | So, separate project. We'll do that 2326.32s - 2328.32s | another time. So there's the RF modulation. 2328.32s


chunk_id: 153_chunk_60
chunk_text:
2292.32s | this was, because now we can just monitor 2292.32s - 2294.32s | for this wavelength of light. 2294.32s - 2296.32s | So imagine you have a little device with a photo 2296.32s - 2298.32s | diode, a photo sensor 2298.32s - 2300.32s | on you, so that whenever someone points 2300.32s - 2302.32s | their phone camera at you, you get 2302.32s - 2304.32s | a little vibration. Because you 2304.32s - 2306.32s | can just measure for that frequency of light, and for 2306.32s - 2308.32s | that on and off path. And now 2308.32s - 2310.32s | you can know when someone points their phone 2310.32s - 2312.32s | camera at you before they're even recording. 2312.32s - 2314.32s | And it only will show, 2314.32s - 2316.32s | you can see that sort of rectangle 2316.32s - 2318.32s | that's exactly the same path. 2318.32s - 2320.32s | That means I could just 2320.32s - 2322.32s | make all of you vibrate right now. 2322.32s - 2324.32s | How fun would that be? 2324.32s - 2326.32s | So, separate project. We'll do that 2326.32s - 2328.32s | another time. So there's the RF modulation. 2328.32s - 2330.32s | This is the biggest improvement that I've seen 2330.32s - 2332.32s | in this laser microphone. So actually getting 2332.32s - 2334.32s | into the RF domain. 2334.32s - 2336.32s | The photo diode I used, this is the 2336.32s - 2338.32s | Spot 2D. It's pretty interesting, it actually 2338.32s - 2340.32s | has two cells. So where photo 2340.32s - 2342.32s | diodes are typically one pixel, this is really two pixels. 2342.32s - 2344.32s | The hardest challenge, the 2344.32s - 2346.32s | biggest challenge of this whole system is that you must 2346.32s - 2348.32s | get essentially to the edge of the diode. 2348.32s - 2350.32s | You don't want to get the light in the center, you want to get 2350.32s - 2352.32s | to the edge. Because as soon as the edge, 2352.32s - 2354.32s | you essentially want your light, 2354.32s - 2356.32s | your reflection to go on and off that diode. 2356.32s - 2358.32s | If you're in the center, then you're just gonna 2358.32s - 2360.32s | you're not gonna get much variation. 2360.32s - 2362.32s | But if you're at the edge, that's where you


chunk_id: 153_chunk_61
chunk_text:
- 2330.32s | This is the biggest improvement that I've seen 2330.32s - 2332.32s | in this laser microphone. So actually getting 2332.32s - 2334.32s | into the RF domain. 2334.32s - 2336.32s | The photo diode I used, this is the 2336.32s - 2338.32s | Spot 2D. It's pretty interesting, it actually 2338.32s - 2340.32s | has two cells. So where photo 2340.32s - 2342.32s | diodes are typically one pixel, this is really two pixels. 2342.32s - 2344.32s | The hardest challenge, the 2344.32s - 2346.32s | biggest challenge of this whole system is that you must 2346.32s - 2348.32s | get essentially to the edge of the diode. 2348.32s - 2350.32s | You don't want to get the light in the center, you want to get 2350.32s - 2352.32s | to the edge. Because as soon as the edge, 2352.32s - 2354.32s | you essentially want your light, 2354.32s - 2356.32s | your reflection to go on and off that diode. 2356.32s - 2358.32s | If you're in the center, then you're just gonna 2358.32s - 2360.32s | you're not gonna get much variation. 2360.32s - 2362.32s | But if you're at the edge, that's where you get all the variation. 2362.32s - 2364.32s | There I noticed there was a hair 2364.32s - 2366.32s | in their photo. Fortunately there was 2366.32s - 2368.32s | no hair in the photo diode they sent me, so I didn't have 2368.32s - 2370.32s | to send it back. And then 2370.32s - 2372.32s | the software that we use. So we use some 2372.32s - 2374.32s | awesome software. First, 2374.32s - 2377.95s | Guneo Radio. And we'll 2377.95s - 2379.95s | quickly go through the steps here, but all 2379.95s - 2381.95s | this will be online as well. 2381.95s - 2383.95s | So Guneo Radio, all the red stuff on the left, 2383.95s - 2385.95s | those are just variables. That just makes it 2385.95s - 2387.95s | easier for me to, just like in software, 2387.95s - 2389.95s | to use a single variable that will change things 2389.95s - 2391.95s | in multiple areas. The things 2391.95s - 2393.95s | circled in blue, those are just 2393.95s - 2395.95s | GUI, those are just graphical 2395.95s - 2397.95s | syncs, so we can see information. 2397.95s - 2399.95s | The heart of it, 2399.95s


chunk_id: 153_chunk_62
chunk_text:
get all the variation. 2362.32s - 2364.32s | There I noticed there was a hair 2364.32s - 2366.32s | in their photo. Fortunately there was 2366.32s - 2368.32s | no hair in the photo diode they sent me, so I didn't have 2368.32s - 2370.32s | to send it back. And then 2370.32s - 2372.32s | the software that we use. So we use some 2372.32s - 2374.32s | awesome software. First, 2374.32s - 2377.95s | Guneo Radio. And we'll 2377.95s - 2379.95s | quickly go through the steps here, but all 2379.95s - 2381.95s | this will be online as well. 2381.95s - 2383.95s | So Guneo Radio, all the red stuff on the left, 2383.95s - 2385.95s | those are just variables. That just makes it 2385.95s - 2387.95s | easier for me to, just like in software, 2387.95s - 2389.95s | to use a single variable that will change things 2389.95s - 2391.95s | in multiple areas. The things 2391.95s - 2393.95s | circled in blue, those are just 2393.95s - 2395.95s | GUI, those are just graphical 2395.95s - 2397.95s | syncs, so we can see information. 2397.95s - 2399.95s | The heart of it, 2399.95s - 2401.95s | the heart of the Guneo Radio stuff is, first 2401.95s - 2403.95s | we start with our USRP source. 2403.95s - 2405.95s | So this 2405.95s - 2407.95s | pulls in data at a sample rate of 4.8 2407.95s - 2409.95s | megahertz, or mega samples per second. 2409.95s - 2411.95s | Our center frequency is 2411.95s - 2413.95s | 125.2 megahertz. 2413.95s - 2415.95s | So 125 megahertz because of the 2415.95s - 2417.95s | RF upconverter, the Hamminup, and then 2417.95s - 2419.95s | 200 kilohertz. Now, we're 2419.95s - 2421.95s | actually modulating at 400 kilohertz, 2421.95s - 2423.95s | but we don't want to listen at 400 kilohertz because 2423.95s - 2425.95s | there's something called the DC spike. Any software 2425.95s - 2427.95s | divine radio is going to give you this giant DC 2427.95s - 2429.95s | spike, and you want to move away from that, and 2429.95s - 2431.95s | then you filter out that DC spike, and then you can 2431.95s - 2433.95s | listen to the actual data you want. 2433.95s - 2435.95s | We mentioned a couple 2435.95s - 2437.95s | different SDRs. The reason I chose


chunk_id: 153_chunk_63
chunk_text:
- 2401.95s | the heart of the Guneo Radio stuff is, first 2401.95s - 2403.95s | we start with our USRP source. 2403.95s - 2405.95s | So this 2405.95s - 2407.95s | pulls in data at a sample rate of 4.8 2407.95s - 2409.95s | megahertz, or mega samples per second. 2409.95s - 2411.95s | Our center frequency is 2411.95s - 2413.95s | 125.2 megahertz. 2413.95s - 2415.95s | So 125 megahertz because of the 2415.95s - 2417.95s | RF upconverter, the Hamminup, and then 2417.95s - 2419.95s | 200 kilohertz. Now, we're 2419.95s - 2421.95s | actually modulating at 400 kilohertz, 2421.95s - 2423.95s | but we don't want to listen at 400 kilohertz because 2423.95s - 2425.95s | there's something called the DC spike. Any software 2425.95s - 2427.95s | divine radio is going to give you this giant DC 2427.95s - 2429.95s | spike, and you want to move away from that, and 2429.95s - 2431.95s | then you filter out that DC spike, and then you can 2431.95s - 2433.95s | listen to the actual data you want. 2433.95s - 2435.95s | We mentioned a couple 2435.95s - 2437.95s | different SDRs. The reason I chose the 2437.95s - 2439.95s | B210 was because it had a high 2439.95s - 2441.95s | resolution, or bitrate, and 2441.95s - 2443.95s | it had a high sample rate. 2443.95s - 2445.95s | You can also use a Salier logic analyzer. 2445.95s - 2447.95s | I realize this is also actually a pretty nice 2447.95s - 2449.95s | 50 mega samples 2449.95s - 2451.95s | per second is also 12 bits. 2451.95s - 2453.95s | Then we go into 2453.95s - 2455.95s | a translating FIR filter. 2455.95s - 2457.95s | This is three things. First, it's a 2457.95s - 2459.95s | bandpass filter. Oh, first, it 2459.95s - 2461.95s | actually changes the frequency you're at. 2461.95s - 2463.95s | So we want to go from 2463.95s - 2465.95s | 125.2 to 2465.95s - 2467.95s | 125.4. That's where our sound is. 2467.95s - 2469.95s | So now we're centered on the sound, 2469.95s - 2471.95s | and the sound is moving up and 2471.95s - 2473.95s | down. So our signal is 2473.95s - 2475.95s | some sort of sound wave, but 2475.95s - 2477.95s | our amplitude modulated signal is at 2477.95s - 2479.95s | 400


chunk_id: 153_chunk_64
chunk_text:
the 2437.95s - 2439.95s | B210 was because it had a high 2439.95s - 2441.95s | resolution, or bitrate, and 2441.95s - 2443.95s | it had a high sample rate. 2443.95s - 2445.95s | You can also use a Salier logic analyzer. 2445.95s - 2447.95s | I realize this is also actually a pretty nice 2447.95s - 2449.95s | 50 mega samples 2449.95s - 2451.95s | per second is also 12 bits. 2451.95s - 2453.95s | Then we go into 2453.95s - 2455.95s | a translating FIR filter. 2455.95s - 2457.95s | This is three things. First, it's a 2457.95s - 2459.95s | bandpass filter. Oh, first, it 2459.95s - 2461.95s | actually changes the frequency you're at. 2461.95s - 2463.95s | So we want to go from 2463.95s - 2465.95s | 125.2 to 2465.95s - 2467.95s | 125.4. That's where our sound is. 2467.95s - 2469.95s | So now we're centered on the sound, 2469.95s - 2471.95s | and the sound is moving up and 2471.95s - 2473.95s | down. So our signal is 2473.95s - 2475.95s | some sort of sound wave, but 2475.95s - 2477.95s | our amplitude modulated signal is at 2477.95s - 2479.95s | 400 kilohertz. So it's going up and down. 2479.95s - 2481.95s | So the FIR 2481.95s - 2483.95s | filter will also then do a bandpass. 2483.95s - 2485.95s | So now we're saying, I only want what's 2485.95s - 2487.95s | around the 400 megahertz. 2487.95s - 2489.95s | Excuse me, 400 kilohertz. Everything else we can 2489.95s - 2491.95s | ignore. So we bandpass that out, and 2491.95s - 2493.95s | then we decimate. Decimate just brings 2493.95s - 2495.95s | the sample rate down to a more usable 2495.95s - 2497.95s | sample rate. Then we go into 2497.95s - 2499.95s | and we amplitude demodulate. 2499.95s - 2501.95s | So we convert the AM back 2501.95s - 2503.95s | into the actual sound. So now we 2503.95s - 2505.95s | can hear sound, and then we save the file. 2505.95s - 2507.95s | Then we use something called iZotope 2507.95s - 2509.95s | RX. This is absolutely incredible software. 2509.95s - 2511.95s | It's commercial software, but it's 2511.95s - 2513.95s | very good. It's great at spectral 2513.95s - 2515.95s | repair, and it gives you a spectrograph. So you can 2515.95s - 2517.95s | actually


chunk_id: 153_chunk_65
chunk_text:
kilohertz. So it's going up and down. 2479.95s - 2481.95s | So the FIR 2481.95s - 2483.95s | filter will also then do a bandpass. 2483.95s - 2485.95s | So now we're saying, I only want what's 2485.95s - 2487.95s | around the 400 megahertz. 2487.95s - 2489.95s | Excuse me, 400 kilohertz. Everything else we can 2489.95s - 2491.95s | ignore. So we bandpass that out, and 2491.95s - 2493.95s | then we decimate. Decimate just brings 2493.95s - 2495.95s | the sample rate down to a more usable 2495.95s - 2497.95s | sample rate. Then we go into 2497.95s - 2499.95s | and we amplitude demodulate. 2499.95s - 2501.95s | So we convert the AM back 2501.95s - 2503.95s | into the actual sound. So now we 2503.95s - 2505.95s | can hear sound, and then we save the file. 2505.95s - 2507.95s | Then we use something called iZotope 2507.95s - 2509.95s | RX. This is absolutely incredible software. 2509.95s - 2511.95s | It's commercial software, but it's 2511.95s - 2513.95s | very good. It's great at spectral 2513.95s - 2515.95s | repair, and it gives you a spectrograph. So you can 2515.95s - 2517.95s | actually see what's happening inside of your signal. 2517.95s - 2519.95s | And then you can do all sorts of things like 2519.95s - 2521.95s | de-s, de-hum, de-splosive. 2521.95s - 2523.95s | I have no idea what de-splosive is. 2523.95s - 2525.95s | But it has a lot of ways 2525.95s - 2527.95s | that you can then improve the signal. So you can 2527.95s - 2529.95s | say, hey, I want to learn this area of 2529.95s - 2531.95s | sound where there's just a lot of noise. 2531.95s - 2533.95s | Learn that, and now apply it to the rest of the signal 2533.95s - 2535.95s | and remove that noise. 2535.95s - 2537.95s | FFmpeg, just so we can actually convert some things 2537.95s - 2539.95s | around. And then KeyTap3 2539.95s - 2541.95s | is really the heart of the system for the 2541.95s - 2543.95s | keystroke extraction. We want to know what the person 2543.95s - 2545.95s | is typing. And I like 2545.95s - 2547.95s | this guy's GitHub. He says, I like big VMRC 2547.95s - 2549.95s | and I cannot lie. 2549.95s - 2551.95s | So KeyTap3 is part of this


chunk_id: 153_chunk_66
chunk_text:
see what's happening inside of your signal. 2517.95s - 2519.95s | And then you can do all sorts of things like 2519.95s - 2521.95s | de-s, de-hum, de-splosive. 2521.95s - 2523.95s | I have no idea what de-splosive is. 2523.95s - 2525.95s | But it has a lot of ways 2525.95s - 2527.95s | that you can then improve the signal. So you can 2527.95s - 2529.95s | say, hey, I want to learn this area of 2529.95s - 2531.95s | sound where there's just a lot of noise. 2531.95s - 2533.95s | Learn that, and now apply it to the rest of the signal 2533.95s - 2535.95s | and remove that noise. 2535.95s - 2537.95s | FFmpeg, just so we can actually convert some things 2537.95s - 2539.95s | around. And then KeyTap3 2539.95s - 2541.95s | is really the heart of the system for the 2541.95s - 2543.95s | keystroke extraction. We want to know what the person 2543.95s - 2545.95s | is typing. And I like 2545.95s - 2547.95s | this guy's GitHub. He says, I like big VMRC 2547.95s - 2549.95s | and I cannot lie. 2549.95s - 2551.95s | So KeyTap3 is part of this 2551.95s - 2553.95s | software where he takes audio 2553.95s - 2555.95s | and he's able to then separate 2555.95s - 2557.95s | out the keystrokes. Now what's interesting 2557.95s - 2559.95s | is that when you have a keyboard and you press some keys 2559.95s - 2561.95s | on it, every key produces a 2561.95s - 2563.95s | unique sound. Now we're not 2563.95s - 2565.95s | recording sound, we're recording vibration 2565.95s - 2567.95s | because we're hitting the laptop 2567.95s - 2569.95s | and reflecting off. And when someone 2569.95s - 2571.95s | is typing on that laptop, the sound 2571.95s - 2573.95s | is just vibration. And vibration matter. 2573.95s - 2575.95s | So the laptop is vibrating. 2575.95s - 2577.95s | It's literally vibrating. And because every 2577.95s - 2579.95s | unique key has a position, just 2579.95s - 2581.95s | like if you hit a drum. If you take a drum and you 2581.95s - 2583.95s | hit it in one location, you're producing one sound. 2583.95s - 2585.95s | If you hit it slightly somewhere else, it produces a 2585.95s - 2587.95s | slightly different sound. You can record that 2587.95s - 2589.95s


chunk_id: 153_chunk_67
chunk_text:
2551.95s - 2553.95s | software where he takes audio 2553.95s - 2555.95s | and he's able to then separate 2555.95s - 2557.95s | out the keystrokes. Now what's interesting 2557.95s - 2559.95s | is that when you have a keyboard and you press some keys 2559.95s - 2561.95s | on it, every key produces a 2561.95s - 2563.95s | unique sound. Now we're not 2563.95s - 2565.95s | recording sound, we're recording vibration 2565.95s - 2567.95s | because we're hitting the laptop 2567.95s - 2569.95s | and reflecting off. And when someone 2569.95s - 2571.95s | is typing on that laptop, the sound 2571.95s - 2573.95s | is just vibration. And vibration matter. 2573.95s - 2575.95s | So the laptop is vibrating. 2575.95s - 2577.95s | It's literally vibrating. And because every 2577.95s - 2579.95s | unique key has a position, just 2579.95s - 2581.95s | like if you hit a drum. If you take a drum and you 2581.95s - 2583.95s | hit it in one location, you're producing one sound. 2583.95s - 2585.95s | If you hit it slightly somewhere else, it produces a 2585.95s - 2587.95s | slightly different sound. You can record that 2587.95s - 2589.95s | and you can differentiate those two sounds. 2589.95s - 2591.95s | Then you can figure out where they've actually 2591.95s - 2593.95s | hit. Now on a keyboard, you don't know 2593.95s - 2595.95s | what they're typing. You don't actually know 2595.95s - 2597.95s | what they're hitting. But if you've collected 2597.95s - 2599.95s | over 100 or 200 keystrokes 2599.95s - 2601.95s | and you know the language they're 2601.95s - 2603.95s | typing in, then you can perform 2603.95s - 2605.95s | analysis and say 2605.95s - 2607.95s | frequency analysis. Like what are they 2607.95s - 2609.95s | actually typing? This is a Zodiac Killer. 2609.95s - 2611.95s | So he would release 2611.95s - 2613.95s | these puzzles that are essentially 2613.95s - 2615.95s | substitution ciphers. You can 2615.95s - 2617.95s | take all encryption and break it down into substitution 2617.95s - 2619.95s | cipher and transposition 2619.95s - 2621.95s | cipher. 2621.95s - 2623.95s | Just 2623.95s - 2625.95s | some examples. I love the outdoors. 2625.95s - 2627.95s | So going and as well 2627.95s - 2629.95s | as pointing lasers. So a couple demonstrations 2629.95s - 2631.95s |


chunk_id: 153_chunk_68
chunk_text:
| and you can differentiate those two sounds. 2589.95s - 2591.95s | Then you can figure out where they've actually 2591.95s - 2593.95s | hit. Now on a keyboard, you don't know 2593.95s - 2595.95s | what they're typing. You don't actually know 2595.95s - 2597.95s | what they're hitting. But if you've collected 2597.95s - 2599.95s | over 100 or 200 keystrokes 2599.95s - 2601.95s | and you know the language they're 2601.95s - 2603.95s | typing in, then you can perform 2603.95s - 2605.95s | analysis and say 2605.95s - 2607.95s | frequency analysis. Like what are they 2607.95s - 2609.95s | actually typing? This is a Zodiac Killer. 2609.95s - 2611.95s | So he would release 2611.95s - 2613.95s | these puzzles that are essentially 2613.95s - 2615.95s | substitution ciphers. You can 2615.95s - 2617.95s | take all encryption and break it down into substitution 2617.95s - 2619.95s | cipher and transposition 2619.95s - 2621.95s | cipher. 2621.95s - 2623.95s | Just 2623.95s - 2625.95s | some examples. I love the outdoors. 2625.95s - 2627.95s | So going and as well 2627.95s - 2629.95s | as pointing lasers. So a couple demonstrations 2629.95s - 2631.95s | of the setup. 2631.95s - 2633.95s | Here we can see what this actually looks 2633.95s - 2635.95s | like as you're pointing the laser 2635.95s - 2637.95s | onto a reflective surface of a laptop. 2637.95s - 2639.95s | We'll just see the KeyTap 2639.95s - 2641.95s | software. FFmpeg and KeyTap running. 2641.95s - 2646.16s | This is at 10x speed. 2646.16s - 2648.16s | Gonna be very hard to see, but the next slide 2648.16s - 2650.16s | I will do a little screenshot 2650.16s - 2652.16s | so we can compare. 2652.16s - 2654.16s | Again, that's 10x speed. So here's 2654.16s - 2656.16s | typing on a keyboard, what I 2656.16s - 2658.16s | typed, and then what KeyTap 3 was able 2658.16s - 2660.16s | to recover. This is after going 2660.16s - 2662.16s | through the setup, after going through 2662.16s - 2664.16s | GNU Radio, then iZotope RX 2664.16s - 2666.16s | with a lot of cleanup. Again, I needed 2666.16s - 2668.16s | to collect at least 3 kHz 2668.16s - 2670.16s | of sound. And also just 2670.16s - 2672.16s | an example of what the sound 2672.16s - 2674.16s


chunk_id: 153_chunk_69
chunk_text:
of the setup. 2631.95s - 2633.95s | Here we can see what this actually looks 2633.95s - 2635.95s | like as you're pointing the laser 2635.95s - 2637.95s | onto a reflective surface of a laptop. 2637.95s - 2639.95s | We'll just see the KeyTap 2639.95s - 2641.95s | software. FFmpeg and KeyTap running. 2641.95s - 2646.16s | This is at 10x speed. 2646.16s - 2648.16s | Gonna be very hard to see, but the next slide 2648.16s - 2650.16s | I will do a little screenshot 2650.16s - 2652.16s | so we can compare. 2652.16s - 2654.16s | Again, that's 10x speed. So here's 2654.16s - 2656.16s | typing on a keyboard, what I 2656.16s - 2658.16s | typed, and then what KeyTap 3 was able 2658.16s - 2660.16s | to recover. This is after going 2660.16s - 2662.16s | through the setup, after going through 2662.16s - 2664.16s | GNU Radio, then iZotope RX 2664.16s - 2666.16s | with a lot of cleanup. Again, I needed 2666.16s - 2668.16s | to collect at least 3 kHz 2668.16s - 2670.16s | of sound. And also just 2670.16s - 2672.16s | an example of what the sound 2672.16s - 2674.16s | actually sounds like. 2674.16s - 2676.16s | This was playing music inside of a 2676.16s - 2678.16s | room and then reflecting off the window. 2680.16s - 2682.16s | And you can hear a little bit 2682.16s - 2698.85s | of that sound. 2698.85s - 2700.85s | And that is the project. 2700.85s - 2702.85s | The challenges, I mean, this 2702.85s - 2704.85s | was really interesting. How do you get rid of noise? 2704.85s - 2706.85s | This whole thing was really 2706.85s - 2708.85s | signal processing. And the 2708.85s - 2710.85s | improvements to the laser microphone, the biggest thing 2710.85s - 2712.85s | to the laser microphone was really 2712.85s - 2714.85s | getting outside of the sound 2714.85s - 2716.85s | domain, getting into the radio domain. 2716.85s - 2718.85s | Once you get into there, then you have a lot more 2718.85s - 2720.85s | processing capabilities and you have 2720.85s - 2722.85s | all the sound, a ton of noise 2722.85s - 2724.85s | that was there, is gone. 2724.85s - 2726.85s | And there are plenty of improvements 2726.85s - 2728.85s | we can make, we can discuss 2728.85s -


chunk_id: 153_chunk_70
chunk_text:
| actually sounds like. 2674.16s - 2676.16s | This was playing music inside of a 2676.16s - 2678.16s | room and then reflecting off the window. 2680.16s - 2682.16s | And you can hear a little bit 2682.16s - 2698.85s | of that sound. 2698.85s - 2700.85s | And that is the project. 2700.85s - 2702.85s | The challenges, I mean, this 2702.85s - 2704.85s | was really interesting. How do you get rid of noise? 2704.85s - 2706.85s | This whole thing was really 2706.85s - 2708.85s | signal processing. And the 2708.85s - 2710.85s | improvements to the laser microphone, the biggest thing 2710.85s - 2712.85s | to the laser microphone was really 2712.85s - 2714.85s | getting outside of the sound 2714.85s - 2716.85s | domain, getting into the radio domain. 2716.85s - 2718.85s | Once you get into there, then you have a lot more 2718.85s - 2720.85s | processing capabilities and you have 2720.85s - 2722.85s | all the sound, a ton of noise 2722.85s - 2724.85s | that was there, is gone. 2724.85s - 2726.85s | And there are plenty of improvements 2726.85s - 2728.85s | we can make, we can discuss 2728.85s - 2730.85s | later, but thank you so much. 2730.85s - 2732.85s | I appreciate your time.


chunk_id: 154_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=MDndWJxfP-U", "title": "DEF CON 32 - The hack, the crash and two smoking barrels. - Thomas Sermpinis", "description": "This is not a talk in which I will demonstrate exploit chains obtained from the underworld after signing with blood. It\u2019s about sharing meaningful stories from said underworld. The automotive underworld of huge corporations, short deadlines and lukewarm engineers. The one where companies fight for packing more and more functionality inside your computer on wheels, without paying attention to one of the things that our life actually depends on right now, cybersecurity.\n\nWhile others talk about extremely significant remote vulnerabilities, I will focus on a high-level view of architecture and design of vehicles and where security fits in these processes. I will go through a journey of exploitation, from discovering 0days, to persuading engineers for the significance of a finding, by putting him in the driving seat and engaging the breaks mid-journey.\n\nI will conclude, trying to understand why this is happening, why this behavior towards security still exists in the automotive industry, and how a small manufacturer managed to create one of the most secure embedded systems I faced in my career. All this, with a series of demos in real targets, and a real ECU on stage.\n\nOur ultimate goal is to help people understand the state of the industry, spark the interest which can come out of hacking a computer on wheels, and try to raise awareness with a bit of hack, a bit of crash and two smoking barrels.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2378, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.50s - 5.50s | This text was transcribed using whisper model: large-v2 Hello. So thank you for joining um it's an immense honor to be here with you today uh 9.68s - 13.84s | something that I would never expect to happen. But this is the hack the crash and two 13.84s - 20.08s | smoking barrels and how I almost killed an engineer. And I must mention that uh basically I 20.08s - 24.58s | had no lawyers advising me before my talk so I will not if if you will not be able to reach 24.58s - 30.12s | me after the talk it was nice meeting you. And now while you are here because some 30.14s - 34.62s | people in the industry really pissed me off and I wanted to be the one taking the


chunk_id: 154_chunk_1
chunk_text:
targets, and a real ECU on stage.\n\nOur ultimate goal is to help people understand the state of the industry, spark the interest which can come out of hacking a computer on wheels, and try to raise awareness with a bit of hack, a bit of crash and two smoking barrels.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2378, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.50s - 5.50s | This text was transcribed using whisper model: large-v2 Hello. So thank you for joining um it's an immense honor to be here with you today uh 9.68s - 13.84s | something that I would never expect to happen. But this is the hack the crash and two 13.84s - 20.08s | smoking barrels and how I almost killed an engineer. And I must mention that uh basically I 20.08s - 24.58s | had no lawyers advising me before my talk so I will not if if you will not be able to reach 24.58s - 30.12s | me after the talk it was nice meeting you. And now while you are here because some 30.14s - 34.62s | people in the industry really pissed me off and I wanted to be the one taking the stage. 34.62s - 40.42s | And now that I got probably your attention let's start. I'm Thomas and yeah my 40.42s - 44.50s | pictures are usually so bad that uh making it black and white didn't really help. It's like 44.50s - 50.16s | my accent it can only go worse. And people also know me as Crow Tom. And the main thing 50.16s - 55.04s | you need to know about me is that I lead an amazing team uh in Auxilium Pentest Labs 55.04s - 60.50s | they are uh competing in the car hacking village right now and they are second. Um and I 60.50s - 65.50s | also love to hack like everything day, night, whatever. Mainly to prove to me and you that 67.78s - 73.18s | our world is hacking in on in really thin threads. And that most products are created with 73.18s - 78.82s | two main components. A bit of laziness and a sprinkle of capitalism. And for more you can 78.82s - 84.26s | always go to my website. What we will really really talk about today is vehicle 84.28s - 88.62s | security. Or how I like to


chunk_id: 154_chunk_2
chunk_text:
stage. 34.62s - 40.42s | And now that I got probably your attention let's start. I'm Thomas and yeah my 40.42s - 44.50s | pictures are usually so bad that uh making it black and white didn't really help. It's like 44.50s - 50.16s | my accent it can only go worse. And people also know me as Crow Tom. And the main thing 50.16s - 55.04s | you need to know about me is that I lead an amazing team uh in Auxilium Pentest Labs 55.04s - 60.50s | they are uh competing in the car hacking village right now and they are second. Um and I 60.50s - 65.50s | also love to hack like everything day, night, whatever. Mainly to prove to me and you that 67.78s - 73.18s | our world is hacking in on in really thin threads. And that most products are created with 73.18s - 78.82s | two main components. A bit of laziness and a sprinkle of capitalism. And for more you can 78.82s - 84.26s | always go to my website. What we will really really talk about today is vehicle 84.28s - 88.62s | security. Or how I like to call it all the stupid things that automotive industry is doing 88.62s - 94.62s | still in 2024. We will try to understand where we are uh where we are heading and if there are 94.62s - 98.70s | any if there is any light in the end of the tunnel. Hoping to get more people interested in 98.70s - 103.36s | the industry I love and highlight the significance of all the safety related hardware that no 103.36s - 109.70s | one cares about. What we will definitely not talk about is extreme exploit chains. I love to 109.72s - 115.22s | hack but I'm the worst at it. And this means that I'm not here to teach you how to do it but to 115.22s - 120.92s | show you why you should be here too and why you should care. Also if you were alerted into 120.92s - 124.66s | coming to my talk because of the title I'm sorry to tell you that during the process of the 124.66s - 128.86s | testing preparation and development of my talk no engineers were actually killed or 128.86s - 135.10s | suffocated due due to lack of oxygen.


chunk_id: 154_chunk_3
chunk_text:
call it all the stupid things that automotive industry is doing 88.62s - 94.62s | still in 2024. We will try to understand where we are uh where we are heading and if there are 94.62s - 98.70s | any if there is any light in the end of the tunnel. Hoping to get more people interested in 98.70s - 103.36s | the industry I love and highlight the significance of all the safety related hardware that no 103.36s - 109.70s | one cares about. What we will definitely not talk about is extreme exploit chains. I love to 109.72s - 115.22s | hack but I'm the worst at it. And this means that I'm not here to teach you how to do it but to 115.22s - 120.92s | show you why you should be here too and why you should care. Also if you were alerted into 120.92s - 124.66s | coming to my talk because of the title I'm sorry to tell you that during the process of the 124.66s - 128.86s | testing preparation and development of my talk no engineers were actually killed or 128.86s - 135.10s | suffocated due due to lack of oxygen. And let's start with the state of the industry and 135.10s - 140.64s | what a better start than one of my favorite examples of my living room on wheels. Uh as 140.64s - 145.22s | this car is not actually a result of pin by ride episode but still packs more functionality 145.22s - 149.96s | and entertainment than my living room. This example of a computer on wheels might be one of 149.96s - 154.86s | the extreme ones but it's becoming kind of the norm to be honest. Vehicles are getting 154.86s - 160.10s | connected, getting richer services and functionality something that the users ask for I 160.10s - 165.10s | guess. What they don't ask for though is for these services to be implemented in an insecure 165.10s - 171.82s | way. We see examples of improper and insecure implementation of new functionality every day 171.82s - 178.66s | and we have a handful of examples making the news every week. And while news outlets are 178.66s - 185.70s | mainly interested in the financial aspect of the thing um no one wants like their car to be 185.70s - 190.70s | stolen to be


chunk_id: 154_chunk_4
chunk_text:
And let's start with the state of the industry and 135.10s - 140.64s | what a better start than one of my favorite examples of my living room on wheels. Uh as 140.64s - 145.22s | this car is not actually a result of pin by ride episode but still packs more functionality 145.22s - 149.96s | and entertainment than my living room. This example of a computer on wheels might be one of 149.96s - 154.86s | the extreme ones but it's becoming kind of the norm to be honest. Vehicles are getting 154.86s - 160.10s | connected, getting richer services and functionality something that the users ask for I 160.10s - 165.10s | guess. What they don't ask for though is for these services to be implemented in an insecure 165.10s - 171.82s | way. We see examples of improper and insecure implementation of new functionality every day 171.82s - 178.66s | and we have a handful of examples making the news every week. And while news outlets are 178.66s - 185.70s | mainly interested in the financial aspect of the thing um no one wants like their car to be 185.70s - 190.70s | stolen to be honest. I will mostly focus today on the safety aspect of those security issues. 193.54s - 197.84s | And while the industry waits for the security software defined vehicle messiah today we will 197.84s - 202.88s | start with the complicated architectures that look like this. Uh here we have a representative 202.88s - 207.72s | example of a vehicle architecture with individual parts being electronic control control 207.72s - 212.90s | units. Different embedded components that most of the time have a single specific purpose 212.90s - 219.50s | inside the vehicle. All these are segmented in several isolated buses to avoid external 219.50s - 225.18s | communication or interruption and segment them by functionality and criticality. What you 225.18s - 230.38s | can also see is the fact that some of the interfaces are getting exposed internally though. 230.38s - 234.62s | And as we saw previously this is a kind of a necessity considering new technology and 234.62s - 239.66s | requirements needed to exist to make it make it happen. As an example the onboard charging 239.66s - 245.06s | ECU has an exposed interface handling the communication between the charger and the vehicle 245.06s -


chunk_id: 154_chunk_5
chunk_text:
honest. I will mostly focus today on the safety aspect of those security issues. 193.54s - 197.84s | And while the industry waits for the security software defined vehicle messiah today we will 197.84s - 202.88s | start with the complicated architectures that look like this. Uh here we have a representative 202.88s - 207.72s | example of a vehicle architecture with individual parts being electronic control control 207.72s - 212.90s | units. Different embedded components that most of the time have a single specific purpose 212.90s - 219.50s | inside the vehicle. All these are segmented in several isolated buses to avoid external 219.50s - 225.18s | communication or interruption and segment them by functionality and criticality. What you 225.18s - 230.38s | can also see is the fact that some of the interfaces are getting exposed internally though. 230.38s - 234.62s | And as we saw previously this is a kind of a necessity considering new technology and 234.62s - 239.66s | requirements needed to exist to make it make it happen. As an example the onboard charging 239.66s - 245.06s | ECU has an exposed interface handling the communication between the charger and the vehicle 245.06s - 250.06s | and the main head unit that the user inter uh interacts with is exposed to the internet through 250.06s - 256.04s | a telematics unit. Most of the times for SOS calls, OTA updates and more interconnected 256.04s - 261.88s | functionality. Now of course the purpose of this talk is not to cover everything automotive 261.88s - 266.94s | related but we need to get a bit of understanding on what we are seeing here and what the demos 266.96s - 273.06s | are representing later. Uh for this reason we will mainly focus on CAN uh which many of you 273.06s - 278.54s | might know as it exists for more than 40 years. Um and you would be surprised if I tell you 278.54s - 283.84s | that the majority of the ECUs we are testing still come with this interface. And of course 283.84s - 289.78s | the need of a single ABS ECU 30 plus years ago does not even come close to modern needs. So 289.78s - 295.82s | the the protocol has several iterations but still the main issue from my point of view is that 295.86s - 300.74s | there


chunk_id: 154_chunk_6
chunk_text:
250.06s | and the main head unit that the user inter uh interacts with is exposed to the internet through 250.06s - 256.04s | a telematics unit. Most of the times for SOS calls, OTA updates and more interconnected 256.04s - 261.88s | functionality. Now of course the purpose of this talk is not to cover everything automotive 261.88s - 266.94s | related but we need to get a bit of understanding on what we are seeing here and what the demos 266.96s - 273.06s | are representing later. Uh for this reason we will mainly focus on CAN uh which many of you 273.06s - 278.54s | might know as it exists for more than 40 years. Um and you would be surprised if I tell you 278.54s - 283.84s | that the majority of the ECUs we are testing still come with this interface. And of course 283.84s - 289.78s | the need of a single ABS ECU 30 plus years ago does not even come close to modern needs. So 289.78s - 295.82s | the the protocol has several iterations but still the main issue from my point of view is that 295.86s - 300.74s | there is no encryption as a standard and no message authentication. This makes CAN messages 300.74s - 306.44s | flowing on those buses prone to interception, injection and replication in cases that no 306.44s - 312.72s | additional protections are implemented. Which is more common than you think even 40 years 312.72s - 318.28s | after its inception. Of course this is not only uh the only technology which is currently 318.28s - 323.90s | used in modern vehicles but it's one of the most commonly used and that's why it's important 323.90s - 328.42s | to stress its flaws considering the stubbornness of automotive companies to stick with 328.42s - 334.68s | archaic and insecure technologies. As we speak for the current state of automotive security 334.68s - 340.62s | it's worth mentioning that um what started to be enforced to all manufacturers homologating 340.62s - 346.64s | vehicles uh in UNESCO member countries. Um but I don't want to bore with you as USA does 346.64s - 353.40s | not have any specific binding regulation similar to this. But it's worth mentioning that 353.40s - 359.18s | it's a starting point for shaping the completely unregulated mess that exists


chunk_id: 154_chunk_7
chunk_text:
is no encryption as a standard and no message authentication. This makes CAN messages 300.74s - 306.44s | flowing on those buses prone to interception, injection and replication in cases that no 306.44s - 312.72s | additional protections are implemented. Which is more common than you think even 40 years 312.72s - 318.28s | after its inception. Of course this is not only uh the only technology which is currently 318.28s - 323.90s | used in modern vehicles but it's one of the most commonly used and that's why it's important 323.90s - 328.42s | to stress its flaws considering the stubbornness of automotive companies to stick with 328.42s - 334.68s | archaic and insecure technologies. As we speak for the current state of automotive security 334.68s - 340.62s | it's worth mentioning that um what started to be enforced to all manufacturers homologating 340.62s - 346.64s | vehicles uh in UNESCO member countries. Um but I don't want to bore with you as USA does 346.64s - 353.40s | not have any specific binding regulation similar to this. But it's worth mentioning that 353.40s - 359.18s | it's a starting point for shaping the completely unregulated mess that exists till now in our 359.18s - 365.32s | industry but of course it's still a regulation with all the negatives that come with it. 365.32s - 370.12s | Considering that I will have a relatively negative talk I want to state from now that while 370.12s - 374.36s | the majority of the industry has a negative approach to cyber security there are several 374.36s - 379.94s | people that still strive for secure and safe vehicles every day with their work, research and 379.94s - 385.22s | discussions. Though not everything is sunshine and flowers and automotive is mainly based on 385.22s - 389.78s | hundred plus year old mechanical engineering industries that were recently forced to 389.78s - 395.36s | implement a lot of things they had no idea about and innovate in an environment with really 395.36s - 400.50s | short life cycles and restricting safety requirements that will make most of us cry in any 400.50s - 405.50s | case in many cases. I struggled a lot though so let me tell you my story. To start with I have to 406.06s - 411.06s | tell you that I'm tired of hearing about the state of


chunk_id: 154_chunk_8
chunk_text:
till now in our 359.18s - 365.32s | industry but of course it's still a regulation with all the negatives that come with it. 365.32s - 370.12s | Considering that I will have a relatively negative talk I want to state from now that while 370.12s - 374.36s | the majority of the industry has a negative approach to cyber security there are several 374.36s - 379.94s | people that still strive for secure and safe vehicles every day with their work, research and 379.94s - 385.22s | discussions. Though not everything is sunshine and flowers and automotive is mainly based on 385.22s - 389.78s | hundred plus year old mechanical engineering industries that were recently forced to 389.78s - 395.36s | implement a lot of things they had no idea about and innovate in an environment with really 395.36s - 400.50s | short life cycles and restricting safety requirements that will make most of us cry in any 400.50s - 405.50s | case in many cases. I struggled a lot though so let me tell you my story. To start with I have to 406.06s - 411.06s | tell you that I'm tired of hearing about the state of automotive security by professionals in 415.24s - 419.68s | commercial events referring to a couple of good examples in the sea of OEMs and tier one 419.68s - 425.24s | suppliers developing products in this industry. Tesla and BMW are not the only companies 425.24s - 430.98s | out there. And yes while I really appreciate their work in some cases we are here to talk 431.00s - 436.80s | about the industry as a whole and not the two examples that are out of the ordinary. And I'm 436.80s - 441.78s | saying this because vulnerability disclosure programs are not the norm here. The small 441.78s - 447.88s | amount of OEMs that escaped from their mechanical engineering past attitude or they 447.88s - 452.96s | started in this new generation of automotive manufacturers is not representative for the 452.96s - 458.10s | whole industry. And even the companies that incentivize and support researchers they only 458.12s - 462.92s | give payouts to findings that are heavily security critical but no mention to safety 462.92s - 468.90s | critical issues and exploit chains. And I'm saying this because the last two years I 468.90s - 474.90s | discovered twenty


chunk_id: 154_chunk_9
chunk_text:
automotive security by professionals in 415.24s - 419.68s | commercial events referring to a couple of good examples in the sea of OEMs and tier one 419.68s - 425.24s | suppliers developing products in this industry. Tesla and BMW are not the only companies 425.24s - 430.98s | out there. And yes while I really appreciate their work in some cases we are here to talk 431.00s - 436.80s | about the industry as a whole and not the two examples that are out of the ordinary. And I'm 436.80s - 441.78s | saying this because vulnerability disclosure programs are not the norm here. The small 441.78s - 447.88s | amount of OEMs that escaped from their mechanical engineering past attitude or they 447.88s - 452.96s | started in this new generation of automotive manufacturers is not representative for the 452.96s - 458.10s | whole industry. And even the companies that incentivize and support researchers they only 458.12s - 462.92s | give payouts to findings that are heavily security critical but no mention to safety 462.92s - 468.90s | critical issues and exploit chains. And I'm saying this because the last two years I 468.90s - 474.90s | discovered twenty five safety related findings out of which only two were accepted until now. 474.90s - 479.40s | And not because they are out of scope or not applicable but because there is no way to 479.40s - 485.18s | actually disclose them. To start to start talking about them though uh we need to get an 485.20s - 489.86s | understanding of one of the protocols we approach today in our example POCs namely the 489.86s - 494.64s | Unified Diagnostics Protocol which lives in the application layer of the ECUs and allows 494.64s - 499.54s | diagnostic functionality such as reading and erasing faults, reprogramming, testing and 499.54s - 505.02s | monitoring. It commonly consists of several services that handle specific actions and the 505.02s - 510.68s | common one here that we will try to use in uh in these examples in these demos is the ECU 510.72s - 515.86s | reset or service eleven which is commonly used to perform a reset on the ECU as the name 515.86s - 521.00s | implies but of different types so depending on the supplied subservice we can specify if it's a 521.00s - 526.60s | hard a soft or


chunk_id: 154_chunk_10
chunk_text:
five safety related findings out of which only two were accepted until now. 474.90s - 479.40s | And not because they are out of scope or not applicable but because there is no way to 479.40s - 485.18s | actually disclose them. To start to start talking about them though uh we need to get an 485.20s - 489.86s | understanding of one of the protocols we approach today in our example POCs namely the 489.86s - 494.64s | Unified Diagnostics Protocol which lives in the application layer of the ECUs and allows 494.64s - 499.54s | diagnostic functionality such as reading and erasing faults, reprogramming, testing and 499.54s - 505.02s | monitoring. It commonly consists of several services that handle specific actions and the 505.02s - 510.68s | common one here that we will try to use in uh in these examples in these demos is the ECU 510.72s - 515.86s | reset or service eleven which is commonly used to perform a reset on the ECU as the name 515.86s - 521.00s | implies but of different types so depending on the supplied subservice we can specify if it's a 521.00s - 526.60s | hard a soft or any other supported uh type of reset on the ECU. And finally I have to 526.60s - 531.58s | mention that the hard ECU reset is most in most cases it's equivalent to a comp to a 531.58s - 538.58s | complete power cycle and we will see how this can go really bad for the ECU. Now the last 538.58s - 543.02s | five years me and my team performed almost two hundred penetration testing and research 543.02s - 548.70s | projects in the automotive industry. Uh is the screen? Yeah. In the automotive industry 548.70s - 554.84s | sorry. And this means that first of all we got a broad understanding and experience of how 554.84s - 559.98s | security is implemented and discovered several nasty things along the way. While we try to 559.98s - 564.38s | work with all these people to make the products more secure the issue is that I'm not able to 564.38s - 569.36s | talk about those so I had to find a way to share some of those juicy things. So it was 569.36s - 574.32s | during a warm summer in Arizona when I had the rental unit from


chunk_id: 154_chunk_11
chunk_text:
any other supported uh type of reset on the ECU. And finally I have to 526.60s - 531.58s | mention that the hard ECU reset is most in most cases it's equivalent to a comp to a 531.58s - 538.58s | complete power cycle and we will see how this can go really bad for the ECU. Now the last 538.58s - 543.02s | five years me and my team performed almost two hundred penetration testing and research 543.02s - 548.70s | projects in the automotive industry. Uh is the screen? Yeah. In the automotive industry 548.70s - 554.84s | sorry. And this means that first of all we got a broad understanding and experience of how 554.84s - 559.98s | security is implemented and discovered several nasty things along the way. While we try to 559.98s - 564.38s | work with all these people to make the products more secure the issue is that I'm not able to 564.38s - 569.36s | talk about those so I had to find a way to share some of those juicy things. So it was 569.36s - 574.32s | during a warm summer in Arizona when I had the rental unit from a brand which I tried my 574.32s - 580.06s | best to hide here. And during my free time and during night as if I was testing during the day 580.06s - 585.44s | in Arizona I would not be here. Uh I started working uh like poking around uh this thing 585.44s - 590.44s | that you see there and I had my first hit. In this case we triggered something that is not 590.88s - 597.78s | a hundred percent clear what it is. From the context given in the error created on the 597.78s - 602.12s | heads up display. For this reason we need to dig deeper and understand the architecture of 602.12s - 609.12s | the vehicle, understand how, why, in which extent something is affected. Is this error real? Is 609.12s - 615.14s | it expected behavior? Does it even have any security or safety impact or not? This is the 615.14s - 621.24s | only, this is only a part of the questions that I have to answer at this point in order to 621.24s - 627.88s | move forward. And that's what I did. In the first demo you see how we


chunk_id: 154_chunk_12
chunk_text:
a brand which I tried my 574.32s - 580.06s | best to hide here. And during my free time and during night as if I was testing during the day 580.06s - 585.44s | in Arizona I would not be here. Uh I started working uh like poking around uh this thing 585.44s - 590.44s | that you see there and I had my first hit. In this case we triggered something that is not 590.88s - 597.78s | a hundred percent clear what it is. From the context given in the error created on the 597.78s - 602.12s | heads up display. For this reason we need to dig deeper and understand the architecture of 602.12s - 609.12s | the vehicle, understand how, why, in which extent something is affected. Is this error real? Is 609.12s - 615.14s | it expected behavior? Does it even have any security or safety impact or not? This is the 615.14s - 621.24s | only, this is only a part of the questions that I have to answer at this point in order to 621.24s - 627.88s | move forward. And that's what I did. In the first demo you see how we discovered that the 627.88s - 633.62s | affected ECU uh and by issuing a simple ECU reset on the user accessible onboard 633.62s - 638.06s | diagnostics board the ECU resets and the light of the affected blind spot blind spot 638.06s - 645.00s | detection sensor is engaged. Of course I didn't stop there and because at this point a lot of 645.02s - 651.16s | educated guesses can be done considering uh what was discovered. As is the finding has no 651.16s - 656.70s | big safety related severity outside of the fact that it can distract the driver. By listing the 656.70s - 661.38s | known facts though we can assume where the affected ECU is located in the architecture and 661.38s - 668.18s | how this can be escalated further by a malicious user. What we know is that first of all we can 668.18s - 673.56s | power cycle the ECU and what and that there are no preconditions that can restrict this 673.58s - 680.22s | action. Like a vehicle speed uh restriction for example. Additionally from the function of the 680.22s - 685.22s | assistive driving uh we can assume that the blind


chunk_id: 154_chunk_13
chunk_text:
discovered that the 627.88s - 633.62s | affected ECU uh and by issuing a simple ECU reset on the user accessible onboard 633.62s - 638.06s | diagnostics board the ECU resets and the light of the affected blind spot blind spot 638.06s - 645.00s | detection sensor is engaged. Of course I didn't stop there and because at this point a lot of 645.02s - 651.16s | educated guesses can be done considering uh what was discovered. As is the finding has no 651.16s - 656.70s | big safety related severity outside of the fact that it can distract the driver. By listing the 656.70s - 661.38s | known facts though we can assume where the affected ECU is located in the architecture and 661.38s - 668.18s | how this can be escalated further by a malicious user. What we know is that first of all we can 668.18s - 673.56s | power cycle the ECU and what and that there are no preconditions that can restrict this 673.58s - 680.22s | action. Like a vehicle speed uh restriction for example. Additionally from the function of the 680.22s - 685.22s | assistive driving uh we can assume that the blind spot detection sensor is connected with the 685.22s - 692.00s | functionality of the ADAS itself. By this we can easily prove that the sensor can be 692.00s - 697.08s | triggered mid drive. Uh as a direct result it can confuse the driver because of the engagement 697.10s - 702.84s | of a sensor in an unexpected situation. But more importantly we can engage serious 702.84s - 708.68s | safety implications to the ADAS system like steering interruption during a lane change or 708.68s - 713.78s | even braking engagement during a false safety related incident on the blind spot detection 713.78s - 719.48s | sensor. Of course I don't want to check these assumptions myself um and I hope I don't need to 719.48s - 726.16s | mention that you you should always check safety related issues in a safe environment. Who has 726.18s - 731.48s | the ability and the environment? The manufacturer of course. And for this reason I had to find a 731.48s - 736.32s | way to report the finding and prove those assumptions. Now going through the process of 736.32s - 742.02s | vulnerability disclosure I initiated uh by trying to find a


chunk_id: 154_chunk_14
chunk_text:
spot detection sensor is connected with the 685.22s - 692.00s | functionality of the ADAS itself. By this we can easily prove that the sensor can be 692.00s - 697.08s | triggered mid drive. Uh as a direct result it can confuse the driver because of the engagement 697.10s - 702.84s | of a sensor in an unexpected situation. But more importantly we can engage serious 702.84s - 708.68s | safety implications to the ADAS system like steering interruption during a lane change or 708.68s - 713.78s | even braking engagement during a false safety related incident on the blind spot detection 713.78s - 719.48s | sensor. Of course I don't want to check these assumptions myself um and I hope I don't need to 719.48s - 726.16s | mention that you you should always check safety related issues in a safe environment. Who has 726.18s - 731.48s | the ability and the environment? The manufacturer of course. And for this reason I had to find a 731.48s - 736.32s | way to report the finding and prove those assumptions. Now going through the process of 736.32s - 742.02s | vulnerability disclosure I initiated uh by trying to find a communication channel uh with the 742.02s - 747.46s | OEM and a couple of years ago that this happened. The problem is that there was no 747.46s - 751.30s | vulnerability disclosure program. No one was answering to me regarding this from the 751.34s - 757.38s | contact options and the people I discovered online. But of course I didn't give up. I kept 757.38s - 763.56s | hacking. And getting our ha- hands a bit dirtier here we need to introduce the main access 763.56s - 769.12s | control mechanism in UDS diagnostics called security access. Which as you understand from 769.12s - 775.14s | my diagram is a simple challenge response. The client requests a random seed, the ECU generates 775.14s - 782.16s | what seed uh that seed and calculates the key using the secret algorithm and secret key. And 782.16s - 786.46s | after that the client needs to know the same secrets, use the random seed and calculated key 786.46s - 792.90s | to send to the ECU where the ECU verifies uh verifies this uh calculated key and grants or 792.90s - 798.30s | rejects that access to the client. The implementation highly highly


chunk_id: 154_chunk_15
chunk_text:
communication channel uh with the 742.02s - 747.46s | OEM and a couple of years ago that this happened. The problem is that there was no 747.46s - 751.30s | vulnerability disclosure program. No one was answering to me regarding this from the 751.34s - 757.38s | contact options and the people I discovered online. But of course I didn't give up. I kept 757.38s - 763.56s | hacking. And getting our ha- hands a bit dirtier here we need to introduce the main access 763.56s - 769.12s | control mechanism in UDS diagnostics called security access. Which as you understand from 769.12s - 775.14s | my diagram is a simple challenge response. The client requests a random seed, the ECU generates 775.14s - 782.16s | what seed uh that seed and calculates the key using the secret algorithm and secret key. And 782.16s - 786.46s | after that the client needs to know the same secrets, use the random seed and calculated key 786.46s - 792.90s | to send to the ECU where the ECU verifies uh verifies this uh calculated key and grants or 792.90s - 798.30s | rejects that access to the client. The implementation highly highly depends on the 798.30s - 803.54s | cyber security requirements of the OEM most of the times. Uh and when these are loosely 803.54s - 809.32s | developed we see some unimaginably sloppy implementations, backdoors and weak sources of 809.32s - 817.99s | randomness um or any other random aspect of uh the process. Where this access control is 817.99s - 824.57s | used no- commonly I would say mostly software updates and reprogramming and the most 824.57s - 831.57s | commonly used uh in high severity instances um is these ones. Um mainly also the ones that 831.57s - 837.47s | we care about and that shows the level of access they can give us in cases of compromise. And 837.47s - 842.29s | of course it's automos- automotive so the process is not encrypted. But it's behind an 842.29s - 847.29s | ADPS and it's a challenge response right? Knowing that the process is unencrypted we already 849.63s - 855.37s | know that we can intercept and replay a seed and the applicable calculated key for the process. 855.37s - 861.67s | Message authentication also does not exist in 99 percent of the times here so that should


chunk_id: 154_chunk_16
chunk_text:
depends on the 798.30s - 803.54s | cyber security requirements of the OEM most of the times. Uh and when these are loosely 803.54s - 809.32s | developed we see some unimaginably sloppy implementations, backdoors and weak sources of 809.32s - 817.99s | randomness um or any other random aspect of uh the process. Where this access control is 817.99s - 824.57s | used no- commonly I would say mostly software updates and reprogramming and the most 824.57s - 831.57s | commonly used uh in high severity instances um is these ones. Um mainly also the ones that 831.57s - 837.47s | we care about and that shows the level of access they can give us in cases of compromise. And 837.47s - 842.29s | of course it's automos- automotive so the process is not encrypted. But it's behind an 842.29s - 847.29s | ADPS and it's a challenge response right? Knowing that the process is unencrypted we already 849.63s - 855.37s | know that we can intercept and replay a seed and the applicable calculated key for the process. 855.37s - 861.67s | Message authentication also does not exist in 99 percent of the times here so that should not 861.67s - 867.75s | be an issue most probably. But even with access to the bus managing to intercept the seed and 867.75s - 873.51s | the applicable key should not yield to elevated access as the process heavily based on the 873.51s - 879.69s | random aspect of the seed. Um if we cannot control the seed we cannot replay a successful 879.71s - 886.23s | seed key pair to obtain elevated access to the target ECU. Or can we? And going back to our 886.23s - 891.33s | friend ECU reset I want to remind you that one of the subservices capable of full power 891.33s - 897.49s | cycling the ECU is the hard ECU reset. This is the direct outcome though. Indirectly by 897.49s - 902.51s | completing a power cycle we also perform a reset to the system clock in many cases. And here 902.77s - 909.61s | we see the effects of this assumption. Uh while the seed of the target ECU can be considered 909.61s - 915.65s | really secure at 32 bytes we can see that we can reset the system clock with an ECU reset and 915.65s - 920.75s |


chunk_id: 154_chunk_17
chunk_text:
not 861.67s - 867.75s | be an issue most probably. But even with access to the bus managing to intercept the seed and 867.75s - 873.51s | the applicable key should not yield to elevated access as the process heavily based on the 873.51s - 879.69s | random aspect of the seed. Um if we cannot control the seed we cannot replay a successful 879.71s - 886.23s | seed key pair to obtain elevated access to the target ECU. Or can we? And going back to our 886.23s - 891.33s | friend ECU reset I want to remind you that one of the subservices capable of full power 891.33s - 897.49s | cycling the ECU is the hard ECU reset. This is the direct outcome though. Indirectly by 897.49s - 902.51s | completing a power cycle we also perform a reset to the system clock in many cases. And here 902.77s - 909.61s | we see the effects of this assumption. Uh while the seed of the target ECU can be considered 909.61s - 915.65s | really secure at 32 bytes we can see that we can reset the system clock with an ECU reset and 915.65s - 920.75s | after a predefined and fixed delay between the reset and the seed request the supplied 920.75s - 925.75s | random seed is always the same with a staggering hundred percent accuracy. In this case we 926.01s - 932.75s | invalidated the assumption of what is needed in a challenge response when we can intercept 932.75s - 938.55s | successfully a seed and key pair. With that in mind we only need one seed key pair to obtain 938.55s - 943.19s | elevated access to the unit. Which can potentially be obtained at the service visit or during 943.19s - 950.19s | an OTA update from the head unit. Fast forward two years later and I eventually discovered 950.21s - 956.25s | someone that was willing to help me report those issues to the OEM. I prepared a well 956.25s - 960.81s | structured report of of my vulnerabilities and sent it to the contact point working for the 960.81s - 967.25s | OEM. The issues were acknowledged a couple of days later but privately. At this point we know 967.25s - 973.29s | that these findings were not only affecting the model and model year I tested but several 973.29s


chunk_id: 154_chunk_18
chunk_text:
after a predefined and fixed delay between the reset and the seed request the supplied 920.75s - 925.75s | random seed is always the same with a staggering hundred percent accuracy. In this case we 926.01s - 932.75s | invalidated the assumption of what is needed in a challenge response when we can intercept 932.75s - 938.55s | successfully a seed and key pair. With that in mind we only need one seed key pair to obtain 938.55s - 943.19s | elevated access to the unit. Which can potentially be obtained at the service visit or during 943.19s - 950.19s | an OTA update from the head unit. Fast forward two years later and I eventually discovered 950.21s - 956.25s | someone that was willing to help me report those issues to the OEM. I prepared a well 956.25s - 960.81s | structured report of of my vulnerabilities and sent it to the contact point working for the 960.81s - 967.25s | OEM. The issues were acknowledged a couple of days later but privately. At this point we know 967.25s - 973.29s | that these findings were not only affecting the model and model year I tested but several 973.29s - 978.83s | models and bra- and of the brand and numerous model years. So we are talking about a 978.83s - 985.77s | significant number of affected vehicles. The drama starts here though. Despite the help 985.77s - 990.81s | from the contact point OEM decided that the cost of fixing the issue exceeds the expectations 990.81s - 997.65s | for this model. The excuse is that future electrical and electronic architecture that they 997.65s - 1003.03s | designed will mitigate those issues in the models for 2025 and 2026. Which of course 1003.03s - 1008.33s | directly means that the currently sold architecture is still vulnerable and that the OEM 1008.33s - 1013.91s | is not willing to either fix or disclose the findings publicly. As a romantic myself I 1013.91s - 1019.17s | decided to not publish the findings. I wanted to act professionally especially in comparison 1019.17s - 1024.95s | to the norm in my industry and irresponsibility brings chaos. I'm not the one feeding this 1024.95s - 1029.95s | beast. Trying to find a solution I decided to uh to propose a responsible disclosure to a generic 1030.89s - 1035.89s | VDP namely the ASRG


chunk_id: 154_chunk_19
chunk_text:
- 978.83s | models and bra- and of the brand and numerous model years. So we are talking about a 978.83s - 985.77s | significant number of affected vehicles. The drama starts here though. Despite the help 985.77s - 990.81s | from the contact point OEM decided that the cost of fixing the issue exceeds the expectations 990.81s - 997.65s | for this model. The excuse is that future electrical and electronic architecture that they 997.65s - 1003.03s | designed will mitigate those issues in the models for 2025 and 2026. Which of course 1003.03s - 1008.33s | directly means that the currently sold architecture is still vulnerable and that the OEM 1008.33s - 1013.91s | is not willing to either fix or disclose the findings publicly. As a romantic myself I 1013.91s - 1019.17s | decided to not publish the findings. I wanted to act professionally especially in comparison 1019.17s - 1024.95s | to the norm in my industry and irresponsibility brings chaos. I'm not the one feeding this 1024.95s - 1029.95s | beast. Trying to find a solution I decided to uh to propose a responsible disclosure to a generic 1030.89s - 1035.89s | VDP namely the ASRG Automotive Security Research Group which out of many things they are 1039.03s - 1044.77s | also an officially recognized CNA. So after a short discussion with my contact point and the 1044.77s - 1049.77s | OEM uh I decided to report the issue to ASRG. Something that needs to be mentioned out here 1052.03s - 1057.05s | here for the sake of compli- completeness sorry. Uh is that I disclosed the finding in a generic 1059.99s - 1064.99s | email from the website of the VDP. And not to anyone directly just the generic available email 1067.75s - 1073.03s | address that was uh on the website. At this point and after a couple of email exchanges with 1073.03s - 1078.03s | me the OEM and the ASRG the OEM stops responding completely. I was completely clueless of 1080.73s - 1086.15s | what there is to follow. Uh despite my continuous effort to resolve the issue and find why 1086.17s - 1093.19s | this happened um the OEM wasn't responding to all uh of our requests. Or to any of our 1093.19s - 1098.23s | requests. And not only they didn't give me a reason but I was directly accused


chunk_id: 154_chunk_20
chunk_text:
Automotive Security Research Group which out of many things they are 1039.03s - 1044.77s | also an officially recognized CNA. So after a short discussion with my contact point and the 1044.77s - 1049.77s | OEM uh I decided to report the issue to ASRG. Something that needs to be mentioned out here 1052.03s - 1057.05s | here for the sake of compli- completeness sorry. Uh is that I disclosed the finding in a generic 1059.99s - 1064.99s | email from the website of the VDP. And not to anyone directly just the generic available email 1067.75s - 1073.03s | address that was uh on the website. At this point and after a couple of email exchanges with 1073.03s - 1078.03s | me the OEM and the ASRG the OEM stops responding completely. I was completely clueless of 1080.73s - 1086.15s | what there is to follow. Uh despite my continuous effort to resolve the issue and find why 1086.17s - 1093.19s | this happened um the OEM wasn't responding to all uh of our requests. Or to any of our 1093.19s - 1098.23s | requests. And not only they didn't give me a reason but I was directly accused by third 1098.23s - 1103.69s | parties which I never contacted or revealed my findings to that I'm collaborating with 1103.69s - 1109.17s | hostile nations. You don't accuse me of doing something like this especially when I tried so 1109.17s - 1115.27s | much to responsibly disclose this shit and not and the only thing they did was find excuses. 1115.29s - 1121.97s | And to be honest I don't want to dex dox anyone uh this is not why I'm here. I'm here to share 1121.97s - 1128.21s | my experience and maybe shake the industry a bit out of this limbo they are into. But what 1128.21s - 1133.11s | happened is that the that the person that handled my case in the public VDP had the 1133.11s - 1139.41s | citizenship of a supposed hostile nation which the legal department of the OEM decided that 1139.41s - 1144.95s | it's not good for their image. You want to hear some plot twist uh basically this guy 1144.97s - 1150.91s | does not live in this nation he has another residency on the homeland of the OEM and guess 1150.91s - 1156.21s | what I recently learned


chunk_id: 154_chunk_21
chunk_text:
by third 1098.23s - 1103.69s | parties which I never contacted or revealed my findings to that I'm collaborating with 1103.69s - 1109.17s | hostile nations. You don't accuse me of doing something like this especially when I tried so 1109.17s - 1115.27s | much to responsibly disclose this shit and not and the only thing they did was find excuses. 1115.29s - 1121.97s | And to be honest I don't want to dex dox anyone uh this is not why I'm here. I'm here to share 1121.97s - 1128.21s | my experience and maybe shake the industry a bit out of this limbo they are into. But what 1128.21s - 1133.11s | happened is that the that the person that handled my case in the public VDP had the 1133.11s - 1139.41s | citizenship of a supposed hostile nation which the legal department of the OEM decided that 1139.41s - 1144.95s | it's not good for their image. You want to hear some plot twist uh basically this guy 1144.97s - 1150.91s | does not live in this nation he has another residency on the homeland of the OEM and guess 1150.91s - 1156.21s | what I recently learned that he has chosen to handle this topic because of an affiliation 1156.21s - 1161.75s | with the OEM and he has he was the best person for this job. But the OEM research can go that 1161.75s - 1167.59s | far of course or they didn't even care to be honest. After all the drama and after I contact 1167.59s - 1172.13s | all the parties saying that this level of accusations from third parties and the fact that 1172.15s - 1177.15s | they disclosed they disclosed the private findings outside of the legal framework was 1177.15s - 1181.93s | unacceptable. I also announced to them that the findings will be published published on the 1181.93s - 1186.93s | day of DEF CON today. And of course this is the day they answered. Something that needs to 1190.57s - 1195.41s | be mentioned here is that during the initial discussion for the findings I was clearly 1195.41s - 1201.35s | asked if the finding is discovered by the directly connecting to the ECU or from the OBD 1201.37s - 1208.17s | port. Um as the OBD port is user accessible and the findings are applicable and if it's only


chunk_id: 154_chunk_22
chunk_text:
that he has chosen to handle this topic because of an affiliation 1156.21s - 1161.75s | with the OEM and he has he was the best person for this job. But the OEM research can go that 1161.75s - 1167.59s | far of course or they didn't even care to be honest. After all the drama and after I contact 1167.59s - 1172.13s | all the parties saying that this level of accusations from third parties and the fact that 1172.15s - 1177.15s | they disclosed they disclosed the private findings outside of the legal framework was 1177.15s - 1181.93s | unacceptable. I also announced to them that the findings will be published published on the 1181.93s - 1186.93s | day of DEF CON today. And of course this is the day they answered. Something that needs to 1190.57s - 1195.41s | be mentioned here is that during the initial discussion for the findings I was clearly 1195.41s - 1201.35s | asked if the finding is discovered by the directly connecting to the ECU or from the OBD 1201.37s - 1208.17s | port. Um as the OBD port is user accessible and the findings are applicable and if it's only 1208.17s - 1213.35s | applicable to the direct connection will mark the findings as mitigated by the IDPS system. 1213.35s - 1218.35s | Something that I don't agree but it was reasonable. This though not so much. Um yeah. So 1221.99s - 1226.05s | yeah today I'm releasing these 2 vulnerabilities as I said I don't want to dox anyone I want 1226.05s - 1231.77s | a safe future with cars that can support their functionality in a secure way but in in this 1231.77s - 1236.77s | case the OEM instead of communicating decided to play politics and it's not only them this is 1238.67s - 1244.31s | the common trend. Researchers are not the ones to blame here with falsified accusations. As in 1244.31s - 1250.09s | most cases we are more than happy to collaborate and help each other. And not only 1250.09s - 1255.25s | researchers, pen testers too. Let's crash it and see where it brings us in this case. As we 1255.25s - 1259.99s | saw previously politics play a big role. Not only in public disclosure but in private 1259.99s - 1264.69s | projects too. Throughout my time with automotive security projects I


chunk_id: 154_chunk_23
chunk_text:
1208.17s - 1213.35s | applicable to the direct connection will mark the findings as mitigated by the IDPS system. 1213.35s - 1218.35s | Something that I don't agree but it was reasonable. This though not so much. Um yeah. So 1221.99s - 1226.05s | yeah today I'm releasing these 2 vulnerabilities as I said I don't want to dox anyone I want 1226.05s - 1231.77s | a safe future with cars that can support their functionality in a secure way but in in this 1231.77s - 1236.77s | case the OEM instead of communicating decided to play politics and it's not only them this is 1238.67s - 1244.31s | the common trend. Researchers are not the ones to blame here with falsified accusations. As in 1244.31s - 1250.09s | most cases we are more than happy to collaborate and help each other. And not only 1250.09s - 1255.25s | researchers, pen testers too. Let's crash it and see where it brings us in this case. As we 1255.25s - 1259.99s | saw previously politics play a big role. Not only in public disclosure but in private 1259.99s - 1264.69s | projects too. Throughout my time with automotive security projects I heard a lot of excuses by 1264.69s - 1271.71s | engineers and management only uh on why they don't want to accept or fix an issue. The usual 1271.71s - 1276.71s | suspects are loosely developed requirements uh or internal or external. Strict deadlines and 1276.91s - 1281.91s | long product life cycles along others of course. By my conclu but my conclusion is always that 1286.15s - 1291.23s | it's a culture issue. Either the company culture or the respective local culture affects the way 1291.23s - 1296.53s | companies consume, approach and mitigate issues. Of course it's a complex issue where 1296.53s - 1302.27s | regulators, governments and external parties are contributing to the development and 1302.27s - 1308.83s | production of a full vehicle. But in the end the people I interacted and worked with uh out of 1308.83s - 1315.01s | these projects construct my perception of this industry. But considering the culture and how 1315.01s - 1321.35s | the findings are approached what do we need to do to persuade them about the severity? Which 1321.35s - 1326.85s | level should we reach and why people uh and which people should we contact? Who is


chunk_id: 154_chunk_24
chunk_text:
heard a lot of excuses by 1264.69s - 1271.71s | engineers and management only uh on why they don't want to accept or fix an issue. The usual 1271.71s - 1276.71s | suspects are loosely developed requirements uh or internal or external. Strict deadlines and 1276.91s - 1281.91s | long product life cycles along others of course. By my conclu but my conclusion is always that 1286.15s - 1291.23s | it's a culture issue. Either the company culture or the respective local culture affects the way 1291.23s - 1296.53s | companies consume, approach and mitigate issues. Of course it's a complex issue where 1296.53s - 1302.27s | regulators, governments and external parties are contributing to the development and 1302.27s - 1308.83s | production of a full vehicle. But in the end the people I interacted and worked with uh out of 1308.83s - 1315.01s | these projects construct my perception of this industry. But considering the culture and how 1315.01s - 1321.35s | the findings are approached what do we need to do to persuade them about the severity? Which 1321.35s - 1326.85s | level should we reach and why people uh and which people should we contact? Who is 1326.87s - 1333.71s | responsible for the person that will die if my next finding is not fixed? Even if you develop the 1333.71s - 1339.91s | target with security in mind uh and with the best of intentions logical flaws can exist and 1339.91s - 1344.39s | exploited. Developers of different components usually only interact with a vehicle 1344.39s - 1349.39s | simulation ignoring how one action can have a security or safety event outside the scope of the 1349.51s - 1354.51s | functional testing. And this is how safety related findings can be discovered in most 1357.69s - 1364.03s | unexpected for the manufacturer behavior. A completely unrelated issue of seemingly minimal 1364.03s - 1370.43s | secure uh security impact can have a devastating safety outcome. As a first use case we can 1370.43s - 1374.81s | easily get the example of electric vehicles where I was testing the security not only of a 1374.83s - 1379.77s | battery management system on the on board charging but the batteries themselves. By 1379.77s - 1384.61s | analyzing the communication and while I was close to the car I discovered that there is a sound 1384.61s - 1389.91s | generated


chunk_id: 154_chunk_25
chunk_text:
1326.87s - 1333.71s | responsible for the person that will die if my next finding is not fixed? Even if you develop the 1333.71s - 1339.91s | target with security in mind uh and with the best of intentions logical flaws can exist and 1339.91s - 1344.39s | exploited. Developers of different components usually only interact with a vehicle 1344.39s - 1349.39s | simulation ignoring how one action can have a security or safety event outside the scope of the 1349.51s - 1354.51s | functional testing. And this is how safety related findings can be discovered in most 1357.69s - 1364.03s | unexpected for the manufacturer behavior. A completely unrelated issue of seemingly minimal 1364.03s - 1370.43s | secure uh security impact can have a devastating safety outcome. As a first use case we can 1370.43s - 1374.81s | easily get the example of electric vehicles where I was testing the security not only of a 1374.83s - 1379.77s | battery management system on the on board charging but the batteries themselves. By 1379.77s - 1384.61s | analyzing the communication and while I was close to the car I discovered that there is a sound 1384.61s - 1389.91s | generated when I was injecting uh an unauthenticated message. When I started discussing 1389.91s - 1395.65s | with one of the engineers it ended up being the battery contra- contractors of the AV. I was 1395.65s - 1400.55s | immediately concerned at that point knowing that wear and tear of the con- contact uh surface 1400.57s - 1405.57s | can increase the resistance and lead to excessive excessive heating. And you know what 1405.57s - 1410.61s | comes with after excessive heating and localized uh especially heating for extended 1410.61s - 1416.95s | periods of time? It's of course fire. Um of course I cannot burn an engineer and I cannot 1416.95s - 1422.09s | conduct a test to prove physics the physics behind behind it without risking the battery pack 1422.09s - 1427.29s | burning nonstop for days. So the topic ended there, the vehicle is out, all engineers are 1427.33s - 1434.41s | safe, a couple of hundreds of thousands of users are not. Same applies to hydrogen and the 1434.41s - 1439.81s | loving OEM that could not understand why small leaks in hydrogen in the hydrogen tank can 1439.81s - 1445.75s | affect uh the specific rotations


chunk_id: 154_chunk_26
chunk_text:
when I was injecting uh an unauthenticated message. When I started discussing 1389.91s - 1395.65s | with one of the engineers it ended up being the battery contra- contractors of the AV. I was 1395.65s - 1400.55s | immediately concerned at that point knowing that wear and tear of the con- contact uh surface 1400.57s - 1405.57s | can increase the resistance and lead to excessive excessive heating. And you know what 1405.57s - 1410.61s | comes with after excessive heating and localized uh especially heating for extended 1410.61s - 1416.95s | periods of time? It's of course fire. Um of course I cannot burn an engineer and I cannot 1416.95s - 1422.09s | conduct a test to prove physics the physics behind behind it without risking the battery pack 1422.09s - 1427.29s | burning nonstop for days. So the topic ended there, the vehicle is out, all engineers are 1427.33s - 1434.41s | safe, a couple of hundreds of thousands of users are not. Same applies to hydrogen and the 1434.41s - 1439.81s | loving OEM that could not understand why small leaks in hydrogen in the hydrogen tank can 1439.81s - 1445.75s | affect uh the specific rotations of the valve and can lead to suffocation of the whole 1445.75s - 1452.54s | garage we were working in in a couple of minutes. As I said in the start uh I have no 1452.54s - 1457.90s | magical exploit chains but to prove this finding in an effective way doesn't take much. 1457.90s - 1464.18s | Considering that at the current state we can easily spoof messages in an unencrypted way 1464.18s - 1469.68s | and perform a power cycle with an unrestricted service we can easily find a way to reproduce 1469.68s - 1474.96s | the issue from an exposed interface. Because most of the times manufacturers try to use the 1474.96s - 1481.00s | obscurity factor as a way of mitigation for those findings. But as we saw in the 1481.00s - 1486.44s | architecture modern vehicles are getting more connected than ever so find the exposed 1486.44s - 1491.44s | interface, directly communicate uh with the ECU uh and start sending, that's my advice. 1494.28s - 1500.62s | Even if it needs some cutting around. Now of course after that you have to listen to all the 1500.62s - 1505.90s | excuses about how your


chunk_id: 154_chunk_27
chunk_text:
of the valve and can lead to suffocation of the whole 1445.75s - 1452.54s | garage we were working in in a couple of minutes. As I said in the start uh I have no 1452.54s - 1457.90s | magical exploit chains but to prove this finding in an effective way doesn't take much. 1457.90s - 1464.18s | Considering that at the current state we can easily spoof messages in an unencrypted way 1464.18s - 1469.68s | and perform a power cycle with an unrestricted service we can easily find a way to reproduce 1469.68s - 1474.96s | the issue from an exposed interface. Because most of the times manufacturers try to use the 1474.96s - 1481.00s | obscurity factor as a way of mitigation for those findings. But as we saw in the 1481.00s - 1486.44s | architecture modern vehicles are getting more connected than ever so find the exposed 1486.44s - 1491.44s | interface, directly communicate uh with the ECU uh and start sending, that's my advice. 1494.28s - 1500.62s | Even if it needs some cutting around. Now of course after that you have to listen to all the 1500.62s - 1505.90s | excuses about how your exploit is not realistic and how physical security mitigates issues 1505.90s - 1510.40s | in digital security when at this point it's time to put them inside the vehicle and show 1510.46s - 1517.04s | them adjustable injections where they will either believe you or they will believe in God. Of 1517.04s - 1521.84s | course for safety reasons and when I'm ready to unleash my magical exploit chain there is 1521.84s - 1527.04s | always some party pooper that restricts me from doing so and thank you to this party pooper 1527.04s - 1533.18s | but uh I guess in many times it's not only that they don't believe you but they even want to 1533.18s - 1538.80s | prove you wrong during the night because that's who we are. Next day I found this in the 1538.82s - 1544.26s | garage after some engineer tried to engage the injection from the OBD port from for the 1544.26s - 1550.88s | sake of completeness this is how I left it the previous day. Continuing with the trend of 1550.88s - 1557.88s | naiveness though both from mine and the engineer side I got my hands on an ECU unrelated


chunk_id: 154_chunk_28
chunk_text:
exploit is not realistic and how physical security mitigates issues 1505.90s - 1510.40s | in digital security when at this point it's time to put them inside the vehicle and show 1510.46s - 1517.04s | them adjustable injections where they will either believe you or they will believe in God. Of 1517.04s - 1521.84s | course for safety reasons and when I'm ready to unleash my magical exploit chain there is 1521.84s - 1527.04s | always some party pooper that restricts me from doing so and thank you to this party pooper 1527.04s - 1533.18s | but uh I guess in many times it's not only that they don't believe you but they even want to 1533.18s - 1538.80s | prove you wrong during the night because that's who we are. Next day I found this in the 1538.82s - 1544.26s | garage after some engineer tried to engage the injection from the OBD port from for the 1544.26s - 1550.88s | sake of completeness this is how I left it the previous day. Continuing with the trend of 1550.88s - 1557.88s | naiveness though both from mine and the engineer side I got my hands on an ECU unrelated to 1557.88s - 1563.08s | commercial project and I thought here we are let's do some exploitation. So I started my 1563.08s - 1567.76s | common workflow tried to exploit trying to exploit UDS and trying to evaluate the source of 1567.78s - 1572.78s | randomness but after several hours it didn't seem feasible so I had to resort resort in other 1575.02s - 1580.02s | solutions. So I did this thing apart and started getting a better understanding of its guts. I 1582.20s - 1588.34s | analyzed the hardware parts one by one and started getting deeper inside my rabbit hole. To 1588.34s - 1594.28s | realize that it's one more case of automotive SOC architecture with all the pros and cons 1594.30s - 1599.94s | that come with it. The biggest thing that has to be said about it um and which will help us 1599.94s - 1605.84s | understand some of the issues later on is the fact that ECUs are considered safety related 1605.84s - 1611.28s | components with which require real time responsiveness due to the safety related nature 1611.28s - 1617.66s | on the products that utilize them. So by opening one of the


chunk_id: 154_chunk_29
chunk_text:
to 1557.88s - 1563.08s | commercial project and I thought here we are let's do some exploitation. So I started my 1563.08s - 1567.76s | common workflow tried to exploit trying to exploit UDS and trying to evaluate the source of 1567.78s - 1572.78s | randomness but after several hours it didn't seem feasible so I had to resort resort in other 1575.02s - 1580.02s | solutions. So I did this thing apart and started getting a better understanding of its guts. I 1582.20s - 1588.34s | analyzed the hardware parts one by one and started getting deeper inside my rabbit hole. To 1588.34s - 1594.28s | realize that it's one more case of automotive SOC architecture with all the pros and cons 1594.30s - 1599.94s | that come with it. The biggest thing that has to be said about it um and which will help us 1599.94s - 1605.84s | understand some of the issues later on is the fact that ECUs are considered safety related 1605.84s - 1611.28s | components with which require real time responsiveness due to the safety related nature 1611.28s - 1617.66s | on the products that utilize them. So by opening one of the targets we can easily see what 1617.66s - 1623.80s | happens here. Not only one SOC but two exist on the target board. And this is because of the 1623.82s - 1629.82s | safety related functionality we mentioned earlier. An instruction needs to be executed twice 1629.82s - 1636.26s | in either two different controllers um in this case the secure and application controller 1636.26s - 1642.20s | which we discovered or two different isolated cores and then compared between the two. If the 1642.20s - 1648.14s | output of the instruction is the same it gets executed if not a fallback procedure has to be 1648.14s - 1653.28s | followed depending on the system. Of course this architecture is applicable to higher severity 1653.32s - 1658.80s | safety related devices like airplanes with more secure controllers needed but this is out 1658.80s - 1670.50s | of the scope at least for today. Why this is important? Uh because in the devices in which is 1670.94s - 1676.84s | applicable their fail- failure will result in loss or damage of equipment, environmental 1676.84s - 1681.84s | harm, injury or even death of some users or the surrounding people. And moving


chunk_id: 154_chunk_30
chunk_text:
targets we can easily see what 1617.66s - 1623.80s | happens here. Not only one SOC but two exist on the target board. And this is because of the 1623.82s - 1629.82s | safety related functionality we mentioned earlier. An instruction needs to be executed twice 1629.82s - 1636.26s | in either two different controllers um in this case the secure and application controller 1636.26s - 1642.20s | which we discovered or two different isolated cores and then compared between the two. If the 1642.20s - 1648.14s | output of the instruction is the same it gets executed if not a fallback procedure has to be 1648.14s - 1653.28s | followed depending on the system. Of course this architecture is applicable to higher severity 1653.32s - 1658.80s | safety related devices like airplanes with more secure controllers needed but this is out 1658.80s - 1670.50s | of the scope at least for today. Why this is important? Uh because in the devices in which is 1670.94s - 1676.84s | applicable their fail- failure will result in loss or damage of equipment, environmental 1676.84s - 1681.84s | harm, injury or even death of some users or the surrounding people. And moving closer to the 1681.98s - 1686.98s | hardware we see that not only the supplier was kind enough to spoil the fun and let us uh tell 1689.28s - 1695.22s | us when uh one of where one of the JTAG headers is on the board but they included a second 1695.22s - 1701.10s | header for the secure controller. Unfortunately there uh after connected connecting my 1701.10s - 1708.12s | debugger I discovered that both the JTAG interfaces are locked. And after I desperately 1708.12s - 1714.02s | started clicking on my power supply I realized something really interesting. And here you 1714.02s - 1720.39s | can see uh did it start? Yes so here you can see that the device is locked by normally 1723.59s - 1728.59s | connecting my uh JTAG debugger to the to the unit to the target ECU and by connecting the JTAG 1729.59s - 1734.59s | on the first seconds after boot you can see a nice easter egg that we get debug on the secure 1742.73s - 1747.87s | controller. So yes we got access to the secure controller in this case we basically got to 1747.87s - 1754.11s | enable the


chunk_id: 154_chunk_31
chunk_text:
closer to the 1681.98s - 1686.98s | hardware we see that not only the supplier was kind enough to spoil the fun and let us uh tell 1689.28s - 1695.22s | us when uh one of where one of the JTAG headers is on the board but they included a second 1695.22s - 1701.10s | header for the secure controller. Unfortunately there uh after connected connecting my 1701.10s - 1708.12s | debugger I discovered that both the JTAG interfaces are locked. And after I desperately 1708.12s - 1714.02s | started clicking on my power supply I realized something really interesting. And here you 1714.02s - 1720.39s | can see uh did it start? Yes so here you can see that the device is locked by normally 1723.59s - 1728.59s | connecting my uh JTAG debugger to the to the unit to the target ECU and by connecting the JTAG 1729.59s - 1734.59s | on the first seconds after boot you can see a nice easter egg that we get debug on the secure 1742.73s - 1747.87s | controller. So yes we got access to the secure controller in this case we basically got to 1747.87s - 1754.11s | enable the debug access in a really short period of time during boot uh and as a result we can 1754.13s - 1758.61s | control the execution and dump the memory of the vulnerable controller. I love automotive 1758.61s - 1764.95s | security. I know that you're not yet tired of the fails so on the same ECU and because we are 1764.95s - 1769.59s | talking about the telematics unit there is a Qualcomm modem SOC running which comes with 1769.59s - 1774.73s | these magical pins that if sorted provide us with a nice Qualcomm download mode and after 1774.73s - 1779.39s | discovering some other pins seemingly matching a USB port pin out and performing the 1779.41s - 1785.45s | dangerous act of connecting a random USB from an ECU purchased from eBay we realized that our 1785.45s - 1791.69s | assumptions are correct. After I dumped the firmware with more than one ways as you see I 1791.69s - 1796.43s | realized that the automotive related controller has several references to the system clock 1796.43s - 1800.63s | which confused me even more. As my process of discovering weak sources of randomness 1800.63s - 1806.57s | till now


chunk_id: 154_chunk_32
chunk_text:
debug access in a really short period of time during boot uh and as a result we can 1754.13s - 1758.61s | control the execution and dump the memory of the vulnerable controller. I love automotive 1758.61s - 1764.95s | security. I know that you're not yet tired of the fails so on the same ECU and because we are 1764.95s - 1769.59s | talking about the telematics unit there is a Qualcomm modem SOC running which comes with 1769.59s - 1774.73s | these magical pins that if sorted provide us with a nice Qualcomm download mode and after 1774.73s - 1779.39s | discovering some other pins seemingly matching a USB port pin out and performing the 1779.41s - 1785.45s | dangerous act of connecting a random USB from an ECU purchased from eBay we realized that our 1785.45s - 1791.69s | assumptions are correct. After I dumped the firmware with more than one ways as you see I 1791.69s - 1796.43s | realized that the automotive related controller has several references to the system clock 1796.43s - 1800.63s | which confused me even more. As my process of discovering weak sources of randomness 1800.63s - 1806.57s | till now was unbeatable. So what is happening here? Went back to my terminal and performed 1806.59s - 1813.73s | some more tests and as you see here uh when the seed capture goes faster we can make some 1813.73s - 1818.71s | really important observations. Which is that the middle byte of the seed is incrementing by 1818.71s - 1823.71s | one. My assumptions seemed more correct than ever but I was also more confused than ever. Uh 1825.65s - 1830.55s | there was some missing piece that I was struggling to find. Some implemented mitigation that 1830.55s - 1837.54s | was in front of me but could not see it. What this mitigation was? Of course security 1837.56s - 1841.90s | through obscurity as always with automotive and I started thinking what if the ECU is 1841.90s - 1847.14s | restricting software power cycles for safety reasons. As we are talking about a telematics 1847.14s - 1853.24s | unit that has to be always available for SOS calls. And if that's the case how can we 1853.24s - 1858.94s | control a power cycle in more than uh more ways than an ECU reset? And that's where my 1858.94s -


chunk_id: 154_chunk_33
chunk_text:
was unbeatable. So what is happening here? Went back to my terminal and performed 1806.59s - 1813.73s | some more tests and as you see here uh when the seed capture goes faster we can make some 1813.73s - 1818.71s | really important observations. Which is that the middle byte of the seed is incrementing by 1818.71s - 1823.71s | one. My assumptions seemed more correct than ever but I was also more confused than ever. Uh 1825.65s - 1830.55s | there was some missing piece that I was struggling to find. Some implemented mitigation that 1830.55s - 1837.54s | was in front of me but could not see it. What this mitigation was? Of course security 1837.56s - 1841.90s | through obscurity as always with automotive and I started thinking what if the ECU is 1841.90s - 1847.14s | restricting software power cycles for safety reasons. As we are talking about a telematics 1847.14s - 1853.24s | unit that has to be always available for SOS calls. And if that's the case how can we 1853.24s - 1858.94s | control a power cycle in more than uh more ways than an ECU reset? And that's where my 1858.94s - 1865.32s | favorite re- relay comes into play. And we immediately see not only a duplicate but a 1865.34s - 1872.13s | complete compromise of the unit here. POC for this will be published under my tool Karen 1874.67s - 1879.83s | Caribou Next uh but it's nothing that you cannot easily make in a couple of minutes. The 1879.83s - 1883.91s | main reason that this happens is because there is always a battery in those telematics 1883.91s - 1889.41s | systems to mitigate downtime and unexpected power cycle that will restrict the unit from 1889.41s - 1894.41s | performing an SOS uh call during an emergency. So we got a bit pranked for a second there but 1894.75s - 1899.75s | found a way through eventually. And for the smarties out there that uh this is not only 1902.75s - 1908.77s | applicable to controlled uh environments with power supplies but many of these nowadays 1908.77s - 1915.01s | come uh with external on or internal for pass sensor vehicles battery isolators. Mainly 1915.01s - 1921.45s | used in safety related incidents to cut power and mitigate the risk of fires and other 1921.45s - 1926.99s | issues.


chunk_id: 154_chunk_34
chunk_text:
1865.32s | favorite re- relay comes into play. And we immediately see not only a duplicate but a 1865.34s - 1872.13s | complete compromise of the unit here. POC for this will be published under my tool Karen 1874.67s - 1879.83s | Caribou Next uh but it's nothing that you cannot easily make in a couple of minutes. The 1879.83s - 1883.91s | main reason that this happens is because there is always a battery in those telematics 1883.91s - 1889.41s | systems to mitigate downtime and unexpected power cycle that will restrict the unit from 1889.41s - 1894.41s | performing an SOS uh call during an emergency. So we got a bit pranked for a second there but 1894.75s - 1899.75s | found a way through eventually. And for the smarties out there that uh this is not only 1902.75s - 1908.77s | applicable to controlled uh environments with power supplies but many of these nowadays 1908.77s - 1915.01s | come uh with external on or internal for pass sensor vehicles battery isolators. Mainly 1915.01s - 1921.45s | used in safety related incidents to cut power and mitigate the risk of fires and other 1921.45s - 1926.99s | issues. Uh but I used to I used it to bypass restrictions that were only possible on 1926.99s - 1931.73s | individual ECUs. And now by controlling the power supply externally through the battery 1931.73s - 1937.67s | isolator we can perform all these attacks in a combined manner in full vehicles. Here we 1937.67s - 1942.91s | see the exposed battery isolator of heavy duty vehicles. And here we see something I 1942.91s - 1947.89s | discovered a couple of weeks ago. The battery isolator of a passenger vehicle which of 1947.89s - 1952.93s | course made me laugh but uh it will make me cry probably in the future when I will get into 1952.93s - 1959.01s | more politics with the manufacturers about the applicability of my future findings. This is a 1959.01s - 1965.17s | sample list of the applicable findings for the ECU. And of course I had no response so I guess 1965.17s - 1971.85s | nothing to see here. But it's not only dark and stormy days. While everything we said now is 1971.85s - 1978.09s | applicable to most of the OEMs. While this is only a small uh this is only a


chunk_id: 154_chunk_35
chunk_text:
Uh but I used to I used it to bypass restrictions that were only possible on 1926.99s - 1931.73s | individual ECUs. And now by controlling the power supply externally through the battery 1931.73s - 1937.67s | isolator we can perform all these attacks in a combined manner in full vehicles. Here we 1937.67s - 1942.91s | see the exposed battery isolator of heavy duty vehicles. And here we see something I 1942.91s - 1947.89s | discovered a couple of weeks ago. The battery isolator of a passenger vehicle which of 1947.89s - 1952.93s | course made me laugh but uh it will make me cry probably in the future when I will get into 1952.93s - 1959.01s | more politics with the manufacturers about the applicability of my future findings. This is a 1959.01s - 1965.17s | sample list of the applicable findings for the ECU. And of course I had no response so I guess 1965.17s - 1971.85s | nothing to see here. But it's not only dark and stormy days. While everything we said now is 1971.85s - 1978.09s | applicable to most of the OEMs. While this is only a small uh this is only a small subject 1978.09s - 1984.09s | sub subset of the issues we see every day. And they clearly are some relics of 1984.09s - 1989.77s | vulnerabilities discovered in modern vehicles and components. And while several CVEs are 1989.77s - 1996.51s | currently stuck you saw because of uh the unacceptable attitude of the industry. There is 1996.51s - 2001.81s | always someone that breaks the norm and makes us smile and not because they made everything 2001.81s - 2008.25s | perfect but because they proved a point. So one small manufacturer came to us for some common 2008.25s - 2013.85s | service. We started evaluating the unit and after several several tries we didn't manage to 2013.85s - 2019.79s | discover a single entry point to the custom ECU. While the hardware used was one of the 2019.79s - 2026.43s | cheapest of the self hardware a developer can buy. And what was the solution in this case? One 2026.43s - 2031.09s | of the cheapest of the self hardware a developer can buy. And we're talking about this 2031.09s - 2037.83s | mighty ESP32 a low cost, low power SOC that was fitting perfectly the needs of the


chunk_id: 154_chunk_36
chunk_text:
small subject 1978.09s - 1984.09s | sub subset of the issues we see every day. And they clearly are some relics of 1984.09s - 1989.77s | vulnerabilities discovered in modern vehicles and components. And while several CVEs are 1989.77s - 1996.51s | currently stuck you saw because of uh the unacceptable attitude of the industry. There is 1996.51s - 2001.81s | always someone that breaks the norm and makes us smile and not because they made everything 2001.81s - 2008.25s | perfect but because they proved a point. So one small manufacturer came to us for some common 2008.25s - 2013.85s | service. We started evaluating the unit and after several several tries we didn't manage to 2013.85s - 2019.79s | discover a single entry point to the custom ECU. While the hardware used was one of the 2019.79s - 2026.43s | cheapest of the self hardware a developer can buy. And what was the solution in this case? One 2026.43s - 2031.09s | of the cheapest of the self hardware a developer can buy. And we're talking about this 2031.09s - 2037.83s | mighty ESP32 a low cost, low power SOC that was fitting perfectly the needs of the OEM in 2037.83s - 2043.27s | this case. Of course it's not built for safety critical functionality and its main focus is 2043.27s - 2049.85s | automation. But for the case we needed for for the case needed there was nothing more 2049.85s - 2055.75s | needed by the OEM in this case. And from a security standpoint it proved a big point. Because 2055.77s - 2061.55s | this ten dollar ESP32 in contrary to what comes with hundreds of thousands of dollars of 2061.55s - 2067.71s | automotive uh worth of automotive SOCs comes standard with an RNG. It uses a combination of 2067.71s - 2073.29s | thermal noise sourced from the hardware analog to digital converter and combines it with 2073.29s - 2078.99s | the asynchronous clock mismatch for true random generation as we call it in this industry. And 2079.01s - 2084.01s | I say it again with ten dollars but does it solve completely the problem here? Of course 2086.31s - 2091.73s | not. There are still ways to bypass these mitigations but the point is how difficult and 2091.73s - 2097.29s | financially viable you make it for an attacker to perform an attack like


chunk_id: 154_chunk_37
chunk_text:
OEM in 2037.83s - 2043.27s | this case. Of course it's not built for safety critical functionality and its main focus is 2043.27s - 2049.85s | automation. But for the case we needed for for the case needed there was nothing more 2049.85s - 2055.75s | needed by the OEM in this case. And from a security standpoint it proved a big point. Because 2055.77s - 2061.55s | this ten dollar ESP32 in contrary to what comes with hundreds of thousands of dollars of 2061.55s - 2067.71s | automotive uh worth of automotive SOCs comes standard with an RNG. It uses a combination of 2067.71s - 2073.29s | thermal noise sourced from the hardware analog to digital converter and combines it with 2073.29s - 2078.99s | the asynchronous clock mismatch for true random generation as we call it in this industry. And 2079.01s - 2084.01s | I say it again with ten dollars but does it solve completely the problem here? Of course 2086.31s - 2091.73s | not. There are still ways to bypass these mitigations but the point is how difficult and 2091.73s - 2097.29s | financially viable you make it for an attacker to perform an attack like this. It's not about 2097.29s - 2101.93s | how sophisticated an exploit is in the end it's about who has the biggest biggest budget to 2101.93s - 2107.37s | invest. So the mitigation is clearly about how expensive you make it for an attacker to break 2107.39s - 2113.39s | into your system, steal your IP or even potentially perform coordinated attacks. And while 2113.39s - 2118.03s | looking at systems like the PlayStation running non safety critical chips that implement 2118.03s - 2122.87s | state of the art mitigations for these issues and our computer on wheels cannot even mitigate 2122.87s - 2128.27s | the basics I'm left to wonder is there any light in the end of the tunnel? And my answer is 2128.27s - 2135.27s | that it's up to us all of us here to make the best out of it. The best out of our work and our 2135.31s - 2140.65s | research. To pass out our culture to the people that we're working with. From the higher to 2140.65s - 2146.29s | the lower level. Not with bitching not with attitudes but with scientific proof with our 2146.29s - 2152.63s | POCs with our


chunk_id: 154_chunk_38
chunk_text:
this. It's not about 2097.29s - 2101.93s | how sophisticated an exploit is in the end it's about who has the biggest biggest budget to 2101.93s - 2107.37s | invest. So the mitigation is clearly about how expensive you make it for an attacker to break 2107.39s - 2113.39s | into your system, steal your IP or even potentially perform coordinated attacks. And while 2113.39s - 2118.03s | looking at systems like the PlayStation running non safety critical chips that implement 2118.03s - 2122.87s | state of the art mitigations for these issues and our computer on wheels cannot even mitigate 2122.87s - 2128.27s | the basics I'm left to wonder is there any light in the end of the tunnel? And my answer is 2128.27s - 2135.27s | that it's up to us all of us here to make the best out of it. The best out of our work and our 2135.31s - 2140.65s | research. To pass out our culture to the people that we're working with. From the higher to 2140.65s - 2146.29s | the lower level. Not with bitching not with attitudes but with scientific proof with our 2146.29s - 2152.63s | POCs with our posts and our talks. Let's make the world a safer place one POC at a time. And 2152.63s - 2157.63s | in honor to this year's theme remember to take back the internet we need to engage. Thank you. 2158.53s - 2186.35s | Any questions? Hi awesome talk thank you. Um did you think about going to NHTSA the National 2190.79s - 2195.59s | Highway Transportation Safety Administration who is responsible for implementing safety 2195.59s - 2201.47s | standards for car manufacturers? Yeah look there are several things that we can do. I agree 2201.47s - 2208.31s | with you. The problem is that you have to take several steps into reaching a point that I 2208.31s - 2214.01s | will follow your advice. I mean the specific advice you gave right now. It's like I agree 2214.01s - 2220.99s | with you but I would expect that the manufacturer already handled it. Of course in many of 2220.99s - 2225.99s | the cases maybe I did it. I cannot reveal it to you but maybe I did it. But I have to say that 2229.23s - 2233.43s | there is a need for something to change in this industry


chunk_id: 154_chunk_39
chunk_text:
posts and our talks. Let's make the world a safer place one POC at a time. And 2152.63s - 2157.63s | in honor to this year's theme remember to take back the internet we need to engage. Thank you. 2158.53s - 2186.35s | Any questions? Hi awesome talk thank you. Um did you think about going to NHTSA the National 2190.79s - 2195.59s | Highway Transportation Safety Administration who is responsible for implementing safety 2195.59s - 2201.47s | standards for car manufacturers? Yeah look there are several things that we can do. I agree 2201.47s - 2208.31s | with you. The problem is that you have to take several steps into reaching a point that I 2208.31s - 2214.01s | will follow your advice. I mean the specific advice you gave right now. It's like I agree 2214.01s - 2220.99s | with you but I would expect that the manufacturer already handled it. Of course in many of 2220.99s - 2225.99s | the cases maybe I did it. I cannot reveal it to you but maybe I did it. But I have to say that 2229.23s - 2233.43s | there is a need for something to change in this industry and that's what I had to clarify 2233.49s - 2238.49s | here. Totally agree and it that would be the perfect world wouldn't it if you know people I think 2241.83s - 2246.83s | most engineers want to do the right thing. They want to operate securely and write good code 2246.83s - 2251.85s | and and all the rest of it. But then to your point there's that sprinkle of capitalism and um 2254.75s - 2259.75s | budgetary this and that and somebody says well it's good enough. And then you know that's that's 2260.01s - 2265.01s | why we do sometimes need those government agencies even though they themselves are not the 2266.35s - 2272.71s | most efficient right. I agree there needs to be a balance but I think there needs to be a 2272.71s - 2278.79s | balance in all the ways you know even for who talks where. You know there are the commercial 2278.79s - 2283.19s | conferences that everyone brags about from the industry. We also need to talk about stuff. We 2283.19s - 2289.57s | also need to be able to get the stand and start discussing about these things. Thank you


chunk_id: 154_chunk_40
chunk_text:
and that's what I had to clarify 2233.49s - 2238.49s | here. Totally agree and it that would be the perfect world wouldn't it if you know people I think 2241.83s - 2246.83s | most engineers want to do the right thing. They want to operate securely and write good code 2246.83s - 2251.85s | and and all the rest of it. But then to your point there's that sprinkle of capitalism and um 2254.75s - 2259.75s | budgetary this and that and somebody says well it's good enough. And then you know that's that's 2260.01s - 2265.01s | why we do sometimes need those government agencies even though they themselves are not the 2266.35s - 2272.71s | most efficient right. I agree there needs to be a balance but I think there needs to be a 2272.71s - 2278.79s | balance in all the ways you know even for who talks where. You know there are the commercial 2278.79s - 2283.19s | conferences that everyone brags about from the industry. We also need to talk about stuff. We 2283.19s - 2289.57s | also need to be able to get the stand and start discussing about these things. Thank you very 2289.59s - 2296.00s | much it was awesome. Thank you. Hi again thank you for the talk. Amazing talk. But um do you 2296.00s - 2301.18s | think emerging tech emerging technologies such as automotive ethernet or secure CAN transceivers 2301.18s - 2306.32s | might help mitigate some of the risk? Definitely definitely and we see a change in the 2306.32s - 2310.82s | industry. As I said software defined vehicles and centralized architecture is something that 2310.82s - 2317.06s | we we hear about a lot of years now but it's not yet implemented in many vehicles and that's 2317.08s - 2323.04s | why I was talking about the differences between uh mainstream OEMs and the new type of OEMs 2323.04s - 2327.88s | that are basically IT companies that started building cars. So this is the main difference. 2327.88s - 2331.76s | They have way more experience in this but the industry just needs to catch up. They are 2331.76s - 2338.75s | exposing so many things and they need to do something about it. Thank you. Thanks. Thank you 2338.75s - 2342.11s | for thank you for your talk. This was great. My question is regarding


chunk_id: 154_chunk_41
chunk_text:
very 2289.59s - 2296.00s | much it was awesome. Thank you. Hi again thank you for the talk. Amazing talk. But um do you 2296.00s - 2301.18s | think emerging tech emerging technologies such as automotive ethernet or secure CAN transceivers 2301.18s - 2306.32s | might help mitigate some of the risk? Definitely definitely and we see a change in the 2306.32s - 2310.82s | industry. As I said software defined vehicles and centralized architecture is something that 2310.82s - 2317.06s | we we hear about a lot of years now but it's not yet implemented in many vehicles and that's 2317.08s - 2323.04s | why I was talking about the differences between uh mainstream OEMs and the new type of OEMs 2323.04s - 2327.88s | that are basically IT companies that started building cars. So this is the main difference. 2327.88s - 2331.76s | They have way more experience in this but the industry just needs to catch up. They are 2331.76s - 2338.75s | exposing so many things and they need to do something about it. Thank you. Thanks. Thank you 2338.75s - 2342.11s | for thank you for your talk. This was great. My question is regarding your tool kit. Is 2342.11s - 2347.09s | everything you know hand built? Can you? My question is about your tool kit. Is everything 2347.09s - 2352.33s | Python scripts that you build or is there a software or platform uh that we? Um no basically 2352.33s - 2358.17s | it's a modular tool and this is not only the POC but you can use it to perform the same 2358.17s - 2364.21s | attacks to other vehicles. What's the name of that tool? Uh Carrying Caribou Next. Uh it's a 2364.21s - 2368.21s | fork of the original Carrying Caribou which is a state of the industry for a lot of years 2368.21s - 2373.89s | but I just made the fork because of uh the slowness of the development of this project. Thank 2373.89s - 2374.93s | you. You're welcome.


chunk_id: 154_chunk_42
chunk_text:
your tool kit. Is 2342.11s - 2347.09s | everything you know hand built? Can you? My question is about your tool kit. Is everything 2347.09s - 2352.33s | Python scripts that you build or is there a software or platform uh that we? Um no basically 2352.33s - 2358.17s | it's a modular tool and this is not only the POC but you can use it to perform the same 2358.17s - 2364.21s | attacks to other vehicles. What's the name of that tool? Uh Carrying Caribou Next. Uh it's a 2364.21s - 2368.21s | fork of the original Carrying Caribou which is a state of the industry for a lot of years 2368.21s - 2373.89s | but I just made the fork because of uh the slowness of the development of this project. Thank 2373.89s - 2374.93s | you. You're welcome.


chunk_id: 155_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=G7GwXu684JY", "title": "DEF CON 32 - Sshamble Unexpected Exposures in the Secure Shell - HD Moore, Rob King", "description": "The Secure Shell (SSH) has evolved from a remote shell service to a standardized secure transport that is second only to Transport Layer Security (TLS) in terms of exposure and popularity. SSH is no longer just for POSIX operating systems; SSH services can be found in everything from network devices, to source code forges, to Windows-based file transfer tools. While OpenSSH is still the most prominent implementation, it's now just one of dozens, and these include a handful of libraries that drive a wide range of applications. This presentation digs deep into SSH, the lesser-known implementations, many of the surprising security issues found along the way, and how to exploit them. As part of this talk, we will release an open source tool, dubbed \"sshamble\", that assists with research and security testing of SSH services.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2723, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.05s - 5.75s | This text was transcribed using whisper model: large-v2 Hey guys, uh, so we're gonna talk about SSH. And this has been probably the most exciting year in 5.75s - 12.59s | SSH since X2.cd got lea- X2.cd got leaked by Teso. So, um, uh, props to anyone who used that. 12.59s - 17.59s | Uh, so, uh, SSH for folks who aren't aware, um, you probably, probably should be or if you 17.59s - 21.57s | don't know what SSH is, but, um, SSH, secure shell, port 22, the thing we've been using to 21.57s - 26.53s | admin the internet for many years, like almost 30 years. Um, there's really two flavors of 26.53s - 31.09s | SSH that we use the most. There's OpenSH, which is like 80 something percent of all SSH 31.09s - 35.09s | installations. And then there's DropBear, which is like another like 5 to 8 percent. And then 35.09s - 39.71s | there's a long tail of random weird stuff out there. So we decided to do some research into 39.71s - 44.81s | first looking into the XC backdoor. And then part of that, we just accidentally found a couple 44.81s - 47.67s | tens of thousands of shells. And we're like, well, let's go figure out what all these random 47.67s - 51.69s | things, all these free shells were.


chunk_id: 155_chunk_1
chunk_text:
12.59s | SSH since X2.cd got lea- X2.cd got leaked by Teso. So, um, uh, props to anyone who used that. 12.59s - 17.59s | Uh, so, uh, SSH for folks who aren't aware, um, you probably, probably should be or if you 17.59s - 21.57s | don't know what SSH is, but, um, SSH, secure shell, port 22, the thing we've been using to 21.57s - 26.53s | admin the internet for many years, like almost 30 years. Um, there's really two flavors of 26.53s - 31.09s | SSH that we use the most. There's OpenSH, which is like 80 something percent of all SSH 31.09s - 35.09s | installations. And then there's DropBear, which is like another like 5 to 8 percent. And then 35.09s - 39.71s | there's a long tail of random weird stuff out there. So we decided to do some research into 39.71s - 44.81s | first looking into the XC backdoor. And then part of that, we just accidentally found a couple 44.81s - 47.67s | tens of thousands of shells. And we're like, well, let's go figure out what all these random 47.67s - 51.69s | things, all these free shells were. Uh, and that led to this giant pile of work and this open 51.69s - 55.09s | source tool. Um, so if you want to play with the toolkit, you can get it right now. It's this, 55.11s - 60.09s | the shamble.com SSH and BLE. And that goes to GitHub and you can go grab the stuff and play 60.09s - 63.79s | with it. And it's a big hot mess, but we're making it better. And it should be a lot of fun as 63.79s - 67.89s | we start cranking on, make the polishing up, making it cool. Um, so with that, we'll go ahead 67.89s - 73.99s | and get started. Um, fortunately we're only doing 67 slides in 45 minutes, not 100. So we 73.99s - 78.93s | had a little breathing room this time. Um, so I'm sure we're all very much aware of the XC 78.93s - 82.77s | utils backdoor. Well, step back a little bit. So there's, you know, four major events this 82.79s - 86.89s | year in SSH that were really important. Obviously XC utils backdoor targeted SSH using the 86.89s - 92.89s | system D patches and Debian


chunk_id: 155_chunk_2
chunk_text:
Uh, and that led to this giant pile of work and this open 51.69s - 55.09s | source tool. Um, so if you want to play with the toolkit, you can get it right now. It's this, 55.11s - 60.09s | the shamble.com SSH and BLE. And that goes to GitHub and you can go grab the stuff and play 60.09s - 63.79s | with it. And it's a big hot mess, but we're making it better. And it should be a lot of fun as 63.79s - 67.89s | we start cranking on, make the polishing up, making it cool. Um, so with that, we'll go ahead 67.89s - 73.99s | and get started. Um, fortunately we're only doing 67 slides in 45 minutes, not 100. So we 73.99s - 78.93s | had a little breathing room this time. Um, so I'm sure we're all very much aware of the XC 78.93s - 82.77s | utils backdoor. Well, step back a little bit. So there's, you know, four major events this 82.79s - 86.89s | year in SSH that were really important. Obviously XC utils backdoor targeted SSH using the 86.89s - 92.89s | system D patches and Debian and, uh, Red Hat builds of OpenSH. We also had the really cool 92.89s - 96.13s | Terrapin vulnerability, which affected pretty much everything because of the truncation 96.13s - 100.81s | attack. Um, we also had, uh, the regression vulnerabilities, the really fantastic work by the 100.81s - 105.51s | Qualys Threat Research Unit. Um, and then the other regression bug found by Solar Designer 105.51s - 109.51s | that only affected Red Hat. And regression was amazing. It's a signal re-entrance bug that 109.55s - 114.33s | gets you remote route in OpenSH by default. It just takes six hours on a 32-bit machine or 114.33s - 119.03s | weeks or months on a 64-bit to compromise. So, but it's been a really cool year. Um, one of my 119.03s - 123.67s | favorite SSH bugs this year kind of flew under the radar. Um, the guys at Watchtower Labs did a 123.67s - 128.43s | really cool analysis of the move-it vulnerability that uses the SFTP server. And so they found a 128.43s - 132.41s | vulnerability where any public key being sent to the service, um, would be treated like a file 132.41s - 136.41s |


chunk_id: 155_chunk_3
chunk_text:
and, uh, Red Hat builds of OpenSH. We also had the really cool 92.89s - 96.13s | Terrapin vulnerability, which affected pretty much everything because of the truncation 96.13s - 100.81s | attack. Um, we also had, uh, the regression vulnerabilities, the really fantastic work by the 100.81s - 105.51s | Qualys Threat Research Unit. Um, and then the other regression bug found by Solar Designer 105.51s - 109.51s | that only affected Red Hat. And regression was amazing. It's a signal re-entrance bug that 109.55s - 114.33s | gets you remote route in OpenSH by default. It just takes six hours on a 32-bit machine or 114.33s - 119.03s | weeks or months on a 64-bit to compromise. So, but it's been a really cool year. Um, one of my 119.03s - 123.67s | favorite SSH bugs this year kind of flew under the radar. Um, the guys at Watchtower Labs did a 123.67s - 128.43s | really cool analysis of the move-it vulnerability that uses the SFTP server. And so they found a 128.43s - 132.41s | vulnerability where any public key being sent to the service, um, would be treated like a file 132.41s - 136.41s | path, like the binary blog is treated like a file path. And it just opened random UNC URLs and 136.41s - 139.65s | all kinds of fun stuff. They threaded like a million little needles to be able to get a shell 139.65s - 142.89s | remotely and move it. But the really cool thing about that bug is it affected every other 142.89s - 147.79s | vendor also using IPWorks as the underlying library. So, they actually uncovered like a supply 147.79s - 152.57s | chain bug, if you will, which is really neat. So, going kind of back on topic again, um, the 152.57s - 158.77s | XE Utils vulnerability or backdoor was amazing. It was like it's own little Netflix docuseries, 158.77s - 163.57s | right? We're going to see like the true crime of XE Utils for years. But like who is Gia Tan? 163.57s - 167.41s | Like it's going to, it's the most dramatic thing to happen to InfoSec in a very long time. Um, 167.41s - 171.11s | so the, this is a multi-year campaign where this person, um, contributed to open source for a 171.11s - 175.55s | long time, then eventually


chunk_id: 155_chunk_4
chunk_text:
path, like the binary blog is treated like a file path. And it just opened random UNC URLs and 136.41s - 139.65s | all kinds of fun stuff. They threaded like a million little needles to be able to get a shell 139.65s - 142.89s | remotely and move it. But the really cool thing about that bug is it affected every other 142.89s - 147.79s | vendor also using IPWorks as the underlying library. So, they actually uncovered like a supply 147.79s - 152.57s | chain bug, if you will, which is really neat. So, going kind of back on topic again, um, the 152.57s - 158.77s | XE Utils vulnerability or backdoor was amazing. It was like it's own little Netflix docuseries, 158.77s - 163.57s | right? We're going to see like the true crime of XE Utils for years. But like who is Gia Tan? 163.57s - 167.41s | Like it's going to, it's the most dramatic thing to happen to InfoSec in a very long time. Um, 167.41s - 171.11s | so the, this is a multi-year campaign where this person, um, contributed to open source for a 171.11s - 175.55s | long time, then eventually kind of twisted the knife and tried to backdoor the world. And I got 175.55s - 180.15s | caught the very last minute by, uh, Andrews Frond who says, hey, my SSH is taking slightly too 180.15s - 183.89s | much longer than it should. And then unraveled the whole thing right before it got put into the 183.89s - 188.19s | stable distributions. So, we got really close to the whole internet being backdoored. Uh, but 188.19s - 191.67s | what was really important about that backdoor that it was a nobody but us backdoor, which is 191.67s - 194.97s | normally, you know, normally the US government's famous for those. But in this case, who 194.97s - 199.51s | knows who it was. Um, in fact, it was a encryption key controlled by the attacker that only 199.51s - 202.91s | people with a private key had access could abuse the backdoor. That was really a neat thing 202.91s - 207.65s | about it. So, we thought it'd be fun to go figure out who this Gia Tan person was. And we're 207.65s - 211.89s | like, hey, you know, everyone's looking for Gia Tan, we're going to


chunk_id: 155_chunk_5
chunk_text:
kind of twisted the knife and tried to backdoor the world. And I got 175.55s - 180.15s | caught the very last minute by, uh, Andrews Frond who says, hey, my SSH is taking slightly too 180.15s - 183.89s | much longer than it should. And then unraveled the whole thing right before it got put into the 183.89s - 188.19s | stable distributions. So, we got really close to the whole internet being backdoored. Uh, but 188.19s - 191.67s | what was really important about that backdoor that it was a nobody but us backdoor, which is 191.67s - 194.97s | normally, you know, normally the US government's famous for those. But in this case, who 194.97s - 199.51s | knows who it was. Um, in fact, it was a encryption key controlled by the attacker that only 199.51s - 202.91s | people with a private key had access could abuse the backdoor. That was really a neat thing 202.91s - 207.65s | about it. So, we thought it'd be fun to go figure out who this Gia Tan person was. And we're 207.65s - 211.89s | like, hey, you know, everyone's looking for Gia Tan, we're going to go find some Gia Tan. Uh, 211.89s - 215.15s | and we're very happy, Alfredo, if you're out here, thank you so much for designing your 215.15s - 220.87s | graphics. They're amazing. Um, so we decided to go hunting. And, you know, before we go 220.89s - 225.67s | hunting for Gia specifically, we want to talk a little bit about SSH protocol. So, uh, Gia Tan 225.67s - 230.71s | targeted SSH, uh, with ex- with ex-utils backdoor. So, we're going to target Gia Tan using 230.71s - 236.19s | SSH. But before we go there, we need to talk about how SSH public key authentication 236.19s - 240.15s | works. So, SSH public key authentication is two stage. The first thing you do is say, hey 240.15s - 244.19s | server, would you accept this public key for this username on your machine? And it says, yeah, 244.19s - 247.89s | sure. And then you have to sign this big blob of data that proves that you have the private 247.89s - 251.29s | key. But you can do that first part without the private key at all. And it's really cool. 251.31s - 255.01s | There's


chunk_id: 155_chunk_6
chunk_text:
go find some Gia Tan. Uh, 211.89s - 215.15s | and we're very happy, Alfredo, if you're out here, thank you so much for designing your 215.15s - 220.87s | graphics. They're amazing. Um, so we decided to go hunting. And, you know, before we go 220.89s - 225.67s | hunting for Gia specifically, we want to talk a little bit about SSH protocol. So, uh, Gia Tan 225.67s - 230.71s | targeted SSH, uh, with ex- with ex-utils backdoor. So, we're going to target Gia Tan using 230.71s - 236.19s | SSH. But before we go there, we need to talk about how SSH public key authentication 236.19s - 240.15s | works. So, SSH public key authentication is two stage. The first thing you do is say, hey 240.15s - 244.19s | server, would you accept this public key for this username on your machine? And it says, yeah, 244.19s - 247.89s | sure. And then you have to sign this big blob of data that proves that you have the private 247.89s - 251.29s | key. But you can do that first part without the private key at all. And it's really cool. 251.31s - 255.01s | There's been a module in Metasploit for it since 2012, lets you take someone else's public key 255.01s - 258.15s | that you got however you got, and then check a bunch of servers to see whether that public key 258.15s - 261.19s | has access to, uh, those servers for that username. And you can, so you can kind of see 261.19s - 264.75s | where this is going. Um, it's, there's this great common or open SSH saying, is this a 264.75s - 267.63s | problem? I don't know. But it's been there forever. It's just kind of the protocol spec at 267.63s - 271.33s | this point. It is what it is. Maybe it's not a big security deal. So, we decided to create 271.33s - 275.03s | this thing called Shamble, which started off being a half-off scanner for SSH. So, what we 275.03s - 278.67s | do is you take a bunch of public keys, and then you'd like put them in Shamble and scan the 278.69s - 283.19s | whole internet saying, what on the internet can you access using these public keys? And the 283.19s - 287.53s | idea is like, well, if we


chunk_id: 155_chunk_7
chunk_text:
been a module in Metasploit for it since 2012, lets you take someone else's public key 255.01s - 258.15s | that you got however you got, and then check a bunch of servers to see whether that public key 258.15s - 261.19s | has access to, uh, those servers for that username. And you can, so you can kind of see 261.19s - 264.75s | where this is going. Um, it's, there's this great common or open SSH saying, is this a 264.75s - 267.63s | problem? I don't know. But it's been there forever. It's just kind of the protocol spec at 267.63s - 271.33s | this point. It is what it is. Maybe it's not a big security deal. So, we decided to create 271.33s - 275.03s | this thing called Shamble, which started off being a half-off scanner for SSH. So, what we 275.03s - 278.67s | do is you take a bunch of public keys, and then you'd like put them in Shamble and scan the 278.69s - 283.19s | whole internet saying, what on the internet can you access using these public keys? And the 283.19s - 287.53s | idea is like, well, if we have, let's say, Geotan's public key, we can find all the servers 287.53s - 290.23s | that they use, and then from there we figure out who they are. So, that was, that was the 290.23s - 294.31s | idea. But it ended up evolving into this massive tool to find all kinds of other crap 294.31s - 297.61s | because of all the things that we found. So, you know, first thing you do say is, hey, my 297.61s - 300.95s | name's Geotan, we're gonna go download your GitHub keys. So, we grabbed their two GitHub 300.95s - 305.51s | keys, which are still present today, um, and basically took those two public keys, ran them 305.53s - 309.69s | to Shamble, and then, um, you know, threw that at the whole internet, all the, all the SSH 309.69s - 314.07s | daemons we could find, let it grind out for a couple days. And what's, what's exciting about 314.07s - 316.77s | it is like, we spent the whole weekend on this, we hadn't slept or anything like that, Rob and 316.77s - 320.41s | I were like working at four in the morning, we're like, we


chunk_id: 155_chunk_8
chunk_text:
have, let's say, Geotan's public key, we can find all the servers 287.53s - 290.23s | that they use, and then from there we figure out who they are. So, that was, that was the 290.23s - 294.31s | idea. But it ended up evolving into this massive tool to find all kinds of other crap 294.31s - 297.61s | because of all the things that we found. So, you know, first thing you do say is, hey, my 297.61s - 300.95s | name's Geotan, we're gonna go download your GitHub keys. So, we grabbed their two GitHub 300.95s - 305.51s | keys, which are still present today, um, and basically took those two public keys, ran them 305.53s - 309.69s | to Shamble, and then, um, you know, threw that at the whole internet, all the, all the SSH 309.69s - 314.07s | daemons we could find, let it grind out for a couple days. And what's, what's exciting about 314.07s - 316.77s | it is like, we spent the whole weekend on this, we hadn't slept or anything like that, Rob and 316.77s - 320.41s | I were like working at four in the morning, we're like, we got one, we got a hit for GEA. It's 320.41s - 324.35s | really exciting. Um, in the meantime, we're melting all of our DigitalOcean nodes, so this 324.35s - 328.09s | is this poor little DO droplet just like falling apart as we're like destroying it. It's, I 328.09s - 332.79s | think it sent like a terabyte of traffic at this point, like we're, yeah, we made DO VMs 332.81s - 338.41s | very unhappy. Um, so, just heads up for law enforcement, um, we sent the public key for 338.41s - 343.05s | GEATAN to every server on the internet from our IPs. We are not GEATAN, we do not backdoor 343.05s - 346.79s | exe-utils, even though it very much looks like we did. So we sort of accidentally framed 346.79s - 351.39s | ourselves, uh, we realized that after the fact that we probably might, I'm sure the long-arm 351.39s - 354.37s | law will catch up at some point, like, you guys, you're GEATAN, like 10 years from now, and 354.37s - 360.33s | like, yeah, we are not, sorry. So, um, unfortunately, like every single result we found 360.35s - 363.41s | that


chunk_id: 155_chunk_9
chunk_text:
got one, we got a hit for GEA. It's 320.41s - 324.35s | really exciting. Um, in the meantime, we're melting all of our DigitalOcean nodes, so this 324.35s - 328.09s | is this poor little DO droplet just like falling apart as we're like destroying it. It's, I 328.09s - 332.79s | think it sent like a terabyte of traffic at this point, like we're, yeah, we made DO VMs 332.81s - 338.41s | very unhappy. Um, so, just heads up for law enforcement, um, we sent the public key for 338.41s - 343.05s | GEATAN to every server on the internet from our IPs. We are not GEATAN, we do not backdoor 343.05s - 346.79s | exe-utils, even though it very much looks like we did. So we sort of accidentally framed 346.79s - 351.39s | ourselves, uh, we realized that after the fact that we probably might, I'm sure the long-arm 351.39s - 354.37s | law will catch up at some point, like, you guys, you're GEATAN, like 10 years from now, and 354.37s - 360.33s | like, yeah, we are not, sorry. So, um, unfortunately, like every single result we found 360.35s - 363.41s | that we thought was GEATAN was a false positive. It was like a buggy server with like the 363.41s - 367.09s | memory was corrupted or the service would accept every fifth public key or every third 367.09s - 370.99s | public key. So we had to say, okay, let's try a bunch of random public keys and if you reject 370.99s - 375.93s | all those, now try the GEAT key. And let's try like an RSA key, an RSA 1024, 2048. We've 375.93s - 379.49s | still found devices that are just randomly accept or randomly not accept keys and it just 379.49s - 383.43s | drove us crazy. So we finally fixed all these bugs, re-scanned, re-scanned, re-scanned, uh, 383.43s - 387.31s | you know, clicked all those DigitalOcean abuse notices, says, yeah, we're good, our server's 387.31s - 391.85s | not compromised, we're cool. Um, and we still found no GEATAN. So whoever this, you know, 391.85s - 395.59s | actor was, they had really good OPSEC, we found nothing, so good job them. Um, but we did 395.59s - 399.23s | find like thousands of free shells. So we're like, how come we're getting all these


chunk_id: 155_chunk_10
chunk_text:
we thought was GEATAN was a false positive. It was like a buggy server with like the 363.41s - 367.09s | memory was corrupted or the service would accept every fifth public key or every third 367.09s - 370.99s | public key. So we had to say, okay, let's try a bunch of random public keys and if you reject 370.99s - 375.93s | all those, now try the GEAT key. And let's try like an RSA key, an RSA 1024, 2048. We've 375.93s - 379.49s | still found devices that are just randomly accept or randomly not accept keys and it just 379.49s - 383.43s | drove us crazy. So we finally fixed all these bugs, re-scanned, re-scanned, re-scanned, uh, 383.43s - 387.31s | you know, clicked all those DigitalOcean abuse notices, says, yeah, we're good, our server's 387.31s - 391.85s | not compromised, we're cool. Um, and we still found no GEATAN. So whoever this, you know, 391.85s - 395.59s | actor was, they had really good OPSEC, we found nothing, so good job them. Um, but we did 395.59s - 399.23s | find like thousands of free shells. So we're like, how come we're getting all these random 399.23s - 403.53s | shells on all these random machines? And that's really what this talk is, is about. Uh, so 403.53s - 408.47s | with that, um, a little bit of a detour. So an SH, um, public keys used to not be something 408.47s - 411.37s | that you actually made public. They used to be something you kind of kept privately in your 411.37s - 415.11s | .SH directly and you copied to a server here and there. But, um, in the last five or six 415.11s - 420.55s | years, we've seen people using, uh, SH keys like identities. So just like people used PGP back 420.55s - 424.05s | in the day, you can now use SH keys as your identity when you're installing a Ubuntu server. 424.05s - 426.89s | You can tell it to grab your key from GitHub or from Launchpad and automatically give you 426.89s - 432.79s | access to your server during installation by username. Um, you can also, uh, um, use these 432.79s - 436.69s | keys for things like, uh, OJ encryption. So if you use the OJ tool or H tool, you can use it 436.69s


chunk_id: 155_chunk_11
chunk_text:
random 399.23s - 403.53s | shells on all these random machines? And that's really what this talk is, is about. Uh, so 403.53s - 408.47s | with that, um, a little bit of a detour. So an SH, um, public keys used to not be something 408.47s - 411.37s | that you actually made public. They used to be something you kind of kept privately in your 411.37s - 415.11s | .SH directly and you copied to a server here and there. But, um, in the last five or six 415.11s - 420.55s | years, we've seen people using, uh, SH keys like identities. So just like people used PGP back 420.55s - 424.05s | in the day, you can now use SH keys as your identity when you're installing a Ubuntu server. 424.05s - 426.89s | You can tell it to grab your key from GitHub or from Launchpad and automatically give you 426.89s - 432.79s | access to your server during installation by username. Um, you can also, uh, um, use these 432.79s - 436.69s | keys for things like, uh, OJ encryption. So if you use the OJ tool or H tool, you can use it 436.69s - 439.83s | almost like a PGP key now these days as well. So there's all kinds of cool stuff you can do 439.83s - 443.57s | with, uh, SH keys you didn't before. But the key thing here is like, keys are effectively 443.57s - 447.37s | public if you use any of these major platforms. And literally public. So there's this great 447.37s - 451.25s | little, uh, daemon by Filippo where you SSH into it, it'll say who you are. It'll use the 451.25s - 454.67s | public key you send to the server, dock to you based on the GitHub database and say, oh, 454.67s - 458.65s | you're so and so, welcome. So it's kind of a fun little trick. And effectively we're doing 458.65s - 462.39s | that, but at scale for the whole internet. So if you want to link a user to a particular key 462.39s - 465.89s | on a particular server, you need, um, one, a list of all the SH servers out there. So 465.89s - 469.45s | ZMAP, Mascan, dump it from Shodan, whatever you want to do to get the list. You want a list of 469.45s


chunk_id: 155_chunk_12
chunk_text:
- 439.83s | almost like a PGP key now these days as well. So there's all kinds of cool stuff you can do 439.83s - 443.57s | with, uh, SH keys you didn't before. But the key thing here is like, keys are effectively 443.57s - 447.37s | public if you use any of these major platforms. And literally public. So there's this great 447.37s - 451.25s | little, uh, daemon by Filippo where you SSH into it, it'll say who you are. It'll use the 451.25s - 454.67s | public key you send to the server, dock to you based on the GitHub database and say, oh, 454.67s - 458.65s | you're so and so, welcome. So it's kind of a fun little trick. And effectively we're doing 458.65s - 462.39s | that, but at scale for the whole internet. So if you want to link a user to a particular key 462.39s - 465.89s | on a particular server, you need, um, one, a list of all the SH servers out there. So 465.89s - 469.45s | ZMAP, Mascan, dump it from Shodan, whatever you want to do to get the list. You want a list of 469.45s - 472.77s | all the public keys, so you go grind all those out of GitHub through their BigQuery API, 472.79s - 476.67s | about 117 million users as of about a month ago. Uh, Launchpad's got a bunch of users too. 476.67s - 480.13s | You get all their keys too, why, why not? And then Bad Keys is a great project by, uh, 480.13s - 483.91s | Hanno Bach, um, that allows you to, that keeps track of all the compromised keys out there. 483.91s - 487.31s | So you can look for keys that give you access to the system. And then lastly, you need a list 487.31s - 491.25s | of common usernames the user might have, like root, ec2 user for cloud, Ubuntu, et cetera, 491.25s - 494.99s | or whatever the comment is in the key. So one of the nice things about GitHub is that when 494.99s - 498.25s | you upload your public key to there, they actually preserve the comment field, which is 498.25s - 501.39s | typically your, your username when you uploaded the key. So you know what their default 501.41s - 504.09s | username is. So if you're


chunk_id: 155_chunk_13
chunk_text:
- 472.77s | all the public keys, so you go grind all those out of GitHub through their BigQuery API, 472.79s - 476.67s | about 117 million users as of about a month ago. Uh, Launchpad's got a bunch of users too. 476.67s - 480.13s | You get all their keys too, why, why not? And then Bad Keys is a great project by, uh, 480.13s - 483.91s | Hanno Bach, um, that allows you to, that keeps track of all the compromised keys out there. 483.91s - 487.31s | So you can look for keys that give you access to the system. And then lastly, you need a list 487.31s - 491.25s | of common usernames the user might have, like root, ec2 user for cloud, Ubuntu, et cetera, 491.25s - 494.99s | or whatever the comment is in the key. So one of the nice things about GitHub is that when 494.99s - 498.25s | you upload your public key to there, they actually preserve the comment field, which is 498.25s - 501.39s | typically your, your username when you uploaded the key. So you know what their default 501.41s - 504.09s | username is. So if you're trying to find like their server someplace, you can pull it out of 504.09s - 507.85s | the comment, use that to talk to the user and so on. So you, you take this nice little recipe 507.85s - 512.89s | and you throw it in the oven and, um, it gives you a nice little primitive to take one key and 512.89s - 515.89s | check lots of servers really fast. Like you can grind through all the servers on the internet 515.89s - 519.83s | in like an hour or something like that on a single box. It's pretty quickly just for one key. 519.83s - 522.73s | Um, but if you want to test, um, so that works great if you're looking for like a geotan 522.73s - 526.87s | everywhere. But what if you want to say for this server on the internet that's acting fishy, 526.87s - 531.11s | which GitHub user has access to it? And do the other way, check all 117 million keys on 531.13s - 534.67s | one server. Well, that's a very different attack. This is like, you know, a duck-sized horse or 534.67s - 538.43s | horse-sized ducks, you


chunk_id: 155_chunk_14
chunk_text:
trying to find like their server someplace, you can pull it out of 504.09s - 507.85s | the comment, use that to talk to the user and so on. So you, you take this nice little recipe 507.85s - 512.89s | and you throw it in the oven and, um, it gives you a nice little primitive to take one key and 512.89s - 515.89s | check lots of servers really fast. Like you can grind through all the servers on the internet 515.89s - 519.83s | in like an hour or something like that on a single box. It's pretty quickly just for one key. 519.83s - 522.73s | Um, but if you want to test, um, so that works great if you're looking for like a geotan 522.73s - 526.87s | everywhere. But what if you want to say for this server on the internet that's acting fishy, 526.87s - 531.11s | which GitHub user has access to it? And do the other way, check all 117 million keys on 531.13s - 534.67s | one server. Well, that's a very different attack. This is like, you know, a duck-sized horse or 534.67s - 538.43s | horse-sized ducks, you know, kind of approach. So if we want to test a million keys against, 538.43s - 542.87s | uh, a single server, it's a little bit tougher because, uh, SH will slow you down. Uh, they 542.87s - 546.31s | have, uh, this thing called max auth limit, which is how many tries you can authenticate 546.31s - 549.25s | before it kicks you off of that connection. And there's a max connection limit, so you can 549.25s - 552.89s | only do so many of those at once, right? So the idea is that with OpenSH, if you try to 552.89s - 556.49s | brute force keys, you get four into it and it knocks you out and you can't auth anymore. So 556.49s - 559.69s | if you've ever had more than four keys in your SH, uh, agent and you try to shell out a 559.71s - 562.81s | machine and it just immediately says, you know, too many tries, that's why. It's because you're 562.81s - 568.05s | hitting the max auth limit of OpenSH. However, um, OpenSH is the only one that does that. 568.05s - 572.35s | Everything else lets you just bang keys


chunk_id: 155_chunk_15
chunk_text:
know, kind of approach. So if we want to test a million keys against, 538.43s - 542.87s | uh, a single server, it's a little bit tougher because, uh, SH will slow you down. Uh, they 542.87s - 546.31s | have, uh, this thing called max auth limit, which is how many tries you can authenticate 546.31s - 549.25s | before it kicks you off of that connection. And there's a max connection limit, so you can 549.25s - 552.89s | only do so many of those at once, right? So the idea is that with OpenSH, if you try to 552.89s - 556.49s | brute force keys, you get four into it and it knocks you out and you can't auth anymore. So 556.49s - 559.69s | if you've ever had more than four keys in your SH, uh, agent and you try to shell out a 559.71s - 562.81s | machine and it just immediately says, you know, too many tries, that's why. It's because you're 562.81s - 568.05s | hitting the max auth limit of OpenSH. However, um, OpenSH is the only one that does that. 568.05s - 572.35s | Everything else lets you just bang keys all day long. So DropBear lets you just grind keys as 572.35s - 576.19s | fast as that little device can, can test them. Um, also a lot of commercial products like 576.19s - 579.83s | BitVise, GlobalScape, Maverick, LanCom, all this stuff, all their SH daemons do not care. 579.83s - 583.43s | They'll let you just try every possible key in the world until, until you're done. It's great. 583.43s - 586.03s | Uh, we emailed the DropBear folks, they didn't care, they didn't even bother replying, so 586.05s - 590.91s | like, it's not really a bug, it's a feature. So we like that feature. So, uh, with the 590.91s - 594.95s | shamble code you mentioned before, we tested the GitHub, like 4.6 million key database at the 594.95s - 599.19s | time, and you can do about 10,000 keys per second on a DropBear box on an embedded node 599.19s - 602.25s | without it spiking the CPU on the target device at all. It just doesn't even care. It's like 602.25s - 605.99s | super fast. So it doesn't even murder the machine. And this is 10,000 keys per second per 605.99s - 610.53s


chunk_id: 155_chunk_16
chunk_text:
all day long. So DropBear lets you just grind keys as 572.35s - 576.19s | fast as that little device can, can test them. Um, also a lot of commercial products like 576.19s - 579.83s | BitVise, GlobalScape, Maverick, LanCom, all this stuff, all their SH daemons do not care. 579.83s - 583.43s | They'll let you just try every possible key in the world until, until you're done. It's great. 583.43s - 586.03s | Uh, we emailed the DropBear folks, they didn't care, they didn't even bother replying, so 586.05s - 590.91s | like, it's not really a bug, it's a feature. So we like that feature. So, uh, with the 590.91s - 594.95s | shamble code you mentioned before, we tested the GitHub, like 4.6 million key database at the 594.95s - 599.19s | time, and you can do about 10,000 keys per second on a DropBear box on an embedded node 599.19s - 602.25s | without it spiking the CPU on the target device at all. It just doesn't even care. It's like 602.25s - 605.99s | super fast. So it doesn't even murder the machine. And this is 10,000 keys per second per 605.99s - 610.53s | connection, and DropBear is typically configured with 15 connections. So you can do 150,000 610.53s - 614.83s | keys per second on a machine for pub key testing to dock someone's server. So if you see 614.83s - 618.27s | someone like hitting you on a random box and SH is open, just go take all the keys and give 618.27s - 622.15s | it, like yeah, you jerk, stop that. And just email them, like quit it. Like, it's really, 622.15s - 625.85s | really easy to dock to your hackers. And if you're running an SH honeypot, and your SH 625.85s - 629.29s | honeypot collects the public key being sent to you, you can turn around and flip that on 629.29s - 632.79s | them again and immediately figure out who they are. Like, people forget all the time that 632.79s - 635.39s | their SH agent's configured, and they're sending their public key to every server they 635.39s - 638.53s | connect to. Even if their agent is not authenticating to it, they're still automatically 638.53s - 642.53s | sending that public key as a test whenever you touch anything. So if you're a, a


chunk_id: 155_chunk_17
chunk_text:
| connection, and DropBear is typically configured with 15 connections. So you can do 150,000 610.53s - 614.83s | keys per second on a machine for pub key testing to dock someone's server. So if you see 614.83s - 618.27s | someone like hitting you on a random box and SH is open, just go take all the keys and give 618.27s - 622.15s | it, like yeah, you jerk, stop that. And just email them, like quit it. Like, it's really, 622.15s - 625.85s | really easy to dock to your hackers. And if you're running an SH honeypot, and your SH 625.85s - 629.29s | honeypot collects the public key being sent to you, you can turn around and flip that on 629.29s - 632.79s | them again and immediately figure out who they are. Like, people forget all the time that 632.79s - 635.39s | their SH agent's configured, and they're sending their public key to every server they 635.39s - 638.53s | connect to. Even if their agent is not authenticating to it, they're still automatically 638.53s - 642.53s | sending that public key as a test whenever you touch anything. So if you're a, a lead hacker 642.53s - 645.31s | and you've been just SHing to random machines on the internet, you're also sending your 645.31s - 650.87s | public key identity to all those machines, and if they're logging in, you're a host. So, um, 650.87s - 654.91s | by contrast, if you try the same attack against OpenSH, you can do 132 keys per second. So 654.91s - 659.49s | it'll take you 10 hours to do the same 4.8 million keys with a single connection. So, um, 659.49s - 663.69s | obviously the OpenSH approach is much nicer, um, but it's great if you're trying to, um, 663.69s - 667.09s | ad- ad- docks people. So, uh, with that, I'll hand it to Rob to talk about shaking out 667.09s - 672.09s | shells. Testing, testing. Testing. Testing, testing. Hey, alright. So, shaking out shells. 676.87s - 681.87s | Say that five times fast. Um, what we did with Shamble is it resulted in, uh, around 27 684.45s - 690.15s | million devices on the public internet that are listening on port 22. We got another, you 690.15s - 694.55s | know, 14 million or so that actually negotiated, uh, SSH


chunk_id: 155_chunk_18
chunk_text:
lead hacker 642.53s - 645.31s | and you've been just SHing to random machines on the internet, you're also sending your 645.31s - 650.87s | public key identity to all those machines, and if they're logging in, you're a host. So, um, 650.87s - 654.91s | by contrast, if you try the same attack against OpenSH, you can do 132 keys per second. So 654.91s - 659.49s | it'll take you 10 hours to do the same 4.8 million keys with a single connection. So, um, 659.49s - 663.69s | obviously the OpenSH approach is much nicer, um, but it's great if you're trying to, um, 663.69s - 667.09s | ad- ad- docks people. So, uh, with that, I'll hand it to Rob to talk about shaking out 667.09s - 672.09s | shells. Testing, testing. Testing. Testing, testing. Hey, alright. So, shaking out shells. 676.87s - 681.87s | Say that five times fast. Um, what we did with Shamble is it resulted in, uh, around 27 684.45s - 690.15s | million devices on the public internet that are listening on port 22. We got another, you 690.15s - 694.55s | know, 14 million or so that actually negotiated, uh, SSH off, and we ended up with about 694.55s - 699.55s | 110,000 sessions. Um, what's really interesting about SSH, so SSH, uh, especially OpenSSH 701.55s - 708.24s | has done an immense amount of work in- do what? Oh, sorry, front mics are hot. Uh, so- 712.26s - 717.26s | sorry. So, uh, we ended up with, um, about 110,000, uh, that are actually listening and we 719.12s - 723.50s | were able to get sessions. What's fascinating about OpenSSH is- or SSH, is that there's a 723.52s - 729.36s | fairly large post-authentication attack surface. So, SSH does lots of things. You can create 729.36s - 733.70s | tunnels, you, uh, can create pseudo terminals, there's subsystems, there's all sorts of things 733.70s - 738.88s | that are running on, uh, SSH once you're inside. Uh, it kind of assumes that once you've 738.88s - 742.94s | authenticated you're okay, but there's an immense, uh, an immense amount of systems out 742.94s - 747.94s | there that actually will do this interesting post-auth-auth. So, you authenticate, uh, non-authentication 748.20s - 753.20s | with LeftBeef and you get in and then it actually gives you a secondary authentication mechanism. 756.24s


chunk_id: 155_chunk_19
chunk_text:
off, and we ended up with about 694.55s - 699.55s | 110,000 sessions. Um, what's really interesting about SSH, so SSH, uh, especially OpenSSH 701.55s - 708.24s | has done an immense amount of work in- do what? Oh, sorry, front mics are hot. Uh, so- 712.26s - 717.26s | sorry. So, uh, we ended up with, um, about 110,000, uh, that are actually listening and we 719.12s - 723.50s | were able to get sessions. What's fascinating about OpenSSH is- or SSH, is that there's a 723.52s - 729.36s | fairly large post-authentication attack surface. So, SSH does lots of things. You can create 729.36s - 733.70s | tunnels, you, uh, can create pseudo terminals, there's subsystems, there's all sorts of things 733.70s - 738.88s | that are running on, uh, SSH once you're inside. Uh, it kind of assumes that once you've 738.88s - 742.94s | authenticated you're okay, but there's an immense, uh, an immense amount of systems out 742.94s - 747.94s | there that actually will do this interesting post-auth-auth. So, you authenticate, uh, non-authentication 748.20s - 753.20s | with LeftBeef and you get in and then it actually gives you a secondary authentication mechanism. 756.24s - 760.48s | It'll prompt you for a username and then a password, but you're inside the session at that 760.48s - 763.54s | point. So, you can start doing some interesting things. This is one of the- the interesting 763.54s - 769.12s | cool things that- that Shamble will do. Um, you can say, oh, okay, uh, I can send signals, I 769.12s - 775.22s | can send, uh, SIGWINCH, I can, uh, forward X11, things like that. And you can see there's a 775.24s - 781.72s | fair amount of large, uh, devices, uh, popular devices out there that do this post-auth-auth. 781.72s - 787.22s | So, you can see you've got, uh, SonicWall firewalls, um, Juniper network devices. You can 787.22s - 791.16s | SSH in with AuthNone and then it'll give you the secondary one. That, uh, that smaller one, 791.16s - 794.70s | the PleaseLogin, that's, uh, a ruckus one that HG's gonna talk about here in a minute. 794.70s - 799.70s | That's super, uh, super fascinating. But it's worth noting that there is this post-auth attack 800.46s - 805.46s | service that is kind of not considered, but is exposed. So, and with


chunk_id: 155_chunk_20
chunk_text:
- 760.48s | It'll prompt you for a username and then a password, but you're inside the session at that 760.48s - 763.54s | point. So, you can start doing some interesting things. This is one of the- the interesting 763.54s - 769.12s | cool things that- that Shamble will do. Um, you can say, oh, okay, uh, I can send signals, I 769.12s - 775.22s | can send, uh, SIGWINCH, I can, uh, forward X11, things like that. And you can see there's a 775.24s - 781.72s | fair amount of large, uh, devices, uh, popular devices out there that do this post-auth-auth. 781.72s - 787.22s | So, you can see you've got, uh, SonicWall firewalls, um, Juniper network devices. You can 787.22s - 791.16s | SSH in with AuthNone and then it'll give you the secondary one. That, uh, that smaller one, 791.16s - 794.70s | the PleaseLogin, that's, uh, a ruckus one that HG's gonna talk about here in a minute. 794.70s - 799.70s | That's super, uh, super fascinating. But it's worth noting that there is this post-auth attack 800.46s - 805.46s | service that is kind of not considered, but is exposed. So, and with that, with sort of the 807.70s - 812.60s | first one that you can talk about is signal injection. I'm gonna pass it back to HG for that. 812.60s - 814.60s | Did we get the second mic working? 814.60s - 816.94s | Cool, thank you. Sorry, I just wanted to stay away from the front mic so we don't get 816.94s - 821.54s | feedback here. Um, so, uh, Rob mentioned that one of the things you can do to a post-auth 821.54s - 826.52s | session is, uh, inject signals into the process before you've fully authenticated. So, 826.54s - 830.44s | effectively, you can connect to a machine, it'll pass through the authentication from 830.44s - 834.44s | SSH, Auth equal None, and then drop you to a real login shell and it'll say, PleaseLogin. 834.44s - 838.76s | And you can just say, Signal Sec V, and it goes, ah, and dies. Which is a lot of fun. So, 838.76s - 841.62s | effectively, you can just, you know, we talk about regression being signal re-entrance. 841.62s - 844.62s | This is just signal entrance. You just bang signals all day long into whatever process you


chunk_id: 155_chunk_21
chunk_text:
that, with sort of the 807.70s - 812.60s | first one that you can talk about is signal injection. I'm gonna pass it back to HG for that. 812.60s - 814.60s | Did we get the second mic working? 814.60s - 816.94s | Cool, thank you. Sorry, I just wanted to stay away from the front mic so we don't get 816.94s - 821.54s | feedback here. Um, so, uh, Rob mentioned that one of the things you can do to a post-auth 821.54s - 826.52s | session is, uh, inject signals into the process before you've fully authenticated. So, 826.54s - 830.44s | effectively, you can connect to a machine, it'll pass through the authentication from 830.44s - 834.44s | SSH, Auth equal None, and then drop you to a real login shell and it'll say, PleaseLogin. 834.44s - 838.76s | And you can just say, Signal Sec V, and it goes, ah, and dies. Which is a lot of fun. So, 838.76s - 841.62s | effectively, you can just, you know, we talk about regression being signal re-entrance. 841.62s - 844.62s | This is just signal entrance. You just bang signals all day long into whatever process you 844.62s - 848.56s | want and see what terrible things fall back out of it. So, uh, we didn't get too far into 848.56s - 850.80s | this testing, but we've put, there's all kinds of fun things that come out of it. You can 850.80s - 853.90s | send a SIGINT request, you can pass Python scripts that are part of the login shell to 853.92s - 858.52s | crash. Uh, you can do SIG alarms, SIG childs, SIG ills, SIG aborts, you can pass core dumps, 858.52s - 862.62s | uh, all kinds of crazy stuff you can just do with signals. And OpenSH tries to protect you a 862.62s - 866.80s | little bit by limiting things like SIG Sec V, SIG abort, and so on. Uh, but DropBear does 866.80s - 869.60s | not. DropBear is like, anything that you can possibly send me, I'll treat as a signal and 869.60s - 872.76s | deliver to the process. Thank you. Um, so there's a lot of really cool attacks that we think 872.76s - 876.44s | you can do there and we're gonna start working on expanding the shamble code to then basically 876.44s - 880.44s


chunk_id: 155_chunk_22
chunk_text:
844.62s - 848.56s | want and see what terrible things fall back out of it. So, uh, we didn't get too far into 848.56s - 850.80s | this testing, but we've put, there's all kinds of fun things that come out of it. You can 850.80s - 853.90s | send a SIGINT request, you can pass Python scripts that are part of the login shell to 853.92s - 858.52s | crash. Uh, you can do SIG alarms, SIG childs, SIG ills, SIG aborts, you can pass core dumps, 858.52s - 862.62s | uh, all kinds of crazy stuff you can just do with signals. And OpenSH tries to protect you a 862.62s - 866.80s | little bit by limiting things like SIG Sec V, SIG abort, and so on. Uh, but DropBear does 866.80s - 869.60s | not. DropBear is like, anything that you can possibly send me, I'll treat as a signal and 869.60s - 872.76s | deliver to the process. Thank you. Um, so there's a lot of really cool attacks that we think 872.76s - 876.44s | you can do there and we're gonna start working on expanding the shamble code to then basically 876.44s - 880.44s | just mash symbols into random processes so you get a shell. And, yeah. Um, with that, hand 880.48s - 885.82s | it back to Rob, talk about TSP forwarding. I, I do always love that, uh, DropBear is like, 885.82s - 889.16s | I, you know, it's like, if it were dying, it wouldn't be dictating, right? It wouldn't be 889.16s - 895.16s | writing it out, it would just say IE, but no. Um, but another part of this post-auth, uh, uh, 895.16s - 901.90s | attack surface is forwarding, right? So SSH allows you to generate or create tunnels, uh, you 901.90s - 905.60s | know, through channels and create encrypted tunnels. It's almost like a little miniature VPN 905.60s - 909.84s | thing. And this is a pretty popular and common, uh, feature. But once you've po- once you're 909.84s - 913.02s | in this post-auth situation, you can start doing that. You can start creating these things 913.02s - 917.92s | on a lot of these systems. Um, many of them will administratively restrict you from doing it 917.92s - 923.46s | or they'll only let you go to certain things, but for example, uh,


chunk_id: 155_chunk_23
chunk_text:
| just mash symbols into random processes so you get a shell. And, yeah. Um, with that, hand 880.48s - 885.82s | it back to Rob, talk about TSP forwarding. I, I do always love that, uh, DropBear is like, 885.82s - 889.16s | I, you know, it's like, if it were dying, it wouldn't be dictating, right? It wouldn't be 889.16s - 895.16s | writing it out, it would just say IE, but no. Um, but another part of this post-auth, uh, uh, 895.16s - 901.90s | attack surface is forwarding, right? So SSH allows you to generate or create tunnels, uh, you 901.90s - 905.60s | know, through channels and create encrypted tunnels. It's almost like a little miniature VPN 905.60s - 909.84s | thing. And this is a pretty popular and common, uh, feature. But once you've po- once you're 909.84s - 913.02s | in this post-auth situation, you can start doing that. You can start creating these things 913.02s - 917.92s | on a lot of these systems. Um, many of them will administratively restrict you from doing it 917.92s - 923.46s | or they'll only let you go to certain things, but for example, uh, uh, you can say, OK, well 923.46s - 927.70s | I'm gonna try to forward to this particular host or I'm gonna try to forward to a local host 927.70s - 932.64s | and do a loopback. Um, and we actually found, uh, this is an ION, yeah, OK, good, the chip's 932.64s - 939.30s | blank. Uh, this is a, an ION network's access point and you can see that it's trying to, uh, 939.34s - 946.04s | forward to Google.com and it, it gets rejected. And then it's gonna try, oh, and by the way, 946.04s - 950.68s | this is the shambles shell, uh, which I love. Um, and it'd say, oh, I'm gonna try to get 950.68s - 955.86s | 88888, but then you can actually forward back to local host. You can actually use that to 955.86s - 961.12s | get around restrictions and things like that once you're in this sort of, uh, uh, mystery, 961.12s - 967.46s | uh, uh, post-auth shell. But the big, the big one is shell injection. I'm gonna let 967.46s - 971.84s | Jason take this one cause this is super cool. One thing that was kind of


chunk_id: 155_chunk_24
chunk_text:
uh, you can say, OK, well 923.46s - 927.70s | I'm gonna try to forward to this particular host or I'm gonna try to forward to a local host 927.70s - 932.64s | and do a loopback. Um, and we actually found, uh, this is an ION, yeah, OK, good, the chip's 932.64s - 939.30s | blank. Uh, this is a, an ION network's access point and you can see that it's trying to, uh, 939.34s - 946.04s | forward to Google.com and it, it gets rejected. And then it's gonna try, oh, and by the way, 946.04s - 950.68s | this is the shambles shell, uh, which I love. Um, and it'd say, oh, I'm gonna try to get 950.68s - 955.86s | 88888, but then you can actually forward back to local host. You can actually use that to 955.86s - 961.12s | get around restrictions and things like that once you're in this sort of, uh, uh, mystery, 961.12s - 967.46s | uh, uh, post-auth shell. But the big, the big one is shell injection. I'm gonna let 967.46s - 971.84s | Jason take this one cause this is super cool. One thing that was kind of fun about this is 971.84s - 975.40s | that we found bugs that like we shouldn't have found. Like because of this post-auth 975.40s - 979.38s | sequence, effectively you SH to the machine and instead of asking for a password, you just, 979.38s - 982.34s | it drops you straight in, but it drops you straight into a secondary shell. And that 982.34s - 985.48s | secondary shell has its own bugs. So we kept finding these vulnerabilities in these 985.48s - 989.06s | secondary shells that no one had found before, even though they were like stupid. Like we 989.06s - 993.02s | found so many dumb bugs just because no one really tested that level of the protocol. So 993.02s - 998.60s | in this case, um, we're ran across these like ruckus access points and you SH them. There's 998.60s - 1002.00s | about 36,000 of these suckers exposed on the internet. About 900 are vulnerable to this 1002.00s - 1006.90s | particular attack still right now today. And it asks you for a username, you type in root, you 1006.90s - 1009.44s | type in, you start entering your password and for your password, you


chunk_id: 155_chunk_25
chunk_text:
fun about this is 971.84s - 975.40s | that we found bugs that like we shouldn't have found. Like because of this post-auth 975.40s - 979.38s | sequence, effectively you SH to the machine and instead of asking for a password, you just, 979.38s - 982.34s | it drops you straight in, but it drops you straight into a secondary shell. And that 982.34s - 985.48s | secondary shell has its own bugs. So we kept finding these vulnerabilities in these 985.48s - 989.06s | secondary shells that no one had found before, even though they were like stupid. Like we 989.06s - 993.02s | found so many dumb bugs just because no one really tested that level of the protocol. So 993.02s - 998.60s | in this case, um, we're ran across these like ruckus access points and you SH them. There's 998.60s - 1002.00s | about 36,000 of these suckers exposed on the internet. About 900 are vulnerable to this 1002.00s - 1006.90s | particular attack still right now today. And it asks you for a username, you type in root, you 1006.90s - 1009.44s | type in, you start entering your password and for your password, you just type in like 1009.44s - 1012.40s | dollar parenthesis, whatever command you want to run, right? And it's redirected back out to 1012.40s - 1015.38s | standard error so you can see the result. And it just runs this route for your life. It's 1015.38s - 1019.74s | great. Um, so we'll, we reached out to ruckus of course, like, Hey, what's up? Like you guys, 1019.74s - 1023.28s | is this a new bug? Is this a fixed bug? We can't really tell what's patched. Like, Oh yeah, we 1023.28s - 1026.58s | patched that already. I'm like, did you tell anyone? Nope. They didn't tell anyone. There's no 1026.58s - 1029.92s | CV, you know, security note whatsoever. So of course no one's applying patches because they 1029.92s - 1033.68s | didn't know they had to apply the patch. Um, so they've got two different tracks, the 521 and 1033.68s - 1037.28s | the 61. Those both fix it. But there's, you know, still about, you know, almost a thousand 1037.28s - 1041.02s | folks out there still running unpatched up. But the question was like, why did this bug live so 1041.02s - 1044.60s | long?


chunk_id: 155_chunk_26
chunk_text:
just type in like 1009.44s - 1012.40s | dollar parenthesis, whatever command you want to run, right? And it's redirected back out to 1012.40s - 1015.38s | standard error so you can see the result. And it just runs this route for your life. It's 1015.38s - 1019.74s | great. Um, so we'll, we reached out to ruckus of course, like, Hey, what's up? Like you guys, 1019.74s - 1023.28s | is this a new bug? Is this a fixed bug? We can't really tell what's patched. Like, Oh yeah, we 1023.28s - 1026.58s | patched that already. I'm like, did you tell anyone? Nope. They didn't tell anyone. There's no 1026.58s - 1029.92s | CV, you know, security note whatsoever. So of course no one's applying patches because they 1029.92s - 1033.68s | didn't know they had to apply the patch. Um, so they've got two different tracks, the 521 and 1033.68s - 1037.28s | the 61. Those both fix it. But there's, you know, still about, you know, almost a thousand 1037.28s - 1041.02s | folks out there still running unpatched up. But the question was like, why did this bug live so 1041.02s - 1044.60s | long? How did we end up with this? Like a stupid login prompts, like password character 1044.60s - 1048.20s | injection. And it's because there's behind this SSH off layer that no one really bothered to 1048.20s - 1051.76s | test it. Like all your folks who normally hit a telnet prompts, something like that, just 1051.76s - 1056.24s | hadn't tried this SSH post off attack. So we uncovered this whole like layer of bugs that 1056.24s - 1059.88s | really should have been found 20 years ago, but they were just hiding behind this extra SSH 1059.88s - 1063.38s | layer. Uh, and that's one of the interesting kind of side effects of this work. So here's an 1063.38s - 1068.14s | example of us, uh, rooting one of these random ruckus boxes. SSH in with all the, I don't care 1068.14s - 1073.22s | about my cipher stuff. Please log in or OOT. And then for the password, we're just typing in 1073.24s - 1078.78s | $PSAUX-W and getting a big process listing. And the funny thing about it is you can actually see 1078.78s - 1083.02s | the echo command in the PS listing showing that it's


chunk_id: 155_chunk_27
chunk_text:
How did we end up with this? Like a stupid login prompts, like password character 1044.60s - 1048.20s | injection. And it's because there's behind this SSH off layer that no one really bothered to 1048.20s - 1051.76s | test it. Like all your folks who normally hit a telnet prompts, something like that, just 1051.76s - 1056.24s | hadn't tried this SSH post off attack. So we uncovered this whole like layer of bugs that 1056.24s - 1059.88s | really should have been found 20 years ago, but they were just hiding behind this extra SSH 1059.88s - 1063.38s | layer. Uh, and that's one of the interesting kind of side effects of this work. So here's an 1063.38s - 1068.14s | example of us, uh, rooting one of these random ruckus boxes. SSH in with all the, I don't care 1068.14s - 1073.22s | about my cipher stuff. Please log in or OOT. And then for the password, we're just typing in 1073.24s - 1078.78s | $PSAUX-W and getting a big process listing. And the funny thing about it is you can actually see 1078.78s - 1083.02s | the echo command in the PS listing showing that it's going to shop 256 sum. That's how they 1083.02s - 1086.46s | check your password. So they fixed it just by putting in proper quotes, but whole thing is 1086.46s - 1090.10s | ridiculous. So it's amazing like how many dumb bugs are out there. If you just go a little bit 1090.10s - 1093.40s | further into the protocol stack and back to Rob for the permit. 1095.46s - 1100.30s | So SSH, you know, is the secure shell. It's designed to talk as your shell. It replaces 1100.30s - 1105.42s | Telnet and RSH and all that. And it lets you set environment variables. Um, environment 1105.42s - 1109.60s | variables are used to control the execution of things and, you know, keep track of environment 1109.60s - 1115.00s | and all that. And a lot of, uh, SSH implementations will limit what you can send, but a lot 1115.00s - 1119.74s | won't. Um, there's been a, uh, and it's configurable. Of course, some will, you can say, 1119.74s - 1124.84s | I accept these environment variables, don't accept these. So there's been this renaissance in, 1124.84s - 1129.78s | uh, Gitforges lately. There's a ton. There's,


chunk_id: 155_chunk_28
chunk_text:
going to shop 256 sum. That's how they 1083.02s - 1086.46s | check your password. So they fixed it just by putting in proper quotes, but whole thing is 1086.46s - 1090.10s | ridiculous. So it's amazing like how many dumb bugs are out there. If you just go a little bit 1090.10s - 1093.40s | further into the protocol stack and back to Rob for the permit. 1095.46s - 1100.30s | So SSH, you know, is the secure shell. It's designed to talk as your shell. It replaces 1100.30s - 1105.42s | Telnet and RSH and all that. And it lets you set environment variables. Um, environment 1105.42s - 1109.60s | variables are used to control the execution of things and, you know, keep track of environment 1109.60s - 1115.00s | and all that. And a lot of, uh, SSH implementations will limit what you can send, but a lot 1115.00s - 1119.74s | won't. Um, there's been a, uh, and it's configurable. Of course, some will, you can say, 1119.74s - 1124.84s | I accept these environment variables, don't accept these. So there's been this renaissance in, 1124.84s - 1129.78s | uh, Gitforges lately. There's a ton. There's, there's GITI, there's GOGS, there's a, I always 1129.80s - 1134.46s | pronounce this wrong, FORGEHO. Tell me if I'm saying that right. Garrett, things like that. 1134.46s - 1139.04s | And they are using these embedded SSH libraries that speak the SSH protocol. And these 1139.04s - 1143.28s | libraries, because they're, you know, designed for general use, they will accept, you know, 1143.28s - 1147.88s | any environment variable you send. And they rely on the client, the user of the library, to, 1147.88s - 1154.56s | uh, limit what is going on. Um, and so that's generally okay. Like a lot of them do it 1154.56s - 1159.84s | correctly. Uh, for example, GitLab, GITI, FORGEHO, they will only accept Git protocol as, 1159.84s - 1163.88s | uh, an environment variable. And that's a, something that's looked at by Git to negotiate 1163.88s - 1167.18s | protocol versions. So you can say, oh, I want to use Git protocol version two or whatever. 1167.18s - 1170.82s | But for example, there's still some vulnerabilities there. If you were using a version of one 1170.82s - 1174.52s | of these, these are all written in Go, and it


chunk_id: 155_chunk_29
chunk_text:
there's GITI, there's GOGS, there's a, I always 1129.80s - 1134.46s | pronounce this wrong, FORGEHO. Tell me if I'm saying that right. Garrett, things like that. 1134.46s - 1139.04s | And they are using these embedded SSH libraries that speak the SSH protocol. And these 1139.04s - 1143.28s | libraries, because they're, you know, designed for general use, they will accept, you know, 1143.28s - 1147.88s | any environment variable you send. And they rely on the client, the user of the library, to, 1147.88s - 1154.56s | uh, limit what is going on. Um, and so that's generally okay. Like a lot of them do it 1154.56s - 1159.84s | correctly. Uh, for example, GitLab, GITI, FORGEHO, they will only accept Git protocol as, 1159.84s - 1163.88s | uh, an environment variable. And that's a, something that's looked at by Git to negotiate 1163.88s - 1167.18s | protocol versions. So you can say, oh, I want to use Git protocol version two or whatever. 1167.18s - 1170.82s | But for example, there's still some vulnerabilities there. If you were using a version of one 1170.82s - 1174.52s | of these, these are all written in Go, and it was compiled using a version of Go prior to 1174.52s - 1180.56s | 1.19.3, which is a year or two old, um, on Windows systems, they don't properly sanitize 1180.56s - 1183.86s | the, uh, the value of the environment variable. So if you put a null in there, you can 1183.90s - 1188.94s | actually just inject arbitrary environment variables, which is, uh, super fun. But, um, 1188.94s - 1193.94s | there was another one that was really interesting in, uh, GOGS, where whenever it gets an 1193.94s - 1198.44s | environment variable, it actually runs the env command. And so the point of the env command 1198.44s - 1202.88s | is to start a new process, um, with a, a new environment with, you know, setting certain 1202.88s - 1207.68s | environment variables or whatever. And it starts a new process. It doesn't affect the 1207.68s - 1213.72s | environment that you're in, right? It, it, that's not how POSIX works. So you could 1213.72s - 1218.36s | just say, okay, well, I want to set an environment variable with, you know, daset, dash 1218.36s - 1224.76s | S A equals B, and then, you know, bash or,


chunk_id: 155_chunk_30
chunk_text:
was compiled using a version of Go prior to 1174.52s - 1180.56s | 1.19.3, which is a year or two old, um, on Windows systems, they don't properly sanitize 1180.56s - 1183.86s | the, uh, the value of the environment variable. So if you put a null in there, you can 1183.90s - 1188.94s | actually just inject arbitrary environment variables, which is, uh, super fun. But, um, 1188.94s - 1193.94s | there was another one that was really interesting in, uh, GOGS, where whenever it gets an 1193.94s - 1198.44s | environment variable, it actually runs the env command. And so the point of the env command 1198.44s - 1202.88s | is to start a new process, um, with a, a new environment with, you know, setting certain 1202.88s - 1207.68s | environment variables or whatever. And it starts a new process. It doesn't affect the 1207.68s - 1213.72s | environment that you're in, right? It, it, that's not how POSIX works. So you could 1213.72s - 1218.36s | just say, okay, well, I want to set an environment variable with, you know, daset, dash 1218.36s - 1224.76s | S A equals B, and then, you know, bash or, you know, touch temp foo or whatever, and you 1224.76s - 1228.46s | are just executing arbitrary commands. And we, we did reach out, there's, there's no 1228.46s - 1234.44s | patch for this, uh, it's, seems moribund, so maybe don't use it. Um. 1235.00s - 1238.94s | this one too. Um, this is a great example of like parallel discovery. So not, not in the 1238.94s - 1243.68s | court sense, but in the, uh, we reported this vulnerability on like April 24th and Sonar 1243.68s - 1247.28s | Research had reported the same bug to the same maintainer on the 22nd and they scooped us on 1247.28s - 1250.68s | the advisory. We both had our own separate GitHub advisories, but it's just hilarious. So 1250.68s - 1254.06s | we both managed to look at the same bug at the same time. So it's funny like how often that 1254.06s - 1257.32s | happens. And this is a great example. So props to the Sonar source folks for beating us by 1257.32s - 1261.16s | two days. Uh, and they did a really great blog post about how the bug works, but it, it 1261.16s - 1263.80s |


chunk_id: 155_chunk_31
chunk_text:
you know, touch temp foo or whatever, and you 1224.76s - 1228.46s | are just executing arbitrary commands. And we, we did reach out, there's, there's no 1228.46s - 1234.44s | patch for this, uh, it's, seems moribund, so maybe don't use it. Um. 1235.00s - 1238.94s | this one too. Um, this is a great example of like parallel discovery. So not, not in the 1238.94s - 1243.68s | court sense, but in the, uh, we reported this vulnerability on like April 24th and Sonar 1243.68s - 1247.28s | Research had reported the same bug to the same maintainer on the 22nd and they scooped us on 1247.28s - 1250.68s | the advisory. We both had our own separate GitHub advisories, but it's just hilarious. So 1250.68s - 1254.06s | we both managed to look at the same bug at the same time. So it's funny like how often that 1254.06s - 1257.32s | happens. And this is a great example. So props to the Sonar source folks for beating us by 1257.32s - 1261.16s | two days. Uh, and they did a really great blog post about how the bug works, but it, it 1261.16s - 1263.80s | almost looks like a backdoor cause this doesn't actually influence the environment of the 1263.80s - 1269.30s | subprocess. It's just a straight command exec pre-auth. So it's a, it's a funky bug. Yeah. 1269.30s - 1274.34s | Yeah, exactly. Thank you, HG. Um, so going back to these, uh, these libraries. So for 1274.34s - 1279.18s | example, uh, Apache Mino, which is a Java, uh, implementation of SSH will accept any 1279.18s - 1285.24s | variable you want. Um, and most of the time, uh, it doesn't really run into anything, but 1285.24s - 1288.58s | this is, this is maybe my whole, this is maybe my favorite thing that we found, uh, 1288.58s - 1292.98s | personally. Uh, so there's this piece of software called SoftServe and it's designed to 1292.98s - 1299.32s | build, um, get repos and it gives you this beautiful, uh, SSH or, you know, CLI, you SSH 1299.32s - 1304.26s | and you control it, you can do whatever. And it uses, um, the charm bracelet SSH, uh, 1304.26s - 1309.36s | library, which is built on top of goes SSH. Um, and it will accept any environment 1309.36s - 1313.76s |


chunk_id: 155_chunk_32
chunk_text:
almost looks like a backdoor cause this doesn't actually influence the environment of the 1263.80s - 1269.30s | subprocess. It's just a straight command exec pre-auth. So it's a, it's a funky bug. Yeah. 1269.30s - 1274.34s | Yeah, exactly. Thank you, HG. Um, so going back to these, uh, these libraries. So for 1274.34s - 1279.18s | example, uh, Apache Mino, which is a Java, uh, implementation of SSH will accept any 1279.18s - 1285.24s | variable you want. Um, and most of the time, uh, it doesn't really run into anything, but 1285.24s - 1288.58s | this is, this is maybe my whole, this is maybe my favorite thing that we found, uh, 1288.58s - 1292.98s | personally. Uh, so there's this piece of software called SoftServe and it's designed to 1292.98s - 1299.32s | build, um, get repos and it gives you this beautiful, uh, SSH or, you know, CLI, you SSH 1299.32s - 1304.26s | and you control it, you can do whatever. And it uses, um, the charm bracelet SSH, uh, 1304.26s - 1309.36s | library, which is built on top of goes SSH. Um, and it will accept any environment 1309.36s - 1313.76s | variable or it did. We reported it, they fixed it. This is our CVE, go us. Um, but what's 1313.78s - 1320.56s | fun is you can, first off, watch how slow I am when I'm typing in a, in GIF form, but, um, 1320.56s - 1325.82s | you can, uh, we just basically created some shellcode and we checked it into LFS and you 1325.82s - 1329.50s | can actually do this in lots of different ways. LFS just, uh, get LFS as large file 1329.50s - 1332.96s | storage. It, it just makes it to where it's not compressed and, uh, the file name is 1332.96s - 1336.18s | predictable so we don't have to worry about it too much. Uh, makes it easier to exploit. 1336.18s - 1341.18s | We push it up to, uh, to SoftServe and then, uh, doing the SHA 256 sum of our shellcode 1343.78s - 1347.12s | because that gives us the, uh, the file name that we can, you know, guess. And then we 1347.12s - 1352.12s | just set LD preload to our shellcode and we now have, you know, shell on that system. So 1353.66s - 1357.26s | that


chunk_id: 155_chunk_33
chunk_text:
variable or it did. We reported it, they fixed it. This is our CVE, go us. Um, but what's 1313.78s - 1320.56s | fun is you can, first off, watch how slow I am when I'm typing in a, in GIF form, but, um, 1320.56s - 1325.82s | you can, uh, we just basically created some shellcode and we checked it into LFS and you 1325.82s - 1329.50s | can actually do this in lots of different ways. LFS just, uh, get LFS as large file 1329.50s - 1332.96s | storage. It, it just makes it to where it's not compressed and, uh, the file name is 1332.96s - 1336.18s | predictable so we don't have to worry about it too much. Uh, makes it easier to exploit. 1336.18s - 1341.18s | We push it up to, uh, to SoftServe and then, uh, doing the SHA 256 sum of our shellcode 1343.78s - 1347.12s | because that gives us the, uh, the file name that we can, you know, guess. And then we 1347.12s - 1352.12s | just set LD preload to our shellcode and we now have, you know, shell on that system. So 1353.66s - 1357.26s | that was super fun. Uh, I, I always love when I get a shell and I'm just like, oh, this is 1357.26s - 1360.70s | great, you know? Uh, so that made me really happy. And these, uh, these folks were really 1360.70s - 1365.24s | super cool to work with. Um, we, uh, we disclosed that and they were very, very nice. 1365.24s - 1372.24s | Uh, but now moving on to, uh, broken states, which is the SSH state machine to HD. 1372.26s - 1376.30s | Thanks. Um, another fun thing about the SoftServe side. So that particular exploit, um, 1376.30s - 1380.14s | because it's using Git LFS, you can reference a raw file on disk and you don't have to know 1380.14s - 1383.40s | your file location. You can use relative paths and stuff. But this works just fine for 1383.40s - 1387.04s | unauthenticated Git access too. So if you're running SoftServe for read-only access, you can 1387.04s - 1390.08s | still exploit it. It just requires jumping through more hoops because you can specify LD 1390.08s - 1394.18s | preload, LD load library. You can set LD library debug output paths. There's a million


chunk_id: 155_chunk_34
chunk_text:
was super fun. Uh, I, I always love when I get a shell and I'm just like, oh, this is 1357.26s - 1360.70s | great, you know? Uh, so that made me really happy. And these, uh, these folks were really 1360.70s - 1365.24s | super cool to work with. Um, we, uh, we disclosed that and they were very, very nice. 1365.24s - 1372.24s | Uh, but now moving on to, uh, broken states, which is the SSH state machine to HD. 1372.26s - 1376.30s | Thanks. Um, another fun thing about the SoftServe side. So that particular exploit, um, 1376.30s - 1380.14s | because it's using Git LFS, you can reference a raw file on disk and you don't have to know 1380.14s - 1383.40s | your file location. You can use relative paths and stuff. But this works just fine for 1383.40s - 1387.04s | unauthenticated Git access too. So if you're running SoftServe for read-only access, you can 1387.04s - 1390.08s | still exploit it. It just requires jumping through more hoops because you can specify LD 1390.08s - 1394.18s | preload, LD load library. You can set LD library debug output paths. There's a million ways 1394.18s - 1397.98s | you can, like, eventually get a file onto disk to then load or to trigger a shell script. 1397.98s - 1401.62s | Just LFS was the quickest way to be like, yes, we're loading arbitrary code. So it, right 1401.64s - 1405.04s | access to the repo is not a requirement to exploit SoftServe. And there's still about 10 1405.04s - 1407.88s | of those suckers hanging out on the internet right now that are exploitable. So if you're 1407.88s - 1412.52s | quick, they're yours. Um, kidding. But, um, so I'll talk a little bit about the SH state 1412.52s - 1416.72s | engine. So SSH is like incredibly complicated in terms of how it makes you go through these 1416.72s - 1419.92s | different states to get to each phase of the protocol. The stuff you're mostly familiar 1419.92s - 1424.36s | with is like when you first connect to the port 22, you'll see like SH-2.0, uh, server 1424.36s - 1427.70s | banner, things like that. If you happen to send the same manner back to it or you connect 1427.70s - 1431.04s | a dropper, then you'll get this big blob


chunk_id: 155_chunk_35
chunk_text:
ways 1394.18s - 1397.98s | you can, like, eventually get a file onto disk to then load or to trigger a shell script. 1397.98s - 1401.62s | Just LFS was the quickest way to be like, yes, we're loading arbitrary code. So it, right 1401.64s - 1405.04s | access to the repo is not a requirement to exploit SoftServe. And there's still about 10 1405.04s - 1407.88s | of those suckers hanging out on the internet right now that are exploitable. So if you're 1407.88s - 1412.52s | quick, they're yours. Um, kidding. But, um, so I'll talk a little bit about the SH state 1412.52s - 1416.72s | engine. So SSH is like incredibly complicated in terms of how it makes you go through these 1416.72s - 1419.92s | different states to get to each phase of the protocol. The stuff you're mostly familiar 1419.92s - 1424.36s | with is like when you first connect to the port 22, you'll see like SH-2.0, uh, server 1424.36s - 1427.70s | banner, things like that. If you happen to send the same manner back to it or you connect 1427.70s - 1431.04s | a dropper, then you'll get this big blob of stuff with no delimited strings, which have 1431.06s - 1434.66s | like ciphers and Macs and algorithms, things like that inside of it. So all that's kind of 1434.66s - 1439.46s | during the, uh, server version exchange and the key exchange. Um, the SH daemons are very 1439.46s - 1443.74s | clear that they will only accept a certain range of message values for each state. So before 1443.74s - 1447.34s | you've done the, uh, version exchange, you can't do the key exchange. Before you do the key 1447.34s - 1451.48s | exchange, you can't do authentication exchange. And this is enforced two ways. The protocol 1451.48s - 1455.84s | itself has a range of values allowed for each state. So values 1 through 49 are allowed in 1455.84s - 1460.12s | state 1, 0 to 79 in state 2 and so on. So if you're trying to like just open a channel or 1460.16s - 1463.14s | open a shell, technically there's no even message handler for it because it hasn't even 1463.14s - 1466.54s | configured the state handler to even accept that type of message yet. But that depends very 1466.54s - 1470.14s |


chunk_id: 155_chunk_36
chunk_text:
of stuff with no delimited strings, which have 1431.06s - 1434.66s | like ciphers and Macs and algorithms, things like that inside of it. So all that's kind of 1434.66s - 1439.46s | during the, uh, server version exchange and the key exchange. Um, the SH daemons are very 1439.46s - 1443.74s | clear that they will only accept a certain range of message values for each state. So before 1443.74s - 1447.34s | you've done the, uh, version exchange, you can't do the key exchange. Before you do the key 1447.34s - 1451.48s | exchange, you can't do authentication exchange. And this is enforced two ways. The protocol 1451.48s - 1455.84s | itself has a range of values allowed for each state. So values 1 through 49 are allowed in 1455.84s - 1460.12s | state 1, 0 to 79 in state 2 and so on. So if you're trying to like just open a channel or 1460.16s - 1463.14s | open a shell, technically there's no even message handler for it because it hasn't even 1463.14s - 1466.54s | configured the state handler to even accept that type of message yet. But that depends very 1466.54s - 1470.14s | much on the implementation. Uh, DropBear and OpenSH are really good at keeping a big 1470.14s - 1473.98s | command table. And when they go to another state, they just remove that command table 1473.98s - 1476.82s | handler for the previous state. So there's really no way to like accidentally call the 1476.82s - 1481.08s | wrong function pointer. Um, and that mostly works the way you expect. What's also 1481.08s - 1484.86s | interesting here is everything after the key exchange, of course, is encrypted. So SH is 1484.86s - 1487.92s | kind of like TLS in a lot of ways in that you have your normally version exchange, key 1487.96s - 1491.10s | exchange, algorithm, Tiffy Hellman type thing, and then you have like your encrypted 1491.10s - 1494.90s | transport. And that's where all the fun stuff happens, like authentication, your banner, if 1494.90s - 1497.64s | you will. Like if you ever see a pre-auth banner in SH, it's actually being sent over the 1497.64s - 1500.98s | encrypted connection, not over the on-auth connection. So typically when you're talking 1500.98s - 1503.34s | about an SH banner, you're not talking about the version string,


chunk_id: 155_chunk_37
chunk_text:
much on the implementation. Uh, DropBear and OpenSH are really good at keeping a big 1470.14s - 1473.98s | command table. And when they go to another state, they just remove that command table 1473.98s - 1476.82s | handler for the previous state. So there's really no way to like accidentally call the 1476.82s - 1481.08s | wrong function pointer. Um, and that mostly works the way you expect. What's also 1481.08s - 1484.86s | interesting here is everything after the key exchange, of course, is encrypted. So SH is 1484.86s - 1487.92s | kind of like TLS in a lot of ways in that you have your normally version exchange, key 1487.96s - 1491.10s | exchange, algorithm, Tiffy Hellman type thing, and then you have like your encrypted 1491.10s - 1494.90s | transport. And that's where all the fun stuff happens, like authentication, your banner, if 1494.90s - 1497.64s | you will. Like if you ever see a pre-auth banner in SH, it's actually being sent over the 1497.64s - 1500.98s | encrypted connection, not over the on-auth connection. So typically when you're talking 1500.98s - 1503.34s | about an SH banner, you're not talking about the version string, you're talking about the 1503.34s - 1507.14s | pre-auth big blob of data that it sends you when you try to authenticate. Um, so lots of 1507.14s - 1510.62s | cool stuff happening there, but you can see the state engine is pretty complicated. Um, 1510.62s - 1513.72s | what's also worth pointing out here is there's something called a larval session. So that 1513.72s - 1518.16s | means you've successfully authenticated, or maybe not, and it's the state of your shell 1518.16s - 1521.60s | before there's a shell. So effectively, if you haven't created a sub-process yet, you're in 1521.60s - 1524.84s | this kind of like larval state, and that's how the code generally references it. And that's 1524.84s - 1529.00s | important when we start getting into some of these other exploits. So a historic example 1529.00s - 1533.58s | where this has gone wrong is libsh. In 2018, someone reported vulnerability where this 1533.58s - 1536.98s | library is used for both client and server side. Same with opensh, same with dropper. They 1536.98s - 1540.62s | kind of share the same code base for both halves of the protocol. Um, and if you sent


chunk_id: 155_chunk_38
chunk_text:
you're talking about the 1503.34s - 1507.14s | pre-auth big blob of data that it sends you when you try to authenticate. Um, so lots of 1507.14s - 1510.62s | cool stuff happening there, but you can see the state engine is pretty complicated. Um, 1510.62s - 1513.72s | what's also worth pointing out here is there's something called a larval session. So that 1513.72s - 1518.16s | means you've successfully authenticated, or maybe not, and it's the state of your shell 1518.16s - 1521.60s | before there's a shell. So effectively, if you haven't created a sub-process yet, you're in 1521.60s - 1524.84s | this kind of like larval state, and that's how the code generally references it. And that's 1524.84s - 1529.00s | important when we start getting into some of these other exploits. So a historic example 1529.00s - 1533.58s | where this has gone wrong is libsh. In 2018, someone reported vulnerability where this 1533.58s - 1536.98s | library is used for both client and server side. Same with opensh, same with dropper. They 1536.98s - 1540.62s | kind of share the same code base for both halves of the protocol. Um, and if you sent the 1540.62s - 1543.92s | user-authenticated succeeded message from the client to the server, the server's like, oh, 1543.92s - 1547.32s | okay, cool, you're in, and that's fine. Um, and there's still a bunch of these libsh 1547.32s - 1550.36s | implementations out there that'll just drop you to a shell if you send user-auth success, and 1550.36s - 1554.64s | of course, you know, Sham will test for that and makes it easy for you to use it. Um, so we 1554.64s - 1558.54s | decided to take this up another level. Instead of just saying, let's just send a fake success 1558.54s - 1562.30s | message, let's just try to get a shell everywhere. Let's take every single part of the 1562.30s - 1566.14s | protocol transition and say, let's do half-auth, let's do full-auth, let's do a fake pubkey, 1566.14s - 1570.32s | let's do a password, let's do a password none, let's do even before sh user-auth command at 1570.32s - 1573.62s | all. And between every one of those attempts, we're gonna ask you for a shell. We're just 1573.62s - 1575.76s | gonna be like, how about a shell now? How about a


chunk_id: 155_chunk_39
chunk_text:
the 1540.62s - 1543.92s | user-authenticated succeeded message from the client to the server, the server's like, oh, 1543.92s - 1547.32s | okay, cool, you're in, and that's fine. Um, and there's still a bunch of these libsh 1547.32s - 1550.36s | implementations out there that'll just drop you to a shell if you send user-auth success, and 1550.36s - 1554.64s | of course, you know, Sham will test for that and makes it easy for you to use it. Um, so we 1554.64s - 1558.54s | decided to take this up another level. Instead of just saying, let's just send a fake success 1558.54s - 1562.30s | message, let's just try to get a shell everywhere. Let's take every single part of the 1562.30s - 1566.14s | protocol transition and say, let's do half-auth, let's do full-auth, let's do a fake pubkey, 1566.14s - 1570.32s | let's do a password, let's do a password none, let's do even before sh user-auth command at 1570.32s - 1573.62s | all. And between every one of those attempts, we're gonna ask you for a shell. We're just 1573.62s - 1575.76s | gonna be like, how about a shell now? How about a shell now? How about a shell now? How 1575.76s - 1579.60s | about now? Um, and it worked. Like, we got crap loads of shells from random devices because 1579.60s - 1583.30s | we asked them in weird states to give us a shell. So there's some out there where you don't 1583.30s - 1586.16s | even bother even starting the authentication process and it gives you a shell. There's some 1586.16s - 1588.86s | out there where you start the authentication process but don't finish, it gives you a shell. 1588.86s - 1592.80s | Like, it's all over the map. So, um, there's three good examples we talk about here. First 1592.80s - 1597.34s | one is the Digi transport, uh, gateways. They're mostly using, like, ICS environments. They're 1597.34s - 1600.70s | kind of, like, out in the field, hard and stuff. They act as, like, kind of the VPN router, if 1600.70s - 1605.68s | you will, for all the, all the juicy OT stuff you want to hack behind it. Um, so having a 1605.68s - 1608.78s | remote admin to these means you basically have serial port access to all the stuff behind it, 1608.78s


chunk_id: 155_chunk_40
chunk_text:
shell now? How about a shell now? How 1575.76s - 1579.60s | about now? Um, and it worked. Like, we got crap loads of shells from random devices because 1579.60s - 1583.30s | we asked them in weird states to give us a shell. So there's some out there where you don't 1583.30s - 1586.16s | even bother even starting the authentication process and it gives you a shell. There's some 1586.16s - 1588.86s | out there where you start the authentication process but don't finish, it gives you a shell. 1588.86s - 1592.80s | Like, it's all over the map. So, um, there's three good examples we talk about here. First 1592.80s - 1597.34s | one is the Digi transport, uh, gateways. They're mostly using, like, ICS environments. They're 1597.34s - 1600.70s | kind of, like, out in the field, hard and stuff. They act as, like, kind of the VPN router, if 1600.70s - 1605.68s | you will, for all the, all the juicy OT stuff you want to hack behind it. Um, so having a 1605.68s - 1608.78s | remote admin to these means you basically have serial port access to all the stuff behind it, 1608.78s - 1611.44s | which is great. So if you want to, like, blow up pipelines, things like that, that's how you 1611.44s - 1615.62s | do it. Um, so the Digi team was really cool. They were great to work with. Um, this device 1615.62s - 1618.72s | had already been, like, basically effectively legacy and retired, but it's still up for 1618.72s - 1621.92s | maintenance on screen patches. Like, they had to go find, like, the one developer who hadn't 1621.92s - 1624.80s | looked at this thing in five years and dust off their compiler and try to figure out how to 1624.86s - 1627.66s | build the damn thing and all that. And the funny thing about this is it ended up being an 1627.66s - 1633.10s | un, uh, an uninitialized variable in the SH engine. So it took us forever to repro, because 1633.10s - 1636.14s | we'd say, hey, we can get shells on, like, all these machines on the internet. Like, here's a 1636.14s - 1639.64s | bunch of them, here's the serial numbers, like, it's bad, go fix it. Like, we can't repro. I'm 1639.64s - 1642.78s | like, you gotta


chunk_id: 155_chunk_41
chunk_text:
- 1611.44s | which is great. So if you want to, like, blow up pipelines, things like that, that's how you 1611.44s - 1615.62s | do it. Um, so the Digi team was really cool. They were great to work with. Um, this device 1615.62s - 1618.72s | had already been, like, basically effectively legacy and retired, but it's still up for 1618.72s - 1621.92s | maintenance on screen patches. Like, they had to go find, like, the one developer who hadn't 1621.92s - 1624.80s | looked at this thing in five years and dust off their compiler and try to figure out how to 1624.86s - 1627.66s | build the damn thing and all that. And the funny thing about this is it ended up being an 1627.66s - 1633.10s | un, uh, an uninitialized variable in the SH engine. So it took us forever to repro, because 1633.10s - 1636.14s | we'd say, hey, we can get shells on, like, all these machines on the internet. Like, here's a 1636.14s - 1639.64s | bunch of them, here's the serial numbers, like, it's bad, go fix it. Like, we can't repro. I'm 1639.64s - 1642.78s | like, you gotta be kidding me. Like, just run the command. Like, what are you doing wrong? 1642.78s - 1646.74s | Like, it's run command, what's doing, it was not their fault, of course. It's that when they 1646.74s - 1650.02s | were setting up the machine to test, they were logging in for the rest of the age first and 1650.02s - 1653.02s | setting up their monitoring on it, and then they'd run our exploit and it wouldn't work. 1653.04s - 1656.28s | Because the uninitialized variable had been set. So just one of those things was, like, 1656.28s - 1659.38s | freaking Heisenbug repro, it took forever to fix. Anyways, so we finally got to the end of 1659.38s - 1661.96s | it, but the team was really cool, they're great to work with, they got a patch out, even for 1661.96s - 1665.92s | this legacy hardware, so awesome to see them actually supporting older systems. Uh, then we 1665.92s - 1669.90s | found these Realtek devices that are, like, branded to all kinds of things. Netterbit, um, 1669.90s - 1673.44s | Netist, there's probably like a dozen vendors out there, and they all have, like, different 1673.44s -


chunk_id: 155_chunk_42
chunk_text:
be kidding me. Like, just run the command. Like, what are you doing wrong? 1642.78s - 1646.74s | Like, it's run command, what's doing, it was not their fault, of course. It's that when they 1646.74s - 1650.02s | were setting up the machine to test, they were logging in for the rest of the age first and 1650.02s - 1653.02s | setting up their monitoring on it, and then they'd run our exploit and it wouldn't work. 1653.04s - 1656.28s | Because the uninitialized variable had been set. So just one of those things was, like, 1656.28s - 1659.38s | freaking Heisenbug repro, it took forever to fix. Anyways, so we finally got to the end of 1659.38s - 1661.96s | it, but the team was really cool, they're great to work with, they got a patch out, even for 1661.96s - 1665.92s | this legacy hardware, so awesome to see them actually supporting older systems. Uh, then we 1665.92s - 1669.90s | found these Realtek devices that are, like, branded to all kinds of things. Netterbit, um, 1669.90s - 1673.44s | Netist, there's probably like a dozen vendors out there, and they all have, like, different 1673.44s - 1677.34s | flavors of firmware from 2018 to 2023, and there's just, like, free shells everywhere. We 1677.34s - 1680.70s | didn't even know who to report it to, so that's, there's a bunch out there. Um, yeah, have fun 1680.72s - 1685.26s | with that. Uh, we also ran across a bunch of Panasonic switches, but also a really weird set, 1685.26s - 1688.26s | and we had no idea who to report that one to either, like, the normal Panasonic thing 1688.26s - 1691.46s | wasn't the right fit, and so, all the docs were in Japanese, we kind of gave up on that 1691.46s - 1694.50s | too, so we'll eventually figure out how to disclose that one, but there's a bunch of 1694.50s - 1697.10s | random Panasonic switches that'll just give you a shell pre-auth as well through the same 1697.10s - 1700.64s | mechanism. Um, and this is just kind of the tip of the iceberg. We found another, like, 70 1700.64s - 1704.18s | odd devices, we just haven't figured out where they are yet. Um, so, you know, basically 1704.18s - 1706.52s | take Shamble, throw it in your home network, throw


chunk_id: 155_chunk_43
chunk_text:
1677.34s | flavors of firmware from 2018 to 2023, and there's just, like, free shells everywhere. We 1677.34s - 1680.70s | didn't even know who to report it to, so that's, there's a bunch out there. Um, yeah, have fun 1680.72s - 1685.26s | with that. Uh, we also ran across a bunch of Panasonic switches, but also a really weird set, 1685.26s - 1688.26s | and we had no idea who to report that one to either, like, the normal Panasonic thing 1688.26s - 1691.46s | wasn't the right fit, and so, all the docs were in Japanese, we kind of gave up on that 1691.46s - 1694.50s | too, so we'll eventually figure out how to disclose that one, but there's a bunch of 1694.50s - 1697.10s | random Panasonic switches that'll just give you a shell pre-auth as well through the same 1697.10s - 1700.64s | mechanism. Um, and this is just kind of the tip of the iceberg. We found another, like, 70 1700.64s - 1704.18s | odd devices, we just haven't figured out where they are yet. Um, so, you know, basically 1704.18s - 1706.52s | take Shamble, throw it in your home network, throw it in your work network, and you might 1706.52s - 1710.12s | just get random free shells out of crap through this stage transition. The only trick of it 1710.14s - 1713.34s | here is you may have to specify a username that's not the default username. So, if the 1713.34s - 1716.88s | device typically has, like, an admin or manager username, specify all the default admin 1716.88s - 1722.56s | usernames for the products, and you'll be more likely to shake out some shells. So, here's 1722.56s - 1727.06s | an example of the Netterbit NSL-224s. These are really popular in Iran, so a huge portion 1727.06s - 1731.70s | of Iran uses these things, and you just basically log in as, you know, whatever you like. Um, 1731.70s - 1736.10s | so, in this case, we're using the Shamble shell for it, we're just saying, like, brute 1736.10s - 1739.68s | force all the different session states, and it logs us directly into it, and it shows 1740.20s - 1743.74s | the firmware, all the info, things like that. So, it's super straightforward. And here's an 1743.74s - 1748.20s | example of the Digi transport ICS gateways.


chunk_id: 155_chunk_44
chunk_text:
it in your work network, and you might 1706.52s - 1710.12s | just get random free shells out of crap through this stage transition. The only trick of it 1710.14s - 1713.34s | here is you may have to specify a username that's not the default username. So, if the 1713.34s - 1716.88s | device typically has, like, an admin or manager username, specify all the default admin 1716.88s - 1722.56s | usernames for the products, and you'll be more likely to shake out some shells. So, here's 1722.56s - 1727.06s | an example of the Netterbit NSL-224s. These are really popular in Iran, so a huge portion 1727.06s - 1731.70s | of Iran uses these things, and you just basically log in as, you know, whatever you like. Um, 1731.70s - 1736.10s | so, in this case, we're using the Shamble shell for it, we're just saying, like, brute 1736.10s - 1739.68s | force all the different session states, and it logs us directly into it, and it shows 1740.20s - 1743.74s | the firmware, all the info, things like that. So, it's super straightforward. And here's an 1743.74s - 1748.20s | example of the Digi transport ICS gateways. Same thing, what I love about this is when you 1748.20s - 1753.22s | log in, it says, welcome, your access is super! So, I also have the, you know, the South Park 1753.22s - 1757.58s | voice in my head when I see that, so it's amazing. Um, with that, I would like to talk a 1757.58s - 1762.66s | little bit about the OpenSH landscape. So, you know, typically we think about, like, SSH 1762.66s - 1767.80s | being OpenSH, and sure, it's like 90% of us, it's 87% of all SSH in the world, but OpenSH 1767.82s - 1772.12s | isn't just OpenSH either. There's a lot of different flavors of OpenSH. So, for folks who 1772.12s - 1777.76s | aren't super familiar, OpenSH was forked from OSSH, which was forked from the original V1, 1777.76s - 1784.40s | um, you know, tattoo, um, version of SSH back in the day. Um, but OpenSH wasn't designed 1784.40s - 1789.48s | for Linux. OpenSH was hard-coded for OpenBSD. Like, they didn't want our dirty Linux paws all 1789.48s - 1793.18s | over their beautiful SH daemon, so eventually they conceded and said, you know what, you 1793.18s -


chunk_id: 155_chunk_45
chunk_text:
Same thing, what I love about this is when you 1748.20s - 1753.22s | log in, it says, welcome, your access is super! So, I also have the, you know, the South Park 1753.22s - 1757.58s | voice in my head when I see that, so it's amazing. Um, with that, I would like to talk a 1757.58s - 1762.66s | little bit about the OpenSH landscape. So, you know, typically we think about, like, SSH 1762.66s - 1767.80s | being OpenSH, and sure, it's like 90% of us, it's 87% of all SSH in the world, but OpenSH 1767.82s - 1772.12s | isn't just OpenSH either. There's a lot of different flavors of OpenSH. So, for folks who 1772.12s - 1777.76s | aren't super familiar, OpenSH was forked from OSSH, which was forked from the original V1, 1777.76s - 1784.40s | um, you know, tattoo, um, version of SSH back in the day. Um, but OpenSH wasn't designed 1784.40s - 1789.48s | for Linux. OpenSH was hard-coded for OpenBSD. Like, they didn't want our dirty Linux paws all 1789.48s - 1793.18s | over their beautiful SH daemon, so eventually they conceded and said, you know what, you 1793.18s - 1796.62s | guys can, all you plebs can actually touch our beautiful SH code, but we're gonna create a 1796.64s - 1800.44s | version of OpenSH just for you called OpenSH Portable. So, when you talk about OpenSH, you're 1800.44s - 1803.64s | really talking about the portable version of OpenSH, which has a compatibility layer that 1803.64s - 1808.36s | makes, um, all of us heathens be able to use the nice functions of BSD, basically, uh, without 1808.36s - 1812.12s | all the pledge and cool things like that. But if you look at OpenSH Portable, there's actually a 1812.12s - 1816.60s | bunch of variants of that too. So, if you look at, like, who has molested OpenSH the most, 1816.60s - 1820.20s | we're gonna start off with Apple. Apple was just light touch. They just gave a little hug. 1820.20s - 1824.10s | They didn't really do much to it. Uh, they did not do terrible things to OpenSH. They, um, 1824.12s - 1829.96s | added some changes for, um, let's see, the key login, the endpoint event logging, uh, PKCS 1829.96s - 1833.32s | helper and keychain, things like that. Really straight forward, not


chunk_id: 155_chunk_46
chunk_text:
1796.62s | guys can, all you plebs can actually touch our beautiful SH code, but we're gonna create a 1796.64s - 1800.44s | version of OpenSH just for you called OpenSH Portable. So, when you talk about OpenSH, you're 1800.44s - 1803.64s | really talking about the portable version of OpenSH, which has a compatibility layer that 1803.64s - 1808.36s | makes, um, all of us heathens be able to use the nice functions of BSD, basically, uh, without 1808.36s - 1812.12s | all the pledge and cool things like that. But if you look at OpenSH Portable, there's actually a 1812.12s - 1816.60s | bunch of variants of that too. So, if you look at, like, who has molested OpenSH the most, 1816.60s - 1820.20s | we're gonna start off with Apple. Apple was just light touch. They just gave a little hug. 1820.20s - 1824.10s | They didn't really do much to it. Uh, they did not do terrible things to OpenSH. They, um, 1824.12s - 1829.96s | added some changes for, um, let's see, the key login, the endpoint event logging, uh, PKCS 1829.96s - 1833.32s | helper and keychain, things like that. Really straight forward, not terrible at all. Very 1833.32s - 1838.44s | happy that they did not destroy OpenSH. Um, if you start looking at Debian and Ubuntu, they've 1838.44s - 1843.40s | got about 36 different patches on top of the core OpenSH code. Uh, and those patches make it 1843.40s - 1847.94s | libxutils backdoor compatible, um, among other things, right? But there's a lot of changes, and 1847.94s - 1850.74s | those changes aren't getting the same scrutiny that, let's say, the rest of OpenSH code is 1850.74s - 1853.82s | getting. It's, it's basically linking it to all kinds of other libraries. It's the reason why it 1853.84s - 1857.44s | linked to system D. Um, there's a lot more attack service because of all those changes they 1857.44s - 1862.28s | put into the, those system patches. Now, moving up to Red Hat, now you're like 60 plus 1862.28s - 1865.82s | different patches. So even, even bigger attack service. And, you know, hopefully they're 1865.82s - 1868.82s | auditing this stuff and everyone's looking at it, cause it's important, cause if you're hacking 1868.82s - 1872.12s | a Linux server, it's probably gonna be either Debian, Ubuntu, or


chunk_id: 155_chunk_47
chunk_text:
terrible at all. Very 1833.32s - 1838.44s | happy that they did not destroy OpenSH. Um, if you start looking at Debian and Ubuntu, they've 1838.44s - 1843.40s | got about 36 different patches on top of the core OpenSH code. Uh, and those patches make it 1843.40s - 1847.94s | libxutils backdoor compatible, um, among other things, right? But there's a lot of changes, and 1847.94s - 1850.74s | those changes aren't getting the same scrutiny that, let's say, the rest of OpenSH code is 1850.74s - 1853.82s | getting. It's, it's basically linking it to all kinds of other libraries. It's the reason why it 1853.84s - 1857.44s | linked to system D. Um, there's a lot more attack service because of all those changes they 1857.44s - 1862.28s | put into the, those system patches. Now, moving up to Red Hat, now you're like 60 plus 1862.28s - 1865.82s | different patches. So even, even bigger attack service. And, you know, hopefully they're 1865.82s - 1868.82s | auditing this stuff and everyone's looking at it, cause it's important, cause if you're hacking 1868.82s - 1872.12s | a Linux server, it's probably gonna be either Debian, Ubuntu, or Red Hat based these days, 1872.12s - 1875.36s | right? Unless you're like, I use ARC. You know, you know, there's only a few of those out 1875.36s - 1881.46s | there. Um, so, um, if you're using, uh, you know, Debian, Ubuntu, Red Hat, Linux, etc., um, 1881.46s - 1885.48s | you probably have a ton of different patches on top of OpenSH that are not pure OpenSH, if 1885.48s - 1889.52s | you will. Uh, you've mangled pretty well. And then there's a thing called PKI-SSH, which I 1889.52s - 1893.82s | think probably a lot of folks haven't heard about. It was forked from OpenSH back in 2002 1893.82s - 1898.50s | to support X.509 certificates and then FIPS code. So because it supports X.509 and FIPS, a lot 1898.50s - 1902.62s | of the networking vendors decided to use that instead of regular SSH, uh, to build out their 1902.62s - 1905.22s | products because they want to sell to the federal government and they want to use 1905.22s - 1909.70s | Crestiel crypto protocols. Um, so there's a thing called PKI-SSH. It forked in 2002. It 1909.74s - 1913.92s | mostly, it's almost like they


chunk_id: 155_chunk_48
chunk_text:
Red Hat based these days, 1872.12s - 1875.36s | right? Unless you're like, I use ARC. You know, you know, there's only a few of those out 1875.36s - 1881.46s | there. Um, so, um, if you're using, uh, you know, Debian, Ubuntu, Red Hat, Linux, etc., um, 1881.46s - 1885.48s | you probably have a ton of different patches on top of OpenSH that are not pure OpenSH, if 1885.48s - 1889.52s | you will. Uh, you've mangled pretty well. And then there's a thing called PKI-SSH, which I 1889.52s - 1893.82s | think probably a lot of folks haven't heard about. It was forked from OpenSH back in 2002 1893.82s - 1898.50s | to support X.509 certificates and then FIPS code. So because it supports X.509 and FIPS, a lot 1898.50s - 1902.62s | of the networking vendors decided to use that instead of regular SSH, uh, to build out their 1902.62s - 1905.22s | products because they want to sell to the federal government and they want to use 1905.22s - 1909.70s | Crestiel crypto protocols. Um, so there's a thing called PKI-SSH. It forked in 2002. It 1909.74s - 1913.92s | mostly, it's almost like they hate each other. If you do, like, so, put it this way, we diffed 1913.92s - 1917.76s | all of it. We looked at, like, OpenSH mainline to every one of these forks and just read every 1917.76s - 1921.82s | single line of code for days and weeks. Well, that was my vacation. I just did that for hours 1921.82s - 1926.60s | a day. Um, but the PKI-X one is really funny because you'll see a change in OpenSH and then a 1926.60s - 1932.30s | change is written slightly differently in PKI-SSH and they oftentimes disagree. Like, once 1932.30s - 1935.60s | in a while they mostly match, like, if one equal this, if that equal that, but occasionally it's 1935.64s - 1939.82s | like, if not, when equal this. And it's like, so, there's probably some weird compatibility 1939.82s - 1943.18s | bugs because the changes weren't followed entirely. They obviously don't want to look like 1943.18s - 1946.82s | they're copying OpenSH, but they also can't not copy it and stay compatible. So you can just, 1946.82s - 1950.76s | you can feel the rage between the two teams there. It's great. Um, I've never


chunk_id: 155_chunk_49
chunk_text:
hate each other. If you do, like, so, put it this way, we diffed 1913.92s - 1917.76s | all of it. We looked at, like, OpenSH mainline to every one of these forks and just read every 1917.76s - 1921.82s | single line of code for days and weeks. Well, that was my vacation. I just did that for hours 1921.82s - 1926.60s | a day. Um, but the PKI-X one is really funny because you'll see a change in OpenSH and then a 1926.60s - 1932.30s | change is written slightly differently in PKI-SSH and they oftentimes disagree. Like, once 1932.30s - 1935.60s | in a while they mostly match, like, if one equal this, if that equal that, but occasionally it's 1935.64s - 1939.82s | like, if not, when equal this. And it's like, so, there's probably some weird compatibility 1939.82s - 1943.18s | bugs because the changes weren't followed entirely. They obviously don't want to look like 1943.18s - 1946.82s | they're copying OpenSH, but they also can't not copy it and stay compatible. So you can just, 1946.82s - 1950.76s | you can feel the rage between the two teams there. It's great. Um, I've never felt so much 1950.76s - 1955.66s | like animosity in a code diff before. Um, but finally, uh, the, the really fun one here is 1955.66s - 1960.30s | Windows. So Microsoft Windows, um, shipped OpenSH on Windows 10. Everyone's like, oh my 1960.30s - 1963.74s | God, I can actually type SSH and curl. I don't have to do all these stupid commands anymore to 1963.74s - 1967.32s | back to my Windows box. I can use the built-in nice native Linux commands to back to my 1967.32s - 1970.98s | Linux boxes. And that was great. So we love the fact that SH clients on Windows, we can use 1970.98s - 1975.52s | them for all kinds of stuff. Um, there's also SH server for Windows. And so there's a fork for, 1975.52s - 1981.06s | uh, of OpenSH portable called OpenSH, um, under the PowerShell GitHub repo. And they just 1981.06s - 1985.26s | massacred it. There's like 350 files are changed. They ripped out everything. All those secure 1985.26s - 1989.48s | parts of SH kind of just got put into the corner over there, uh, and, and deleted. And then 1989.48s - 1993.24s | it's


chunk_id: 155_chunk_50
chunk_text:
felt so much 1950.76s - 1955.66s | like animosity in a code diff before. Um, but finally, uh, the, the really fun one here is 1955.66s - 1960.30s | Windows. So Microsoft Windows, um, shipped OpenSH on Windows 10. Everyone's like, oh my 1960.30s - 1963.74s | God, I can actually type SSH and curl. I don't have to do all these stupid commands anymore to 1963.74s - 1967.32s | back to my Windows box. I can use the built-in nice native Linux commands to back to my 1967.32s - 1970.98s | Linux boxes. And that was great. So we love the fact that SH clients on Windows, we can use 1970.98s - 1975.52s | them for all kinds of stuff. Um, there's also SH server for Windows. And so there's a fork for, 1975.52s - 1981.06s | uh, of OpenSH portable called OpenSH, um, under the PowerShell GitHub repo. And they just 1981.06s - 1985.26s | massacred it. There's like 350 files are changed. They ripped out everything. All those secure 1985.26s - 1989.48s | parts of SH kind of just got put into the corner over there, uh, and, and deleted. And then 1989.48s - 1993.24s | it's like, if Windows do something totally different. So they ripped out support. They ripped 1993.24s - 1996.78s | out, um, the PrivSep stuff works totally different through a sub process versus the fork 1996.78s - 2001.28s | because there's no forks on Windows. Um, they, uh, logged to Windows Event Viewer. They 2001.28s - 2005.68s | logged, uh, they sent telemetry back to Microsoft for everything you do. Um, they still 2005.68s - 2009.06s | haven't bothered fixing Terrapin. Like, it just, it's a very different fork. So if you're 2009.06s - 2012.82s | using Windows and SH, either a client or a server, you probably want to pay attention to this 2012.82s - 2017.16s | next slide, which is, uh, let's see, this is what it looks like. Not super exciting. But if you 2017.16s - 2019.90s | start looking through the OpenSH for Windows code, you can start looking at the telemetry 2019.90s - 2023.94s | callback. You can't disable this crap. Unless you disable telemetry, telemetry total on your 2023.94s - 2028.64s | machine. Every single connection going to your Windows, your SH server on Windows is sending 2028.64s - 2032.20s | your client version and server


chunk_id: 155_chunk_51
chunk_text:
like, if Windows do something totally different. So they ripped out support. They ripped 1993.24s - 1996.78s | out, um, the PrivSep stuff works totally different through a sub process versus the fork 1996.78s - 2001.28s | because there's no forks on Windows. Um, they, uh, logged to Windows Event Viewer. They 2001.28s - 2005.68s | logged, uh, they sent telemetry back to Microsoft for everything you do. Um, they still 2005.68s - 2009.06s | haven't bothered fixing Terrapin. Like, it just, it's a very different fork. So if you're 2009.06s - 2012.82s | using Windows and SH, either a client or a server, you probably want to pay attention to this 2012.82s - 2017.16s | next slide, which is, uh, let's see, this is what it looks like. Not super exciting. But if you 2017.16s - 2019.90s | start looking through the OpenSH for Windows code, you can start looking at the telemetry 2019.90s - 2023.94s | callback. You can't disable this crap. Unless you disable telemetry, telemetry total on your 2023.94s - 2028.64s | machine. Every single connection going to your Windows, your SH server on Windows is sending 2028.64s - 2032.20s | your client version and server version back to Microsoft in the telemetry. So every time you 2032.20s - 2035.48s | port scan your system, every time you run a Nessa scan against your Windows server, it's 2035.48s - 2038.88s | sending that info back. Every time you SH directly from your Mac OS client or whatever it is 2038.88s - 2042.56s | to a Windows server, it's sending your version string back to them. So Microsoft knows who you 2042.56s - 2046.82s | talk to and knows who you shell into. It collects all those craps for default telemetry. It 2046.82s - 2050.04s | even collects telemetry for things that are part of encrypted session. Like things like 2050.04s - 2053.98s | authentication methods that are negotiated over the secure channel. That's also shipped off 2053.98s - 2057.76s | to telemetry. So, uh, you know, I know we're all good, you know, cool kids here and we 2057.76s - 2062.56s | disable telemetry in VS code, but like, have you done so in OpenSH? Probably not, right? Um, 2062.56s - 2065.76s | so it's worth digging out the diagnostics viewer where you can look at the telemetry data on 2065.76s - 2070.84s | Windows and


chunk_id: 155_chunk_52
chunk_text:
version back to Microsoft in the telemetry. So every time you 2032.20s - 2035.48s | port scan your system, every time you run a Nessa scan against your Windows server, it's 2035.48s - 2038.88s | sending that info back. Every time you SH directly from your Mac OS client or whatever it is 2038.88s - 2042.56s | to a Windows server, it's sending your version string back to them. So Microsoft knows who you 2042.56s - 2046.82s | talk to and knows who you shell into. It collects all those craps for default telemetry. It 2046.82s - 2050.04s | even collects telemetry for things that are part of encrypted session. Like things like 2050.04s - 2053.98s | authentication methods that are negotiated over the secure channel. That's also shipped off 2053.98s - 2057.76s | to telemetry. So, uh, you know, I know we're all good, you know, cool kids here and we 2057.76s - 2062.56s | disable telemetry in VS code, but like, have you done so in OpenSH? Probably not, right? Um, 2062.56s - 2065.76s | so it's worth digging out the diagnostics viewer where you can look at the telemetry data on 2065.76s - 2070.84s | Windows and seeing like all your SH stuff being shipped off to the cloud. Um, so, yeah. But 2070.84s - 2075.54s | the next thing we'll talk about is even worse. Uh, so there's this really key function. We 2075.56s - 2081.74s | talked about OpenSH portal being a compatibility layer to make it, um, work not on OpenBSD. So 2081.74s - 2086.10s | the pure OpenBSD people, you know, can give us their code. Um, one of the functions that 2086.10s - 2090.08s | they implemented was timing safe B comp, which is like you expect. It compares two binary 2090.08s - 2094.18s | blobs as are these identical in a way that doesn't change based on how long the strings are, 2094.18s - 2097.92s | what contents they have. It can be consistent either way. This is to prevent side channel 2097.92s - 2101.46s | attacks. It's really clean, really code. It's only like four lines of code. Maybe take out 2101.48s - 2105.92s | the return and the int and the variable. It's only three lines of code. It's really hard to 2105.92s - 2110.52s | break this, right? This is a super nice great piece of code by,


chunk_id: 155_chunk_53
chunk_text:
seeing like all your SH stuff being shipped off to the cloud. Um, so, yeah. But 2070.84s - 2075.54s | the next thing we'll talk about is even worse. Uh, so there's this really key function. We 2075.56s - 2081.74s | talked about OpenSH portal being a compatibility layer to make it, um, work not on OpenBSD. So 2081.74s - 2086.10s | the pure OpenBSD people, you know, can give us their code. Um, one of the functions that 2086.10s - 2090.08s | they implemented was timing safe B comp, which is like you expect. It compares two binary 2090.08s - 2094.18s | blobs as are these identical in a way that doesn't change based on how long the strings are, 2094.18s - 2097.92s | what contents they have. It can be consistent either way. This is to prevent side channel 2097.92s - 2101.46s | attacks. It's really clean, really code. It's only like four lines of code. Maybe take out 2101.48s - 2105.92s | the return and the int and the variable. It's only three lines of code. It's really hard to 2105.92s - 2110.52s | break this, right? This is a super nice great piece of code by, uh, you know, Damian Miller. 2110.52s - 2114.32s | It's great. It's perfect. It's beautiful. And then OpenSH for Windows comes along. And they 2114.32s - 2121.20s | made it Windows compatible. So, uh, Windows compatible means, uh, first they look for a 2121.20s - 2125.90s | back R and a back N and they scrub out the back R. And so they just, they allied the fact 2125.90s - 2129.68s | that there's a back R back N. They treated it as if it was equal to a back N. But you can 2129.70s - 2133.80s | probably see there's some problems here. Um, we'll kind of highlight those real quick. First 2133.80s - 2137.48s | off, there's only two lines of code they added and they introduced a ton of bugs. It's no 2137.48s - 2142.32s | longer timing safe because they look one byte ahead. It's no longer, uh, secure because they 2142.32s - 2146.28s | read one byte out of, out of memory. They're actually reading the, the pointer plus one, not 2146.28s - 2149.82s | the pointer, which could be beyond the end of that particular variable. So for every back R 2149.82s - 2153.36s


chunk_id: 155_chunk_54
chunk_text:
uh, you know, Damian Miller. 2110.52s - 2114.32s | It's great. It's perfect. It's beautiful. And then OpenSH for Windows comes along. And they 2114.32s - 2121.20s | made it Windows compatible. So, uh, Windows compatible means, uh, first they look for a 2121.20s - 2125.90s | back R and a back N and they scrub out the back R. And so they just, they allied the fact 2125.90s - 2129.68s | that there's a back R back N. They treated it as if it was equal to a back N. But you can 2129.70s - 2133.80s | probably see there's some problems here. Um, we'll kind of highlight those real quick. First 2133.80s - 2137.48s | off, there's only two lines of code they added and they introduced a ton of bugs. It's no 2137.48s - 2142.32s | longer timing safe because they look one byte ahead. It's no longer, uh, secure because they 2142.32s - 2146.28s | read one byte out of, out of memory. They're actually reading the, the pointer plus one, not 2146.28s - 2149.82s | the pointer, which could be beyond the end of that particular variable. So for every back R 2149.82s - 2153.36s | back N sequence you have in the source buffer called by this function, you're actually going 2153.36s - 2157.60s | one byte out of the memory buffer and moving forward. And that, and then that value's being 2157.62s - 2161.22s | compared for your byte comparison. So if you know there's a blob of data at the end of your 2161.22s - 2164.50s | buffer, you can now just tell SH to not compare the bytes you thought you were comparing and 2164.50s - 2167.06s | now compare the bytes at the end of the buffer, which are typically a bunch of nulls or 2167.06s - 2170.40s | something more predictable. So there's a bunch of like really gnarly bugs that happen just 2170.40s - 2173.34s | because somebody decided their config parser didn't work with this function that wasn't 2173.34s - 2178.14s | designed to parse configs in the first place. Um, so it's about as bad as it gets. So this 2178.14s - 2182.34s | function is used in every single packet that gets processed by SH. So every crypto buffer 2182.36s - 2187.86s | coming into it gets the SH comp or comp buff check on


chunk_id: 155_chunk_55
chunk_text:
| back N sequence you have in the source buffer called by this function, you're actually going 2153.36s - 2157.60s | one byte out of the memory buffer and moving forward. And that, and then that value's being 2157.62s - 2161.22s | compared for your byte comparison. So if you know there's a blob of data at the end of your 2161.22s - 2164.50s | buffer, you can now just tell SH to not compare the bytes you thought you were comparing and 2164.50s - 2167.06s | now compare the bytes at the end of the buffer, which are typically a bunch of nulls or 2167.06s - 2170.40s | something more predictable. So there's a bunch of like really gnarly bugs that happen just 2170.40s - 2173.34s | because somebody decided their config parser didn't work with this function that wasn't 2173.34s - 2178.14s | designed to parse configs in the first place. Um, so it's about as bad as it gets. So this 2178.14s - 2182.34s | function is used in every single packet that gets processed by SH. So every crypto buffer 2182.36s - 2187.86s | coming into it gets the SH comp or comp buff check on it. And, and basically it gets buggy 2187.86s - 2191.46s | really quick. Um, it's used for RSA signature validation, all this stuff. But the question 2191.46s - 2194.90s | was like, can we actually exploit it? And that's where it gets tricky. It's like the buffer 2194.90s - 2198.64s | that you can, that triggers the bug is the first buffer, first parameter, and the attacker 2198.64s - 2202.28s | doesn't control it directly. But if you do enough signing operations, you're not packets. 2202.28s - 2205.18s | Eventually you get a buffer that has at least one back R back N in it. If you get to two, you 2205.18s - 2207.84s | get a little more interesting, but it's been really tough to actually get an exploit out of 2207.84s - 2212.08s | it. So of course, when we report to Microsoft, uh, their take is, you know, even though we've 2212.08s - 2216.50s | got $1 billion annual security budget, we've got 3,500 security professionals and we backdoor 2216.50s - 2221.36s | your timing, save B comp code, you do not get a banana. So we got nothing. They said, no, no, 2221.36s - 2224.10s |


chunk_id: 155_chunk_56
chunk_text:
it. And, and basically it gets buggy 2187.86s - 2191.46s | really quick. Um, it's used for RSA signature validation, all this stuff. But the question 2191.46s - 2194.90s | was like, can we actually exploit it? And that's where it gets tricky. It's like the buffer 2194.90s - 2198.64s | that you can, that triggers the bug is the first buffer, first parameter, and the attacker 2198.64s - 2202.28s | doesn't control it directly. But if you do enough signing operations, you're not packets. 2202.28s - 2205.18s | Eventually you get a buffer that has at least one back R back N in it. If you get to two, you 2205.18s - 2207.84s | get a little more interesting, but it's been really tough to actually get an exploit out of 2207.84s - 2212.08s | it. So of course, when we report to Microsoft, uh, their take is, you know, even though we've 2212.08s - 2216.50s | got $1 billion annual security budget, we've got 3,500 security professionals and we backdoor 2216.50s - 2221.36s | your timing, save B comp code, you do not get a banana. So we got nothing. They said, no, no, 2221.36s - 2224.10s | you guys don't get anything. We're not going to fix it. Have fun. Like, all right, well, we're 2224.10s - 2229.48s | going to talk about it at DEF CON. See you guys. Uh, so we did. Cool. Um, so that's the end of 2229.48s - 2232.68s | the, most of the content about SH. We're getting a little close to time. I want to make sure 2232.68s - 2235.68s | we have time for a little bit of questions here. Uh, we're going to talk a little about the 2235.68s - 2239.98s | shamble tool. So, uh, this tool is a research tool for SH simplifications. It's a 2239.98s - 2243.26s | combination of like, I think you can use today to scan your network, but I think you can extend to 2243.26s - 2247.42s | find even more horrible bugs in SH and then share them with the world. So, uh, we, we'd like 2247.42s - 2253.00s | you to, uh, play with it, make it better and, and rain hell upon vendors that do it wrong. Um, 2253.00s - 2256.00s | there's a lot of really cool interesting attacks against authentication, auth bypass, null 2256.00s - 2261.18s


chunk_id: 155_chunk_57
chunk_text:
you guys don't get anything. We're not going to fix it. Have fun. Like, all right, well, we're 2224.10s - 2229.48s | going to talk about it at DEF CON. See you guys. Uh, so we did. Cool. Um, so that's the end of 2229.48s - 2232.68s | the, most of the content about SH. We're getting a little close to time. I want to make sure 2232.68s - 2235.68s | we have time for a little bit of questions here. Uh, we're going to talk a little about the 2235.68s - 2239.98s | shamble tool. So, uh, this tool is a research tool for SH simplifications. It's a 2239.98s - 2243.26s | combination of like, I think you can use today to scan your network, but I think you can extend to 2243.26s - 2247.42s | find even more horrible bugs in SH and then share them with the world. So, uh, we, we'd like 2247.42s - 2253.00s | you to, uh, play with it, make it better and, and rain hell upon vendors that do it wrong. Um, 2253.00s - 2256.00s | there's a lot of really cool interesting attacks against authentication, auth bypass, null 2256.00s - 2261.18s | bytes, uh, ends up when you send a, uh, uh, SH password authentication, there's a, if you send a 2261.18s - 2264.82s | second parameter in addition to your password, that tells SH server that you want to change 2264.82s - 2268.14s | your password to that new value. So you can imagine that when we're developing this tool, we 2268.18s - 2273.38s | might have actually changed a lot of passwords. Uh, so be careful about that part. Uh, other than 2273.38s - 2276.38s | that, and it's kind of funny, it's like, oh, I got into all these machines and then you scan 2276.38s - 2278.98s | them again. Like now I can't get into all those machines. What happened? Well, we 2278.98s - 2282.36s | accidentally sent all the passwords to a null byte. Uh, there's also a lot of systems out 2282.36s - 2285.92s | there that will, uh, accept a null byte as a password. And there's specifically a lot of 2285.92s - 2289.54s | honeypots. So we doxed like 5,000 honeypots by accident because they accept null byte 2289.54s - 2292.04s | passwords where nothing else does. It's like, oh, here's all the


chunk_id: 155_chunk_58
chunk_text:
| bytes, uh, ends up when you send a, uh, uh, SH password authentication, there's a, if you send a 2261.18s - 2264.82s | second parameter in addition to your password, that tells SH server that you want to change 2264.82s - 2268.14s | your password to that new value. So you can imagine that when we're developing this tool, we 2268.18s - 2273.38s | might have actually changed a lot of passwords. Uh, so be careful about that part. Uh, other than 2273.38s - 2276.38s | that, and it's kind of funny, it's like, oh, I got into all these machines and then you scan 2276.38s - 2278.98s | them again. Like now I can't get into all those machines. What happened? Well, we 2278.98s - 2282.36s | accidentally sent all the passwords to a null byte. Uh, there's also a lot of systems out 2282.36s - 2285.92s | there that will, uh, accept a null byte as a password. And there's specifically a lot of 2285.92s - 2289.54s | honeypots. So we doxed like 5,000 honeypots by accident because they accept null byte 2289.54s - 2292.04s | passwords where nothing else does. It's like, oh, here's all the honeypots. That makes our 2292.04s - 2295.50s | lives a lot easier. Uh, a lot of the pre-auth state transition stuff, so you can extend 2295.50s - 2298.34s | those, make your own. It's kind of modular. It's not as cool as Metasploit, but it does a lot of 2298.34s - 2301.50s | stuff like that. You can kind of add your own checks to register them. Uh, and then all the 2301.50s - 2304.68s | post-session stuff too. If you get a session, but you don't get a shell, you can use 2304.68s - 2308.68s | Shamble to like bang on that session, try signals, jam keystrokes into it, generally do all 2308.68s - 2311.62s | the crap you don't want to do by hand that's really annoying. And eventually, um, do that. 2311.62s - 2314.48s | Plus we added some timing analysis stuff too. So if you think there's like timing leak in 2314.48s - 2317.62s | the username, we've got some built-in functions that'll tell you like what's the, what's the 2317.62s - 2321.10s | statistical probability of this username being different than this other one based on a timing 2321.10s - 2326.10s | attack with really


chunk_id: 155_chunk_59
chunk_text:
honeypots. That makes our 2292.04s - 2295.50s | lives a lot easier. Uh, a lot of the pre-auth state transition stuff, so you can extend 2295.50s - 2298.34s | those, make your own. It's kind of modular. It's not as cool as Metasploit, but it does a lot of 2298.34s - 2301.50s | stuff like that. You can kind of add your own checks to register them. Uh, and then all the 2301.50s - 2304.68s | post-session stuff too. If you get a session, but you don't get a shell, you can use 2304.68s - 2308.68s | Shamble to like bang on that session, try signals, jam keystrokes into it, generally do all 2308.68s - 2311.62s | the crap you don't want to do by hand that's really annoying. And eventually, um, do that. 2311.62s - 2314.48s | Plus we added some timing analysis stuff too. So if you think there's like timing leak in 2314.48s - 2317.62s | the username, we've got some built-in functions that'll tell you like what's the, what's the 2317.62s - 2321.10s | statistical probability of this username being different than this other one based on a timing 2321.10s - 2326.10s | attack with really tight, uh, timing. So Shamble.com gets you all that stuff. And there's a 2326.10s - 2329.24s | whole bunch of stuff it does. So I think first off, I want to hand it to Rob to talk about all 2329.24s - 2334.14s | the vulnerability checks we do. So, uh, Shamble will actually check for all the vulnerabilities 2334.14s - 2338.42s | we talked about, uh, over this. And they will not only check for you, it will give you proof. 2338.42s - 2342.62s | So you can run through, uh, it'll check for TCP forwarding, see if it can forward anywhere. 2342.62s - 2346.46s | It'll try different, uh, destinations, see what it can find. See if it's, uh, administratively 2346.46s - 2350.76s | prohibited for some. Uh, it will do generic environment injection. So it'll take, uh, 2350.76s - 2354.26s | environment variables that will control execution of processes and we'll check to see if the 2354.26s - 2358.46s | output changes and things like that. Uh, LD preload, stuff like that. Super useful. We'll say, 2358.46s - 2361.20s | oh, this is actually how it's vulnerable. This is what it can do. It'll tell you what to


chunk_id: 155_chunk_60
chunk_text:
tight, uh, timing. So Shamble.com gets you all that stuff. And there's a 2326.10s - 2329.24s | whole bunch of stuff it does. So I think first off, I want to hand it to Rob to talk about all 2329.24s - 2334.14s | the vulnerability checks we do. So, uh, Shamble will actually check for all the vulnerabilities 2334.14s - 2338.42s | we talked about, uh, over this. And they will not only check for you, it will give you proof. 2338.42s - 2342.62s | So you can run through, uh, it'll check for TCP forwarding, see if it can forward anywhere. 2342.62s - 2346.46s | It'll try different, uh, destinations, see what it can find. See if it's, uh, administratively 2346.46s - 2350.76s | prohibited for some. Uh, it will do generic environment injection. So it'll take, uh, 2350.76s - 2354.26s | environment variables that will control execution of processes and we'll check to see if the 2354.26s - 2358.46s | output changes and things like that. Uh, LD preload, stuff like that. Super useful. We'll say, 2358.46s - 2361.20s | oh, this is actually how it's vulnerable. This is what it can do. It'll tell you what to do 2361.20s - 2365.34s | next. Um, the software vulnerability that we talked about, it will, uh, it will give you the 2365.34s - 2370.68s | exact, uh, version and exactly the repo that it used and everything to get into there. Um, it 2370.68s - 2375.32s | will check the GOGS thing. That's the, uh, that's the, uh, ENV thing that looks vaguely like a 2375.34s - 2379.42s | backdoor, um, where it's executing ENV and it'll try to give you commands, uh, command 2379.42s - 2383.48s | execution there. And, uh, it will check the ruckus password escape. That's the one where you 2383.48s - 2389.36s | can, uh, you can put bat ticks or a dollar parents in the password and, uh, it'll just give 2389.36s - 2392.92s | that to you and it'll say, and the report you can actually see, uh, in the report, it'll say, 2392.92s - 2395.90s | okay, here's what I found. Here's the references and here's the proof. It'll actually give you 2395.90s - 2399.90s | the output that it found. Um, and you can just run that. They're automatically, it will 2399.90s - 2403.70s | automatically detect it and it


chunk_id: 155_chunk_61
chunk_text:
do 2361.20s - 2365.34s | next. Um, the software vulnerability that we talked about, it will, uh, it will give you the 2365.34s - 2370.68s | exact, uh, version and exactly the repo that it used and everything to get into there. Um, it 2370.68s - 2375.32s | will check the GOGS thing. That's the, uh, that's the, uh, ENV thing that looks vaguely like a 2375.34s - 2379.42s | backdoor, um, where it's executing ENV and it'll try to give you commands, uh, command 2379.42s - 2383.48s | execution there. And, uh, it will check the ruckus password escape. That's the one where you 2383.48s - 2389.36s | can, uh, you can put bat ticks or a dollar parents in the password and, uh, it'll just give 2389.36s - 2392.92s | that to you and it'll say, and the report you can actually see, uh, in the report, it'll say, 2392.92s - 2395.90s | okay, here's what I found. Here's the references and here's the proof. It'll actually give you 2395.90s - 2399.90s | the output that it found. Um, and you can just run that. They're automatically, it will 2399.90s - 2403.70s | automatically detect it and it will continue. We're continually adding more vulnerabilities 2403.76s - 2407.36s | to make it easier. So, uh, stay tuned and run that on all your systems and tell us what you 2407.36s - 2411.76s | find. Well, thanks Rob. And even the last 24 hours since the code's gone live, we've got a lot 2411.76s - 2414.70s | of great feedback, feature requests, things like that. So we're really excited to keep 2414.70s - 2418.00s | expanding it. Adding things like the, you know, a keystroke masher where it just like hits 2418.00s - 2420.74s | every possible keystroke trying to break out of the shell. Like the things you usually put 2420.74s - 2423.54s | your toddler in front of to make them give you shells. Like we'll just do that for you here. 2423.54s - 2428.48s | So, uh, who needs AI, right? Um, but in that sense, um, lots of cool stuff's already built in 2428.48s - 2435.20s | today. Uh, to get started you just run shamblescan-o. It generates a gigantic JSON file. Um, if 2435.20s - 2438.74s | you run this across the whole internet, you get about 60 gigs of data. I don't know


chunk_id: 155_chunk_62
chunk_text:
will continue. We're continually adding more vulnerabilities 2403.76s - 2407.36s | to make it easier. So, uh, stay tuned and run that on all your systems and tell us what you 2407.36s - 2411.76s | find. Well, thanks Rob. And even the last 24 hours since the code's gone live, we've got a lot 2411.76s - 2414.70s | of great feedback, feature requests, things like that. So we're really excited to keep 2414.70s - 2418.00s | expanding it. Adding things like the, you know, a keystroke masher where it just like hits 2418.00s - 2420.74s | every possible keystroke trying to break out of the shell. Like the things you usually put 2420.74s - 2423.54s | your toddler in front of to make them give you shells. Like we'll just do that for you here. 2423.54s - 2428.48s | So, uh, who needs AI, right? Um, but in that sense, um, lots of cool stuff's already built in 2428.48s - 2435.20s | today. Uh, to get started you just run shamblescan-o. It generates a gigantic JSON file. Um, if 2435.20s - 2438.74s | you run this across the whole internet, you get about 60 gigs of data. I don't know why I know 2438.74s - 2442.34s | that, but it's a lot of fun and you have millions of shells to go play with. Uh, and then you can 2442.34s - 2445.28s | run the analyze command. It'll try to like bucket your results based on what cool things you 2445.28s - 2449.42s | found. So if it, if it's like a known backdoor or a known, uh, bug, we'll hopefully stick into 2449.42s - 2452.72s | its own little file and you keep track of them that way. We also report like vulnerabilities in 2452.72s - 2456.32s | the JSON. You can scrape out and import. Uh, of course all this stuff's been, a lot of this has 2456.32s - 2459.84s | been linked into the run zero tool that we work on at, at our day job. And so it does a lot of 2459.84s - 2462.96s | these checks for you automatically, including grabbing all your keys, stuff like that. We're 2462.96s - 2467.00s | also looking at integrating it with, uh, HanoBox, uh, uh, bad keys project to automatically 2467.00s - 2470.54s | identify host keys that have been compromised. And shambles is unique in that


chunk_id: 155_chunk_63
chunk_text:
why I know 2438.74s - 2442.34s | that, but it's a lot of fun and you have millions of shells to go play with. Uh, and then you can 2442.34s - 2445.28s | run the analyze command. It'll try to like bucket your results based on what cool things you 2445.28s - 2449.42s | found. So if it, if it's like a known backdoor or a known, uh, bug, we'll hopefully stick into 2449.42s - 2452.72s | its own little file and you keep track of them that way. We also report like vulnerabilities in 2452.72s - 2456.32s | the JSON. You can scrape out and import. Uh, of course all this stuff's been, a lot of this has 2456.32s - 2459.84s | been linked into the run zero tool that we work on at, at our day job. And so it does a lot of 2459.84s - 2462.96s | these checks for you automatically, including grabbing all your keys, stuff like that. We're 2462.96s - 2467.00s | also looking at integrating it with, uh, HanoBox, uh, uh, bad keys project to automatically 2467.00s - 2470.54s | identify host keys that have been compromised. And shambles is unique in that it's one of the 2470.54s - 2474.28s | very few tools that test all of your host keys, not just your first host key. So if your 2474.28s - 2478.78s | machine has an RSA key, an ECDSA, an ED25519, et cetera, we'll actually grab all the 2478.78s - 2482.38s | different host keys by grabbing them all and then test all of those keys for weak keys and, uh, 2482.38s - 2485.52s | things like that. So it's still a little bit early for the bad key stuff, but we're, we're 2485.52s - 2489.26s | making progress. Uh, so an example, one of the neat things about shamble is that you can tell 2489.26s - 2493.30s | it to get into that larval session state without actually opening the process, which is a 2493.30s - 2497.54s | pain in the butt to do otherwise with an SH client. So essentially you say, um, you know, 2497.54s - 2501.64s | shamble scan dash dash interact equal first. So interact with the first session you get and 2501.64s - 2505.18s | then interact auto equal nothing. Do not do any, do not do anything at all and just drop you 2505.18s


chunk_id: 155_chunk_64
chunk_text:
it's one of the 2470.54s - 2474.28s | very few tools that test all of your host keys, not just your first host key. So if your 2474.28s - 2478.78s | machine has an RSA key, an ECDSA, an ED25519, et cetera, we'll actually grab all the 2478.78s - 2482.38s | different host keys by grabbing them all and then test all of those keys for weak keys and, uh, 2482.38s - 2485.52s | things like that. So it's still a little bit early for the bad key stuff, but we're, we're 2485.52s - 2489.26s | making progress. Uh, so an example, one of the neat things about shamble is that you can tell 2489.26s - 2493.30s | it to get into that larval session state without actually opening the process, which is a 2493.30s - 2497.54s | pain in the butt to do otherwise with an SH client. So essentially you say, um, you know, 2497.54s - 2501.64s | shamble scan dash dash interact equal first. So interact with the first session you get and 2501.64s - 2505.18s | then interact auto equal nothing. Do not do any, do not do anything at all and just drop you 2505.18s - 2508.62s | straight to the interpreter shell instead. And then from that interpreter shell, you can like 2508.62s - 2512.58s | set any environment variables you want. LD debug equal all, LD preload, whatever you like. 2512.58s - 2516.92s | Uh, you can start sending signals to it even pre shell. And then when you want to drop a shell, 2516.92s - 2520.46s | either type exec to run a command or you can do shell to get interactive shell. And at that 2520.46s - 2523.42s | point you can then mess with the shell itself. So it gives you kind of all the tools you need to 2523.42s - 2527.00s | manually mess with it. And control E is how you open the shamble shell, uh, from the prompt 2527.00s - 2530.36s | there. Just so we don't conflict with the SSH escape codes. And there's a million other things 2530.36s - 2533.00s | we can talk about, but we're going to keep kind of hammering on the code a little bit. And of 2533.00s - 2537.68s | course, happy scanning. And, uh, here's us just throwing out a slash 24 real quick, but it is 2537.68s -


chunk_id: 155_chunk_65
chunk_text:
- 2508.62s | straight to the interpreter shell instead. And then from that interpreter shell, you can like 2508.62s - 2512.58s | set any environment variables you want. LD debug equal all, LD preload, whatever you like. 2512.58s - 2516.92s | Uh, you can start sending signals to it even pre shell. And then when you want to drop a shell, 2516.92s - 2520.46s | either type exec to run a command or you can do shell to get interactive shell. And at that 2520.46s - 2523.42s | point you can then mess with the shell itself. So it gives you kind of all the tools you need to 2523.42s - 2527.00s | manually mess with it. And control E is how you open the shamble shell, uh, from the prompt 2527.00s - 2530.36s | there. Just so we don't conflict with the SSH escape codes. And there's a million other things 2530.36s - 2533.00s | we can talk about, but we're going to keep kind of hammering on the code a little bit. And of 2533.00s - 2537.68s | course, happy scanning. And, uh, here's us just throwing out a slash 24 real quick, but it is 2537.68s - 2541.38s | pretty fast too. It'll just, it'll eat all your CPU and RAM, just grinding away all your 2541.38s - 2547.62s | things. Um, and yeah, here's a bunch of bones we found. Thanks. We've got a couple minutes, I 2547.62s - 2550.98s | think, for questions. It looks like, uh, if you have a question, please come up to the middle 2550.98s - 2570.98s | standy thing and the mic so that everyone else can hear you. The mic may not be on. I'm not 2570.98s - 2579.96s | sure. You want to grab this one instead? Yeah. I'm sorry. You're still on mic. All right. So 2579.96s - 2585.40s | out of all the implementations that you have, uh, that you've scanned, what is in your 2585.46s - 2592.16s | opinion, the most secure? Uh, the most seeker or the most insecure? The most secure. Okay. 2592.16s - 2597.74s | Yeah. The, yeah. Two, you know, the, the TLDR of this entire talk is just use openSH98P1 2597.74s - 2601.14s | and don't do anything else. Just don't roll your own. That's basically all you found. Just 2601.14s - 2606.38s | like any other crypto, anytime you


chunk_id: 155_chunk_66
chunk_text:
2541.38s | pretty fast too. It'll just, it'll eat all your CPU and RAM, just grinding away all your 2541.38s - 2547.62s | things. Um, and yeah, here's a bunch of bones we found. Thanks. We've got a couple minutes, I 2547.62s - 2550.98s | think, for questions. It looks like, uh, if you have a question, please come up to the middle 2550.98s - 2570.98s | standy thing and the mic so that everyone else can hear you. The mic may not be on. I'm not 2570.98s - 2579.96s | sure. You want to grab this one instead? Yeah. I'm sorry. You're still on mic. All right. So 2579.96s - 2585.40s | out of all the implementations that you have, uh, that you've scanned, what is in your 2585.46s - 2592.16s | opinion, the most secure? Uh, the most seeker or the most insecure? The most secure. Okay. 2592.16s - 2597.74s | Yeah. The, yeah. Two, you know, the, the TLDR of this entire talk is just use openSH98P1 2597.74s - 2601.14s | and don't do anything else. Just don't roll your own. That's basically all you found. Just 2601.14s - 2606.38s | like any other crypto, anytime you try to mess with it, you break it. Oh, thank you. Uh, any 2606.38s - 2615.30s | other questions? Does anybody recognize my shirt? It's, it's particularly nerdy. I'll be your 2615.32s - 2623.76s | friend if you know. Anybody? Anybody? One more question? Uh, yes. Did you guys try anything 2623.76s - 2628.78s | with PuTTY? PuTTY, P-U-T-T-Y, client. I'm sorry. Yeah. It's, it's, uh, uh, TTY client for 2634.08s - 2638.88s | Windows called PuTTY. Oh, PuTTY. Do SSH. Yeah. We didn't look at the code for it because it's 2638.88s - 2642.48s | mostly client side. We really focused on all the, just the server side implementations. Uh, I 2642.48s - 2645.22s | know PuTTY does a bunch of weird things with the keys. Like it has a weird preferences in 2645.24s - 2649.64s | which EDSA keys uses, but we didn't get the chance to test PuTTY itself. There, there was an 2649.64s - 2653.14s | interesting, uh, not volume per se, but there was an interesting, uh, key generation issue 2653.14s - 2656.18s | with PuTTY this year. I need to go back and look at that. Yeah. Sorry. Another question? Does 2656.18s - 2662.62s


chunk_id: 155_chunk_67
chunk_text:
try to mess with it, you break it. Oh, thank you. Uh, any 2606.38s - 2615.30s | other questions? Does anybody recognize my shirt? It's, it's particularly nerdy. I'll be your 2615.32s - 2623.76s | friend if you know. Anybody? Anybody? One more question? Uh, yes. Did you guys try anything 2623.76s - 2628.78s | with PuTTY? PuTTY, P-U-T-T-Y, client. I'm sorry. Yeah. It's, it's, uh, uh, TTY client for 2634.08s - 2638.88s | Windows called PuTTY. Oh, PuTTY. Do SSH. Yeah. We didn't look at the code for it because it's 2638.88s - 2642.48s | mostly client side. We really focused on all the, just the server side implementations. Uh, I 2642.48s - 2645.22s | know PuTTY does a bunch of weird things with the keys. Like it has a weird preferences in 2645.24s - 2649.64s | which EDSA keys uses, but we didn't get the chance to test PuTTY itself. There, there was an 2649.64s - 2653.14s | interesting, uh, not volume per se, but there was an interesting, uh, key generation issue 2653.14s - 2656.18s | with PuTTY this year. I need to go back and look at that. Yeah. Sorry. Another question? Does 2656.18s - 2662.62s | Shamble detects honeypots? Like how do you guys are detecting honeypots? And like, um, how 2662.62s - 2671.28s | Shamble detects honeypots? Sorry? Oh, okay. Yeah. So the short version is you, it just makes 2671.28s - 2674.70s | the TCP connection to whatever port and range you tell it to. And then it looks for SSH 2674.72s - 2678.32s | version, does the handshake, all that. So, um, that's about it. Unless I missed your 2678.32s - 2684.02s | question. How is it detecting honeypots? Oh, honeypots. Yeah. Um, so the funny thing is 2684.02s - 2688.36s | most honeypots, uh, have a bug where they accept a nullbyte password and they just drop and 2688.36s - 2692.60s | they accept that where a real machine will never accept the nullbyte password. So in a, in a, in 2692.60s - 2695.70s | an open stage implementation, by default, if you put a null into the password field, it'll 2695.70s - 2699.74s | kick you back out. But most honeypots will accept you with a nullbyte password. And that's 2699.74s - 2703.44s | an easy way to find like 5,000 of them. Um, we found a bunch of other


chunk_id: 155_chunk_68
chunk_text:
| Shamble detects honeypots? Like how do you guys are detecting honeypots? And like, um, how 2662.62s - 2671.28s | Shamble detects honeypots? Sorry? Oh, okay. Yeah. So the short version is you, it just makes 2671.28s - 2674.70s | the TCP connection to whatever port and range you tell it to. And then it looks for SSH 2674.72s - 2678.32s | version, does the handshake, all that. So, um, that's about it. Unless I missed your 2678.32s - 2684.02s | question. How is it detecting honeypots? Oh, honeypots. Yeah. Um, so the funny thing is 2684.02s - 2688.36s | most honeypots, uh, have a bug where they accept a nullbyte password and they just drop and 2688.36s - 2692.60s | they accept that where a real machine will never accept the nullbyte password. So in a, in a, in 2692.60s - 2695.70s | an open stage implementation, by default, if you put a null into the password field, it'll 2695.70s - 2699.74s | kick you back out. But most honeypots will accept you with a nullbyte password. And that's 2699.74s - 2703.44s | an easy way to find like 5,000 of them. Um, we found a bunch of other ones through, uh, some 2703.48s - 2706.98s | of them accept any public key, no matter what key you give it. Other ones will take, uh, 2706.98s - 2711.28s | passwords that are, uh, outside the spec otherwise or m-mangled password requests. So you 2711.28s - 2717.13s | just throw garbage at it and it accepts it, you know it's not open stage. Cool. Alright, and 2717.13s - 2720.57s | that's it. Thank you very much. Thanks everybody. Look for us if you have any questions. We're 2720.57s - 2721.27s | happy to talk to y'all.


chunk_id: 155_chunk_69
chunk_text:
ones through, uh, some 2703.48s - 2706.98s | of them accept any public key, no matter what key you give it. Other ones will take, uh, 2706.98s - 2711.28s | passwords that are, uh, outside the spec otherwise or m-mangled password requests. So you 2711.28s - 2717.13s | just throw garbage at it and it accepts it, you know it's not open stage. Cool. Alright, and 2717.13s - 2720.57s | that's it. Thank you very much. Thanks everybody. Look for us if you have any questions. We're 2720.57s - 2721.27s | happy to talk to y'all.


chunk_id: 156_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=JERBqoTllaE", "title": "DEF CON 32 - Splitting the email atom exploiting parsers to bypass access controls - Gareth Heyes", "description": "Websites often parse users' email addresses to identify their organisation. Unfortunately, parsing emails is far from straightforward thanks to a collection of ancient RFCs that everyone knows are crazy. You can probably see where this is going\u2026\n\nIn this session, I'll introduce techniques for crafting RFC-compliant email addresses that bypass virtually all defences leading to broken assumptions, parser discrepancies and emails being routed to wildly unexpected destinations. I'll show you how to exploit multiple applications and libraries to spoof email domains, access internal systems protected by 'Zero Trust', and bypass employee-only registration barriers.\n\nThen I'll introduce another class of attack - harmless-looking input transformed into malicious payloads by unwitting libraries, leading to yet more misrouted emails, and blind CSS injection on a well-known target.\n\nI'll leave you with a full methodology and toolkit to identify and exploit your own targets, plus a CTF to develop your new skillset.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2175, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 5.76s | This text was transcribed using whisper model: large-v2 Welcome to splitting the email atom, exploiting parsers to bypass access controls. 6.96s - 12.56s | Email addresses might seem mundane but the RFCs governing them are downright bonkers. 13.44s - 19.92s | I'll show you why predicting an email destination is highly complex and I'll take you on a journey 19.92s - 27.20s | of ancient protocols, exotic encodings, access control bypasses and how I gained remote code 27.20s - 36.86s | execution from an RFC compliant email address. First I'll explain why email address parser 36.86s - 42.22s | discrepancies matter. Next I'll cover the shaky foundations that emails are built on. 43.66s - 49.18s | The core of the talk will focus on parser discrepancies including Unicode overflows, 49.18s - 53.74s | encoded word, AMP Unicode all with real world case studies. 54.94s - 59.34s | Then I'll share my methodology and tools for automating exploitation. 59.90s - 65.26s | Followed by advice on defense. I'll conclude with the key takeaways leaving five minutes 65.26s - 73.09s | for questions. There's also a bonus material for Defcon 2. So this research all started when we 73.09s - 79.65s | realized many websites use the domain part of the email address to infer the user's organization 79.65s -


chunk_id: 156_chunk_1
chunk_text:
access controls. 6.96s - 12.56s | Email addresses might seem mundane but the RFCs governing them are downright bonkers. 13.44s - 19.92s | I'll show you why predicting an email destination is highly complex and I'll take you on a journey 19.92s - 27.20s | of ancient protocols, exotic encodings, access control bypasses and how I gained remote code 27.20s - 36.86s | execution from an RFC compliant email address. First I'll explain why email address parser 36.86s - 42.22s | discrepancies matter. Next I'll cover the shaky foundations that emails are built on. 43.66s - 49.18s | The core of the talk will focus on parser discrepancies including Unicode overflows, 49.18s - 53.74s | encoded word, AMP Unicode all with real world case studies. 54.94s - 59.34s | Then I'll share my methodology and tools for automating exploitation. 59.90s - 65.26s | Followed by advice on defense. I'll conclude with the key takeaways leaving five minutes 65.26s - 73.09s | for questions. There's also a bonus material for Defcon 2. So this research all started when we 73.09s - 79.65s | realized many websites use the domain part of the email address to infer the user's organization 79.65s - 86.29s | and apply access control. For example Slack will automatically give you access to your company's 86.29s - 93.33s | Slack channel based upon your work email address and Cloudflare Zero Trust can be configured to 93.33s - 100.93s | use the email domain to protect your internal network. This makes email verification a critical 100.93s - 110.38s | security boundary. What could possibly go wrong? Everyone knows that URL parser discrepancies are 110.38s - 119.26s | critical as they can lead to SSRF path traversal and other security issues. Using an email domain 119.26s - 125.90s | for access control makes email address parser discrepancies critical too. Predicting which 125.90s - 132.30s | domain an email should be routed to should be simple but it's actually ludicrously difficult 132.30s - 140.90s | even for valid RFC compliant addresses. So we've established why email address parser discrepancies 140.90s - 148.10s | matter. Now let's explore why predicting the email destination is so challenging. Email addresses are 148.10s - 155.06s | built on a shaky foundation of RFCs designed many years ago. Validation is often performed using 155.06s - 162.26s | regular expressions copy and pasted from Stack Overflow all


chunk_id: 156_chunk_2
chunk_text:
86.29s | and apply access control. For example Slack will automatically give you access to your company's 86.29s - 93.33s | Slack channel based upon your work email address and Cloudflare Zero Trust can be configured to 93.33s - 100.93s | use the email domain to protect your internal network. This makes email verification a critical 100.93s - 110.38s | security boundary. What could possibly go wrong? Everyone knows that URL parser discrepancies are 110.38s - 119.26s | critical as they can lead to SSRF path traversal and other security issues. Using an email domain 119.26s - 125.90s | for access control makes email address parser discrepancies critical too. Predicting which 125.90s - 132.30s | domain an email should be routed to should be simple but it's actually ludicrously difficult 132.30s - 140.90s | even for valid RFC compliant addresses. So we've established why email address parser discrepancies 140.90s - 148.10s | matter. Now let's explore why predicting the email destination is so challenging. Email addresses are 148.10s - 155.06s | built on a shaky foundation of RFCs designed many years ago. Validation is often performed using 155.06s - 162.26s | regular expressions copy and pasted from Stack Overflow all trying to follow the RFC. However 162.26s - 170.56s | one mistake in the RegEx and everything can come crashing down. I'm not going to bore you 170.56s - 176.96s | with RFCs but I will highlight the important ones for this talk. For instance the characters before 176.96s - 183.20s | the at symbol in an email address are called the local part. The RFC allows what is called the 183.20s - 189.76s | quoted local part. This enables you to use characters in the local part that are not 189.76s - 196.08s | normally allowed by using quotes. In the example shown I use a quoted local part to use the at 196.08s - 204.08s | symbol as part of the address. The same RFC allows you to use a quoted per which means one character 204.08s - 210.24s | preceded by a backslash. This enables you to use a double quote and a backslash as part of the 210.24s - 217.20s | address provided it is it is escaped. Characters enclosed in parentheses are treated as comments 217.20s - 223.76s | and can be placed anywhere within the address except the quoted local part. They're all ignored


chunk_id: 156_chunk_3
chunk_text:
trying to follow the RFC. However 162.26s - 170.56s | one mistake in the RegEx and everything can come crashing down. I'm not going to bore you 170.56s - 176.96s | with RFCs but I will highlight the important ones for this talk. For instance the characters before 176.96s - 183.20s | the at symbol in an email address are called the local part. The RFC allows what is called the 183.20s - 189.76s | quoted local part. This enables you to use characters in the local part that are not 189.76s - 196.08s | normally allowed by using quotes. In the example shown I use a quoted local part to use the at 196.08s - 204.08s | symbol as part of the address. The same RFC allows you to use a quoted per which means one character 204.08s - 210.24s | preceded by a backslash. This enables you to use a double quote and a backslash as part of the 210.24s - 217.20s | address provided it is it is escaped. Characters enclosed in parentheses are treated as comments 217.20s - 223.76s | and can be placed anywhere within the address except the quoted local part. They're all ignored 223.76s - 233.07s | when the actual email is delivered. So here are two email addresses. You might be wondering which 233.07s - 240.83s | one is valid as this is a typical question asked in an email presentation. However it's the wrong 240.83s - 249.33s | question for this talk. The question you should be asking is which domain do they go to? You might 249.33s - 257.01s | expect both emails to go to example.com but that's not what happens. They both go to psres.net 257.97s - 263.97s | Remember how I said predicting the email destination is extremely difficult? This is just 263.97s - 270.53s | the tip of the iceberg. The first example works on postfix and the second example works on sendmail. 271.25s - 280.83s | If you are confused you should be. Next let's explain why this happens. A source route is a 280.83s - 286.91s | sequence of servers which an email is sent before reaching its final destination. Servers in the 286.91s - 293.15s | chain are separated by commas with the final destination marked with a colon before the 293.15s - 301.09s | recipient's full address. Another form of source routing


chunk_id: 156_chunk_4
chunk_text:
223.76s - 233.07s | when the actual email is delivered. So here are two email addresses. You might be wondering which 233.07s - 240.83s | one is valid as this is a typical question asked in an email presentation. However it's the wrong 240.83s - 249.33s | question for this talk. The question you should be asking is which domain do they go to? You might 249.33s - 257.01s | expect both emails to go to example.com but that's not what happens. They both go to psres.net 257.97s - 263.97s | Remember how I said predicting the email destination is extremely difficult? This is just 263.97s - 270.53s | the tip of the iceberg. The first example works on postfix and the second example works on sendmail. 271.25s - 280.83s | If you are confused you should be. Next let's explain why this happens. A source route is a 280.83s - 286.91s | sequence of servers which an email is sent before reaching its final destination. Servers in the 286.91s - 293.15s | chain are separated by commas with the final destination marked with a colon before the 293.15s - 301.09s | recipient's full address. Another form of source routing is called the percent hack. Despite its 301.09s - 306.69s | name the actual character is determined by the mailer. In this process the email is initially 306.69s - 313.25s | sent to example.com after which the percent symbol is converted into an at symbol and the email is 313.25s - 323.94s | sent to foo at psres.net. This process can be repeated several times. Before email addresses 323.94s - 332.10s | existed and even the internet people exchanged messages using UUCP. UUCP stands for Unix to Unix 332.10s - 338.50s | copy protocol. It's an early protocol that separates the local user and multiple hosts 338.50s - 344.58s | using an exclamation mark creating what is known as the bang path. Unlike the standard format 345.14s - 350.50s | for internet email addresses today the bang path lists the host from left to right 350.50s - 358.83s | with the destination user mailbox on the right as you can see in the example. So going back to 358.83s - 363.71s | the original examples with all the special characters removed what the parentheses actually 363.71s - 369.55s | do is remove that symbol and domain and without the domain


chunk_id: 156_chunk_5
chunk_text:
is called the percent hack. Despite its 301.09s - 306.69s | name the actual character is determined by the mailer. In this process the email is initially 306.69s - 313.25s | sent to example.com after which the percent symbol is converted into an at symbol and the email is 313.25s - 323.94s | sent to foo at psres.net. This process can be repeated several times. Before email addresses 323.94s - 332.10s | existed and even the internet people exchanged messages using UUCP. UUCP stands for Unix to Unix 332.10s - 338.50s | copy protocol. It's an early protocol that separates the local user and multiple hosts 338.50s - 344.58s | using an exclamation mark creating what is known as the bang path. Unlike the standard format 345.14s - 350.50s | for internet email addresses today the bang path lists the host from left to right 350.50s - 358.83s | with the destination user mailbox on the right as you can see in the example. So going back to 358.83s - 363.71s | the original examples with all the special characters removed what the parentheses actually 363.71s - 369.55s | do is remove that symbol and domain and without the domain part postfix treats that as a percent 369.95s - 376.03s | route. Using a backslash and escape in the at symbol has the same effect on send mail which 376.03s - 382.11s | treats the email as a UUCP address. Pretty damn crazy right and I've tested it and all those 382.11s - 389.41s | special characters do go to the mailbox. I wish I could tell you that I uncovered this behavior by 389.41s - 394.13s | analyzing thousands of lines of code and using a debugger and stepping through the code flow 394.13s - 401.41s | in send mail and postfix but that's not actually how it went down. I noticed an unnamed target 401.41s - 406.61s | was allowing all sorts of special characters so I just took all the characters pasted it into my 406.61s - 412.61s | email and expected it to fail but actually what happened was I checked the syslog on the box that 412.61s - 419.81s | I was testing and I noticed a difference. I was getting host unknown error in the delivery status 419.81s - 425.01s | notification. This was significant because it would suggest a different host was being


chunk_id: 156_chunk_6
chunk_text:
part postfix treats that as a percent 369.95s - 376.03s | route. Using a backslash and escape in the at symbol has the same effect on send mail which 376.03s - 382.11s | treats the email as a UUCP address. Pretty damn crazy right and I've tested it and all those 382.11s - 389.41s | special characters do go to the mailbox. I wish I could tell you that I uncovered this behavior by 389.41s - 394.13s | analyzing thousands of lines of code and using a debugger and stepping through the code flow 394.13s - 401.41s | in send mail and postfix but that's not actually how it went down. I noticed an unnamed target 401.41s - 406.61s | was allowing all sorts of special characters so I just took all the characters pasted it into my 406.61s - 412.61s | email and expected it to fail but actually what happened was I checked the syslog on the box that 412.61s - 419.81s | I was testing and I noticed a difference. I was getting host unknown error in the delivery status 419.81s - 425.01s | notification. This was significant because it would suggest a different host was being used. 426.53s - 430.69s | If you look at the error you'll notice the exclamation mark is missing. I didn't actually 430.69s - 436.53s | notice that at the time so I started to remove characters, resend the email and I still got the 436.53s - 443.01s | same error message. I narrowed it down to the exclamation mark and thus discovered this UUCP 443.01s - 449.97s | behavior. This was bonkers by sheer luck the characters I pasted into my email address 449.97s - 455.81s | ended with a backslash. I think I did this subconsciously and then when the exclamation 455.81s - 461.73s | mark was then sorry and then escape the out symbol and then the exclamation mark was treating 461.73s - 468.45s | the address as a UUCP address. I then wrote a fuzzer to find the other behavior with source 468.45s - 474.45s | routes with postfix. These findings gave me great confidence that there were a ton of bugs out there 474.45s - 484.10s | so I began to look for more and this is a bonus slide for Defcon. In the RFC there are optional 484.10s - 491.70s | SMTP parameters. I analyzed


chunk_id: 156_chunk_7
chunk_text:
used. 426.53s - 430.69s | If you look at the error you'll notice the exclamation mark is missing. I didn't actually 430.69s - 436.53s | notice that at the time so I started to remove characters, resend the email and I still got the 436.53s - 443.01s | same error message. I narrowed it down to the exclamation mark and thus discovered this UUCP 443.01s - 449.97s | behavior. This was bonkers by sheer luck the characters I pasted into my email address 449.97s - 455.81s | ended with a backslash. I think I did this subconsciously and then when the exclamation 455.81s - 461.73s | mark was then sorry and then escape the out symbol and then the exclamation mark was treating 461.73s - 468.45s | the address as a UUCP address. I then wrote a fuzzer to find the other behavior with source 468.45s - 474.45s | routes with postfix. These findings gave me great confidence that there were a ton of bugs out there 474.45s - 484.10s | so I began to look for more and this is a bonus slide for Defcon. In the RFC there are optional 484.10s - 491.70s | SMTP parameters. I analyzed the postfix code with a poet swinger colleague and I discovered that 491.70s - 495.78s | these parameters could be used to remove the domain part of the email address. 496.58s - 501.78s | I found this parsing bug on a real target but the application in question didn't use the email 501.78s - 508.10s | domain for access control. This attack works by escaping the backslash to break out of the 508.10s - 514.26s | quoted local part confusing the email validation. Then you can use the greater than to end the 514.26s - 520.98s | receipt to command and then you stick all the rest of the address within this SMTP optional 520.98s - 527.86s | parameter and you will notice that yeah this works on a real target and is a valid 531.30s - 537.62s | SMTP conversation so when it does the receipt to command it's a valid syntax for that. 540.37s - 545.97s | As a further bonus here is some surprising email parsing behavior that I uncovered 545.97s - 551.41s | works on postfix. I couldn't use these for access control bypasses but nevertheless 551.41s - 557.01s | they are interesting and challenges your


chunk_id: 156_chunk_8
chunk_text:
the postfix code with a poet swinger colleague and I discovered that 491.70s - 495.78s | these parameters could be used to remove the domain part of the email address. 496.58s - 501.78s | I found this parsing bug on a real target but the application in question didn't use the email 501.78s - 508.10s | domain for access control. This attack works by escaping the backslash to break out of the 508.10s - 514.26s | quoted local part confusing the email validation. Then you can use the greater than to end the 514.26s - 520.98s | receipt to command and then you stick all the rest of the address within this SMTP optional 520.98s - 527.86s | parameter and you will notice that yeah this works on a real target and is a valid 531.30s - 537.62s | SMTP conversation so when it does the receipt to command it's a valid syntax for that. 540.37s - 545.97s | As a further bonus here is some surprising email parsing behavior that I uncovered 545.97s - 551.41s | works on postfix. I couldn't use these for access control bypasses but nevertheless 551.41s - 557.01s | they are interesting and challenges your assumptions of how email addresses are parsed. 557.81s - 565.09s | This first one uses a UUCP address and is sent regardless of the quotes. It's pretty damn crazy. 567.14s - 573.54s | This second one uses source roots so if you use a square bracket syntax postfix will still treat 573.54s - 582.59s | it as a source root and send to that email. So one of the main problems I had to solve with 582.59s - 588.83s | this research was generating blocked characters. Since many web applications will block multiple 588.83s - 596.03s | art symbols so this following section focuses on unicode overflows which enable the creation 596.03s - 601.47s | of ASCII characters from higher unicode characters. It's pretty much normalization 601.47s - 610.37s | but I'm calling it unicode overflows because it's a different technique. So the PHP char 610.37s - 616.93s | function is a good example of how unicode overflows can occur. The function generates 616.93s - 622.45s | a character from an integer code point. Here's an illustration of how the algorithm is used by this 622.45s - 629.25s | function. It loops while the code point is less than zero


chunk_id: 156_chunk_9
chunk_text:
assumptions of how email addresses are parsed. 557.81s - 565.09s | This first one uses a UUCP address and is sent regardless of the quotes. It's pretty damn crazy. 567.14s - 573.54s | This second one uses source roots so if you use a square bracket syntax postfix will still treat 573.54s - 582.59s | it as a source root and send to that email. So one of the main problems I had to solve with 582.59s - 588.83s | this research was generating blocked characters. Since many web applications will block multiple 588.83s - 596.03s | art symbols so this following section focuses on unicode overflows which enable the creation 596.03s - 601.47s | of ASCII characters from higher unicode characters. It's pretty much normalization 601.47s - 610.37s | but I'm calling it unicode overflows because it's a different technique. So the PHP char 610.37s - 616.93s | function is a good example of how unicode overflows can occur. The function generates 616.93s - 622.45s | a character from an integer code point. Here's an illustration of how the algorithm is used by this 622.45s - 629.25s | function. It loops while the code point is less than zero continually adding 256 until it's non 629.25s - 636.93s | negative because why not it's PHP after all. Then it uses the mod operation to ensure the byte value 636.93s - 644.61s | is always within a range of 0 to 255. So if you introduce a unicode character is larger than 255 644.61s - 650.37s | it'd be truncated into this range. Note that unicode overflows aren't just specific to PHP. 652.93s - 659.65s | So generating a unicode overflow in JavaScript is quite simple using the from code point method. 660.29s - 667.49s | First you pass the number that will cause the overflow such as 0x100 which is 256 in decimal. 668.13s - 672.69s | Next you provide the second hex number to specify the actual character that you want 673.57s - 680.69s | like 0x40 which is the art symbol. The from code point method will generate a unicode character 680.77s - 686.29s | and when this character is transformed to fit within 255 a system that doesn't support higher 686.29s - 690.93s | unicode characters will produce the ASCII character specified by the second number. 693.39s - 698.99s | So I hunted for real world


chunk_id: 156_chunk_10
chunk_text:
continually adding 256 until it's non 629.25s - 636.93s | negative because why not it's PHP after all. Then it uses the mod operation to ensure the byte value 636.93s - 644.61s | is always within a range of 0 to 255. So if you introduce a unicode character is larger than 255 644.61s - 650.37s | it'd be truncated into this range. Note that unicode overflows aren't just specific to PHP. 652.93s - 659.65s | So generating a unicode overflow in JavaScript is quite simple using the from code point method. 660.29s - 667.49s | First you pass the number that will cause the overflow such as 0x100 which is 256 in decimal. 668.13s - 672.69s | Next you provide the second hex number to specify the actual character that you want 673.57s - 680.69s | like 0x40 which is the art symbol. The from code point method will generate a unicode character 680.77s - 686.29s | and when this character is transformed to fit within 255 a system that doesn't support higher 686.29s - 690.93s | unicode characters will produce the ASCII character specified by the second number. 693.39s - 698.99s | So I hunted for real world unicode overflows and I found a target that altered characters 698.99s - 705.31s | within the mailer's SMTP conversation. This application blocked the backslash within the 705.31s - 711.71s | quoted local part but I bypassed the validation using unicode overflows that enabled me to escape 711.71s - 718.43s | characters and break out of the quoted local part. Despite this when using an encoded art symbol 719.07s - 725.15s | the email wasn't sent suggesting there is a double validation going on once in the application and 725.15s - 731.87s | once before sending. So although I didn't manage to exploit this particular target the key takeaway 731.87s - 737.71s | is if you can you can use a unicode overflow to bypass validation and actually smuggle characters 737.79s - 747.25s | within the SMTP conversation. So unicode overflows were great but I needed more methods to generate 747.25s - 753.17s | block characters so I took a deep dive into the glorious RFC looking for gold and I found it. 754.29s - 760.29s | This next section is about encoded word. I discovered this when trying to find ways of 760.29s - 769.17s | encoding the art symbol


chunk_id: 156_chunk_11
chunk_text:
unicode overflows and I found a target that altered characters 698.99s - 705.31s | within the mailer's SMTP conversation. This application blocked the backslash within the 705.31s - 711.71s | quoted local part but I bypassed the validation using unicode overflows that enabled me to escape 711.71s - 718.43s | characters and break out of the quoted local part. Despite this when using an encoded art symbol 719.07s - 725.15s | the email wasn't sent suggesting there is a double validation going on once in the application and 725.15s - 731.87s | once before sending. So although I didn't manage to exploit this particular target the key takeaway 731.87s - 737.71s | is if you can you can use a unicode overflow to bypass validation and actually smuggle characters 737.79s - 747.25s | within the SMTP conversation. So unicode overflows were great but I needed more methods to generate 747.25s - 753.17s | block characters so I took a deep dive into the glorious RFC looking for gold and I found it. 754.29s - 760.29s | This next section is about encoded word. I discovered this when trying to find ways of 760.29s - 769.17s | encoding the art symbol without unicode overflows. Encoded word is specified in RFC 2047 769.17s - 778.85s | and it allows the inclusion of unicode characters using encoded data and here is how encoded word 778.85s - 785.33s | works. So first we've got the equals and question mark that indicate the start of encoded word. 786.93s - 792.53s | The following character the following is the character encoding in this case utf-8. 800.99s - 806.91s | Inside the so the question marks act as a separator between the charset and the encoded type 808.27s - 813.07s | then it's the type of encoding and then you've got your encoded data as hex 813.07s - 819.79s | so it's prefixed with equals so equal 41 is an uppercase a so that's where the data occurs 822.26s - 829.14s | and the question mark equals indicate the end of the encoded word and the actual email that 829.14s - 836.02s | gets sent is that so you all the meta characters are removed and that email is sent to there. 839.01s - 845.01s | To probe for encoded word you should make two requests with the two charsets. The reason for 845.01s - 851.01s |


chunk_id: 156_chunk_12
chunk_text:
without unicode overflows. Encoded word is specified in RFC 2047 769.17s - 778.85s | and it allows the inclusion of unicode characters using encoded data and here is how encoded word 778.85s - 785.33s | works. So first we've got the equals and question mark that indicate the start of encoded word. 786.93s - 792.53s | The following character the following is the character encoding in this case utf-8. 800.99s - 806.91s | Inside the so the question marks act as a separator between the charset and the encoded type 808.27s - 813.07s | then it's the type of encoding and then you've got your encoded data as hex 813.07s - 819.79s | so it's prefixed with equals so equal 41 is an uppercase a so that's where the data occurs 822.26s - 829.14s | and the question mark equals indicate the end of the encoded word and the actual email that 829.14s - 836.02s | gets sent is that so you all the meta characters are removed and that email is sent to there. 839.01s - 845.01s | To probe for encoded word you should make two requests with the two charsets. The reason for 845.01s - 851.01s | this is that many different email parsing libraries support different charsets. When 851.01s - 857.49s | probing you should use lowercase characters in in case the site rejects or transforms to lowercase 857.49s - 864.93s | so I was initially using x as a charset but to reduce the size of the the probe but however on 864.93s - 870.85s | some systems they will reject unknown charsets and it would fail so it's better to use these 870.85s - 877.49s | two probes and then follow up with a charset of x to see if it works. If successful in each case 878.45s - 884.29s | you'll send an email to the ones displayed. In a real probe you would use a collaborator payload 884.29s - 891.17s | or a similar tool. I've highlighted the encoded and decoded text in red so for example equals 891.17s - 901.81s | 61 is a lowercase a. So we've covered how encoded word works so let's dive into some real world case 901.81s - 910.13s | studies. The following case studies all use the Ruby mail library which has over 508 million 910.13s - 918.29s | downloads. At the time of testing


chunk_id: 156_chunk_13
chunk_text:
this is that many different email parsing libraries support different charsets. When 851.01s - 857.49s | probing you should use lowercase characters in in case the site rejects or transforms to lowercase 857.49s - 864.93s | so I was initially using x as a charset but to reduce the size of the the probe but however on 864.93s - 870.85s | some systems they will reject unknown charsets and it would fail so it's better to use these 870.85s - 877.49s | two probes and then follow up with a charset of x to see if it works. If successful in each case 878.45s - 884.29s | you'll send an email to the ones displayed. In a real probe you would use a collaborator payload 884.29s - 891.17s | or a similar tool. I've highlighted the encoded and decoded text in red so for example equals 891.17s - 901.81s | 61 is a lowercase a. So we've covered how encoded word works so let's dive into some real world case 901.81s - 910.13s | studies. The following case studies all use the Ruby mail library which has over 508 million 910.13s - 918.29s | downloads. At the time of testing the version was 2.8.1. This library is used by many popular 918.29s - 928.38s | applications including github, zendesk, gitlab and bugcrowd. So for my first case study I'm going to 928.38s - 933.58s | show you how I exploited gitlab enterprise. I love this vector because it's so elegant. 934.38s - 939.26s | So first I used a charset of x because this was not important on the enterprise product. 941.26s - 948.14s | Then I use an encoded at symbol so equals 40 is encoded at and then I used the underscore 948.14s - 954.70s | character. So interestingly encoded word supports equals 20 as a space but also underscore. What 954.70s - 961.98s | happens then is the email is split in half and the email is sent to that address. So gitlab thinks 961.98s - 971.50s | the address is example.com but it actually goes to psres.net. So what was the impact on gitlab 971.50s - 977.50s | enterprise? Well I could verify email addresses that I didn't control. This means I could gain 977.58s - 988.53s | access to gitlab enterprise servers that use domain-based registration restrictions. To understand 988.53s - 994.85s | the next


chunk_id: 156_chunk_14
chunk_text:
the version was 2.8.1. This library is used by many popular 918.29s - 928.38s | applications including github, zendesk, gitlab and bugcrowd. So for my first case study I'm going to 928.38s - 933.58s | show you how I exploited gitlab enterprise. I love this vector because it's so elegant. 934.38s - 939.26s | So first I used a charset of x because this was not important on the enterprise product. 941.26s - 948.14s | Then I use an encoded at symbol so equals 40 is encoded at and then I used the underscore 948.14s - 954.70s | character. So interestingly encoded word supports equals 20 as a space but also underscore. What 954.70s - 961.98s | happens then is the email is split in half and the email is sent to that address. So gitlab thinks 961.98s - 971.50s | the address is example.com but it actually goes to psres.net. So what was the impact on gitlab 971.50s - 977.50s | enterprise? Well I could verify email addresses that I didn't control. This means I could gain 977.58s - 988.53s | access to gitlab enterprise servers that use domain-based registration restrictions. To understand 988.53s - 994.85s | the next set of slides let's have a quick recap on the how the email gets sent at the smtp level. 995.49s - 1000.53s | So there's a conversation between the mailer and the smtp client and that and there's a handshake 1000.53s - 1005.25s | that occurs but that's not important for this part of the talk. The important part is the receipt2 1005.25s - 1011.25s | command. You'll notice it's enclosed with angle brackets. We're going to abuse this in the next 1011.25s - 1022.27s | few slides to change the email destination. Gitlab is also an idp and I exploited the email 1022.83s - 1029.07s | verification. So I used x for the slide because it wouldn't all fit on. No one needs to be able 1029.07s - 1036.35s | to see it but you'd have to use this charset specified in red here. Then I used an encoded 1036.51s - 1042.75s | symbol again but this time I used the greater than symbol. So this is an encoded greater than symbol 1043.47s - 1051.71s | and then an encoded space and then gitlab thinks the domain is example.com but it actually goes 1051.71s - 1057.31s | to psres.net.


chunk_id: 156_chunk_15
chunk_text:
set of slides let's have a quick recap on the how the email gets sent at the smtp level. 995.49s - 1000.53s | So there's a conversation between the mailer and the smtp client and that and there's a handshake 1000.53s - 1005.25s | that occurs but that's not important for this part of the talk. The important part is the receipt2 1005.25s - 1011.25s | command. You'll notice it's enclosed with angle brackets. We're going to abuse this in the next 1011.25s - 1022.27s | few slides to change the email destination. Gitlab is also an idp and I exploited the email 1022.83s - 1029.07s | verification. So I used x for the slide because it wouldn't all fit on. No one needs to be able 1029.07s - 1036.35s | to see it but you'd have to use this charset specified in red here. Then I used an encoded 1036.51s - 1042.75s | symbol again but this time I used the greater than symbol. So this is an encoded greater than symbol 1043.47s - 1051.71s | and then an encoded space and then gitlab thinks the domain is example.com but it actually goes 1051.71s - 1057.31s | to psres.net. So you can spoof any domain you like and verify any domain you like on gitlab. 1060.06s - 1066.86s | So yeah using this bug you could bypass domain-based access controls that websites 1067.18s - 1073.42s | that support gitlab as an idp. This screenshot shows that I've got a Microsoft verified email 1073.42s - 1078.46s | address and gitlab email address. It's a bit small but you can see it's verified. 1080.75s - 1088.27s | So this one is more complex and this works on zendesk and uses the quoted local part with 1088.27s - 1099.36s | encoded quotes. First we start the quoted local part then we use a q encoded double quote. 1099.36s - 1105.36s | So equals 22 is a double quote followed by an encoded at symbol this time. 1107.60s - 1115.28s | Next we have to use the greater than and a null character for zendesk. So this has the same effect 1115.28s - 1123.86s | on space the null character prevents the rest of the address from being used. Due to the quirks of 1123.86s - 1130.58s | the mailer and the validation that zendesk use I had to use an encoded less


chunk_id: 156_chunk_16
chunk_text:
So you can spoof any domain you like and verify any domain you like on gitlab. 1060.06s - 1066.86s | So yeah using this bug you could bypass domain-based access controls that websites 1067.18s - 1073.42s | that support gitlab as an idp. This screenshot shows that I've got a Microsoft verified email 1073.42s - 1078.46s | address and gitlab email address. It's a bit small but you can see it's verified. 1080.75s - 1088.27s | So this one is more complex and this works on zendesk and uses the quoted local part with 1088.27s - 1099.36s | encoded quotes. First we start the quoted local part then we use a q encoded double quote. 1099.36s - 1105.36s | So equals 22 is a double quote followed by an encoded at symbol this time. 1107.60s - 1115.28s | Next we have to use the greater than and a null character for zendesk. So this has the same effect 1115.28s - 1123.86s | on space the null character prevents the rest of the address from being used. Due to the quirks of 1123.86s - 1130.58s | the mailer and the validation that zendesk use I had to use an encoded less than character and 1130.66s - 1137.38s | a double quote and my theory for this is that zendesk were doing email parsing multiple times 1137.38s - 1142.42s | so adding all this would then decode and then start to remove parts of the email address 1143.54s - 1148.50s | and then we finish the quoted local part and the actual email that gets sent is there. 1148.50s - 1157.94s | Absolutely crazy um yeah pretty nuts. So the impact of this attack was attackers could verify 1157.94s - 1163.14s | email domains from domain email addresses from domains they don't control which means they could 1163.14s - 1172.43s | access zendesk email domain protected support centers. GitHub were also vulnerable to the 1172.43s - 1180.03s | greater than a null attack so first I created an encoded at symbol then I used an encoded 1180.03s - 1187.95s | greater than symbol to end the receipt to command and github required a null character so adding 1187.95s - 1193.23s | this null character would then ignore the rest of the address and that would go to that email again. 1197.02s - 1203.02s | So using this technique I was able to


chunk_id: 156_chunk_17
chunk_text:
than character and 1130.66s - 1137.38s | a double quote and my theory for this is that zendesk were doing email parsing multiple times 1137.38s - 1142.42s | so adding all this would then decode and then start to remove parts of the email address 1143.54s - 1148.50s | and then we finish the quoted local part and the actual email that gets sent is there. 1148.50s - 1157.94s | Absolutely crazy um yeah pretty nuts. So the impact of this attack was attackers could verify 1157.94s - 1163.14s | email domains from domain email addresses from domains they don't control which means they could 1163.14s - 1172.43s | access zendesk email domain protected support centers. GitHub were also vulnerable to the 1172.43s - 1180.03s | greater than a null attack so first I created an encoded at symbol then I used an encoded 1180.03s - 1187.95s | greater than symbol to end the receipt to command and github required a null character so adding 1187.95s - 1193.23s | this null character would then ignore the rest of the address and that would go to that email again. 1197.02s - 1203.02s | So using this technique I was able to verify domains I didn't control on github and I had 1203.02s - 1213.97s | verified emails from mozilla.com github.com and microsoft.com. By spoofing domains on github I 1213.97s - 1218.85s | could verify domains I don't control this means I could bypass domain-based access controls 1218.85s - 1225.57s | on websites that used github as an identity provider. For example I could penetrate internal 1225.57s - 1233.09s | networks protected by cloudflow zero trust if it was configured to use github as an idp and email 1233.09s - 1240.53s | domain validation. So the following screenshot shows zero trust trusting domains from github.com 1240.53s - 1246.53s | since any domain can be spoofed and verified this vulnerability affected cloudflow zero trust 1246.53s - 1256.19s | instance using email domain validation. So as I was testing multiple ruby libraries I could I 1256.19s - 1262.59s | discovered that you could use base64 encoded email addresses that's why not right we all need this 1262.59s - 1271.39s | don't we need base64 encoded addresses in this example you can it uses the b as the encoding 1271.39s - 1281.55s | type so that indicates base64 and this is a base64 foobar so


chunk_id: 156_chunk_18
chunk_text:
verify domains I didn't control on github and I had 1203.02s - 1213.97s | verified emails from mozilla.com github.com and microsoft.com. By spoofing domains on github I 1213.97s - 1218.85s | could verify domains I don't control this means I could bypass domain-based access controls 1218.85s - 1225.57s | on websites that used github as an identity provider. For example I could penetrate internal 1225.57s - 1233.09s | networks protected by cloudflow zero trust if it was configured to use github as an idp and email 1233.09s - 1240.53s | domain validation. So the following screenshot shows zero trust trusting domains from github.com 1240.53s - 1246.53s | since any domain can be spoofed and verified this vulnerability affected cloudflow zero trust 1246.53s - 1256.19s | instance using email domain validation. So as I was testing multiple ruby libraries I could I 1256.19s - 1262.59s | discovered that you could use base64 encoded email addresses that's why not right we all need this 1262.59s - 1271.39s | don't we need base64 encoded addresses in this example you can it uses the b as the encoding 1271.39s - 1281.55s | type so that indicates base64 and this is a base64 foobar so I'm using foobar as an example but any 1281.55s - 1289.63s | character can be encoded and that results into an email of foobar at psres.net don't worry it gets 1289.63s - 1299.23s | worse it gets more disgusting. So who remembers this a script tag encoded in utf-7 this xss vector 1299.23s - 1309.23s | used to work on ie anybody remember it yeah surely no let's see surely email parsing libraries 1309.23s - 1317.23s | won't allow me to use a utf-7 charset of course they do using the ruby library mail here is a 1317.23s - 1326.11s | utf-7 encoded address so this is a an utf-7 foobar you'll notice the ampersand that's intentional 1326.11s - 1334.03s | because that's the character that they support for utf-7 so the the charset will be decoded and 1334.03s - 1342.11s | the email will be sent to foobar at psres.net I know what you're thinking or maybe it's just me 1342.11s - 1352.11s | but yes you can use utf-7 and base64 in an email address in this example there's a base64 1352.11s - 1359.55s | email address with a utf-7 charset first the email parser will decode base64


chunk_id: 156_chunk_19
chunk_text:
I'm using foobar as an example but any 1281.55s - 1289.63s | character can be encoded and that results into an email of foobar at psres.net don't worry it gets 1289.63s - 1299.23s | worse it gets more disgusting. So who remembers this a script tag encoded in utf-7 this xss vector 1299.23s - 1309.23s | used to work on ie anybody remember it yeah surely no let's see surely email parsing libraries 1309.23s - 1317.23s | won't allow me to use a utf-7 charset of course they do using the ruby library mail here is a 1317.23s - 1326.11s | utf-7 encoded address so this is a an utf-7 foobar you'll notice the ampersand that's intentional 1326.11s - 1334.03s | because that's the character that they support for utf-7 so the the charset will be decoded and 1334.03s - 1342.11s | the email will be sent to foobar at psres.net I know what you're thinking or maybe it's just me 1342.11s - 1352.11s | but yes you can use utf-7 and base64 in an email address in this example there's a base64 1352.11s - 1359.55s | email address with a utf-7 charset first the email parser will decode base64 1360.67s - 1367.15s | then the email parser will decode the utf-7 charset finally the decoded address will be 1367.15s - 1373.95s | sent there absolutely crazy and I'll emphasize the point that any character can be encoded I'm 1373.95s - 1382.94s | just using foobar to make it simple to follow then I thought what about utf-7 and queue encoding 1382.94s - 1389.90s | so here I'm going to modify the a character and replace it with equals 41 this will then get 1389.90s - 1397.82s | decoded and then the and then it will be decoded and form a utf-7 encoded foobar so it's going 1397.82s - 1403.42s | through two layers of encoding at this point you might start having a few doubts about following 1403.42s - 1409.98s | the rfc especially when I tell you that this works in the domain part 2 and when I tested the 1410.86s - 1420.86s | ruby mail library I know what you're thinking it's sorry I've lost track I know what you're 1420.86s - 1426.46s | thinking no website is going to support utf-7 right no website is going to support that 1427.18s - 1434.94s | but actually there


chunk_id: 156_chunk_20
chunk_text:
1360.67s - 1367.15s | then the email parser will decode the utf-7 charset finally the decoded address will be 1367.15s - 1373.95s | sent there absolutely crazy and I'll emphasize the point that any character can be encoded I'm 1373.95s - 1382.94s | just using foobar to make it simple to follow then I thought what about utf-7 and queue encoding 1382.94s - 1389.90s | so here I'm going to modify the a character and replace it with equals 41 this will then get 1389.90s - 1397.82s | decoded and then the and then it will be decoded and form a utf-7 encoded foobar so it's going 1397.82s - 1403.42s | through two layers of encoding at this point you might start having a few doubts about following 1403.42s - 1409.98s | the rfc especially when I tell you that this works in the domain part 2 and when I tested the 1410.86s - 1420.86s | ruby mail library I know what you're thinking it's sorry I've lost track I know what you're 1420.86s - 1426.46s | thinking no website is going to support utf-7 right no website is going to support that 1427.18s - 1434.94s | but actually there was a small source code web hosting site called github they supported utf-7 1435.42s - 1440.62s | I'm so gutted that I didn't exploit them with utf-7 because they'd already fixed it by the 1440.62s - 1447.41s | time I found this and then yeah it'll go to that email address so foobar psres done it 1450.37s - 1457.01s | so then I went hunting for encoded word outside of ruby and I found that php mailer supports 1457.01s - 1463.17s | encoded word within the name of the recipient I tried exploiting this in wordpress and other 1463.17s - 1468.61s | applications but the requirements of needing angle brackets around the email made exploitation 1468.61s - 1474.29s | difficult still I bet there are vulnerable systems that decode the actual name of the 1474.29s - 1485.17s | recipient so you may find this in bug bounty sites so we've explored how you can manipulate 1485.17s - 1491.33s | email parsing to sidestep access controls but shall we take it a bit further what if we could 1491.33s - 1497.97s | use an email address and weaponize it to gain remote code execution in this section we'll cover 1497.97s -


chunk_id: 156_chunk_21
chunk_text:
was a small source code web hosting site called github they supported utf-7 1435.42s - 1440.62s | I'm so gutted that I didn't exploit them with utf-7 because they'd already fixed it by the 1440.62s - 1447.41s | time I found this and then yeah it'll go to that email address so foobar psres done it 1450.37s - 1457.01s | so then I went hunting for encoded word outside of ruby and I found that php mailer supports 1457.01s - 1463.17s | encoded word within the name of the recipient I tried exploiting this in wordpress and other 1463.17s - 1468.61s | applications but the requirements of needing angle brackets around the email made exploitation 1468.61s - 1474.29s | difficult still I bet there are vulnerable systems that decode the actual name of the 1474.29s - 1485.17s | recipient so you may find this in bug bounty sites so we've explored how you can manipulate 1485.17s - 1491.33s | email parsing to sidestep access controls but shall we take it a bit further what if we could 1491.33s - 1497.97s | use an email address and weaponize it to gain remote code execution in this section we'll cover 1497.97s - 1506.69s | punicode attacks and how I exploited joomla punicode is a way to represent unicode characters 1506.69s - 1513.01s | in the current dns system punicode always starts with xn and is followed by two hyphens 1513.57s - 1519.41s | the algorithm converts the sequence of unicode characters into a representation that utilizes 1519.41s - 1525.01s | only alphanumeric characters and hyphens for example the domain ruchun I hope I pronounced 1525.01s - 1531.41s | that right is encoded with the following punicode sequence as you can see there due to the very 1531.41s - 1537.81s | nature of how punicode works it makes it difficult to test because changing one character can affect 1537.81s - 1543.57s | the entire output and the character position due to how the algorithm works so what we want to do 1543.57s - 1551.01s | is generate some malicious characters that when it's decoded uh sorry what we want to do is 1551.01s - 1557.81s | generate malicious characters when it's decoded but doing so is a big challenge in these examples 1557.81s - 1563.09s | you can see the unicode character changes when one byte is modified this makes it difficult to


chunk_id: 156_chunk_22
chunk_text:
1506.69s | punicode attacks and how I exploited joomla punicode is a way to represent unicode characters 1506.69s - 1513.01s | in the current dns system punicode always starts with xn and is followed by two hyphens 1513.57s - 1519.41s | the algorithm converts the sequence of unicode characters into a representation that utilizes 1519.41s - 1525.01s | only alphanumeric characters and hyphens for example the domain ruchun I hope I pronounced 1525.01s - 1531.41s | that right is encoded with the following punicode sequence as you can see there due to the very 1531.41s - 1537.81s | nature of how punicode works it makes it difficult to test because changing one character can affect 1537.81s - 1543.57s | the entire output and the character position due to how the algorithm works so what we want to do 1543.57s - 1551.01s | is generate some malicious characters that when it's decoded uh sorry what we want to do is 1551.01s - 1557.81s | generate malicious characters when it's decoded but doing so is a big challenge in these examples 1557.81s - 1563.09s | you can see the unicode character changes when one byte is modified this makes it difficult to 1563.09s - 1570.61s | generate a malicious payload so after reading about punicode in uh on wikipedia I followed 1570.61s - 1578.45s | a link to an online punicode converter and I began to experiment the converter used the idn php library 1578.45s - 1584.29s | I first started to add zeros to the beginning of the punicode address to convert it into ascii 1584.29s - 1589.97s | characters so I initially succeeded generating comma a comma which was so surprising I doubted 1589.97s - 1595.33s | my eyes encouraged by this I started to experiment further and managed to produce an art symbol 1598.03s - 1602.59s | so after searching github I found an interesting target using the library 1602.59s - 1609.63s | joomla this was great because if I got xss then I would have rce doing a source code analysis 1609.63s - 1615.07s | I noticed they were escaping the email before it was punicode decoded this means if I could 1615.07s - 1621.87s | produce some malformed punicode that when decoded produces html I could get xss but it wouldn't be 1621.87s - 1629.63s | that easy sounds simple just give the decoder some malformed punicode


chunk_id: 156_chunk_23
chunk_text:
1563.09s - 1570.61s | generate a malicious payload so after reading about punicode in uh on wikipedia I followed 1570.61s - 1578.45s | a link to an online punicode converter and I began to experiment the converter used the idn php library 1578.45s - 1584.29s | I first started to add zeros to the beginning of the punicode address to convert it into ascii 1584.29s - 1589.97s | characters so I initially succeeded generating comma a comma which was so surprising I doubted 1589.97s - 1595.33s | my eyes encouraged by this I started to experiment further and managed to produce an art symbol 1598.03s - 1602.59s | so after searching github I found an interesting target using the library 1602.59s - 1609.63s | joomla this was great because if I got xss then I would have rce doing a source code analysis 1609.63s - 1615.07s | I noticed they were escaping the email before it was punicode decoded this means if I could 1615.07s - 1621.87s | produce some malformed punicode that when decoded produces html I could get xss but it wouldn't be 1621.87s - 1629.63s | that easy sounds simple just give the decoder some malformed punicode and generate some html 1629.63s - 1634.83s | but remember how the algorithm works any change in the character can result in a completely 1634.83s - 1640.83s | different output I thought about this for a while and I thought that this was a good job for a fuzzer 1641.87s - 1648.59s | so I wrote a fuzzer to generate malformed punicode and the results were interesting I found many ways 1648.59s - 1653.07s | to generate different characters so you can see what I was trying to do here I'm trying to generate 1653.07s - 1661.10s | an svg type so I started generating millions of different character combinations I managed to 1661.10s - 1667.18s | construct partial xss vectors but I encountered several issues I could only generate two ascii 1667.18s - 1673.10s | characters by using more than one punicode subdomain this limitation arose from the specific 1673.10s - 1681.26s | workings of the punicode of the punicode algorithm php and the quirks of this buggy php idn library 1681.26s - 1686.54s | as you can see in the examples I was really close but these problems made exploiting joomla 1686.54s - 1693.90s | very difficult I


chunk_id: 156_chunk_24
chunk_text:
and generate some html 1629.63s - 1634.83s | but remember how the algorithm works any change in the character can result in a completely 1634.83s - 1640.83s | different output I thought about this for a while and I thought that this was a good job for a fuzzer 1641.87s - 1648.59s | so I wrote a fuzzer to generate malformed punicode and the results were interesting I found many ways 1648.59s - 1653.07s | to generate different characters so you can see what I was trying to do here I'm trying to generate 1653.07s - 1661.10s | an svg type so I started generating millions of different character combinations I managed to 1661.10s - 1667.18s | construct partial xss vectors but I encountered several issues I could only generate two ascii 1667.18s - 1673.10s | characters by using more than one punicode subdomain this limitation arose from the specific 1673.10s - 1681.26s | workings of the punicode of the punicode algorithm php and the quirks of this buggy php idn library 1681.26s - 1686.54s | as you can see in the examples I was really close but these problems made exploiting joomla 1686.54s - 1693.90s | very difficult I concluded that xss was not feasible so because although I was able to 1693.90s - 1699.66s | generate a single quoted attribute it required an underscore character and joomla however 1699.66s - 1704.06s | does not permit underscore does not permit underscore characters in the domain part of 1704.06s - 1710.62s | the email address so you can see those mad punicode addresses are trying to inject some html 1711.58s - 1717.98s | so what's that the end of the story not quite I thought about this for a while and I worked out 1717.98s - 1724.14s | that you could use a single punicode subdomain and you could generate any opening tag eventually 1724.14s - 1729.74s | after a lot of testing I concluded the only exploitable vector was an opening style tag 1730.30s - 1736.14s | here I use malformed punicode to construct it it looks like a test string right but this is 1736.70s - 1743.10s | this is actually how it works style 1 2 3 and 3 2 1 sorry and that would generate style tag 1745.33s - 1751.49s | the rest of the pre-existing joomla html code would add the space and the closing


chunk_id: 156_chunk_25
chunk_text:
concluded that xss was not feasible so because although I was able to 1693.90s - 1699.66s | generate a single quoted attribute it required an underscore character and joomla however 1699.66s - 1704.06s | does not permit underscore does not permit underscore characters in the domain part of 1704.06s - 1710.62s | the email address so you can see those mad punicode addresses are trying to inject some html 1711.58s - 1717.98s | so what's that the end of the story not quite I thought about this for a while and I worked out 1717.98s - 1724.14s | that you could use a single punicode subdomain and you could generate any opening tag eventually 1724.14s - 1729.74s | after a lot of testing I concluded the only exploitable vector was an opening style tag 1730.30s - 1736.14s | here I use malformed punicode to construct it it looks like a test string right but this is 1736.70s - 1743.10s | this is actually how it works style 1 2 3 and 3 2 1 sorry and that would generate style tag 1745.33s - 1751.49s | the rest of the pre-existing joomla html code would add the space and the closing angle bracket 1751.49s - 1757.81s | for me so it injects this style tag and then the rest of the html adds those characters for me 1760.02s - 1765.30s | so what I'd need is two accounts the first registered registers with a style tag with 1765.30s - 1772.26s | malformed punicode as demonstrated the second account has the actual css payload inside the 1772.26s - 1779.38s | name of the user that imports the malicious style sheet the first account starts with a 1779.38s - 1785.62s | and the second account starts with x this is to ensure the style injection occurs first 1785.62s - 1792.74s | and then the payload with the import occurs second notice I'm using curly braces this is 1792.74s - 1798.58s | to trade to treat all the html that occurs before the import as an invalid css selector 1798.58s - 1808.24s | and this still works because this is css right it'll just work so the first step is to register 1808.24s - 1814.88s | two accounts for the attacker the first with the malicious punicode and the second with the evil 1814.88s - 1821.92s | css so here we're using the malformed


chunk_id: 156_chunk_26
chunk_text:
angle bracket 1751.49s - 1757.81s | for me so it injects this style tag and then the rest of the html adds those characters for me 1760.02s - 1765.30s | so what I'd need is two accounts the first registered registers with a style tag with 1765.30s - 1772.26s | malformed punicode as demonstrated the second account has the actual css payload inside the 1772.26s - 1779.38s | name of the user that imports the malicious style sheet the first account starts with a 1779.38s - 1785.62s | and the second account starts with x this is to ensure the style injection occurs first 1785.62s - 1792.74s | and then the payload with the import occurs second notice I'm using curly braces this is 1792.74s - 1798.58s | to trade to treat all the html that occurs before the import as an invalid css selector 1798.58s - 1808.24s | and this still works because this is css right it'll just work so the first step is to register 1808.24s - 1814.88s | two accounts for the attacker the first with the malicious punicode and the second with the evil 1814.88s - 1821.92s | css so here we're using the malformed punicode in the email and the second account in the name 1825.66s - 1832.86s | the attacker then uses import chaining and a custom node server a custom css exfiltrator 1832.86s - 1839.34s | to quickly exfiltrate the c-surf token from the admin and when the admin visits the user's page 1839.34s - 1844.30s | this css will get executed and the c-surf token is leaked to the attacker 1846.06s - 1854.93s | the screenshot shows this process happening using the exfiltrated token the attacker then 1854.93s - 1862.05s | uses the css exfiltrator and gives the admin a url the admin visits that site and the c-surf 1862.05s - 1868.05s | attack is then performed on the admin using the exfiltrated token and then the admin template 1868.05s - 1877.60s | is then modified and then you get rce now james said i should do a live demo i wasn't as keen 1877.60s - 1890.54s | but let's give it a shot right so on the left is the victim so it's the admin on the left 1891.18s - 1895.82s | on the right is the attacker we've also got the exfiltrator running 1896.78s - 1904.06s | and this


chunk_id: 156_chunk_27
chunk_text:
punicode in the email and the second account in the name 1825.66s - 1832.86s | the attacker then uses import chaining and a custom node server a custom css exfiltrator 1832.86s - 1839.34s | to quickly exfiltrate the c-surf token from the admin and when the admin visits the user's page 1839.34s - 1844.30s | this css will get executed and the c-surf token is leaked to the attacker 1846.06s - 1854.93s | the screenshot shows this process happening using the exfiltrated token the attacker then 1854.93s - 1862.05s | uses the css exfiltrator and gives the admin a url the admin visits that site and the c-surf 1862.05s - 1868.05s | attack is then performed on the admin using the exfiltrated token and then the admin template 1868.05s - 1877.60s | is then modified and then you get rce now james said i should do a live demo i wasn't as keen 1877.60s - 1890.54s | but let's give it a shot right so on the left is the victim so it's the admin on the left 1891.18s - 1895.82s | on the right is the attacker we've also got the exfiltrator running 1896.78s - 1904.06s | and this is where the token will be extracted so the attacker visits the page i've pre-filled 1904.06s - 1910.22s | the data because you don't want to see me typing everything and the email address contains a 1910.22s - 1915.98s | malformed punicode so i get an error and that error is just because i haven't configured 1915.98s - 1924.14s | mail on the server and then you register a second account and this is with the actual payload in 1924.14s - 1935.60s | that exfiltrates the token so the two accounts are registered now let's log in as the admin 1935.60s - 1951.79s | and pray to the demo gods right thank you very much but we still need to send the message to 1951.79s - 1957.47s | the admin right hey admin how's your day going yeah going good living the dream let's click on 1957.47s - 1966.32s | this so i'm showing you a real attack he wouldn't show the payload in there but we've backdoored 1966.32s - 1976.99s | joomla and then the attacker goes to pond and we've got rce we're casting etc password thank you 1976.99s - 1994.46s | thank you so whilst conducting this


chunk_id: 156_chunk_28
chunk_text:
is where the token will be extracted so the attacker visits the page i've pre-filled 1904.06s - 1910.22s | the data because you don't want to see me typing everything and the email address contains a 1910.22s - 1915.98s | malformed punicode so i get an error and that error is just because i haven't configured 1915.98s - 1924.14s | mail on the server and then you register a second account and this is with the actual payload in 1924.14s - 1935.60s | that exfiltrates the token so the two accounts are registered now let's log in as the admin 1935.60s - 1951.79s | and pray to the demo gods right thank you very much but we still need to send the message to 1951.79s - 1957.47s | the admin right hey admin how's your day going yeah going good living the dream let's click on 1957.47s - 1966.32s | this so i'm showing you a real attack he wouldn't show the payload in there but we've backdoored 1966.32s - 1976.99s | joomla and then the attacker goes to pond and we've got rce we're casting etc password thank you 1976.99s - 1994.46s | thank you so whilst conducting this research i found it useful to follow the following methodology 1994.46s - 2002.06s | probe observe encode exploit first probe for encoded word observe that it will be decoded 2002.06s - 2007.34s | to confirm that it's supported then encode the various characters and observe how they're 2007.34s - 2012.94s | decoded and then follow with an exploit that abuses these characters so this methodology 2012.94s - 2018.22s | this methodology is spelt out here so these are the steps you can take to exploit and this is the 2018.22s - 2026.26s | some of the steps i use to exploit these targets hackverter is a free open source tool that i wrote 2026.26s - 2032.98s | for burp suite i've crafted some hackverter tags to help you generate unicode overflows 2032.98s - 2040.02s | and encoded word attacks easily within burp turbo intruder is another free burp extension 2040.02s - 2045.30s | written by james kettle i've created a turbo intruder script to exploit the mailers so you 2045.30s - 2051.38s | remember when github supported null for example this was found with turbo intruder i've also 2051.38s - 2058.26s | created a punicode fuzzer to help with malformed


chunk_id: 156_chunk_29
chunk_text:
research i found it useful to follow the following methodology 1994.46s - 2002.06s | probe observe encode exploit first probe for encoded word observe that it will be decoded 2002.06s - 2007.34s | to confirm that it's supported then encode the various characters and observe how they're 2007.34s - 2012.94s | decoded and then follow with an exploit that abuses these characters so this methodology 2012.94s - 2018.22s | this methodology is spelt out here so these are the steps you can take to exploit and this is the 2018.22s - 2026.26s | some of the steps i use to exploit these targets hackverter is a free open source tool that i wrote 2026.26s - 2032.98s | for burp suite i've crafted some hackverter tags to help you generate unicode overflows 2032.98s - 2040.02s | and encoded word attacks easily within burp turbo intruder is another free burp extension 2040.02s - 2045.30s | written by james kettle i've created a turbo intruder script to exploit the mailers so you 2045.30s - 2051.38s | remember when github supported null for example this was found with turbo intruder i've also 2051.38s - 2058.26s | created a punicode fuzzer to help with malformed punicode the fuzzer works by giving some inputs 2058.74s - 2064.02s | some punicode address and then the placeholders are substituted with random numbers characters or 2064.02s - 2070.02s | white space it was really effective in finding what characters could be generated we've also 2070.02s - 2079.18s | updated burp intruder word list with a list of these attacks too for your convenience to defend 2079.18s - 2086.22s | against email splitting attacks make sure you filter out or disable encoded word always verify 2086.30s - 2092.54s | email addresses before using them even when received from an sso provider after validating 2092.54s - 2098.62s | the email address do not use the domain as a sole means of authorization because it can lead to bad 2098.62s - 2106.67s | stuff a few blog posts were really inspirational when conducting this research i recommend you 2106.67s - 2112.11s | read each one because they are really useful and contain really useful information the import 2112.11s - 2117.23s | training technique to use to exfiltrate the token is from pet villa and donut awesome researchers 2120.19s - 2126.91s | so the three takeaways that i want to leave you with


chunk_id: 156_chunk_30
chunk_text:
punicode the fuzzer works by giving some inputs 2058.74s - 2064.02s | some punicode address and then the placeholders are substituted with random numbers characters or 2064.02s - 2070.02s | white space it was really effective in finding what characters could be generated we've also 2070.02s - 2079.18s | updated burp intruder word list with a list of these attacks too for your convenience to defend 2079.18s - 2086.22s | against email splitting attacks make sure you filter out or disable encoded word always verify 2086.30s - 2092.54s | email addresses before using them even when received from an sso provider after validating 2092.54s - 2098.62s | the email address do not use the domain as a sole means of authorization because it can lead to bad 2098.62s - 2106.67s | stuff a few blog posts were really inspirational when conducting this research i recommend you 2106.67s - 2112.11s | read each one because they are really useful and contain really useful information the import 2112.11s - 2117.23s | training technique to use to exfiltrate the token is from pet villa and donut awesome researchers 2120.19s - 2126.91s | so the three takeaways that i want to leave you with are valid email addresses that can trigger 2126.91s - 2134.43s | major parser discrepancies even email addresses that end in at example.com might go elsewhere 2134.43s - 2140.11s | and as a result is never safe to use email domains for access control enforcement 2140.59s - 2147.31s | we've created a web security academy ctf so you can try and do an email splitting attack 2147.87s - 2152.67s | i've also created a docker file with the vulnerable joomla uh installation for your 2153.47s - 2160.03s | convenience you can get all the materials and download the um all the materials for 2160.03s - 2164.59s | this presentation are on the github repository thank you very much defcon 2164.59s - 2174.83s | thank you any questions


chunk_id: 156_chunk_31
chunk_text:
are valid email addresses that can trigger 2126.91s - 2134.43s | major parser discrepancies even email addresses that end in at example.com might go elsewhere 2134.43s - 2140.11s | and as a result is never safe to use email domains for access control enforcement 2140.59s - 2147.31s | we've created a web security academy ctf so you can try and do an email splitting attack 2147.87s - 2152.67s | i've also created a docker file with the vulnerable joomla uh installation for your 2153.47s - 2160.03s | convenience you can get all the materials and download the um all the materials for 2160.03s - 2164.59s | this presentation are on the github repository thank you very much defcon 2164.59s - 2174.83s | thank you any questions


chunk_id: 157_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=Dh220NQIkaQ", "title": "DEF CON 32 - Redefining V2G: How to use your vehicle as game controller -Timm Lauser, Jannis Hamborg", "description": "Modern cars are a complex networks of computers put on four wheels. For security research, it is important to understand the car's internal network and exposed interfaces. But what else could you use this knowledge for? You probably guessed it from the title \ud83d\ude42. So we developed a tool to turn our research car into a game controller.\n\nIn this talk, we present Vehicle-to-Game (V2G), a Python-based project that enables the usage of cars as game controllers. V2G can run either directly on a laptop or turn a Raspberry Pi Zero WH into a Bluetooth gamepad. In addition, V2G can either be used over the OBD2-diagnostic port or by directly accessing the internal CAN-busses of the car.\n\nOur project can be a great starting point if you always wanted to tinker around with your car or want to learn about the CAN bus or diagnostic communication (UDS). To make V2G work with your car, some reverse engineering of CAN messages or diagnostic communication will be required (as well as additional hardware to connect to the CAN bus). Otherwise, if you can get this running, you can be sure that you own a more expensive game controller than your neighbors.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2339, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 1.20s - 3.20s | This text was transcribed using whisper model: large-v2 Hello DEF CON! 3.20s - 4.20s | Hi! 4.20s - 13.66s | I hope you enjoy your time here, we definitely do. 13.66s - 16.66s | It's actually our first time here at DEF CON 16.66s - 21.66s | and thus we are very proud and excited to present to you our talk 21.66s - 26.66s | Redefining V2G, how to use your vehicle as a game controller. 27.66s - 31.66s | So, why do we need to redefine the acronym V2G? 31.66s - 39.39s | Well, let me tell you a story. 39.39s - 45.39s | Once upon a time, our professor told us we should do some research about V2G. 45.39s - 50.39s | And what he means by that is that we look at vehicle-to-grid communication, 50.39s - 54.39s | the communication between the car and the charge point 54.39s - 61.39s | and also the backend and even the power grid for bi-directional


chunk_id: 157_chunk_1
chunk_text:
you can get this running, you can be sure that you own a more expensive game controller than your neighbors.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2339, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 1.20s - 3.20s | This text was transcribed using whisper model: large-v2 Hello DEF CON! 3.20s - 4.20s | Hi! 4.20s - 13.66s | I hope you enjoy your time here, we definitely do. 13.66s - 16.66s | It's actually our first time here at DEF CON 16.66s - 21.66s | and thus we are very proud and excited to present to you our talk 21.66s - 26.66s | Redefining V2G, how to use your vehicle as a game controller. 27.66s - 31.66s | So, why do we need to redefine the acronym V2G? 31.66s - 39.39s | Well, let me tell you a story. 39.39s - 45.39s | Once upon a time, our professor told us we should do some research about V2G. 45.39s - 50.39s | And what he means by that is that we look at vehicle-to-grid communication, 50.39s - 54.39s | the communication between the car and the charge point 54.39s - 61.39s | and also the backend and even the power grid for bi-directional charging, for example. 61.39s - 65.39s | Well, that's actually a pretty cool research topic. 65.39s - 69.67s | But do you know what's even cooler? 69.67s - 71.67s | Using your car as a game controller. 71.67s - 77.67s | So, that's why we developed this little project called Vehicle-to-Game. 77.67s - 82.67s | But before we get started with that, a short introduction of ourselves. 82.67s - 87.67s | My name is Tim, I'm a PhD student at Darmstadt University of Applied Sciences in Germany. 87.67s - 91.67s | And I mainly do automotive security. 91.67s - 94.67s | So, also a lot of theoretical stuff. 94.67s - 99.67s | I look at protocols and standards and do a formal analysis of these standards 99.67s - 104.67s | to see if they meet certain security goals. 104.67s - 107.67s | Yeah, hello from my side too. 107.67s - 112.67s | I'm Janis, I'm also a PhD student at our small automotive research group 112.67s - 118.67s | called ACSD, Automotive Cyber Security Darmstadt. 118.67s - 120.67s | It's located in Germany. 120.67s - 124.67s | I finished my master's at the end of the last year 124.67s -


chunk_id: 157_chunk_2
chunk_text:
charging, for example. 61.39s - 65.39s | Well, that's actually a pretty cool research topic. 65.39s - 69.67s | But do you know what's even cooler? 69.67s - 71.67s | Using your car as a game controller. 71.67s - 77.67s | So, that's why we developed this little project called Vehicle-to-Game. 77.67s - 82.67s | But before we get started with that, a short introduction of ourselves. 82.67s - 87.67s | My name is Tim, I'm a PhD student at Darmstadt University of Applied Sciences in Germany. 87.67s - 91.67s | And I mainly do automotive security. 91.67s - 94.67s | So, also a lot of theoretical stuff. 94.67s - 99.67s | I look at protocols and standards and do a formal analysis of these standards 99.67s - 104.67s | to see if they meet certain security goals. 104.67s - 107.67s | Yeah, hello from my side too. 107.67s - 112.67s | I'm Janis, I'm also a PhD student at our small automotive research group 112.67s - 118.67s | called ACSD, Automotive Cyber Security Darmstadt. 118.67s - 120.67s | It's located in Germany. 120.67s - 124.67s | I finished my master's at the end of the last year 124.67s - 129.67s | and now I'm a PhD student about resilience in the automotive topic, 129.67s - 132.67s | but also for IoT systems. 132.67s - 138.67s | Means what happens if an ECU in a car breaks or is going to be compromised, 138.67s - 141.67s | how you can migrate functionality to another ECU 141.67s - 148.67s | and strengthen the safety inside the car by such a resilience concept. 148.67s - 152.67s | Our research group is also very focused on teaching. 152.67s - 155.67s | We have a lecture called Automotive Security 155.67s - 159.67s | and therefore we have to motivate students, of course, 159.67s - 165.67s | and that's why we have created this motivating and beginner-friendly talk 165.67s - 171.67s | and our project V2G to get students excited and motivated 171.67s - 175.67s | about the topic of automotive research. 175.67s - 179.67s | Maybe the most important member of our research group is our research car. 179.67s - 181.67s | It's a Volkswagen ID.3. 181.67s - 183.67s | It's an electric vehicle. 183.67s - 185.67s | And since, of course, we are Germans, 185.67s - 193.52s | so we have to do


chunk_id: 157_chunk_3
chunk_text:
129.67s | and now I'm a PhD student about resilience in the automotive topic, 129.67s - 132.67s | but also for IoT systems. 132.67s - 138.67s | Means what happens if an ECU in a car breaks or is going to be compromised, 138.67s - 141.67s | how you can migrate functionality to another ECU 141.67s - 148.67s | and strengthen the safety inside the car by such a resilience concept. 148.67s - 152.67s | Our research group is also very focused on teaching. 152.67s - 155.67s | We have a lecture called Automotive Security 155.67s - 159.67s | and therefore we have to motivate students, of course, 159.67s - 165.67s | and that's why we have created this motivating and beginner-friendly talk 165.67s - 171.67s | and our project V2G to get students excited and motivated 171.67s - 175.67s | about the topic of automotive research. 175.67s - 179.67s | Maybe the most important member of our research group is our research car. 179.67s - 181.67s | It's a Volkswagen ID.3. 181.67s - 183.67s | It's an electric vehicle. 183.67s - 185.67s | And since, of course, we are Germans, 185.67s - 193.52s | so we have to do research on the Volkswagen, I think. 193.52s - 197.52s | Usually the initial step of the automotive research, 197.52s - 202.52s | but also other security research, is considering attack vectors. 202.52s - 206.52s | And that's what we have to do also for the automotive context. 206.52s - 209.52s | You can see there are various attacks. 209.52s - 211.52s | It's a huge attack surface. 211.52s - 214.52s | First of all, you have long-range attacks, you have short-range attacks, 214.52s - 218.52s | but you have also physical attack possibilities. 218.52s - 220.52s | For the long-range attacks, for example, 220.52s - 226.52s | the cellular communication between the car and the back end of the OEM, 226.52s - 229.52s | for example, for over-the-air updates. 229.52s - 234.52s | In newly upcoming cars, you have also the V2X communication, 234.52s - 239.52s | cars communicating to each other about their location, about their speed. 239.52s - 242.52s | You have cars communicating with road signs 243.52s - 250.52s | to get a status about allowed speed, for example, of this street section. 250.52s - 252.52s | You have short-range attacks. 252.52s - 255.52s | That's more


chunk_id: 157_chunk_4
chunk_text:
research on the Volkswagen, I think. 193.52s - 197.52s | Usually the initial step of the automotive research, 197.52s - 202.52s | but also other security research, is considering attack vectors. 202.52s - 206.52s | And that's what we have to do also for the automotive context. 206.52s - 209.52s | You can see there are various attacks. 209.52s - 211.52s | It's a huge attack surface. 211.52s - 214.52s | First of all, you have long-range attacks, you have short-range attacks, 214.52s - 218.52s | but you have also physical attack possibilities. 218.52s - 220.52s | For the long-range attacks, for example, 220.52s - 226.52s | the cellular communication between the car and the back end of the OEM, 226.52s - 229.52s | for example, for over-the-air updates. 229.52s - 234.52s | In newly upcoming cars, you have also the V2X communication, 234.52s - 239.52s | cars communicating to each other about their location, about their speed. 239.52s - 242.52s | You have cars communicating with road signs 243.52s - 250.52s | to get a status about allowed speed, for example, of this street section. 250.52s - 252.52s | You have short-range attacks. 252.52s - 255.52s | That's more or less classical cyber security, 255.52s - 260.52s | considering Bluetooth, Wi-Fi connection for your infotainment system 260.52s - 264.52s | between the smartphone, for example, for playing via Apple CarPlay, 264.52s - 268.52s | for example, the music on your car. 268.52s - 272.52s | Maybe the most interesting and car-specific attack vectors 272.52s - 274.52s | are these physical attacks. 274.52s - 278.52s | That's the bus systems inside the car. 278.52s - 283.52s | There are several of them, but we want to focus on two, 283.52s - 286.52s | and we'll go into them a little bit later in detail, 286.52s - 289.52s | because we need them for our V2G project, 289.52s - 294.52s | getting all information required for our game controller out of this car. 294.52s - 301.66s | Here you can see our two main research cars. 301.66s - 303.66s | We are focused on electric vehicles. 303.66s - 306.66s | On the left side, you can see our Volkswagen ID.3. 306.66s - 310.66s | On the right side, you can see the Tesla Model 3. 310.66s - 313.66s | We use them for practical research. 313.66s - 316.66s | Tim also


chunk_id: 157_chunk_5
chunk_text:
or less classical cyber security, 255.52s - 260.52s | considering Bluetooth, Wi-Fi connection for your infotainment system 260.52s - 264.52s | between the smartphone, for example, for playing via Apple CarPlay, 264.52s - 268.52s | for example, the music on your car. 268.52s - 272.52s | Maybe the most interesting and car-specific attack vectors 272.52s - 274.52s | are these physical attacks. 274.52s - 278.52s | That's the bus systems inside the car. 278.52s - 283.52s | There are several of them, but we want to focus on two, 283.52s - 286.52s | and we'll go into them a little bit later in detail, 286.52s - 289.52s | because we need them for our V2G project, 289.52s - 294.52s | getting all information required for our game controller out of this car. 294.52s - 301.66s | Here you can see our two main research cars. 301.66s - 303.66s | We are focused on electric vehicles. 303.66s - 306.66s | On the left side, you can see our Volkswagen ID.3. 306.66s - 310.66s | On the right side, you can see the Tesla Model 3. 310.66s - 313.66s | We use them for practical research. 313.66s - 316.66s | Tim also introduced them as theoretical research. 316.66s - 318.66s | I'm also more theoretical part, 318.66s - 321.66s | but you cannot do the whole time theoretical research, 321.66s - 324.66s | so you have to do tinkering around with a car. 324.66s - 326.66s | It's also good for the motivation. 326.66s - 330.66s | There's a lot of information you just get when you look at the actual car, 330.66s - 332.66s | because the manufacturers won't tell you. 332.66s - 334.66s | Also, for students, it's quite cool 334.66s - 339.66s | to do research on the actual cars and projects. 340.66s - 343.66s | We have equipped our cars with lots of techniques 343.66s - 346.66s | to get information about them. 346.66s - 351.66s | We'll show you in the following how we have done this. 351.66s - 353.66s | That's the back of the Volkswagen ID.3. 353.66s - 356.66s | We've equipped this with lots of measurement techniques. 356.66s - 359.66s | On the right, you can see so-called vector boxes. 359.66s - 362.66s | They're from a German company called Vector. 362.66s - 364.66s | That's why we call them vector boxes. 364.66s -


chunk_id: 157_chunk_6
chunk_text:
introduced them as theoretical research. 316.66s - 318.66s | I'm also more theoretical part, 318.66s - 321.66s | but you cannot do the whole time theoretical research, 321.66s - 324.66s | so you have to do tinkering around with a car. 324.66s - 326.66s | It's also good for the motivation. 326.66s - 330.66s | There's a lot of information you just get when you look at the actual car, 330.66s - 332.66s | because the manufacturers won't tell you. 332.66s - 334.66s | Also, for students, it's quite cool 334.66s - 339.66s | to do research on the actual cars and projects. 340.66s - 343.66s | We have equipped our cars with lots of techniques 343.66s - 346.66s | to get information about them. 346.66s - 351.66s | We'll show you in the following how we have done this. 351.66s - 353.66s | That's the back of the Volkswagen ID.3. 353.66s - 356.66s | We've equipped this with lots of measurement techniques. 356.66s - 359.66s | On the right, you can see so-called vector boxes. 359.66s - 362.66s | They're from a German company called Vector. 362.66s - 364.66s | That's why we call them vector boxes. 364.66s - 369.66s | They're for capturing different buses inside a car. 369.66s - 372.66s | We have equipped the car in a way 372.66s - 377.66s | that we can get a holistic view of all relevant buses in this car. 377.66s - 380.66s | On the left side, you can also see 380.66s - 384.66s | some interesting parts for the electrical engineers. 384.66s - 388.66s | We have equipped the car with so-called LEM sensors. 388.66s - 391.66s | They are current-measuring sensors via induction. 391.66s - 396.66s | You can clip them on the high-voltage system wires 396.66s - 398.66s | to measure the current. 398.66s - 401.66s | The idea behind this holistic view 401.66s - 405.66s | between physical and messages inside the car 405.66s - 409.66s | is that we can compare those data 409.66s - 414.66s | and get correlations between the actual physical measurements 414.66s - 419.66s | and the recorded, for example, canvas data. 419.66s - 425.34s | As I've already introduced, from a theoretical way, 425.34s - 428.34s | there's also a practical attack surface, of course. 428.34s - 435.34s | On the left side, you can see classical key fob


chunk_id: 157_chunk_7
chunk_text:
369.66s | They're for capturing different buses inside a car. 369.66s - 372.66s | We have equipped the car in a way 372.66s - 377.66s | that we can get a holistic view of all relevant buses in this car. 377.66s - 380.66s | On the left side, you can also see 380.66s - 384.66s | some interesting parts for the electrical engineers. 384.66s - 388.66s | We have equipped the car with so-called LEM sensors. 388.66s - 391.66s | They are current-measuring sensors via induction. 391.66s - 396.66s | You can clip them on the high-voltage system wires 396.66s - 398.66s | to measure the current. 398.66s - 401.66s | The idea behind this holistic view 401.66s - 405.66s | between physical and messages inside the car 405.66s - 409.66s | is that we can compare those data 409.66s - 414.66s | and get correlations between the actual physical measurements 414.66s - 419.66s | and the recorded, for example, canvas data. 419.66s - 425.34s | As I've already introduced, from a theoretical way, 425.34s - 428.34s | there's also a practical attack surface, of course. 428.34s - 435.34s | On the left side, you can see classical key fob attacks using an SDR. 435.34s - 439.34s | Maybe all of you have heard about the roll jam attack. 439.34s - 444.34s | You jam the signal of the key fob because it's using a rolling code 444.34s - 447.34s | and the owner of the car will press a second time 447.34s - 451.34s | and you have recorded both signals 451.34s - 456.34s | and you resend the older one because the car hasn't heard this already. 456.34s - 460.34s | So you have a newer one for the car unlocking this in the future 460.34s - 463.34s | without the owner getting any notice about this. 463.34s - 468.34s | In the middle, you can see for automotive and classical attack surfaces 468.34s - 474.34s | also unsoldering the chips where the firmware is located on 474.34s - 476.34s | because you have physical access to your car. 476.34s - 481.34s | If you own the car, you can do anything you like with it, more or less. 481.34s - 485.34s | So that's why we have unsoldered the EMMC chip 485.34s - 489.34s | to get in contact with the firmware. 489.34s - 492.34s | That's


chunk_id: 157_chunk_8
chunk_text:
attacks using an SDR. 435.34s - 439.34s | Maybe all of you have heard about the roll jam attack. 439.34s - 444.34s | You jam the signal of the key fob because it's using a rolling code 444.34s - 447.34s | and the owner of the car will press a second time 447.34s - 451.34s | and you have recorded both signals 451.34s - 456.34s | and you resend the older one because the car hasn't heard this already. 456.34s - 460.34s | So you have a newer one for the car unlocking this in the future 460.34s - 463.34s | without the owner getting any notice about this. 463.34s - 468.34s | In the middle, you can see for automotive and classical attack surfaces 468.34s - 474.34s | also unsoldering the chips where the firmware is located on 474.34s - 476.34s | because you have physical access to your car. 476.34s - 481.34s | If you own the car, you can do anything you like with it, more or less. 481.34s - 485.34s | So that's why we have unsoldered the EMMC chip 485.34s - 489.34s | to get in contact with the firmware. 489.34s - 492.34s | That's the same we've done with the key fob. 492.34s - 496.34s | You can see here there was the memory chip. 496.34s - 503.34s | And maybe another interesting part is that you can directly connect 503.34s - 507.34s | with here you can see such a vector box to the internal buses of the car. 507.34s - 511.34s | Here you can see one such an ECU 511.34s - 518.34s | and we have connected this box with the CAN bus of the ECU controlling messages. 518.34s - 525.34s | But before we go there for a little bit in detail how these messages look like 525.34s - 529.34s | first we have to understand what this CAN bus actually is. 529.34s - 533.34s | How can we talk to those cars? 533.34s - 540.74s | For a game controller, we require, as I've already mentioned, 540.74s - 544.74s | information about specific actuators of the car. 544.74s - 546.74s | For example, the steering wheel. 546.74s - 551.74s | We later want to transfer the angle of the steering wheel to our virtual game controller. 551.74s - 554.74s | So we have to get this information out of


chunk_id: 157_chunk_9
chunk_text:
the same we've done with the key fob. 492.34s - 496.34s | You can see here there was the memory chip. 496.34s - 503.34s | And maybe another interesting part is that you can directly connect 503.34s - 507.34s | with here you can see such a vector box to the internal buses of the car. 507.34s - 511.34s | Here you can see one such an ECU 511.34s - 518.34s | and we have connected this box with the CAN bus of the ECU controlling messages. 518.34s - 525.34s | But before we go there for a little bit in detail how these messages look like 525.34s - 529.34s | first we have to understand what this CAN bus actually is. 529.34s - 533.34s | How can we talk to those cars? 533.34s - 540.74s | For a game controller, we require, as I've already mentioned, 540.74s - 544.74s | information about specific actuators of the car. 544.74s - 546.74s | For example, the steering wheel. 546.74s - 551.74s | We later want to transfer the angle of the steering wheel to our virtual game controller. 551.74s - 554.74s | So we have to get this information out of the car. 554.74s - 557.74s | And this information is transferred via the CAN bus. 557.74s - 567.49s | The topology of such a car looks like follows. 567.49s - 569.49s | It's a very condensed view. 569.49s - 572.49s | It's a very simplified view of our Volkswagen ID.3 572.49s - 579.49s | where you can see there's a main gateway ECU and several domains. 579.49s - 583.49s | Each domain consists of several other ECUs 583.49s - 586.49s | and each of those domains is separated in a way 586.49s - 591.49s | based on the criticality of those functionalities in the ECUs. 591.49s - 595.49s | For example, in the drive domain you can see 595.49s - 598.49s | that's located the engine ECU but also the brake ECU. 598.49s - 600.49s | They're all safety relevant. 600.49s - 603.49s | So they're very critical for the safety behavior of the car. 603.49s - 608.49s | On the left side you can see a separated domain with less criticality 608.49s - 612.49s | for example the light controlling inside the car. 612.49s - 620.90s | The special thing in this topology is that those domains are separated


chunk_id: 157_chunk_10
chunk_text:
the car. 554.74s - 557.74s | And this information is transferred via the CAN bus. 557.74s - 567.49s | The topology of such a car looks like follows. 567.49s - 569.49s | It's a very condensed view. 569.49s - 572.49s | It's a very simplified view of our Volkswagen ID.3 572.49s - 579.49s | where you can see there's a main gateway ECU and several domains. 579.49s - 583.49s | Each domain consists of several other ECUs 583.49s - 586.49s | and each of those domains is separated in a way 586.49s - 591.49s | based on the criticality of those functionalities in the ECUs. 591.49s - 595.49s | For example, in the drive domain you can see 595.49s - 598.49s | that's located the engine ECU but also the brake ECU. 598.49s - 600.49s | They're all safety relevant. 600.49s - 603.49s | So they're very critical for the safety behavior of the car. 603.49s - 608.49s | On the left side you can see a separated domain with less criticality 608.49s - 612.49s | for example the light controlling inside the car. 612.49s - 620.90s | The special thing in this topology is that those domains are separated 620.90s - 622.90s | based on this gateway ECU. 622.90s - 631.90s | The gateway ECU is responsible for shielding the inside of the car against the outside 631.90s - 636.90s | because, maybe you know this from combustion engines, 636.90s - 640.90s | the outside of the car is connected with a so-called OBD2 port. 640.90s - 642.90s | It's for diagnosis. 642.90s - 646.90s | If you bring your car to a garage they will plug there in 646.90s - 649.90s | and you want to prevent that via the OBD2 port. 649.90s - 652.90s | Everyone can read everything of the car. 652.90s - 657.90s | So that's why such a gateway ECU is introduced into this topology. 657.90s - 661.90s | But this strongly depends on the actual car you want to consider. 661.90s - 671.58s | That's just for the Volkswagen ID.3 and the group of vehicles from Volkswagen. 671.58s - 674.58s | Now we get a little bit into detail about this CAN bus. 674.58s - 677.58s | The CAN bus was developed by Bosch in 1986. 677.58s - 683.58s | It's a dual wire twisted pair cable and as I said before it's


chunk_id: 157_chunk_11
chunk_text:
620.90s - 622.90s | based on this gateway ECU. 622.90s - 631.90s | The gateway ECU is responsible for shielding the inside of the car against the outside 631.90s - 636.90s | because, maybe you know this from combustion engines, 636.90s - 640.90s | the outside of the car is connected with a so-called OBD2 port. 640.90s - 642.90s | It's for diagnosis. 642.90s - 646.90s | If you bring your car to a garage they will plug there in 646.90s - 649.90s | and you want to prevent that via the OBD2 port. 649.90s - 652.90s | Everyone can read everything of the car. 652.90s - 657.90s | So that's why such a gateway ECU is introduced into this topology. 657.90s - 661.90s | But this strongly depends on the actual car you want to consider. 661.90s - 671.58s | That's just for the Volkswagen ID.3 and the group of vehicles from Volkswagen. 671.58s - 674.58s | Now we get a little bit into detail about this CAN bus. 674.58s - 677.58s | The CAN bus was developed by Bosch in 1986. 677.58s - 683.58s | It's a dual wire twisted pair cable and as I said before it's a bus topology. 683.58s - 685.58s | What does it mean? 685.58s - 693.58s | The bus topology means that the ECUs are connected to the same wire or wire pair 693.58s - 698.58s | and all ECUs get the same state of information in the respective time frame. 698.58s - 704.58s | We have a frequency in this CAN bus and all this information is distributed 704.58s - 710.58s | in this time frame to all ECUs connected to this CAN bus. 710.58s - 713.58s | It's also a multi-master protocol. 713.58s - 718.58s | It means that all ECUs can send and receive on demand 718.58s - 722.58s | and there's no master required to control them. 722.58s - 730.18s | Now we have the foundations how this CAN bus works. 730.18s - 735.18s | Now we get to gain access to this physical CAN bus inside the car. 735.18s - 742.18s | Maybe the most convenient way is to find just a repair manual or a wiring diagram of the car. 742.18s - 744.18s | They are usually available for garages. 744.18s - 747.18s | For Volkswagen you can get them online. 747.18s - 751.18s | If


chunk_id: 157_chunk_12
chunk_text:
a bus topology. 683.58s - 685.58s | What does it mean? 685.58s - 693.58s | The bus topology means that the ECUs are connected to the same wire or wire pair 693.58s - 698.58s | and all ECUs get the same state of information in the respective time frame. 698.58s - 704.58s | We have a frequency in this CAN bus and all this information is distributed 704.58s - 710.58s | in this time frame to all ECUs connected to this CAN bus. 710.58s - 713.58s | It's also a multi-master protocol. 713.58s - 718.58s | It means that all ECUs can send and receive on demand 718.58s - 722.58s | and there's no master required to control them. 722.58s - 730.18s | Now we have the foundations how this CAN bus works. 730.18s - 735.18s | Now we get to gain access to this physical CAN bus inside the car. 735.18s - 742.18s | Maybe the most convenient way is to find just a repair manual or a wiring diagram of the car. 742.18s - 744.18s | They are usually available for garages. 744.18s - 747.18s | For Volkswagen you can get them online. 747.18s - 751.18s | If you claim you are a garage then you can buy it. 751.18s - 757.18s | Otherwise you have to find it out by yourself but this can become very, very hard. 757.18s - 761.18s | So very common having such a wiring diagram. 761.18s - 769.18s | Based on this wiring diagram you can find a good exposed position of an interesting CAN bus 769.18s - 771.18s | where you can connect to. 771.18s - 777.18s | For example here you can see the Tesla Model 3 which is in the mid console of the car. 777.18s - 786.18s | There's one of three CAN buses which you can easily open and connect to ready to buy adapter. 786.18s - 789.18s | You can buy those adapters easily on eBay for example. 789.18s - 794.18s | And then you can gain access to this CAN bus. 794.18s - 798.18s | If you don't want to destroy your car or altering this 798.18s - 804.18s | there are also less intrusive techniques called contactless CAN readers. 804.18s - 808.18s | They read CAN messages based on induction of the signal. 808.18s - 811.18s | And that's more or less looks like


chunk_id: 157_chunk_13
chunk_text:
you claim you are a garage then you can buy it. 751.18s - 757.18s | Otherwise you have to find it out by yourself but this can become very, very hard. 757.18s - 761.18s | So very common having such a wiring diagram. 761.18s - 769.18s | Based on this wiring diagram you can find a good exposed position of an interesting CAN bus 769.18s - 771.18s | where you can connect to. 771.18s - 777.18s | For example here you can see the Tesla Model 3 which is in the mid console of the car. 777.18s - 786.18s | There's one of three CAN buses which you can easily open and connect to ready to buy adapter. 786.18s - 789.18s | You can buy those adapters easily on eBay for example. 789.18s - 794.18s | And then you can gain access to this CAN bus. 794.18s - 798.18s | If you don't want to destroy your car or altering this 798.18s - 804.18s | there are also less intrusive techniques called contactless CAN readers. 804.18s - 808.18s | They read CAN messages based on induction of the signal. 808.18s - 811.18s | And that's more or less looks like a crocodile. 811.18s - 814.18s | That's why some products called CAN crocodile. 814.18s - 817.18s | You clamp the CAN wires high and low. 817.18s - 824.18s | Those dual wires between the clamp of the contactless CAN reader. 824.18s - 827.18s | And you can read those messages. 827.18s - 831.18s | So you have gained access to the physical layer. 831.18s - 835.18s | You have read those physical signals of the CAN bus. 835.18s - 839.18s | Now you have to transfer them into software. 840.18s - 844.18s | For the Raspberry Pi for example. 844.18s - 848.18s | A CAN head where those physical CAN signals are interpreted 848.18s - 852.18s | and transferred to the kernel of the Raspberry Pi. 852.18s - 858.18s | There are also other options available which can conveniently be used 858.18s - 862.18s | where you can connect your CAN bus directly via USB to your PC. 862.18s - 867.18s | This also works for Windows so maybe it's for part of you interesting. 867.18s - 872.18s | So now we have transferred the message to the software part of our project. 872.18s - 875.18s | And that's where


chunk_id: 157_chunk_14
chunk_text:
a crocodile. 811.18s - 814.18s | That's why some products called CAN crocodile. 814.18s - 817.18s | You clamp the CAN wires high and low. 817.18s - 824.18s | Those dual wires between the clamp of the contactless CAN reader. 824.18s - 827.18s | And you can read those messages. 827.18s - 831.18s | So you have gained access to the physical layer. 831.18s - 835.18s | You have read those physical signals of the CAN bus. 835.18s - 839.18s | Now you have to transfer them into software. 840.18s - 844.18s | For the Raspberry Pi for example. 844.18s - 848.18s | A CAN head where those physical CAN signals are interpreted 848.18s - 852.18s | and transferred to the kernel of the Raspberry Pi. 852.18s - 858.18s | There are also other options available which can conveniently be used 858.18s - 862.18s | where you can connect your CAN bus directly via USB to your PC. 862.18s - 867.18s | This also works for Windows so maybe it's for part of you interesting. 867.18s - 872.18s | So now we have transferred the message to the software part of our project. 872.18s - 875.18s | And that's where Tim continues. 875.18s - 878.18s | Alright, so very conveniently in the Linux kernel 878.18s - 881.18s | there's already a CAN driver built in. 881.18s - 884.18s | And if you want to work with that there's CANutils 884.18s - 888.18s | which has all the basic tools to use that. 888.18s - 892.18s | Also if you want to do more advanced stuff for scripting 892.18s - 895.18s | you can use for example PythonCAN as a really good library. 895.18s - 897.18s | That's what we use for our project. 897.18s - 901.18s | There's also CAN tools for more advanced command line tools. 901.18s - 906.18s | If you're into GUIs there's SavvyCAN which is a really good open source GUI tool. 906.18s - 909.18s | And of course there are a lot of commercial tools. 909.18s - 912.18s | We talked about all this vector stuff before. 912.18s - 914.18s | But let's stick with the very basics. 914.18s - 920.18s | So you install CANutils and then there's this condom command 920.18s - 923.18s | which will just print out all of the CAN messages on the bus. 923.18s - 928.18s | It looks


chunk_id: 157_chunk_15
chunk_text:
Tim continues. 875.18s - 878.18s | Alright, so very conveniently in the Linux kernel 878.18s - 881.18s | there's already a CAN driver built in. 881.18s - 884.18s | And if you want to work with that there's CANutils 884.18s - 888.18s | which has all the basic tools to use that. 888.18s - 892.18s | Also if you want to do more advanced stuff for scripting 892.18s - 895.18s | you can use for example PythonCAN as a really good library. 895.18s - 897.18s | That's what we use for our project. 897.18s - 901.18s | There's also CAN tools for more advanced command line tools. 901.18s - 906.18s | If you're into GUIs there's SavvyCAN which is a really good open source GUI tool. 906.18s - 909.18s | And of course there are a lot of commercial tools. 909.18s - 912.18s | We talked about all this vector stuff before. 912.18s - 914.18s | But let's stick with the very basics. 914.18s - 920.18s | So you install CANutils and then there's this condom command 920.18s - 923.18s | which will just print out all of the CAN messages on the bus. 923.18s - 928.18s | It looks somehow like this but probably a lot faster if you're on a real car. 928.18s - 931.18s | So for a Tesla for example it might be on one bus 931.18s - 934.18s | it's I think like 3,000 messages a second. 934.18s - 937.18s | So it can be quite a lot. 937.18s - 942.18s | One step back even if you connect to this. 942.18s - 947.18s | So for Linux the CAN interface is like any other network interface 947.18s - 951.18s | if your adapter is compatible with SocketCAN. 952.18s - 956.18s | The only difference is that you don't have network manager 956.18s - 960.18s | to directly get your interface up and running. 960.18s - 963.18s | And you also need a bitrate. 963.18s - 969.18s | So you have to tell the computer how fast the bus operates. 969.18s - 974.18s | And you can measure that by using an oscilloscope of course. 974.18s - 978.18s | Luckily for automotive it's usually 500 kilobits per second. 978.18s - 980.18s | So you can also try that. 980.18s - 989.18s | And just as a disclaimer there are also more modern standards 989.18s -


