Swiss Cybervoting PIT(falls)
Kirschner, Jannis
The Swiss democracy is one of it's kind. Digitization is starting to affect even our most critical processes, such as voting. When a piece of code suddenly gets responsible for democracy, it's only natural that the voices get loud and many questions get raised: Is our democracy at stake? Do we have to fear for our privacy? Is electronic voting even feasible in Switzerland? Is such a solution secure? As part of a mandatory Public Intrusion Test (PIT), the Swisspost released their e-voting source code to the world and started a heated debate - far beyond the Swiss borders. Not only the codebase revealed several problems during the PIT. Interesting scoping, redefining the term "open source" and unreleased security audits were only some of the issues that security researchers faced and caused controversy. In this talk we will have a look at many technical and non-technical aspects of the e-voting solution and PIT from the view of a participating security researcher.
 So, the Swiss democracy is one of its kind. No other country lets its citizens have that much of an impact on their rules and regulations. Meanwhile, in a time where everything gets digitized, it's only a natural conclusion that this might also affect voting someday. So earlier this year, the Swiss Post released their e-voting source code as part of a mandatory public intrusion test, or PIT for short. Yeah, and that's where our story starts. My name is Janis Kirschner, I'm a Swiss cybersecurity researcher and CTF player. Together with my research team, ZEDUAT0, we analyzed the Swiss e-voting source code. Obviously, my views are my own, not my employers, grandmas or dogs. So, a little bit of background information. Why should we vote digitally in the first place? So one of the main arguments was that it's comfortable for expats, for people living abroad, because for them, voting used to be quite a hassle. They have to send the votes per mail, and sometimes the mail gets lost or arrived too late, so that's one of the main reasons. Also it should attract young voters, and it should make voting more accessible to the public. However, with the e-voting also comes with major downsides. Security risks are on scale. You don't have to bribe a few thousand people, you have to find the right exploit, and maybe you can even do it in the comfort of your home and home. Also, it's very expensive to maintain, and the systems must be trusted, and it's hard to create that trust, because how do you make sure that the software running on these voting machines is actually the software that has been released or tested? The first thing that comes to mind is a checksum. I mean, checksums are great, right? But how do you make sure the checksum program is right and not just the static string? So that's one of the major problems. I often hear a comparison between electronic voting and electronic banking. However, I think there are major differences, and in my opinion it's easier to protect electronic banking, because there you have transactions between two parties that can easily be identified and corrected in electronic voting. You have to guarantee absolute anonymity for the voter, which makes it pretty hard. There are two components, there is the universal verifiability and the individual verifiability that are supposed to make you validate your votes mathematically. These are some core components of electronic voting. So yeah, the process is if you vote offline, you usually have your vote, and you put it in a ballot box, and then you have a lot of people that count the votes. You have election helpers, you have election observers, et cetera. But if you vote online, you just send your request to the server, and afterwards you get a checksum back. And that checksum is for your individual verifiability that you can prove mathematically that your vote has been counted correctly. On the other side, for the government, they get the universal verifiability where they can check if all votes have been counted correctly, mathematically. So fast forward a bit. Electronic voting is nothing new, per se. Many canons already had electronic voting solutions in place, for example Basel or Geneva. However, the new parties that the government wanted to use electronic voting as an official channel, as an official voting channel all over Switzerland. So there were some problems. Geneva had to stop their e-voting program completely, and Basel is on the verge of it, because electronic voting is extremely expensive. There were some studies that said for every effective user that used electronic voting, over 10 years, the canton of Basel would have to pay around 4,000 Swiss francs, which is honestly quite a lot. And Geneva is an interesting example, because it developed its own electronic voting solution that has been used by some of the canton in Switzerland. So source code publication. It was pretty interesting when we could get our hands on this very special code, this very important code. And so it started to the great news. We went to the website, we wanted to download it, and we were greeted with a non-disclosing agreement. This struck me as odd, because I thought the code was supposed to be open source. However, the Swiss Post introduced open code, which is basically, releases a snapshot of the code under an NDA. So the code is public, but it's not really open source, not at all. So yeah. Nevertheless, we signed up for it, because we wanted to test the code. And the first thing we noticed is how big the code actually was. Like it was around a quarter million lines of code. It was really big. And it featured a microservice architecture of several components that talk with each other. It was really, really a big solution. And another thing that was really, really big was the dependencies. They had a lot of dependencies. Like really a lot. And history has shown that dependencies can be really dangerous. One example that I like to come up with is EventStream early 2018, where a developer got tired of maintaining his nice little project and transferred ownership to someone who offered help. However, the person was a malicious actor. And yeah, now a few thousand programs featured malware in it. And also in the eVoting code, we found some dependencies that were party libraries that were vulnerable to several exploits. However, the functions weren't exactly used. So the risk wasn't that big. But the fact that these libraries were present shows that, yeah, it's a real threat and that patch management is hard. So where do you start when you got such a big software? The first point would be documentation. You look at how does it work, what's the threat model, just look how it works. So in the Geneva system, they had a lot of documentation. They had like threat models for every component. But in the new Swiss Post system, there were only three high-level documents. Some about the cryptography, a little bit high-level voting workflow, a little bit lower level. It wasn't that useful. It also featured some API descriptions, but most of them were internal and weren't of much use. But there was something interesting. There were security audits before the public intrusion test. And these are great because you can see maybe there were invalid patches or just see what are the core parts that are interesting to look at. So we went to the Swiss Post website, we downloaded it, and the file sizes seemed oddly small. Now when you open these PDFs, they only seem to contain the covers in the table of contents. Honest mistake, of course, everybody published the wrong thing. But after some further investigation, it showed that this was on purpose to protect the IP law of the company that audited it. And they didn't want to give out those reports, which was kind of a bummer. So okay, we had to work without any documentation. So next thing you usually do is, yeah, set up the system and check a bit how does it work, how does it interact, how play with it, however you couldn't build the system. The system wasn't buildable at all. The system wasn't meant to be built. The system relied on an internal build server at the development company in Spain. And you were only supposed to access the system during the official public intrusion test where they provided you with test instance. So even with some public effort to reconstruct the source code, by several parties, it didn't work out. It was just a too limited time frame. And yeah, the system was too big. So all that was left was static analysis over the whole thing. So during our research, the media blew up a bit about the news of some e-voting leak. This is odd, I thought, because the system was released, right, where there's some components they were hiding or something. No, it turns out some people took the source code and uploaded it to their own GitHub repository. So others could evade the non-disclosement agreements. And obviously, there were DMCA claims filed against it. And so this news could have been avoided if they would have open sourced the solution. So this function is really interesting. How does it make you feel? How does it make you feel with user inputs? How does it make you feel with user input that's not validated? Yeah, you know what I want to imply here. The component called a secure data manager didn't seem as secure at all. However, the post assured us that it's actually very secure because the cantons that run this component would use some air gaps. And air gaps have proven to be very effective over time, right? So yeah, very secure and out of scope. But they were happy to tell us that they would sign patch it. So it's all great. So this was around the time when the actual public intrusion test started. And you were provided with two URLs that you could test. It was the voting workflow and the administration workflow. Well, you could only test the voting workflow. The administration workflow required some certificate based authentication. And however, they didn't provide these certificates. They didn't provide them on purpose because it wouldn't be realistic to provide them, right? So you couldn't test the admin interface at all, maybe through post exploitation. So all that was left was the voting workflow, which brings us to the pit scope. To illustrate it, we started out with around a quarter million lines of code, right? We put it through a public intrusion test and we get this. This isn't cut off. These are nine rest end points. That was the pit scope. Yeah, nine rest end points, which were very interesting. We looked at them. Surely they must be very secure. I mean, security must be tight there. But even with that scope, we still found some stuff. Turns out they used the X4Water4 headers, which transmit your IP address. You can change them client side. And they relied on these headers for the internal Splunk logs. So you could just move some arbitrary IP addresses into their logs, into their internal logs. This one was also accepted as one of the few vulnerabilities of the system, which is really interesting even with the narrow scope. And do you remember the universal verifiability from the beginning? Yeah, apparently it's been broken as well. Some researchers found that apparently if you had access to the system and if you could change the votes theoretically onto some circumstances, you could also do it undetectable. And so much for the e-voting solution. Apparently they weren't allowed to continue with it anymore. What holds the future? Currently, there were discussions about an e-voting moratorium in Switzerland where they wanted to hold all e-voting projects for five years. And I've also seen developments made by big corporations, Microsoft recently released an e-voting library written in plain C. Must be interesting to look at. And yeah, it still features a lot of interesting research area. So in conclusion, e-voting is interesting, but with great power comes great responsibility. And if you want to develop an e-voting system, please put sufficient care into it. Thank you. Is there any questions? If yes, go to the microphones to the left or the right. All of its weekly bhg program requests. Yeah, to the left. Did you have a chance to take a look at the source code from the Geneva solution as well? Or only the post? Swiss Post System, I didn't audit Geneva system. However, I looked at it from just from the perspective. Geneva did a lot of things right there. They open sourced it properly, they provided lots of documentation, and it just seemed a little bit more fitting. So I just looked at it from a program perspective. They made it easier for researchers. They had also a buildable system, they provided docker containers. So that's for the Geneva system. But I can't make any assumptions from a co-perspective. On the right. So thanks for the talk. Do you know why you couldn't build the source code? Was it a part of source code missing or something like that? So basically the source code relied on an internal build server at Skytel. So if you wanted to build it, you would need to have all the correct components, right? And you would basically need to reconstruct the build process for you. So since they didn't provide that, it would have been very, very complicated. And some people tried exactly that to figure out which components were used and write your own build scripts. But the problem was that there wasn't enough time to do that. Okay. To the left. Hello. If there were no vulnerability with this universal verifiability, wouldn't Switzerland have online voting? And can you tell me a bit more about this universal verifiability, vulnerability, what access to the system should the operator have to use it? So basically you're saying that what are the effects of the universal verifiability vulnerabilities? If this problem wouldn't have appeared, then Switzerland would have had online voting for the elections in October, right? Quite possibly. Quite possibly. I mean, there were other problems, like especially the one with the source code that wasn't open sourced in some parts were missing and you couldn't build it. Usually the text from the government said that you should be able to build it. Maybe this would have caused problems, but it was certainly an important factor that it can be built. Yeah, that it can be employed. Yeah, then a big thanks and a big applause. Thank you.
 So, the Swiss democracy is one of its kind.  No other country lets its citizens have that much of an impact on their rules and regulations.  Meanwhile, in a time where everything gets digitized, it's only a natural conclusion  that this might also affect voting someday.  So earlier this year, the Swiss Post released their e-voting source code as part of a mandatory  public intrusion test, or PIT for short.  Yeah, and that's where our story starts.  My name is Janis Kirschner, I'm a Swiss cybersecurity researcher and CTF player.  Together with my research team, ZEDUAT0, we analyzed the Swiss e-voting source code.  Obviously, my views are my own, not my employers, grandmas or dogs.  So, a little bit of background information.  Why should we vote digitally in the first place?  So one of the main arguments was that it's comfortable for expats, for people living abroad,  because for them, voting used to be quite a hassle.  They have to send the votes per mail, and sometimes the mail gets lost or arrived too  late, so that's one of the main reasons.  Also it should attract young voters, and it should make voting more accessible to the  public.  However, with the e-voting also comes with major downsides.  Security risks are on scale.  You don't have to bribe a few thousand people, you have to find the right exploit, and maybe  you can even do it in the comfort of your home and home.  Also, it's very expensive to maintain, and the systems must be trusted, and it's hard  to create that trust, because how do you make sure that the software running on these voting  machines is actually the software that has been released or tested?  The first thing that comes to mind is a checksum.  I mean, checksums are great, right?  But how do you make sure the checksum program is right and not just the static string?  So that's one of the major problems.  I often hear a comparison between electronic voting and electronic banking.  However, I think there are major differences, and in my opinion it's easier to protect  electronic banking, because there you have transactions between two parties that can  easily be identified and corrected in electronic voting.  You have to guarantee absolute anonymity for the voter, which makes it pretty hard.  There are two components, there is the universal verifiability and the individual verifiability  that are supposed to make you validate your votes mathematically.  These are some core components of electronic voting.  So yeah, the process is if you vote offline, you usually have your vote, and you put it  in a ballot box, and then you have a lot of people that count the votes.  You have election helpers, you have election observers, et cetera.  But if you vote online, you just send your request to the server, and afterwards you  get a checksum back.  And that checksum is for your individual verifiability that you can prove mathematically  that your vote has been counted correctly.  On the other side, for the government, they get the universal verifiability where they  can check if all votes have been counted correctly, mathematically.  So fast forward a bit.  Electronic voting is nothing new, per se.  Many canons already had electronic voting solutions in place, for example Basel or Geneva.  However, the new parties that the government wanted to use electronic voting as an official  channel, as an official voting channel all over Switzerland.  So there were some problems.  Geneva had to stop their e-voting program completely, and Basel is on the verge of it,  because electronic voting is extremely expensive.  There were some studies that said for every effective user that used electronic voting,  over 10 years, the canton of Basel would have to pay around 4,000 Swiss francs, which is  honestly quite a lot.  And Geneva is an interesting example, because it developed its own electronic voting solution  that has been used by some of the canton in Switzerland.  So source code publication.  It was pretty interesting when we could get our hands on this very special code, this  very important code.  And so it started to the great news.  We went to the website, we wanted to download it, and we were greeted with a non-disclosing  agreement.  This struck me as odd, because I thought the code was supposed to be open source.  However, the Swiss Post introduced open code, which is basically, releases a snapshot of  the code under an NDA.  So the code is public, but it's not really open source, not at all.  So yeah.  Nevertheless, we signed up for it, because we wanted to test the code.  And the first thing we noticed is how big the code actually was.  Like it was around a quarter million lines of code.  It was really big.  And it featured a microservice architecture of several components that talk with each  other.  It was really, really a big solution.  And another thing that was really, really big was the dependencies.  They had a lot of dependencies.  Like really a lot.  And history has shown that dependencies can be really dangerous.  One example that I like to come up with is EventStream early 2018, where a developer  got tired of maintaining his nice little project and transferred ownership to someone who offered  help.  However, the person was a malicious actor.  And yeah, now a few thousand programs featured malware in it.  And also in the eVoting code, we found some dependencies that were party libraries that  were vulnerable to several exploits.  However, the functions weren't exactly used.  So the risk wasn't that big.  But the fact that these libraries were present shows that, yeah, it's a real threat and that  patch management is hard.  So where do you start when you got such a big software?  The first point would be documentation.  You look at how does it work, what's the threat model, just look how it works.  So in the Geneva system, they had a lot of documentation.  They had like threat models for every component.  But in the new Swiss Post system, there were only three high-level documents.  Some about the cryptography, a little bit high-level voting workflow, a little bit lower  level.  It wasn't that useful.  It also featured some API descriptions, but most of them were internal and weren't of  much use.  But there was something interesting.  There were security audits before the public intrusion test.  And these are great because you can see maybe there were invalid patches or just see what  are the core parts that are interesting to look at.  So we went to the Swiss Post website, we downloaded it, and the file sizes seemed oddly small.  Now when you open these PDFs, they only seem to contain the covers in the table of contents.  Honest mistake, of course, everybody published the wrong thing.  But after some further investigation, it showed that this was on purpose to protect the IP  law of the company that audited it.  And they didn't want to give out those reports, which was kind of a bummer.  So okay, we had to work without any documentation.  So next thing you usually do is, yeah, set up the system and check a bit how does it work,  how does it interact, how play with it, however you couldn't build the system.  The system wasn't buildable at all.  The system wasn't meant to be built.  The system relied on an internal build server at the development company in Spain.  And you were only supposed to access the system during the official public intrusion test  where they provided you with test instance.  So even with some public effort to reconstruct the source code, by several parties, it didn't  work out.  It was just a too limited time frame.  And yeah, the system was too big.  So all that was left was static analysis over the whole thing.  So during our research, the media blew up a bit about the news of some e-voting leak.  This is odd, I thought, because the system was released, right, where there's some components  they were hiding or something.  No, it turns out some people took the source code and uploaded it to their own GitHub repository.  So others could evade the non-disclosement agreements.  And obviously, there were DMCA claims filed against it.  And so this news could have been avoided if they would have open sourced the solution.  So this function is really interesting.  How does it make you feel?  How does it make you feel with user inputs?  How does it make you feel with user input that's not validated?  Yeah, you know what I want to imply here.  The component called a secure data manager didn't seem as secure at all.  However, the post assured us that it's actually very secure because the cantons that run this  component would use some air gaps.  And air gaps have proven to be very effective over time, right?  So yeah, very secure and out of scope.  But they were happy to tell us that they would sign patch it.  So it's all great.  So this was around the time when the actual public intrusion test started.  And you were provided with two URLs that you could test.  It was the voting workflow and the administration workflow.  Well, you could only test the voting workflow.  The administration workflow required some certificate based authentication.  And however, they didn't provide these certificates.  They didn't provide them on purpose because it wouldn't be realistic to provide them, right?  So you couldn't test the admin interface at all, maybe through post exploitation.  So all that was left was the voting workflow, which brings us to the pit scope.  To illustrate it, we started out with around a quarter million lines of code, right?  We put it through a public intrusion test and we get this.  This isn't cut off.  These are nine rest end points.  That was the pit scope.  Yeah, nine rest end points, which were very interesting.  We looked at them.  Surely they must be very secure.  I mean, security must be tight there.  But even with that scope, we still found some stuff.  Turns out they used the X4Water4 headers, which transmit your IP address.  You can change them client side.  And they relied on these headers for the internal Splunk logs.  So you could just move some arbitrary IP addresses into their logs, into their internal logs.  This one was also accepted as one of the few vulnerabilities of the system, which is really  interesting even with the narrow scope.  And do you remember the universal verifiability from the beginning?  Yeah, apparently it's been broken as well.  Some researchers found that apparently if you had access to the system and if you could  change the votes theoretically onto some circumstances, you could also do it undetectable.  And so much for the e-voting solution.  Apparently they weren't allowed to continue with it anymore.  What holds the future?  Currently, there were discussions about an e-voting moratorium in Switzerland where  they wanted to hold all e-voting projects for five years.  And I've also seen developments made by big corporations, Microsoft recently released  an e-voting library written in plain C. Must be interesting to look at.  And yeah, it still features a lot of interesting research area.  So in conclusion, e-voting is interesting, but with great power comes great responsibility.  And if you want to develop an e-voting system, please put sufficient care into it.  Thank you.  Is there any questions?  If yes, go to the microphones to the left or the right.  All of its weekly bhg program requests.  Yeah, to the left.  Did you have a chance to take a look at the source code from the Geneva solution as well?  Or only the post?  Swiss Post System, I didn't audit Geneva system. However, I looked at it from just from the perspective.  Geneva did a lot of things right there. They open sourced it properly, they provided lots of documentation,  and it just seemed a little bit more fitting. So I just looked at it from a program perspective.  They made it easier for researchers. They had also a buildable system, they provided docker containers.  So that's for the Geneva system. But I can't make any assumptions from a co-perspective.  On the right.  So thanks for the talk. Do you know why you couldn't build the source code?  Was it a part of source code missing or something like that?  So basically the source code relied on an internal build server at Skytel.  So if you wanted to build it, you would need to have all the correct components, right?  And you would basically need to reconstruct the build process for you.  So since they didn't provide that, it would have been very, very complicated.  And some people tried exactly that to figure out which components were used and write your own build scripts.  But the problem was that there wasn't enough time to do that.  Okay. To the left.  Hello. If there were no vulnerability with this universal verifiability, wouldn't Switzerland have online voting?  And can you tell me a bit more about this universal verifiability, vulnerability,  what access to the system should the operator have to use it?  So basically you're saying that what are the effects of the universal verifiability vulnerabilities?  If this problem wouldn't have appeared, then Switzerland would have had online voting for the elections in October, right?  Quite possibly.  Quite possibly. I mean, there were other problems,  like especially the one with the source code that wasn't open sourced in some parts were missing and you couldn't build it.  Usually the text from the government said that you should be able to build it.  Maybe this would have caused problems, but it was certainly an important factor that it can be built.  Yeah, that it can be employed.  Yeah, then a big thanks and a big applause.  Thank you.
36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_0_59.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_60_107.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_108_251.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_252_10727.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_10728_11231.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_11232_15635.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_15636_15923.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_15924_16355.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_16356_16775.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_16776_17195.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_17196_17687.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_17688_17879.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_17880_18287.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_18288_19235.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_19236_20003.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_20004_20903.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_20904_21371.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_21372_22043.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_22044_22451.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_22452_23159.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_23160_23999.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_24000_26255.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_26256_27143.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_27144_27203.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_27204_27251.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_27252_27311.png 36c3-chaoswest-88-eng-Swiss_Cybervoting_PIT_falls_hd_27312_27739.png
So, the Swiss democracy is one of its kind. No other country lets its citizens have that much of an impact on their rules and regulations. Meanwhile, in a time where everything gets digitized, it's only a natural conclusion that this might also affect voting someday. So earlier this year, the Swiss Post released their e-voting source code as part of a mandatory public intrusion test, or PIT for short. Yeah, and that's where our story starts. My name is Janis Kirschner, I'm a Swiss cybersecurity researcher and CTF player. Together with my research team, ZEDUAT0, we analyzed the Swiss e-voting source code. Obviously, my views are my own, not my employers, grandmas or dogs. So, a little bit of background information. Why should we vote digitally in the first place? So one of the main arguments was that it's comfortable for expats, for people living abroad, because for them, voting used to be quite a hassle. They have to send the votes per mail, and sometimes the mail gets lost or arrived too late, so that's one of the main reasons. Also it should attract young voters, and it should make voting more accessible to the public. However, with the e-voting also comes with major downsides. Security risks are on scale. You don't have to bribe a few thousand people, you have to find the right exploit, and maybe you can even do it in the comfort of your home and home. Also, it's very expensive to maintain, and the systems must be trusted, and it's hard to create that trust, because how do you make sure that the software running on these voting machines is actually the software that has been released or tested? The first thing that comes to mind is a checksum. I mean, checksums are great, right? But how do you make sure the checksum program is right and not just the static string? So that's one of the major problems. I often hear a comparison between electronic voting and electronic banking. However, I think there are major differences, and in my opinion it's easier to protect electronic banking, because there you have transactions between two parties that can easily be identified and corrected in electronic voting. You have to guarantee absolute anonymity for the voter, which makes it pretty hard. There are two components, there is the universal verifiability and the individual verifiability that are supposed to make you validate your votes mathematically. These are some core components of electronic voting. So yeah, the process is if you vote offline, you usually have your vote, and you put it in a ballot box, and then you have a lot of people that count the votes. You have election helpers, you have election observers, et cetera. But if you vote online, you just send your request to the server, and afterwards you get a checksum back. And that checksum is for your individual verifiability that you can prove mathematically that your vote has been counted correctly. On the other side, for the government, they get the universal verifiability where they can check if all votes have been counted correctly, mathematically. So fast forward a bit. Electronic voting is nothing new, per se. Many canons already had electronic voting solutions in place, for example Basel or Geneva. However, the new parties that the government wanted to use electronic voting as an official channel, as an official voting channel all over Switzerland. So there were some problems. Geneva had to stop their e-voting program completely, and Basel is on the verge of it, because electronic voting is extremely expensive. There were some studies that said for every effective user that used electronic voting, over 10 years, the canton of Basel would have to pay around 4,000 Swiss francs, which is honestly quite a lot. And Geneva is an interesting example, because it developed its own electronic voting solution that has been used by some of the canton in Switzerland. So source code publication. It was pretty interesting when we could get our hands on this very special code, this very important code. And so it started to the great news. We went to the website, we wanted to download it, and we were greeted with a non-disclosing agreement. This struck me as odd, because I thought the code was supposed to be open source. However, the Swiss Post introduced open code, which is basically, releases a snapshot of the code under an NDA. So the code is public, but it's not really open source, not at all. So yeah. Nevertheless, we signed up for it, because we wanted to test the code. And the first thing we noticed is how big the code actually was. Like it was around a quarter million lines of code. It was really big. And it featured a microservice architecture of several components that talk with each other. It was really, really a big solution. And another thing that was really, really big was the dependencies. They had a lot of dependencies. Like really a lot. And history has shown that dependencies can be really dangerous. One example that I like to come up with is EventStream early 2018, where a developer got tired of maintaining his nice little project and transferred ownership to someone who offered help. However, the person was a malicious actor. And yeah, now a few thousand programs featured malware in it. And also in the eVoting code, we found some dependencies that were party libraries that were vulnerable to several exploits. However, the functions weren't exactly used. So the risk wasn't that big. But the fact that these libraries were present shows that, yeah, it's a real threat and that patch management is hard. So where do you start when you got such a big software? The first point would be documentation. You look at how does it work, what's the threat model, just look how it works. So in the Geneva system, they had a lot of documentation. They had like threat models for every component. But in the new Swiss Post system, there were only three high-level documents. Some about the cryptography, a little bit high-level voting workflow, a little bit lower level. It wasn't that useful. It also featured some API descriptions, but most of them were internal and weren't of much use. But there was something interesting. There were security audits before the public intrusion test. And these are great because you can see maybe there were invalid patches or just see what are the core parts that are interesting to look at. So we went to the Swiss Post website, we downloaded it, and the file sizes seemed oddly small. Now when you open these PDFs, they only seem to contain the covers in the table of contents. Honest mistake, of course, everybody published the wrong thing. But after some further investigation, it showed that this was on purpose to protect the IP law of the company that audited it. And they didn't want to give out those reports, which was kind of a bummer. So okay, we had to work without any documentation. So next thing you usually do is, yeah, set up the system and check a bit how does it work, how does it interact, how play with it, however you couldn't build the system. The system wasn't buildable at all. The system wasn't meant to be built. The system relied on an internal build server at the development company in Spain. And you were only supposed to access the system during the official public intrusion test where they provided you with test instance. So even with some public effort to reconstruct the source code, by several parties, it didn't work out. It was just a too limited time frame. And yeah, the system was too big. So all that was left was static analysis over the whole thing. So during our research, the media blew up a bit about the news of some e-voting leak. This is odd, I thought, because the system was released, right, where there's some components they were hiding or something. No, it turns out some people took the source code and uploaded it to their own GitHub repository. So others could evade the non-disclosement agreements. And obviously, there were DMCA claims filed against it. And so this news could have been avoided if they would have open sourced the solution. So this function is really interesting. How does it make you feel? How does it make you feel with user inputs? How does it make you feel with user input that's not validated? Yeah, you know what I want to imply here. The component called a secure data manager didn't seem as secure at all. However, the post assured us that it's actually very secure because the cantons that run this component would use some air gaps. And air gaps have proven to be very effective over time, right? So yeah, very secure and out of scope. But they were happy to tell us that they would sign patch it. So it's all great. So this was around the time when the actual public intrusion test started. And you were provided with two URLs that you could test. It was the voting workflow and the administration workflow. Well, you could only test the voting workflow. The administration workflow required some certificate based authentication. And however, they didn't provide these certificates. They didn't provide them on purpose because it wouldn't be realistic to provide them, right? So you couldn't test the admin interface at all, maybe through post exploitation. So all that was left was the voting workflow, which brings us to the pit scope. To illustrate it, we started out with around a quarter million lines of code, right? We put it through a public intrusion test and we get this. This isn't cut off. These are nine rest end points. That was the pit scope. Yeah, nine rest end points, which were very interesting. We looked at them. Surely they must be very secure. I mean, security must be tight there. But even with that scope, we still found some stuff. Turns out they used the X4Water4 headers, which transmit your IP address. You can change them client side. And they relied on these headers for the internal Splunk logs. So you could just move some arbitrary IP addresses into their logs, into their internal logs. This one was also accepted as one of the few vulnerabilities of the system, which is really interesting even with the narrow scope. And do you remember the universal verifiability from the beginning? Yeah, apparently it's been broken as well. Some researchers found that apparently if you had access to the system and if you could change the votes theoretically onto some circumstances, you could also do it undetectable. And so much for the e-voting solution. Apparently they weren't allowed to continue with it anymore. What holds the future? Currently, there were discussions about an e-voting moratorium in Switzerland where they wanted to hold all e-voting projects for five years. And I've also seen developments made by big corporations, Microsoft recently released an e-voting library written in plain C. Must be interesting to look at. And yeah, it still features a lot of interesting research area. So in conclusion, e-voting is interesting, but with great power comes great responsibility. And if you want to develop an e-voting system, please put sufficient care into it. Thank you. Is there any questions? If yes, go to the microphones to the left or the right. All of its weekly bhg program requests. Yeah, to the left. Did you have a chance to take a look at the source code from the Geneva solution as well? Or only the post? Swiss Post System, I didn't audit Geneva system. However, I looked at it from just from the perspective. Geneva did a lot of things right there. They open sourced it properly, they provided lots of documentation, and it just seemed a little bit more fitting. So I just looked at it from a program perspective. They made it easier for researchers. They had also a buildable system, they provided docker containers. So that's for the Geneva system. But I can't make any assumptions from a co-perspective. On the right. So thanks for the talk. Do you know why you couldn't build the source code? Was it a part of source code missing or something like that? So basically the source code relied on an internal build server at Skytel. So if you wanted to build it, you would need to have all the correct components, right? And you would basically need to reconstruct the build process for you. So since they didn't provide that, it would have been very, very complicated. And some people tried exactly that to figure out which components were used and write your own build scripts. But the problem was that there wasn't enough time to do that. Okay. To the left. Hello. If there were no vulnerability with this universal verifiability, wouldn't Switzerland have online voting? And can you tell me a bit more about this universal verifiability, vulnerability, what access to the system should the operator have to use it? So basically you're saying that what are the effects of the universal verifiability vulnerabilities? If this problem wouldn't have appeared, then Switzerland would have had online voting for the elections in October, right? Quite possibly. Quite possibly. I mean, there were other problems, like especially the one with the source code that wasn't open sourced in some parts were missing and you couldn't build it. Usually the text from the government said that you should be able to build it. Maybe this would have caused problems, but it was certainly an important factor that it can be built. Yeah, that it can be employed. Yeah, then a big thanks and a big applause. Thank you.
So, the Swiss democracy is one of its kind. No digitized, it's only a natural conclusion that this year, the Swiss Post released their e-voting source code as part of a mandatory public intrusion test, or PIT for short. Yeah, and electronic voting. You have to guarantee absolute used by some of the canton in Switzerland. So interesting when we could get our hands on this supposed to be open source. However, the Swiss interesting. There were security audits before during the official public intrusion test where And so much for the e-voting solution. Apparently a look at the source code from the Geneva