2

So, I've run an unauthenticated Nessus scan against a critical piece of infrastructure as part of a pen-test but I'm getting back some weird stuff and i can't seem to re-create the issue to demonstrate it to the client.

The machine i'm testing is a HP-UX machine but Nessus is flagging that a specific share 'backup' can be accessed using a NULL session (Nessus pluginID 42411) and that the contents of the share are read/write (it goes on to list the correct contents of the share (confirmed with the admin)). This is exploiting the service on TCP 445.

Now generally, if I'm trying to establish a NULL session from a Windows-based machine to a windows based machine which is vulnerable I'll run the following command

C:\> net use \\hostname\IPC$ "" /USER:""

Then I can simply browse shares by simply opening up a run dialogue and going \hostname\ and I see a nice listing. Not so in this case. I can't see the contents of the share or even open it.

So, obviously this is a HP-UX machine which means that this finding is already a bit off, but none-the-less, it's still seeing stuff it shouldn't be and I don't know how to re-create this. The associated CVEs (1999-0520 and 1999-0519) do not appear to contain any useful information regarding exploiting this. Are NULL sessions a Windows only issue or is that any Samba client? How can I reproduce this issue either on a Linux test machine or on my Windows test machine to demonstrate the vulnerability to the client?

The other vulnerability identified by Nessus is 'Samba Symlink Traversal Arbitrary File access' (Plugin ID 44406). It shows that it is able to read the contents of /etc/passwd and the contents are again, confirmed to be correct, however I'm not entirely sure about how to reproduce this again. According to the Samba advisory the problem occurs when a client is allowed to write to a directory (presumably the above mentioned 'backup' share) and create symlinks to local resources. It appears that this code will demonstrate the issue.

Is it correct that fixing the NULL session authentication will fix the Symlink issue (at least for unauthenticated attackers)?

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
NULLZ
  • 11,426
  • 17
  • 77
  • 111

1 Answers1

1

Make sure you are using the correct account for accessing the NULL share. This could be nobody or smbnull. (Check your smb.conf file.)

C:\> net use \\hostname\backup "" /USER:nobody

C:\> net use \\hostname\backup "" /USER:smbnull

Also try the backup share instead of IPC$ with your empty user:

C:\> net use \\hostname\backup "" /USER:""

Is it correct that fixing the NULL session authentication will fix the Symlink issue (at least for unauthenticated attackers?).

Yes, it will fix it for unauthenticated attackers. To fix it for all users, you should set wide links to no.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178