Starting point - Oopsie Can't access simple http website.

So I’m pretty new to htb, I’ve completed Archetype( The previous challenge) in the starting point batch.

I’ve enumerated the machine with nmap and discovered 2 ports as followed:

PORT   STATE SERVICE   VERSION
22/tcp open  ssh       OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 61:e4:3f:d4:1e:e2:b2:f1:0d:3c:ed:36:28:36:67:c7 (RSA)
|   256 24:1d:a4:17:d4:e3:2a:9c:90:5c:30:58:8f:60:77:8d (ECDSA)
|_  256 78:03:0e:b4:a1:af:e5:c2:f9:8d:29:05:3e:29:c9:f2 (ED25519)
80/tcp open  ssl/http?
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Apache/2.4.29

Basically when I go to the website : http://10.10.10.28 it loads indefinitely . I was thinking the problem was just incorrect path in the url, but I can’t seem to enumerate anything because there is no connection :

Error: error on running gobuster: unable to connect to http://10.10.10.28:80/: Get "http://10.10.10.28:80/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

as i mentioned, pings and nmap was working. ssh was working .
something interesting happned while accesing the ssh through port 80:

└─$ ssh -vvvv -p 80 10.10.10.28      
OpenSSH_8.4p1 Debian-3, OpenSSL 1.1.1i  8 Dec 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 10.10.10.28 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/kali/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/kali/.ssh/known_hosts2'
debug2: ssh_connect_direct
debug1: Connecting to 10.10.10.28 [10.10.10.28] port 80.
debug1: Connection established.
debug1: identity file /home/kali/.ssh/id_rsa type -1
debug1: identity file /home/kali/.ssh/id_rsa-cert type -1
debug1: identity file /home/kali/.ssh/id_dsa type -1
debug1: identity file /home/kali/.ssh/id_dsa-cert type -1
debug1: identity file /home/kali/.ssh/id_ecdsa type -1
debug1: identity file /home/kali/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/kali/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/kali/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/kali/.ssh/id_ed25519 type -1
debug1: identity file /home/kali/.ssh/id_ed25519-cert type -1
debug1: identity file /home/kali/.ssh/id_ed25519_sk type -1
debug1: identity file /home/kali/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/kali/.ssh/id_xmss type -1
debug1: identity file /home/kali/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Debian-3
debug1: kex_exchange_identification: banner line 0: HTTP/1.1 400 Bad Request
debug1: kex_exchange_identification: banner line 1: Date: Wed, 05 May 2021 14:52:48 GMT
debug1: kex_exchange_identification: banner line 2: Server: Apache/2.4.29 (Ubuntu)
debug1: kex_exchange_identification: banner line 3: Content-Length: 301
debug1: kex_exchange_identification: banner line 4: Connection: close
debug1: kex_exchange_identification: banner line 5: Content-Type: text/html; charset=iso-8859-1
debug1: kex_exchange_identification: banner line 6: 
debug1: kex_exchange_identification: banner line 7: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
debug1: kex_exchange_identification: banner line 8: <html><head>
debug1: kex_exchange_identification: banner line 9: <title>400 Bad Request</title>
debug1: kex_exchange_identification: banner line 10: </head><body>
debug1: kex_exchange_identification: banner line 11: <h1>Bad Request</h1>
debug1: kex_exchange_identification: banner line 12: <p>Your browser sent a request that this server could not understand.<br />
debug1: kex_exchange_identification: banner line 13: </p>
debug1: kex_exchange_identification: banner line 14: <hr>
debug1: kex_exchange_identification: banner line 15: <address>Apache/2.4.29 (Ubuntu) Server at 127.0.1.1 Port 80</address>
debug1: kex_exchange_identification: banner line 16: </body></html>
kex_exchange_identification: Connection closed by remote host
Connection closed by 10.10.10.28 port 80

So I know that there is an Apache running in there. I’ve tried accessing the website through Firefox as well as a fresh install of chromium.

I tried to continue, but the beginning of the next challenge write up suggested the challenges are incremental.

My thoughts are as follows: most probably the machine is malfunctioning ( Though I’ve tried resetting it a few times) or some other user is trying really hard to brute force something and it’s overloaded.

I really refuse to believe that the machine is trickier than that.
Thanks for the help :smiley:

Edit: It occurred to me that my vpn setting might be relevant. so I’ll share it here: EU Starting point VPN, EU Starting point #1, and I’ve tried both Connection TCP and UDP

It does look like something is broken. Looking at the walkthrough the webserver should be listening on port 80.

If you try an nmap scan of nmap -Pn -sC -sV -T4 --min-rate=1000 10.10.10.28 you will get a bit more information on the server.

It is clearly running Apache as the ssh output shows (and nmap should show), the nmap output you’ve shown here does look like something isn’t working properly. When you try to connect with a browser what messages do you get?

@TazWake said:

It does look like something is broken. Looking at the walkthrough the webserver should be listening on port 80.

If you try an nmap scan of nmap -Pn -sC -sV -T4 --min-rate=1000 10.10.10.28 you will get a bit more information on the server.

It is clearly running Apache as the ssh output shows (and nmap should show), the nmap output you’ve shown here does look like something isn’t working properly. When you try to connect with a browser what messages do you get?

when I enter the site It loads forever…

@umlal said:

when I enter the site It loads forever…

So there is no error, response or notice within the browser?

This could be an endpoint issue. When you connected to the port using a non-browser client, there was clearly a quick response (HTTP 400) so if the browser is failing to connect there might be some other issue at play. How long does it take before it times out? When it times out, what message does it say? (For example “Ambiguous redirect” is often a response here)

You can try using curl -v http://10.10.10.28 and see what the server response gives you.

If that works and browser still fails, it could be that you have a proxy set up from a previous attack (but then you should get a proxy error) or something else in the configuration is causing it.

Failing that, clear cookies in the browser or try incognito mode.

@TazWake Thank you so much for taking the time to suggest a solution, but I was not able to figure out what the problem is and how to fix the issue. I simply can’t access the web server I’ve also tested everything from a fresh latest Kali setup on Debian(KDE) but I still get the same frustrating result( reloads forever)…

doing the command you’ve suggested - curl (also from sudo) gives:

┌──(kali㉿kali)-[~]
└─$ curl -v http://10.10.10.28
*   Trying 10.10.10.28:80...
* Connected to 10.10.10.28 (10.10.10.28) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.10.10.28
> User-Agent: curl/7.74.0
> Accept: */*
> 

It looks like it’s running forever, same symptom as the browser. I have no proxy running, except the openvpn(Starting point) I mentioned above.

Clearing cookie and running incognito , both in chrome and Firefox doesn’t change the problem.

I’m trying everything I can to investigate this issue.

This is the request from firefox:

GET / undefined
Host: 10.10.10.28
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1

It’s worth mentioning that it just keeps on going and that there are no other requests or responses being made.

I have run this Python script as sudo and get the following response:

└─$ cat access-web.py                                                      130 ⨯
import requests
import logging
import http.client as http_client

http_client.HTTPConnection.debuglevel = 1

logging.basicConfig()
logging.getLogger().setLevel(logging.DEBUG)
requests_log = logging.getLogger("requests.packages.urllib3")
requests_log.setLevel(logging.DEBUG)
requests_log.propagate = True

requests.get('http://10.10.10.28')
┌──(kali㉿kali)-[~/Desktop/hack-the-box/Oopsie]
└─$ sudo python3 access-web.py                                             130 ⨯
[sudo] password for kali: 
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): 10.10.10.28:80
send: b'GET / HTTP/1.1\r\nHost: 10.10.10.28\r\nUser-Agent: python-requests/2.25.1\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\n\r\n'

my hosts file:

└─$ cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       kali

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

I really think that there is a problem with the Oopsie machine, but I’m not sure how to eliminate the option that it’s a fault in my machine.

@umlal said:

I really think that there is a problem with the Oopsie machine, but I’m not sure how to eliminate the option that it’s a fault in my machine.

Well, it’s difficult to be certain, but the curl output would be the main one for me. It seems strange that using ssh to connect resulted in a HTTP 400 request (meaning the server is functioning) but using curl is generating a timeout.

That does make me suspect the issue is with the server now. The likely cause is that something is breaking when it tries to process the index page. There isn’t much else you can check (*). It’s probably worth raising a Jira ticket with HTB if a reset isn’t working (or isn’t an option).

(*) - you can run tcpdump/wireshark and have a deeper analysis of the traffic to and from your machine. That might return something else of use but it’s unlikely to really add much knowledge.

@TazWake said:

@umlal said:

I really think that there is a problem with the Oopsie machine, but I’m not sure how to eliminate the option that it’s a fault in my machine.

Well, it’s difficult to be certain, but the curl output would be the main one for me. It seems strange that using ssh to connect resulted in a HTTP 400 request (meaning the server is functioning) but using curl is generating a timeout.

That does make me suspect the issue is with the server now. The likely cause is that something is breaking when it tries to process the index page. There isn’t much else you can check (*). It’s probably worth raising a Jira ticket with HTB if a reset isn’t working (or isn’t an option).

(*) - you can run tcpdump/wireshark and have a deeper analysis of the traffic to and from your machine. That might return something else of use but it’s unlikely to really add much knowledge.

OK, I won’t linger on it for long, tomorrow I’ll try to connect through campus( to eliminate an issue on my home internet), and I’ll test Wireshark before harassing some poor developer. if my internet isn’t the culprit i’ll try to buy a vip subscription to see if it solves the problem, if the problem persist then I’ll consider myself worthy of support.
What really bother me is that I can’t tell i it’s only happening to me or maybe other users are also having problems. Thanks anyway @TazWake

Just to update. the box worked perfectly on my mobile hotspot. so the issue is probably my home internet. I’ve yet to find a solution but i would update here if I’ll find a solution.

Try to set the VPN MTU Size to e.g. 1300

1 Like

Not sure if it helps but I did a write-up that goes in to a bit more detail than the guide: Hack The Box Walkthrough: Oopsie - Bob McKay's Blog

that is work for me
to do that
ifconfig | grep mtu

If size mtu 1500 changed to 1300

ifconfig <Interface_name> mtu <mtu_size>

full instructions here: How to change MTU size in Linux