Paul Hempshall

Website Cyber Security Professional

Predictable from Observable State

Published: September 6, 2022 9:52 pm

Analysis Application Security

In this post, I will describe a couple of real-life examples of where the predictability of visible information can lead to problems such as information disclosure and unintended authentication bypass.

The first step in analysing a system is the reconnaissance phase. When inspecting a website, we can look at the source code, frontend configuration files and HTTP headers. With this information, we can build up an idea of naming conventions for application functions, variables and parameters, filenames, and directory structures.

Predicting file name and directory structure

Scenario: An independent record label and music store allowed streaming of embedded 30-second sample clips within their website.

Redacted image of music store website showing embedded music player.
Embedded audio player was located where the broken flash player sits.

Upon inspecting the HTML source code, we can see the configuration playlist URL for the embedded audio player. 

<object width="428" height="204" id="mp3player" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0">
  <param name="movie" value="http://www.[redacted].com/mp3player.swf?config=http://www.[redacted].com/config_features.xml&file=http://www.[redacted].com/mp3/example_album_name/samples/playlist.xml"/>
  <param name="wmode" value="transparent"/>
  <embed src="http://www.[redacted].com/mp3player.swf?config=http://www.[redacted].com/config_features.xml&file=http://www.[redacted].com/mp3/example_album_name/samples/playlist.xml" wmode="transparent" width="428" height="204" name="mp3player" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer"/>
</object>

Within the playlist file are the track's metadata and source location URL. 

<playlist version="1" xmlns="http://xspf.org/ns/0/">
  <title>Example Album Name</title>
  <info>http://www.[redacted].com</info>
  <tracklist>
    <track>
    <annotation>Artist Name - Track Name</annotation>
    <location>http://www.[redacted].com/mp3/example_album_name/samples/02_Artist_Name_-_Track_Name_sample.mp3</location>
    <info>http://www.[redacted].com</info>
    </track>
    ...
  </tracklist>
</playlist>

If we look at the location within the playlist, there are a few things that stand out. The directory /samples/ and the filename ending _sample.

http://www.[redacted].com/mp3/example_album_name/samples/02_Artist_Name_-_Track_Name_sample.mp3

Removing these two naming conventions from the URL would yield the full track.

http://www.[redacted].com/mp3/example_album_name/02_Artist_Name_-_Track_Name.mp3

An attacker could create a list of full tracks using the information available in the sample playlist files. The attacker could then download the entire catalogue of music.

This example was circa 2011.

A symptom of a bigger problem

I've seen other situations similar to the above, such as e-commerce websites manually uploading images of discount coupons with predictable filenames, allowing you to bypass the usual steps required to obtain them. Sometimes even finding them before their release date, pre-uploaded. Imagine a competitor knowing your upcoming offers in advance.

Other examples highlight flaws in the design and development process. For example, when mixing application logic with the view to determine what features appear on the frontend. The function exists, but as far as the user is concerned, it does not exist, as there are no frontend features. However, by looking at the naming convention for the rest of the known functions, we can then start to predict other function names. With this predictability, an attacker can reduce their guesswork, using your structure against you, and access private features not intended for that account type.

Imagine a scenario where the application allows you to upload documents but does not allow you to delete them without moderator approval. The same application will allow you to upload pictures and also allows you to delete them. You inspect the application and find these API URLs.

  • /api/files/documents/upload
  • /api/files/images/upload
  • /api/files/images/delete

Can we predict the delete documents function? Yes. Should we be able to access it even if we could predict it? No.

These examples of predicting from observable states are symptoms of a much greater security concern, broken authentication or privilege escalation.

When scoping your security tests, include all available, not just observable, public endpoints. Conduct tests against each user access level, public to admin, ensuring compliance with your security control policies and intended access privileges.