# MediaChunks

chunk_id: 180_chunk_28
chunk_text:
is not a surprise that we're now at the point of talking about liability. 1401.75s - 1403.43s | We saw this coming for decades. 1403.43s - 1408.95s | I love to quote Dan Kaminsky on this, who said like, you know, security was never a 1408.95s - 1412.83s | consideration when the internet was invented. 1412.83s - 1416.07s | The internet was invented to move pictures of cats. 1416.07s - 1418.19s | It's very good at that. 1418.19s - 1422.31s | But I do think, so at the end of the day, we are a voluntary agency, but, you know, 1422.31s - 1428.09s | we started out at RSA, we have this secure by design pledge, where companies are signing 1428.09s - 1433.97s | up to it, committing to make material progress in seven key areas, you know, increasing 1433.97s - 1439.89s | use of MFA, decreasing use of default password, eliminating whole classes of vulnerabilities. 1439.89s - 1446.09s | And we had 68 vendors that signed at RSA, three months later, we're nearly at 200. 1446.09s - 1450.45s | And I think there's virtue in being able to track progress and transparently report on 1450.45s - 1451.45s | it. 1451.45s - 1455.05s | Like that's a way, it's not like we're going to give people scores and stuff, and we're 1455.05s - 1456.85s | going to have a third party do it. 1456.89s - 1458.89s | So I really think transparency... 1458.89s - 1463.57s | I like that you have the cycle, because otherwise they just stamp it and then they never... 1463.57s - 1467.89s | No, I mean, as you say, transparency creates trust. 1467.89s - 1472.25s | And part of that then will help consumers say, well, did you sign the pledge? 1472.25s - 1475.33s | How did you do on implementing the pledge? 1475.33s - 1482.33s | And you know, that will help to build, I think, greater security and resilience into the ecosystem. 1482.33s - 1485.93s | I think product makers love to differentiate themselves. 1486.01s - 1489.93s | And so if you give them some ways to differentiate, maybe their marketing team takes it and runs 1489.93s - 1490.93s | with it. 1490.93s - 1491.93s | Yeah. 1491.93s - 1496.17s | And then they maybe respond to you giving them more tools that they can use to differentiate 1496.17s - 1497.17s | themselves. 1497.17s


chunk_id: 180_chunk_29
chunk_text:
1451.45s - 1455.05s | Like that's a way, it's not like we're going to give people scores and stuff, and we're 1455.05s - 1456.85s | going to have a third party do it. 1456.89s - 1458.89s | So I really think transparency... 1458.89s - 1463.57s | I like that you have the cycle, because otherwise they just stamp it and then they never... 1463.57s - 1467.89s | No, I mean, as you say, transparency creates trust. 1467.89s - 1472.25s | And part of that then will help consumers say, well, did you sign the pledge? 1472.25s - 1475.33s | How did you do on implementing the pledge? 1475.33s - 1482.33s | And you know, that will help to build, I think, greater security and resilience into the ecosystem. 1482.33s - 1485.93s | I think product makers love to differentiate themselves. 1486.01s - 1489.93s | And so if you give them some ways to differentiate, maybe their marketing team takes it and runs 1489.93s - 1490.93s | with it. 1490.93s - 1491.93s | Yeah. 1491.93s - 1496.17s | And then they maybe respond to you giving them more tools that they can use to differentiate 1496.17s - 1497.17s | themselves. 1497.17s - 1498.17s | No, I totally agree. 1498.17s - 1499.65s | Should we see if anyone has questions for us? 1499.65s - 1500.65s | Yeah. 1500.65s - 1501.65s | We're coming down to 20 minutes left. 1501.65s - 1503.17s | Let's see how this goes. 1503.17s - 1504.17s | And if you... 1504.17s - 1505.81s | 20 minutes of questions. 1505.81s - 1508.01s | As you terrify us, we'll just drink. 1508.01s - 1509.01s | AJA. 1509.01s - 1510.01s | Ask Jeff. 1510.01s - 1511.01s | AJJA. 1511.01s - 1512.01s | Ask Jeff. 1512.01s - 1513.01s | Okay, go ahead. 1513.01s - 1517.01s | Do you want to tell us where you're from or anything to give us a little bit of perspective? 1517.01s - 1519.45s | Oh, wait. 1519.45s - 1520.45s | Wait. 1520.45s - 1524.73s | Let's turn on the microphone in the Q&A session area. 1524.73s - 1525.73s | Try speaking at it again. 1525.73s - 1528.61s | We'll see if they've turned it up. 1528.61s - 1529.61s | Number four. 1529.61s - 1530.61s | Okay. 1530.61s - 1531.61s | There it is. 1531.61s - 1532.61s | Yeah. 1532.61s - 1533.61s | You got to be close


chunk_id: 180_chunk_30
chunk_text:
- 1498.17s | No, I totally agree. 1498.17s - 1499.65s | Should we see if anyone has questions for us? 1499.65s - 1500.65s | Yeah. 1500.65s - 1501.65s | We're coming down to 20 minutes left. 1501.65s - 1503.17s | Let's see how this goes. 1503.17s - 1504.17s | And if you... 1504.17s - 1505.81s | 20 minutes of questions. 1505.81s - 1508.01s | As you terrify us, we'll just drink. 1508.01s - 1509.01s | AJA. 1509.01s - 1510.01s | Ask Jeff. 1510.01s - 1511.01s | AJJA. 1511.01s - 1512.01s | Ask Jeff. 1512.01s - 1513.01s | Okay, go ahead. 1513.01s - 1517.01s | Do you want to tell us where you're from or anything to give us a little bit of perspective? 1517.01s - 1519.45s | Oh, wait. 1519.45s - 1520.45s | Wait. 1520.45s - 1524.73s | Let's turn on the microphone in the Q&A session area. 1524.73s - 1525.73s | Try speaking at it again. 1525.73s - 1528.61s | We'll see if they've turned it up. 1528.61s - 1529.61s | Number four. 1529.61s - 1530.61s | Okay. 1530.61s - 1531.61s | There it is. 1531.61s - 1532.61s | Yeah. 1532.61s - 1533.61s | You got to be close to the microphone, though. 1533.61s - 1534.61s | Oh, yeah. 1534.61s - 1535.61s | Wait, wait. 1535.61s - 1544.34s | You got to be closer than that. 1544.34s - 1545.34s | Okay. 1545.34s - 1546.34s | Yeah. 1546.50s - 1549.78s | Well, they say you basically have to eat the microphone for it to work. 1549.78s - 1564.38s | So yes. 1564.38s - 1574.96s | My job is done here. 1574.96s - 1639.10s | Thanks dude. 1639.10s - 1640.10s | Yeah. 1640.10s - 1641.10s | No, it's a great question. 1641.10s - 1644.66s | Thank you for the kind words. 1644.66s - 1649.58s | Before I answer that, can I give you one of my pet peeves? 1649.58s - 1656.02s | The names that we call these threat actors drive me frickin' bananas. 1656.02s - 1668.78s | I mean, you know, Midnight Blizzard, Fancy Bear, Wizard Spider, Nemesis Kitten, The Lazarus 1668.78s - 1671.86s | Group, Volt Typhoon. 1671.86s - 1673.98s | That's redonkulous, man. 1673.98s - 1675.62s | I'm on this campaign. 1675.62s - 1682.81s | So I want to rename all these things, scrawny nuisance, right? 1682.81s - 1683.81s | I got more. 1683.81s - 1684.81s | I


chunk_id: 180_chunk_31
chunk_text:
to the microphone, though. 1533.61s - 1534.61s | Oh, yeah. 1534.61s - 1535.61s | Wait, wait. 1535.61s - 1544.34s | You got to be closer than that. 1544.34s - 1545.34s | Okay. 1545.34s - 1546.34s | Yeah. 1546.50s - 1549.78s | Well, they say you basically have to eat the microphone for it to work. 1549.78s - 1564.38s | So yes. 1564.38s - 1574.96s | My job is done here. 1574.96s - 1639.10s | Thanks dude. 1639.10s - 1640.10s | Yeah. 1640.10s - 1641.10s | No, it's a great question. 1641.10s - 1644.66s | Thank you for the kind words. 1644.66s - 1649.58s | Before I answer that, can I give you one of my pet peeves? 1649.58s - 1656.02s | The names that we call these threat actors drive me frickin' bananas. 1656.02s - 1668.78s | I mean, you know, Midnight Blizzard, Fancy Bear, Wizard Spider, Nemesis Kitten, The Lazarus 1668.78s - 1671.86s | Group, Volt Typhoon. 1671.86s - 1673.98s | That's redonkulous, man. 1673.98s - 1675.62s | I'm on this campaign. 1675.62s - 1682.81s | So I want to rename all these things, scrawny nuisance, right? 1682.81s - 1683.81s | I got more. 1683.81s - 1684.81s | I got more. 1684.81s - 1692.07s | Stable Ferret, Weak Weasel, and my favorite, Doofus Dingo. 1692.07s - 1696.55s | That's what I'm talking about, right? 1696.55s - 1702.55s | So it's a great question and you know, frankly, this is something that we are super focused 1702.55s - 1706.73s | on at CISA and it's a threat that's different in kind. 1706.73s - 1713.99s | For most of my career, we really focused on China as a threat of espionage, data theft, 1713.99s - 1719.99s | theft, and over the past couple years, we have seen Chinese cyberspace force actors 1719.99s - 1726.11s | embedding deep within our critical infrastructure, not for espionage, but rather to launch disruptive 1726.11s - 1731.59s | or destructive attacks in the event of a conflict in Taiwan. 1731.59s - 1738.27s | So it's a world where a war in Asia will have very real impacts on the lives of Americans. 1738.27s - 1744.87s | You would see pipelines exploding, pollution of water systems, severing of telecommunications, 1744.87s - 1751.87s | derailing of transportation nodes, all specifically to incite societal panic and chaos and deter 1751.87s - 1755.83s | our ability to marshal military might


chunk_id: 180_chunk_32
chunk_text:
got more. 1684.81s - 1692.07s | Stable Ferret, Weak Weasel, and my favorite, Doofus Dingo. 1692.07s - 1696.55s | That's what I'm talking about, right? 1696.55s - 1702.55s | So it's a great question and you know, frankly, this is something that we are super focused 1702.55s - 1706.73s | on at CISA and it's a threat that's different in kind. 1706.73s - 1713.99s | For most of my career, we really focused on China as a threat of espionage, data theft, 1713.99s - 1719.99s | theft, and over the past couple years, we have seen Chinese cyberspace force actors 1719.99s - 1726.11s | embedding deep within our critical infrastructure, not for espionage, but rather to launch disruptive 1726.11s - 1731.59s | or destructive attacks in the event of a conflict in Taiwan. 1731.59s - 1738.27s | So it's a world where a war in Asia will have very real impacts on the lives of Americans. 1738.27s - 1744.87s | You would see pipelines exploding, pollution of water systems, severing of telecommunications, 1744.87s - 1751.87s | derailing of transportation nodes, all specifically to incite societal panic and chaos and deter 1751.87s - 1755.83s | our ability to marshal military might and citizen will. 1755.83s - 1757.39s | And so it is a very real threat. 1757.39s - 1762.51s | It's not a theoretical one, because our hunt teams have actually worked with the private 1762.51s - 1770.83s | sector to identify and eradicate these actors from multiple sectors, water, power, comms, 1770.83s - 1771.83s | transportation. 1771.83s - 1778.19s | So really a real threat, and it's why we are making the case to how important resilience 1778.19s - 1780.31s | is for every single business. 1780.31s - 1783.95s | But to your point, they are using living off the land techniques. 1783.95s - 1785.95s | So it's not like malware, right? 1785.95s - 1789.99s | They're actually using the native processes of the system. 1789.99s - 1794.91s | And within the compromised infrastructure, they are hard to find. 1794.91s - 1796.63s | We have fantastic talents. 1796.63s - 1798.75s | It's a kudos to our threat hunt team. 1798.75s - 1802.07s | They've actually been able to find and identify them. 1802.07s - 1804.47s | But once they're in the infrastructure, they're hard to find. 1804.47s - 1809.83s | But the thing, the secure by design angle is the


chunk_id: 180_chunk_33
chunk_text:
and citizen will. 1755.83s - 1757.39s | And so it is a very real threat. 1757.39s - 1762.51s | It's not a theoretical one, because our hunt teams have actually worked with the private 1762.51s - 1770.83s | sector to identify and eradicate these actors from multiple sectors, water, power, comms, 1770.83s - 1771.83s | transportation. 1771.83s - 1778.19s | So really a real threat, and it's why we are making the case to how important resilience 1778.19s - 1780.31s | is for every single business. 1780.31s - 1783.95s | But to your point, they are using living off the land techniques. 1783.95s - 1785.95s | So it's not like malware, right? 1785.95s - 1789.99s | They're actually using the native processes of the system. 1789.99s - 1794.91s | And within the compromised infrastructure, they are hard to find. 1794.91s - 1796.63s | We have fantastic talents. 1796.63s - 1798.75s | It's a kudos to our threat hunt team. 1798.75s - 1802.07s | They've actually been able to find and identify them. 1802.07s - 1804.47s | But once they're in the infrastructure, they're hard to find. 1804.47s - 1809.83s | But the thing, the secure by design angle is the way that they're getting into the infrastructure 1809.83s - 1813.91s | is they're using edge devices as a launch point. 1813.91s - 1818.55s | And those edge devices are actually very easy to compromise. 1818.55s - 1823.95s | And one of the vendors who we've been working with actually credit to them, because they 1823.95s - 1828.27s | were the first ones to sign the pledge, is Avanti. 1828.27s - 1832.55s | But that's an edge device, one of many, that the Chinese are taking advantage of to hop 1832.55s - 1835.03s | into our critical infrastructure. 1835.03s - 1840.23s | And so what we did, we actually put out an emergency directive and told all of the federal 1840.23s - 1846.15s | civilian agencies, you need to pull out this piece of technology, because we cannot guarantee 1846.47s - 1849.63s | that it does not implicate risk. 1849.63s - 1853.39s | And frankly, we work with that company. 1853.39s - 1857.83s | And we realize that it has an issue on reputation and business, but they were really good to 1857.83s - 1858.83s | work with. 1858.83s - 1859.83s | They signed the pledge. 1859.83s - 1860.83s | They're


chunk_id: 180_chunk_34
chunk_text:
way that they're getting into the infrastructure 1809.83s - 1813.91s | is they're using edge devices as a launch point. 1813.91s - 1818.55s | And those edge devices are actually very easy to compromise. 1818.55s - 1823.95s | And one of the vendors who we've been working with actually credit to them, because they 1823.95s - 1828.27s | were the first ones to sign the pledge, is Avanti. 1828.27s - 1832.55s | But that's an edge device, one of many, that the Chinese are taking advantage of to hop 1832.55s - 1835.03s | into our critical infrastructure. 1835.03s - 1840.23s | And so what we did, we actually put out an emergency directive and told all of the federal 1840.23s - 1846.15s | civilian agencies, you need to pull out this piece of technology, because we cannot guarantee 1846.47s - 1849.63s | that it does not implicate risk. 1849.63s - 1853.39s | And frankly, we work with that company. 1853.39s - 1857.83s | And we realize that it has an issue on reputation and business, but they were really good to 1857.83s - 1858.83s | work with. 1858.83s - 1859.83s | They signed the pledge. 1859.83s - 1860.83s | They're making progress. 1860.83s - 1861.83s | We're going to track it. 1861.83s - 1864.43s | But that, at the end of the day, that's the complexity. 1864.43s - 1869.31s | Yes, there are ways to find these actors if you know what to look for. 1869.31s - 1872.83s | But also the way that they're getting in, we've made it easy on them, because we're 1872.83s - 1877.71s | not demanding enough from our technology vendors, and that's what our push for Secure 1877.71s - 1878.71s | by Design is. 1878.71s - 1883.39s | Okay, let's go to the next question. 1883.39s - 1926.66s | You got to get really close in there. 1926.66s - 1927.66s | Yeah. 1927.66s - 1930.38s | So your last question, absolutely. 1930.38s - 1935.98s | We are working across the federal government to ensure that we are eating our own dog food 1935.98s - 1940.94s | when it comes to Secure by Design, or drinking our own bourbon, as it were, when it comes 1940.94s - 1941.94s | to Secure by Design. 1942.10s - 1945.50s | And we work closely with GSA on FedRAMP. 1945.50s - 1949.38s | But we are absolutely using all


chunk_id: 180_chunk_35
chunk_text:
making progress. 1860.83s - 1861.83s | We're going to track it. 1861.83s - 1864.43s | But that, at the end of the day, that's the complexity. 1864.43s - 1869.31s | Yes, there are ways to find these actors if you know what to look for. 1869.31s - 1872.83s | But also the way that they're getting in, we've made it easy on them, because we're 1872.83s - 1877.71s | not demanding enough from our technology vendors, and that's what our push for Secure 1877.71s - 1878.71s | by Design is. 1878.71s - 1883.39s | Okay, let's go to the next question. 1883.39s - 1926.66s | You got to get really close in there. 1926.66s - 1927.66s | Yeah. 1927.66s - 1930.38s | So your last question, absolutely. 1930.38s - 1935.98s | We are working across the federal government to ensure that we are eating our own dog food 1935.98s - 1940.94s | when it comes to Secure by Design, or drinking our own bourbon, as it were, when it comes 1940.94s - 1941.94s | to Secure by Design. 1942.10s - 1945.50s | And we work closely with GSA on FedRAMP. 1945.50s - 1949.38s | But we are absolutely using all of the tools of procurement. 1949.38s - 1955.82s | Just last week, we put out a Secure by Demand focused software acquisition guide for government 1955.82s - 1957.22s | enterprise customers. 1957.22s - 1962.74s | And then we put out something earlier this week, Secure by Demand for software customers. 1962.74s - 1969.18s | So questions that you can ask of vendors to see how they are prioritizing security. 1969.18s - 1972.38s | So yes is the answer to your second question. 1972.38s - 1977.26s | Look, for the first one, I'm the head goalie for cyber. 1977.26s - 1978.86s | We're the cyber defenders. 1978.86s - 1985.30s | But we do work very closely with folks like Ambassador Nate Fick, who is the cyber ambassador. 1985.30s - 1990.62s | We work very closely with NSA, with CyberCom, and with the Federal Bureau of Investigation. 1990.62s - 1997.34s | And I have to say, I think that we have, as a government, become more cohesive, more coherent, 1997.34s - 2003.50s | when we are using levers that have not necessarily been used as aggressively before to hold other 2003.50s - 2010.14s | governments accountable, whether it's through justice or whether


chunk_id: 180_chunk_36
chunk_text:
of the tools of procurement. 1949.38s - 1955.82s | Just last week, we put out a Secure by Demand focused software acquisition guide for government 1955.82s - 1957.22s | enterprise customers. 1957.22s - 1962.74s | And then we put out something earlier this week, Secure by Demand for software customers. 1962.74s - 1969.18s | So questions that you can ask of vendors to see how they are prioritizing security. 1969.18s - 1972.38s | So yes is the answer to your second question. 1972.38s - 1977.26s | Look, for the first one, I'm the head goalie for cyber. 1977.26s - 1978.86s | We're the cyber defenders. 1978.86s - 1985.30s | But we do work very closely with folks like Ambassador Nate Fick, who is the cyber ambassador. 1985.30s - 1990.62s | We work very closely with NSA, with CyberCom, and with the Federal Bureau of Investigation. 1990.62s - 1997.34s | And I have to say, I think that we have, as a government, become more cohesive, more coherent, 1997.34s - 2003.50s | when we are using levers that have not necessarily been used as aggressively before to hold other 2003.50s - 2010.14s | governments accountable, whether it's through justice or whether it's in diplomatic ways. 2010.14s - 2013.22s | I get you that there is more to be done. 2013.22s - 2016.06s | There is always more to be done in this world. 2016.06s - 2023.74s | But I do think that across the federal government, we have attempted to more forcefully attribute 2023.74s - 2032.26s | activity and hold partners accountable for being involved in malicious cyber activity. 2032.26s - 2037.26s | So I've got a question on that. 2037.26s - 2040.90s | I always like to say internet problems are global problems. 2040.90s - 2049.56s | And so even when you have different opinions with China on a political issue, there's still 2049.56s - 2051.68s | a giant manufacturer. 2051.68s - 2056.08s | If there's a problem in a product or a defective something or other, you still have to talk 2056.08s - 2060.68s | with China because chances are they're manufacturing the thing, right? 2060.68s - 2067.52s | So you still need to maintain positive relationships, working relationships with the manufacturers 2067.52s - 2068.84s | around the entire world. 2068.84s - 2072.84s | And sometimes those manufacturers are in countries who are having a political disagreement. 2072.84s -


chunk_id: 180_chunk_37
chunk_text:
it's in diplomatic ways. 2010.14s - 2013.22s | I get you that there is more to be done. 2013.22s - 2016.06s | There is always more to be done in this world. 2016.06s - 2023.74s | But I do think that across the federal government, we have attempted to more forcefully attribute 2023.74s - 2032.26s | activity and hold partners accountable for being involved in malicious cyber activity. 2032.26s - 2037.26s | So I've got a question on that. 2037.26s - 2040.90s | I always like to say internet problems are global problems. 2040.90s - 2049.56s | And so even when you have different opinions with China on a political issue, there's still 2049.56s - 2051.68s | a giant manufacturer. 2051.68s - 2056.08s | If there's a problem in a product or a defective something or other, you still have to talk 2056.08s - 2060.68s | with China because chances are they're manufacturing the thing, right? 2060.68s - 2067.52s | So you still need to maintain positive relationships, working relationships with the manufacturers 2067.52s - 2068.84s | around the entire world. 2068.84s - 2072.84s | And sometimes those manufacturers are in countries who are having a political disagreement. 2072.84s - 2077.72s | But you still have to have positive relationships because they're producing the thing, right? 2077.72s - 2079.08s | So you have to have a sort of a nuance. 2079.60s - 2085.52s | And I think maybe CISA is in a unique position in that, like you mentioned earlier, you're 2085.52s - 2090.12s | not intelligence community, you're not military, right? 2090.12s - 2091.40s | You're civilian. 2091.40s - 2097.68s | So you can speak from a different perspective that's more civilian than military. 2097.68s - 2098.68s | Yeah. 2098.68s - 2104.28s | And, you know, that opportunity has not come up. 2104.28s - 2107.72s | I think we talked about this as one of the early meetings, like having the head of CISA 2107.88s - 2114.80s | and the head of China's CERT together, frankly, given some of the things that we have seen 2114.80s - 2121.44s | them doing in our critical infrastructure, which I don't think that they've owned up 2121.44s - 2122.44s | to. 2122.44s - 2125.16s | In fact, they've completely denied it. 2125.16s - 2131.40s | I think that's really problematic because at the end of the day, these targets are civilian 2131.40s


chunk_id: 180_chunk_38
chunk_text:
2077.72s | But you still have to have positive relationships because they're producing the thing, right? 2077.72s - 2079.08s | So you have to have a sort of a nuance. 2079.60s - 2085.52s | And I think maybe CISA is in a unique position in that, like you mentioned earlier, you're 2085.52s - 2090.12s | not intelligence community, you're not military, right? 2090.12s - 2091.40s | You're civilian. 2091.40s - 2097.68s | So you can speak from a different perspective that's more civilian than military. 2097.68s - 2098.68s | Yeah. 2098.68s - 2104.28s | And, you know, that opportunity has not come up. 2104.28s - 2107.72s | I think we talked about this as one of the early meetings, like having the head of CISA 2107.88s - 2114.80s | and the head of China's CERT together, frankly, given some of the things that we have seen 2114.80s - 2121.44s | them doing in our critical infrastructure, which I don't think that they've owned up 2121.44s - 2122.44s | to. 2122.44s - 2125.16s | In fact, they've completely denied it. 2125.16s - 2131.40s | I think that's really problematic because at the end of the day, these targets are civilian 2131.40s - 2134.16s | critical infrastructure. 2134.16s - 2139.00s | And I would be happy to have discussions that were in good faith, where we thought 2139.00s - 2143.56s | we could make real progress, but I'm not sure we're at that stage right now. 2143.56s - 2176.76s | OK, let's go to the next gentleman. 2176.76s - 2177.76s | Take what off the table? 2177.76s - 2189.63s | Why are we taking it off the table? 2189.63s - 2193.55s | So if you magically have secured by design and it achieves all of its goals and it's 2193.55s - 2195.95s | done, what's next in line? 2195.95s - 2200.63s | But are you... 2200.63s - 2201.63s | Oh, what's the next... 2201.63s - 2204.98s | I don't know if I heard that. 2204.98s - 2205.98s | What is it? 2206.06s - 2209.62s | So it's basically, if you have secure by design success and Rust and everybody in the world 2209.62s - 2211.90s | is using Rust, what's next? 2211.90s - 2212.90s | Yeah. 2212.90s - 2217.74s | So, you know, I sort of said tongue in cheek yesterday, we want to get to a world where 2217.74s - 2222.74s


chunk_id: 180_chunk_39
chunk_text:
- 2134.16s | critical infrastructure. 2134.16s - 2139.00s | And I would be happy to have discussions that were in good faith, where we thought 2139.00s - 2143.56s | we could make real progress, but I'm not sure we're at that stage right now. 2143.56s - 2176.76s | OK, let's go to the next gentleman. 2176.76s - 2177.76s | Take what off the table? 2177.76s - 2189.63s | Why are we taking it off the table? 2189.63s - 2193.55s | So if you magically have secured by design and it achieves all of its goals and it's 2193.55s - 2195.95s | done, what's next in line? 2195.95s - 2200.63s | But are you... 2200.63s - 2201.63s | Oh, what's the next... 2201.63s - 2204.98s | I don't know if I heard that. 2204.98s - 2205.98s | What is it? 2206.06s - 2209.62s | So it's basically, if you have secure by design success and Rust and everybody in the world 2209.62s - 2211.90s | is using Rust, what's next? 2211.90s - 2212.90s | Yeah. 2212.90s - 2217.74s | So, you know, I sort of said tongue in cheek yesterday, we want to get to a world where 2217.74s - 2222.74s | the community works to make products so secure that cybersecurity goes away. 2222.74s - 2227.42s | I mean, the reason we have the cybersecurity industry is because technology vendors have 2227.42s - 2235.14s | been able to create flawed, defective, insecure products, or defective for decades, right? 2235.30s - 2240.94s | Because it's been all about incentives have been speed to market and features, not security. 2240.94s - 2249.02s | So if we actually achieve secure by design, I mean, I will be like doing the Snoopy dance 2249.02s - 2250.30s | everywhere, right? 2250.30s - 2256.34s | Because that will be a world where ransomware is a shocking anomaly and where damaging software 2256.34s - 2259.70s | vulnerabilities are as infrequent as plane crashes. 2259.70s - 2265.82s | Now, does that mean that vulnerabilities or defects will go away completely? 2265.82s - 2267.38s | No, of course not. 2267.38s - 2272.54s | I fundamentally believe you can dramatically drive down the number of exploitable defects, 2272.54s - 2279.46s | but there will still be room for the research community, the hacking community. 2279.46s - 2285.46s | I mean, this community is actually responsible for making us all better,


chunk_id: 180_chunk_40
chunk_text:
| the community works to make products so secure that cybersecurity goes away. 2222.74s - 2227.42s | I mean, the reason we have the cybersecurity industry is because technology vendors have 2227.42s - 2235.14s | been able to create flawed, defective, insecure products, or defective for decades, right? 2235.30s - 2240.94s | Because it's been all about incentives have been speed to market and features, not security. 2240.94s - 2249.02s | So if we actually achieve secure by design, I mean, I will be like doing the Snoopy dance 2249.02s - 2250.30s | everywhere, right? 2250.30s - 2256.34s | Because that will be a world where ransomware is a shocking anomaly and where damaging software 2256.34s - 2259.70s | vulnerabilities are as infrequent as plane crashes. 2259.70s - 2265.82s | Now, does that mean that vulnerabilities or defects will go away completely? 2265.82s - 2267.38s | No, of course not. 2267.38s - 2272.54s | I fundamentally believe you can dramatically drive down the number of exploitable defects, 2272.54s - 2279.46s | but there will still be room for the research community, the hacking community. 2279.46s - 2285.46s | I mean, this community is actually responsible for making us all better, right? 2285.46s - 2289.62s | We run the coordinated vulnerability disclosure program for the US government. 2289.62s - 2297.54s | So we work with researchers all the time and we have an enormous respect and admiration 2297.54s - 2302.14s | for folks and we intermediate between hackers and product owners. 2302.14s - 2307.78s | And I don't think that will go away completely, but we do want to live in a world where the 2307.78s - 2311.70s | number of defects in our products is dramatically lowered. 2311.70s - 2316.18s | I mean, that will be a better world for all of us where we don't have to worry about our 2316.18s - 2320.94s | parents constantly having to deal with malware and all of this. 2320.94s - 2324.22s | So there will always be a role for hackers. 2324.22s - 2325.22s | Yeah. 2325.22s - 2332.10s | And even if every bit of code in the universe is memory safe, temporally, spatially memory 2332.10s - 2336.66s | safe, there's always going to be business logic flaws. 2336.66s - 2340.74s | There's so many other categories, but that's what you want to do, right? 2340.74s - 2341.74s | You want


chunk_id: 180_chunk_41
chunk_text:
right? 2285.46s - 2289.62s | We run the coordinated vulnerability disclosure program for the US government. 2289.62s - 2297.54s | So we work with researchers all the time and we have an enormous respect and admiration 2297.54s - 2302.14s | for folks and we intermediate between hackers and product owners. 2302.14s - 2307.78s | And I don't think that will go away completely, but we do want to live in a world where the 2307.78s - 2311.70s | number of defects in our products is dramatically lowered. 2311.70s - 2316.18s | I mean, that will be a better world for all of us where we don't have to worry about our 2316.18s - 2320.94s | parents constantly having to deal with malware and all of this. 2320.94s - 2324.22s | So there will always be a role for hackers. 2324.22s - 2325.22s | Yeah. 2325.22s - 2332.10s | And even if every bit of code in the universe is memory safe, temporally, spatially memory 2332.10s - 2336.66s | safe, there's always going to be business logic flaws. 2336.66s - 2340.74s | There's so many other categories, but that's what you want to do, right? 2340.74s - 2341.74s | You want to push them up the stack. 2341.74s - 2343.34s | You want the difficulty to become harder. 2343.34s - 2344.98s | You don't want a mass exploit. 2344.98s - 2349.30s | We want you to have to spend all the time in the world understanding one business system 2349.30s - 2354.42s | to exploit some business logic flaw in one thing instead of a single one-off that can 2354.42s - 2356.38s | devastate an entire landscape. 2356.38s - 2360.34s | Create massive friction for attackers, for squandering. 2360.34s - 2362.02s | And you want to make it be more noisy. 2362.02s - 2365.26s | So when they do do something, it's more visible. 2365.26s - 2388.76s | And so, okay. 2388.76s - 2397.27s | Thanks dude. 2397.27s - 2398.87s | Well thank you. 2398.87s - 2417.58s | Under twin powers, activate. 2417.58s - 2419.42s | That AI will unleash, you mean? 2419.42s - 2432.01s | Threat of AI. 2432.01s - 2433.01s | Threat of AI. 2433.01s - 2434.01s | Yeah, I'll tell you. 2434.01s - 2440.69s | So the interesting thing is, it's really, we might have to drink to the end of CAPTCHA, 2440.69s - 2441.69s | right? 2441.69s


chunk_id: 180_chunk_42
chunk_text:
to push them up the stack. 2341.74s - 2343.34s | You want the difficulty to become harder. 2343.34s - 2344.98s | You don't want a mass exploit. 2344.98s - 2349.30s | We want you to have to spend all the time in the world understanding one business system 2349.30s - 2354.42s | to exploit some business logic flaw in one thing instead of a single one-off that can 2354.42s - 2356.38s | devastate an entire landscape. 2356.38s - 2360.34s | Create massive friction for attackers, for squandering. 2360.34s - 2362.02s | And you want to make it be more noisy. 2362.02s - 2365.26s | So when they do do something, it's more visible. 2365.26s - 2388.76s | And so, okay. 2388.76s - 2397.27s | Thanks dude. 2397.27s - 2398.87s | Well thank you. 2398.87s - 2417.58s | Under twin powers, activate. 2417.58s - 2419.42s | That AI will unleash, you mean? 2419.42s - 2432.01s | Threat of AI. 2432.01s - 2433.01s | Threat of AI. 2433.01s - 2434.01s | Yeah, I'll tell you. 2434.01s - 2440.69s | So the interesting thing is, it's really, we might have to drink to the end of CAPTCHA, 2440.69s - 2441.69s | right? 2441.69s - 2443.65s | I mean, if AI is that good, right? 2443.65s - 2449.09s | I mean, so for example, we run this, you caught on to the fact we're really big into community. 2449.09s - 2454.89s | And so DEF CON, a couple of years ago, we started the mastodon server, DEF CON.social. 2454.93s - 2460.25s | And before Elon bought Twitter, we were kind of hedging our bets. 2460.25s - 2464.29s | So we started to build our mastodon server, just in case things go south. 2464.29s - 2467.93s | Things went south, mastodon. 2467.93s - 2469.97s | And so people are signing up to the service. 2469.97s - 2472.93s | And now you put in a CAPTCHA. 2472.93s - 2474.37s | And so we use H-CAPTCHA. 2474.37s - 2478.77s | It's the more friendly CAPTCHA, more privacy respecting CAPTCHA. 2478.77s - 2484.25s | Well then you start paying attention, like, does this CAPTCHA actually prevent spam signups? 2484.25s - 2487.93s | And it's supposedly a very performant CAPTCHA. 2487.93s - 2497.73s | And you start reading academic studies, H-CAPTCHA can be bypassed 98% of the time. 2497.73s - 2501.77s | But the competitors are 99% of the


chunk_id: 180_chunk_43
chunk_text:
- 2443.65s | I mean, if AI is that good, right? 2443.65s - 2449.09s | I mean, so for example, we run this, you caught on to the fact we're really big into community. 2449.09s - 2454.89s | And so DEF CON, a couple of years ago, we started the mastodon server, DEF CON.social. 2454.93s - 2460.25s | And before Elon bought Twitter, we were kind of hedging our bets. 2460.25s - 2464.29s | So we started to build our mastodon server, just in case things go south. 2464.29s - 2467.93s | Things went south, mastodon. 2467.93s - 2469.97s | And so people are signing up to the service. 2469.97s - 2472.93s | And now you put in a CAPTCHA. 2472.93s - 2474.37s | And so we use H-CAPTCHA. 2474.37s - 2478.77s | It's the more friendly CAPTCHA, more privacy respecting CAPTCHA. 2478.77s - 2484.25s | Well then you start paying attention, like, does this CAPTCHA actually prevent spam signups? 2484.25s - 2487.93s | And it's supposedly a very performant CAPTCHA. 2487.93s - 2497.73s | And you start reading academic studies, H-CAPTCHA can be bypassed 98% of the time. 2497.73s - 2501.77s | But the competitors are 99% of the time. 2501.77s - 2503.57s | Do you know who created CAPTCHA? 2503.57s - 2506.77s | We're 50% more effective. 2506.77s - 2509.69s | Do you know where CAPTCHA was created? 2509.69s - 2510.69s | Do you know who created it? 2510.69s - 2511.69s | Who? 2511.69s - 2512.69s | It was at Carnegie Mellon. 2512.69s - 2513.69s | Carnegie Mellon, yeah. 2514.13s - 2517.53s | And that's why we did our, well not why, but one of the cool reasons we did our secure 2517.53s - 2518.53s | by design launch. 2518.53s - 2520.77s | It was at Carnegie Mellon. 2520.77s - 2525.49s | So then you're like, okay, well, that's the defeat rate. 2525.49s - 2527.37s | What's the human rate? 2527.37s - 2533.49s | Humans can bypass CAPTCHA 78% of the time. 2533.49s - 2539.05s | So it's like, well, if you don't make a mistake, you're probably a robot. 2539.05s - 2540.49s | So you have to make some mistakes. 2540.49s - 2542.73s | And so that's done. 2542.77s - 2546.21s | I don't see CAPTCHAs, right? 2546.21s - 2551.62s | And it's sad because, oh no, we're defenseless. 2551.62s - 2555.34s | But we better own


chunk_id: 180_chunk_44
chunk_text:
time. 2501.77s - 2503.57s | Do you know who created CAPTCHA? 2503.57s - 2506.77s | We're 50% more effective. 2506.77s - 2509.69s | Do you know where CAPTCHA was created? 2509.69s - 2510.69s | Do you know who created it? 2510.69s - 2511.69s | Who? 2511.69s - 2512.69s | It was at Carnegie Mellon. 2512.69s - 2513.69s | Carnegie Mellon, yeah. 2514.13s - 2517.53s | And that's why we did our, well not why, but one of the cool reasons we did our secure 2517.53s - 2518.53s | by design launch. 2518.53s - 2520.77s | It was at Carnegie Mellon. 2520.77s - 2525.49s | So then you're like, okay, well, that's the defeat rate. 2525.49s - 2527.37s | What's the human rate? 2527.37s - 2533.49s | Humans can bypass CAPTCHA 78% of the time. 2533.49s - 2539.05s | So it's like, well, if you don't make a mistake, you're probably a robot. 2539.05s - 2540.49s | So you have to make some mistakes. 2540.49s - 2542.73s | And so that's done. 2542.77s - 2546.21s | I don't see CAPTCHAs, right? 2546.21s - 2551.62s | And it's sad because, oh no, we're defenseless. 2551.62s - 2555.34s | But we better own up to it really quick because pretending that we're not defenseless, that's 2555.34s - 2556.34s | not going to work. 2556.34s - 2557.34s | Right? 2557.34s - 2560.26s | And so it feels like AI is going to fundamentally change some of this stuff. 2560.26s - 2566.66s | Like one of the questions is, okay, well, almost perfect voice duplication for these 2566.66s - 2569.42s | CEO takeover voice attacks. 2569.42s - 2570.42s | Yeah. 2570.42s - 2571.42s | Okay. 2571.42s - 2572.90s | Well, that's reality. 2572.90s - 2574.90s | We can't pretend we're going back. 2574.90s - 2577.34s | So no more voice authentication. 2577.34s - 2578.34s | Okay. 2578.34s - 2581.42s | But we better own up to that really quick. 2581.42s - 2582.42s | Right? 2582.42s - 2583.42s | Well, yeah. 2583.42s - 2584.42s | I mean, I'd say a couple of things. 2584.42s - 2587.74s | Like I am a tech optimist. 2587.74s - 2590.14s | I'm an optimist in general, and I'm a tech optimist. 2590.14s - 2592.90s | I wouldn't be in this business if I weren't. 2592.90s - 2598.74s | We just named a chief AI officer, Lisa Einstein, who kicked some


chunk_id: 180_chunk_45
chunk_text:
up to it really quick because pretending that we're not defenseless, that's 2555.34s - 2556.34s | not going to work. 2556.34s - 2557.34s | Right? 2557.34s - 2560.26s | And so it feels like AI is going to fundamentally change some of this stuff. 2560.26s - 2566.66s | Like one of the questions is, okay, well, almost perfect voice duplication for these 2566.66s - 2569.42s | CEO takeover voice attacks. 2569.42s - 2570.42s | Yeah. 2570.42s - 2571.42s | Okay. 2571.42s - 2572.90s | Well, that's reality. 2572.90s - 2574.90s | We can't pretend we're going back. 2574.90s - 2577.34s | So no more voice authentication. 2577.34s - 2578.34s | Okay. 2578.34s - 2581.42s | But we better own up to that really quick. 2581.42s - 2582.42s | Right? 2582.42s - 2583.42s | Well, yeah. 2583.42s - 2584.42s | I mean, I'd say a couple of things. 2584.42s - 2587.74s | Like I am a tech optimist. 2587.74s - 2590.14s | I'm an optimist in general, and I'm a tech optimist. 2590.14s - 2592.90s | I wouldn't be in this business if I weren't. 2592.90s - 2598.74s | We just named a chief AI officer, Lisa Einstein, who kicked some serious ass. 2598.74s - 2599.74s | I'm really proud of her. 2599.74s - 2600.74s | Lisa Einstein, please stand up. 2600.74s - 2601.74s | Chief AI officer. 2601.74s - 2602.74s | Lisa. 2602.74s - 2603.74s | Rock on. 2603.74s - 2604.74s | Yay. 2604.74s - 2612.74s | Because we want to ensure that we are leveraging these capabilities for cyber defense, but 2612.74s - 2618.30s | we also want to make sure that we are reducing risk from these capabilities to critical infrastructure. 2618.30s - 2621.82s | So we put out a roadmap with a lot of the work that we're doing. 2621.82s - 2629.54s | We put out a guide specific on secure by design for AI with international partners, federal 2629.54s - 2630.54s | partners. 2631.22s - 2635.94s | As we've been talking about software, like AI, the same rules apply to AI. 2635.94s - 2642.82s | You have to consider security first, because these are very powerful, fast-moving capabilities, 2642.82s - 2644.70s | but we don't want to be scared of them. 2644.70s - 2647.18s | We want to be able to optimize the use of them. 2647.18s - 2652.18s | And so we're excited about the


chunk_id: 180_chunk_46
chunk_text:
serious ass. 2598.74s - 2599.74s | I'm really proud of her. 2599.74s - 2600.74s | Lisa Einstein, please stand up. 2600.74s - 2601.74s | Chief AI officer. 2601.74s - 2602.74s | Lisa. 2602.74s - 2603.74s | Rock on. 2603.74s - 2604.74s | Yay. 2604.74s - 2612.74s | Because we want to ensure that we are leveraging these capabilities for cyber defense, but 2612.74s - 2618.30s | we also want to make sure that we are reducing risk from these capabilities to critical infrastructure. 2618.30s - 2621.82s | So we put out a roadmap with a lot of the work that we're doing. 2621.82s - 2629.54s | We put out a guide specific on secure by design for AI with international partners, federal 2629.54s - 2630.54s | partners. 2631.22s - 2635.94s | As we've been talking about software, like AI, the same rules apply to AI. 2635.94s - 2642.82s | You have to consider security first, because these are very powerful, fast-moving capabilities, 2642.82s - 2644.70s | but we don't want to be scared of them. 2644.70s - 2647.18s | We want to be able to optimize the use of them. 2647.18s - 2652.18s | And so we're excited about the power of it. 2652.18s - 2657.02s | There's a lot of hype here, so we don't want to get sucked into the hype, but we were at 2657.02s - 2658.02s | the AICC. 2659.02s - 2661.94s | I think you guys just heard from those folks yesterday. 2661.94s - 2665.58s | And so if there are things that can be done with some of these capabilities to find and 2665.58s - 2672.58s | fix vulnerabilities, the thing that I am very excited about is the ability to use AI to 2672.58s - 2677.54s | refactor code from memory unsafe to memory safe. 2677.54s - 2683.38s | Think about how that could have a transformative impact on some of the defects that we have 2683.38s - 2685.10s | to deal with on a daily basis. 2685.78s - 2690.46s | I think we should get excited about it, but I don't think we should get Skynet scared 2690.46s - 2691.46s | about it. 2691.46s - 2697.42s | The only thing I'd say is, I spent a lot of my life doing counterterrorism. 2697.42s - 2705.18s | I was in Iraq twice, Afghanistan, and we used to talk about Al-Qaeda's chief bomb maker


chunk_id: 180_chunk_47
chunk_text:
power of it. 2652.18s - 2657.02s | There's a lot of hype here, so we don't want to get sucked into the hype, but we were at 2657.02s - 2658.02s | the AICC. 2659.02s - 2661.94s | I think you guys just heard from those folks yesterday. 2661.94s - 2665.58s | And so if there are things that can be done with some of these capabilities to find and 2665.58s - 2672.58s | fix vulnerabilities, the thing that I am very excited about is the ability to use AI to 2672.58s - 2677.54s | refactor code from memory unsafe to memory safe. 2677.54s - 2683.38s | Think about how that could have a transformative impact on some of the defects that we have 2683.38s - 2685.10s | to deal with on a daily basis. 2685.78s - 2690.46s | I think we should get excited about it, but I don't think we should get Skynet scared 2690.46s - 2691.46s | about it. 2691.46s - 2697.42s | The only thing I'd say is, I spent a lot of my life doing counterterrorism. 2697.42s - 2705.18s | I was in Iraq twice, Afghanistan, and we used to talk about Al-Qaeda's chief bomb maker 2705.18s - 2711.98s | a lot, and now you think about Al-Qaeda's chief AI officer. 2711.98s - 2713.66s | That ain't good. 2713.66s - 2717.90s | The pictures of the data centers in the tunnels. 2717.90s - 2719.30s | That's just ungood. 2719.30s - 2725.90s | And so we want to make sure that these capabilities are protected from being used by terrorists 2725.90s - 2729.74s | and criminals and rogue nations to do real harm. 2729.74s - 2734.14s | Okay, we only have time for one question. 2734.14s - 2735.26s | I'm sorry. 2735.26s - 2736.62s | So you've got it. 2736.62s - 2738.94s | Hopefully it's... 2738.94s - 2739.94s | Go for it. 2739.94s - 2743.46s | Better be the greatest question ever. 2743.46s - 2744.46s | No pressure. 2744.46s - 2745.46s | No pressure. 2745.46s - 2746.46s | No pressure. 2746.46s - 2749.38s | No pressure. 2749.38s - 2750.38s | Closer to the microphone. 2750.38s - 2751.38s | Closer. 2751.38s - 2752.38s | Closer to the microphone. 2752.38s - 2765.70s | Right. 2765.70s - 2770.97s | Okay, so the question is around cyber liability. 2770.97s - 2775.97s | Do you think it's going to be hard to


chunk_id: 180_chunk_48
chunk_text:
2705.18s - 2711.98s | a lot, and now you think about Al-Qaeda's chief AI officer. 2711.98s - 2713.66s | That ain't good. 2713.66s - 2717.90s | The pictures of the data centers in the tunnels. 2717.90s - 2719.30s | That's just ungood. 2719.30s - 2725.90s | And so we want to make sure that these capabilities are protected from being used by terrorists 2725.90s - 2729.74s | and criminals and rogue nations to do real harm. 2729.74s - 2734.14s | Okay, we only have time for one question. 2734.14s - 2735.26s | I'm sorry. 2735.26s - 2736.62s | So you've got it. 2736.62s - 2738.94s | Hopefully it's... 2738.94s - 2739.94s | Go for it. 2739.94s - 2743.46s | Better be the greatest question ever. 2743.46s - 2744.46s | No pressure. 2744.46s - 2745.46s | No pressure. 2745.46s - 2746.46s | No pressure. 2746.46s - 2749.38s | No pressure. 2749.38s - 2750.38s | Closer to the microphone. 2750.38s - 2751.38s | Closer. 2751.38s - 2752.38s | Closer to the microphone. 2752.38s - 2765.70s | Right. 2765.70s - 2770.97s | Okay, so the question is around cyber liability. 2770.97s - 2775.97s | Do you think it's going to be hard to do because of all the laws around liability? 2775.97s - 2778.97s | Yes, I do. 2778.97s - 2789.16s | Because it's what? 2789.16s - 2790.16s | Oh. 2790.16s - 2791.16s | Oh, yeah. 2791.16s - 2792.16s | No. 2792.16s - 2801.04s | It's an interesting issue when you think about it because a lot of the incidents that happen, 2801.04s - 2805.08s | we very much focus on the proximate cause, not the root cause. 2805.08s - 2806.80s | So you're exactly right. 2806.80s - 2811.24s | I mean, that's the issues around human error, like we had a ransomware attack because somebody 2811.24s - 2815.80s | downloaded a malicious file or got phished into giving up their password, right? 2815.80s - 2820.72s | So we always focus on the proximate cause, not the root cause. 2820.72s - 2826.04s | And yeah, to get anything done like this is hard, and I always worry that it's going 2826.04s - 2831.72s | to be a major devastating attack that actually gets some sort of legislation. 2831.72s - 2839.20s | I mean, I think I would just give you my perspective from working closely with members of Congress. 2839.20s - 2840.20s |


chunk_id: 180_chunk_49
chunk_text:
do because of all the laws around liability? 2775.97s - 2778.97s | Yes, I do. 2778.97s - 2789.16s | Because it's what? 2789.16s - 2790.16s | Oh. 2790.16s - 2791.16s | Oh, yeah. 2791.16s - 2792.16s | No. 2792.16s - 2801.04s | It's an interesting issue when you think about it because a lot of the incidents that happen, 2801.04s - 2805.08s | we very much focus on the proximate cause, not the root cause. 2805.08s - 2806.80s | So you're exactly right. 2806.80s - 2811.24s | I mean, that's the issues around human error, like we had a ransomware attack because somebody 2811.24s - 2815.80s | downloaded a malicious file or got phished into giving up their password, right? 2815.80s - 2820.72s | So we always focus on the proximate cause, not the root cause. 2820.72s - 2826.04s | And yeah, to get anything done like this is hard, and I always worry that it's going 2826.04s - 2831.72s | to be a major devastating attack that actually gets some sort of legislation. 2831.72s - 2839.20s | I mean, I think I would just give you my perspective from working closely with members of Congress. 2839.20s - 2840.20s | They get this. 2840.20s - 2841.20s | They understand. 2841.20s - 2846.04s | I do think the report that we released, the Cyber Safety Review Board report, caught a 2846.04s - 2851.68s | lot of attention in terms of how important a culture of security is, how important it 2851.68s - 2858.88s | is for a vendor to take accountability and responsibility for producing secure software. 2858.88s - 2863.56s | So I don't think it's impossible, but it will take a lot of work to do. 2863.56s - 2868.16s | I do think that is something, you know, this is, as Jeff was saying, there's all kinds 2868.16s - 2871.56s | of levers that can lead us to a more secure ecosystem. 2871.56s - 2879.21s | I do think that is a very important one because it leads to a product differentiator. 2879.21s - 2880.21s | Thank you for the question. 2880.21s - 2881.53s | All right, everyone. 2881.53s - 2882.53s | Let's give it up. 2882.53s - 2883.53s | Thank you for being here. 2883.53s - 2884.53s | Thanks, everybody. 2884.53s - 2885.53s | Love you. 2885.53s - 2886.53s | Bye. 2886.53s - 2887.53s | Bye. 2887.53s - 2888.53s


chunk_id: 180_chunk_50
chunk_text:
They get this. 2840.20s - 2841.20s | They understand. 2841.20s - 2846.04s | I do think the report that we released, the Cyber Safety Review Board report, caught a 2846.04s - 2851.68s | lot of attention in terms of how important a culture of security is, how important it 2851.68s - 2858.88s | is for a vendor to take accountability and responsibility for producing secure software. 2858.88s - 2863.56s | So I don't think it's impossible, but it will take a lot of work to do. 2863.56s - 2868.16s | I do think that is something, you know, this is, as Jeff was saying, there's all kinds 2868.16s - 2871.56s | of levers that can lead us to a more secure ecosystem. 2871.56s - 2879.21s | I do think that is a very important one because it leads to a product differentiator. 2879.21s - 2880.21s | Thank you for the question. 2880.21s - 2881.53s | All right, everyone. 2881.53s - 2882.53s | Let's give it up. 2882.53s - 2883.53s | Thank you for being here. 2883.53s - 2884.53s | Thanks, everybody. 2884.53s - 2885.53s | Love you. 2885.53s - 2886.53s | Bye. 2886.53s - 2887.53s | Bye. 2887.53s - 2888.53s | Bye. 2888.53s - 2889.53s | Bye. 2889.53s - 2890.03s | Bye.


chunk_id: 181_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=7k3zOylPKbM", "title": "DEF CON 32 - AWS CloudQuarry: Digging for secrets in public AMIs - Eduard Agavriloae, Matei Josephs", "description": "Join us as we unravel another story of public resources from AWS, digging in 3.1 million AMIs for secrets. Beyond the findings, we'll delve into the ominous connection between exfiltrated AWS access credentials from these AMIs and the heightened risk of AWS account takeover. This talk will highlight key methodologies, tools, and lessons learned, emphasizing the critical need for robust security measures in the cloud to prevent both data exposure and potential account compromise.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2372, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.43s - 8.05s | This text was transcribed using whisper model: large-v2 Hello DEF CON. So I'm very happy to be here. This has been a dream of mine for uh many 8.05s - 16.05s | many years and uh thanks for being part of it. This research is about a cool story about 16.05s - 23.79s | um secrets in public cloud resources and um you know uh who thinks we will never run out 23.79s - 32.73s | of customers public public sharing secrets in public cloud resources. Yeah I think I think we 32.73s - 39.53s | will never run out of that. And uh my name is Edward Agaduluia. I was a senior penetration 39.53s - 45.25s | tester at KPMG Romania while I've done uh this research. Uh huge shout out to them for 45.25s - 50.81s | supporting the the the research and uh trusting this idea. Uh I was also a contractor at 50.81s - 56.31s | Syncubes uh I I mean I still am and I'm doing offensive cloud uh projects there. I also 56.31s - 66.09s | work one month at CrowdStrike but I resigned on Friday so so I'm open for new opportunities 66.09s - 71.09s | and um yeah I'm trying to do some uh cloud security research. Now I started um a cloud 75.09s - 80.09s | configuration review uh for a customer of uh Syncubes and um I got the initial access um and 81.09s - 86.09s | I started using uh Scout Suite as I uh uh always uh as I always do. And um I checked the 92.73s - 99.33s | report. I saw the S3 findings, the CloudTrail findings, the YAM findings and when I looked at


chunk_id: 181_chunk_1
chunk_text:
I think we 32.73s - 39.53s | will never run out of that. And uh my name is Edward Agaduluia. I was a senior penetration 39.53s - 45.25s | tester at KPMG Romania while I've done uh this research. Uh huge shout out to them for 45.25s - 50.81s | supporting the the the research and uh trusting this idea. Uh I was also a contractor at 50.81s - 56.31s | Syncubes uh I I mean I still am and I'm doing offensive cloud uh projects there. I also 56.31s - 66.09s | work one month at CrowdStrike but I resigned on Friday so so I'm open for new opportunities 66.09s - 71.09s | and um yeah I'm trying to do some uh cloud security research. Now I started um a cloud 75.09s - 80.09s | configuration review uh for a customer of uh Syncubes and um I got the initial access um and 81.09s - 86.09s | I started using uh Scout Suite as I uh uh always uh as I always do. And um I checked the 92.73s - 99.33s | report. I saw the S3 findings, the CloudTrail findings, the YAM findings and when I looked at 99.33s - 104.35s | the EC2 dashboard I saw for the first time the critical finding AMI is set to public and who 104.71s - 109.71s | knows what an AMI is? Ok cool and um who used at least once an EC2 instance? Ok so if you 116.25s - 122.03s | used an EC2 instance you kind of know what an AMI is because every time you start a an EC2 122.03s - 128.73s | instance you are using an AMI. It's like a snapshot of a virtual machine and you can 128.75s - 133.75s | pre-configure an an AMI to contain your applications, secrets, um so to have a baseline 137.33s - 142.47s | right? And then you can start new EC2 instances starting from this AMI. And you have AWS 142.47s - 148.07s | Marketplace AMI that are official and from trusted vendors which are the recommended ones 148.07s - 154.45s | you can use. And you can also have community AMIs that are published by anyone. And you 154.47s - 159.91s | have to be careful with uh with them because if you don't trust the publisher you might have 159.91s - 164.91s | some backdoors


chunk_id: 181_chunk_2
chunk_text:
99.33s - 104.35s | the EC2 dashboard I saw for the first time the critical finding AMI is set to public and who 104.71s - 109.71s | knows what an AMI is? Ok cool and um who used at least once an EC2 instance? Ok so if you 116.25s - 122.03s | used an EC2 instance you kind of know what an AMI is because every time you start a an EC2 122.03s - 128.73s | instance you are using an AMI. It's like a snapshot of a virtual machine and you can 128.75s - 133.75s | pre-configure an an AMI to contain your applications, secrets, um so to have a baseline 137.33s - 142.47s | right? And then you can start new EC2 instances starting from this AMI. And you have AWS 142.47s - 148.07s | Marketplace AMI that are official and from trusted vendors which are the recommended ones 148.07s - 154.45s | you can use. And you can also have community AMIs that are published by anyone. And you 154.47s - 159.91s | have to be careful with uh with them because if you don't trust the publisher you might have 159.91s - 164.91s | some backdoors malware and so on. But in any case the thing is that an AMI can be public or 168.09s - 173.05s | private and by default they are private and it's actually hard to make one public. And I 173.05s - 178.69s | think you can see where I'm going with this. The issue is that they can be public and this 178.71s - 183.71s | customer had 5 public AMIs um exposed for multiple years and when I asked them hey can I 187.01s - 192.65s | take a look uh inside the AMIs to to see what's inside of them? And um they were like no and so 192.65s - 198.93s | I I regretted I even asked. But I got this question what was inside the AMIs? And this 198.93s - 205.33s | actually gave me the research idea if there are other companies with secrets in public 205.51s - 210.51s | AMIs out there. So um first we wanted to do this research so bad that we haven't checked any 215.81s - 221.89s | previous work but when we are when we were in the middle of it we discovered the work done 221.89s - 227.99s


chunk_id: 181_chunk_3
chunk_text:
malware and so on. But in any case the thing is that an AMI can be public or 168.09s - 173.05s | private and by default they are private and it's actually hard to make one public. And I 173.05s - 178.69s | think you can see where I'm going with this. The issue is that they can be public and this 178.71s - 183.71s | customer had 5 public AMIs um exposed for multiple years and when I asked them hey can I 187.01s - 192.65s | take a look uh inside the AMIs to to see what's inside of them? And um they were like no and so 192.65s - 198.93s | I I regretted I even asked. But I got this question what was inside the AMIs? And this 198.93s - 205.33s | actually gave me the research idea if there are other companies with secrets in public 205.51s - 210.51s | AMIs out there. So um first we wanted to do this research so bad that we haven't checked any 215.81s - 221.89s | previous work but when we are when we were in the middle of it we discovered the work done 221.89s - 227.99s | by Dolev Farhi who scanned based on keywords AMIs in a single AWS region which was was 227.99s - 234.13s | fine but it was not enough uh from our perspective. And also the work done by Ben Morris 234.17s - 240.17s | who searched secrets in public ABS snapshots but we will see shortly that that there is very 240.17s - 245.17s | little overlap between his work. And funny story um last days um I was talking about uh the 247.61s - 252.75s | research with someone and he was like hey you know who did something similar? Um he searched 252.75s - 257.39s | public ABS snapshots uh he's Ben and he pointed at someone and it was Ben Morris and he was 257.43s - 263.94s | like yeah and sorry. So yeah we um I've met mo- Ben Morris um I've been saying his name a 267.14s - 272.14s | lot um uh rehearsing the presentation it was uh it was a pleasure to to meet him in person 274.62s - 280.96s | he's a lovely guy. Now uh we set some goals for the research to dig for secrets in every 280.96s - 286.66s


chunk_id: 181_chunk_4
chunk_text:
| by Dolev Farhi who scanned based on keywords AMIs in a single AWS region which was was 227.99s - 234.13s | fine but it was not enough uh from our perspective. And also the work done by Ben Morris 234.17s - 240.17s | who searched secrets in public ABS snapshots but we will see shortly that that there is very 240.17s - 245.17s | little overlap between his work. And funny story um last days um I was talking about uh the 247.61s - 252.75s | research with someone and he was like hey you know who did something similar? Um he searched 252.75s - 257.39s | public ABS snapshots uh he's Ben and he pointed at someone and it was Ben Morris and he was 257.43s - 263.94s | like yeah and sorry. So yeah we um I've met mo- Ben Morris um I've been saying his name a 267.14s - 272.14s | lot um uh rehearsing the presentation it was uh it was a pleasure to to meet him in person 274.62s - 280.96s | he's a lovely guy. Now uh we set some goals for the research to dig for secrets in every 280.96s - 286.66s | public AMI across all AWS regions to have some fun and do some responsible disclosure. We 286.66s - 292.26s | also had a hidden goal to get some bounties and uh my colleague Matei will tell you more 292.26s - 299.18s | about it. Starting the research we had to collect every public AMI across all A- all AWS 299.18s - 305.92s | regions and to do that you have to um you have to use the CLI because AWS automatically 305.92s - 311.68s | deprecates images after two years uh after they were published. And if they are 311.68s - 317.02s | deprecated you can find them in the in the web portal. Also customers can deprecate their 317.04s - 322.12s | images whenever they want. So we have to uh you have to use the CLI and specify the flag 322.12s - 328.16s | include deprecated to make sure you get all the AMIs. And we did that and we got 3.1 328.16s - 333.16s | million AMIs and um we were sure that this was too much for us to scan all of them and we 335.26s - 340.26s | started asking if we can remove


chunk_id: 181_chunk_5
chunk_text:
| public AMI across all AWS regions to have some fun and do some responsible disclosure. We 286.66s - 292.26s | also had a hidden goal to get some bounties and uh my colleague Matei will tell you more 292.26s - 299.18s | about it. Starting the research we had to collect every public AMI across all A- all AWS 299.18s - 305.92s | regions and to do that you have to um you have to use the CLI because AWS automatically 305.92s - 311.68s | deprecates images after two years uh after they were published. And if they are 311.68s - 317.02s | deprecated you can find them in the in the web portal. Also customers can deprecate their 317.04s - 322.12s | images whenever they want. So we have to uh you have to use the CLI and specify the flag 322.12s - 328.16s | include deprecated to make sure you get all the AMIs. And we did that and we got 3.1 328.16s - 333.16s | million AMIs and um we were sure that this was too much for us to scan all of them and we 335.26s - 340.26s | started asking if we can remove AMIs based on the chances of having secrets. So we removed 341.02s - 346.02s | AMIs for from marketplace that left us with 1.5 million. We removed AMIs owned by AWS that 349.62s - 355.96s | were not in the marketplace that left us with 1 million and we went further and uh we 355.96s - 362.00s | removed the owners that had more than 50 public AMIs because honestly if you are a company 362.00s - 367.64s | and you have more than 50 public AMIs security wise you are in a point of no return or you 367.66s - 373.90s | are or you are uh an official publisher an unofficial publisher right? And that left us 373.90s - 378.90s | with 27,000 AMIs. Now we did some sanity filtering because some AMIs had 17 volumes or 382.84s - 389.12s | volumes uh as big as 20 terabytes. Obviously I'm very curious what's inside of them but for 389.12s - 396.12s | our budget we had to remove them uh and that left us with 26,000 AMIs. Now the distribution 396.14s - 401.14s | uh from our list looks like this. Obviously the most AMIs were in U.S.


chunk_id: 181_chunk_6
chunk_text:
AMIs based on the chances of having secrets. So we removed 341.02s - 346.02s | AMIs for from marketplace that left us with 1.5 million. We removed AMIs owned by AWS that 349.62s - 355.96s | were not in the marketplace that left us with 1 million and we went further and uh we 355.96s - 362.00s | removed the owners that had more than 50 public AMIs because honestly if you are a company 362.00s - 367.64s | and you have more than 50 public AMIs security wise you are in a point of no return or you 367.66s - 373.90s | are or you are uh an official publisher an unofficial publisher right? And that left us 373.90s - 378.90s | with 27,000 AMIs. Now we did some sanity filtering because some AMIs had 17 volumes or 382.84s - 389.12s | volumes uh as big as 20 terabytes. Obviously I'm very curious what's inside of them but for 389.12s - 396.12s | our budget we had to remove them uh and that left us with 26,000 AMIs. Now the distribution 396.14s - 401.14s | uh from our list looks like this. Obviously the most AMIs were in U.S. East 1 and um region 403.62s - 409.72s | with the smallest number of AMIs was IL Central 1, Israel Central 1 with only 30 public 409.72s - 414.72s | AMIs after uh after our filtering. And when I'm saying that we collected the AMIs this is 418.46s - 423.46s | what I mean by it. So we got the JSON definition for each AMI and uh you have a lot of 423.58s - 430.28s | information like the ones highlighted, the image ID, the information about the snapshot, 430.28s - 436.12s | but you also have other important information like description, title and the owner of the 436.12s - 441.12s | AMI and we'll see how we can use that uh shortly. Now that we had our list we need a way to 444.10s - 449.80s | access the contents of the AMI and this should be time and cost effective, automated and as 449.84s - 456.32s | reliable as possible. And we looked for various methods, some of them might work in certain 456.32s - 461.32s | situations but only the fourth option was the right one for us. So first we tried to copy the 463.62s -


chunk_id: 181_chunk_7
chunk_text:
East 1 and um region 403.62s - 409.72s | with the smallest number of AMIs was IL Central 1, Israel Central 1 with only 30 public 409.72s - 414.72s | AMIs after uh after our filtering. And when I'm saying that we collected the AMIs this is 418.46s - 423.46s | what I mean by it. So we got the JSON definition for each AMI and uh you have a lot of 423.58s - 430.28s | information like the ones highlighted, the image ID, the information about the snapshot, 430.28s - 436.12s | but you also have other important information like description, title and the owner of the 436.12s - 441.12s | AMI and we'll see how we can use that uh shortly. Now that we had our list we need a way to 444.10s - 449.80s | access the contents of the AMI and this should be time and cost effective, automated and as 449.84s - 456.32s | reliable as possible. And we looked for various methods, some of them might work in certain 456.32s - 461.32s | situations but only the fourth option was the right one for us. So first we tried to copy the 463.62s - 468.62s | snapshot uh of the AMI in our own AWS account and download it but even if the AMI is 471.40s - 477.00s | public the ABS snapshot is not by default and that's why it's very little overlap between our 477.00s - 483.22s | work and the work done by Ben Morris. Next we tried to start an EC2 instance based on the 483.22s - 488.22s | target AMI, create a an ABS snapshot of its volume and download it. But we we we quickly we 490.52s - 495.52s | quickly realized that this will take a lot of time for an ABS snapshot of uh 100 gigabytes. 498.40s - 504.04s | It took around 20, 30 minutes to download and we were sure that AWS will block our IP since 504.08s - 511.18s | we are downloading uh terabytes of data, right? So definitely not an option but we realized we 511.18s - 517.46s | had to operate as much as possible within the native AWS features to to achieve the faster 517.46s - 522.46s | uh the faster method. And we we tried to start a new EC2 instance based on the target AMI and 525.34s


chunk_id: 181_chunk_8
chunk_text:
468.62s | snapshot uh of the AMI in our own AWS account and download it but even if the AMI is 471.40s - 477.00s | public the ABS snapshot is not by default and that's why it's very little overlap between our 477.00s - 483.22s | work and the work done by Ben Morris. Next we tried to start an EC2 instance based on the 483.22s - 488.22s | target AMI, create a an ABS snapshot of its volume and download it. But we we we quickly we 490.52s - 495.52s | quickly realized that this will take a lot of time for an ABS snapshot of uh 100 gigabytes. 498.40s - 504.04s | It took around 20, 30 minutes to download and we were sure that AWS will block our IP since 504.08s - 511.18s | we are downloading uh terabytes of data, right? So definitely not an option but we realized we 511.18s - 517.46s | had to operate as much as possible within the native AWS features to to achieve the faster 517.46s - 522.46s | uh the faster method. And we we tried to start a new EC2 instance based on the target AMI and 525.34s - 531.98s | connect directly to the instance but for some reason the instances were not in a state that 531.98s - 537.36s | allowed us to connect to them. Either through SSH or through SSM features it just didn't 537.36s - 542.36s | work. But we did a work around a work around and um we got to this method. So we have a secret 545.66s - 551.64s | searcher instance. We call it like this because it's a sec- it's an instance that we already 551.64s - 557.24s | have in our own AWS account and it's working we can connect to it. And next we start an EC2 557.24s - 562.28s | instance based on the target AMI, detach its volume and reattach it to our secret searcher 562.28s - 568.32s | instance where we can connect and analyze the data. It's like having a working laptop and 568.32s - 573.56s | someone brought a laptop that doesn't work but you can get out the hard disk and connect it to 573.56s - 577.66s | your laptop and basically that's how you can access the data. And everything is happening 577.66s - 584.54s | within the AWS


chunk_id: 181_chunk_9
chunk_text:
- 531.98s | connect directly to the instance but for some reason the instances were not in a state that 531.98s - 537.36s | allowed us to connect to them. Either through SSH or through SSM features it just didn't 537.36s - 542.36s | work. But we did a work around a work around and um we got to this method. So we have a secret 545.66s - 551.64s | searcher instance. We call it like this because it's a sec- it's an instance that we already 551.64s - 557.24s | have in our own AWS account and it's working we can connect to it. And next we start an EC2 557.24s - 562.28s | instance based on the target AMI, detach its volume and reattach it to our secret searcher 562.28s - 568.32s | instance where we can connect and analyze the data. It's like having a working laptop and 568.32s - 573.56s | someone brought a laptop that doesn't work but you can get out the hard disk and connect it to 573.56s - 577.66s | your laptop and basically that's how you can access the data. And everything is happening 577.66s - 584.54s | within the AWS environment so it was both fast and with it was both as reliable as possible. 584.54s - 592.28s | Now I'll show you a demo on how you can manually access the contents of one AMI. Let me 592.28s - 599.31s | see if I can start this. So we can search based on the uh description. You can use this to 599.31s - 604.05s | target certain technologies or companies. You have to mention the right region because 604.05s - 610.01s | otherwise you will not find the the the AMI and you also have to specify the flag include 610.01s - 617.03s | deprecated to make sure you get all the images right? If you know the AWS account ID you can 617.03s - 622.03s | try to find all the images owned by that account so that's that might be useful for uh for 622.03s - 627.03s | bug pound-hunter right? But let's stick with uh our uh description based search. So let's try 629.61s - 636.40s | to copy the ABS snapshot as um as a first step. So you you will see that if you try to copy 639.54s - 644.00s | the snapshot in


chunk_id: 181_chunk_10
chunk_text:
environment so it was both fast and with it was both as reliable as possible. 584.54s - 592.28s | Now I'll show you a demo on how you can manually access the contents of one AMI. Let me 592.28s - 599.31s | see if I can start this. So we can search based on the uh description. You can use this to 599.31s - 604.05s | target certain technologies or companies. You have to mention the right region because 604.05s - 610.01s | otherwise you will not find the the the AMI and you also have to specify the flag include 610.01s - 617.03s | deprecated to make sure you get all the images right? If you know the AWS account ID you can 617.03s - 622.03s | try to find all the images owned by that account so that's that might be useful for uh for 622.03s - 627.03s | bug pound-hunter right? But let's stick with uh our uh description based search. So let's try 629.61s - 636.40s | to copy the ABS snapshot as um as a first step. So you you will see that if you try to copy 639.54s - 644.00s | the snapshot in our own AWS account we will get the error message source snapshot is not 644.00s - 650.66s | found. That's because the ABS snapshot is not public only the AMI is. Now we will do the 650.66s - 655.20s | method uh with the secret search searcher instance so we have our instance that it's 655.20s - 660.18s | running and now we will start a new instance based on the target AMI and we will place it in 660.18s - 665.58s | the same availability zone as our secret searcher instance. We you need the same availability 665.58s - 672.26s | zone to make sure you have you you can move the volume between the instances. Now the 672.28s - 678.38s | instance is running we will stop it and we will detach the volume and we will reattach it to 678.38s - 685.40s | the secret searcher instance. After you detach the volume you can delete the initial ins- the 685.40s - 690.40s | the EC2 instance that is based on the AMI if you want to reduce some cost but in any case uh you 694.40s - 699.54s | can just attach the volume and then you


chunk_id: 181_chunk_11
chunk_text:
our own AWS account we will get the error message source snapshot is not 644.00s - 650.66s | found. That's because the ABS snapshot is not public only the AMI is. Now we will do the 650.66s - 655.20s | method uh with the secret search searcher instance so we have our instance that it's 655.20s - 660.18s | running and now we will start a new instance based on the target AMI and we will place it in 660.18s - 665.58s | the same availability zone as our secret searcher instance. We you need the same availability 665.58s - 672.26s | zone to make sure you have you you can move the volume between the instances. Now the 672.28s - 678.38s | instance is running we will stop it and we will detach the volume and we will reattach it to 678.38s - 685.40s | the secret searcher instance. After you detach the volume you can delete the initial ins- the 685.40s - 690.40s | the EC2 instance that is based on the AMI if you want to reduce some cost but in any case uh you 694.40s - 699.54s | can just attach the volume and then you can connect to it. We use the web portal uh because 699.56s - 704.76s | it was easier for the demo but you can also connect through SSH. A common error that we 704.76s - 710.26s | encountered was an ID collision between the new volume and the root volume that was 710.26s - 716.68s | attached to to the instance. And we had to use all kind of weird tools I've never heard 716.68s - 723.68s | about uh in order to fix this issue but once that is done you will be able to mount the 723.82s - 729.56s | volume and connect um to mount the volume and access the files. And now that it's mounted 729.56s - 734.70s | let's look for some AWS credentials right? We found some and now let's check if they are 734.70s - 741.24s | valid. Because for some older instances the secrets might not be valid anymore so every 741.24s - 750.34s | time you have to check them. So surprise yes they are working and that's exactly how we 750.34s - 756.44s | felt when we found our first AWS access keys and in the same day we found


chunk_id: 181_chunk_12
chunk_text:
can connect to it. We use the web portal uh because 699.56s - 704.76s | it was easier for the demo but you can also connect through SSH. A common error that we 704.76s - 710.26s | encountered was an ID collision between the new volume and the root volume that was 710.26s - 716.68s | attached to to the instance. And we had to use all kind of weird tools I've never heard 716.68s - 723.68s | about uh in order to fix this issue but once that is done you will be able to mount the 723.82s - 729.56s | volume and connect um to mount the volume and access the files. And now that it's mounted 729.56s - 734.70s | let's look for some AWS credentials right? We found some and now let's check if they are 734.70s - 741.24s | valid. Because for some older instances the secrets might not be valid anymore so every 741.24s - 750.34s | time you have to check them. So surprise yes they are working and that's exactly how we 750.34s - 756.44s | felt when we found our first AWS access keys and in the same day we found 10 other valid 756.44s - 762.72s | access keys so we realized that this was a big issue indeed. This is the high level 762.72s - 767.98s | architecture we put in place. We had a master EC2 instance where we round uh we we ran our 767.98s - 774.66s | big script and in each region we started the secret searcher instance um and then we 774.66s - 781.50s | started batches of twenty uh twenty instances based on AMIs to um to make sure we um we 781.50s - 786.64s | reduce the time. And for each instance we detach the volume, we reattach it to the secret 786.64s - 793.24s | searcher instance where we will search for secrets and sensitive files. And after run 793.24s - 798.24s | run after writing 1.2K lines of code, 14 days of scanning time and a bill of 450 dollars, we 801.18s - 806.18s | collected 500 gigabytes of carefully selected files and data um that we had now to to 806.54s - 811.94s | analyze and I invite my colleague Matej Josic to tell you more about it. 811.94s - 820.08s | Thank you. Cool. Good morning everybody and


chunk_id: 181_chunk_13
chunk_text:
10 other valid 756.44s - 762.72s | access keys so we realized that this was a big issue indeed. This is the high level 762.72s - 767.98s | architecture we put in place. We had a master EC2 instance where we round uh we we ran our 767.98s - 774.66s | big script and in each region we started the secret searcher instance um and then we 774.66s - 781.50s | started batches of twenty uh twenty instances based on AMIs to um to make sure we um we 781.50s - 786.64s | reduce the time. And for each instance we detach the volume, we reattach it to the secret 786.64s - 793.24s | searcher instance where we will search for secrets and sensitive files. And after run 793.24s - 798.24s | run after writing 1.2K lines of code, 14 days of scanning time and a bill of 450 dollars, we 801.18s - 806.18s | collected 500 gigabytes of carefully selected files and data um that we had now to to 806.54s - 811.94s | analyze and I invite my colleague Matej Josic to tell you more about it. 811.94s - 820.08s | Thank you. Cool. Good morning everybody and thank you so much for being here. It's actually an 822.16s - 827.16s | absolute pleasure to be on stage at DEF CON 32. This is the secret searcher section where I'm 830.60s - 837.04s | going to talk about how we search for secrets, what sorts of secrets we found, and what we 837.06s - 844.74s | were able to do with them. I am Matej Anthony-Josephs. I've been with KPMG for about an 844.74s - 849.34s | year and a half and I'd like to take this opportunity to thank them for the time and the 849.34s - 855.66s | budget for this project right here. Other than that, I'm a senior security researcher with 855.66s - 860.32s | experience in pen testing, threat hunting, vulnerability management, and a bit of people 860.32s - 865.32s | management as well. Now, completely unrelated to this research, I've also set up a company 866.00s - 870.60s | alongside my wife, Alexa. Our company's called Hivehack, because we're absolutely 870.60s - 876.28s | fascinated by the collaborative trace of bees, whereby up to 60,000 bees work together in a 876.28s - 881.28s | colony for the greater good of the community.


chunk_id: 181_chunk_14
chunk_text:
thank you so much for being here. It's actually an 822.16s - 827.16s | absolute pleasure to be on stage at DEF CON 32. This is the secret searcher section where I'm 830.60s - 837.04s | going to talk about how we search for secrets, what sorts of secrets we found, and what we 837.06s - 844.74s | were able to do with them. I am Matej Anthony-Josephs. I've been with KPMG for about an 844.74s - 849.34s | year and a half and I'd like to take this opportunity to thank them for the time and the 849.34s - 855.66s | budget for this project right here. Other than that, I'm a senior security researcher with 855.66s - 860.32s | experience in pen testing, threat hunting, vulnerability management, and a bit of people 860.32s - 865.32s | management as well. Now, completely unrelated to this research, I've also set up a company 866.00s - 870.60s | alongside my wife, Alexa. Our company's called Hivehack, because we're absolutely 870.60s - 876.28s | fascinated by the collaborative trace of bees, whereby up to 60,000 bees work together in a 876.28s - 881.28s | colony for the greater good of the community. Similarly, we think that uh collaboration is 886.08s - 891.86s | probably the most important part of cyber security. And while I don't know the exact 891.86s - 898.88s | numbers, just looking around Dafcon, I can see why. There's quite a hive of hackers around 898.88s - 905.68s | here. That's enough about me, back to Cloud Query. For our initial strategy, we decided to 905.68s - 911.76s | be as lazy as possible. And trust me, being lazy is a good thing here. We wanted to avoid 911.76s - 916.66s | reinventing the wheel, and wanted to use known tools as much as possible, such as 916.66s - 921.66s | TruffleHog. But we quickly realized that this was not going to work. In fact, the tools which 924.10s - 930.00s | we tried to use were quite slow, and produced loads of false positives. And while we could 930.00s - 934.78s | have worked through the false positives, the fact that the tools were slow was the main 934.78s - 940.08s | issue, because slow scanning times meant that our EC2 instances ran longer, which in turn 940.08s - 945.76s | meant that uh our AWS bill would


chunk_id: 181_chunk_15
chunk_text:
Similarly, we think that uh collaboration is 886.08s - 891.86s | probably the most important part of cyber security. And while I don't know the exact 891.86s - 898.88s | numbers, just looking around Dafcon, I can see why. There's quite a hive of hackers around 898.88s - 905.68s | here. That's enough about me, back to Cloud Query. For our initial strategy, we decided to 905.68s - 911.76s | be as lazy as possible. And trust me, being lazy is a good thing here. We wanted to avoid 911.76s - 916.66s | reinventing the wheel, and wanted to use known tools as much as possible, such as 916.66s - 921.66s | TruffleHog. But we quickly realized that this was not going to work. In fact, the tools which 924.10s - 930.00s | we tried to use were quite slow, and produced loads of false positives. And while we could 930.00s - 934.78s | have worked through the false positives, the fact that the tools were slow was the main 934.78s - 940.08s | issue, because slow scanning times meant that our EC2 instances ran longer, which in turn 940.08s - 945.76s | meant that uh our AWS bill would have been way higher, leaving us broke and lazy, rather 945.76s - 952.68s | than just lazy. So, with this in mind, we had to pivot, and we went back to the Zen of Python. 954.78s - 961.02s | More specifically, the following section of it. Simple is better than complex, complex is 961.02s - 967.86s | better than complicated, and special cases aren't special enough to break the rules. So, with 967.86s - 974.40s | this in mind, we reduced our scope even further, and became even lazier. We ended up only 974.40s - 980.50s | looking for specific types of files or directories, such as uh, well, environment secrets, 980.50s - 985.50s | secrets leaked within git repositories, AWS credentials, private keys, and a few others. Now 987.98s - 993.84s | we faced an other issue, and that is, finding the right tool for this. We had to find the 993.84s - 999.78s | tool, which allowed us to search for files and directories on the file system, based on 999.80s - 1006.10s | their names. The tool had to be quick and simple. So, you can probably see where I'm going 1006.10s - 1011.12s | with this.


chunk_id: 181_chunk_16
chunk_text:
have been way higher, leaving us broke and lazy, rather 945.76s - 952.68s | than just lazy. So, with this in mind, we had to pivot, and we went back to the Zen of Python. 954.78s - 961.02s | More specifically, the following section of it. Simple is better than complex, complex is 961.02s - 967.86s | better than complicated, and special cases aren't special enough to break the rules. So, with 967.86s - 974.40s | this in mind, we reduced our scope even further, and became even lazier. We ended up only 974.40s - 980.50s | looking for specific types of files or directories, such as uh, well, environment secrets, 980.50s - 985.50s | secrets leaked within git repositories, AWS credentials, private keys, and a few others. Now 987.98s - 993.84s | we faced an other issue, and that is, finding the right tool for this. We had to find the 993.84s - 999.78s | tool, which allowed us to search for files and directories on the file system, based on 999.80s - 1006.10s | their names. The tool had to be quick and simple. So, you can probably see where I'm going 1006.10s - 1011.12s | with this. We ended up using the native Unix utility, find, of course. So, uh, we, we 1014.08s - 1019.12s | skipped the Windows directory, program files directories, because they're full of junk and 1019.12s - 1025.26s | slowed down our scans. We skipped everything about, above 25 megabytes, because, well, this 1025.28s - 1030.68s | is only a proof of concept. We didn't need to find everything, really. And searched for all of 1030.68s - 1037.46s | these various files and directories. So, besides our, well, proprietary and very complex use 1037.46s - 1043.32s | of find, and I'm only joking as well, it's not that complex, we had to set up a few other 1043.32s - 1049.86s | things. And one of them was an automation for verifying AWS credentials. And you'll see in a 1049.88s - 1056.28s | minute exactly why we needed that. Secondly, we used Git leaks for checking Git repositories 1056.28s - 1061.28s | for secrets. Also, we had to set up a few other automations for verifying API keys and other 1064.86s - 1070.82s | types of credentials. And for this we used key hacks, which is a fantastic repository of 1070.82s - 1076.66s |


chunk_id: 181_chunk_17
chunk_text:
We ended up using the native Unix utility, find, of course. So, uh, we, we 1014.08s - 1019.12s | skipped the Windows directory, program files directories, because they're full of junk and 1019.12s - 1025.26s | slowed down our scans. We skipped everything about, above 25 megabytes, because, well, this 1025.28s - 1030.68s | is only a proof of concept. We didn't need to find everything, really. And searched for all of 1030.68s - 1037.46s | these various files and directories. So, besides our, well, proprietary and very complex use 1037.46s - 1043.32s | of find, and I'm only joking as well, it's not that complex, we had to set up a few other 1043.32s - 1049.86s | things. And one of them was an automation for verifying AWS credentials. And you'll see in a 1049.88s - 1056.28s | minute exactly why we needed that. Secondly, we used Git leaks for checking Git repositories 1056.28s - 1061.28s | for secrets. Also, we had to set up a few other automations for verifying API keys and other 1064.86s - 1070.82s | types of credentials. And for this we used key hacks, which is a fantastic repository of 1070.82s - 1076.66s | methods for validating keys and credentials. However, even if we had all of these 1076.66s - 1081.88s | automations set up, we, we're still left with, well, a shit load of manual work, to be 1081.88s - 1086.88s | fair. Um, so, following our data collection phase, we were left with 2 million generic API 1089.64s - 1095.48s | keys, and of course many of them are false positives. Over 100,000 potential AWS 1095.48s - 1102.46s | credentials. Several private keys, you can see some slack tokens, uh, uh, Stripe, Telegram, 1102.46s - 1107.40s | and so on and so forth. So you can probably see why we needed all of these automations for 1107.40s - 1112.40s | validating the keys and credentials. So, out of the, about 100,000 AWS credentials, only 1116.04s - 1121.04s | about 120 of them were valid, out of which 20 were root. Now, I know that this does not seem 1124.18s - 1129.18s | like a lot. I mean, what is, 120 out of 100,000 is nothing, right? But, think about it this 1132.46s - 1137.46s | way. These, these keys allowed us to access the AWS accounts of over 100 companies. So, this


chunk_id: 181_chunk_18
chunk_text:
methods for validating keys and credentials. However, even if we had all of these 1076.66s - 1081.88s | automations set up, we, we're still left with, well, a shit load of manual work, to be 1081.88s - 1086.88s | fair. Um, so, following our data collection phase, we were left with 2 million generic API 1089.64s - 1095.48s | keys, and of course many of them are false positives. Over 100,000 potential AWS 1095.48s - 1102.46s | credentials. Several private keys, you can see some slack tokens, uh, uh, Stripe, Telegram, 1102.46s - 1107.40s | and so on and so forth. So you can probably see why we needed all of these automations for 1107.40s - 1112.40s | validating the keys and credentials. So, out of the, about 100,000 AWS credentials, only 1116.04s - 1121.04s | about 120 of them were valid, out of which 20 were root. Now, I know that this does not seem 1124.18s - 1129.18s | like a lot. I mean, what is, 120 out of 100,000 is nothing, right? But, think about it this 1132.46s - 1137.46s | way. These, these keys allowed us to access the AWS accounts of over 100 companies. So, this 1143.00s - 1149.44s | gave us initial access there, and for 20 of them we had absolute complete control. So, let 1149.44s - 1155.94s | that sink in for a bit. Now, we faced another issue, and that is identifying the owners. And 1158.38s - 1163.78s | for this, we used the get contact information call, which gave us, well, the 1163.78s - 1169.48s | company name, in some cases the name of the contact, uh, phone number, email address, and 1169.48s - 1174.48s | so on and so forth. So, with this in mind, we found something surprising. And that is, that 1178.02s - 1183.56s | it's not only small boutique-like companies affected by this. In fact, many of the companies 1183.56s - 1188.56s | are on the Fortune 500 list. Some of the most valuable ones were worth 200, respectively 50 1188.92s - 1193.92s | billion dollars. We found three large telecom companies, which you've definitely heard about in 1196.86s - 1201.30s | the past. Ten relevant security and tech companies, and several others in consulting, 1201.30s - 1208.04s | education, health, manufacturing. Now, unfortunately, we cannot disclose much more about the 1208.04s - 1213.88s | companies at


chunk_id: 181_chunk_19
chunk_text:
1143.00s - 1149.44s | gave us initial access there, and for 20 of them we had absolute complete control. So, let 1149.44s - 1155.94s | that sink in for a bit. Now, we faced another issue, and that is identifying the owners. And 1158.38s - 1163.78s | for this, we used the get contact information call, which gave us, well, the 1163.78s - 1169.48s | company name, in some cases the name of the contact, uh, phone number, email address, and 1169.48s - 1174.48s | so on and so forth. So, with this in mind, we found something surprising. And that is, that 1178.02s - 1183.56s | it's not only small boutique-like companies affected by this. In fact, many of the companies 1183.56s - 1188.56s | are on the Fortune 500 list. Some of the most valuable ones were worth 200, respectively 50 1188.92s - 1193.92s | billion dollars. We found three large telecom companies, which you've definitely heard about in 1196.86s - 1201.30s | the past. Ten relevant security and tech companies, and several others in consulting, 1201.30s - 1208.04s | education, health, manufacturing. Now, unfortunately, we cannot disclose much more about the 1208.04s - 1213.88s | companies at the moment, but maybe in the coming weeks or months we will be able to do so. Now, 1213.90s - 1218.90s | you may ask, well, anybody can write whatever they like in the contact information in the AWS 1221.24s - 1226.58s | account, right? And you're absolutely right. And then our efforts for identifying the 1226.58s - 1233.22s | owners could have been completely in vain. However, here is where our OSINT came in. We did 1233.22s - 1237.12s | quite a bit of OSINT, went on social media, including LinkedIn, and found several of these 1237.12s - 1242.76s | owners. Funnily enough, many of them had several AWS certifications on their accounts, 1242.78s - 1248.14s | suggesting that they are security aware and know how to properly configure their AWS 1248.14s - 1255.37s | accounts. Now, one of these companies, which was and still is actually on the Fortune 500 1255.37s - 1260.37s | list, had a program on bug crowd. So we reported it. And this way we got our first P1, our 1262.77s - 1267.71s | first confirmed critical vulnerability on a bug bounty platform. That was absolutely 1267.71s - 1275.24s | fantastic for us. Oh,


chunk_id: 181_chunk_20
chunk_text:
the moment, but maybe in the coming weeks or months we will be able to do so. Now, 1213.90s - 1218.90s | you may ask, well, anybody can write whatever they like in the contact information in the AWS 1221.24s - 1226.58s | account, right? And you're absolutely right. And then our efforts for identifying the 1226.58s - 1233.22s | owners could have been completely in vain. However, here is where our OSINT came in. We did 1233.22s - 1237.12s | quite a bit of OSINT, went on social media, including LinkedIn, and found several of these 1237.12s - 1242.76s | owners. Funnily enough, many of them had several AWS certifications on their accounts, 1242.78s - 1248.14s | suggesting that they are security aware and know how to properly configure their AWS 1248.14s - 1255.37s | accounts. Now, one of these companies, which was and still is actually on the Fortune 500 1255.37s - 1260.37s | list, had a program on bug crowd. So we reported it. And this way we got our first P1, our 1262.77s - 1267.71s | first confirmed critical vulnerability on a bug bounty platform. That was absolutely 1267.71s - 1275.24s | fantastic for us. Oh, thank you. Thank you. Now, let's see, how much do you guys think 1276.68s - 1281.82s | we made out of it? So, who thinks we made between $10,000 and $100,000? So, let's say 1281.82s - 1286.82s | 5 digits. Yeah, only a few hands up. Maybe 4 digits, so 1,000 and 10,000? Right, a few 1289.46s - 1294.50s | more. Well, let's say AWS or cloud in general is niche, maybe they don't really care about 1294.50s - 1299.50s | these accounts. Maybe 3 digits? Okay, yeah, that's pretty low. Um, yeah, we made $0 out 1299.50s - 1304.50s | of it, nothing. Uh, yeah, thank you, absolutely. Um, well, to be fair, there's a bit of a 1312.12s - 1318.62s | catch. It wasn't a bug bounty program, it's, it was a vulnerability discloser program. And 1318.62s - 1323.86s | we weren't too disappointed to be fair. Because we didn't really aim to make money out of 1323.86s - 1328.86s | this research. We just wanted to make the internet a safer place. Although this sounds a 1328.86s - 1335.20s | bit cliche. But still, we quickly forgot about this because we found something else which I 1335.20s


chunk_id: 181_chunk_21
chunk_text:
thank you. Thank you. Now, let's see, how much do you guys think 1276.68s - 1281.82s | we made out of it? So, who thinks we made between $10,000 and $100,000? So, let's say 1281.82s - 1286.82s | 5 digits. Yeah, only a few hands up. Maybe 4 digits, so 1,000 and 10,000? Right, a few 1289.46s - 1294.50s | more. Well, let's say AWS or cloud in general is niche, maybe they don't really care about 1294.50s - 1299.50s | these accounts. Maybe 3 digits? Okay, yeah, that's pretty low. Um, yeah, we made $0 out 1299.50s - 1304.50s | of it, nothing. Uh, yeah, thank you, absolutely. Um, well, to be fair, there's a bit of a 1312.12s - 1318.62s | catch. It wasn't a bug bounty program, it's, it was a vulnerability discloser program. And 1318.62s - 1323.86s | we weren't too disappointed to be fair. Because we didn't really aim to make money out of 1323.86s - 1328.86s | this research. We just wanted to make the internet a safer place. Although this sounds a 1328.86s - 1335.20s | bit cliche. But still, we quickly forgot about this because we found something else which I 1335.20s - 1341.30s | think was more interesting than this. I like to call this story, how we earned and lost $3 1341.30s - 1346.68s | million in a week. And, well, we're in Vegas right now, we all know a thing or two about 1346.68s - 1353.38s | losing and earning money quickly, right? Um, maybe not quite $3 million. For a bit of 1353.38s - 1359.82s | context, we found this company which had a public AMI, there was a git repository within that 1359.82s - 1366.82s | AMI, and within the git repository we found, um, a Stripe API key. And for those of you who 1366.82s - 1373.20s | don't know, Stripe is a payment service not unlike PayPal. So our first thought was, okay, 1373.20s - 1378.20s | let's run a balance call to the API and that's what we got. Uh, 7 digits in the USD currency. So 1378.56s - 1383.56s | what looked like $3.1 million. Fantastic. So our first thought, of course, was, well, how 1387.44s - 1392.74s | would a threat actor go about transferring these funds into their own account for research 1392.74s - 1399.32s | purposes only, trust me. Only


chunk_id: 181_chunk_22
chunk_text:
- 1341.30s | think was more interesting than this. I like to call this story, how we earned and lost $3 1341.30s - 1346.68s | million in a week. And, well, we're in Vegas right now, we all know a thing or two about 1346.68s - 1353.38s | losing and earning money quickly, right? Um, maybe not quite $3 million. For a bit of 1353.38s - 1359.82s | context, we found this company which had a public AMI, there was a git repository within that 1359.82s - 1366.82s | AMI, and within the git repository we found, um, a Stripe API key. And for those of you who 1366.82s - 1373.20s | don't know, Stripe is a payment service not unlike PayPal. So our first thought was, okay, 1373.20s - 1378.20s | let's run a balance call to the API and that's what we got. Uh, 7 digits in the USD currency. So 1378.56s - 1383.56s | what looked like $3.1 million. Fantastic. So our first thought, of course, was, well, how 1387.44s - 1392.74s | would a threat actor go about transferring these funds into their own account for research 1392.74s - 1399.32s | purposes only, trust me. Only research. So we went to the documentation and we quickly 1399.32s - 1406.57s | realized that the amount is in cents. So what we thought was $3.1 million was actually 1406.59s - 1413.23s | $31,000. Of course, we were very disappointed. Um, we had to get over the disappointment 1413.23s - 1418.51s | that our net worth reduced from $3.1 million to $31,000 by simply reading the 1418.51s - 1425.01s | documentation. So if there's any conclusion here, don't read the documentation. Um, just 1425.01s - 1430.91s | joking of course. Uh, so we wrote an email to their security contact, let them know what's up 1430.93s - 1438.11s | and waited and waited and waited. And all we got was radio silence for a few weeks. It was 1438.11s - 1442.37s | pretty annoying to be fair. We thought, well, did we do something wrong? Didn't we prove 1442.37s - 1447.39s | impact? So we thought of proving impact and that's what we did. We, or I, uh, registered to 1451.15s - 1458.40s | their, uh, cheapest plan which was $9.99 per month. Confirmed the transaction from the 1458.46s - 1463.46s | API. And did a refund call which


chunk_id: 181_chunk_23
chunk_text:
research. So we went to the documentation and we quickly 1399.32s - 1406.57s | realized that the amount is in cents. So what we thought was $3.1 million was actually 1406.59s - 1413.23s | $31,000. Of course, we were very disappointed. Um, we had to get over the disappointment 1413.23s - 1418.51s | that our net worth reduced from $3.1 million to $31,000 by simply reading the 1418.51s - 1425.01s | documentation. So if there's any conclusion here, don't read the documentation. Um, just 1425.01s - 1430.91s | joking of course. Uh, so we wrote an email to their security contact, let them know what's up 1430.93s - 1438.11s | and waited and waited and waited. And all we got was radio silence for a few weeks. It was 1438.11s - 1442.37s | pretty annoying to be fair. We thought, well, did we do something wrong? Didn't we prove 1442.37s - 1447.39s | impact? So we thought of proving impact and that's what we did. We, or I, uh, registered to 1451.15s - 1458.40s | their, uh, cheapest plan which was $9.99 per month. Confirmed the transaction from the 1458.46s - 1463.46s | API. And did a refund call which was successful. Fantastic. And a second level of validation 1466.96s - 1472.40s | was that, uh, the transaction was reverted. So my money was back in my account and I could 1472.40s - 1477.84s | still use their services which I didn't do because I didn't need their services. But now this 1477.84s - 1482.58s | was a bingo moment for us cause we knew that we can talk about money. So we contacted the 1482.58s - 1488.08s | CEO but for this we had to go on LinkedIn, found the CEO, do a bit of OSINT, get their email 1488.10s - 1493.64s | address, and write to them. And guess what? Within a couple of hours we got a response where 1493.64s - 1498.64s | he also CC'd the CTO and asked us for more info. And we provided more info. We gave them a 1501.78s - 1507.72s | comprehensive report including the finding, the impact of the finding, uh, and steps for 1507.72s - 1512.72s | remediating this. And what we got in response was a pretty dry message from the CTO saying, 1513.08s - 1518.08s | thanks for sharing the relevant information, we have made the AMI


chunk_id: 181_chunk_24
chunk_text:
was successful. Fantastic. And a second level of validation 1466.96s - 1472.40s | was that, uh, the transaction was reverted. So my money was back in my account and I could 1472.40s - 1477.84s | still use their services which I didn't do because I didn't need their services. But now this 1477.84s - 1482.58s | was a bingo moment for us cause we knew that we can talk about money. So we contacted the 1482.58s - 1488.08s | CEO but for this we had to go on LinkedIn, found the CEO, do a bit of OSINT, get their email 1488.10s - 1493.64s | address, and write to them. And guess what? Within a couple of hours we got a response where 1493.64s - 1498.64s | he also CC'd the CTO and asked us for more info. And we provided more info. We gave them a 1501.78s - 1507.72s | comprehensive report including the finding, the impact of the finding, uh, and steps for 1507.72s - 1512.72s | remediating this. And what we got in response was a pretty dry message from the CTO saying, 1513.08s - 1518.08s | thanks for sharing the relevant information, we have made the AMI private. For now. Like what? 1520.32s - 1525.32s | For now? Okay. And we'll be replacing the keys. Thanks so much for responsible disclosure. 1529.02s - 1534.96s | We took that as a thanks bye. And yeah, honestly we were a bit disappointed but we had a lot 1534.96s - 1539.04s | of research to do. We had to go back to our research and just, uh, dig through the 500 1539.06s - 1545.70s | gigabytes of data which we already got. However, one month later I was forced to remember the 1545.70s - 1550.70s | issue. I checked my bank account and there's a 999 transaction. So I was so excited about 1553.24s - 1558.24s | being able to do the refund that I completely forgot to cancel my subscription. Oh. Well, 1561.02s - 1567.26s | remember that we are fairly broke so we, I didn't want to let 999 go by just like that. So I 1567.28s - 1572.28s | went back into the API, did the same call again and guess what? Money was back in my account. 1574.36s - 1580.86s | Yes, thank you. Yup. Well, we were disappointed initially by the dry response. But you


chunk_id: 181_chunk_25
chunk_text:
private. For now. Like what? 1520.32s - 1525.32s | For now? Okay. And we'll be replacing the keys. Thanks so much for responsible disclosure. 1529.02s - 1534.96s | We took that as a thanks bye. And yeah, honestly we were a bit disappointed but we had a lot 1534.96s - 1539.04s | of research to do. We had to go back to our research and just, uh, dig through the 500 1539.06s - 1545.70s | gigabytes of data which we already got. However, one month later I was forced to remember the 1545.70s - 1550.70s | issue. I checked my bank account and there's a 999 transaction. So I was so excited about 1553.24s - 1558.24s | being able to do the refund that I completely forgot to cancel my subscription. Oh. Well, 1561.02s - 1567.26s | remember that we are fairly broke so we, I didn't want to let 999 go by just like that. So I 1567.28s - 1572.28s | went back into the API, did the same call again and guess what? Money was back in my account. 1574.36s - 1580.86s | Yes, thank you. Yup. Well, we were disappointed initially by the dry response. But you cannot 1584.10s - 1589.10s | even imagine our disappointment that the issue was still not fixed one month later. Now, 1591.94s - 1597.20s | there's way more impact than just this. Think about it this way. We had to spawn several EC2 1597.22s - 1602.88s | instances in our account. We got a bill of 500 dollars which, well, I'd have preferred to 1602.88s - 1607.86s | avoid. So, yeah, if we weren't ethical we could have went and used the, um, victims, so to 1610.40s - 1615.40s | speak, AWS accounts, uh, to do this research for free. Now, a second potential area of impact, 1618.14s - 1623.14s | uh, which I think has a bit more potential, um, well, AWS based ransomware. Um, and this way I 1623.32s - 1628.32s | could have come to DefCon for free. Um, so, typically when we think about ransomware, we 1631.32s - 1637.16s | think about these teams of developers working 24-7, uh, working on evasion and stuff like 1637.16s - 1643.04s | that. Uh, perhaps when, when we talk about ransomware as a service, uh, they're using, uh, 1643.04s - 1648.04s | 24-7, uh, customer support teams and call centers.


chunk_id: 181_chunk_26
chunk_text:
cannot 1584.10s - 1589.10s | even imagine our disappointment that the issue was still not fixed one month later. Now, 1591.94s - 1597.20s | there's way more impact than just this. Think about it this way. We had to spawn several EC2 1597.22s - 1602.88s | instances in our account. We got a bill of 500 dollars which, well, I'd have preferred to 1602.88s - 1607.86s | avoid. So, yeah, if we weren't ethical we could have went and used the, um, victims, so to 1610.40s - 1615.40s | speak, AWS accounts, uh, to do this research for free. Now, a second potential area of impact, 1618.14s - 1623.14s | uh, which I think has a bit more potential, um, well, AWS based ransomware. Um, and this way I 1623.32s - 1628.32s | could have come to DefCon for free. Um, so, typically when we think about ransomware, we 1631.32s - 1637.16s | think about these teams of developers working 24-7, uh, working on evasion and stuff like 1637.16s - 1643.04s | that. Uh, perhaps when, when we talk about ransomware as a service, uh, they're using, uh, 1643.04s - 1648.04s | 24-7, uh, customer support teams and call centers. Well, in here, with access to the 1648.38s - 1653.38s | profiles, to the accounts, we could have used this, well, one liner or four liner, depends 1657.46s - 1662.46s | how you write it, to list every S3 bucket within the accounts, copy all of the data to our 1666.46s - 1671.46s | local systems and then remove all the data. Now, instead of the data which they expect to 1671.76s - 1678.26s | have on their accounts, they could find something along these lines, a ransom note. All your 1678.26s - 1682.50s | files have been stolen, you must buy us a Romania, Las Vegas ticket to get your files. And 1682.50s - 1687.08s | honestly, that would have been pretty reasonable, it's only what, 500, a thousand dollars, so 1687.08s - 1692.08s | yeah, pretty decent ransom. And I need this disclaimer here, this is just a joke. We didn't 1694.48s - 1700.48s | do this and we wouldn't do this, but it's pretty cool that we could have done this, right? 1700.48s - 1705.48s | Now, Eduard, wanna take over? So, the research was done, uh, we collected the data, we found 1708.12s - 1715.12s |


chunk_id: 181_chunk_27
chunk_text:
Well, in here, with access to the 1648.38s - 1653.38s | profiles, to the accounts, we could have used this, well, one liner or four liner, depends 1657.46s - 1662.46s | how you write it, to list every S3 bucket within the accounts, copy all of the data to our 1666.46s - 1671.46s | local systems and then remove all the data. Now, instead of the data which they expect to 1671.76s - 1678.26s | have on their accounts, they could find something along these lines, a ransom note. All your 1678.26s - 1682.50s | files have been stolen, you must buy us a Romania, Las Vegas ticket to get your files. And 1682.50s - 1687.08s | honestly, that would have been pretty reasonable, it's only what, 500, a thousand dollars, so 1687.08s - 1692.08s | yeah, pretty decent ransom. And I need this disclaimer here, this is just a joke. We didn't 1694.48s - 1700.48s | do this and we wouldn't do this, but it's pretty cool that we could have done this, right? 1700.48s - 1705.48s | Now, Eduard, wanna take over? So, the research was done, uh, we collected the data, we found 1708.12s - 1715.12s | secrets, we validated them, but we wanted to bring down the impact of the effective companies 1715.12s - 1721.10s | before we, we published the research. So, we looked for, uh, contacted, contact details and 1721.10s - 1727.10s | we couldn't find many, we had to search for websites to go find their contact information, 1727.10s - 1734.10s | give some generic email just to make sure we don't give out too much information to, to 1734.10s - 1739.30s | someone that doesn't need to know it. So, we sent almost 70 responsible disclosure emails 1739.30s - 1744.48s | and we received less than 10 responses. We had to do some weird things like contacting the 1744.48s - 1749.08s | national search for one company, scheduled a sales call just to tell them about the 1749.08s - 1754.08s | vulnerability and 90 days later after we did all this, only 10 AWS keys were invalidated. So, 1758.10s - 1764.70s | that sucked and it's like companies are using AWS and they are ignoring responsible 1764.70s - 1768.64s | disclosure, they don't have contact details, they never wrote an access keys and they are 1768.64s - 1774.14s | like, man, this


chunk_id: 181_chunk_28
chunk_text:
secrets, we validated them, but we wanted to bring down the impact of the effective companies 1715.12s - 1721.10s | before we, we published the research. So, we looked for, uh, contacted, contact details and 1721.10s - 1727.10s | we couldn't find many, we had to search for websites to go find their contact information, 1727.10s - 1734.10s | give some generic email just to make sure we don't give out too much information to, to 1734.10s - 1739.30s | someone that doesn't need to know it. So, we sent almost 70 responsible disclosure emails 1739.30s - 1744.48s | and we received less than 10 responses. We had to do some weird things like contacting the 1744.48s - 1749.08s | national search for one company, scheduled a sales call just to tell them about the 1749.08s - 1754.08s | vulnerability and 90 days later after we did all this, only 10 AWS keys were invalidated. So, 1758.10s - 1764.70s | that sucked and it's like companies are using AWS and they are ignoring responsible 1764.70s - 1768.64s | disclosure, they don't have contact details, they never wrote an access keys and they are 1768.64s - 1774.14s | like, man, this cloud thing is so unsafe. It's not like that, right? And in a desperate 1774.14s - 1781.04s | attempt to invalidate more keys, we notified AWS security team and we were, we were like, I 1781.06s - 1787.06s | know this is weird but we got 120 access keys that are valid. Here are, here is the proof, 1787.06s - 1793.40s | um, can you invalidate them? We have a research we want to publish it. And the AWS security 1793.40s - 1800.34s | team, the most amazing team we, we worked with, um, they made me rethink about the whole 1800.34s - 1805.34s | responsible disclosure process and after a few days after contacting them, more than 60 1805.34s - 1810.48s | AWS keys were invalidated. We had a meeting about the research, we provided some, some 1810.52s - 1816.10s | ideas, we discussed fixes and it was overall an amazing experience and I want to give a 1816.10s - 1821.90s | huge high, uh, a huge shout out to Christian Severt from, uh, from AWS security team and 1821.90s - 1826.90s | uh, AWS security outreach team. So, please give them a round of applause. Thank you. 1830.04s


chunk_id: 181_chunk_29
chunk_text:
cloud thing is so unsafe. It's not like that, right? And in a desperate 1774.14s - 1781.04s | attempt to invalidate more keys, we notified AWS security team and we were, we were like, I 1781.06s - 1787.06s | know this is weird but we got 120 access keys that are valid. Here are, here is the proof, 1787.06s - 1793.40s | um, can you invalidate them? We have a research we want to publish it. And the AWS security 1793.40s - 1800.34s | team, the most amazing team we, we worked with, um, they made me rethink about the whole 1800.34s - 1805.34s | responsible disclosure process and after a few days after contacting them, more than 60 1805.34s - 1810.48s | AWS keys were invalidated. We had a meeting about the research, we provided some, some 1810.52s - 1816.10s | ideas, we discussed fixes and it was overall an amazing experience and I want to give a 1816.10s - 1821.90s | huge high, uh, a huge shout out to Christian Severt from, uh, from AWS security team and 1821.90s - 1826.90s | uh, AWS security outreach team. So, please give them a round of applause. Thank you. 1830.04s - 1834.04s | Now, to discuss a bit about detecting and defending against this and let's start with 1834.04s - 1842.04s | defending. So, if your AWS account has this, um, yellow warning signs, you, you, you might 1842.04s - 1847.76s | want to look into it. So, the settings block public access for AMIs and ABS snapshots 1847.76s - 1852.56s | should be enabled. They should look like this, they should, should have this green check 1852.56s - 1859.24s | mark. You can also use the CLI to validate if you have public AMIs. Make sure to check 1859.24s - 1865.08s | every region and uh, make sure to check for deprecated images. You have to be careful 1865.08s - 1870.58s | about this because one technique attackers are using to exfiltrate data is by making AMIs 1870.58s - 1876.66s | public and accessing them from their account and if that happens to you, you should look 1876.66s - 1882.16s | in CloudTrail for this event, shared snapshot volume created. This is the only event you 1882.16s - 1887.26s | get in CloudTrail if someone accesses your public AMI and it doesn't have a lot of 1887.26s - 1894.10s


chunk_id: 181_chunk_30
chunk_text:
- 1834.04s | Now, to discuss a bit about detecting and defending against this and let's start with 1834.04s - 1842.04s | defending. So, if your AWS account has this, um, yellow warning signs, you, you, you might 1842.04s - 1847.76s | want to look into it. So, the settings block public access for AMIs and ABS snapshots 1847.76s - 1852.56s | should be enabled. They should look like this, they should, should have this green check 1852.56s - 1859.24s | mark. You can also use the CLI to validate if you have public AMIs. Make sure to check 1859.24s - 1865.08s | every region and uh, make sure to check for deprecated images. You have to be careful 1865.08s - 1870.58s | about this because one technique attackers are using to exfiltrate data is by making AMIs 1870.58s - 1876.66s | public and accessing them from their account and if that happens to you, you should look 1876.66s - 1882.16s | in CloudTrail for this event, shared snapshot volume created. This is the only event you 1882.16s - 1887.26s | get in CloudTrail if someone accesses your public AMI and it doesn't have a lot of 1887.26s - 1894.10s | information. As you can see the IP address is hidden which I get it. It's protecting the, 1894.10s - 1900.00s | the, the customer that is accessing the API, the, the AMI, that is cool. But the only 1900.00s - 1904.94s | identifiable information you have is the account ID which you can't do much uh, with it, 1904.94s - 1909.78s | right? So, better be careful, better protect your account and enable uh, enable the 1909.78s - 1916.22s | settings if you don't plan to publish AMIs or uh, or uh, ABS snapshots. Now, we have a lot 1916.22s - 1921.22s | of data and we did other research with uh, with it. And one idea we had was, so we had 1923.72s - 1930.06s | 20K JSON web tokens and we looked if there are any tokens that were not expired, maybe 1930.06s - 1934.70s | they had some secrets in them, any other misconfigurations but nothing came out of it. 1934.70s - 1941.08s | However, it was a, it was a good try. Next, we looked through our 4K unique SSH private 1941.08s - 1945.94s | keys, we generated public keys and a figure print and


chunk_id: 181_chunk_31
chunk_text:
| information. As you can see the IP address is hidden which I get it. It's protecting the, 1894.10s - 1900.00s | the, the customer that is accessing the API, the, the AMI, that is cool. But the only 1900.00s - 1904.94s | identifiable information you have is the account ID which you can't do much uh, with it, 1904.94s - 1909.78s | right? So, better be careful, better protect your account and enable uh, enable the 1909.78s - 1916.22s | settings if you don't plan to publish AMIs or uh, or uh, ABS snapshots. Now, we have a lot 1916.22s - 1921.22s | of data and we did other research with uh, with it. And one idea we had was, so we had 1923.72s - 1930.06s | 20K JSON web tokens and we looked if there are any tokens that were not expired, maybe 1930.06s - 1934.70s | they had some secrets in them, any other misconfigurations but nothing came out of it. 1934.70s - 1941.08s | However, it was a, it was a good try. Next, we looked through our 4K unique SSH private 1941.08s - 1945.94s | keys, we generated public keys and a figure print and we searched on showdown but nothing 1945.94s - 1951.98s | uh, nothing came out of it. Uh, one idea was to perform the same scan from within the AWS 1951.98s - 1956.96s | network. Maybe that's how uh, we might find some, some servers but that was just too much 1956.96s - 1961.96s | work and uh, it wasn't worth it. Another cool idea we had but we haven't started this yet. So, 1964.30s - 1969.84s | we collected a lot of private, a lot of repositories and some of them are surely private. 1969.84s - 1974.80s | We wanted to identify the private repositories to identify the deployed web application in 1974.80s - 1981.20s | the wild and then perform source code review um, in order to find some vulnerabilities, get 1981.20s - 1987.88s | some CVs, get some bounties but that is a lot of work and we, we are keeping it for um, for 1987.88s - 1994.76s | later. And that is not all. Matei if you will. Yep, so while we're on the topic of further 1994.78s - 2001.88s | research, well we still have about 500 gigabytes of potential secrets and we tried our best


chunk_id: 181_chunk_32
chunk_text:
we searched on showdown but nothing 1945.94s - 1951.98s | uh, nothing came out of it. Uh, one idea was to perform the same scan from within the AWS 1951.98s - 1956.96s | network. Maybe that's how uh, we might find some, some servers but that was just too much 1956.96s - 1961.96s | work and uh, it wasn't worth it. Another cool idea we had but we haven't started this yet. So, 1964.30s - 1969.84s | we collected a lot of private, a lot of repositories and some of them are surely private. 1969.84s - 1974.80s | We wanted to identify the private repositories to identify the deployed web application in 1974.80s - 1981.20s | the wild and then perform source code review um, in order to find some vulnerabilities, get 1981.20s - 1987.88s | some CVs, get some bounties but that is a lot of work and we, we are keeping it for um, for 1987.88s - 1994.76s | later. And that is not all. Matei if you will. Yep, so while we're on the topic of further 1994.78s - 2001.88s | research, well we still have about 500 gigabytes of potential secrets and we tried our best to 2001.88s - 2008.46s | dig, dig through that data but there's definitely way more to find. Moreover, our colleague 2008.46s - 2015.06s | from KPMG Romania, Stefan Tica, worked on some similar research uh, on Azure and we are 2015.06s - 2020.64s | looking forward to his research being published as well in the near future. Also, we will 2020.66s - 2025.66s | soon make a word list public with all the files which we found in all these public AMIs which 2028.06s - 2034.06s | we scanned. Now, going back to the research objectives formulated by Edward at the 2034.06s - 2039.06s | beginning of this talk. We aim to dig for secrets in every public AMI across all AWS regions. And 2041.38s - 2048.38s | while we didn't dig into all public AMIs, we dug into all public AMIs which we found 2048.38s - 2055.36s | interesting. So I'd say that this was achieved. Also, we aim to have fun and yeah, we did. We 2055.36s - 2060.50s | found a lot more stuff than we expected. It was a roller coaster and thanks Edward for this. 2060.50s - 2067.38s | Lastly, responsible disclosure. Well, I was


chunk_id: 181_chunk_33
chunk_text:
to 2001.88s - 2008.46s | dig, dig through that data but there's definitely way more to find. Moreover, our colleague 2008.46s - 2015.06s | from KPMG Romania, Stefan Tica, worked on some similar research uh, on Azure and we are 2015.06s - 2020.64s | looking forward to his research being published as well in the near future. Also, we will 2020.66s - 2025.66s | soon make a word list public with all the files which we found in all these public AMIs which 2028.06s - 2034.06s | we scanned. Now, going back to the research objectives formulated by Edward at the 2034.06s - 2039.06s | beginning of this talk. We aim to dig for secrets in every public AMI across all AWS regions. And 2041.38s - 2048.38s | while we didn't dig into all public AMIs, we dug into all public AMIs which we found 2048.38s - 2055.36s | interesting. So I'd say that this was achieved. Also, we aim to have fun and yeah, we did. We 2055.36s - 2060.50s | found a lot more stuff than we expected. It was a roller coaster and thanks Edward for this. 2060.50s - 2067.38s | Lastly, responsible disclosure. Well, I was a bit disappointed by the responsible 2067.38s - 2074.38s | disclosure process in general. Well, many of the owners uh, didn't, didn't respond to us. 2074.38s - 2079.38s | Others, well, didn't have any sort of information for us to contact them. Um, however, the 2081.62s - 2087.52s | experience of responsibly disclosing this to the AWS team definitely made up for all of the 2087.52s - 2093.90s | less pleasant experiences so this was definitely achieved as well. Now, that we are 2093.90s - 2100.64s | approaching the end of this talk, here are our conclusions. Firstly, the impact of this 2100.66s - 2105.66s | research is not yet fully uncovered. There's still way more to find out there. We have found 2109.44s - 2115.08s | several secrets already in the data which we collected. There's definitely more in the data 2115.08s - 2118.78s | which we already collected but there's definitely way more out there which we did not 2118.78s - 2125.02s | collect yet. Potentially, a nice area of research would be continuously monitoring new AMIs 2125.04s - 2131.38s | becoming public. Secondly, security by obscurity is definitely insufficient. So many 2131.38s - 2135.98s | developers definitely


chunk_id: 181_chunk_34
chunk_text:
a bit disappointed by the responsible 2067.38s - 2074.38s | disclosure process in general. Well, many of the owners uh, didn't, didn't respond to us. 2074.38s - 2079.38s | Others, well, didn't have any sort of information for us to contact them. Um, however, the 2081.62s - 2087.52s | experience of responsibly disclosing this to the AWS team definitely made up for all of the 2087.52s - 2093.90s | less pleasant experiences so this was definitely achieved as well. Now, that we are 2093.90s - 2100.64s | approaching the end of this talk, here are our conclusions. Firstly, the impact of this 2100.66s - 2105.66s | research is not yet fully uncovered. There's still way more to find out there. We have found 2109.44s - 2115.08s | several secrets already in the data which we collected. There's definitely more in the data 2115.08s - 2118.78s | which we already collected but there's definitely way more out there which we did not 2118.78s - 2125.02s | collect yet. Potentially, a nice area of research would be continuously monitoring new AMIs 2125.04s - 2131.38s | becoming public. Secondly, security by obscurity is definitely insufficient. So many 2131.38s - 2135.98s | developers definitely thought that their Git repositories were safe because they're private, 2135.98s - 2142.26s | right? But how is anything private if it's placed in a public resource? Also, you may be 2142.26s - 2148.86s | thinking, hey, I won't be a target of this, right? Nobody cares about my AMIs. Well, think 2148.86s - 2154.70s | about it this way. Edward and I, two cyber security guys from Romania, were able to do this. 2154.72s - 2160.86s | Think about what the threat actors could do. So definitely, don't make your AMIs public if you 2160.86s - 2165.86s | don't have to. Now, AMIs are only the tip of the iceberg here. There are still a lot of other 2169.40s - 2175.74s | interesting things to find across several other public cloud providers. Who knows, maybe 2175.74s - 2181.94s | next year we'll be back here talking about how we dug for secrets in a different cloud 2181.96s - 2187.72s | resource. And still, we encourage you to do your own research as well. And please, let us 2187.72s - 2194.74s | know if you have any sort of ideas. We're happy to help. Actually, going back to my initial


chunk_id: 181_chunk_35
chunk_text:
thought that their Git repositories were safe because they're private, 2135.98s - 2142.26s | right? But how is anything private if it's placed in a public resource? Also, you may be 2142.26s - 2148.86s | thinking, hey, I won't be a target of this, right? Nobody cares about my AMIs. Well, think 2148.86s - 2154.70s | about it this way. Edward and I, two cyber security guys from Romania, were able to do this. 2154.72s - 2160.86s | Think about what the threat actors could do. So definitely, don't make your AMIs public if you 2160.86s - 2165.86s | don't have to. Now, AMIs are only the tip of the iceberg here. There are still a lot of other 2169.40s - 2175.74s | interesting things to find across several other public cloud providers. Who knows, maybe 2175.74s - 2181.94s | next year we'll be back here talking about how we dug for secrets in a different cloud 2181.96s - 2187.72s | resource. And still, we encourage you to do your own research as well. And please, let us 2187.72s - 2194.74s | know if you have any sort of ideas. We're happy to help. Actually, going back to my initial 2194.74s - 2200.90s | point within the secret searcher section. Collaboration is definitely the most important 2200.90s - 2206.58s | aspect of cyber security. So please, connect with us. Let us know if you need any help with 2206.58s - 2212.38s | any sort of research in the future. And we'll definitely be happy to help. This being said, 2212.38s - 2228.51s | thank you very much everybody. We appreciate you being here. Any questions? Yep. Sure, go 2228.51s - 2246.72s | ahead. Is the mic on? Not yet. Can we get the question mic on please? Oh, perhaps just speak 2246.72s - 2258.31s | really loudly. Well go ahead Edward. Uh, we don't know. So, we, we didn't perform any calls 2259.31s - 2264.31s | beside the contact information. Um, so we tried to get uh, security operation and uh, another 2267.49s - 2272.39s | type of contact details but we, we didn't check the permissions. I'm sure for some of them, we 2272.39s - 2277.19s | surely could have. But yeah, that, that was too much because surely there were some 2277.19s - 2282.95s | automation based on the uh, access keys and uh, we might have broke,


chunk_id: 181_chunk_36
chunk_text:
2194.74s - 2200.90s | point within the secret searcher section. Collaboration is definitely the most important 2200.90s - 2206.58s | aspect of cyber security. So please, connect with us. Let us know if you need any help with 2206.58s - 2212.38s | any sort of research in the future. And we'll definitely be happy to help. This being said, 2212.38s - 2228.51s | thank you very much everybody. We appreciate you being here. Any questions? Yep. Sure, go 2228.51s - 2246.72s | ahead. Is the mic on? Not yet. Can we get the question mic on please? Oh, perhaps just speak 2246.72s - 2258.31s | really loudly. Well go ahead Edward. Uh, we don't know. So, we, we didn't perform any calls 2259.31s - 2264.31s | beside the contact information. Um, so we tried to get uh, security operation and uh, another 2267.49s - 2272.39s | type of contact details but we, we didn't check the permissions. I'm sure for some of them, we 2272.39s - 2277.19s | surely could have. But yeah, that, that was too much because surely there were some 2277.19s - 2282.95s | automation based on the uh, access keys and uh, we might have broke, uh, broken something. 2282.97s - 2288.51s | So, yeah. Also, please note that just having the uh, S3 ransomware sort of code in my 2288.51s - 2302.57s | terminal got my adrenaline rushing. So we, we didn't try to do anything like that. Yes. I 2302.57s - 2318.60s | didn't have to, I wanted to. Sorry? Yeah, actually, so yeah, I'm looking for new 2318.60s - 2323.54s | opportunities. If you have something in mind in the offensive security, cloud research or 2323.54s - 2328.28s | cloud security, just give me a message. I'll, I'll start applying next week. So, thanks. 2333.32s - 2345.36s | Cool. Any other questions? Yes, please. Uh, no, and to be fair, we didn't even expect that. I 2345.36s - 2351.94s | mean, we had KPMG for that. So, thanks KPMG. And uh, we are waiting some t-shirts from the 2351.94s - 2361.02s | companies we disclosed this. Thank you. Mic's working, so if anybody has any questions, 2361.02s - 2366.40s | you can speak in the mic. Cool. Doesn't look like any other questions. We'll just be around 2366.40s - 2370.00s | here, so please let us know guys. Nice talking to you. Thank


chunk_id: 181_chunk_37
chunk_text:
uh, broken something. 2282.97s - 2288.51s | So, yeah. Also, please note that just having the uh, S3 ransomware sort of code in my 2288.51s - 2302.57s | terminal got my adrenaline rushing. So we, we didn't try to do anything like that. Yes. I 2302.57s - 2318.60s | didn't have to, I wanted to. Sorry? Yeah, actually, so yeah, I'm looking for new 2318.60s - 2323.54s | opportunities. If you have something in mind in the offensive security, cloud research or 2323.54s - 2328.28s | cloud security, just give me a message. I'll, I'll start applying next week. So, thanks. 2333.32s - 2345.36s | Cool. Any other questions? Yes, please. Uh, no, and to be fair, we didn't even expect that. I 2345.36s - 2351.94s | mean, we had KPMG for that. So, thanks KPMG. And uh, we are waiting some t-shirts from the 2351.94s - 2361.02s | companies we disclosed this. Thank you. Mic's working, so if anybody has any questions, 2361.02s - 2366.40s | you can speak in the mic. Cool. Doesn't look like any other questions. We'll just be around 2366.40s - 2370.00s | here, so please let us know guys. Nice talking to you. Thank you.


chunk_id: 182_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=-pxmly8xeas", "title": "DEF CON 32 - Breaking the Beam:Exploiting VSAT Modems from Earth - Lenders, Willbold, Bisping", "description": "VSAT satellite communication systems are widely used to provide two-way data and voice communications to remote areas, including maritime environments, crisis regions, and other locations where terrestrial communication infrastructure is limited or unavailable. In this presentation, we report on our security findings from our reverse-engineering efforts to exploit VSAT satellite modems from the Earth. We will focus on the Newtec MDM2200 from iDirect as an example. First, we explain how we reverse-engineered the software stack running on the modem device to find 0-day vulnerabilities. Then, we show how we reverse-engineered the network stack to devise attacks that can be launched by injecting wireless signals through the antenna dish of a VSAT terminal. Finally, we demonstrate our software-defined radio end-to-end attacks to inject bogus firmware updates and to gain a remote root shell access on the modem. To the best of knowledge, this represents the first successful demonstration of signal injection attacks on VSAT modems using software-defined radios from the Earth, while previous attacks on VSAT systems such as the ViaSat hack in 2022 were based on exploiting the operator\u2019s network through Internet VPN connections. Our work therefore enlarges significantly the attack surface of VSAT systems.\n\nOur presentation at DEF CON is part of a project that has three parts.\n\nIn the first part, we focus on the inherent security issues in current VSAT system practices. This work will be appear in May at ACM WiSec 2024.\n\nVSAsTer: Uncovering Inherent Security Issues in Current VSAT System Practices, Johannes Willbold, Moritz Schloegel, Robin Bisping, Martin Strohmeier, Thorsten Holz, Vincent Lenders, 17th ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec), Seoul, Korea, May 2024.\n\nThe second part deals with the systematic evaluation of wireless signal injection attacks using a software-defined radio. This work will appear in August at Usenix Security 2024:\n\nWireless Signal Injection Attacks on VSAT Satellite Modems, Robin Bisping, Johannes Willbold, Martin Strohmeier, and Vincent Lenders, 33rd USENIX Security Symposium (USENIX Security), Philadelphia PA, USA, August 2024.\n\nThe third part of the project deals with reverse-engineering of the software and network stack of satellite modems and the development of exploits that can be injected over the air through the antenna dish of a VSAT terminal from the ground. This part shall be presented at DEF CON this year.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2379, "channel":


chunk_id: 182_chunk_1
chunk_text:
through Internet VPN connections. Our work therefore enlarges significantly the attack surface of VSAT systems.\n\nOur presentation at DEF CON is part of a project that has three parts.\n\nIn the first part, we focus on the inherent security issues in current VSAT system practices. This work will be appear in May at ACM WiSec 2024.\n\nVSAsTer: Uncovering Inherent Security Issues in Current VSAT System Practices, Johannes Willbold, Moritz Schloegel, Robin Bisping, Martin Strohmeier, Thorsten Holz, Vincent Lenders, 17th ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec), Seoul, Korea, May 2024.\n\nThe second part deals with the systematic evaluation of wireless signal injection attacks using a software-defined radio. This work will appear in August at Usenix Security 2024:\n\nWireless Signal Injection Attacks on VSAT Satellite Modems, Robin Bisping, Johannes Willbold, Martin Strohmeier, and Vincent Lenders, 33rd USENIX Security Symposium (USENIX Security), Philadelphia PA, USA, August 2024.\n\nThe third part of the project deals with reverse-engineering of the software and network stack of satellite modems and the development of exploits that can be injected over the air through the antenna dish of a VSAT terminal from the ground. This part shall be presented at DEF CON this year.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2379, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 1.49s - 8.67s | This text was transcribed using whisper model: large-v2 So hello everyone and welcome to our presentation on breaking the beam a new type of attack 9.65s - 14.09s | That aims at exploiting vSAT satellite communication from the earth 14.77s - 18.69s | But first let me introduce ourself. I'm Vincent. I'm 20.09s - 22.77s | Cybersecurity researcher for more than 20 years 23.13s - 28.29s | I've been focusing mostly on the security of wireless networks in my research and 28.29s - 33.13s | And currently I'm acting as a director of the cyber defense campus in Switzerland 33.53s - 36.77s | We have also with us today Johannes is a PhD student 37.41s - 38.89s | from the 38.89s - 45.69s | University of Bochum in Germany and is researching the software security of space and satellite systems 46.17s - 50.77s | and also with us today is a Robin is a graduate students from ETH Zurich and 51.37s - 56.37s | It has been also working at the cyber defense campus in the context of his master thesis 56.85s - 58.25s | So 58.25s - 60.53s |


chunk_id: 182_chunk_2
chunk_text:
"DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 1.49s - 8.67s | This text was transcribed using whisper model: large-v2 So hello everyone and welcome to our presentation on breaking the beam a new type of attack 9.65s - 14.09s | That aims at exploiting vSAT satellite communication from the earth 14.77s - 18.69s | But first let me introduce ourself. I'm Vincent. I'm 20.09s - 22.77s | Cybersecurity researcher for more than 20 years 23.13s - 28.29s | I've been focusing mostly on the security of wireless networks in my research and 28.29s - 33.13s | And currently I'm acting as a director of the cyber defense campus in Switzerland 33.53s - 36.77s | We have also with us today Johannes is a PhD student 37.41s - 38.89s | from the 38.89s - 45.69s | University of Bochum in Germany and is researching the software security of space and satellite systems 46.17s - 50.77s | and also with us today is a Robin is a graduate students from ETH Zurich and 51.37s - 56.37s | It has been also working at the cyber defense campus in the context of his master thesis 56.85s - 58.25s | So 58.25s - 60.53s | Let me start with what vSAT 61.29s - 68.09s | Communication is vSAT stands for very small aperture terminal. This is a special type of 69.49s - 71.49s | satellite communication 71.73s - 72.93s | that 72.93s - 74.93s | communicates over 75.25s - 83.41s | Geostationary satellites you you can see here on the picture on the left a maritime vSAT communication system 86.23s - 87.87s | A 87.87s - 90.35s | Maritime vSAT. Can you please switch off the 91.55s - 98.83s | The music. Thanks. We have a maritime vSAT communication system that is equipped on the ship or on the right 98.83s - 100.67s | We have a terrestrial 100.67s - 101.83s | vSAT 101.83s - 104.75s | system that is typically used for 105.79s - 107.27s | terrestrial 107.27s - 108.31s | applications 108.31s - 112.03s | This vSAT communication systems. They typically provide data 113.03s - 115.87s | Video or voice communication services 116.71s - 117.95s | and 117.95s - 120.23s | They are not so small as the name stands 120.75s - 125.27s | This antenna dishes can be typically the size of a one meter or two meters 127.96s - 129.84s |


chunk_id: 182_chunk_3
chunk_text:
Let me start with what vSAT 61.29s - 68.09s | Communication is vSAT stands for very small aperture terminal. This is a special type of 69.49s - 71.49s | satellite communication 71.73s - 72.93s | that 72.93s - 74.93s | communicates over 75.25s - 83.41s | Geostationary satellites you you can see here on the picture on the left a maritime vSAT communication system 86.23s - 87.87s | A 87.87s - 90.35s | Maritime vSAT. Can you please switch off the 91.55s - 98.83s | The music. Thanks. We have a maritime vSAT communication system that is equipped on the ship or on the right 98.83s - 100.67s | We have a terrestrial 100.67s - 101.83s | vSAT 101.83s - 104.75s | system that is typically used for 105.79s - 107.27s | terrestrial 107.27s - 108.31s | applications 108.31s - 112.03s | This vSAT communication systems. They typically provide data 113.03s - 115.87s | Video or voice communication services 116.71s - 117.95s | and 117.95s - 120.23s | They are not so small as the name stands 120.75s - 125.27s | This antenna dishes can be typically the size of a one meter or two meters 127.96s - 129.84s | Okay 129.84s - 134.40s | if we look at a system a vSAT communication system 134.48s - 142.18s | It basically consists of three components. We have a central hub. The central hub is typically connected to the Internet 142.18s - 143.30s | and 143.30s - 145.70s | We have a satellite geostationary 146.26s - 150.86s | Geostationary satellite that's a satellite that is in the orbit such that it 151.62s - 153.62s | Rotates at the same speed 154.14s - 161.66s | Around the earth out there as the earth is rotating around its own axis. So the satellite stays always at the same 162.78s - 166.90s | Location compared to the earth and then we have a vSAT 167.34s - 174.46s | Endpoint that's a dish with a modem where users can connect their mobile device or smartphone laptops, whatever 175.38s - 181.14s | If we look at the communication, it's a bidirectional communication. So we have a forward channel 181.54s - 185.62s | From the central hub that goes over the satellite to the vSAT endpoint 186.42s - 188.06s | and we have a 188.06s - 191.90s | Return channel that goes from the vSAT endpoint back


chunk_id: 182_chunk_4
chunk_text:
Okay 129.84s - 134.40s | if we look at a system a vSAT communication system 134.48s - 142.18s | It basically consists of three components. We have a central hub. The central hub is typically connected to the Internet 142.18s - 143.30s | and 143.30s - 145.70s | We have a satellite geostationary 146.26s - 150.86s | Geostationary satellite that's a satellite that is in the orbit such that it 151.62s - 153.62s | Rotates at the same speed 154.14s - 161.66s | Around the earth out there as the earth is rotating around its own axis. So the satellite stays always at the same 162.78s - 166.90s | Location compared to the earth and then we have a vSAT 167.34s - 174.46s | Endpoint that's a dish with a modem where users can connect their mobile device or smartphone laptops, whatever 175.38s - 181.14s | If we look at the communication, it's a bidirectional communication. So we have a forward channel 181.54s - 185.62s | From the central hub that goes over the satellite to the vSAT endpoint 186.42s - 188.06s | and we have a 188.06s - 191.90s | Return channel that goes from the vSAT endpoint back over the satellite 192.50s - 197.42s | To the central up the satellite is really a very dumb. It's typically a bent pipe 197.42s - 203.06s | So it just takes the signals from the uplink that it receives and forwards them to the downlink 203.22s - 207.66s | That's the only thing that the satellite is typically doing is in terms of signal 208.22s - 210.10s | forwarding 210.10s - 212.46s | now if we look at the security of 213.14s - 215.14s | vSAT communication systems 215.26s - 222.90s | We can consider three thread models and the first thread model is basically an attacker that tries to attack the 222.90s - 224.90s | system from the internet 225.14s - 227.14s | so it will attack and try to 228.22s - 230.22s | infiltrate from the central hub and 230.74s - 236.62s | Basically, this is also what happened and what everybody was talking for the last two years. That is what happened in February 237.50s - 239.50s | 2022 239.50s - 245.82s | In where at the same time on the same day as the Russian invaded the Ukraine there was an attack 246.54s - 253.74s |


chunk_id: 182_chunk_5
chunk_text:
over the satellite 192.50s - 197.42s | To the central up the satellite is really a very dumb. It's typically a bent pipe 197.42s - 203.06s | So it just takes the signals from the uplink that it receives and forwards them to the downlink 203.22s - 207.66s | That's the only thing that the satellite is typically doing is in terms of signal 208.22s - 210.10s | forwarding 210.10s - 212.46s | now if we look at the security of 213.14s - 215.14s | vSAT communication systems 215.26s - 222.90s | We can consider three thread models and the first thread model is basically an attacker that tries to attack the 222.90s - 224.90s | system from the internet 225.14s - 227.14s | so it will attack and try to 228.22s - 230.22s | infiltrate from the central hub and 230.74s - 236.62s | Basically, this is also what happened and what everybody was talking for the last two years. That is what happened in February 237.50s - 239.50s | 2022 239.50s - 245.82s | In where at the same time on the same day as the Russian invaded the Ukraine there was an attack 246.54s - 253.74s | basically through this ground system ground system network to deploy bogus malicious 254.46s - 256.22s | firmwares to 256.22s - 257.86s | thousands of 257.86s - 260.50s | vSAT endpoints and this this attack 261.90s - 263.02s | basically 263.02s - 265.02s | Was was was basically? 265.58s - 267.58s | rendering thousands of 267.62s - 271.70s | Modems unavailable and had to be replaced or updated 272.82s - 279.54s | Now this attack has been presented last year and the year before at Defcon so many people have analyzed what happened there 280.46s - 287.74s | So there is a second threat model which basically looks at attacks against the satellite itself 288.62s - 289.86s | so 289.86s - 294.50s | Basically the idea would be to attack the satellite directly over their air interface 295.18s - 302.38s | So we have been doing some research the previous years on these types of attacks for example at IEEE S&P in 2020 302.46s - 304.70s | We showed how it is possible to intercept 305.90s - 307.42s | vSAT 307.42s - 309.10s | communication 309.10s - 314.54s | Passively with an eavesdropper. We have been also doing some some research


chunk_id: 182_chunk_6
chunk_text:
basically through this ground system ground system network to deploy bogus malicious 254.46s - 256.22s | firmwares to 256.22s - 257.86s | thousands of 257.86s - 260.50s | vSAT endpoints and this this attack 261.90s - 263.02s | basically 263.02s - 265.02s | Was was was basically? 265.58s - 267.58s | rendering thousands of 267.62s - 271.70s | Modems unavailable and had to be replaced or updated 272.82s - 279.54s | Now this attack has been presented last year and the year before at Defcon so many people have analyzed what happened there 280.46s - 287.74s | So there is a second threat model which basically looks at attacks against the satellite itself 288.62s - 289.86s | so 289.86s - 294.50s | Basically the idea would be to attack the satellite directly over their air interface 295.18s - 302.38s | So we have been doing some research the previous years on these types of attacks for example at IEEE S&P in 2020 302.46s - 304.70s | We showed how it is possible to intercept 305.90s - 307.42s | vSAT 307.42s - 309.10s | communication 309.10s - 314.54s | Passively with an eavesdropper. We have been also doing some some research presenting this year at aerospace 316.26s - 319.54s | Conference about reconnaissance how to basically 320.42s - 323.66s | Discover capabilities of satellites or last year 323.66s - 329.02s | I had an IEEE S&P Johannes was also presenting a paper that shows 329.38s - 334.14s | how you could find the vulnerabilities in satellites and try to exploit those and 335.50s - 343.10s | Then the the focus of today is to look at the threat model of an attacker the third threat model which basically 343.58s - 348.54s | Attacks directly the vSAT endpoint, and this is the new thing that we are considering in this work 349.14s - 351.14s | basically, we we 351.74s - 355.82s | We try to understand our feasibilities to directly 356.46s - 360.62s | Attack the endpoint without going through a central hub or the satellite 361.82s - 366.86s | So our research contribution in this work. We have been reverse engineering 368.18s - 372.50s | Vsat modem it's from I direct. It's the new tech MDM 373.74s - 376.70s | 2200 that's the model we have been analyzing and 377.34s - 383.14s | We have been reverse engineering the entire software


chunk_id: 182_chunk_7
chunk_text:
presenting this year at aerospace 316.26s - 319.54s | Conference about reconnaissance how to basically 320.42s - 323.66s | Discover capabilities of satellites or last year 323.66s - 329.02s | I had an IEEE S&P Johannes was also presenting a paper that shows 329.38s - 334.14s | how you could find the vulnerabilities in satellites and try to exploit those and 335.50s - 343.10s | Then the the focus of today is to look at the threat model of an attacker the third threat model which basically 343.58s - 348.54s | Attacks directly the vSAT endpoint, and this is the new thing that we are considering in this work 349.14s - 351.14s | basically, we we 351.74s - 355.82s | We try to understand our feasibilities to directly 356.46s - 360.62s | Attack the endpoint without going through a central hub or the satellite 361.82s - 366.86s | So our research contribution in this work. We have been reverse engineering 368.18s - 372.50s | Vsat modem it's from I direct. It's the new tech MDM 373.74s - 376.70s | 2200 that's the model we have been analyzing and 377.34s - 383.14s | We have been reverse engineering the entire software stack as well as the communication protocol stack 383.62s - 385.78s | Up down to the physical layer 386.54s - 393.86s | So we found several vulnerabilities in the software and the communication stack of the modem which allows us to implement 394.58s - 402.00s | three over-the-air wireless attacks that use software-defined radios and this attacks allow us to 402.60s - 408.68s | Remotely reset the modem to update a malicious firmware to the modem and also to obtain a 409.20s - 411.20s | remote admin shell and 412.28s - 415.64s | Finally we demonstrate the feasibility of these 416.12s - 420.96s | Attacks to launch this and attacks by breaking the beam and what do we mean by breaking the beam? 421.56s - 425.24s | Basically the idea is that we inject signals 426.00s - 431.80s | from not directly from from the satellite, but from from a side beam from a 432.00s - 435.72s | Attacker that is on earth that is close to the satellite 436.36s - 440.08s | typically what people have at a conventional wisdom what people have assumed is that 440.72s - 444.88s | satellites communicate we said satellite communication as quite robust


chunk_id: 182_chunk_8
chunk_text:
stack as well as the communication protocol stack 383.62s - 385.78s | Up down to the physical layer 386.54s - 393.86s | So we found several vulnerabilities in the software and the communication stack of the modem which allows us to implement 394.58s - 402.00s | three over-the-air wireless attacks that use software-defined radios and this attacks allow us to 402.60s - 408.68s | Remotely reset the modem to update a malicious firmware to the modem and also to obtain a 409.20s - 411.20s | remote admin shell and 412.28s - 415.64s | Finally we demonstrate the feasibility of these 416.12s - 420.96s | Attacks to launch this and attacks by breaking the beam and what do we mean by breaking the beam? 421.56s - 425.24s | Basically the idea is that we inject signals 426.00s - 431.80s | from not directly from from the satellite, but from from a side beam from a 432.00s - 435.72s | Attacker that is on earth that is close to the satellite 436.36s - 440.08s | typically what people have at a conventional wisdom what people have assumed is that 440.72s - 444.88s | satellites communicate we said satellite communication as quite robust against 445.16s - 450.08s | signal injection attacks from the side because you have typically a high directional beam 450.64s - 457.58s | towards the 457.58s - 461.60s | Sorry for that 461.60s - 463.60s | Okay, am I connected? Yeah 463.88s - 465.88s | Okay, so the idea 466.88s - 473.88s | Yeah, the idea what people assume this has basically since the the dish has a very high directionality 474.80s - 476.80s | Basically, it would be difficult to inject 477.24s - 478.40s | signals 478.40s - 483.36s | From the side and what we show basically in our research is actually it's possible 483.68s - 487.52s | From the from a side beam to inject these signals these attacks 488.04s - 490.04s | from from the earth 490.28s - 495.00s | So with that I want to give the word to Johannes will present his 495.56s - 500.56s | Research or his work on reverse engineering the the modem. We've been looking at 501.08s - 504.94s | All right. Thank you. So 505.42s - 511.22s | So far, we've basically heard what kind of setup we need to actually attack these modems and as already introduced 511.22s


chunk_id: 182_chunk_9
chunk_text:
against 445.16s - 450.08s | signal injection attacks from the side because you have typically a high directional beam 450.64s - 457.58s | towards the 457.58s - 461.60s | Sorry for that 461.60s - 463.60s | Okay, am I connected? Yeah 463.88s - 465.88s | Okay, so the idea 466.88s - 473.88s | Yeah, the idea what people assume this has basically since the the dish has a very high directionality 474.80s - 476.80s | Basically, it would be difficult to inject 477.24s - 478.40s | signals 478.40s - 483.36s | From the side and what we show basically in our research is actually it's possible 483.68s - 487.52s | From the from a side beam to inject these signals these attacks 488.04s - 490.04s | from from the earth 490.28s - 495.00s | So with that I want to give the word to Johannes will present his 495.56s - 500.56s | Research or his work on reverse engineering the the modem. We've been looking at 501.08s - 504.94s | All right. Thank you. So 505.42s - 511.22s | So far, we've basically heard what kind of setup we need to actually attack these modems and as already introduced 511.22s - 517.18s | We are attacking the new tech modem MDM 2200 and we also looked at a different modem call from Viasat 517.38s - 519.50s | Exactly the one attack in Ukraine not in this talk 519.50s - 521.62s | But in the research paper, this is all based on 522.22s - 529.54s | But we picked this this I direct modem or also new I direct and it's kind of interchangeably since I direct the quiet new tech 529.54s - 533.38s | some while ago and so I direct owns all of these products at this point and 533.98s - 541.42s | There's pretty good case study since they themselves today are on the according to their website rank themselves first maritime communications in 542.10s - 545.38s | Aerospace communications or rather in the basically commercial planes 545.90s - 549.78s | Having visa systems and also in media and network broadcasting 549.78s - 555.42s | And so while it's it's pretty clear that this specific system that we are looking at here is not deployed on all of these 555.42s - 557.42s | This I want to be very clear these vulnerability 558.26s - 564.54s | These vulnerabilities


chunk_id: 182_chunk_10
chunk_text:
- 517.18s | We are attacking the new tech modem MDM 2200 and we also looked at a different modem call from Viasat 517.38s - 519.50s | Exactly the one attack in Ukraine not in this talk 519.50s - 521.62s | But in the research paper, this is all based on 522.22s - 529.54s | But we picked this this I direct modem or also new I direct and it's kind of interchangeably since I direct the quiet new tech 529.54s - 533.38s | some while ago and so I direct owns all of these products at this point and 533.98s - 541.42s | There's pretty good case study since they themselves today are on the according to their website rank themselves first maritime communications in 542.10s - 545.38s | Aerospace communications or rather in the basically commercial planes 545.90s - 549.78s | Having visa systems and also in media and network broadcasting 549.78s - 555.42s | And so while it's it's pretty clear that this specific system that we are looking at here is not deployed on all of these 555.42s - 557.42s | This I want to be very clear these vulnerability 558.26s - 564.54s | These vulnerabilities are not quite you can't go out and basically pawn every airplane with it. This definitely won't work 564.54s - 566.54s | It's a different system from the same company 567.90s - 569.62s | so 569.86s - 575.78s | Far basically, we have this visa at endpoints and it's separated into the antenna, which you basically place outdoor 575.78s - 578.34s | And that's why it's also called outdoor unit 578.54s - 584.20s | Then we have this modem this the small little box that you play somewhere inside and that's why it's called indoor unit 584.86s - 590.98s | And all of this is basically connecting your local area network where you have your PC Wi-Fi, etc 591.58s - 596.10s | So the really interesting part is really this modem in the middle because this one is basically 596.34s - 602.46s | Receiving the traffic from the satellite antenna and it's doing signal processing and it is all kinds of doing is doing all kinds of 602.74s - 604.74s | control plane management, etc 605.18s - 608.10s | And there are basically two kinds of traffic flowing through there 608.10s - 614.54s | Usually these attacks and these talks


chunk_id: 182_chunk_11
chunk_text:
are not quite you can't go out and basically pawn every airplane with it. This definitely won't work 564.54s - 566.54s | It's a different system from the same company 567.90s - 569.62s | so 569.86s - 575.78s | Far basically, we have this visa at endpoints and it's separated into the antenna, which you basically place outdoor 575.78s - 578.34s | And that's why it's also called outdoor unit 578.54s - 584.20s | Then we have this modem this the small little box that you play somewhere inside and that's why it's called indoor unit 584.86s - 590.98s | And all of this is basically connecting your local area network where you have your PC Wi-Fi, etc 591.58s - 596.10s | So the really interesting part is really this modem in the middle because this one is basically 596.34s - 602.46s | Receiving the traffic from the satellite antenna and it's doing signal processing and it is all kinds of doing is doing all kinds of 602.74s - 604.74s | control plane management, etc 605.18s - 608.10s | And there are basically two kinds of traffic flowing through there 608.10s - 614.54s | Usually these attacks and these talks at these conferences focus on internet traffic going from the antenna to this local area network 614.66s - 618.74s | But we are only and exclusively focusing on the control plane traffic 618.74s - 624.14s | And so this is oftentimes separated either with a VPN or so. It's in this in this specific case 624.14s - 629.38s | It's the same physical channel and but we are only considering the control plane basically operating these modems 629.38s - 634.50s | It has nothing to do with the actual LAN network and to keep everything that I'm going to talk about 634.82s - 638.70s | Like all nice and mapped up. I did a little chart. So basically on the left side 638.70s - 643.30s | We have the antenna and the right side our local area network and in the big in the middle a big 643.58s - 646.84s | Question mark that we are slowly trying to to resolve 647.70s - 653.46s | So first order of business as usual because it's pretty fun to open anything up. I guess most here agree 654.14s - 661.62s | It's you get a nice little circuit board. Very unsurprising and


chunk_id: 182_chunk_12
chunk_text:
at these conferences focus on internet traffic going from the antenna to this local area network 614.66s - 618.74s | But we are only and exclusively focusing on the control plane traffic 618.74s - 624.14s | And so this is oftentimes separated either with a VPN or so. It's in this in this specific case 624.14s - 629.38s | It's the same physical channel and but we are only considering the control plane basically operating these modems 629.38s - 634.50s | It has nothing to do with the actual LAN network and to keep everything that I'm going to talk about 634.82s - 638.70s | Like all nice and mapped up. I did a little chart. So basically on the left side 638.70s - 643.30s | We have the antenna and the right side our local area network and in the big in the middle a big 643.58s - 646.84s | Question mark that we are slowly trying to to resolve 647.70s - 653.46s | So first order of business as usual because it's pretty fun to open anything up. I guess most here agree 654.14s - 661.62s | It's you get a nice little circuit board. Very unsurprising and if you actually look up these individual components you see for example demodulator 661.62s - 666.78s | Which is well unsurprisingly doing demodulation. You see some digital analog converter 666.86s - 672.10s | You see an FPGA which is doing a lot of signal processing since this is way too much to be handled by these 672.26s - 679.02s | Lower and arm processors and then finally the microcontroller that we are going to focus on a some arm v5 to e microcontroller 679.98s - 683.30s | So not much progress yet. We basically just knew that there is some 683.82s - 685.82s | RF decoding signal processing 686.46s - 691.14s | Stuff going on that that I'm personally not going to focus on since I'm doing more on the software side 691.14s - 695.82s | And so what do we need for this? We actually need to dump the software off of this modem 696.42s - 698.34s | and there 698.34s - 702.42s | Plenty number of ways to do this. You could use like a bus pirate sold off the flash chips 703.06s - 707.26s | It all seems pretty involved and I'm terrible with any kind of


chunk_id: 182_chunk_13
chunk_text:
if you actually look up these individual components you see for example demodulator 661.62s - 666.78s | Which is well unsurprisingly doing demodulation. You see some digital analog converter 666.86s - 672.10s | You see an FPGA which is doing a lot of signal processing since this is way too much to be handled by these 672.26s - 679.02s | Lower and arm processors and then finally the microcontroller that we are going to focus on a some arm v5 to e microcontroller 679.98s - 683.30s | So not much progress yet. We basically just knew that there is some 683.82s - 685.82s | RF decoding signal processing 686.46s - 691.14s | Stuff going on that that I'm personally not going to focus on since I'm doing more on the software side 691.14s - 695.82s | And so what do we need for this? We actually need to dump the software off of this modem 696.42s - 698.34s | and there 698.34s - 702.42s | Plenty number of ways to do this. You could use like a bus pirate sold off the flash chips 703.06s - 707.26s | It all seems pretty involved and I'm terrible with any kind of hardware 707.26s - 711.86s | so I definitely keep my hands off of that and so instead these modems oftentimes have a 712.86s - 719.58s | Questionable web UI when it comes to security and so when we basically look for blindly basically looks for some code injection 719.58s - 722.22s | We found something obviously the code we only had afterwards 722.46s - 729.30s | but basically this entire website is written as like bash scripts and the server is basically just a bunch of bash scripts and 729.78s - 732.38s | If you basically insert the right string at the right time 732.38s - 736.86s | Then you just get a proper command injection and can just open a remote shell. It's really that simple 737.86s - 742.70s | And if you do this, then you have a nice mode and then if a nice console access to the actual modem 742.70s - 747.58s | Which is even more useful than using a bus pirate since now we can actually run commands on the modem 747.86s - 751.22s | All right. Let's actually do this. Let's figure out how all of this is working 751.82s - 756.62s |


chunk_id: 182_chunk_14
chunk_text:
hardware 707.26s - 711.86s | so I definitely keep my hands off of that and so instead these modems oftentimes have a 712.86s - 719.58s | Questionable web UI when it comes to security and so when we basically look for blindly basically looks for some code injection 719.58s - 722.22s | We found something obviously the code we only had afterwards 722.46s - 729.30s | but basically this entire website is written as like bash scripts and the server is basically just a bunch of bash scripts and 729.78s - 732.38s | If you basically insert the right string at the right time 732.38s - 736.86s | Then you just get a proper command injection and can just open a remote shell. It's really that simple 737.86s - 742.70s | And if you do this, then you have a nice mode and then if a nice console access to the actual modem 742.70s - 747.58s | Which is even more useful than using a bus pirate since now we can actually run commands on the modem 747.86s - 751.22s | All right. Let's actually do this. Let's figure out how all of this is working 751.82s - 756.62s | So in this specific case, we when we see the network interface, we see some pretty regular stuff 756.62s - 758.22s | ETH 0 pretty clear what that is 758.22s - 764.66s | We see some to end network device, which are usually for VPNs and one device that is not very common called modem 765.26s - 767.18s | So where is this coming from? 767.18s - 771.98s | So usually some these network devices come from a specific kernel and in this case 771.98s - 775.54s | There are in fact a few kernel objects that are shipped with this operating system 775.54s - 781.46s | So we have something for DVB, which is basically the protocol or the underlying protocol of all of the satellite communication 781.46s - 786.02s | So there's a pretty good hint something with new tech hardware abstraction layer also pretty good hint 786.06s - 788.86s | so we search a little bit around in these kernel objects and 789.66s - 794.10s | Yeah, we found exactly the code we were looking for. It's allocating some net device called modem 794.94s - 801.78s | Perfect. We can also look in jitra into what kind


chunk_id: 182_chunk_15
chunk_text:
So in this specific case, we when we see the network interface, we see some pretty regular stuff 756.62s - 758.22s | ETH 0 pretty clear what that is 758.22s - 764.66s | We see some to end network device, which are usually for VPNs and one device that is not very common called modem 765.26s - 767.18s | So where is this coming from? 767.18s - 771.98s | So usually some these network devices come from a specific kernel and in this case 771.98s - 775.54s | There are in fact a few kernel objects that are shipped with this operating system 775.54s - 781.46s | So we have something for DVB, which is basically the protocol or the underlying protocol of all of the satellite communication 781.46s - 786.02s | So there's a pretty good hint something with new tech hardware abstraction layer also pretty good hint 786.06s - 788.86s | so we search a little bit around in these kernel objects and 789.66s - 794.10s | Yeah, we found exactly the code we were looking for. It's allocating some net device called modem 794.94s - 801.78s | Perfect. We can also look in jitra into what kind of functions it exposing definitely some sending function not quite a receive function 801.78s - 803.78s | But it's definitely working in some way 804.38s - 808.98s | but interestingly when we kind of grab through the list of functions and search for common terms on 809.98s - 813.34s | Cryptography like encrypting decrypting key exchange, etc 813.34s - 819.22s | We didn't find anything and which is which doesn't mean that there is no encryption, but it's at least some kind of a hint 820.14s - 823.90s | So to update our system app we have these drivers exposing this modem 823.90s - 827.58s | Which doesn't seem to have any crypto and also when we went through a cold pass a little bit 827.58s - 833.10s | We couldn't find anything. So we at this point. We're just assuming it as no basically data link layer protection here 833.70s - 837.30s | And then the next question is basically what kind of applications are listening there? 837.30s - 843.02s | So this modem interface is basically exposing network traffic and easy to consume on a Linux device 843.02s - 848.30s | And you can just do accept listen


chunk_id: 182_chunk_16
chunk_text:
of functions it exposing definitely some sending function not quite a receive function 801.78s - 803.78s | But it's definitely working in some way 804.38s - 808.98s | but interestingly when we kind of grab through the list of functions and search for common terms on 809.98s - 813.34s | Cryptography like encrypting decrypting key exchange, etc 813.34s - 819.22s | We didn't find anything and which is which doesn't mean that there is no encryption, but it's at least some kind of a hint 820.14s - 823.90s | So to update our system app we have these drivers exposing this modem 823.90s - 827.58s | Which doesn't seem to have any crypto and also when we went through a cold pass a little bit 827.58s - 833.10s | We couldn't find anything. So we at this point. We're just assuming it as no basically data link layer protection here 833.70s - 837.30s | And then the next question is basically what kind of applications are listening there? 837.30s - 843.02s | So this modem interface is basically exposing network traffic and easy to consume on a Linux device 843.02s - 848.30s | And you can just do accept listen receive blah blah the usual kind of setup and then there is for example 848.70s - 853.24s | Application called TC net clients, which is some third-party software called from tele tech 853.54s - 859.02s | So they basically ensure that the internet traffic is actually running but for the control plane that I'm talking about 859.02s - 862.54s | We are caring really only about this modem controller and SW download 862.54s - 867.46s | So two software packets or two to software applications running on the modem in the first one 867.46s - 872.06s | We are going to focus on this modem controller and it kind of does exactly what the name says it controls 872.66s - 874.66s | configuration on the modem 874.70s - 876.70s | and when you basically look into the 877.26s - 878.66s | initialization routine 878.66s - 882.14s | We've kind of found what we are looking for that. There is at least some crypto 882.14s - 886.34s | So that that seems pretty good at a first glance. So we have some modem crypt in it 886.34s - 892.82s | We can see that it's reading some modem database and we


chunk_id: 182_chunk_17
chunk_text:
receive blah blah the usual kind of setup and then there is for example 848.70s - 853.24s | Application called TC net clients, which is some third-party software called from tele tech 853.54s - 859.02s | So they basically ensure that the internet traffic is actually running but for the control plane that I'm talking about 859.02s - 862.54s | We are caring really only about this modem controller and SW download 862.54s - 867.46s | So two software packets or two to software applications running on the modem in the first one 867.46s - 872.06s | We are going to focus on this modem controller and it kind of does exactly what the name says it controls 872.66s - 874.66s | configuration on the modem 874.70s - 876.70s | and when you basically look into the 877.26s - 878.66s | initialization routine 878.66s - 882.14s | We've kind of found what we are looking for that. There is at least some crypto 882.14s - 886.34s | So that that seems pretty good at a first glance. So we have some modem crypt in it 886.34s - 892.82s | We can see that it's reading some modem database and we can also see that it's using some private key pushing it somewhere 892.86s - 897.46s | Okay, so there seems to be something going on with crypto, but I won't bore you with code all all the time 897.58s - 899.18s | So 899.18s - 901.78s | Basically, it's receiving a terminal private key 901.78s - 907.30s | The terminal private key is exchanged when you first turn on this modem after you receive it from your satellite service provider 907.30s - 913.24s | So it's exchanging this thing and then storing it kind of permanently on your device and then whenever you boot it up 913.58s - 919.14s | It's loading this key and it's using this key as a key encryption key. What does a key encryption key do? 919.14s - 923.06s | It encrypts keys and basically when you start up the modem 923.06s - 927.14s | You receive two messages one session key message and one network configuration message 927.22s - 934.42s | both of them control that key that is actually used to encrypt this specific traffic and a terminal private keys encoding both of these and 934.86s - 939.74s | It works in a


chunk_id: 182_chunk_18
chunk_text:
can also see that it's using some private key pushing it somewhere 892.86s - 897.46s | Okay, so there seems to be something going on with crypto, but I won't bore you with code all all the time 897.58s - 899.18s | So 899.18s - 901.78s | Basically, it's receiving a terminal private key 901.78s - 907.30s | The terminal private key is exchanged when you first turn on this modem after you receive it from your satellite service provider 907.30s - 913.24s | So it's exchanging this thing and then storing it kind of permanently on your device and then whenever you boot it up 913.58s - 919.14s | It's loading this key and it's using this key as a key encryption key. What does a key encryption key do? 919.14s - 923.06s | It encrypts keys and basically when you start up the modem 923.06s - 927.14s | You receive two messages one session key message and one network configuration message 927.22s - 934.42s | both of them control that key that is actually used to encrypt this specific traffic and a terminal private keys encoding both of these and 934.86s - 939.74s | It works in a way that basically we have to hop and hop is sending a packet to the actual modem controller 940.14s - 944.04s | In some hub terminal envelope, which is some Google proto buff protocol 944.58s - 950.14s | And when we're looking at the code first line basically passes this proto buff into some predefined data structure 950.50s - 954.78s | And then it's doing some interesting stuff. So first it's basically looking for some encryption flag 954.78s - 958.90s | If it's not set it's basically discarding the packets if it's set it's going on 959.22s - 963.54s | It's checking is the counter of the packet defined in this network packet zero 963.98s - 969.70s | Then it's pretty interesting we define or we just assign the buffer to the message string if it's not zero 969.90s - 976.10s | Then we actually decrypt it. So at least from this function if we set it to zero, we can just skip the 976.62s - 978.86s | Decryption which is useful since we don't know the key 979.86s - 984.70s | But there's definitely something more to it since if you just have counter zero 984.70s - 989.14s |


chunk_id: 182_chunk_19
chunk_text:
way that basically we have to hop and hop is sending a packet to the actual modem controller 940.14s - 944.04s | In some hub terminal envelope, which is some Google proto buff protocol 944.58s - 950.14s | And when we're looking at the code first line basically passes this proto buff into some predefined data structure 950.50s - 954.78s | And then it's doing some interesting stuff. So first it's basically looking for some encryption flag 954.78s - 958.90s | If it's not set it's basically discarding the packets if it's set it's going on 959.22s - 963.54s | It's checking is the counter of the packet defined in this network packet zero 963.98s - 969.70s | Then it's pretty interesting we define or we just assign the buffer to the message string if it's not zero 969.90s - 976.10s | Then we actually decrypt it. So at least from this function if we set it to zero, we can just skip the 976.62s - 978.86s | Decryption which is useful since we don't know the key 979.86s - 984.70s | But there's definitely something more to it since if you just have counter zero 984.70s - 989.14s | It might just be some key exchange protocol in the very beginning. So there might be some 990.02s - 993.58s | Receive counter matching going on and that is exactly what we found 993.94s - 1001.30s | so basically there's encryption manager and it has a receive counter match functionality and it takes the encryption manager and a packet counter and 1001.42s - 1007.92s | Compares is it the actual expected counter? So if the previous one is 68 it expects the next one to be 69 1008.64s - 1012.04s | That that sounds pretty nice. It sounds exactly like what we are looking for 1012.04s - 1018.68s | and if we have to if the match is false, it's doing a second check which checks if the counter is unequal to zero and 1019.28s - 1026.12s | Only then it's discarding the message, but interesting part is if the counter is zero, then it's not discarding the message 1026.12s - 1032.56s | So basically this kind of exactly the thing that it's trying to prevent. It's not preventing. I guess there's some coding error 1032.56s - 1037.84s | They probably meant to use some other counter probably the reference


chunk_id: 182_chunk_20
chunk_text:
It might just be some key exchange protocol in the very beginning. So there might be some 990.02s - 993.58s | Receive counter matching going on and that is exactly what we found 993.94s - 1001.30s | so basically there's encryption manager and it has a receive counter match functionality and it takes the encryption manager and a packet counter and 1001.42s - 1007.92s | Compares is it the actual expected counter? So if the previous one is 68 it expects the next one to be 69 1008.64s - 1012.04s | That that sounds pretty nice. It sounds exactly like what we are looking for 1012.04s - 1018.68s | and if we have to if the match is false, it's doing a second check which checks if the counter is unequal to zero and 1019.28s - 1026.12s | Only then it's discarding the message, but interesting part is if the counter is zero, then it's not discarding the message 1026.12s - 1032.56s | So basically this kind of exactly the thing that it's trying to prevent. It's not preventing. I guess there's some coding error 1032.56s - 1037.84s | They probably meant to use some other counter probably the reference counter from the modem and not the one from the packets 1038.24s - 1043.64s | But yeah, this basically allows us to kind of bypass the entire encryption of this modem controller 1043.64s - 1046.14s | Which is maybe not quite as it was intended or maybe it was 1047.72s - 1054.44s | All right, second part is this SW download application software updates are always fun from a security perspective, so let's take a look at that 1055.52s - 1059.64s | So we have to hop and the hop is basically sending out update signal packets 1059.84s - 1065.84s | Around once a second or ten times a second depending on the configuration and these update signal packets basically tell you hey 1065.84s - 1070.20s | There's currently this software version available for this hardware revision on this port 1070.20s - 1075.44s | So if you want to get it, just listen to me and an SW download decides this sounds interesting 1075.44s - 1082.00s | I want to receive these packets and it's just subscribing to the correct multicast on a correct port and gets the current software version 1083.20s - 1084.64s | Interestingly, there's no crypto on


chunk_id: 182_chunk_21
chunk_text:
counter from the modem and not the one from the packets 1038.24s - 1043.64s | But yeah, this basically allows us to kind of bypass the entire encryption of this modem controller 1043.64s - 1046.14s | Which is maybe not quite as it was intended or maybe it was 1047.72s - 1054.44s | All right, second part is this SW download application software updates are always fun from a security perspective, so let's take a look at that 1055.52s - 1059.64s | So we have to hop and the hop is basically sending out update signal packets 1059.84s - 1065.84s | Around once a second or ten times a second depending on the configuration and these update signal packets basically tell you hey 1065.84s - 1070.20s | There's currently this software version available for this hardware revision on this port 1070.20s - 1075.44s | So if you want to get it, just listen to me and an SW download decides this sounds interesting 1075.44s - 1082.00s | I want to receive these packets and it's just subscribing to the correct multicast on a correct port and gets the current software version 1083.20s - 1084.64s | Interestingly, there's no crypto on that 1084.64s - 1089.96s | That's just UDP packets and anybody can just go to any modem and essentially just broadcast their own software update 1090.72s - 1094.00s | But in just in case you're too lazy to kind of build your own 1094.36s - 1098.64s | Linux operating system interface with the FPGA and everything it gets easier and 1099.36s - 1101.36s | worse from a security perspective 1101.72s - 1106.26s | So this also it's a vulnerability if missing encryption authentication is not enough 1106.80s - 1109.44s | Basically, this is one of these update signaling packets 1109.68s - 1115.84s | It's basically saying case some you image ID then it says octet for whatever reason and then it says, okay 1115.84s - 1119.00s | There's a bulk size as a version that is associated with this specific update 1119.12s - 1125.28s | There's a minimal version that you need etc. And this octet part is pretty interesting since this is the function that is passing this 1125.28s - 1131.32s | I'm not making this up. And so basically has a static buffer of 80 bytes and then it's using a scan F with 1132.16s - 1137.04s |


chunk_id: 182_chunk_22
chunk_text:
that 1084.64s - 1089.96s | That's just UDP packets and anybody can just go to any modem and essentially just broadcast their own software update 1090.72s - 1094.00s | But in just in case you're too lazy to kind of build your own 1094.36s - 1098.64s | Linux operating system interface with the FPGA and everything it gets easier and 1099.36s - 1101.36s | worse from a security perspective 1101.72s - 1106.26s | So this also it's a vulnerability if missing encryption authentication is not enough 1106.80s - 1109.44s | Basically, this is one of these update signaling packets 1109.68s - 1115.84s | It's basically saying case some you image ID then it says octet for whatever reason and then it says, okay 1115.84s - 1119.00s | There's a bulk size as a version that is associated with this specific update 1119.12s - 1125.28s | There's a minimal version that you need etc. And this octet part is pretty interesting since this is the function that is passing this 1125.28s - 1131.32s | I'm not making this up. And so basically has a static buffer of 80 bytes and then it's using a scan F with 1132.16s - 1137.04s | Unlimited length string to pass this octet just this octet part 1138.04s - 1145.24s | Well pretty pretty easy from that parts to to gain some kind of control over the PC, but it shouldn't be that simple, right? 1145.24s - 1148.24s | There's still a SLR secondary. So it's something like that 1149.36s - 1152.08s | Turns out they're using an ancient Linux version 1152.88s - 1157.84s | Version two point six point thirty five of the kernel and now some of you might be thinking but hey 1157.84s - 1163.56s | Why is this guy talking about some ancient technology that nobody or that that they found on some scrapyard? 1163.56s - 1170.82s | No, this was freshly installed for us in 2022. So this is not something super old. This is something they newly shipped to customers 1171.46s - 1176.06s | And also their office, you know secondary is because if you have Linux two point six point thirty five 1176.06s - 1178.06s | You probably don't bother about this part anyway 1179.22s - 1184.88s | So to conclude first, there's no data link protection in the in this modem kernel device 1185.14s - 1190.98s | There


chunk_id: 182_chunk_23
chunk_text:
Unlimited length string to pass this octet just this octet part 1138.04s - 1145.24s | Well pretty pretty easy from that parts to to gain some kind of control over the PC, but it shouldn't be that simple, right? 1145.24s - 1148.24s | There's still a SLR secondary. So it's something like that 1149.36s - 1152.08s | Turns out they're using an ancient Linux version 1152.88s - 1157.84s | Version two point six point thirty five of the kernel and now some of you might be thinking but hey 1157.84s - 1163.56s | Why is this guy talking about some ancient technology that nobody or that that they found on some scrapyard? 1163.56s - 1170.82s | No, this was freshly installed for us in 2022. So this is not something super old. This is something they newly shipped to customers 1171.46s - 1176.06s | And also their office, you know secondary is because if you have Linux two point six point thirty five 1176.06s - 1178.06s | You probably don't bother about this part anyway 1179.22s - 1184.88s | So to conclude first, there's no data link protection in the in this modem kernel device 1185.14s - 1190.98s | There is an encryption bypass on a modem controller, which is the only part in the control plane actually implementing crypto 1191.50s - 1194.86s | We can just broadcast updates as we want to this modem 1194.86s - 1199.16s | And if this is not enough, we can also have a fully unmitigated remote code execution 1200.04s - 1203.68s | And we kind of tested all of this on a little bit wacky way basically 1203.68s - 1208.44s | We are using the Ethernet port and reconfigure the fireball to send the packets to the to this modem network device 1209.08s - 1213.88s | for for easier testing, but obviously way more interesting approach is to actually do it wirelessly and 1214.56s - 1219.40s | What does a PhD student do when he doesn't want to figure out all of the wireless parts? 1219.48s - 1223.44s | Find a perfect student to actually figure it out. And this is a Robins turn now 1226.48s - 1230.28s | Yeah, so let's address this remaining question mark 1232.00s - 1237.56s | For this we started again by opening up this box looking at what components are built in and 1238.24s - 1244.36s |


chunk_id: 182_chunk_24
chunk_text:
is an encryption bypass on a modem controller, which is the only part in the control plane actually implementing crypto 1191.50s - 1194.86s | We can just broadcast updates as we want to this modem 1194.86s - 1199.16s | And if this is not enough, we can also have a fully unmitigated remote code execution 1200.04s - 1203.68s | And we kind of tested all of this on a little bit wacky way basically 1203.68s - 1208.44s | We are using the Ethernet port and reconfigure the fireball to send the packets to the to this modem network device 1209.08s - 1213.88s | for for easier testing, but obviously way more interesting approach is to actually do it wirelessly and 1214.56s - 1219.40s | What does a PhD student do when he doesn't want to figure out all of the wireless parts? 1219.48s - 1223.44s | Find a perfect student to actually figure it out. And this is a Robins turn now 1226.48s - 1230.28s | Yeah, so let's address this remaining question mark 1232.00s - 1237.56s | For this we started again by opening up this box looking at what components are built in and 1238.24s - 1244.36s | researching via their tech sheets and all resources we found how the hardware works and 1244.92s - 1246.92s | From this we could already 1247.28s - 1254.96s | Deduct that there are two separate signal processing pipelines one for the transmission and one for reception 1255.48s - 1261.23s | in addition we had a handy tool in the web interface a 1261.75s - 1269.51s | Diagnostic screen which provided us with the internal states of the modem including some states from the FPGA and 1270.83s - 1277.03s | This confirmed our protocol assumptions and it proved to be very helpful when implementing our attacker 1277.55s - 1282.55s | since we could see what packets have been parsed correctly and what isn't working yet and 1284.43s - 1288.03s | Finally we had the binaries thanks to Joanna's work 1288.95s - 1293.27s | Which also proved very helpful since some of the parsing logic 1293.79s - 1300.67s | Was implemented in the kernel modules. So not on dedicated ICS and by studying that we 1301.23s - 1304.59s | Could know what the modem expected us to transmit 1306.67s - 1308.19s | with these 1308.19s - 1314.75s | Three information sources. It became


chunk_id: 182_chunk_25
chunk_text:
researching via their tech sheets and all resources we found how the hardware works and 1244.92s - 1246.92s | From this we could already 1247.28s - 1254.96s | Deduct that there are two separate signal processing pipelines one for the transmission and one for reception 1255.48s - 1261.23s | in addition we had a handy tool in the web interface a 1261.75s - 1269.51s | Diagnostic screen which provided us with the internal states of the modem including some states from the FPGA and 1270.83s - 1277.03s | This confirmed our protocol assumptions and it proved to be very helpful when implementing our attacker 1277.55s - 1282.55s | since we could see what packets have been parsed correctly and what isn't working yet and 1284.43s - 1288.03s | Finally we had the binaries thanks to Joanna's work 1288.95s - 1293.27s | Which also proved very helpful since some of the parsing logic 1293.79s - 1300.67s | Was implemented in the kernel modules. So not on dedicated ICS and by studying that we 1301.23s - 1304.59s | Could know what the modem expected us to transmit 1306.67s - 1308.19s | with these 1308.19s - 1314.75s | Three information sources. It became pretty clear that the protocol used here is DVB RCS 1315.31s - 1317.31s | the DVB 1317.87s - 1321.19s | Protocol suite comes from the TV broadcasting domain 1321.35s - 1326.91s | But what's more important here is the RCS which stands for return channel over satellite 1327.59s - 1333.43s | because we don't want to have these one-way transmissions, but we need a return channel for the 1334.15s - 1335.31s | interactive 1335.31s - 1337.23s | internet protocol 1337.23s - 1339.23s | behavior 1339.27s - 1342.67s | What's best about this protocol is also that it's open and 1343.31s - 1348.39s | That's why there are lots of resources and specifications which are freely available 1350.55s - 1352.19s | Also, it's 1352.19s - 1357.91s | kind of a meta protocol because it leverages multiple sub protocols and 1358.15s - 1360.95s | Defines how these sub protocols interact with each other 1362.39s - 1370.23s | In this regard it's also important to mention s3p or set three play because new tech never talks about DVB RCS 1370.23s - 1375.79s | but s3 play which is their proprietary implementation of DVB RCS and 1376.83s - 1382.07s | Since it's their own


chunk_id: 182_chunk_26
chunk_text:
pretty clear that the protocol used here is DVB RCS 1315.31s - 1317.31s | the DVB 1317.87s - 1321.19s | Protocol suite comes from the TV broadcasting domain 1321.35s - 1326.91s | But what's more important here is the RCS which stands for return channel over satellite 1327.59s - 1333.43s | because we don't want to have these one-way transmissions, but we need a return channel for the 1334.15s - 1335.31s | interactive 1335.31s - 1337.23s | internet protocol 1337.23s - 1339.23s | behavior 1339.27s - 1342.67s | What's best about this protocol is also that it's open and 1343.31s - 1348.39s | That's why there are lots of resources and specifications which are freely available 1350.55s - 1352.19s | Also, it's 1352.19s - 1357.91s | kind of a meta protocol because it leverages multiple sub protocols and 1358.15s - 1360.95s | Defines how these sub protocols interact with each other 1362.39s - 1370.23s | In this regard it's also important to mention s3p or set three play because new tech never talks about DVB RCS 1370.23s - 1375.79s | but s3 play which is their proprietary implementation of DVB RCS and 1376.83s - 1382.07s | Since it's their own implementation and proprietary there are some uniquenesses to it 1382.15s - 1389.91s | so in some instances we found that they deviated a little bit from the specification or they used some custom features to 1390.71s - 1394.91s | transmit some other compulsory data, which is required and 1395.15s - 1403.64s | And now let's quickly go through these layers at the lowest layer with DVB s2 1404.36s - 1407.72s | Which is the protocol which handles all the wireless stuff? 1408.04s - 1411.04s | So if you're a bit familiar with these wireless protocols 1411.04s - 1417.16s | It has all these basic features such as pretending a preamble to synchronize 1417.60s - 1425.16s | Transmitter and receiver it defines what modulation schemes are supported and it also defines the error correction codes 1427.41s - 1430.93s | One layer higher up we have MPEG transport streams 1430.93s - 1436.65s | And their task is to bundle multiple data streams into one 1437.17s - 1439.17s | bigger stream and 1440.37s - 1444.61s | In this project we've only implemented the forward channel 1444.61s - 1445.69s | so I'm 1445.69s - 1448.57s | focusing on this forward channel from central hub


chunk_id: 182_chunk_27
chunk_text:
implementation and proprietary there are some uniquenesses to it 1382.15s - 1389.91s | so in some instances we found that they deviated a little bit from the specification or they used some custom features to 1390.71s - 1394.91s | transmit some other compulsory data, which is required and 1395.15s - 1403.64s | And now let's quickly go through these layers at the lowest layer with DVB s2 1404.36s - 1407.72s | Which is the protocol which handles all the wireless stuff? 1408.04s - 1411.04s | So if you're a bit familiar with these wireless protocols 1411.04s - 1417.16s | It has all these basic features such as pretending a preamble to synchronize 1417.60s - 1425.16s | Transmitter and receiver it defines what modulation schemes are supported and it also defines the error correction codes 1427.41s - 1430.93s | One layer higher up we have MPEG transport streams 1430.93s - 1436.65s | And their task is to bundle multiple data streams into one 1437.17s - 1439.17s | bigger stream and 1440.37s - 1444.61s | In this project we've only implemented the forward channel 1444.61s - 1445.69s | so I'm 1445.69s - 1448.57s | focusing on this forward channel from central hub to 1449.17s - 1455.01s | Endpoints and since we have this star topology where one central hub transmits to multiple 1455.61s - 1462.25s | Endpoints it's implemented as a broadcast channel that contains all these individual data streams, and that's why this 1462.77s - 1464.77s | MPEG transport streams are so useful 1465.29s - 1472.01s | They are constructed in a hierarchical way at the lowest layer or lowest level there are elementary streams 1472.01s - 1475.53s | Which could be audio streams or video streams or in our? 1476.29s - 1482.09s | context data streams these elementary streams are then bundled together to programs and 1482.77s - 1488.61s | A transport stream can finally be made up of multiples of these programs 1489.65s - 1494.81s | There's also some space for metadata or some configuration data 1494.97s - 1500.77s | Which is used to transmit the structure of these streams, but also to initialize the modem 1503.48s - 1510.80s | Because when the modem starts up it starts in a in an empty state and awaits instruction from the central hub 1511.64s - 1516.76s | It has some pre-configured values such as a frequency and a symbol rate 1517.40s


chunk_id: 182_chunk_28
chunk_text:
to 1449.17s - 1455.01s | Endpoints and since we have this star topology where one central hub transmits to multiple 1455.61s - 1462.25s | Endpoints it's implemented as a broadcast channel that contains all these individual data streams, and that's why this 1462.77s - 1464.77s | MPEG transport streams are so useful 1465.29s - 1472.01s | They are constructed in a hierarchical way at the lowest layer or lowest level there are elementary streams 1472.01s - 1475.53s | Which could be audio streams or video streams or in our? 1476.29s - 1482.09s | context data streams these elementary streams are then bundled together to programs and 1482.77s - 1488.61s | A transport stream can finally be made up of multiples of these programs 1489.65s - 1494.81s | There's also some space for metadata or some configuration data 1494.97s - 1500.77s | Which is used to transmit the structure of these streams, but also to initialize the modem 1503.48s - 1510.80s | Because when the modem starts up it starts in a in an empty state and awaits instruction from the central hub 1511.64s - 1516.76s | It has some pre-configured values such as a frequency and a symbol rate 1517.40s - 1520.24s | For where to expect these initial values 1520.24s - 1526.84s | And this is called the initial carrier and with this information transmitted on this carrier it learns 1527.12s - 1529.04s | Where to tune next? 1529.04s - 1536.44s | To learn the configuration values for the final carrier where the data streams are finally transmitted 1537.36s - 1544.72s | In our attacker implementation we simplified things quite a bit, so we didn't transmit on three separate frequencies 1544.88s - 1548.64s | but we use this flexibility of this transport streams to 1549.36s - 1555.40s | Include all this information from the beginning and instruct the modem to retune over and over again 1555.76s - 1561.72s | But each time the multiplex a different stream from within this same transport stream 1562.52s - 1563.76s | and 1563.76s - 1570.32s | This is like basically the high-level overview of this protocol. There's only one thing left which is 1570.84s - 1576.56s | Called multi protocol encapsulation which is a thin wrapper around the IP packets 1576.72s - 1579.84s | Such that they can be included in these MPEG transport streams 1580.40s - 1583.88s | But from there on


chunk_id: 182_chunk_29
chunk_text:
- 1520.24s | For where to expect these initial values 1520.24s - 1526.84s | And this is called the initial carrier and with this information transmitted on this carrier it learns 1527.12s - 1529.04s | Where to tune next? 1529.04s - 1536.44s | To learn the configuration values for the final carrier where the data streams are finally transmitted 1537.36s - 1544.72s | In our attacker implementation we simplified things quite a bit, so we didn't transmit on three separate frequencies 1544.88s - 1548.64s | but we use this flexibility of this transport streams to 1549.36s - 1555.40s | Include all this information from the beginning and instruct the modem to retune over and over again 1555.76s - 1561.72s | But each time the multiplex a different stream from within this same transport stream 1562.52s - 1563.76s | and 1563.76s - 1570.32s | This is like basically the high-level overview of this protocol. There's only one thing left which is 1570.84s - 1576.56s | Called multi protocol encapsulation which is a thin wrapper around the IP packets 1576.72s - 1579.84s | Such that they can be included in these MPEG transport streams 1580.40s - 1583.88s | But from there on up it's really basic internet protocols IP 1584.60s - 1586.28s | UDP and TCP 1586.28s - 1595.43s | So with this knowledge and the understanding of these protocols we attempted our attacker implementation 1596.35s - 1600.27s | We chose a software-defined radio based stack we 1601.03s - 1603.03s | opted for a USRP 1603.63s - 1607.51s | SDR, but really any other SDR could be chosen as well and 1608.55s - 1612.83s | Since SDRs are somewhat restricted in their output frequencies 1612.91s - 1620.59s | We also bought some off-the-shelf components for up converting these frequencies into the satellite frequency bands 1620.99s - 1625.27s | For this modem, that's the KU and KA bands at roughly 1625.79s - 1631.59s | 10 to 10.7 gigahertz or I believe even up to 15 gigahertz and 1632.79s - 1634.99s | this totaled in a cost of about 1635.63s - 1637.43s | $2,000 but 1637.43s - 1645.19s | I'm pretty sure that it could be significantly reduced if you used more do-it-yourself approach and didn't buy off-the-shelf components 1645.75s - 1650.89s | For the software implementation we chose GNU radio 1651.69s - 1656.37s | Popular framework for SDR applications and as already mentioned


chunk_id: 182_chunk_30
chunk_text:
up it's really basic internet protocols IP 1584.60s - 1586.28s | UDP and TCP 1586.28s - 1595.43s | So with this knowledge and the understanding of these protocols we attempted our attacker implementation 1596.35s - 1600.27s | We chose a software-defined radio based stack we 1601.03s - 1603.03s | opted for a USRP 1603.63s - 1607.51s | SDR, but really any other SDR could be chosen as well and 1608.55s - 1612.83s | Since SDRs are somewhat restricted in their output frequencies 1612.91s - 1620.59s | We also bought some off-the-shelf components for up converting these frequencies into the satellite frequency bands 1620.99s - 1625.27s | For this modem, that's the KU and KA bands at roughly 1625.79s - 1631.59s | 10 to 10.7 gigahertz or I believe even up to 15 gigahertz and 1632.79s - 1634.99s | this totaled in a cost of about 1635.63s - 1637.43s | $2,000 but 1637.43s - 1645.19s | I'm pretty sure that it could be significantly reduced if you used more do-it-yourself approach and didn't buy off-the-shelf components 1645.75s - 1650.89s | For the software implementation we chose GNU radio 1651.69s - 1656.37s | Popular framework for SDR applications and as already mentioned 1656.37s - 1662.13s | we only implemented the forward channel since this what proved to be sufficient for our attacks and 1662.85s - 1666.61s | Can radio was also chosen since we could leverage some of the 1667.49s - 1674.45s | built-in components for DVB s2, but everything on top of it. We implemented ourselves in a custom module and 1677.81s - 1679.81s | Through this approach we 1679.97s - 1687.97s | Started at a state where the modern modem wasn't connected, but we iteratively improved our attacker to be able to finally 1688.65s - 1695.97s | transmit some initialization such that the modem picked up the signal and finally we were able to transmit 1696.61s - 1704.37s | Some messages here. You see a TCB dump on the modem itself and it successfully receives some hello world packages 1704.37s - 1705.81s | We are transmitting 1705.81s - 1716.24s | So if we briefly look again at this map 1716.64s - 1723.04s | We are now capable of injecting arbitrary IP packets into the modems protocol 1723.80s - 1725.80s | into the modems network stack 1728.16s - 1730.16s | Now, let's look at some attacks 1730.56s - 1735.52s | the


chunk_id: 182_chunk_31
chunk_text:
1656.37s - 1662.13s | we only implemented the forward channel since this what proved to be sufficient for our attacks and 1662.85s - 1666.61s | Can radio was also chosen since we could leverage some of the 1667.49s - 1674.45s | built-in components for DVB s2, but everything on top of it. We implemented ourselves in a custom module and 1677.81s - 1679.81s | Through this approach we 1679.97s - 1687.97s | Started at a state where the modern modem wasn't connected, but we iteratively improved our attacker to be able to finally 1688.65s - 1695.97s | transmit some initialization such that the modem picked up the signal and finally we were able to transmit 1696.61s - 1704.37s | Some messages here. You see a TCB dump on the modem itself and it successfully receives some hello world packages 1704.37s - 1705.81s | We are transmitting 1705.81s - 1716.24s | So if we briefly look again at this map 1716.64s - 1723.04s | We are now capable of injecting arbitrary IP packets into the modems protocol 1723.80s - 1725.80s | into the modems network stack 1728.16s - 1730.16s | Now, let's look at some attacks 1730.56s - 1735.52s | the first most basic one we are talking about is a jamming attack, but it is 1736.28s - 1740.84s | Interesting in in this case because it acts as a building block for more advanced attacks 1741.80s - 1745.32s | Because when we jam a modem it no longer 1745.84s - 1749.60s | receives the required synchrony synchronization packets and 1750.20s - 1753.20s | Configuration packets and as a result it 1753.84s - 1758.64s | resets itself to the initial state and awaits new connection instructions and 1760.04s - 1765.40s | this can be used by an attacker to break the connection of a running modem and 1765.84s - 1773.76s | Then provide new initialization instructions to steer it away from the legitimate central hub to a malicious one and 1775.84s - 1780.16s | Once initialized we can mount a malicious firmware update 1780.92s - 1782.64s | attack as 1782.64s - 1788.36s | Joannes has explained before this works by first transmitting a signalization packet 1789.00s - 1791.12s | to one of these internal binaries 1791.84s - 1793.44s | SW download 1793.44s - 1801.64s | To signal that an update is available. What version is available and on what port on


chunk_id: 182_chunk_32
chunk_text:
first most basic one we are talking about is a jamming attack, but it is 1736.28s - 1740.84s | Interesting in in this case because it acts as a building block for more advanced attacks 1741.80s - 1745.32s | Because when we jam a modem it no longer 1745.84s - 1749.60s | receives the required synchrony synchronization packets and 1750.20s - 1753.20s | Configuration packets and as a result it 1753.84s - 1758.64s | resets itself to the initial state and awaits new connection instructions and 1760.04s - 1765.40s | this can be used by an attacker to break the connection of a running modem and 1765.84s - 1773.76s | Then provide new initialization instructions to steer it away from the legitimate central hub to a malicious one and 1775.84s - 1780.16s | Once initialized we can mount a malicious firmware update 1780.92s - 1782.64s | attack as 1782.64s - 1788.36s | Joannes has explained before this works by first transmitting a signalization packet 1789.00s - 1791.12s | to one of these internal binaries 1791.84s - 1793.44s | SW download 1793.44s - 1801.64s | To signal that an update is available. What version is available and on what port on what UDP port to receive it and 1802.24s - 1809.08s | if this version is higher than the currently installed version the modem will start listening on that port and 1809.80s - 1811.80s | receive these messages and 1811.96s - 1818.24s | Once again to I want to emphasize that these messages are neither authenticated nor encrypted 1818.28s - 1820.40s | So it's easy to exploit this 1821.20s - 1823.96s | And that's what we did. We transmitted a 1824.60s - 1830.64s | Malicious update and as you can see in the logs it correctly receives these packets 1831.12s - 1833.56s | It and it tries to install them 1834.20s - 1840.44s | But we set in this case an invalid checksum to prevent the modem from breaking 1840.64s - 1845.80s | since we had we needed to use it afterwards as well, but this proves that 1846.80s - 1852.60s | A malicious firmware can be installed to basically do arbitrary damage 1853.32s - 1855.04s | also to just 1855.04s - 1857.04s | Execute the denial-of-service attack 1857.48s - 1866.55s | The second attack I want to talk about is a remote code execution attack where we leverage the buffer


chunk_id: 182_chunk_33
chunk_text:
what UDP port to receive it and 1802.24s - 1809.08s | if this version is higher than the currently installed version the modem will start listening on that port and 1809.80s - 1811.80s | receive these messages and 1811.96s - 1818.24s | Once again to I want to emphasize that these messages are neither authenticated nor encrypted 1818.28s - 1820.40s | So it's easy to exploit this 1821.20s - 1823.96s | And that's what we did. We transmitted a 1824.60s - 1830.64s | Malicious update and as you can see in the logs it correctly receives these packets 1831.12s - 1833.56s | It and it tries to install them 1834.20s - 1840.44s | But we set in this case an invalid checksum to prevent the modem from breaking 1840.64s - 1845.80s | since we had we needed to use it afterwards as well, but this proves that 1846.80s - 1852.60s | A malicious firmware can be installed to basically do arbitrary damage 1853.32s - 1855.04s | also to just 1855.04s - 1857.04s | Execute the denial-of-service attack 1857.48s - 1866.55s | The second attack I want to talk about is a remote code execution attack where we leverage the buffer overflow 1866.99s - 1872.39s | Vulnerability Joannes has explained and we implemented this one with two payloads 1872.67s - 1880.91s | One where we simply turn on an LED on the modem to have a visual indication and the second one where we opened a 1880.91s - 1882.95s | reverse shell towards a host in the LAN 1883.95s - 1885.35s | but 1885.35s - 1887.35s | Thank you 1887.43s - 1894.31s | but if the modem would be connected via return channel to the central hub 1894.91s - 1898.31s | Such a reverse shell could also be opened to any connected host 1898.47s - 1902.99s | We chose a host in the LAN because we haven't initialized the return channel 1904.47s - 1910.23s | Now next I want to quickly show a demo of this attack it's this remote code execution and we 1911.55s - 1914.19s | Implemented here the LED turn on 1915.03s - 1918.43s | So that the transmission LED on the modem lights lightens up 1918.43s - 1924.23s | It wouldn't turn on in this case because as mentioned again, the return channel isn't initialized 1925.51s - 1927.51s | So here you see our attacker 1927.83s -


chunk_id: 182_chunk_34
chunk_text:
overflow 1866.99s - 1872.39s | Vulnerability Joannes has explained and we implemented this one with two payloads 1872.67s - 1880.91s | One where we simply turn on an LED on the modem to have a visual indication and the second one where we opened a 1880.91s - 1882.95s | reverse shell towards a host in the LAN 1883.95s - 1885.35s | but 1885.35s - 1887.35s | Thank you 1887.43s - 1894.31s | but if the modem would be connected via return channel to the central hub 1894.91s - 1898.31s | Such a reverse shell could also be opened to any connected host 1898.47s - 1902.99s | We chose a host in the LAN because we haven't initialized the return channel 1904.47s - 1910.23s | Now next I want to quickly show a demo of this attack it's this remote code execution and we 1911.55s - 1914.19s | Implemented here the LED turn on 1915.03s - 1918.43s | So that the transmission LED on the modem lights lightens up 1918.43s - 1924.23s | It wouldn't turn on in this case because as mentioned again, the return channel isn't initialized 1925.51s - 1927.51s | So here you see our attacker 1927.83s - 1929.83s | the canoe radio implementation 1930.59s - 1936.95s | Which starts transmitting and the up converter set up and on the other side of the room? 1936.99s - 1941.15s | there's the transmitter with the web interface open and 1943.07s - 1945.43s | It should pick up the signal any moment 1946.71s - 1949.39s | initialize itself and 1950.95s - 1957.07s | Once receiving the data the transmission LED the second from the right lightens up 1957.51s - 1969.59s | So this works 1969.59s - 1975.79s | Finally, we wanted to explore the conditions under which such an attack can be 1976.47s - 1979.03s | successfully mounted and for this we 1980.03s - 1986.43s | transmitted from different angles both in the horizontal plane and in the vertical plane to find out if 1986.79s - 1988.47s | Such an attack is successful 1988.47s - 1995.23s | Not only from in front of the modem because because the antenna is a directional antenna and must be directly 1995.83s - 1997.47s | Targeted at the satellite 1997.47s - 2002.67s | So it would be much more powerful if we can launch such an attack also from other angles 2002.67s - 2008.47s


chunk_id: 182_chunk_35
chunk_text:
1929.83s | the canoe radio implementation 1930.59s - 1936.95s | Which starts transmitting and the up converter set up and on the other side of the room? 1936.99s - 1941.15s | there's the transmitter with the web interface open and 1943.07s - 1945.43s | It should pick up the signal any moment 1946.71s - 1949.39s | initialize itself and 1950.95s - 1957.07s | Once receiving the data the transmission LED the second from the right lightens up 1957.51s - 1969.59s | So this works 1969.59s - 1975.79s | Finally, we wanted to explore the conditions under which such an attack can be 1976.47s - 1979.03s | successfully mounted and for this we 1980.03s - 1986.43s | transmitted from different angles both in the horizontal plane and in the vertical plane to find out if 1986.79s - 1988.47s | Such an attack is successful 1988.47s - 1995.23s | Not only from in front of the modem because because the antenna is a directional antenna and must be directly 1995.83s - 1997.47s | Targeted at the satellite 1997.47s - 2002.67s | So it would be much more powerful if we can launch such an attack also from other angles 2002.67s - 2008.47s | And we found that there is a range of angles from where such an attack can be 2008.99s - 2014.15s | Successfully mounted not only from directly in front of it here shown in green 2015.27s - 2020.43s | also, keep in mind that this data has been gathered in an anechoic chamber where 2021.27s - 2027.95s | Reflections are minimized. So if this is performed in the real world where there are roofs and walls 2028.07s - 2032.75s | You have much more reflections. And so the success ratio is only going up 2033.23s - 2043.15s | We have also written a paper about this where we go a bit more into the details also about these conditions 2043.75s - 2046.47s | If you're interested in that, please check it out 2046.47s - 2051.23s | it's available online or we're also next week at USENIX in Philly and 2053.72s - 2055.72s | Then then there's one last thing 2056.08s - 2060.04s | So far we have talked about targeting one specific modem 2060.40s - 2067.04s | but during our research we found out that the modem also supports broadcast transmissions and 2067.84s - 2075.64s | this allows us


chunk_id: 182_chunk_36
chunk_text:
| And we found that there is a range of angles from where such an attack can be 2008.99s - 2014.15s | Successfully mounted not only from directly in front of it here shown in green 2015.27s - 2020.43s | also, keep in mind that this data has been gathered in an anechoic chamber where 2021.27s - 2027.95s | Reflections are minimized. So if this is performed in the real world where there are roofs and walls 2028.07s - 2032.75s | You have much more reflections. And so the success ratio is only going up 2033.23s - 2043.15s | We have also written a paper about this where we go a bit more into the details also about these conditions 2043.75s - 2046.47s | If you're interested in that, please check it out 2046.47s - 2051.23s | it's available online or we're also next week at USENIX in Philly and 2053.72s - 2055.72s | Then then there's one last thing 2056.08s - 2060.04s | So far we have talked about targeting one specific modem 2060.40s - 2067.04s | but during our research we found out that the modem also supports broadcast transmissions and 2067.84s - 2075.64s | this allows us to target any modem of this type without any prior information about its MAC address or 2075.64s - 2077.64s | any other identifier and 2078.28s - 2082.88s | This as a result allows us to target any modem that is in reach 2083.36s - 2084.84s | and if you 2084.84s - 2090.76s | Imagine an attacker that is not only capable of injecting signals directly by transmitting it to the modem 2090.76s - 2093.92s | But also in the uplink by first transmitting to the satellite 2094.60s - 2100.92s | It would be capable of not targeting only one modem, but all modems within an entire 2101.56s - 2103.76s | Satellite beam which is an entire region 2104.48s - 2113.17s | All right. So so what is the real-world impact of all of this? 2113.81s - 2115.65s | Basically the setup that we bought 2115.65s - 2122.49s | Is around $2,000 of where the up converter to converting from whatever 6 gigahertz SDR can do to KU band 2123.13s - 2124.81s | Is the biggest part? 2124.81s - 2128.45s | So if you have if you happen to have one of those around that's probably a lot cheaper for you


chunk_id: 182_chunk_37
chunk_text:
to target any modem of this type without any prior information about its MAC address or 2075.64s - 2077.64s | any other identifier and 2078.28s - 2082.88s | This as a result allows us to target any modem that is in reach 2083.36s - 2084.84s | and if you 2084.84s - 2090.76s | Imagine an attacker that is not only capable of injecting signals directly by transmitting it to the modem 2090.76s - 2093.92s | But also in the uplink by first transmitting to the satellite 2094.60s - 2100.92s | It would be capable of not targeting only one modem, but all modems within an entire 2101.56s - 2103.76s | Satellite beam which is an entire region 2104.48s - 2113.17s | All right. So so what is the real-world impact of all of this? 2113.81s - 2115.65s | Basically the setup that we bought 2115.65s - 2122.49s | Is around $2,000 of where the up converter to converting from whatever 6 gigahertz SDR can do to KU band 2123.13s - 2124.81s | Is the biggest part? 2124.81s - 2128.45s | So if you have if you happen to have one of those around that's probably a lot cheaper for you 2128.45s - 2133.53s | And usually you would also have an SDR. So then it's probably pretty easy to pull off 2134.33s - 2139.65s | So these attacks should generally work on all the modems that use SAT 3 play not just MDM 2200 2139.69s - 2144.45s | But they also plenty long list of other of these protocols not just SAT 3 play 2147.29s - 2152.33s | Ultimately we assume that the market share of these modems is 10 to 20 percent out of a few million deployed 2152.33s - 2156.33s | I know this is not a precise number, but it's pretty hard finding these kinds of numbers here 2157.77s - 2162.01s | One important part that we skipped so far is the responsible disclosure process 2162.41s - 2167.09s | So obviously new tech doesn't exist anymore and I direct took over their product 2167.09s - 2173.13s | So we messaged I direct and we first sent the first emails to kind of all public email addresses two years ago 2173.13s - 2177.13s | And then a few weeks afterwards again in November 2023 2177.13s - 2183.45s | We send out another wave of emails including to high-ranking


chunk_id: 182_chunk_38
chunk_text:
2128.45s - 2133.53s | And usually you would also have an SDR. So then it's probably pretty easy to pull off 2134.33s - 2139.65s | So these attacks should generally work on all the modems that use SAT 3 play not just MDM 2200 2139.69s - 2144.45s | But they also plenty long list of other of these protocols not just SAT 3 play 2147.29s - 2152.33s | Ultimately we assume that the market share of these modems is 10 to 20 percent out of a few million deployed 2152.33s - 2156.33s | I know this is not a precise number, but it's pretty hard finding these kinds of numbers here 2157.77s - 2162.01s | One important part that we skipped so far is the responsible disclosure process 2162.41s - 2167.09s | So obviously new tech doesn't exist anymore and I direct took over their product 2167.09s - 2173.13s | So we messaged I direct and we first sent the first emails to kind of all public email addresses two years ago 2173.13s - 2177.13s | And then a few weeks afterwards again in November 2023 2177.13s - 2183.45s | We send out another wave of emails including to high-ranking officials at the company that we found for example through LinkedIn, etc 2183.93s - 2190.53s | And ultimately we disclosed and escalated vulnerabilities to the special Swiss National Cyber Security Center and CSC 2191.21s - 2195.21s | After that and I direct asked for a reproducer script for these vulnerabilities 2195.73s - 2199.85s | And we are now in a process of allocating CVS for these vulnerabilities 2200.61s - 2203.89s | So what a kind of some kind of mitigations, obviously 2203.89s - 2209.25s | that's a pretty broad question here since the the main problem is that we are lacking security from the 2209.57s - 2214.71s | Foundation and a lot of parts and so obviously something like physical layer or data link layer security 2214.93s - 2219.33s | For example for Mac layer encryption as we have seen on other modems would be an option 2219.61s - 2224.97s | Source authentication through for example, the protocols actually validating that not some random network 2224.97s - 2232.29s | Defcon guy is actually just sending the software update or on the network layer maybe IPSec or some other VPN solutions also 2232.77s - 2240.41s | Maybe not using Linux kernel


chunk_id: 182_chunk_39
chunk_text:
officials at the company that we found for example through LinkedIn, etc 2183.93s - 2190.53s | And ultimately we disclosed and escalated vulnerabilities to the special Swiss National Cyber Security Center and CSC 2191.21s - 2195.21s | After that and I direct asked for a reproducer script for these vulnerabilities 2195.73s - 2199.85s | And we are now in a process of allocating CVS for these vulnerabilities 2200.61s - 2203.89s | So what a kind of some kind of mitigations, obviously 2203.89s - 2209.25s | that's a pretty broad question here since the the main problem is that we are lacking security from the 2209.57s - 2214.71s | Foundation and a lot of parts and so obviously something like physical layer or data link layer security 2214.93s - 2219.33s | For example for Mac layer encryption as we have seen on other modems would be an option 2219.61s - 2224.97s | Source authentication through for example, the protocols actually validating that not some random network 2224.97s - 2232.29s | Defcon guy is actually just sending the software update or on the network layer maybe IPSec or some other VPN solutions also 2232.77s - 2240.41s | Maybe not using Linux kernel version 2.6 point 35 on something that has shipped these days is maybe also an option 2241.01s - 2241.65s | But yeah 2241.65s - 2247.85s | It's it's a pretty big pretty broad topic and obviously did it warrant the solution to the specific for example remote code execution should also be 2247.85s - 2249.73s | pretty clear and 2249.73s - 2256.17s | With that essentially we showed the reverse engineering of one of of one probably broadly used visa system 2256.17s - 2258.81s | We identified numerous attack vectors and vulnerabilities 2258.81s - 2265.21s | We also built a full end-to-end wireless attack where we really can just take an SDR and pawn a working modem 2265.73s - 2272.41s | We successfully performed signal injection attack that way and we have a certain as we can be without actually testing it 2272.41s - 2277.65s | Which is obviously not quite feasible and that is would work on a satellite ultimately breaking the beam 2278.25s - 2289.04s | And we do have some time left 2289.04s - 2293.52s | So if you have any questions, feel free to come to one of the microphones in the front 2294.04s - 2295.44s


chunk_id: 182_chunk_40
chunk_text:
version 2.6 point 35 on something that has shipped these days is maybe also an option 2241.01s - 2241.65s | But yeah 2241.65s - 2247.85s | It's it's a pretty big pretty broad topic and obviously did it warrant the solution to the specific for example remote code execution should also be 2247.85s - 2249.73s | pretty clear and 2249.73s - 2256.17s | With that essentially we showed the reverse engineering of one of of one probably broadly used visa system 2256.17s - 2258.81s | We identified numerous attack vectors and vulnerabilities 2258.81s - 2265.21s | We also built a full end-to-end wireless attack where we really can just take an SDR and pawn a working modem 2265.73s - 2272.41s | We successfully performed signal injection attack that way and we have a certain as we can be without actually testing it 2272.41s - 2277.65s | Which is obviously not quite feasible and that is would work on a satellite ultimately breaking the beam 2278.25s - 2289.04s | And we do have some time left 2289.04s - 2293.52s | So if you have any questions, feel free to come to one of the microphones in the front 2294.04s - 2295.44s | otherwise 2295.44s - 2309.68s | Talk to us in a few minutes or so in the back. So I actually do have several questions 2310.36s - 2313.72s | one of the big things with satellite modems is that they have 2314.68s - 2321.32s | Legendary latency. I think that would be the kindest way to put it a lot of the problems with security 2322.04s - 2328.60s | Applications in satellite environments is because you have very specific timeouts, right? 2328.64s - 2330.64s | but a lot of these things are going like to 2331.28s - 2334.76s | 20,000 miles round trip in order to even finish a TCP connection 2334.76s - 2341.04s | And so why IPSec which is pretty vulnerable to those latencies would that be a suggested in your opinion? 2341.56s - 2343.56s | That's an excellent question 2345.28s - 2346.88s | Maybe just don't use IPSec 2346.88s - 2353.60s | I don't think that that is maybe the quite best option and other vendors use VPN solutions quite honestly 2353.60s - 2356.40s | I don't know if they're based on IPSec. So maybe IPSec is not the best option 2356.40s - 2361.88s | It's some


chunk_id: 182_chunk_41
chunk_text:
| otherwise 2295.44s - 2309.68s | Talk to us in a few minutes or so in the back. So I actually do have several questions 2310.36s - 2313.72s | one of the big things with satellite modems is that they have 2314.68s - 2321.32s | Legendary latency. I think that would be the kindest way to put it a lot of the problems with security 2322.04s - 2328.60s | Applications in satellite environments is because you have very specific timeouts, right? 2328.64s - 2330.64s | but a lot of these things are going like to 2331.28s - 2334.76s | 20,000 miles round trip in order to even finish a TCP connection 2334.76s - 2341.04s | And so why IPSec which is pretty vulnerable to those latencies would that be a suggested in your opinion? 2341.56s - 2343.56s | That's an excellent question 2345.28s - 2346.88s | Maybe just don't use IPSec 2346.88s - 2353.60s | I don't think that that is maybe the quite best option and other vendors use VPN solutions quite honestly 2353.60s - 2356.40s | I don't know if they're based on IPSec. So maybe IPSec is not the best option 2356.40s - 2361.88s | It's some some protocol like IPSec that implements ultimately some VPN is some some solution generally 2361.88s - 2365.12s | I think it might be TLS that they might use. That's fair 2366.04s - 2372.47s | All right. Thank you. And if you have any more questions, let us know 2373.63s - 2375.63s | offstage


chunk_id: 182_chunk_42
chunk_text:
some protocol like IPSec that implements ultimately some VPN is some some solution generally 2361.88s - 2365.12s | I think it might be TLS that they might use. That's fair 2366.04s - 2372.47s | All right. Thank you. And if you have any more questions, let us know 2373.63s - 2375.63s | offstage


chunk_id: 183_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=FDVcF28PPnI", "title": "DEF CON 32 - AIxCC Closing Ceremonies", "description": "Closing ceremonies for this round of the AIxCC!", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2271, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.02s - 11.04s | This text was transcribed using whisper model: large-v2 Hello. Tess, Tess, Tess, you can all hear me? Wonderful, I see some thumbs up. I'm Perry 11.04s - 21.15s | Adams. I'm Special Assistant to the Director at DARPA and the creator of the AI Cyber Challenge. 21.15s - 33.71s | I'm Andrew Carney. I'm Program Manager at DARPA and ARPA-H for the AI Cyber Challenge. 33.71s - 39.03s | So I see many, many competitors in the audience today. So I think that many people here are 39.03s - 47.03s | very familiar with the AI Cyber Challenge. We announced at Black Hat and DEF CON last 47.03s - 51.75s | year and I think we upended some of your years. We were very excited for all the hard work 51.75s - 57.43s | that went into the challenge and we were very excited to bring it to DEF CON. So I want 57.43s - 63.63s | to first start by thanking DEF CON for having us, thanking all of you for being such wonderful 63.63s - 71.57s | participants in the AI Cyber Challenge either as competitors or as folks visiting the village 71.57s - 79.55s | walking through it. We had I think over 12,000 folks walk through the AI Cyber Challenge 79.55s - 86.67s | space and we are so thrilled, so thrilled for that. So when we announced it last year 86.67s - 91.91s | I think many people were asking what is this? What would it become? I hope that we answered 91.91s - 96.95s | many of those questions in the village space if you weren't participating. I think many 96.95s - 104.67s | of you have spent the last year working very hard on developing systems that can find and 104.67s - 111.43s | fix vulnerabilities in software and that really goes to the why of the challenge. Why did 111.43s - 117.35s | we do this? Why did DARPA think it was important not just to put on a challenge but to come 117.35s - 122.31s | to DEF CON and to put on a show? Why did ARPA-H think it was important to partner with 122.31s


chunk_id: 183_chunk_1
chunk_text:
having us, thanking all of you for being such wonderful 63.63s - 71.57s | participants in the AI Cyber Challenge either as competitors or as folks visiting the village 71.57s - 79.55s | walking through it. We had I think over 12,000 folks walk through the AI Cyber Challenge 79.55s - 86.67s | space and we are so thrilled, so thrilled for that. So when we announced it last year 86.67s - 91.91s | I think many people were asking what is this? What would it become? I hope that we answered 91.91s - 96.95s | many of those questions in the village space if you weren't participating. I think many 96.95s - 104.67s | of you have spent the last year working very hard on developing systems that can find and 104.67s - 111.43s | fix vulnerabilities in software and that really goes to the why of the challenge. Why did 111.43s - 117.35s | we do this? Why did DARPA think it was important not just to put on a challenge but to come 117.35s - 122.31s | to DEF CON and to put on a show? Why did ARPA-H think it was important to partner with 122.31s - 129.23s | DARPA for this effort? And that goes, it comes down to the fact that our critical infrastructure 129.23s - 135.51s | is very insecure. Software is what undergirds our world and software has vulnerabilities. 135.51s - 140.23s | If you visited the village, if you've been to half of the talks at DEF CON you're already 140.23s - 145.35s | sick of hearing about this, about this problem. I know Andrew and I talk about it all the 145.35s - 150.87s | time. Software is everywhere and there's vulnerabilities in it and especially our 150.87s - 156.35s | healthcare infrastructure, our medical infrastructure, which is why it's so important that this is 156.35s - 162.43s | not just a DARPA effort but an ARPA-H effort and we're incredibly excited to have them 162.43s - 171.75s | come on as partners. I've had many people ask me why, why X? Why AI X CC? And this idea 171.83s - 178.11s | actually was suggested not by me but by another program manager at DARPA who used to go by 178.11s - 185.11s | the handle SIGTRAP and it's because X, hex CC, is SIGTRAP. It's a debug instruction


chunk_id: 183_chunk_2
chunk_text:
- 129.23s | DARPA for this effort? And that goes, it comes down to the fact that our critical infrastructure 129.23s - 135.51s | is very insecure. Software is what undergirds our world and software has vulnerabilities. 135.51s - 140.23s | If you visited the village, if you've been to half of the talks at DEF CON you're already 140.23s - 145.35s | sick of hearing about this, about this problem. I know Andrew and I talk about it all the 145.35s - 150.87s | time. Software is everywhere and there's vulnerabilities in it and especially our 150.87s - 156.35s | healthcare infrastructure, our medical infrastructure, which is why it's so important that this is 156.35s - 162.43s | not just a DARPA effort but an ARPA-H effort and we're incredibly excited to have them 162.43s - 171.75s | come on as partners. I've had many people ask me why, why X? Why AI X CC? And this idea 171.83s - 178.11s | actually was suggested not by me but by another program manager at DARPA who used to go by 178.11s - 185.11s | the handle SIGTRAP and it's because X, hex CC, is SIGTRAP. It's a debug instruction in X86 187.11s - 191.55s | and it's essentially an instruction that will stop program execution and say, hey, we're 191.55s - 194.79s | going to debug this. We're going to see what's wrong. And that's essentially what the 194.79s - 199.99s | challenge is about. It's about finding these vulnerabilities in software. Finding these 200.03s - 205.39s | issues and not just doing it at scale, not just doing it automatically, but then fixing 205.39s - 211.51s | those vulnerabilities automatically and developing systems that can be given to communities, 211.51s - 216.51s | that can be given to industry so that they can secure their own code. So AI CC consists of 219.35s - 225.19s | two competitions. We announced last year and we just wrapped up our semi-final competition. 225.19s - 230.87s | I know many of you are here, very excited to hear the results. And then next year we'll be 230.87s - 236.47s | running our final competition. Seven of the teams that competed this year will be advancing 236.47s - 243.47s | to our final competition and we will be back in August of 2025 to run that. We're very 243.47s - 248.09s |


chunk_id: 183_chunk_3
chunk_text:
in X86 187.11s - 191.55s | and it's essentially an instruction that will stop program execution and say, hey, we're 191.55s - 194.79s | going to debug this. We're going to see what's wrong. And that's essentially what the 194.79s - 199.99s | challenge is about. It's about finding these vulnerabilities in software. Finding these 200.03s - 205.39s | issues and not just doing it at scale, not just doing it automatically, but then fixing 205.39s - 211.51s | those vulnerabilities automatically and developing systems that can be given to communities, 211.51s - 216.51s | that can be given to industry so that they can secure their own code. So AI CC consists of 219.35s - 225.19s | two competitions. We announced last year and we just wrapped up our semi-final competition. 225.19s - 230.87s | I know many of you are here, very excited to hear the results. And then next year we'll be 230.87s - 236.47s | running our final competition. Seven of the teams that competed this year will be advancing 236.47s - 243.47s | to our final competition and we will be back in August of 2025 to run that. We're very 243.47s - 248.09s | excited about that. Andrew, do you want to talk a little bit about ARPA-H and that 248.09s - 254.63s | collaboration? Absolutely. So when Perry, when AI CC began at DARPA, Perry and I were 254.63s - 259.83s | already talking about the potential collaboration and transition opportunities into healthcare. I 259.83s - 265.31s | actually had been at DARPA for many years and had gone to ARPA-H, a new federal agency focused 265.31s - 270.23s | on improving the healthcare of all Americans. It's an incredible place to work. I was very 270.23s - 276.79s | excited to be there and sort of the magnitude of the problems, the complexity of the environment 277.43s - 285.11s | was pretty unreal. And so when AI CC sort of came into being, the idea of very early on that we 285.11s - 290.23s | would have some kind of collaboration or transition kind of working together was like always in the 290.23s - 295.27s | cards. And then, you know, the stars aligning so that we could work together in a very real way 295.27s - 300.23s | and sort of make the challenge real together has been an incredible experience.


chunk_id: 183_chunk_4
chunk_text:
excited about that. Andrew, do you want to talk a little bit about ARPA-H and that 248.09s - 254.63s | collaboration? Absolutely. So when Perry, when AI CC began at DARPA, Perry and I were 254.63s - 259.83s | already talking about the potential collaboration and transition opportunities into healthcare. I 259.83s - 265.31s | actually had been at DARPA for many years and had gone to ARPA-H, a new federal agency focused 265.31s - 270.23s | on improving the healthcare of all Americans. It's an incredible place to work. I was very 270.23s - 276.79s | excited to be there and sort of the magnitude of the problems, the complexity of the environment 277.43s - 285.11s | was pretty unreal. And so when AI CC sort of came into being, the idea of very early on that we 285.11s - 290.23s | would have some kind of collaboration or transition kind of working together was like always in the 290.23s - 295.27s | cards. And then, you know, the stars aligning so that we could work together in a very real way 295.27s - 300.23s | and sort of make the challenge real together has been an incredible experience. And I'm very 300.23s - 309.67s | excited for next year as well. And we've had fantastic partnership on the AI Cyber Challenge. 309.67s - 315.19s | So I started talking about, I started with thanking DEF CON for having us. And that has been a truly 315.19s - 321.03s | fundamental part of this challenge. Last summer, I called up Jeff and I said, listen, I want to do 321.03s - 326.31s | this thing. And he said, okay, let's do it. And that was pretty much the conversation. And he was 326.31s - 331.59s | an enthusiastic participant from the start. And that's pretty much been the case with all of our 331.59s - 337.43s | collaborators. When I approached them and said, here's what I'd like to do, all of them were on 337.43s - 343.91s | board. Because they understood the importance of securing the software. Many of these are technology 343.91s - 347.99s | companies. Actually, all of these are technology companies. So they themselves are software. So 347.99s - 353.35s | they understood the need to secure their own software. They understood the value that their 353.43s - 363.03s | tools, their AI could


chunk_id: 183_chunk_5
chunk_text:
And I'm very 300.23s - 309.67s | excited for next year as well. And we've had fantastic partnership on the AI Cyber Challenge. 309.67s - 315.19s | So I started talking about, I started with thanking DEF CON for having us. And that has been a truly 315.19s - 321.03s | fundamental part of this challenge. Last summer, I called up Jeff and I said, listen, I want to do 321.03s - 326.31s | this thing. And he said, okay, let's do it. And that was pretty much the conversation. And he was 326.31s - 331.59s | an enthusiastic participant from the start. And that's pretty much been the case with all of our 331.59s - 337.43s | collaborators. When I approached them and said, here's what I'd like to do, all of them were on 337.43s - 343.91s | board. Because they understood the importance of securing the software. Many of these are technology 343.91s - 347.99s | companies. Actually, all of these are technology companies. So they themselves are software. So 347.99s - 353.35s | they understood the need to secure their own software. They understood the value that their 353.43s - 363.03s | tools, their AI could bring to software security. And so we had Anthropic, Google, OpenAI, and 363.03s - 369.75s | Microsoft as our corporate partners, corporate collaborators on this effort. And they have been 369.75s - 378.15s | fantastic bringing not just their models and making them available to the competitors, but also 378.15s - 385.51s | bringing their expertise, both about AI and about software security. And then finally, we have the 385.51s - 391.19s | Linux Foundation, the open source security foundation. And these, exactly, I see Omkar in the 391.19s - 396.71s | crowd right there. Similarly, when I called up Omkar and I said, listen, I want to do this, he said, 396.71s - 401.51s | how soon can I get there? And they have been fantastic partners in this effort. 402.31s - 407.03s | Because the goal of the challenge is to focus on finding and fixing vulnerabilities 407.03s - 412.79s | in software. We needed software to focus on. And that's open source software. Open source 412.79s - 419.59s | software is the majority of software. It's what undergirds everything. The Linux kernel is 419.59s - 425.03s | everywhere. Nginx is everywhere. Open source software makes up a


chunk_id: 183_chunk_6
chunk_text:
bring to software security. And so we had Anthropic, Google, OpenAI, and 363.03s - 369.75s | Microsoft as our corporate partners, corporate collaborators on this effort. And they have been 369.75s - 378.15s | fantastic bringing not just their models and making them available to the competitors, but also 378.15s - 385.51s | bringing their expertise, both about AI and about software security. And then finally, we have the 385.51s - 391.19s | Linux Foundation, the open source security foundation. And these, exactly, I see Omkar in the 391.19s - 396.71s | crowd right there. Similarly, when I called up Omkar and I said, listen, I want to do this, he said, 396.71s - 401.51s | how soon can I get there? And they have been fantastic partners in this effort. 402.31s - 407.03s | Because the goal of the challenge is to focus on finding and fixing vulnerabilities 407.03s - 412.79s | in software. We needed software to focus on. And that's open source software. Open source 412.79s - 419.59s | software is the majority of software. It's what undergirds everything. The Linux kernel is 419.59s - 425.03s | everywhere. Nginx is everywhere. Open source software makes up a majority of our software. 425.67s - 429.75s | And so the challenges that we have, which Andrew is going to talk about in a little bit, 430.39s - 436.79s | are based on open source software. And that's in part because of all of the examples I just gave, 436.79s - 442.31s | but also because we wanted to make sure our challenges were modeled on real world examples. 443.43s - 450.47s | We wanted the tools that teams developed on this challenge to be able to apply to real world 450.47s - 457.03s | problems. And that brings me to the other open source aspect of the challenge, which is that 457.03s - 463.03s | all of the tools from prize winning teams will be open sourced. So the research that's been done on 463.03s - 470.33s | this challenge will be brought back to the community by open sourcing it. So yeah, that's 470.33s - 479.22s | amazing, right? I'd like to take a moment before we get into the technical details of the challenge 479.22s - 486.10s | to just a huge shout out to the massive dedicated team spanning technical disciplines, production, 486.10s - 494.10s |


chunk_id: 183_chunk_7
chunk_text:
majority of our software. 425.67s - 429.75s | And so the challenges that we have, which Andrew is going to talk about in a little bit, 430.39s - 436.79s | are based on open source software. And that's in part because of all of the examples I just gave, 436.79s - 442.31s | but also because we wanted to make sure our challenges were modeled on real world examples. 443.43s - 450.47s | We wanted the tools that teams developed on this challenge to be able to apply to real world 450.47s - 457.03s | problems. And that brings me to the other open source aspect of the challenge, which is that 457.03s - 463.03s | all of the tools from prize winning teams will be open sourced. So the research that's been done on 463.03s - 470.33s | this challenge will be brought back to the community by open sourcing it. So yeah, that's 470.33s - 479.22s | amazing, right? I'd like to take a moment before we get into the technical details of the challenge 479.22s - 486.10s | to just a huge shout out to the massive dedicated team spanning technical disciplines, production, 486.10s - 494.10s | logistics, every flavor of support, and every role just filled across industry, academia, 494.74s - 501.22s | our collaborators. It has been a tremendous... Making this happen in the time frame that we 501.22s - 506.18s | were shooting for is immense. The challenges do not come together quickly, and this one did, 506.90s - 510.98s | and it came together successfully. And so that's something to be extremely proud of. And just, 510.98s - 516.26s | I mean, a round of applause for all of the folks that made all of this happen, the experience, 516.26s - 523.30s | the challenges, everything. Thank you. The joke I've been making all week is that it took a 523.30s - 528.90s | village to put on the AICC village. I don't know how funny that is, but I thought it was very funny. 531.14s - 532.58s | Oh. This is you, baby. 532.58s - 533.30s | I have the clicker now. 535.30s - 540.98s | Or this is actually me, I think. So I talked a little bit about the kinds of challenges that we 541.62s - 548.42s | focused on, and these were real open source projects that we chose.


chunk_id: 183_chunk_8
chunk_text:
logistics, every flavor of support, and every role just filled across industry, academia, 494.74s - 501.22s | our collaborators. It has been a tremendous... Making this happen in the time frame that we 501.22s - 506.18s | were shooting for is immense. The challenges do not come together quickly, and this one did, 506.90s - 510.98s | and it came together successfully. And so that's something to be extremely proud of. And just, 510.98s - 516.26s | I mean, a round of applause for all of the folks that made all of this happen, the experience, 516.26s - 523.30s | the challenges, everything. Thank you. The joke I've been making all week is that it took a 523.30s - 528.90s | village to put on the AICC village. I don't know how funny that is, but I thought it was very funny. 531.14s - 532.58s | Oh. This is you, baby. 532.58s - 533.30s | I have the clicker now. 535.30s - 540.98s | Or this is actually me, I think. So I talked a little bit about the kinds of challenges that we 541.62s - 548.42s | focused on, and these were real open source projects that we chose. We were very lucky, 548.42s - 552.90s | again, to have folks like the Open Source Security Foundation come on board to make 552.90s - 558.74s | sure that we were doing this in a way that fit with open source community guidelines, 558.74s - 563.62s | that gave back to the open source community, and we found their support to be incredibly 563.62s - 569.14s | impactful for this. We also needed to focus on real world vulnerabilities. We wanted to 569.14s - 574.26s | focus on vulnerabilities that are actually causing problems today. I don't know if any 574.26s - 579.62s | of you all have been tracking, but there was a recent rather large cybersecurity incident that 579.62s - 586.82s | took out a few systems across the world. And that was memory corruption vulnerabilities. It 586.82s - 591.78s | was memory corruption vulnerabilities at a high privilege level. And so we have the Linux kernel 591.78s - 600.42s | here. We have things running in ring zero for our challenge. We have real world CVEs, CWEs, 600.42s - 605.78s | classes of vulnerabilities that we are using to model our vulnerabilities on top of. 606.10s -


chunk_id: 183_chunk_9
chunk_text:
We were very lucky, 548.42s - 552.90s | again, to have folks like the Open Source Security Foundation come on board to make 552.90s - 558.74s | sure that we were doing this in a way that fit with open source community guidelines, 558.74s - 563.62s | that gave back to the open source community, and we found their support to be incredibly 563.62s - 569.14s | impactful for this. We also needed to focus on real world vulnerabilities. We wanted to 569.14s - 574.26s | focus on vulnerabilities that are actually causing problems today. I don't know if any 574.26s - 579.62s | of you all have been tracking, but there was a recent rather large cybersecurity incident that 579.62s - 586.82s | took out a few systems across the world. And that was memory corruption vulnerabilities. It 586.82s - 591.78s | was memory corruption vulnerabilities at a high privilege level. And so we have the Linux kernel 591.78s - 600.42s | here. We have things running in ring zero for our challenge. We have real world CVEs, CWEs, 600.42s - 605.78s | classes of vulnerabilities that we are using to model our vulnerabilities on top of. 606.10s - 612.02s | And finally, we have our sanitizers. So I talked about how we have these classes of 612.02s - 616.42s | vulnerabilities. The way that these challenges work is we take this open source software, 616.42s - 622.34s | we put our vulnerabilities in it for our competitors to find. But the question maybe you're 622.34s - 626.66s | asking is, well, this is open source software. It might have vulnerabilities. This is real 626.66s - 630.98s | world software, and as we just talked about, there's vulnerabilities everywhere. And so we 630.98s - 636.82s | couldn't just have this nice little answer key for us to find and fix vulnerabilities on. We 636.82s - 641.78s | couldn't just judge teams based on that. So we had to find a way to check if a vulnerability 641.78s - 645.94s | was actually a vulnerability that a team found, and if they fixed those correctly. And what we 645.94s - 652.98s | did was we used sanitizers for this. These are sanitizers like Address Sanitizer, KSAN, JASR, 652.98s - 658.50s | et cetera, that are themselves open source projects that are maintained by some of our 658.50s - 663.70s |


chunk_id: 183_chunk_10
chunk_text:
612.02s | And finally, we have our sanitizers. So I talked about how we have these classes of 612.02s - 616.42s | vulnerabilities. The way that these challenges work is we take this open source software, 616.42s - 622.34s | we put our vulnerabilities in it for our competitors to find. But the question maybe you're 622.34s - 626.66s | asking is, well, this is open source software. It might have vulnerabilities. This is real 626.66s - 630.98s | world software, and as we just talked about, there's vulnerabilities everywhere. And so we 630.98s - 636.82s | couldn't just have this nice little answer key for us to find and fix vulnerabilities on. We 636.82s - 641.78s | couldn't just judge teams based on that. So we had to find a way to check if a vulnerability 641.78s - 645.94s | was actually a vulnerability that a team found, and if they fixed those correctly. And what we 645.94s - 652.98s | did was we used sanitizers for this. These are sanitizers like Address Sanitizer, KSAN, JASR, 652.98s - 658.50s | et cetera, that are themselves open source projects that are maintained by some of our 658.50s - 663.70s | collaborators, by some other folks that are used in program analysis tools today. And one of the 663.70s - 669.14s | reasons for this is to design a competition, which does have to be gamified in some ways, 669.14s - 674.18s | but to design it using tools that are already present in software development life cycles. 674.18s - 678.02s | Again, to make sure the things that came out of this challenge can be given back to the community. 680.02s - 684.42s | So the first challenge project that was announced was the Linux kernel. Not a single kernel module, 684.42s - 689.54s | not a driver, the Linux kernel. Both the scale, the complexity, the size, 689.54s - 694.10s | and also the ubiquity of it in real life. This was an incredible challenge project to start with. 695.54s - 699.14s | And the amount of the Linux kernel that was harnessed in this case was pretty significant. 700.10s - 708.34s | We saw approaching 20% of the code in scope was available for potential CPVs. 709.22s - 714.26s | And also the way the code, the CPVs or the challenge projects and challenge project 714.26s - 718.18s


chunk_id: 183_chunk_11
chunk_text:
collaborators, by some other folks that are used in program analysis tools today. And one of the 663.70s - 669.14s | reasons for this is to design a competition, which does have to be gamified in some ways, 669.14s - 674.18s | but to design it using tools that are already present in software development life cycles. 674.18s - 678.02s | Again, to make sure the things that came out of this challenge can be given back to the community. 680.02s - 684.42s | So the first challenge project that was announced was the Linux kernel. Not a single kernel module, 684.42s - 689.54s | not a driver, the Linux kernel. Both the scale, the complexity, the size, 689.54s - 694.10s | and also the ubiquity of it in real life. This was an incredible challenge project to start with. 695.54s - 699.14s | And the amount of the Linux kernel that was harnessed in this case was pretty significant. 700.10s - 708.34s | We saw approaching 20% of the code in scope was available for potential CPVs. 709.22s - 714.26s | And also the way the code, the CPVs or the challenge projects and challenge project 714.26s - 718.18s | vulnerabilities, forgive my lack of acronym kind of clarification up here. 722.98s - 727.22s | If anyone's ever, raise your hand if you've ever written a fuzzer or a harness. 728.90s - 733.38s | Right. It's super easy, right? It doesn't take any time at all. It's not a huge time 733.38s - 736.18s | sink for you actually finding vaults. No, it's incredibly challenging. 736.18s - 737.46s | You're just being sarcastic there. 737.46s - 743.78s | Slash S, right? It's very, very challenging. And I just like to say just generally to a huge 743.78s - 749.22s | shout out to Jonathan Metzman, the Google Project Zero team for working directly with us on 749.22s - 755.30s | infrastructure and sort of tackling some of the fully automated evaluation and the infrastructure 755.30s - 761.38s | challenges with running this competition at this scale in this way. So yeah, thank you to OSS Fuzz, 761.38s - 762.26s | Google for that. 762.26s - 767.06s | We're very lucky that OSS Fuzz has already gone through some of the pain and suffering 767.06s - 771.14s | of doing vulnerability discovery on open source software at scale. 771.14s -


chunk_id: 183_chunk_12
chunk_text:
| vulnerabilities, forgive my lack of acronym kind of clarification up here. 722.98s - 727.22s | If anyone's ever, raise your hand if you've ever written a fuzzer or a harness. 728.90s - 733.38s | Right. It's super easy, right? It doesn't take any time at all. It's not a huge time 733.38s - 736.18s | sink for you actually finding vaults. No, it's incredibly challenging. 736.18s - 737.46s | You're just being sarcastic there. 737.46s - 743.78s | Slash S, right? It's very, very challenging. And I just like to say just generally to a huge 743.78s - 749.22s | shout out to Jonathan Metzman, the Google Project Zero team for working directly with us on 749.22s - 755.30s | infrastructure and sort of tackling some of the fully automated evaluation and the infrastructure 755.30s - 761.38s | challenges with running this competition at this scale in this way. So yeah, thank you to OSS Fuzz, 761.38s - 762.26s | Google for that. 762.26s - 767.06s | We're very lucky that OSS Fuzz has already gone through some of the pain and suffering 767.06s - 771.14s | of doing vulnerability discovery on open source software at scale. 771.14s - 773.94s | And they brought a lot of those lessons learned and they were very helpful. 773.94s - 781.38s | Absolutely. So the second challenge project that we'll talk about is Engine X. This is 782.26s - 786.26s | one of the most popular web servers running 20% of the world's busiest websites. 787.22s - 793.94s | A good chunk of its code base is open source. The statefulness of this code is significant. 793.94s - 800.66s | It's a lot of S's. But this was another of our challenge projects. And once again, 800.66s - 804.74s | harnessing a significant portion of the code base, but not the entirety. 807.85s - 813.37s | SQLite was the third of the five. SQLite has an extraordinary 814.33s - 821.21s | a community-producing unit tests and tests for it. This makes patching it challenging 821.21s - 825.85s | because you have to pass a lot of those tests. And it's also been looked at a lot. 827.21s - 831.77s | It's an OSS Fuzz project. And so we took that into the competition knowing that if we could 831.77s - 835.61s | find things that were different than what was being found


chunk_id: 183_chunk_13
chunk_text:
773.94s | And they brought a lot of those lessons learned and they were very helpful. 773.94s - 781.38s | Absolutely. So the second challenge project that we'll talk about is Engine X. This is 782.26s - 786.26s | one of the most popular web servers running 20% of the world's busiest websites. 787.22s - 793.94s | A good chunk of its code base is open source. The statefulness of this code is significant. 793.94s - 800.66s | It's a lot of S's. But this was another of our challenge projects. And once again, 800.66s - 804.74s | harnessing a significant portion of the code base, but not the entirety. 807.85s - 813.37s | SQLite was the third of the five. SQLite has an extraordinary 814.33s - 821.21s | a community-producing unit tests and tests for it. This makes patching it challenging 821.21s - 825.85s | because you have to pass a lot of those tests. And it's also been looked at a lot. 827.21s - 831.77s | It's an OSS Fuzz project. And so we took that into the competition knowing that if we could 831.77s - 835.61s | find things that were different than what was being found within the community at large, 835.61s - 842.70s | that would be extra exciting. Jenkins. So something that we haven't maybe touched on. 842.86s - 849.58s | Or the fact that Java was in scope was a big deal here. Java is everywhere. One of the major 849.58s - 854.86s | projects that we've been talking about is actually the payment system that's used for Medicare. 854.86s - 860.86s | So in health and human services, about 5% of our GDP and the healthcare of 50 to 70 million 860.86s - 867.66s | Americans, depending on how you slice it, goes through a code base that is COBOL and Java. 867.66s - 872.30s | Ancient COBOL and new Java. Surely nothing will go wrong. 874.06s - 878.62s | But reasoning over this code base, especially while it's transitioning, this is a huge 878.62s - 882.46s | undertaking. And so it's one of the many challenges that when we're talking about 882.46s - 888.30s | critical infrastructure across sectors and places where the DEF CON community can potentially help, 888.30s - 895.42s | can plug in, can really make a big difference both personally and just for society at large. 895.42s


chunk_id: 183_chunk_14
chunk_text:
within the community at large, 835.61s - 842.70s | that would be extra exciting. Jenkins. So something that we haven't maybe touched on. 842.86s - 849.58s | Or the fact that Java was in scope was a big deal here. Java is everywhere. One of the major 849.58s - 854.86s | projects that we've been talking about is actually the payment system that's used for Medicare. 854.86s - 860.86s | So in health and human services, about 5% of our GDP and the healthcare of 50 to 70 million 860.86s - 867.66s | Americans, depending on how you slice it, goes through a code base that is COBOL and Java. 867.66s - 872.30s | Ancient COBOL and new Java. Surely nothing will go wrong. 874.06s - 878.62s | But reasoning over this code base, especially while it's transitioning, this is a huge 878.62s - 882.46s | undertaking. And so it's one of the many challenges that when we're talking about 882.46s - 888.30s | critical infrastructure across sectors and places where the DEF CON community can potentially help, 888.30s - 895.42s | can plug in, can really make a big difference both personally and just for society at large. 895.42s - 898.78s | That's one of them. And so we're hoping to point out more of those. 899.82s - 901.82s | Very little of that has to do with Jenkins. That's all Java. 902.78s - 907.42s | But Java is incredibly important because the first two challenges we talked about are 908.22s - 915.82s | compiled languages C and C++. They focus on memory corruption vulnerabilities. Largely, 915.82s - 920.46s | they see challenges. And then Java focuses on a different class of vulnerability. 920.46s - 925.02s | I know that lately, especially over the last couple of years, memory corruption, memory safety 925.02s - 930.38s | has been a major topic of conversation. And we wanted to make sure that was front and center 930.38s - 935.02s | of this challenge. But of course, it's not the only class of vulnerabilities that we need to 935.02s - 939.42s | worry about. As Andrew says, these kinds of vulnerabilities, these kinds of software 939.42s - 943.82s | languages are present in our healthcare industry. They're present across the board. 943.82s - 949.26s | And so Java and the kinds of vulnerabilities that aren't necessarily memory corruption that 949.26s - 955.50s


chunk_id: 183_chunk_15
chunk_text:
- 898.78s | That's one of them. And so we're hoping to point out more of those. 899.82s - 901.82s | Very little of that has to do with Jenkins. That's all Java. 902.78s - 907.42s | But Java is incredibly important because the first two challenges we talked about are 908.22s - 915.82s | compiled languages C and C++. They focus on memory corruption vulnerabilities. Largely, 915.82s - 920.46s | they see challenges. And then Java focuses on a different class of vulnerability. 920.46s - 925.02s | I know that lately, especially over the last couple of years, memory corruption, memory safety 925.02s - 930.38s | has been a major topic of conversation. And we wanted to make sure that was front and center 930.38s - 935.02s | of this challenge. But of course, it's not the only class of vulnerabilities that we need to 935.02s - 939.42s | worry about. As Andrew says, these kinds of vulnerabilities, these kinds of software 939.42s - 943.82s | languages are present in our healthcare industry. They're present across the board. 943.82s - 949.26s | And so Java and the kinds of vulnerabilities that aren't necessarily memory corruption that 949.26s - 955.50s | you find in there, we also had in scope, which is very difficult to develop sanitizers that can 955.50s - 959.98s | find and identify whether or not teams have accurately identified a vulnerability. 961.18s - 965.90s | And just to even hit that a little more, sanitizers, the ability to automatically 966.70s - 971.74s | have a high confidence indicator or Oracle that you found something worth addressing, 971.74s - 975.18s | that's huge. Knowing that there's something there that you should investigate further or 975.18s - 980.94s | allocate resources towards is tremendous. But that instrumentation on its own needs TLC. 980.94s - 986.94s | It needs support. It's hard to do. So once again, if you're looking for an additional hobby, 986.94s - 993.74s | maybe working on Jazzer or sanitizers for Java generally is something to consider. 994.86s - 998.94s | I'll also say that for Jenkins, it was especially interesting. You'll see that the CPV entry points, 998.94s - 1003.42s | kind of the reachable functions and nodes, feels relatively low. It has to do with the 1003.42s - 1009.18s | plugin architecture of Jenkins. And so the fact that the base reachability seems


chunk_id: 183_chunk_16
chunk_text:
| you find in there, we also had in scope, which is very difficult to develop sanitizers that can 955.50s - 959.98s | find and identify whether or not teams have accurately identified a vulnerability. 961.18s - 965.90s | And just to even hit that a little more, sanitizers, the ability to automatically 966.70s - 971.74s | have a high confidence indicator or Oracle that you found something worth addressing, 971.74s - 975.18s | that's huge. Knowing that there's something there that you should investigate further or 975.18s - 980.94s | allocate resources towards is tremendous. But that instrumentation on its own needs TLC. 980.94s - 986.94s | It needs support. It's hard to do. So once again, if you're looking for an additional hobby, 986.94s - 993.74s | maybe working on Jazzer or sanitizers for Java generally is something to consider. 994.86s - 998.94s | I'll also say that for Jenkins, it was especially interesting. You'll see that the CPV entry points, 998.94s - 1003.42s | kind of the reachable functions and nodes, feels relatively low. It has to do with the 1003.42s - 1009.18s | plugin architecture of Jenkins. And so the fact that the base reachability seems low, 1009.18s - 1012.78s | but as you start loading plugins and at runtime, things get far more complex very quickly. 1013.50s - 1019.58s | And when Andrew says reachability, what he's getting at is, well, maybe there might be a flaw 1019.58s - 1026.46s | in the code, but can you actually reach that flaw? Can an attacker actually start from an 1026.46s - 1033.26s | entry point into that code and get to that what we call a sink, get to that flaw? So that's one 1033.26s - 1038.22s | thing that you're checking when assessing if a team has actually found their vulnerabilities, 1038.22s - 1041.58s | reachability. And so that's some of what went into the design of these challenges. 1042.14s - 1047.74s | And then again, when Andrew talks about the sanitizers and puts out a call for help with 1047.74s - 1055.42s | Jazzer, it's because it can be very difficult to say, okay, I've injected code in a command line 1055.42s - 1059.58s | or something, something like that, but was that actually attacker controlled malicious code? 1059.58s - 1063.82s | What kind of constraints were on it? Is it actually a vulnerability?


chunk_id: 183_chunk_17
chunk_text:
low, 1009.18s - 1012.78s | but as you start loading plugins and at runtime, things get far more complex very quickly. 1013.50s - 1019.58s | And when Andrew says reachability, what he's getting at is, well, maybe there might be a flaw 1019.58s - 1026.46s | in the code, but can you actually reach that flaw? Can an attacker actually start from an 1026.46s - 1033.26s | entry point into that code and get to that what we call a sink, get to that flaw? So that's one 1033.26s - 1038.22s | thing that you're checking when assessing if a team has actually found their vulnerabilities, 1038.22s - 1041.58s | reachability. And so that's some of what went into the design of these challenges. 1042.14s - 1047.74s | And then again, when Andrew talks about the sanitizers and puts out a call for help with 1047.74s - 1055.42s | Jazzer, it's because it can be very difficult to say, okay, I've injected code in a command line 1055.42s - 1059.58s | or something, something like that, but was that actually attacker controlled malicious code? 1059.58s - 1063.82s | What kind of constraints were on it? Is it actually a vulnerability? This challenge runs 1063.82s - 1069.74s | into fundamentally hard problems in program analysis, such as vulnerability metrology. 1069.74s - 1074.38s | How do we assess if a vulnerability is real or not? And how do we assess its severity? 1074.38s - 1078.86s | And that was an interesting part about running this challenge was for the technical team putting 1078.86s - 1083.98s | together these challenges. How do you address this in a creative way in a, how do you create 1083.98s - 1089.10s | a gamified environment that's not too gamified? So these are real world tools, but also allows 1089.10s - 1093.66s | the teams to compete against each other in the timeframe. And I think if you visited the village, 1093.66s - 1098.70s | if you went through Northbridge City, you were able to talk to some of our challenge developers 1098.70s - 1105.66s | and hear about the thought and the serious effort that went into creating this competition. 1106.38s - 1112.22s | Also say that we have, we've been interviewing our challenge developers. And once, after we 1112.22s - 1117.26s | announced the results from this first year, we're hoping to put a lot


chunk_id: 183_chunk_18
chunk_text:
This challenge runs 1063.82s - 1069.74s | into fundamentally hard problems in program analysis, such as vulnerability metrology. 1069.74s - 1074.38s | How do we assess if a vulnerability is real or not? And how do we assess its severity? 1074.38s - 1078.86s | And that was an interesting part about running this challenge was for the technical team putting 1078.86s - 1083.98s | together these challenges. How do you address this in a creative way in a, how do you create 1083.98s - 1089.10s | a gamified environment that's not too gamified? So these are real world tools, but also allows 1089.10s - 1093.66s | the teams to compete against each other in the timeframe. And I think if you visited the village, 1093.66s - 1098.70s | if you went through Northbridge City, you were able to talk to some of our challenge developers 1098.70s - 1105.66s | and hear about the thought and the serious effort that went into creating this competition. 1106.38s - 1112.22s | Also say that we have, we've been interviewing our challenge developers. And once, after we 1112.22s - 1117.26s | announced the results from this first year, we're hoping to put a lot more information just to share 1117.26s - 1122.62s | because this process is fascinating. The idea of creating a gamified challenge as Perry's saying, 1122.62s - 1129.02s | but that is at the scale and scope and complexity of real software. I mean, it's very challenging. 1130.46s - 1136.94s | It's perhaps more type two fun than type one fun relative to like CTF work. So it's not fun when 1136.94s - 1146.60s | you do it, it's fun afterwards. So the last challenge project is Apache Tikka. And a huge 1146.60s - 1151.64s | thanks to Tim Allison, one of the primary maintainers and someone who has written challenges 1151.64s - 1157.48s | for this, who's shared war stories and perspective. And this is just, it's been incredible to have 1157.48s - 1163.32s | someone who's so tightly integrated into this code base working with us. Apache Tikka, actually 1164.28s - 1169.48s | it's parsers. It's thousands and thousands of parsers, which are some of the safest code on 1169.48s - 1174.44s | the planet, right? Like parsers, parsers are... Andrew's being sarcastic again. 1174.44s - 1180.28s | Once again, I should be more sarcastic and maybe careful with


chunk_id: 183_chunk_19
chunk_text:
more information just to share 1117.26s - 1122.62s | because this process is fascinating. The idea of creating a gamified challenge as Perry's saying, 1122.62s - 1129.02s | but that is at the scale and scope and complexity of real software. I mean, it's very challenging. 1130.46s - 1136.94s | It's perhaps more type two fun than type one fun relative to like CTF work. So it's not fun when 1136.94s - 1146.60s | you do it, it's fun afterwards. So the last challenge project is Apache Tikka. And a huge 1146.60s - 1151.64s | thanks to Tim Allison, one of the primary maintainers and someone who has written challenges 1151.64s - 1157.48s | for this, who's shared war stories and perspective. And this is just, it's been incredible to have 1157.48s - 1163.32s | someone who's so tightly integrated into this code base working with us. Apache Tikka, actually 1164.28s - 1169.48s | it's parsers. It's thousands and thousands of parsers, which are some of the safest code on 1169.48s - 1174.44s | the planet, right? Like parsers, parsers are... Andrew's being sarcastic again. 1174.44s - 1180.28s | Once again, I should be more sarcastic and maybe careful with that. But it's all parsers and it's 1180.28s - 1186.76s | parsers that are used all over the place, places you would not expect. So this is kind of thinking 1186.76s - 1191.56s | about that invisible software infrastructure that we rely on, that we may not know we depend on, 1192.20s - 1197.16s | the services that may be backed by Apache Tikka that you're using as an API happily, 1198.12s - 1201.72s | you may really want that Java to be more secure without realizing it. 1207.16s - 1212.36s | Another big piece of this challenge and something that affected the teams, affected the challenge 1212.36s - 1217.96s | development and organization was leveraging external resources. The collaborators provided 1217.96s - 1226.44s | us access to their LLMs, to these services that were changing. Very grateful for their 1226.44s - 1232.36s | involvement, but we never expected any of them to change their release cycles based on our needs. 1232.36s - 1235.72s | So we had to meet them kind of based on where they were and where they were going. 1236.76s - 1242.92s | These models were changing every few months, every few, well, fast, they were


chunk_id: 183_chunk_20
chunk_text:
that. But it's all parsers and it's 1180.28s - 1186.76s | parsers that are used all over the place, places you would not expect. So this is kind of thinking 1186.76s - 1191.56s | about that invisible software infrastructure that we rely on, that we may not know we depend on, 1192.20s - 1197.16s | the services that may be backed by Apache Tikka that you're using as an API happily, 1198.12s - 1201.72s | you may really want that Java to be more secure without realizing it. 1207.16s - 1212.36s | Another big piece of this challenge and something that affected the teams, affected the challenge 1212.36s - 1217.96s | development and organization was leveraging external resources. The collaborators provided 1217.96s - 1226.44s | us access to their LLMs, to these services that were changing. Very grateful for their 1226.44s - 1232.36s | involvement, but we never expected any of them to change their release cycles based on our needs. 1232.36s - 1235.72s | So we had to meet them kind of based on where they were and where they were going. 1236.76s - 1242.92s | These models were changing every few months, every few, well, fast, they were changing fast. 1242.92s - 1246.28s | And so over the year of the challenge, I mean, the models that were available when the challenge was 1246.28s - 1251.24s | announced are not currently available, or at least these are not the ones that we're focused 1251.24s - 1257.48s | on. And that's a big difference from a lot of DARPA or just ARPA-flavored challenges generally. 1257.48s - 1262.04s | When you're trying to frame the problem, when you're trying to create sort of momentum in a 1262.04s - 1267.16s | direction and bring communities together to solve something, part of the design, a big component, 1267.16s - 1272.44s | is how do I define the problem in a way that won't change while the competition is running, 1272.44s - 1278.52s | or that will change in a way that is manageable? These changes were manageable. 1279.96s - 1285.64s | They were very challenging. And so a huge just thanks once again to the organizers and the 1285.64s - 1292.44s | competitors who hit this timeline, who were able to move at the speed of industry leaders. That's 1292.44s - 1299.56s | incredible. Yeah. So we've talked a lot up until


chunk_id: 183_chunk_21
chunk_text:
changing fast. 1242.92s - 1246.28s | And so over the year of the challenge, I mean, the models that were available when the challenge was 1246.28s - 1251.24s | announced are not currently available, or at least these are not the ones that we're focused 1251.24s - 1257.48s | on. And that's a big difference from a lot of DARPA or just ARPA-flavored challenges generally. 1257.48s - 1262.04s | When you're trying to frame the problem, when you're trying to create sort of momentum in a 1262.04s - 1267.16s | direction and bring communities together to solve something, part of the design, a big component, 1267.16s - 1272.44s | is how do I define the problem in a way that won't change while the competition is running, 1272.44s - 1278.52s | or that will change in a way that is manageable? These changes were manageable. 1279.96s - 1285.64s | They were very challenging. And so a huge just thanks once again to the organizers and the 1285.64s - 1292.44s | competitors who hit this timeline, who were able to move at the speed of industry leaders. That's 1292.44s - 1299.56s | incredible. Yeah. So we've talked a lot up until this point about the cyber part of the AI Cyber 1299.56s - 1306.52s | Challenge, and this is really one of the AI parts of the AI Cyber Challenge. One thing that I was 1306.52s - 1312.76s | asked a number of times is, do I have to use AI? Can I just create a system? Is there a requirement? 1312.76s - 1318.52s | And no, we don't believe in mandating approaches. The thesis, though, of the challenge is that AI 1318.52s - 1325.96s | could make a fundamental difference. It could be a revolutionary add-on to existing program 1325.96s - 1331.72s | analysis methods for finding and fixing vulnerabilities. And so one way in which 1331.72s - 1339.40s | our collaborators participated was to provide access to their cutting-edge large language models 1339.40s - 1345.32s | and other large models for this challenge. And part of the reason why Andrew and I are getting 1345.32s - 1350.92s | into the weeds a little bit is because running a challenge like this is hard and required quite a 1350.92s - 1356.04s | lot of coordination with the partners, and we're just incredibly happy that we had that. 1356.68s - 1364.84s


chunk_id: 183_chunk_22
chunk_text:
this point about the cyber part of the AI Cyber 1299.56s - 1306.52s | Challenge, and this is really one of the AI parts of the AI Cyber Challenge. One thing that I was 1306.52s - 1312.76s | asked a number of times is, do I have to use AI? Can I just create a system? Is there a requirement? 1312.76s - 1318.52s | And no, we don't believe in mandating approaches. The thesis, though, of the challenge is that AI 1318.52s - 1325.96s | could make a fundamental difference. It could be a revolutionary add-on to existing program 1325.96s - 1331.72s | analysis methods for finding and fixing vulnerabilities. And so one way in which 1331.72s - 1339.40s | our collaborators participated was to provide access to their cutting-edge large language models 1339.40s - 1345.32s | and other large models for this challenge. And part of the reason why Andrew and I are getting 1345.32s - 1350.92s | into the weeds a little bit is because running a challenge like this is hard and required quite a 1350.92s - 1356.04s | lot of coordination with the partners, and we're just incredibly happy that we had that. 1356.68s - 1364.84s | Absolutely. Also, we were not prescriptive within this list. The competitors could use whichever 1364.84s - 1370.44s | models they chose with constraints that we'll discuss a little bit later, but it was their 1370.44s - 1376.20s | choice. We were not forcing them to use a specific model within this set. And we had a shout out to 1376.20s - 1381.64s | LightLLM, which is the proxy that we used as a means of providing them access in a way that we 1381.64s - 1390.44s | could regulate, speaking of resources. So in addition to the LLM access, these fully autonomous 1390.44s - 1395.32s | systems that were not touched by the competitor teams while they were running, this was the amount 1395.32s - 1401.48s | of compute that they were given. It's significant. It's not insignificant. But it's still, when we're 1401.48s - 1405.56s | talking about relative cost, we're talking about tens to hundreds of thousands of dollars per 1406.12s - 1412.28s | week, or tens to hundreds of dollars per week or month, depending on your usage. 1414.84s - 1419.56s | And the other big constraint was how do we limit the use of the


chunk_id: 183_chunk_23
chunk_text:
| Absolutely. Also, we were not prescriptive within this list. The competitors could use whichever 1364.84s - 1370.44s | models they chose with constraints that we'll discuss a little bit later, but it was their 1370.44s - 1376.20s | choice. We were not forcing them to use a specific model within this set. And we had a shout out to 1376.20s - 1381.64s | LightLLM, which is the proxy that we used as a means of providing them access in a way that we 1381.64s - 1390.44s | could regulate, speaking of resources. So in addition to the LLM access, these fully autonomous 1390.44s - 1395.32s | systems that were not touched by the competitor teams while they were running, this was the amount 1395.32s - 1401.48s | of compute that they were given. It's significant. It's not insignificant. But it's still, when we're 1401.48s - 1405.56s | talking about relative cost, we're talking about tens to hundreds of thousands of dollars per 1406.12s - 1412.28s | week, or tens to hundreds of dollars per week or month, depending on your usage. 1414.84s - 1419.56s | And the other big constraint was how do we limit the use of the LLMs? So we actually used their 1419.56s - 1424.20s | pricing. We pinned their pricing. And each challenge project, each team was given a budget 1424.20s - 1431.56s | of $100 across those models to allocate as they saw fit, and then four hours of wall clock time 1432.36s - 1438.36s | with this compute and access to those LLM APIs. And that's sort of what they were working with. 1439.48s - 1444.04s | Those were their tools or the resources they had in addition for their CRSs to leverage. 1445.00s - 1450.12s | And this goes back to the fundamental idea of the challenge. We want to create 1451.08s - 1456.28s | software security systems that are usable by the community. So not only open sourcing them, 1456.28s - 1461.80s | but making sure that the resources needed to run them are reasonable. 1461.80s - 1473.03s | Absolutely. The competitors. So we had an incredible response to the competition call to 1473.03s - 1479.51s | action. And we ended up getting 91 teams sign up, verified, go through all of the initial registration 1479.51s - 1485.59s | and validate that they're interested in competing. As we released the challenge


chunk_id: 183_chunk_24
chunk_text:
LLMs? So we actually used their 1419.56s - 1424.20s | pricing. We pinned their pricing. And each challenge project, each team was given a budget 1424.20s - 1431.56s | of $100 across those models to allocate as they saw fit, and then four hours of wall clock time 1432.36s - 1438.36s | with this compute and access to those LLM APIs. And that's sort of what they were working with. 1439.48s - 1444.04s | Those were their tools or the resources they had in addition for their CRSs to leverage. 1445.00s - 1450.12s | And this goes back to the fundamental idea of the challenge. We want to create 1451.08s - 1456.28s | software security systems that are usable by the community. So not only open sourcing them, 1456.28s - 1461.80s | but making sure that the resources needed to run them are reasonable. 1461.80s - 1473.03s | Absolutely. The competitors. So we had an incredible response to the competition call to 1473.03s - 1479.51s | action. And we ended up getting 91 teams sign up, verified, go through all of the initial registration 1479.51s - 1485.59s | and validate that they're interested in competing. As we released the challenge exemplars, things for 1485.59s - 1490.31s | them to practice on is what will the competition look like? How do I know what scoring? How do I 1490.31s - 1497.19s | know if I'm winning? How do I know what will win? As they got more and more details on that between 1497.19s - 1502.23s | April of this year and July of this year, which once again, that is a very, very tight timeline 1502.23s - 1509.03s | to operate on. Very tight window. We narrowed the field to 39 teams that kind of made it to 1509.03s - 1514.55s | the starting line. Those teams had something that could be proficient, could be performant 1514.55s - 1519.83s | in this competition. And that was very exciting. And just once again, I have immense respect for 1519.83s - 1525.11s | all the teams, whether or not they made it to that starting line, just this was an extremely 1525.11s - 1529.83s | challenging challenge. The software development challenge, I'm saying challenge a lot, 1531.11s - 1537.59s | the difficulties of creating fully autonomous closed loop systems that you expect to run with 1537.59s - 1546.23s | a lot of


chunk_id: 183_chunk_25
chunk_text:
exemplars, things for 1485.59s - 1490.31s | them to practice on is what will the competition look like? How do I know what scoring? How do I 1490.31s - 1497.19s | know if I'm winning? How do I know what will win? As they got more and more details on that between 1497.19s - 1502.23s | April of this year and July of this year, which once again, that is a very, very tight timeline 1502.23s - 1509.03s | to operate on. Very tight window. We narrowed the field to 39 teams that kind of made it to 1509.03s - 1514.55s | the starting line. Those teams had something that could be proficient, could be performant 1514.55s - 1519.83s | in this competition. And that was very exciting. And just once again, I have immense respect for 1519.83s - 1525.11s | all the teams, whether or not they made it to that starting line, just this was an extremely 1525.11s - 1529.83s | challenging challenge. The software development challenge, I'm saying challenge a lot, 1531.11s - 1537.59s | the difficulties of creating fully autonomous closed loop systems that you expect to run with 1537.59s - 1546.23s | a lot of resources. It's not easy. And so being good at VR, being good at vulnerability 1546.23s - 1550.63s | research, being excellent in other kind of programming disciplines does not necessarily 1550.63s - 1557.91s | equip you to produce software that can survive in this challenge environment. And so we worked 1557.91s - 1562.71s | with the teams, but we really just saw it was exciting to see the growth. Folks really mature 1562.95s - 1569.11s | their capabilities from a development and stability and performance side on top of the 1569.11s - 1576.62s | amazing program analysis and AI-based tools that they were developing. I guess I could 1576.62s - 1581.82s | have teed that up a bit more. Yeah. So just to be clear, Andrew and I are doing this to torture you 1581.82s - 1586.14s | if you are a team in the audience. I think it's been about 20- We're watching that timer real 1586.14s - 1591.18s | close. Since we started. I'm not going to say whether we're close or not. You'll just have to 1591.18s - 1597.58s | sit there. But our overall results, Andrew, do you want to talk about the slide? Absolutely. So


chunk_id: 183_chunk_26
chunk_text:
resources. It's not easy. And so being good at VR, being good at vulnerability 1546.23s - 1550.63s | research, being excellent in other kind of programming disciplines does not necessarily 1550.63s - 1557.91s | equip you to produce software that can survive in this challenge environment. And so we worked 1557.91s - 1562.71s | with the teams, but we really just saw it was exciting to see the growth. Folks really mature 1562.95s - 1569.11s | their capabilities from a development and stability and performance side on top of the 1569.11s - 1576.62s | amazing program analysis and AI-based tools that they were developing. I guess I could 1576.62s - 1581.82s | have teed that up a bit more. Yeah. So just to be clear, Andrew and I are doing this to torture you 1581.82s - 1586.14s | if you are a team in the audience. I think it's been about 20- We're watching that timer real 1586.14s - 1591.18s | close. Since we started. I'm not going to say whether we're close or not. You'll just have to 1591.18s - 1597.58s | sit there. But our overall results, Andrew, do you want to talk about the slide? Absolutely. So 1597.58s - 1602.14s | this is the scoreboard that you saw in the city. Each of those hexes actually represents one of 1602.14s - 1608.06s | the CPVs that we inserted into the challenge projects. And this was sort of the performance 1608.06s - 1614.06s | across all of the competitors over the course of the competition. We saw a really strong performance 1614.06s - 1621.82s | in Nginx. We saw that lone discovery in the Linux kernel, but that is a discovery. That is an 1621.82s - 1626.46s | achievement. And then we saw kind of performance across that range with the other challenge 1626.46s - 1632.62s | projects. It was really interesting to see the fact that the patching was successful, that we 1632.62s - 1636.78s | saw successful patches across a range of CWEs, a range of challenge projects, and a range of 1636.78s - 1646.31s | languages. Getting in a little bit to more detail. So this is probably one of those slides that's way 1646.31s - 1652.23s | better to either screenshot or like watch the video later and read about. Are you saying there's 1652.23s - 1657.99s | going to be additional material later


chunk_id: 183_chunk_27
chunk_text:
1597.58s - 1602.14s | this is the scoreboard that you saw in the city. Each of those hexes actually represents one of 1602.14s - 1608.06s | the CPVs that we inserted into the challenge projects. And this was sort of the performance 1608.06s - 1614.06s | across all of the competitors over the course of the competition. We saw a really strong performance 1614.06s - 1621.82s | in Nginx. We saw that lone discovery in the Linux kernel, but that is a discovery. That is an 1621.82s - 1626.46s | achievement. And then we saw kind of performance across that range with the other challenge 1626.46s - 1632.62s | projects. It was really interesting to see the fact that the patching was successful, that we 1632.62s - 1636.78s | saw successful patches across a range of CWEs, a range of challenge projects, and a range of 1636.78s - 1646.31s | languages. Getting in a little bit to more detail. So this is probably one of those slides that's way 1646.31s - 1652.23s | better to either screenshot or like watch the video later and read about. Are you saying there's 1652.23s - 1657.99s | going to be additional material later that talks about this? I mean, details. We love details, right? 1657.99s - 1663.35s | We're looking forward to releasing more competition kind of details to the community 1663.51s - 1671.75s | at large soon. But this is the high level cut here. And the takeaways are some of what we 1671.75s - 1676.95s | expected, right? We expected people to do well with whether it was a write or a read, but some flavor 1676.95s - 1682.47s | of heap or buffer overflow, or stack-based buffer overflow. We saw strong patching, strong discovery 1682.47s - 1693.99s | there. We saw, you know, the Java results. I think perhaps the Java software security ecosystem 1693.99s - 1699.91s | could use a bit more love. Like we would love to see that space get more love. But we saw a 1699.91s - 1704.39s | promise there too. So the fact that we did see successful discoveries and finds across 1705.03s - 1713.43s | command injection and SSRF, it's very exciting. Yeah, that's important. We're finding both memory 1713.43s - 1717.11s | corruption vulnerabilities and non-memory corruption vulnerabilities like command 1717.11s - 1726.06s | injection. So we have some fantastic coverage there.


chunk_id: 183_chunk_28
chunk_text:
that talks about this? I mean, details. We love details, right? 1657.99s - 1663.35s | We're looking forward to releasing more competition kind of details to the community 1663.51s - 1671.75s | at large soon. But this is the high level cut here. And the takeaways are some of what we 1671.75s - 1676.95s | expected, right? We expected people to do well with whether it was a write or a read, but some flavor 1676.95s - 1682.47s | of heap or buffer overflow, or stack-based buffer overflow. We saw strong patching, strong discovery 1682.47s - 1693.99s | there. We saw, you know, the Java results. I think perhaps the Java software security ecosystem 1693.99s - 1699.91s | could use a bit more love. Like we would love to see that space get more love. But we saw a 1699.91s - 1704.39s | promise there too. So the fact that we did see successful discoveries and finds across 1705.03s - 1713.43s | command injection and SSRF, it's very exciting. Yeah, that's important. We're finding both memory 1713.43s - 1717.11s | corruption vulnerabilities and non-memory corruption vulnerabilities like command 1717.11s - 1726.06s | injection. So we have some fantastic coverage there. If you were paying very close attention 1726.06s - 1731.82s | to the numbers there, they did not necessarily match the scoreboard because we actually had a 1731.82s - 1738.62s | team find something that we did not insert. We found, or one of the teams found something, 1738.62s - 1745.26s | found a bug in SQLite. If you recall from earlier, SQLite has an extremely active user base. It's an 1745.26s - 1753.90s | OSS fuzz project. It has an extremely comprehensive corpus of unit tests. And we found, or one of the 1753.90s - 1762.22s | teams found an all deref in SQLite and it has been patched. So that, I mean, that is very exciting. 1762.22s - 1770.22s | Like real code was both analyzed, a defect was discovered, and a patch, or a defect was 1770.22s - 1775.66s | discovered. We can't take for the patch, credit for the patch in this case, but like year two, 1775.74s - 1778.54s | hashtag year two. But that was very exciting. 1787.02s - 1791.66s | Also, credit where credit is due, that was team Atlanta. So give it up for team Atlanta. 1794.46s - 1795.02s | Good job,


chunk_id: 183_chunk_29
chunk_text:
If you were paying very close attention 1726.06s - 1731.82s | to the numbers there, they did not necessarily match the scoreboard because we actually had a 1731.82s - 1738.62s | team find something that we did not insert. We found, or one of the teams found something, 1738.62s - 1745.26s | found a bug in SQLite. If you recall from earlier, SQLite has an extremely active user base. It's an 1745.26s - 1753.90s | OSS fuzz project. It has an extremely comprehensive corpus of unit tests. And we found, or one of the 1753.90s - 1762.22s | teams found an all deref in SQLite and it has been patched. So that, I mean, that is very exciting. 1762.22s - 1770.22s | Like real code was both analyzed, a defect was discovered, and a patch, or a defect was 1770.22s - 1775.66s | discovered. We can't take for the patch, credit for the patch in this case, but like year two, 1775.74s - 1778.54s | hashtag year two. But that was very exciting. 1787.02s - 1791.66s | Also, credit where credit is due, that was team Atlanta. So give it up for team Atlanta. 1794.46s - 1795.02s | Good job, guys. 1800.65s - 1809.29s | Okay. I think we're getting a little closer. So these were all of the semi-final competitors. 1809.29s - 1810.01s | Do you want to say anything? 1810.89s - 1811.69s | Good job. 1811.69s - 1818.41s | Yeah. Thank you all so much for participating. Thank you all so much for your hard work, 1818.41s - 1822.33s | for developing these systems, for working with us as you submitted it. 1825.00s - 1830.92s | I'll say also, you know, there is so much opportunity for this type of work. I mean, 1831.88s - 1838.20s | no one here lacks for opportunities for work, but if you've done this, regardless of where you land, 1838.20s - 1843.16s | regardless of if you move on to finals or not, like what you developed, what you produced 1843.16s - 1848.28s | has value. And I strongly encourage you to think about ways of keeping that momentum going, 1848.92s - 1851.96s | perhaps not at the breakneck pace of the challenge, you know, live your lives. 1853.00s - 1856.92s | But there are lots of places that could benefit from this work and lots of ways for you to turn


chunk_id: 183_chunk_30
chunk_text:
guys. 1800.65s - 1809.29s | Okay. I think we're getting a little closer. So these were all of the semi-final competitors. 1809.29s - 1810.01s | Do you want to say anything? 1810.89s - 1811.69s | Good job. 1811.69s - 1818.41s | Yeah. Thank you all so much for participating. Thank you all so much for your hard work, 1818.41s - 1822.33s | for developing these systems, for working with us as you submitted it. 1825.00s - 1830.92s | I'll say also, you know, there is so much opportunity for this type of work. I mean, 1831.88s - 1838.20s | no one here lacks for opportunities for work, but if you've done this, regardless of where you land, 1838.20s - 1843.16s | regardless of if you move on to finals or not, like what you developed, what you produced 1843.16s - 1848.28s | has value. And I strongly encourage you to think about ways of keeping that momentum going, 1848.92s - 1851.96s | perhaps not at the breakneck pace of the challenge, you know, live your lives. 1853.00s - 1856.92s | But there are lots of places that could benefit from this work and lots of ways for you to turn 1856.92s - 1861.72s | this into something very real. If you're not going to use it any further, if you're like, nope, 1861.72s - 1870.44s | I'm out, open source your CRS, please. Like give that back to like, please. I will bake you cookies. 1870.92s - 1879.80s | Andrew's cookies are very good. I can attest. And just to echo Andrew, thank you so much for 1879.80s - 1887.24s | all of the work that you did. Every single team that participated provided value. You gave back 1887.24s - 1894.92s | to your community. You invested in the software security of our nation, of our world. And that 1895.88s - 1901.16s | has been really impactful. We are so grateful to have so many fantastic competitors. 1901.72s - 1909.56s | And we are so grateful for you working with us over the last year, for your understanding that 1909.56s - 1918.20s | a challenge like this is a hard thing to do. It's hard to drive innovation in software security. And 1919.16s - 1926.28s | we were thrilled to have such fantastic, intelligent competitors who, to Andrew's point, 1927.32s - 1931.72s | do not lack for job opportunities. One


chunk_id: 183_chunk_31
chunk_text:
1856.92s - 1861.72s | this into something very real. If you're not going to use it any further, if you're like, nope, 1861.72s - 1870.44s | I'm out, open source your CRS, please. Like give that back to like, please. I will bake you cookies. 1870.92s - 1879.80s | Andrew's cookies are very good. I can attest. And just to echo Andrew, thank you so much for 1879.80s - 1887.24s | all of the work that you did. Every single team that participated provided value. You gave back 1887.24s - 1894.92s | to your community. You invested in the software security of our nation, of our world. And that 1895.88s - 1901.16s | has been really impactful. We are so grateful to have so many fantastic competitors. 1901.72s - 1909.56s | And we are so grateful for you working with us over the last year, for your understanding that 1909.56s - 1918.20s | a challenge like this is a hard thing to do. It's hard to drive innovation in software security. And 1919.16s - 1926.28s | we were thrilled to have such fantastic, intelligent competitors who, to Andrew's point, 1927.32s - 1931.72s | do not lack for job opportunities. One more time, guys, the competitors. 1940.41s - 1947.37s | You ready? Okay. So there is actually a point 1948.73s - 1954.49s | that we are building towards, and that is to announce the results of the challenge. 1955.37s - 1962.22s | Are you all ready? I don't know. It didn't sound like you all were ready. Can we do that again? 1966.98s - 1972.82s | Okay. What you just did, I'm going to need you to do that after every competitor that we announced. 1972.82s - 1981.78s | And we are about to go into the seven finalists of AICC. Each team will win $2 million. 1983.38s - 1990.14s | And so here we go. These are in alphabetical order. Okay. It's the next. 1990.30s - 2003.11s | The safety slide, the safety slide, right? 42 Beyond Bug. One of them tweeted, 2003.11s - 2008.79s | I think yesterday, that just seeing the first bloods they were getting on the scoreboard 2008.79s - 2012.47s | made all the sleepless nights worth it. And so I hope this does as well. 2012.47s - 2019.51s | Yeah. Really appreciate their balanced approach, both over C and the Java challenges. Great job. 2019.51s


chunk_id: 183_chunk_32
chunk_text:
more time, guys, the competitors. 1940.41s - 1947.37s | You ready? Okay. So there is actually a point 1948.73s - 1954.49s | that we are building towards, and that is to announce the results of the challenge. 1955.37s - 1962.22s | Are you all ready? I don't know. It didn't sound like you all were ready. Can we do that again? 1966.98s - 1972.82s | Okay. What you just did, I'm going to need you to do that after every competitor that we announced. 1972.82s - 1981.78s | And we are about to go into the seven finalists of AICC. Each team will win $2 million. 1983.38s - 1990.14s | And so here we go. These are in alphabetical order. Okay. It's the next. 1990.30s - 2003.11s | The safety slide, the safety slide, right? 42 Beyond Bug. One of them tweeted, 2003.11s - 2008.79s | I think yesterday, that just seeing the first bloods they were getting on the scoreboard 2008.79s - 2012.47s | made all the sleepless nights worth it. And so I hope this does as well. 2012.47s - 2019.51s | Yeah. Really appreciate their balanced approach, both over C and the Java challenges. Great job. 2019.51s - 2040.78s | All you need is fuzzing brain. So this is my favorite kind of, like, 2040.78s - 2046.70s | characterization. All you need is fuzzing brain had the most aggressive use of the LLMs. 2049.50s - 2054.38s | Apparently, you need more. What Andrew means is for a challenge 2054.38s - 2057.98s | where many competitors used a lot of fuzzing, they used a lot of LLM. 2068.78s - 2077.22s | Very nice. Team Lacrosse, you had the most memorable patch when we were doing validation. 2077.22s - 2099.86s | So thank you for that. Shellfish. I take it there are some 2099.86s - 2102.10s | shellfish folks in the crowd. Just a few. 2104.34s - 2109.94s | Yeah. Your software engineering approach was 2111.14s - 2121.16s | ambitious, I'll say. Team Atlanta. 2127.56s - 2131.40s | Yeah. Fabulous job with the SQLite find. Very cool. Awesome work. 2143.38s - 2147.38s | At some point, I'd like it confirmed to me if Theory is actually two guys, 2149.46s - 2152.66s | because that's the rumor. But congratulations, Theory. 2152.66s - 2156.82s | Do you have a theory about that? I think I may have just shared it with


chunk_id: 183_chunk_33
chunk_text:
- 2040.78s | All you need is fuzzing brain. So this is my favorite kind of, like, 2040.78s - 2046.70s | characterization. All you need is fuzzing brain had the most aggressive use of the LLMs. 2049.50s - 2054.38s | Apparently, you need more. What Andrew means is for a challenge 2054.38s - 2057.98s | where many competitors used a lot of fuzzing, they used a lot of LLM. 2068.78s - 2077.22s | Very nice. Team Lacrosse, you had the most memorable patch when we were doing validation. 2077.22s - 2099.86s | So thank you for that. Shellfish. I take it there are some 2099.86s - 2102.10s | shellfish folks in the crowd. Just a few. 2104.34s - 2109.94s | Yeah. Your software engineering approach was 2111.14s - 2121.16s | ambitious, I'll say. Team Atlanta. 2127.56s - 2131.40s | Yeah. Fabulous job with the SQLite find. Very cool. Awesome work. 2143.38s - 2147.38s | At some point, I'd like it confirmed to me if Theory is actually two guys, 2149.46s - 2152.66s | because that's the rumor. But congratulations, Theory. 2152.66s - 2156.82s | Do you have a theory about that? I think I may have just shared it with the crowd. 2156.82s - 2157.86s | Yeah. It's good. It's good. 2157.86s - 2159.06s | Thank you. Yeah. 2159.06s - 2164.28s | We're here all day. Trail of bits. 2173.50s - 2176.70s | Your judicious use of the LLMs was also appreciated. 2178.78s - 2186.30s | I also appreciate the information that you all have put out about your thoughts on the challenge 2186.30s - 2194.54s | as well as your thoughts behind your system for a competition where many folks, understandably, 2194.54s - 2197.58s | are keeping it a little close to the vest before finals. 2197.58s - 2200.22s | The fact that you're sharing with the community some of the lessons learned 2200.22s - 2202.94s | has really been fantastic, and I've heard that feedback. 2204.46s - 2206.62s | The backup scoreboard on Twitter wasn't bad either. 2207.82s - 2213.51s | Yes. Thank you, Dan. And ladies and gentlemen, the finalists. 2214.07s - 2233.43s | Teams is winning $2 million and a chance to come back to DEF CON in 2025 to compete in AICC finals. 2240.31s - 2245.19s | So to all the competitors, we will be reaching out shortly to provide detailed scoring information. 2245.19s -


chunk_id: 183_chunk_34
chunk_text:
the crowd. 2156.82s - 2157.86s | Yeah. It's good. It's good. 2157.86s - 2159.06s | Thank you. Yeah. 2159.06s - 2164.28s | We're here all day. Trail of bits. 2173.50s - 2176.70s | Your judicious use of the LLMs was also appreciated. 2178.78s - 2186.30s | I also appreciate the information that you all have put out about your thoughts on the challenge 2186.30s - 2194.54s | as well as your thoughts behind your system for a competition where many folks, understandably, 2194.54s - 2197.58s | are keeping it a little close to the vest before finals. 2197.58s - 2200.22s | The fact that you're sharing with the community some of the lessons learned 2200.22s - 2202.94s | has really been fantastic, and I've heard that feedback. 2204.46s - 2206.62s | The backup scoreboard on Twitter wasn't bad either. 2207.82s - 2213.51s | Yes. Thank you, Dan. And ladies and gentlemen, the finalists. 2214.07s - 2233.43s | Teams is winning $2 million and a chance to come back to DEF CON in 2025 to compete in AICC finals. 2240.31s - 2245.19s | So to all the competitors, we will be reaching out shortly to provide detailed scoring information. 2245.19s - 2248.31s | We have a lot more information to share about the competition of the results are out 2249.11s - 2251.19s | and just really looking forward to engaging more 2251.83s - 2254.95s | over the next year and seeing what we can all do working together. 2255.67s - 2266.92s | Thank you. Congratulations, everyone. 2266.92s - 2268.12s | Thank you so much.


chunk_id: 183_chunk_35
chunk_text:
2248.31s | We have a lot more information to share about the competition of the results are out 2249.11s - 2251.19s | and just really looking forward to engaging more 2251.83s - 2254.95s | over the next year and seeing what we can all do working together. 2255.67s - 2266.92s | Thank you. Congratulations, everyone. 2266.92s - 2268.12s | Thank you so much.


chunk_id: 184_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=4cx0RUV7i0s", "title": "DEF CON 32 - Unsaflok: Hacking millions of hotel locks - Lennert Wouters, Ian Carroll", "description": "Electronic hotel locks have been in use for over three decades, and have become an integral part of the hospitality sector. Las Vegas has over 150.000 hotel rooms, many of which use an RFID based electronic lock for access control. Most hotel guests rely on these locks to safeguard personal belongings and to protect their personal safety. However, some of these long-deployed locks have never been publicly scrutinized by the research community.\n\nThis presentation covers the discovery of vulnerabilities affecting three million dormakaba Saflok locks. The Saflok system relied on a proprietary key derivation function for its MIFARE Classic cards and a proprietary encryption algorithm for the card contents. Reverse engineering the Saflok system allowed us to forge valid keycards. After reading a single, low privilege, guest card we are able to create a pair of forged key cards that allow us to deactivate the deadbolt and open any room at the property.\n\nWe reported these vulnerabilities to dormakaba in September of 2022, as part of this presentation we will discuss the responsible disclosure and mitigation processes. Additionally, we will demonstrate how you can determine if your own hotel room has been patched to help ensure your personal safety.\n\nMy Arduino can beat up your hotel room lock - Onity locks - Cody Brocious - Blackhat 2012\nGhost In The Locks: Owning Electronic Locks Without Leaving A Trace - Vingcard locks - Tomi Tuominen and Timo Hirvonen - HITBGSEC 2018", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2492, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 2.35s - 7.43s | This text was transcribed using whisper model: large-v2 Thanks everyone. Welcome to our talk titled Unsaflock, Unlocking Millions of 7.43s - 12.71s | Hotel Locks. I'm Lennart, I'm a hardware security researcher at the KU Leuven 12.71s - 17.11s | University in Belgium. I typically do research related to voltage glitching 17.11s - 23.03s | and other hardware attacks. I'm Ian, I'm an application security researcher. I was 23.03s - 26.45s | formerly at the red team at Robin Hood and now I run a point search engine 26.45s - 34.09s | called C-SERA. We got sued by Air Canada. So as you can probably tell from the 34.09s - 39.25s | first slide, neither of us is really working on locks or RFID stuff all of the 39.25s


chunk_id: 184_chunk_1
chunk_text:
you can determine if your own hotel room has been patched to help ensure your personal safety.\n\nMy Arduino can beat up your hotel room lock - Onity locks - Cody Brocious - Blackhat 2012\nGhost In The Locks: Owning Electronic Locks Without Leaving A Trace - Vingcard locks - Tomi Tuominen and Timo Hirvonen - HITBGSEC 2018", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2492, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 2.35s - 7.43s | This text was transcribed using whisper model: large-v2 Thanks everyone. Welcome to our talk titled Unsaflock, Unlocking Millions of 7.43s - 12.71s | Hotel Locks. I'm Lennart, I'm a hardware security researcher at the KU Leuven 12.71s - 17.11s | University in Belgium. I typically do research related to voltage glitching 17.11s - 23.03s | and other hardware attacks. I'm Ian, I'm an application security researcher. I was 23.03s - 26.45s | formerly at the red team at Robin Hood and now I run a point search engine 26.45s - 34.09s | called C-SERA. We got sued by Air Canada. So as you can probably tell from the 34.09s - 39.25s | first slide, neither of us is really working on locks or RFID stuff all of the 39.25s - 43.81s | time. So when we started working on this it was all relatively new to us. And the 43.81s - 49.57s | reason we started looking at these locks is that a group of us got invited to 49.57s - 53.61s | hack some Las Vegas hotels back in 2022 and they were running a bug bounty 53.61s - 57.77s | program. And one of the elements of the hotel room that was in scope were the 57.77s - 62.05s | hotel locks. And that's how we got nerd sniped and started looking at these 62.05s - 66.53s | hotel locks. Now it wasn't just Ian and me, there were more people involved and 66.53s - 75.44s | some of them are sitting here on the on the first row. So thanks everyone. So 75.44s - 82.12s | here's some related research of other researchers. So back in 2012, 82.12s - 87.76s | C-SERA looked at the Onity locks and she found that there is a programming part 87.76s - 91.28s | on the outside of the door. And if you plug into this you can actually start 91.28s - 97.28s | reading memory of the lock itself.


chunk_id: 184_chunk_2
chunk_text:
- 43.81s | time. So when we started working on this it was all relatively new to us. And the 43.81s - 49.57s | reason we started looking at these locks is that a group of us got invited to 49.57s - 53.61s | hack some Las Vegas hotels back in 2022 and they were running a bug bounty 53.61s - 57.77s | program. And one of the elements of the hotel room that was in scope were the 57.77s - 62.05s | hotel locks. And that's how we got nerd sniped and started looking at these 62.05s - 66.53s | hotel locks. Now it wasn't just Ian and me, there were more people involved and 66.53s - 75.44s | some of them are sitting here on the on the first row. So thanks everyone. So 75.44s - 82.12s | here's some related research of other researchers. So back in 2012, 82.12s - 87.76s | C-SERA looked at the Onity locks and she found that there is a programming part 87.76s - 91.28s | on the outside of the door. And if you plug into this you can actually start 91.28s - 97.28s | reading memory of the lock itself. And if you analyze this memory you can extract 97.28s - 101.24s | the side code. And this side code is enough to send an unlock command to the 101.24s - 106.36s | door and then open it up. Back then C-SERA immediately published all of the 106.36s - 110.00s | details of the attack. And this resulted in some people making their own devices, 110.00s - 115.52s | going to hotels, opening all of the doors, stealing TVs and so on. There's a very 115.52s - 120.28s | nice Wired article about this sort of hacking spree that some people went on. 120.28s - 127.48s | It's well worth the read I would say. Then six years later in 2018 there was 127.48s - 131.64s | an attack on the VIN card system by Essa Abloy. This was an attack by 131.64s - 135.36s | researchers from F-Secure and they figured out that if you can read one 135.36s - 140.56s | card from the hotel that they can make a master key and then open every door in 140.56s - 145.48s | the hotel essentially. In this case F-Secure worked with Essa Abloy on a fix. 145.48s -


chunk_id: 184_chunk_3
chunk_text:
And if you analyze this memory you can extract 97.28s - 101.24s | the side code. And this side code is enough to send an unlock command to the 101.24s - 106.36s | door and then open it up. Back then C-SERA immediately published all of the 106.36s - 110.00s | details of the attack. And this resulted in some people making their own devices, 110.00s - 115.52s | going to hotels, opening all of the doors, stealing TVs and so on. There's a very 115.52s - 120.28s | nice Wired article about this sort of hacking spree that some people went on. 120.28s - 127.48s | It's well worth the read I would say. Then six years later in 2018 there was 127.48s - 131.64s | an attack on the VIN card system by Essa Abloy. This was an attack by 131.64s - 135.36s | researchers from F-Secure and they figured out that if you can read one 135.36s - 140.56s | card from the hotel that they can make a master key and then open every door in 140.56s - 145.48s | the hotel essentially. In this case F-Secure worked with Essa Abloy on a fix. 145.48s - 149.76s | And this also meant that the talk didn't include a lot of technical details. And 149.76s - 153.96s | this is something where we want to strike a balance. So instead of 153.96s - 158.00s | publishing all of the details immediately we went to a long responsible 158.00s - 162.08s | disclosure process. And now we are sharing some of the details of what we 162.08s - 169.68s | found. So this talk is about Dormakabos Saflock. It was introduced in 1988 by 169.72s - 173.52s | Computerized Security Systems. Back then it was a mag stripe lock and then they 173.52s - 178.04s | became RFID locks. It has kind of a weird corporate history. Computerized 178.04s - 182.80s | Security Systems was acquired by Kava in 2006. And then in 2015 two companies 182.80s - 189.24s | called Dorma and Kava merged and now it's called Dormakaba. Saflock is used 189.24s - 194.36s | on three million doors in 13,000 hotels in 131 countries. So this is one of the 194.36s - 198.92s | biggest brands of hotel locks. It's important to talk about the architecture 198.92s - 203.20s | before we start. So these


chunk_id: 184_chunk_4
chunk_text:
149.76s | And this also meant that the talk didn't include a lot of technical details. And 149.76s - 153.96s | this is something where we want to strike a balance. So instead of 153.96s - 158.00s | publishing all of the details immediately we went to a long responsible 158.00s - 162.08s | disclosure process. And now we are sharing some of the details of what we 162.08s - 169.68s | found. So this talk is about Dormakabos Saflock. It was introduced in 1988 by 169.72s - 173.52s | Computerized Security Systems. Back then it was a mag stripe lock and then they 173.52s - 178.04s | became RFID locks. It has kind of a weird corporate history. Computerized 178.04s - 182.80s | Security Systems was acquired by Kava in 2006. And then in 2015 two companies 182.80s - 189.24s | called Dorma and Kava merged and now it's called Dormakaba. Saflock is used 189.24s - 194.36s | on three million doors in 13,000 hotels in 131 countries. So this is one of the 194.36s - 198.92s | biggest brands of hotel locks. It's important to talk about the architecture 198.92s - 203.20s | before we start. So these locks are usually entirely offline. So there's the 203.20s - 206.88s | front desk server and the front desk computers have a connection. But they're 206.88s - 210.44s | not connected to the actual hotel locks. And so the front desk will write the key 210.44s - 214.76s | card that contains the information of what doors it should open. And then the 214.76s - 218.40s | locks make the decisions entirely themselves. They don't contact any server 218.40s - 222.68s | or anything. But in the case of when the lock needs to be upgraded or if you need 222.68s - 226.72s | to see the access history there's this unit called the HH6. And you can plug 226.72s - 230.56s | into a USB port on the bottom of the lock to use this. So generally that's the 230.56s - 236.20s | only connection these locks have. In some places especially in large Vegas hotels 236.20s - 239.98s | they use a kind of a semi-online architecture. So in this case the 239.98s - 243.20s | hallways have Zigbee coordinators in them. And this allows the front desk to 243.20s - 247.52s | kind of see the audit


chunk_id: 184_chunk_5
chunk_text:
locks are usually entirely offline. So there's the 203.20s - 206.88s | front desk server and the front desk computers have a connection. But they're 206.88s - 210.44s | not connected to the actual hotel locks. And so the front desk will write the key 210.44s - 214.76s | card that contains the information of what doors it should open. And then the 214.76s - 218.40s | locks make the decisions entirely themselves. They don't contact any server 218.40s - 222.68s | or anything. But in the case of when the lock needs to be upgraded or if you need 222.68s - 226.72s | to see the access history there's this unit called the HH6. And you can plug 226.72s - 230.56s | into a USB port on the bottom of the lock to use this. So generally that's the 230.56s - 236.20s | only connection these locks have. In some places especially in large Vegas hotels 236.20s - 239.98s | they use a kind of a semi-online architecture. So in this case the 239.98s - 243.20s | hallways have Zigbee coordinators in them. And this allows the front desk to 243.20s - 247.52s | kind of see the audit log. It still doesn't make it an online system. The key 247.52s - 251.44s | cards are still read by the lock and the lock determines if it opens or not. But 251.44s - 256.32s | afterwards it tells the front desk, hey this key opened this lock. This might be 256.32s - 259.84s | beneficial for hotels because you can kind of detect what keys are being used. 259.84s - 268.92s | So when we were starting out we needed a hotel to do our research on. We don't own 268.92s - 273.08s | a hotel so we had to build one ourselves. And that first meant acquiring the 273.08s - 277.64s | system 6000 software. As with any software this is software you can find 277.64s - 283.24s | on some places on the internet. The other thing you need is an RFID encoder. So 283.24s - 288.48s | this is the device that the front desk will use to encode a new key card. Back 288.48s - 294.64s | in 2022 these were very expensive on eBay. $600 to just get one. Now thanks to 294.64s - 298.20s | our research these have really come down in


chunk_id: 184_chunk_6
chunk_text:
log. It still doesn't make it an online system. The key 247.52s - 251.44s | cards are still read by the lock and the lock determines if it opens or not. But 251.44s - 256.32s | afterwards it tells the front desk, hey this key opened this lock. This might be 256.32s - 259.84s | beneficial for hotels because you can kind of detect what keys are being used. 259.84s - 268.92s | So when we were starting out we needed a hotel to do our research on. We don't own 268.92s - 273.08s | a hotel so we had to build one ourselves. And that first meant acquiring the 273.08s - 277.64s | system 6000 software. As with any software this is software you can find 277.64s - 283.24s | on some places on the internet. The other thing you need is an RFID encoder. So 283.24s - 288.48s | this is the device that the front desk will use to encode a new key card. Back 288.48s - 294.64s | in 2022 these were very expensive on eBay. $600 to just get one. Now thanks to 294.64s - 298.20s | our research these have really come down in price. So now you can find them for 298.20s - 308.14s | $45 online. So the reason they are much cheaper these days is they all have to 308.14s - 311.22s | be replaced. So all of the hotels are essentially selling their old encoders 311.22s - 316.30s | online. So another thing you need are my fair classic 1k cards. These are very 316.30s - 321.78s | common, very cheap. You can find them everywhere. And optionally if you want to 321.78s - 327.02s | actually open some doors you can also buy on eBay some door locks or a HH6 327.02s - 331.38s | programmer if you want to play with one of those. So now that we have all of the 331.38s - 335.22s | elements for our hotel we have to set it up. So we start by installing the 335.22s - 340.10s | software. If you open the manual, the installation manual, the first step it 340.10s - 344.06s | tells you is to disable all of the Windows security features and then you're 344.06s - 348.94s | good to start running the installer. Once you've installed the software you copy 349.06s - 352.98s |


chunk_id: 184_chunk_7
chunk_text:
price. So now you can find them for 298.20s - 308.14s | $45 online. So the reason they are much cheaper these days is they all have to 308.14s - 311.22s | be replaced. So all of the hotels are essentially selling their old encoders 311.22s - 316.30s | online. So another thing you need are my fair classic 1k cards. These are very 316.30s - 321.78s | common, very cheap. You can find them everywhere. And optionally if you want to 321.78s - 327.02s | actually open some doors you can also buy on eBay some door locks or a HH6 327.02s - 331.38s | programmer if you want to play with one of those. So now that we have all of the 331.38s - 335.22s | elements for our hotel we have to set it up. So we start by installing the 335.22s - 340.10s | software. If you open the manual, the installation manual, the first step it 340.10s - 344.06s | tells you is to disable all of the Windows security features and then you're 344.06s - 348.94s | good to start running the installer. Once you've installed the software you copy 349.06s - 352.98s | over a GDB database file to the installation directory and then you can 352.98s - 358.94s | start the software. This database file is very useful to us. It's a Firebird 358.94s - 363.58s | database file. It has a default username and password on there. And so you can 363.58s - 367.34s | start reading all of the elements in the database. So this contains 367.34s - 371.66s | configuration data for your specific hotel but also all of the cards that 371.66s - 375.94s | were created by the hotel software. So this means that if you create a card you 375.94s - 379.50s | can go look in the database and look at all the different fields that are 379.50s - 385.58s | encoded on the card. Now as I said back in 2022 real encoders were very 385.58s - 391.58s | expensive but we figured out that this system used to support just commercial 391.58s - 396.38s | RFID reader writers at some point. So that means that you can go into the 396.38s - 400.70s | Firebird database and you can set the hide legacy encoders flag to zero and 401.18s - 405.98s | now


chunk_id: 184_chunk_8
chunk_text:
over a GDB database file to the installation directory and then you can 352.98s - 358.94s | start the software. This database file is very useful to us. It's a Firebird 358.94s - 363.58s | database file. It has a default username and password on there. And so you can 363.58s - 367.34s | start reading all of the elements in the database. So this contains 367.34s - 371.66s | configuration data for your specific hotel but also all of the cards that 371.66s - 375.94s | were created by the hotel software. So this means that if you create a card you 375.94s - 379.50s | can go look in the database and look at all the different fields that are 379.50s - 385.58s | encoded on the card. Now as I said back in 2022 real encoders were very 385.58s - 391.58s | expensive but we figured out that this system used to support just commercial 391.58s - 396.38s | RFID reader writers at some point. So that means that you can go into the 396.38s - 400.70s | Firebird database and you can set the hide legacy encoders flag to zero and 401.18s - 405.98s | now you can use a cheap off-the-shelf encoder essentially. So that this is 405.98s - 414.22s | what we used back in 2012. So about the handheld programmer. So as I 414.22s - 417.98s | mentioned before all of these blocks have a mini USB port on the bottom of it 417.98s - 421.02s | and obviously that struck our interest pretty quickly because it's you know 421.02s - 428.02s | behind and it's in the hallway. So we bought the HH6 off of eBay and we tried 428.02s - 431.66s | to use it in a lock at first and we hit an issue where it detected it was being 431.66s - 434.94s | used at the wrong property. And so we were like okay there's some kind of 434.94s - 438.86s | authentication here. But then we quickly realized that if we just change the 438.86s - 441.90s | property ID in our database to the property we were staying at it would 441.90s - 446.70s | start working. And so there's a lot of interesting features in here and we 446.70s - 450.06s | didn't use it too much in our attack but the main interesting thing is


chunk_id: 184_chunk_9
chunk_text:
you can use a cheap off-the-shelf encoder essentially. So that this is 405.98s - 414.22s | what we used back in 2012. So about the handheld programmer. So as I 414.22s - 417.98s | mentioned before all of these blocks have a mini USB port on the bottom of it 417.98s - 421.02s | and obviously that struck our interest pretty quickly because it's you know 421.02s - 428.02s | behind and it's in the hallway. So we bought the HH6 off of eBay and we tried 428.02s - 431.66s | to use it in a lock at first and we hit an issue where it detected it was being 431.66s - 434.94s | used at the wrong property. And so we were like okay there's some kind of 434.94s - 438.86s | authentication here. But then we quickly realized that if we just change the 438.86s - 441.90s | property ID in our database to the property we were staying at it would 441.90s - 446.70s | start working. And so there's a lot of interesting features in here and we 446.70s - 450.06s | didn't use it too much in our attack but the main interesting thing is you can 450.06s - 454.10s | actually interrogate these locks and you can view every entry and every exit to 454.10s - 457.90s | the room. So for example you can even see you know when housekeeping entered 457.90s - 461.82s | your room. You can see when they left. You can see the previous guests. You can 461.82s - 465.14s | see when they were coming and going. And if you know the property ID you can 465.14s - 469.34s | actually do this to any door on any hotel. It was also useful for our 469.34s - 473.14s | purposes. It will tell you why I refused to open the door. So for a long time we 473.14s - 475.58s | were making fake key cards and we couldn't figure out why it wasn't 475.58s - 478.90s | opening. But the HH6 will actually tell you hey this is why your key card 478.90s - 486.08s | didn't work. So it was very useful for our purposes. So the next step was to 486.08s - 490.68s | reverse engineer the system 6000 software. The software consists out of 490.68s - 494.80s | some Delphi executables which are very


chunk_id: 184_chunk_10
chunk_text:
you can 450.06s - 454.10s | actually interrogate these locks and you can view every entry and every exit to 454.10s - 457.90s | the room. So for example you can even see you know when housekeeping entered 457.90s - 461.82s | your room. You can see when they left. You can see the previous guests. You can 461.82s - 465.14s | see when they were coming and going. And if you know the property ID you can 465.14s - 469.34s | actually do this to any door on any hotel. It was also useful for our 469.34s - 473.14s | purposes. It will tell you why I refused to open the door. So for a long time we 473.14s - 475.58s | were making fake key cards and we couldn't figure out why it wasn't 475.58s - 478.90s | opening. But the HH6 will actually tell you hey this is why your key card 478.90s - 486.08s | didn't work. So it was very useful for our purposes. So the next step was to 486.08s - 490.68s | reverse engineer the system 6000 software. The software consists out of 490.68s - 494.80s | some Delphi executables which are very annoying to reverse engineer. But 494.80s - 499.20s | luckily there are also some .NET binaries in there and those are very 499.20s - 502.76s | easy to reverse engineer. We can simply decompile them and look at the code in 502.76s - 507.32s | .wik. Now we had a few goals for reverse engineering the system. We wanted to 507.32s - 512.52s | understand how the my fair sector keys are derived. How the data stored on the 512.52s - 517.28s | card is encrypted. And then once the data is decrypted what is actually the 517.28s - 522.64s | meaning of the different fields of this data. So first a quick introduction to 522.64s - 527.00s | MyFairClassic. Most of the Cephalog deployments use MyFairClassic 1k cards. 527.00s - 532.92s | These 1k cards have 16 sectors each containing four 16 byte blocks. So they 532.92s - 538.40s | are essentially just storing data. Block 0 is special. It's the manufacturer block. 538.44s - 544.16s | It contains the UID and the manufacturer data. And then the last block of every 544.16s - 548.68s | sector contains the keys. So the keys that you need to authenticate and


chunk_id: 184_chunk_11
chunk_text:
annoying to reverse engineer. But 494.80s - 499.20s | luckily there are also some .NET binaries in there and those are very 499.20s - 502.76s | easy to reverse engineer. We can simply decompile them and look at the code in 502.76s - 507.32s | .wik. Now we had a few goals for reverse engineering the system. We wanted to 507.32s - 512.52s | understand how the my fair sector keys are derived. How the data stored on the 512.52s - 517.28s | card is encrypted. And then once the data is decrypted what is actually the 517.28s - 522.64s | meaning of the different fields of this data. So first a quick introduction to 522.64s - 527.00s | MyFairClassic. Most of the Cephalog deployments use MyFairClassic 1k cards. 527.00s - 532.92s | These 1k cards have 16 sectors each containing four 16 byte blocks. So they 532.92s - 538.40s | are essentially just storing data. Block 0 is special. It's the manufacturer block. 538.44s - 544.16s | It contains the UID and the manufacturer data. And then the last block of every 544.16s - 548.68s | sector contains the keys. So the keys that you need to authenticate and to 548.68s - 554.20s | read the data on the cards. Every sector has two keys associated to it. Key A and 554.20s - 559.96s | key B. And then essentially the access conditions indicate what actions you 559.96s - 565.08s | are allowed to perform with either of these keys. Now if you look specifically 565.48s - 570.00s | at the Cephalog cards. And in the case of the Cephalog system all of the 570.00s - 575.08s | interesting data is stored in sector 0. And the key to read that sector is 575.08s - 580.36s | derived from the UID. So all of the keys marked in orange on the slide are unique 580.36s - 584.72s | for every key card. So they always change. But they are derived from the UID. Which 584.72s - 590.08s | is not a very secure way of implementing this. The key for sector 1 is the same on 590.08s - 593.64s | every Cephalog card across all of the deployments. And that means that if you 593.72s - 597.68s | read one of these cards and you see this key. Then you immediately know it's a 597.68s - 604.56s | Cephalog


chunk_id: 184_chunk_12
chunk_text:
to 548.68s - 554.20s | read the data on the cards. Every sector has two keys associated to it. Key A and 554.20s - 559.96s | key B. And then essentially the access conditions indicate what actions you 559.96s - 565.08s | are allowed to perform with either of these keys. Now if you look specifically 565.48s - 570.00s | at the Cephalog cards. And in the case of the Cephalog system all of the 570.00s - 575.08s | interesting data is stored in sector 0. And the key to read that sector is 575.08s - 580.36s | derived from the UID. So all of the keys marked in orange on the slide are unique 580.36s - 584.72s | for every key card. So they always change. But they are derived from the UID. Which 584.72s - 590.08s | is not a very secure way of implementing this. The key for sector 1 is the same on 590.08s - 593.64s | every Cephalog card across all of the deployments. And that means that if you 593.72s - 597.68s | read one of these cards and you see this key. Then you immediately know it's a 597.68s - 604.56s | Cephalog system. So the key derivation function. To read the data from the card 604.60s - 608.84s | we need the keys to authenticate to this sector. There's a few ways you can get 608.84s - 613.68s | those keys. You can use a Poxmark tree. Run HFMF autophone. And it will 613.68s - 618.04s | immediately spit out all of the keys for you. The other way to do it is to 618.04s - 621.92s | actually reverse engineer the key derivation function. And it turns out 621.96s - 626.24s | that back in 2022 multiple people had already done this. They had 626.24s - 630.32s | reverse engineered the KDF. But they hadn't published it. So at the time we 630.32s - 634.76s | had to reverse engineer it ourselves. In the meantime someone has published the 634.76s - 639.48s | KDF. And now it's also implemented in the Poxmark tree project and in the 639.48s - 646.48s | Flipper 0. It's maybe interesting to know that knowing the KDF is not 646.48s - 650.76s | strictly necessary for our attack. And that's because there are cryptographic 650.76s - 657.10s | attacks on the MyFair Classic cards. So reverse


chunk_id: 184_chunk_13
chunk_text:
system. So the key derivation function. To read the data from the card 604.60s - 608.84s | we need the keys to authenticate to this sector. There's a few ways you can get 608.84s - 613.68s | those keys. You can use a Poxmark tree. Run HFMF autophone. And it will 613.68s - 618.04s | immediately spit out all of the keys for you. The other way to do it is to 618.04s - 621.92s | actually reverse engineer the key derivation function. And it turns out 621.96s - 626.24s | that back in 2022 multiple people had already done this. They had 626.24s - 630.32s | reverse engineered the KDF. But they hadn't published it. So at the time we 630.32s - 634.76s | had to reverse engineer it ourselves. In the meantime someone has published the 634.76s - 639.48s | KDF. And now it's also implemented in the Poxmark tree project and in the 639.48s - 646.48s | Flipper 0. It's maybe interesting to know that knowing the KDF is not 646.48s - 650.76s | strictly necessary for our attack. And that's because there are cryptographic 650.76s - 657.10s | attacks on the MyFair Classic cards. So reverse engineering the KDF. We 657.10s - 662.30s | figured out that the Cephalog card encoder DLL contains a Kaba get secured 662.30s - 667.54s | keys function which implements this KDF. Initially we weren't 100 percent sure 667.54s - 670.74s | that this is the correct function we wanted to reverse engineer. So we we 670.74s - 674.78s | made a simple Python wrapper that uses the DLL. And then we could feed in some 674.78s - 679.58s | new IDs and check if the response was the same key as what we were seeing in 679.58s - 683.30s | the Poxmark project essentially. And then later on when we were sure this was 683.30s - 687.34s | the correct function we translated it to Python so that we had our own library 687.34s - 693.33s | for it. So now we have a pretty good way of reading the data on the MyFair card. 693.33s - 696.73s | But of course our goal is not just to clone it. We want to modify what rooms 696.73s - 701.05s | the key can open. And so we learned that really the only data that matters is the 701.05s - 705.21s


chunk_id: 184_chunk_14
chunk_text:
engineering the KDF. We 657.10s - 662.30s | figured out that the Cephalog card encoder DLL contains a Kaba get secured 662.30s - 667.54s | keys function which implements this KDF. Initially we weren't 100 percent sure 667.54s - 670.74s | that this is the correct function we wanted to reverse engineer. So we we 670.74s - 674.78s | made a simple Python wrapper that uses the DLL. And then we could feed in some 674.78s - 679.58s | new IDs and check if the response was the same key as what we were seeing in 679.58s - 683.30s | the Poxmark project essentially. And then later on when we were sure this was 683.30s - 687.34s | the correct function we translated it to Python so that we had our own library 687.34s - 693.33s | for it. So now we have a pretty good way of reading the data on the MyFair card. 693.33s - 696.73s | But of course our goal is not just to clone it. We want to modify what rooms 696.73s - 701.05s | the key can open. And so we learned that really the only data that matters is the 701.05s - 705.21s | 16 bytes on block 1 which kind of tells lock which doors the lock can open. And 705.21s - 709.85s | then the first byte on block 2 is a checksum of the first block. And so we 709.85s - 713.17s | wanted to figure out it looked like the data was encrypted on the sector because 713.17s - 716.89s | we didn't really see anything meaningful in it. And we found this encrypt card and 716.89s - 721.05s | decrypt card function in the Firebird services DLL. And so using that we 721.05s - 724.65s | discovered that the data on the card was actually encrypted using just a 724.65s - 728.87s | substitution table. And we unfortunately also learned that that substitution 728.87s - 733.61s | table is the same for every Saflock hotel. So every Saflock installation has 733.61s - 739.92s | the keys to decrypt and encrypt every Saflock card. And so now we know how to 739.96s - 744.20s | decrypt it. And now we want to start changing what the fields are. But we had 744.20s - 746.72s | to decrypt the data but we still didn't really know what the 16 bytes


chunk_id: 184_chunk_15
chunk_text:
| 16 bytes on block 1 which kind of tells lock which doors the lock can open. And 705.21s - 709.85s | then the first byte on block 2 is a checksum of the first block. And so we 709.85s - 713.17s | wanted to figure out it looked like the data was encrypted on the sector because 713.17s - 716.89s | we didn't really see anything meaningful in it. And we found this encrypt card and 716.89s - 721.05s | decrypt card function in the Firebird services DLL. And so using that we 721.05s - 724.65s | discovered that the data on the card was actually encrypted using just a 724.65s - 728.87s | substitution table. And we unfortunately also learned that that substitution 728.87s - 733.61s | table is the same for every Saflock hotel. So every Saflock installation has 733.61s - 739.92s | the keys to decrypt and encrypt every Saflock card. And so now we know how to 739.96s - 744.20s | decrypt it. And now we want to start changing what the fields are. But we had 744.20s - 746.72s | to decrypt the data but we still didn't really know what the 16 bytes 746.72s - 750.60s | represented. Luckily in the same DLL we found a function that we didn't think 750.60s - 755.16s | was actually being used. But it basically assembled the 16 bytes for an emergency 755.16s - 758.56s | card. And so we kind of took a look at this function and saw you know what 758.56s - 762.96s | fields is it writing to on sector 1. And we were able to kind of work from there. 762.96s - 766.36s | Work backwards and say OK these bytes are the expiration. These bytes are the 766.36s - 770.44s | room number. Stuff like that. And being able to create cards was also very 770.44s - 773.48s | useful. We had our fake hotel so we created some cards and we were able to 773.48s - 777.12s | decrypt that data. And see you know through this field's line with what we 777.12s - 781.52s | expected. And so slowly byte by byte we figured out what the data was starting 781.52s - 789.94s | to mean. So this is the full card data format for the Saflock systems. It is in 789.94s - 793.18s | alphabetical order. So


chunk_id: 184_chunk_16
chunk_text:
746.72s - 750.60s | represented. Luckily in the same DLL we found a function that we didn't think 750.60s - 755.16s | was actually being used. But it basically assembled the 16 bytes for an emergency 755.16s - 758.56s | card. And so we kind of took a look at this function and saw you know what 758.56s - 762.96s | fields is it writing to on sector 1. And we were able to kind of work from there. 762.96s - 766.36s | Work backwards and say OK these bytes are the expiration. These bytes are the 766.36s - 770.44s | room number. Stuff like that. And being able to create cards was also very 770.44s - 773.48s | useful. We had our fake hotel so we created some cards and we were able to 773.48s - 777.12s | decrypt that data. And see you know through this field's line with what we 777.12s - 781.52s | expected. And so slowly byte by byte we figured out what the data was starting 781.52s - 789.94s | to mean. So this is the full card data format for the Saflock systems. It is in 789.94s - 793.18s | alphabetical order. So if you want to reproduce it you will have to figure out 793.18s - 797.42s | the correct order of the fields. There's a few logical fields in here. There's the 797.46s - 802.10s | card creation date. So this is like up to the second when the card was created at 802.10s - 806.94s | the front desk. There are card levels indicating if this is a guest key, a 806.94s - 811.38s | master key or an emergency key. There's quite a few of these levels. There's a 811.38s - 816.06s | few different types of cards but we'll get into those later on. There's a 816.06s - 820.46s | deadbolt override bit which sounds very interesting obviously. And then there's a 820.46s - 825.74s | few more fields. So the lock ID is an interesting one. This is just a numerical 825.82s - 830.66s | indicator in a database linking a specific, linking to a specific lock. So 830.66s - 834.74s | you can't simply figure out what the lock ID is for a specific room number. 834.74s - 839.66s | But if you know the lock ID for your room number you can sort of guess


chunk_id: 184_chunk_17
chunk_text:
if you want to reproduce it you will have to figure out 793.18s - 797.42s | the correct order of the fields. There's a few logical fields in here. There's the 797.46s - 802.10s | card creation date. So this is like up to the second when the card was created at 802.10s - 806.94s | the front desk. There are card levels indicating if this is a guest key, a 806.94s - 811.38s | master key or an emergency key. There's quite a few of these levels. There's a 811.38s - 816.06s | few different types of cards but we'll get into those later on. There's a 816.06s - 820.46s | deadbolt override bit which sounds very interesting obviously. And then there's a 820.46s - 825.74s | few more fields. So the lock ID is an interesting one. This is just a numerical 825.82s - 830.66s | indicator in a database linking a specific, linking to a specific lock. So 830.66s - 834.74s | you can't simply figure out what the lock ID is for a specific room number. 834.74s - 839.66s | But if you know the lock ID for your room number you can sort of guess what 839.66s - 845.18s | the room next door has as a lock ID. The other thing that we need to know to make 845.18s - 850.46s | cards for every deployment is the property ID. So this is a 12-bit number 850.46s - 854.54s | that is supposed to be different for every hotel. And to make a card for a 854.54s - 858.78s | hotel you need to know this property ID. And finally there's a sequence and 858.78s - 862.82s | combination field. And this was by far the most annoying field in this entire 862.82s - 869.78s | data format. And it took us quite a while to figure out how to work around this. So 869.78s - 875.30s | as I mentioned before, multiple card levels and card types. Most of the keys 875.30s - 879.94s | you will get when you check into a hotel will have lower levels. So guest keys, 879.94s - 884.50s | connector keys, suite keys and so on. And they typically only open a single room 884.50s - 889.10s | in the property. Then there's more special cards like housekeeping keys 889.10s - 893.98s | that typically open a


chunk_id: 184_chunk_18
chunk_text:
what 839.66s - 845.18s | the room next door has as a lock ID. The other thing that we need to know to make 845.18s - 850.46s | cards for every deployment is the property ID. So this is a 12-bit number 850.46s - 854.54s | that is supposed to be different for every hotel. And to make a card for a 854.54s - 858.78s | hotel you need to know this property ID. And finally there's a sequence and 858.78s - 862.82s | combination field. And this was by far the most annoying field in this entire 862.82s - 869.78s | data format. And it took us quite a while to figure out how to work around this. So 869.78s - 875.30s | as I mentioned before, multiple card levels and card types. Most of the keys 875.30s - 879.94s | you will get when you check into a hotel will have lower levels. So guest keys, 879.94s - 884.50s | connector keys, suite keys and so on. And they typically only open a single room 884.50s - 889.10s | in the property. Then there's more special cards like housekeeping keys 889.10s - 893.98s | that typically open a range of rooms. So maybe a floor or a specific tower in the 893.98s - 898.06s | hotel. And then finally we get to the interesting ones like the emergency key. 898.06s - 902.90s | And the emergency key is interesting because since it's used for emergencies 902.90s - 907.22s | it also overrides the deadbolt. So if someone inside of the room flips the 907.22s - 910.82s | deadbolt and someone taps an emergency key on the card it will allow them to 910.86s - 914.58s | override this deadbolt. I think it's important to realize if you're staying in 914.58s - 920.18s | a hotel the deadbolt is just software controlled. Two more interesting key 920.18s - 923.86s | levels are the programming, primary programming key and secondary programming 923.86s - 928.34s | key. And we think the idea here is that you would tap one of these cards to a 928.34s - 935.77s | lock before you can actually reprogram the lock with an H86 programmer. So as 935.77s - 939.01s | Leonard said we spent quite a lot of time on the sequence and combination 939.01s - 942.05s | because we knew what every field meant


chunk_id: 184_chunk_19
chunk_text:
range of rooms. So maybe a floor or a specific tower in the 893.98s - 898.06s | hotel. And then finally we get to the interesting ones like the emergency key. 898.06s - 902.90s | And the emergency key is interesting because since it's used for emergencies 902.90s - 907.22s | it also overrides the deadbolt. So if someone inside of the room flips the 907.22s - 910.82s | deadbolt and someone taps an emergency key on the card it will allow them to 910.86s - 914.58s | override this deadbolt. I think it's important to realize if you're staying in 914.58s - 920.18s | a hotel the deadbolt is just software controlled. Two more interesting key 920.18s - 923.86s | levels are the programming, primary programming key and secondary programming 923.86s - 928.34s | key. And we think the idea here is that you would tap one of these cards to a 928.34s - 935.77s | lock before you can actually reprogram the lock with an H86 programmer. So as 935.77s - 939.01s | Leonard said we spent quite a lot of time on the sequence and combination 939.01s - 942.05s | because we knew what every field meant but we couldn't figure out the valid 942.05s - 946.25s | sequence combination for a lock. So each lock has its own combination value 946.25s - 951.21s | between 0 and 4095. And as Leonard said you can kind of guess what lock IDs are 951.21s - 954.77s | but guessing the combination is very painful. And there's also a sequence 954.77s - 957.89s | number and so this is used just as you check in and check out each guest gets 957.89s - 961.13s | their own sequence number. So for example if someone checks in after you they'll 961.13s - 964.79s | tap their sequence number and that will invalidate all the previous ones. So that 964.79s - 968.05s | prevents you know two people from having a valid key to the same room as that 968.05s - 971.73s | would be pretty bad. And the field is just the sequence encrypted and 971.73s - 975.81s | combined with a combination. And as I said this is really the only field that 975.81s - 981.41s | gave us any trouble in making a valid guess key. At first we tried to brute 981.41s - 986.25s | force the


chunk_id: 184_chunk_20
chunk_text:
but we couldn't figure out the valid 942.05s - 946.25s | sequence combination for a lock. So each lock has its own combination value 946.25s - 951.21s | between 0 and 4095. And as Leonard said you can kind of guess what lock IDs are 951.21s - 954.77s | but guessing the combination is very painful. And there's also a sequence 954.77s - 957.89s | number and so this is used just as you check in and check out each guest gets 957.89s - 961.13s | their own sequence number. So for example if someone checks in after you they'll 961.13s - 964.79s | tap their sequence number and that will invalidate all the previous ones. So that 964.79s - 968.05s | prevents you know two people from having a valid key to the same room as that 968.05s - 971.73s | would be pretty bad. And the field is just the sequence encrypted and 971.73s - 975.81s | combined with a combination. And as I said this is really the only field that 975.81s - 981.41s | gave us any trouble in making a valid guess key. At first we tried to brute 981.41s - 986.25s | force the field. Leonard tapped the Proxmark about 4,000 times trying to 986.25s - 991.97s | guess what the valid sequence number was. This doesn't work. I don't suggest it. The 991.97s - 995.65s | lock does detect that you're trying to just guess key cards and it kind of 995.65s - 1001.33s | shuts itself down. It's also very physically strenuous and annoying. Later 1001.33s - 1004.73s | kind of the crux of our discovery it was that we found that because these 1004.73s - 1007.73s | locks are offline they sometimes have to be re-sequenced if they become 1007.73s - 1012.25s | desynchronized with the front desk. And what a re-sequencing card does is it 1012.25s - 1015.21s | just simply tells lock hey this is your new sequence and this is your new 1015.21s - 1018.21s | combination. And that's perfect for us because those were the only two fields 1018.21s - 1022.41s | we didn't know. So we were able to create a key card that simply re-sequenced as a 1022.41s - 1025.77s | lock and tells it hey this is your new secret value and that's the only one you 1025.77s - 1031.56s | need to create


chunk_id: 184_chunk_21
chunk_text:
field. Leonard tapped the Proxmark about 4,000 times trying to 986.25s - 991.97s | guess what the valid sequence number was. This doesn't work. I don't suggest it. The 991.97s - 995.65s | lock does detect that you're trying to just guess key cards and it kind of 995.65s - 1001.33s | shuts itself down. It's also very physically strenuous and annoying. Later 1001.33s - 1004.73s | kind of the crux of our discovery it was that we found that because these 1004.73s - 1007.73s | locks are offline they sometimes have to be re-sequenced if they become 1007.73s - 1012.25s | desynchronized with the front desk. And what a re-sequencing card does is it 1012.25s - 1015.21s | just simply tells lock hey this is your new sequence and this is your new 1015.21s - 1018.21s | combination. And that's perfect for us because those were the only two fields 1018.21s - 1022.41s | we didn't know. So we were able to create a key card that simply re-sequenced as a 1022.41s - 1025.77s | lock and tells it hey this is your new secret value and that's the only one you 1025.77s - 1031.56s | need to create a forged key card. So now we have all the elements to make a full 1031.56s - 1036.12s | attack. So the idea is that you would start by obtaining any card from the 1036.12s - 1040.44s | hotel just to get the property ID. This can be your own card, this can be an 1040.44s - 1044.92s | expired card, can be a card you found on the floor from the Express checkout box 1044.92s - 1049.80s | or simply one you bought from eBay. So once you have the property ID we can 1049.80s - 1055.12s | start forging keys. So we forge a re-sequencing key card for a privileged 1055.12s - 1060.08s | level. So emergency or grandmaster. And the reason for picking emergency is that 1060.08s - 1064.52s | it works on all of the doors so you don't have to guess a lock ID anymore. 1064.52s - 1069.92s | Then you walk up to a door, you tap your re-sequencing key card, it re-sequences 1069.92s - 1073.28s | the lock and then you have your second key card that is an opening key for the 1073.28s - 1078.00s | same level and it will open


chunk_id: 184_chunk_22
chunk_text:
a forged key card. So now we have all the elements to make a full 1031.56s - 1036.12s | attack. So the idea is that you would start by obtaining any card from the 1036.12s - 1040.44s | hotel just to get the property ID. This can be your own card, this can be an 1040.44s - 1044.92s | expired card, can be a card you found on the floor from the Express checkout box 1044.92s - 1049.80s | or simply one you bought from eBay. So once you have the property ID we can 1049.80s - 1055.12s | start forging keys. So we forge a re-sequencing key card for a privileged 1055.12s - 1060.08s | level. So emergency or grandmaster. And the reason for picking emergency is that 1060.08s - 1064.52s | it works on all of the doors so you don't have to guess a lock ID anymore. 1064.52s - 1069.92s | Then you walk up to a door, you tap your re-sequencing key card, it re-sequences 1069.92s - 1073.28s | the lock and then you have your second key card that is an opening key for the 1073.28s - 1078.00s | same level and it will open the door. And the nice thing is you make this pair of 1078.00s - 1081.84s | cards once for every property and you can now walk around and open every 1081.84s - 1094.59s | single door in the hotel. So of course we also implemented this as a full 1094.63s - 1099.15s | proof-of-concept attack. At this point we had already written a PySaflock module. 1099.15s - 1102.75s | So it's a Python module that supports doing the key derivation function, 1102.75s - 1107.59s | decrypting the card data, deserializing it into the different fields. Then we can 1107.59s - 1112.39s | change fields, re-encrypt it or re-serialize it, re-encrypt it and then write it 1112.39s - 1116.11s | back to a card. And instead of implementing all of this within the 1116.11s - 1119.95s | Proxmark codebase, since we already had the Python script, we sort of made 1119.95s - 1124.43s | simple wrapper functions that call Proxmark codes to read and write stuff 1124.43s - 1131.07s | to a card. Then obviously these days we have to implement the same thing on a 1131.07s - 1136.47s | Flipper 0. This was relatively straightforward. You can make an NFC


chunk_id: 184_chunk_23
chunk_text:
the door. And the nice thing is you make this pair of 1078.00s - 1081.84s | cards once for every property and you can now walk around and open every 1081.84s - 1094.59s | single door in the hotel. So of course we also implemented this as a full 1094.63s - 1099.15s | proof-of-concept attack. At this point we had already written a PySaflock module. 1099.15s - 1102.75s | So it's a Python module that supports doing the key derivation function, 1102.75s - 1107.59s | decrypting the card data, deserializing it into the different fields. Then we can 1107.59s - 1112.39s | change fields, re-encrypt it or re-serialize it, re-encrypt it and then write it 1112.39s - 1116.11s | back to a card. And instead of implementing all of this within the 1116.11s - 1119.95s | Proxmark codebase, since we already had the Python script, we sort of made 1119.95s - 1124.43s | simple wrapper functions that call Proxmark codes to read and write stuff 1124.43s - 1131.07s | to a card. Then obviously these days we have to implement the same thing on a 1131.07s - 1136.47s | Flipper 0. This was relatively straightforward. You can make an NFC 1136.47s - 1140.11s | supported card plugin and that essentially has to implement three 1140.11s - 1144.47s | functions. So the first function is verify and that's essentially a function 1144.47s - 1148.83s | that tries to verify if the card you tapped is a Saflock card. As I mentioned 1148.83s - 1153.31s | earlier, sector 1 has a default key and you can use that default key to detect 1153.31s - 1158.19s | if the card is a Saflock card. Now that you should have a Saflock card, you go to 1158.19s - 1162.83s | the read function. The read function derives the key, so implements the KDF 1162.83s - 1167.95s | and then reads the relevant data blocks. Now that you have those data blocks, you 1167.95s - 1172.91s | can decrypt them, parse out the data and then from there generate, re-sequence an 1172.91s - 1178.67s | emergency card that gets stored on the Flipper's file system. Before anyone asks, 1178.67s - 1184.15s | we're not releasing this plugin, but there is a KDF plugin available on 1184.15s - 1187.75s | GitHub that someone else made and you can actually use that plugin to check 1187.75s -


chunk_id: 184_chunk_24
chunk_text:
1136.47s - 1140.11s | supported card plugin and that essentially has to implement three 1140.11s - 1144.47s | functions. So the first function is verify and that's essentially a function 1144.47s - 1148.83s | that tries to verify if the card you tapped is a Saflock card. As I mentioned 1148.83s - 1153.31s | earlier, sector 1 has a default key and you can use that default key to detect 1153.31s - 1158.19s | if the card is a Saflock card. Now that you should have a Saflock card, you go to 1158.19s - 1162.83s | the read function. The read function derives the key, so implements the KDF 1162.83s - 1167.95s | and then reads the relevant data blocks. Now that you have those data blocks, you 1167.95s - 1172.91s | can decrypt them, parse out the data and then from there generate, re-sequence an 1172.91s - 1178.67s | emergency card that gets stored on the Flipper's file system. Before anyone asks, 1178.67s - 1184.15s | we're not releasing this plugin, but there is a KDF plugin available on 1184.15s - 1187.75s | GitHub that someone else made and you can actually use that plugin to check 1187.75s - 1195.72s | if you're staying at a Saflock hotel. So as I mentioned previously, we actually 1195.72s - 1200.96s | found this at DEF CON two years ago and it was a very long disclosure process. So 1200.96s - 1204.80s | in August we kind of found, you know, the decryption key and we were able to read 1204.80s - 1207.92s | and write to the card, but we didn't actually figure out the re-sequencing 1208.08s - 1212.96s | until a month later. Finally, we were able to figure that out and we 1212.96s - 1217.36s | created a complete proof of concept. Unfortunately, Dorma Kava didn't have any 1217.36s - 1222.84s | disclosure process and so I had to message their CISO on LinkedIn. Luckily, 1222.84s - 1226.32s | he actually took it seriously and responded quickly and they actually have 1226.32s - 1231.80s | a VDP now, I think, which is great. We had our first meeting with them in October 1231.80s - 1236.50s | and from there I think we had at least 13 meetings with Dorma Kava talking 1236.50s - 1240.46s | about the vulnerability and how they were going to fix it. As I mentioned,


chunk_id: 184_chunk_25
chunk_text:
1195.72s | if you're staying at a Saflock hotel. So as I mentioned previously, we actually 1195.72s - 1200.96s | found this at DEF CON two years ago and it was a very long disclosure process. So 1200.96s - 1204.80s | in August we kind of found, you know, the decryption key and we were able to read 1204.80s - 1207.92s | and write to the card, but we didn't actually figure out the re-sequencing 1208.08s - 1212.96s | until a month later. Finally, we were able to figure that out and we 1212.96s - 1217.36s | created a complete proof of concept. Unfortunately, Dorma Kava didn't have any 1217.36s - 1222.84s | disclosure process and so I had to message their CISO on LinkedIn. Luckily, 1222.84s - 1226.32s | he actually took it seriously and responded quickly and they actually have 1226.32s - 1231.80s | a VDP now, I think, which is great. We had our first meeting with them in October 1231.80s - 1236.50s | and from there I think we had at least 13 meetings with Dorma Kava talking 1236.50s - 1240.46s | about the vulnerability and how they were going to fix it. As I mentioned, it's 1240.46s - 1244.58s | three million hotel locks and I don't think they were fully ready to do that 1244.58s - 1250.24s | upgrade for a while and it was quite a painful change. But in November 2023, they 1250.24s - 1254.62s | upgraded the first hotels to resolve the vulnerability, which was great. And then, 1254.62s - 1259.50s | as you may have seen, in March of 2024 we did a limited disclosure of saying, you 1259.50s - 1262.06s | know, these hotel locks have a vulnerability but, you know, we're not 1262.06s - 1266.34s | gonna say exactly what it is. At the time we published it, 36% of 1266.34s - 1271.14s | the locks have been upgraded. Today is our DEF CON talk. They only told us the 1271.14s - 1273.90s | majority of the locks have been updated. We don't have a specific percentage 1273.90s - 1278.34s | anymore. And they said nearly all Las Vegas properties are in the process of 1278.34s - 1283.22s | being mitigated or have been mitigated, more or less. 1284.74s - 1289.54s | Remediation. They added a new enhanced security mode and this is to their 1289.54s - 1293.90s


chunk_id: 184_chunk_26
chunk_text:
it's 1240.46s - 1244.58s | three million hotel locks and I don't think they were fully ready to do that 1244.58s - 1250.24s | upgrade for a while and it was quite a painful change. But in November 2023, they 1250.24s - 1254.62s | upgraded the first hotels to resolve the vulnerability, which was great. And then, 1254.62s - 1259.50s | as you may have seen, in March of 2024 we did a limited disclosure of saying, you 1259.50s - 1262.06s | know, these hotel locks have a vulnerability but, you know, we're not 1262.06s - 1266.34s | gonna say exactly what it is. At the time we published it, 36% of 1266.34s - 1271.14s | the locks have been upgraded. Today is our DEF CON talk. They only told us the 1271.14s - 1273.90s | majority of the locks have been updated. We don't have a specific percentage 1273.90s - 1278.34s | anymore. And they said nearly all Las Vegas properties are in the process of 1278.34s - 1283.22s | being mitigated or have been mitigated, more or less. 1284.74s - 1289.54s | Remediation. They added a new enhanced security mode and this is to their 1289.54s - 1293.90s | Ambiance software. So we mostly looked at system 6000. That's kind of deprecated 1293.90s - 1297.14s | now. There is a fix for it but it's not as good as the enhanced 1297.14s - 1302.06s | security mode. The new enhanced security mode has a new KDF. It encrypts the card 1302.06s - 1307.22s | data using AES, which is much better than a hard-coded substitution cipher. And it 1307.22s - 1310.74s | also uses MyFair Ultralight C. So even if you're able to decrypt the card data, 1310.74s - 1313.62s | it's still hard to actually write it to the card because you don't know the card 1313.62s - 1318.06s | keys. And as I mentioned previously, they also replaced all of the encoders and so 1318.06s - 1321.30s | there's a new encoder for making the keys that also has a secure element 1321.30s - 1328.25s | inside of it. So a lot of people ask us why did it take so long to fix these 1328.25s - 1332.21s | hotel locks? Why did it take two years? And it turns out that the main issue are 1332.21s - 1336.29s | the integrations. So of course first,


chunk_id: 184_chunk_27
chunk_text:
| Ambiance software. So we mostly looked at system 6000. That's kind of deprecated 1293.90s - 1297.14s | now. There is a fix for it but it's not as good as the enhanced 1297.14s - 1302.06s | security mode. The new enhanced security mode has a new KDF. It encrypts the card 1302.06s - 1307.22s | data using AES, which is much better than a hard-coded substitution cipher. And it 1307.22s - 1310.74s | also uses MyFair Ultralight C. So even if you're able to decrypt the card data, 1310.74s - 1313.62s | it's still hard to actually write it to the card because you don't know the card 1313.62s - 1318.06s | keys. And as I mentioned previously, they also replaced all of the encoders and so 1318.06s - 1321.30s | there's a new encoder for making the keys that also has a secure element 1321.30s - 1328.25s | inside of it. So a lot of people ask us why did it take so long to fix these 1328.25s - 1332.21s | hotel locks? Why did it take two years? And it turns out that the main issue are 1332.21s - 1336.29s | the integrations. So of course first, Tomacabra had to come up with a fix for 1336.29s - 1340.49s | their own hotel locks. But then if you start thinking about especially big Las 1340.49s - 1344.49s | Vegas properties, they have so many integrations with the hotel locks. So 1344.49s - 1349.45s | maybe you use the kiosk to check in. You've used the elevators. There's payment 1349.45s - 1353.97s | solutions in some hotels. And some hotels even have towel machines. And so 1353.97s - 1358.01s | when a hotel decides to upgrade their hotel locks, all of these systems have to 1358.01s - 1361.05s | be upgraded as well. And that typically means that they have to contact the 1361.05s - 1364.69s | manufacturers of these systems. And so you can imagine this takes a long time. 1364.69s - 1370.13s | Most of the locks have to be updated manually. That means that someone has to 1370.13s - 1373.05s | walk up to the door and hold the programmer in front of the lock for two 1373.05s - 1378.73s | minutes. Three million locks times two minutes is a lot of minutes. So that's it 1378.73s - 1384.61s | takes a long time. Then


chunk_id: 184_chunk_28
chunk_text:
Tomacabra had to come up with a fix for 1336.29s - 1340.49s | their own hotel locks. But then if you start thinking about especially big Las 1340.49s - 1344.49s | Vegas properties, they have so many integrations with the hotel locks. So 1344.49s - 1349.45s | maybe you use the kiosk to check in. You've used the elevators. There's payment 1349.45s - 1353.97s | solutions in some hotels. And some hotels even have towel machines. And so 1353.97s - 1358.01s | when a hotel decides to upgrade their hotel locks, all of these systems have to 1358.01s - 1361.05s | be upgraded as well. And that typically means that they have to contact the 1361.05s - 1364.69s | manufacturers of these systems. And so you can imagine this takes a long time. 1364.69s - 1370.13s | Most of the locks have to be updated manually. That means that someone has to 1370.13s - 1373.05s | walk up to the door and hold the programmer in front of the lock for two 1373.05s - 1378.73s | minutes. Three million locks times two minutes is a lot of minutes. So that's it 1378.73s - 1384.61s | takes a long time. Then additionally you have to convince property owners to 1384.61s - 1388.05s | perform this update. And that's also one of the reasons we had this limited 1388.05s - 1391.85s | disclosure initially. To make hotel owners aware of the vulnerability and 1391.85s - 1397.09s | give them some extra time to implement a fix. We were told that at the peak of 1397.09s - 1402.33s | deploying this fix, Tomacabra was resolving 500 properties per week. 1402.33s - 1408.88s | Another thing that has changed now in the new update is that the standard guest 1409.00s - 1413.76s | cards will be using ultralight C. And one of the reasons people are making the 1413.76s - 1417.48s | switch over to ultralight C now is that the cost of ultralight C cards has come 1417.48s - 1423.48s | down a lot over the last few years. So if we talk about card cost, we found a few 1423.48s - 1432.32s | statistics online. So on average a hotel is occupied 65%. An average stay at a 1432.32s - 1437.76s | hotel takes 1.8 nights. The average number of cards that gets made per stay 1437.76s - 1444.00s | is 2.


chunk_id: 184_chunk_29
chunk_text:
additionally you have to convince property owners to 1384.61s - 1388.05s | perform this update. And that's also one of the reasons we had this limited 1388.05s - 1391.85s | disclosure initially. To make hotel owners aware of the vulnerability and 1391.85s - 1397.09s | give them some extra time to implement a fix. We were told that at the peak of 1397.09s - 1402.33s | deploying this fix, Tomacabra was resolving 500 properties per week. 1402.33s - 1408.88s | Another thing that has changed now in the new update is that the standard guest 1409.00s - 1413.76s | cards will be using ultralight C. And one of the reasons people are making the 1413.76s - 1417.48s | switch over to ultralight C now is that the cost of ultralight C cards has come 1417.48s - 1423.48s | down a lot over the last few years. So if we talk about card cost, we found a few 1423.48s - 1432.32s | statistics online. So on average a hotel is occupied 65%. An average stay at a 1432.32s - 1437.76s | hotel takes 1.8 nights. The average number of cards that gets made per stay 1437.76s - 1444.00s | is 2. And only 25% of all cards are returned when you check out. Now if we 1444.00s - 1448.08s | think about big Las Vegas properties that have between 3,000 and 7,000 rooms, 1448.08s - 1453.04s | then you can imagine they make a lot of cards. So if we do a bit of simple math 1453.04s - 1461.84s | then we end up with a hotel with 5,000 rooms having roughly 660,000 stays per 1461.84s - 1466.76s | year. That means that around 1.3 million cards are made at one of these big 1466.76s - 1472.60s | properties of which only 300,000 are being returned after stays. So that means 1472.60s - 1478.16s | that a hotel needs to buy roughly 1 million cards per year. If you assume 10 1478.16s - 1483.44s | cents per card that's $100,000 just in RFID cards. Now if you think about a 1483.44s - 1488.64s | MyFair Classic card which is very cheap and maybe those were 10 cents, if an 1488.64s - 1494.00s | ultralight C card a few years back was 20 cents then that would mean $200,000 1494.24s - 1498.16s | in cards. And that's the reason you still find


chunk_id: 184_chunk_30
chunk_text:
And only 25% of all cards are returned when you check out. Now if we 1444.00s - 1448.08s | think about big Las Vegas properties that have between 3,000 and 7,000 rooms, 1448.08s - 1453.04s | then you can imagine they make a lot of cards. So if we do a bit of simple math 1453.04s - 1461.84s | then we end up with a hotel with 5,000 rooms having roughly 660,000 stays per 1461.84s - 1466.76s | year. That means that around 1.3 million cards are made at one of these big 1466.76s - 1472.60s | properties of which only 300,000 are being returned after stays. So that means 1472.60s - 1478.16s | that a hotel needs to buy roughly 1 million cards per year. If you assume 10 1478.16s - 1483.44s | cents per card that's $100,000 just in RFID cards. Now if you think about a 1483.44s - 1488.64s | MyFair Classic card which is very cheap and maybe those were 10 cents, if an 1488.64s - 1494.00s | ultralight C card a few years back was 20 cents then that would mean $200,000 1494.24s - 1498.16s | in cards. And that's the reason you still find a lot of MyFair Classic cards 1498.16s - 1503.80s | around. But luckily prices have been coming down also because there's more of 1503.80s - 1508.08s | these systems asking for ultralight C cards. And so they've become cheap enough 1508.08s - 1514.42s | to the point where hotels are now using ultralight C. So I guess most of the 1514.42s - 1517.70s | people in this room are staying at a hotel this week. So how can you tell if 1517.70s - 1523.02s | the hotel you're staying at is using Saflock and if it's fixed or not? It's 1523.02s - 1527.42s | relatively easy to see if a hotel is using Saflock. Typically you can only 1527.42s - 1531.18s | tell when you're checking in. If you look over the counter you can see the 1531.18s - 1536.26s | encoders. So we have two pictures of encoders on the slide here. The leftmost 1536.26s - 1541.62s | one is an old encoder. It's thicker, it's bigger. And the one on the right is a 1541.62s - 1546.82s | new one. Now if you see the old one you know it's a vulnerable system. If you see 1546.82s -


chunk_id: 184_chunk_31
chunk_text:
a lot of MyFair Classic cards 1498.16s - 1503.80s | around. But luckily prices have been coming down also because there's more of 1503.80s - 1508.08s | these systems asking for ultralight C cards. And so they've become cheap enough 1508.08s - 1514.42s | to the point where hotels are now using ultralight C. So I guess most of the 1514.42s - 1517.70s | people in this room are staying at a hotel this week. So how can you tell if 1517.70s - 1523.02s | the hotel you're staying at is using Saflock and if it's fixed or not? It's 1523.02s - 1527.42s | relatively easy to see if a hotel is using Saflock. Typically you can only 1527.42s - 1531.18s | tell when you're checking in. If you look over the counter you can see the 1531.18s - 1536.26s | encoders. So we have two pictures of encoders on the slide here. The leftmost 1536.26s - 1541.62s | one is an old encoder. It's thicker, it's bigger. And the one on the right is a 1541.62s - 1546.82s | new one. Now if you see the old one you know it's a vulnerable system. If you see 1546.82s - 1551.18s | the new one it could be a fixed system or it can be a system that is in the 1551.18s - 1556.90s | progress of being mitigated to the new solution. You can also quickly recognize 1556.90s - 1562.10s | the locks that are used in these systems. So the small black puck type lock with 1562.10s - 1567.82s | the S going to it is very common here. And those are Saflock locks. So if you 1567.82s - 1573.18s | see those you know it's a Saflock system. Then the next thing you can do is you 1573.18s - 1578.02s | get a card from when checking in. You can tell if it's a Mifer Classic or an 1578.02s - 1583.26s | Oatail HC card. So then you use your your favorite RFID tool which we all 1583.26s - 1587.82s | know is the Flipper Zero with Iceman firmware. Or you use an Android phone 1587.82s - 1591.34s | with the NFC tag info app and that allows you to tell what type of card it 1591.34s - 1596.74s | is. So if it's a Mifer Classic card then you know that the system is still 1596.74s


chunk_id: 184_chunk_32
chunk_text:
1551.18s | the new one it could be a fixed system or it can be a system that is in the 1551.18s - 1556.90s | progress of being mitigated to the new solution. You can also quickly recognize 1556.90s - 1562.10s | the locks that are used in these systems. So the small black puck type lock with 1562.10s - 1567.82s | the S going to it is very common here. And those are Saflock locks. So if you 1567.82s - 1573.18s | see those you know it's a Saflock system. Then the next thing you can do is you 1573.18s - 1578.02s | get a card from when checking in. You can tell if it's a Mifer Classic or an 1578.02s - 1583.26s | Oatail HC card. So then you use your your favorite RFID tool which we all 1583.26s - 1587.82s | know is the Flipper Zero with Iceman firmware. Or you use an Android phone 1587.82s - 1591.34s | with the NFC tag info app and that allows you to tell what type of card it 1591.34s - 1596.74s | is. So if it's a Mifer Classic card then you know that the system is still 1596.74s - 1601.54s | vulnerable to this attack. Or it's not a Saflock deployment so you have to 1601.54s - 1607.94s | really do all three of the steps. So how to protect yourself in Oatail. You see 1607.94s - 1612.46s | it's Saflock. You see it's Mifer Classic. Well you're probably screwed. But 1612.46s - 1617.82s | there's some things you can buy. There's a door bolt deadbolt velcro 1617.82s - 1620.46s | strap and that kind of holds the deadbolt closed. And so that kind of 1620.46s - 1624.20s | prevents it from opening externally. You can also get under door wedges which 1624.20s - 1626.98s | kind of drill themselves into the carpet and prevent the door from opening. 1626.98s - 1630.22s | Obviously there's a gun of hacks but they could be good if you travel a lot. 1630.22s - 1634.38s | And Deviant has some great videos about hotel security as well. And just in 1634.42s - 1638.06s | general even if you're not staying in a Saflock hotel you know maybe next year 1638.06s - 1644.98s | there'll be more vulnerabilities. So that's it. Summary. Reading a single card 1644.98s - 1649.10s | at a


chunk_id: 184_chunk_33
chunk_text:
- 1601.54s | vulnerable to this attack. Or it's not a Saflock deployment so you have to 1601.54s - 1607.94s | really do all three of the steps. So how to protect yourself in Oatail. You see 1607.94s - 1612.46s | it's Saflock. You see it's Mifer Classic. Well you're probably screwed. But 1612.46s - 1617.82s | there's some things you can buy. There's a door bolt deadbolt velcro 1617.82s - 1620.46s | strap and that kind of holds the deadbolt closed. And so that kind of 1620.46s - 1624.20s | prevents it from opening externally. You can also get under door wedges which 1624.20s - 1626.98s | kind of drill themselves into the carpet and prevent the door from opening. 1626.98s - 1630.22s | Obviously there's a gun of hacks but they could be good if you travel a lot. 1630.22s - 1634.38s | And Deviant has some great videos about hotel security as well. And just in 1634.42s - 1638.06s | general even if you're not staying in a Saflock hotel you know maybe next year 1638.06s - 1644.98s | there'll be more vulnerabilities. So that's it. Summary. Reading a single card 1644.98s - 1649.10s | at a hotel allows us to open any door at the property if it's vulnerable. The 1649.10s - 1654.06s | system has been in use since 1988. You'd say hey they didn't have Mifer Classic 1654.06s - 1657.50s | back then and it's true. But they did the same thing for MagStripe cards. So 1657.50s - 1661.62s | unfortunately the system has been vulnerable since before Leonard and I 1661.62s - 1668.66s | were even born. And you know many aspects of these systems still haven't 1668.66s - 1672.18s | been looked at. Once we found a way to you know make these master keys we 1672.18s - 1675.98s | didn't really care about the rest of it. But there's a wide scope. The locks have 1675.98s - 1680.58s | USB ports. The you know there's many many aspects to these systems and more 1680.58s - 1684.78s | vulnerabilities likely exist somewhere. Luckily the cost of the secure cards 1684.78s - 1688.70s | have come down a lot. Ultralight C, Deathfire, stuff like that. Obviously it's 1688.70s - 1692.54s | a lot better than using Mifer Classic which has been broken forever. And 1692.54s - 1695.54s | overall even though we had


chunk_id: 184_chunk_34
chunk_text:
hotel allows us to open any door at the property if it's vulnerable. The 1649.10s - 1654.06s | system has been in use since 1988. You'd say hey they didn't have Mifer Classic 1654.06s - 1657.50s | back then and it's true. But they did the same thing for MagStripe cards. So 1657.50s - 1661.62s | unfortunately the system has been vulnerable since before Leonard and I 1661.62s - 1668.66s | were even born. And you know many aspects of these systems still haven't 1668.66s - 1672.18s | been looked at. Once we found a way to you know make these master keys we 1672.18s - 1675.98s | didn't really care about the rest of it. But there's a wide scope. The locks have 1675.98s - 1680.58s | USB ports. The you know there's many many aspects to these systems and more 1680.58s - 1684.78s | vulnerabilities likely exist somewhere. Luckily the cost of the secure cards 1684.78s - 1688.70s | have come down a lot. Ultralight C, Deathfire, stuff like that. Obviously it's 1688.70s - 1692.54s | a lot better than using Mifer Classic which has been broken forever. And 1692.54s - 1695.54s | overall even though we had to message them on LinkedIn at first we did have a 1695.54s - 1698.86s | positive experience working with Dorma Kava. They didn't take it seriously and 1698.86s - 1705.46s | they didn't sue me. So that's always great. It's time for a demo. 1708.10s - 1727.76s | Okay we have two demos. Are we gonna attempt to show two demos? So for the 1727.76s - 1737.16s | first demo we'll be using the Proxmark 3. I have a few RFID cards here. One of 1737.16s - 1745.74s | them says valid. As you can tell it opens the lock. Now if someone is staying 1745.74s - 1750.38s | inside of the room and they have the deadbolt on then this card no longer 1750.38s - 1760.30s | works. So that's a normal behavior of regular guest cards. The second card I 1760.30s - 1769.79s | have says expired or invalid and that card obviously doesn't work. So we assume 1769.79s - 1773.79s | that this is the card the attacker finds in the hallway or it's maybe the 1773.79s - 1779.59s | card to their room. And finally I have the the two attacker cards labeled one 1779.59s -


chunk_id: 184_chunk_35
chunk_text:
to message them on LinkedIn at first we did have a 1695.54s - 1698.86s | positive experience working with Dorma Kava. They didn't take it seriously and 1698.86s - 1705.46s | they didn't sue me. So that's always great. It's time for a demo. 1708.10s - 1727.76s | Okay we have two demos. Are we gonna attempt to show two demos? So for the 1727.76s - 1737.16s | first demo we'll be using the Proxmark 3. I have a few RFID cards here. One of 1737.16s - 1745.74s | them says valid. As you can tell it opens the lock. Now if someone is staying 1745.74s - 1750.38s | inside of the room and they have the deadbolt on then this card no longer 1750.38s - 1760.30s | works. So that's a normal behavior of regular guest cards. The second card I 1760.30s - 1769.79s | have says expired or invalid and that card obviously doesn't work. So we assume 1769.79s - 1773.79s | that this is the card the attacker finds in the hallway or it's maybe the 1773.79s - 1779.59s | card to their room. And finally I have the the two attacker cards labeled one 1779.59s - 1783.59s | and two. And just to show you that I'm not cheating for the demo I'll tap these 1783.59s - 1792.79s | to the lock and show that the lock doesn't open. Okay so now we'll start by 1792.79s - 1803.78s | reading the expired or the invalid card with the Proxmark. So what we do here is 1803.78s - 1808.06s | we take the UID that we read from the card. We derive the key for the sectors. 1808.06s - 1813.18s | We read the data from the card. We decrypt it. We deserialize it. And here 1813.18s - 1816.86s | we're printing a few of the fields that are stored on the card. So you can see 1816.86s - 1821.18s | this is a level one card. So it's a regular guest key. It was made for the 1821.18s - 1825.54s | for the lead room. And you can also see that the card was created in 1990. And 1825.54s - 1829.06s | that means the card is expired and that's why it no longer works on this 1829.06s - 1834.46s | lock. Now what we really need from this card is the property ID. And using


chunk_id: 184_chunk_36
chunk_text:
1783.59s | and two. And just to show you that I'm not cheating for the demo I'll tap these 1783.59s - 1792.79s | to the lock and show that the lock doesn't open. Okay so now we'll start by 1792.79s - 1803.78s | reading the expired or the invalid card with the Proxmark. So what we do here is 1803.78s - 1808.06s | we take the UID that we read from the card. We derive the key for the sectors. 1808.06s - 1813.18s | We read the data from the card. We decrypt it. We deserialize it. And here 1813.18s - 1816.86s | we're printing a few of the fields that are stored on the card. So you can see 1816.86s - 1821.18s | this is a level one card. So it's a regular guest key. It was made for the 1821.18s - 1825.54s | for the lead room. And you can also see that the card was created in 1990. And 1825.54s - 1829.06s | that means the card is expired and that's why it no longer works on this 1829.06s - 1834.46s | lock. Now what we really need from this card is the property ID. And using this 1834.50s - 1841.77s | property ID we can now start making new cards. So I'll first reprogram the first 1841.77s - 1852.00s | card. So what we're making now is an emergency level re-sequence card. So 1852.00s - 1859.52s | that's the re-sequencing key. And the next key we make is an opening key. And 1859.52s - 1866.50s | now we're ready to break into hotel rooms. I'm gonna assume the person that's 1866.50s - 1869.42s | staying in this room has a deadbolt turned on and then we'll start carrying 1869.42s - 1877.86s | out the attack. So the first key re-sequences the lock and essentially 1877.86s - 1897.84s | enables the second card. And like I mentioned before you can use these two 1897.84s - 1901.60s | cards over and over again in the same property and open all of the all of the 1901.60s - 1906.20s | doors. Now the second demo is essentially the same thing but using the 1906.20s - 1913.74s | flipper zero. I hope it's visible on the screen. But the idea is that whatever I'm 1913.74s - 1916.58s | doing here on the flipper is the same thing as you see


chunk_id: 184_chunk_37
chunk_text:
this 1834.50s - 1841.77s | property ID we can now start making new cards. So I'll first reprogram the first 1841.77s - 1852.00s | card. So what we're making now is an emergency level re-sequence card. So 1852.00s - 1859.52s | that's the re-sequencing key. And the next key we make is an opening key. And 1859.52s - 1866.50s | now we're ready to break into hotel rooms. I'm gonna assume the person that's 1866.50s - 1869.42s | staying in this room has a deadbolt turned on and then we'll start carrying 1869.42s - 1877.86s | out the attack. So the first key re-sequences the lock and essentially 1877.86s - 1897.84s | enables the second card. And like I mentioned before you can use these two 1897.84s - 1901.60s | cards over and over again in the same property and open all of the all of the 1901.60s - 1906.20s | doors. Now the second demo is essentially the same thing but using the 1906.20s - 1913.74s | flipper zero. I hope it's visible on the screen. But the idea is that whatever I'm 1913.74s - 1916.58s | doing here on the flipper is the same thing as you see on the screen over 1916.58s - 1924.50s | there. So essentially we just go into the NFC menu. I'm using the expired card 1924.50s - 1939.87s | again. So I'll read the expired card. It tells us it's a Zephyr card. We can 1939.87s - 1944.03s | again see that the card level, the property ID, the lock ID and that this 1944.03s - 1949.51s | card was created in the 1990s. And in the background what this flipper app has 1949.51s - 1955.35s | done is it has automatically created two extra cards. So this first entry is a 1955.35s - 1959.79s | copy of the card we just read. And then the second one is the re-sequencing key. 1959.79s - 1972.49s | So we can start emulating this one. So now now the lock has been re-sequenced. 1972.49s - 1983.03s | We go back into the menu. We take our opening key. We emulate it. And it opens 1983.03s - 1996.30s | the lock. So thanks everyone for coming to the talk. If anyone has questions we'll 1996.30s - 2014.49s | try to answer them. I'm too short for this. Hello. Um is that the Iceman firmware 2014.67s


chunk_id: 184_chunk_38
chunk_text:
on the screen over 1916.58s - 1924.50s | there. So essentially we just go into the NFC menu. I'm using the expired card 1924.50s - 1939.87s | again. So I'll read the expired card. It tells us it's a Zephyr card. We can 1939.87s - 1944.03s | again see that the card level, the property ID, the lock ID and that this 1944.03s - 1949.51s | card was created in the 1990s. And in the background what this flipper app has 1949.51s - 1955.35s | done is it has automatically created two extra cards. So this first entry is a 1955.35s - 1959.79s | copy of the card we just read. And then the second one is the re-sequencing key. 1959.79s - 1972.49s | So we can start emulating this one. So now now the lock has been re-sequenced. 1972.49s - 1983.03s | We go back into the menu. We take our opening key. We emulate it. And it opens 1983.03s - 1996.30s | the lock. So thanks everyone for coming to the talk. If anyone has questions we'll 1996.30s - 2014.49s | try to answer them. I'm too short for this. Hello. Um is that the Iceman firmware 2014.67s - 2019.67s | up there? Yeah it's a special beta release. Alright. Ok actual question. Um you know 2023.37s - 2028.55s | considering what you said about like the you know the software from Dormakaba uh do 2028.55s - 2032.55s | you think the responsibility lies on Dormakaba or like the hotels for how long it's 2032.55s - 2036.69s | taking them to upgrade their systems? Thinking about like the the logging and even 2036.69s - 2043.54s | like the encryption method used for their cards? It's a good question. Um we also 2043.58s - 2048.82s | don't know entirely how Dormakaba is handling the like resolving or doing the the 2048.82s - 2053.82s | updates. How much of it hotels have to pay. How much Dormakaba pays and so on. Um I 2054.52s - 2058.60s | think that the logging stuff is more an idea we came up with ourselves. Like our idea 2058.60s - 2063.70s | was if if the front desk can can see logs of who's entering the rooms and so on. Then 2063.70s - 2068.14s | in theory it shouldn't be too difficult to check if someone is using a re-sequencing 2068.14s - 2071.78s |


chunk_id: 184_chunk_39
chunk_text:
- 2019.67s | up there? Yeah it's a special beta release. Alright. Ok actual question. Um you know 2023.37s - 2028.55s | considering what you said about like the you know the software from Dormakaba uh do 2028.55s - 2032.55s | you think the responsibility lies on Dormakaba or like the hotels for how long it's 2032.55s - 2036.69s | taking them to upgrade their systems? Thinking about like the the logging and even 2036.69s - 2043.54s | like the encryption method used for their cards? It's a good question. Um we also 2043.58s - 2048.82s | don't know entirely how Dormakaba is handling the like resolving or doing the the 2048.82s - 2053.82s | updates. How much of it hotels have to pay. How much Dormakaba pays and so on. Um I 2054.52s - 2058.60s | think that the logging stuff is more an idea we came up with ourselves. Like our idea 2058.60s - 2063.70s | was if if the front desk can can see logs of who's entering the rooms and so on. Then 2063.70s - 2068.14s | in theory it shouldn't be too difficult to check if someone is using a re-sequencing 2068.14s - 2071.78s | card for example. And you could have some alerts triggered when something like that 2071.82s - 2076.92s | happens. Ok and then Ian um you know I heard you were a degenerate gambler. Are you up or 2076.92s - 2081.92s | down? No I think I'm even now. Are you? Hell yeah. Ooh what's going on? Uh thank you so 2088.77s - 2093.45s | much for talking about the disclosure process and explaining all the other factors that 2093.45s - 2098.15s | weigh on timelines and things like that. Uh it's really important for all the researchers 2098.15s - 2101.95s | to understand that and I think it's wonderful. Did you find the process of working with 2101.95s - 2106.15s | them to be smooth the whole time? Or did was it like smooth with an executive and then 2106.15s - 2112.75s | like lawyers? Like how did that go? Uh they did ask us to sign an NDA at first but we 2112.75s - 2119.07s | said no. And from there it was pretty good. Uh I think obviously it was I think one of 2119.07s - 2123.17s | their first times you know going through this process. And


chunk_id: 184_chunk_40
chunk_text:
card for example. And you could have some alerts triggered when something like that 2071.82s - 2076.92s | happens. Ok and then Ian um you know I heard you were a degenerate gambler. Are you up or 2076.92s - 2081.92s | down? No I think I'm even now. Are you? Hell yeah. Ooh what's going on? Uh thank you so 2088.77s - 2093.45s | much for talking about the disclosure process and explaining all the other factors that 2093.45s - 2098.15s | weigh on timelines and things like that. Uh it's really important for all the researchers 2098.15s - 2101.95s | to understand that and I think it's wonderful. Did you find the process of working with 2101.95s - 2106.15s | them to be smooth the whole time? Or did was it like smooth with an executive and then 2106.15s - 2112.75s | like lawyers? Like how did that go? Uh they did ask us to sign an NDA at first but we 2112.75s - 2119.07s | said no. And from there it was pretty good. Uh I think obviously it was I think one of 2119.07s - 2123.17s | their first times you know going through this process. And so you know we just had to set 2123.17s - 2127.43s | our our expectations of like you know we're eventually going to disclose this and it needs 2127.43s - 2131.57s | to be fixed. And I think once once we all understood that it was it was ok. They were 2132.09s - 2136.73s | they never threatened to sue us or anything. Uh so it was never hostile at all. Cool. We're 2136.73s - 2141.41s | really proud of you. Thank you guys. I'll just add that I think for them it was very new. 2141.41s - 2148.65s | And thanks. Um and like the picture you see in this slide is actually um a video set that 2148.65s - 2153.95s | they had at their facilities. And on the website on unsafelock.com we have a small video 2153.95s - 2160.66s | showing the attack and that video was actually shot at the facility from Dormakabu. Thank 2160.68s - 2166.82s | you to them for that. Um did you say that the substitution table was the same for every 2166.82s - 2173.46s | property? So you said they replaced that with AES? Um in the enhanced mode it uses


chunk_id: 184_chunk_41
chunk_text:
so you know we just had to set 2123.17s - 2127.43s | our our expectations of like you know we're eventually going to disclose this and it needs 2127.43s - 2131.57s | to be fixed. And I think once once we all understood that it was it was ok. They were 2132.09s - 2136.73s | they never threatened to sue us or anything. Uh so it was never hostile at all. Cool. We're 2136.73s - 2141.41s | really proud of you. Thank you guys. I'll just add that I think for them it was very new. 2141.41s - 2148.65s | And thanks. Um and like the picture you see in this slide is actually um a video set that 2148.65s - 2153.95s | they had at their facilities. And on the website on unsafelock.com we have a small video 2153.95s - 2160.66s | showing the attack and that video was actually shot at the facility from Dormakabu. Thank 2160.68s - 2166.82s | you to them for that. Um did you say that the substitution table was the same for every 2166.82s - 2173.46s | property? So you said they replaced that with AES? Um in the enhanced mode it uses AES. Um I 2173.46s - 2178.10s | think they made if you're still using the old system 6000 my understanding is it's no longer 2178.10s - 2182.94s | a substitution table. I don't know if it uses AES or um but it's it's something that's 2182.94s - 2186.58s | specific to each hotel at least which is better than what they had before. That was my 2186.60s - 2191.14s | question. Are the keys now specific to each property like or do you know one way or the 2191.14s - 2199.17s | other? That's our understanding. Yeah. Fingers crossed. Alright thank you. Hi. Um so you 2199.17s - 2205.11s | mentioned when you re-sequence a lock um it invalidates all of the existing cards with I'm 2205.11s - 2210.41s | assuming lower sequence numbers. Does that also happen with the emergency card that you 2210.41s - 2217.77s | re-sequence the lock with? So I I think you were asking about invalidating older cards and 2217.79s - 2223.33s | sequence numbers right? Yeah. Yeah. Um so the idea or at least the way we think it works is if 2223.33s - 2227.67s | you check in at the hotel the sequence


chunk_id: 184_chunk_42
chunk_text:
AES. Um I 2173.46s - 2178.10s | think they made if you're still using the old system 6000 my understanding is it's no longer 2178.10s - 2182.94s | a substitution table. I don't know if it uses AES or um but it's it's something that's 2182.94s - 2186.58s | specific to each hotel at least which is better than what they had before. That was my 2186.60s - 2191.14s | question. Are the keys now specific to each property like or do you know one way or the 2191.14s - 2199.17s | other? That's our understanding. Yeah. Fingers crossed. Alright thank you. Hi. Um so you 2199.17s - 2205.11s | mentioned when you re-sequence a lock um it invalidates all of the existing cards with I'm 2205.11s - 2210.41s | assuming lower sequence numbers. Does that also happen with the emergency card that you 2210.41s - 2217.77s | re-sequence the lock with? So I I think you were asking about invalidating older cards and 2217.79s - 2223.33s | sequence numbers right? Yeah. Yeah. Um so the idea or at least the way we think it works is if 2223.33s - 2227.67s | you check in at the hotel the sequence gets incremented and once a lock sees a higher 2227.67s - 2232.87s | sequence number it stop accept stops accepting older sequence numbers. And the same thing 2232.87s - 2237.65s | is probably true for emergency cards. Uh but since our first card sort of re-sequences the 2237.65s - 2242.31s | lock and tells it this is now your sequence number we can then use our our lock. So the 2242.39s - 2249.43s | re-sequencing cards can have any sequence number you want. So then the older cards that 2249.43s - 2254.87s | worked on the lock before that will get invalidated as a result? I couldn't get it. So I 2254.87s - 2258.95s | think you're asking if we do our attack do the guest key cards get invalidated? Yeah. So the 2258.95s - 2263.01s | sequence is specific to each level so in our attack we're doing the emergency key cards so it 2263.01s - 2267.55s | would break the emergency key cards for the hotel but the guest keys would be unaffected. Um 2268.23s - 2279.20s | Gotcha. Thank you. Is it possible to brute force the property ID so then you wouldn't need 2279.20s - 2284.90s


chunk_id: 184_chunk_43
chunk_text:
gets incremented and once a lock sees a higher 2227.67s - 2232.87s | sequence number it stop accept stops accepting older sequence numbers. And the same thing 2232.87s - 2237.65s | is probably true for emergency cards. Uh but since our first card sort of re-sequences the 2237.65s - 2242.31s | lock and tells it this is now your sequence number we can then use our our lock. So the 2242.39s - 2249.43s | re-sequencing cards can have any sequence number you want. So then the older cards that 2249.43s - 2254.87s | worked on the lock before that will get invalidated as a result? I couldn't get it. So I 2254.87s - 2258.95s | think you're asking if we do our attack do the guest key cards get invalidated? Yeah. So the 2258.95s - 2263.01s | sequence is specific to each level so in our attack we're doing the emergency key cards so it 2263.01s - 2267.55s | would break the emergency key cards for the hotel but the guest keys would be unaffected. Um 2268.23s - 2279.20s | Gotcha. Thank you. Is it possible to brute force the property ID so then you wouldn't need 2279.20s - 2284.90s | another key from the same hotel? Um we could speculate that there's a way to do it. I don't 2284.90s - 2288.30s | know if I would do it via brute forcing because it is pretty painful like you have to 2288.30s - 2293.54s | physically move the device you know across the lock each time. Um but as I said like the USB 2293.54s - 2297.62s | port seemed pretty interesting to us and there may be a way to like get that info from it. Uh 2297.66s - 2305.50s | we just didn't look at that surface at all really so. Thanks. Two questions um one are you 2305.50s - 2313.94s | staying at Resort World? Two is Resort World a Safelock co- hotel? I'm sorry I couldn't hear 2313.94s - 2322.58s | the question. The second one was uh is Resort World a Safelock hotel? Yeah I. We've we've 2322.58s - 2326.42s | both stayed at Resort World and uh we believe it's been fixed there. I believe all the cards 2326.42s - 2336.44s | are ultralight C there so. So for the uh legacy encoder that uh Dormakaba is replacing um it 2336.44s - 2341.30s


