Looking for an easy way to find out when the garbage was being picked up ended up in discovering a data leak affecting half a million people.
|Published:||Mon, September 3, 2018, 23:40|
Social Security numbers
OWASP 2013 A2
OWASP 2013 A3
OWASP 2013 A6
OWASP 2013 A10
|Written by:||Hallvard Nygård & Roy Solberg|
An app that was supposed to contain only addresses and a garbage collection calendar was actually using services that was leaking personal information like names and Social Security numbers for many, many persons.
|Who:||Norconsult Informasjonssystemer (Nois)|
|Severity level:||Low to medium|
|Reception and handling:||Response time good, but slow on fixing. Notification to clients was faulty.|
|Reward:||A thank you|
|Issue:||Information leak with personal data and usage data for up to 625,000 people. Data also contained waste disposal routes, sewage monitoring, and more. Likely that modification of some data was possible.|
A friend came up with an idea of having an Alexa skill/Google Assistant app where one could ask for "when will the paper garbage be picked up"? He saw that the website for BIR - our local waste management company - did not provide an easy way to fetch that data. He said there also was an app with the same data. Taking a look at the communication between the app and the server it quickly became clear that something was very wrong in regards of security.
Using the HTTP proxy application Charles it was easy to look at the traffic between the app and server. Surprisingly the app and server actually used SOAP for communication. SOAP is pretty painful to work with and not commonly observed in the world of apps (though it was used for the case with Tryg and Infotorg).
All the SOAP calls used the same simple username and password and all data was transferred unencrypted over HTTP.
Surprisingly, doing a search for a street name actually returned a list of properties including the full name of the owner.
Then, when selecting a property in the app there was a call getting more details about it. Even though the app did not show the data, the server response returned full name, address and Social Security number of the property owner.
|SOAP and related concepts|
|SOAP is a XML based messaging protocol. It can be used over HTTP, as in this case, or other protocols like JMS and SMTP. A SOAP server contains a lot over SOAP services. These are described in a WSDL file. With the WSDL (and corresponding XSDs) one can generate strongly typed classes for all endpoints that are easy to use. The WSDL/XSD files can contain comments that describe the parameters and possible values. This was not the case here. Using SoapUI or similar tool, one can easily execute different parameters for each service. SoapUI is like Swagger or Postman for REST.|
Using the username and password that was found in the app, we could do queries to the SOAP service. As we did not know the input values, some services was hard to use.
Nois has published quite a few apps, and one of the calls that the app made was one to get the configuration of these apps. Looking at the root of this URL revealed a public facing status page with URLs to many of Nois' web services. This page was even indexed by Google. The URLs gave out WSDL files for all services available.
Based on the copyright statements on the page and source code it looked like the system overview page was last maintained in 2012.
After dedusting SoapUI, we explored some of the "
GetXYZ" services. We were able to get successful response on a subset of the once we tried. Main reason for failed requests was lack of examples of the input parameters. We did not try any write operations.
GetMunicipalities) - Envina
GetWaterGaugePoints- Sandnes kommune
SearchPropertiesWithPrincipalsAndZipCodes- BIR AS
Based on the list of SOAP services available, we figure the following data is available within the systems (given that they use that part of the system):
We created a list of servers we found on the system overview page. We also manage to find some using search engine (Googling for phrases from the application). From the overview page we identified some of the owners and it was also clear that some servers were offline.
To exclude those that were not affected by this huge security flaw, we verified each and every server. Mainly two SOAP services were called, one that returned all municipalities on that server and one with the latest changes in customer data. The service with customer data revealed that our user (
nois/nois) had access to customer data on that particular server AND that the server was currently being used (somebody edited some customer in the past week/month or so).
The servers were verified manually using SoapUI and we took screenshots as proof. The screenshots were edited to censor any personal data (we don't want to have that saved).
A few servers on the overview page did not work even if they showed status “green". One example of this is Gjesdal kommune. According to the overview page, the service was running but we could not reach it. This could be that they had firewalls that blocked our HTTP requests.
The owners were either a municipality or a cooperation of municipalities (Norwegian: IKS - interkommunalt selskap).
|Municipality / company||Municipalities||Inhabitants||Screenshot|
|Avfall Sør AS||Kristiansand, Songdalen, Søgne, Vennesla||120,403 Customer estimate: 45-65,000|
|Remiks||Tromsø, Karlsøy||76,814 Customer estimate: 30-40,000|
|Regiondata||Dovre, Lesja, Sel, Vågå||14,820 Customer estimate: 5-8,000|
|Haugaland Interkommunale Miljøverk (HIM)||Haugesund, Bokn, Tysvær, Vindafjord, Etne||62,026 Customers: 33,052|
||4,524 Customer estimate: 2,000|
|Retura Val-Hall AS / Hallingdal renovasjon / Valdres Kommunale renovasjon||Hol, Ål, Gol, Hemsedal, Nesbyen, Flå, Krødsherad, Nord-Aurdal, Sør-Aurdal, Øystre Slidre, Vestre Slidre, Etnedal, Vang
||40,915 Customer estimate: 15-22,000|
|BIR AS||Askøy, Bergen, Fusa, Kvam, Os, Osterøy, Samnanger, Sund, Vaksdal||359,364 Customer estimate: 140-190,000|
|Innherred Renovasjon||Selbu, Malvik, Meråker, Stjørdal, Frosta, Levanger, Verdal, Inderøy, Leksvik
||92,563 Customers: 35,671|
|Hamos Forvaltning IKS||Hemne, Agdenes, Meldal, Orkdal, Snillfjord, Skaun, Rindal, Hitra, Frøya, Rennebu, Surnadal||50,967 Customer estimate: 20-27,000|
|Stavanger kommune (own server)||Stavanger
||132,729 Customer estimate: 50-70,000|
|Sandnes kommune (own server)||Sandnes||76,328 Customer estimate: 30-40,000|
|Nordfjord Miljøverk IKS (NoMil)||Bremanger, Vågsøy, Selje, Eid, Hornindal, Gloppen, Stryn||32,932 Customer estimate: 12-18,000|
|Envina IKS||Klæbu, Melhus, Midtre Gauldal
||28,582 Customer estimate: 10-15,000|
|Movar (Mosseregionen Vann, Avløp og Renovasjon)||Moss, Rygge, Råde, Vestby, Våler||76,391 Customer estimate: 30-40,000|
It was hard to find good numbers of the amount of customers that are in the databases of the different municipalities. Innherred Renovasjon and Haugaland Interkommunale Miljøverk did have numbers on customers (Innherred)/waste disposal customers (HIM). They were respectively 2.6 inhabitants per customer and 1.87 inhabitant per customer. Based on those numbers we estimate 450,000 to 625,000 private persons possibly exposed with full name, address, Social Security number, contact information, etc.
Some ZIP codes from a
GetEiendom request to the server
This is not a complete list. We manually picked out some from the response in SoapUI to get a feeling for the data set.
Municipalities listed, but with a different service exposed:
We did not have a username/password that worked for this service. It doesn't seem wise to have these on the Internet. They should all add a firewall blocking access.
Municipalities listed, where our requests did not work:
We believe we shouldn't have been able to reach the servers of these municipalities. It doesn't seem wise to have these on the Internet. They probably should all add a firewall blocking access.
Municipalities listed where firewall blocked our request:
We consider all these secure.
Sunday night we sent an e-mail to the director of Nois and the head of department of the department responsible for the software in question.
A few hours later we got a pretty cold "We confirm that the e-mail has been received." back.
Just before midnight we sent an e-mail with some questions and information about another 7 municipalities affected by the issue.
Not having heard back we sent a new e-mail asking for a status.
We soon got a response telling that they had established a working group for the issue. They had fixed a couple of the issues and they had informed the The Norwegian Data Protection Authority (Datatilsynet) and the municipalities in question.
We used the freedom of information law to get a hold of the alerts and communication with the municipalities. The alert was a letter sent on day 5.
In addition to general information, this is was what the letter told:
"It has been discovered that it is technically possible for 3rd party to extract information from this service if you have the deep technical insight required. It is important to emphasize that this has not happened, but that we have implemented preventive measures."
They also said a new version would be rolled out during the next days.
We saw that the issue still was open for many of the municipalities and asked for an ETA of a fix.
Tuesday morning Nois said they expected everything to be OK by the end of the week.
Friday night we asked if really was the case that everything was fixed.
We got a reply that they would work through the weekend to get it fixed.
We informed that not everything was fixed yet. We sent an example query that returned a list of 1208 customers that had changed the last couple of months. The details returned from server included full name, social security number, property identifier and lots of other fields.
Nois told they were working on getting access to the necessary serves to fix it.
In the afternoon we got another response telling us that everything should be OK and they thanked us for informing them about it.
We replied that we still were getting personal data from one of their services.
They looked into the issue and they thought it could have been a service being restarted by an automatic scheduled job...
We got another e-mail telling us that they had even more services automatically restarting during the night.
We noticed that a service was back up running, and it returned information about more than 6,000 persons.
The day after, a Sunday, we got a response that they would contact the customer the day after to make sure it was fixed.
We got another response that the service in question now was removed.
We reported the incident to The Norwegian Data Protection Authority (DPA). After Nois gave their version of it, the DPA closed the case and said they were satisfied by the countermeasures implemented by Nois. We believe the report sent from Nois to the DPA to be inaccurate.
Nois claimed that it was not possible to get lists (supposedly one would have to ask for one at the time) of Social Security numbers or of properties that had not made their payments. Several services returned lists of SSN/customers/properties. (Property addresses are anyways public knowledge and one could easily just as for each property, one by one.)
Nois claimed that the issue was caused by a "technical failure". Not using encryption on any of their services, using both username and password "
nois" and returning Social Security numbers when asking for which days the garbage is picked up is not a technical failure. The cause is ignorance by developers and lack of knowledge by any managers above them. Quite a few people must have been aware of this.
Nois claimed that the "deviation" was open from January 31st 2018 until April 16th 2018. The issue was not closed until the later part of June 2018 and start of August 2018 - and not at all when the report to the DPA was sent. While we discovered this mid April, Nois published BIR's "garbage collection calendar" app in August 2017. Looking at that exact version of the app reveals that the same services without encryption, with the same login and the fields for Social Security numbers, names and addresses were being used. Looking at Innherred Renovasjon's app we found the same to be true in a version released in October 2015. We don't understand why they would specify January 31st 2018 as the start date. If they will want to claim this, they should provide some evidence for the date being January 31st.
Nois claims that no personal information was leaked when looking at the logs. This claim is a bit hard to understand as Nois did not have operational responsibility of many of the servers and they have had a hard time getting access to the servers to do updates. At the time of the report they had not closed the issue on all servers. Also, as mentioned, the issue was seemingly open for much longer than they claim. And finally, the services were indeed leaking personal information for every request being made. It's impossible to know if a request came from the "garbage collection calendar" apps or from someone faking it and looking up a person's Social Security number. And for how long do they have logs for?
During the period from we notified the vendor to the time it was fixed, we monitored the servers from time to time using a small script. The monitoring was done by calling one of the SOAP services. We choose the
GetKommune) as this did not contain the personal information, required authentication and returned some data.
The smilies and colors below indicate if the service responded or not. There are two versions of this data set, one with just the days we tested and one with empty cells for days we did not test.
We sent this security issue out to the local media since there was 14 different corporations/municipalities involved. The main take away from it is that information security is higher on the agenda for a lot of these. We also got to know that the corporations (customers of Nois) did not view this as a security issue/breach of personal data. Norwegian headlines translated below.
digi.no wrote a summary on a national level: "Renovation companies in many Norwegian municipalities leak personal data"
No media reported on these:
What is clear is that the municipality is responsible for the protection of the personal data they have. They are responsible for their database. It seems like Nois have full access to the system for upgrades and checking logs. We still wonder about who is responsible for the running of the systems. Who is responsible for not changing default configuration (default username and password with full access)? Who is responsible for not configuring the firewalls? Who is responsible for building apps on top of SOAP and using a user with full access for the communications?
After the media asked the municipalities responsible for the personal data and after we got to see the letter from Nois notifying their customer about the security issue, most of them did not react to this as a system leaking information. Why did Nois send such a vague letter to the customers and DPA (Datatilsynet)?
Nois claimed they checked the logs and that no data was actually leaked. They also claim the security issue was just present for 4 months. How was the access logs checked? Did they check back in time to at least 2015? Where is the report to their customers about this?
Who checks the security of an app that doesn't contain a login or any personal data at all? No one, because it just doesn't make sense to do that. It was just a coincidence that we discovered this one.
What sticks out in the end for us is that the reception and handling of the issue wasn't very good. Usually IT companies responds more quickly and are more open about the issue and handling of it. Here the customers got a vague description not telling much about what was going on.
It would be interesting to know if anyone really digged into how long the data was available for, because it seems like they have been there for quite a few years.
Finally, if you as a developer are told to use a service that returns much more data than what's intended to be used, you should speak up. Quite a few people have known about these personal data being transferred unencrypted over the wire.