This is Data Insecurity, a blog series about all the ways organizations fail to keep data secure online.
I recently bought a condo that is governed by a Home Owners’ Association (HOA).
The HOA has contracted with a property management company (PMC) to handle community affairs, maintenance, and finances. This PMC distributes information to homeowners via email and via their web portal, which is owned and operated by a web platform provider. Each homeowner has an account on the portal where they can see community announcements, bulletins, and shared documents. Each PMC has a separate subdomain on the provider web portal; if I live in an HOA managed by First Street Management (abbreviated “FSM”), I might access the portal via the URL fsm.webplatform.com. Other users would similarly access the portal at URLs that use their HOA name or abbreviation as the subdomain.
Subdomains are a common way service providers allow access to user content because subdomains allow customers to create personalized online spaces, enhancing branding, organization, and security while allowing clients to have unique, customized experiences within the provider’s ecosystem. Subdomains can also run on different servers so the website’s main webserver is not responding to every request for all customers.
Providing each homeowner with a username and password is a great security measure for delivering information, as long as the website ensures that only authenticated users can access certain information. After logging into the website.
What information do we expect to be private?
Homeowners expect their property management company to keep sensitive information private from unauthenticated users on the internet. This includes personal details like addresses, contact information, and financial records. Protection of payment transactions, maintenance schedules, and access codes is crucial. Homeowners also anticipate the secure handling of community data, such as meeting minutes and shared documents. Privacy measures like encrypted communication, secure portals, and robust authentication systems are essential to ensure that unauthorized individuals cannot access, misuse, or exploit sensitive homeowner information, fostering trust in the property management company’s commitment to confidentiality and security.
What information is secure?
The web portal organizes information in to “Account Information” and “Community Information”. Account information contains individual user account balances, charges, and violations; community information contains a directory of residents (names, addresses, phone numbers, and emails), documents, and a shared calendar.
User account information is secure because the website uses the ASP.NET_SessionId cookie. This cookie does not directly secure websites but it does manage user sessions by assigning a random unique identifier as a cookie each time the user accesses the website. This identifier is sent back and forth between the user’s browser and the server, helping the server associate requests with a specific session. By keeping session data on the server and only sending a session identifier to the client, the risk of exposing sensitive information in the client’s browser is minimized. As long as the website requires the user to send the cookie with each request to receive certain information, then using this cookie is a strong safety measure.
I am unable to access the violations and account settings for other users because I do not know their username and password, nor can I guess the session ID cookie for other live sessions without directly attacking the website’s users with man in the middle attacks.
What information is insecure?
Community information is not well-secured. This side of the web portal does not use session cookies to access information, instead relying on payload parameters in a POST request to retrieve information.
For example, you can access the resident directory at the URL: https://fsm.webplatform.com/[ID]/directory/, where the ID is a numeric value assigned to your condo complex. You would think that the ID would limit you do only seeing directory information for people living in your community; however, this ID does not actually control the information that is shown to the user. Instead, the payload body contains a key called numDirID which determines which condo complex information is returned. This key takes integers as values, all in the lower ballpark of under 1000. This means there is a limited number of possible values for numDirID and we can easily iterate through them to retrieve all available information.
The web portal uses the condo complex name in the URL subdomain (msc) and numDirID to retrieve information. We can use a subdomain sniffer to identify subdomains and we can iterate through numeric values for numDirID.
Community documents are also not secured. The web portal assigns URLs to each document using an auto-incrementing system; the first document for a given HOA is given the URL https://fsm.webplatform.com/account/d/1, the second is /2, etc. I can iterate through increasing numbers until I reach a series of consecutive numbers that don’t exist, which would indicate that I have found the most recent document and there are no more to collect. With document access controlled by the HOA subdomain and the number in the URL extension, we can identify documents for other HOAs by simplying changing the subdomain and iterating through increasing numbers.
I have identified and could easily download thousands of documents in this manner, including policy documents, meeting minutes, annual financials, among others.
How might this have happened?
Developers frequently secure databases and file storage separately to enhance overall system security. Databases store structured data, often sensitive information like user credentials, financial records, or personal details. Securing databases involves measures like encryption, access controls, and authentication to prevent unauthorized access and data breaches.
On the other hand, file storage may contain various types of files, including media, documents, or configuration files. Securing file storage necessitates different considerations, such as ensuring proper access controls, encrypting sensitive files, and protecting against unauthorized modifications or deletions.
In this case, the web portal developers clearly chose to manage the database and file storage separately, and they also manage the user and community data separately. They rightly secured the user data using the ASPNET session cookie. They potentially use row-level security so that only the user associated with each record can access their own information. When I log in with my username and password, the web portal’s server creates a temporary ASPNET session cookie that it sends back to my computer. My computer sends the cookie to the server with every data request; the web server will verify that the cookie is valid and also ensure that the user associated with the cookie has permissions to access the requested data.
When it comes to community information, each record is associated with the HOA community but not a specific user. Row-level security is more complicated here because the web server would need to determine the community that a user is affiliated with and then verify that that community has permissions to access the requested community information. This can be done with many web frameworks, but it can be considered redundant if you already require users to log in and that is the primary means of user access. Web developers do not build primarily with web scrapers in mind; they build for their intended audience, users who will only access the web portal via their web browser. They use authentication to manage user authentication and assume that any data requests that the web portal does behind authentication will only be done in a secure manner. This assumption falls apart once someone inspects the network traffic. You only need access to one HOA portal to gain access to every document and every resident directory that this company has.
Who else might be affected?
There are many free subdomain finders (also known as enumerators) available on the internet. If you wanted a comprehensive search, you would either pay for it or use an open-source intelligence tool to find the subdomains yourself. For this quick analysis, I used the SE Ranking subdomain finder to quickly identify a dozen popular subdomains. I like this one because it also includes traffic analytics about which subdomains are more popular. Theses analytics indicate to me which customers would be most impacted by data insecurity on this platform.
This scan found 350 subdomains. I could also just google the URL and I found links to dozens of their customer websites. After compiling the subdomains for these customers, I had all the information needed to scrape resident contact information and community documents.
How could they secure this information?
To secure the resident directory, The developers might consider using organization-level authentication to ensure that users can only access the directory for their own community. They already know which HOA each user is affiliated with. The missing connection is to verify that the user cannot request information about users belonging to another HOA.
Securing their documents is more complicated. Currently, anyone can access any document at any time if they know the URL and the URL is predictable because they do not use random unique document identifiers. The easiest solution would be to switch to a random unique document identifier in the URL so it could not be easily inferred. Similar to the random session cookie they use for user data, this change would practically eliminate unauthorized document access because guessing random identifiers is a time-consuming operation. If they did not want to switch the URLs, they could assign use temporary document access credentials to authenticated users and verify them on the server before returning documents from file storage.