Google Cloud functions fail when possible subdomain length too long.

[0x646e78]

I have a domain I'm trying to cloud_enum. Let's say this is "preprod-second-hand-elastic-standalone-abcdefghi-abcdefgh.REDCTcloud.com"

This is an acceptable length for a subdomain, and it does resolve. But, adding the fuzz to it makes it too long, and thus fails.

Perhaps a length check on subdomain + fuzz strings before attempting the check? If any component is too long, then skip as there's no way it'd be a positive result?

[+] Checking for project/zones with Google Cloud Functions.
[*] Testing across 1 regions defined in the config file
Traceback (most recent call last):
  File "/home/dnx/3rdparty/cloud_enum/cloud_enum.py", line 255, in <module>
    main()
  File "/home/dnx/3rdparty/cloud_enum/cloud_enum.py", line 244, in main
    gcp_checks.run_all(names, args)
  File "/home/dnx/3rdparty/cloud_enum/enum_tools/gcp_checks.py", line 390, in run_all
    check_functions(names, args.brute, args.quickscan, args.threads)
  File "/home/dnx/3rdparty/cloud_enum/enum_tools/gcp_checks.py", line 338, in check_functions
    utils.get_url_batch(candidates, use_ssl=False,
  File "/home/dnx/3rdparty/cloud_enum/enum_tools/utils.py", line 88, in get_url_batch
    batch_results[url] = batch_pending[url].result(timeout=30)
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/concurrent/futures/_base.py", line 449, in result
    return self.__get_result()
           ^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/concurrent/futures/_base.py", line 401, in __get_result
    raise self._exception
  File "/usr/lib64/python3.11/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/dnx/venv/lib64/python3.11/site-packages/requests/sessions.py", line 589, in request
    resp = self.send(prep, **send_kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/dnx/venv/lib64/python3.11/site-packages/requests/sessions.py", line 703, in send
    r = adapter.send(request, **kwargs)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/dnx/venv/lib64/python3.11/site-packages/requests/adapters.py", line 486, in send
    resp = conn.urlopen(
           ^^^^^^^^^^^^^
  File "/home/dnx/venv/lib64/python3.11/site-packages/urllib3/connectionpool.py", line 790, in urlopen
    response = self._make_request(
               ^^^^^^^^^^^^^^^^^^^
  File "/home/dnx/venv/lib64/python3.11/site-packages/urllib3/connectionpool.py", line 496, in _make_request
    conn.request(
  File "/home/dnx/venv/lib64/python3.11/site-packages/urllib3/connection.py", line 395, in request
    self.endheaders()
  File "/usr/lib64/python3.11/http/client.py", line 1281, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib64/python3.11/http/client.py", line 1041, in _send_output
    self.send(msg)
  File "/usr/lib64/python3.11/http/client.py", line 979, in send
    self.connect()
  File "/home/dnx/venv/lib64/python3.11/site-packages/urllib3/connection.py", line 243, in connect
    self.sock = self._new_conn()
                ^^^^^^^^^^^^^^^^
  File "/home/dnx/venv/lib64/python3.11/site-packages/urllib3/connection.py", line 203, in _new_conn
    sock = connection.create_connection(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/dnx/venv/lib64/python3.11/site-packages/urllib3/util/connection.py", line 58, in create_connection
    raise LocationParseError(f"'{host}', label empty or too long") from None
urllib3.exceptions.LocationParseError: Failed to parse: 'us-central1-preprod-second-hand-elastic-standalone-abcdefghi-abcdefgh.REDCTcloud.com.cloudfunctions.net', label empty or too long

[initstring]

Hi @0x646e78 - nice find!

I believe each "DNS label" can be up to 63 characters in length. Then, there is a total limit of 253-255 depending on how it is processed.

I think if we limit the custom payload to 63, we will never hit the total limit as all the cloud provider strings are short enough.

So, I think the easiest way to fix this is to drop long strings during the mutation stage. I've given this a shot in this PR. If you pull this branch, does it fix your problem?

[0x646e78]

Ah I totally forgot to PR my quick fix yesterday... just opened #63

Your PR still causes the crash for me, as the check needs to be upon mutation. There is also a total length of domains apparently. You can choose to take the idea and adjust your PR accordingly if you like.

[initstring]

Thanks @0x646e78 - I pushed a new commit that hooks into the utility functions. There is now some overlapping protections, but I think it's ok to leave them all.

Does this branch work ok for you now?

[0x646e78]

Yes, that works :D