Sniffing raw sockets (SOCK_RAW) without Administrator account in windows - c++

I am creating a simple sniffer using c++ under visual studio , and windows 10 x64 , but when I tried to run it. I got Failed to create raw socket. which is because admin rights , but I was reaching on internet . I could use something like CAP_NET_ADMIN , but it is linux based . is there a way to do under windows such as wireshark non-root users works?
//Initialise Winsock
printf("\nInitialising Winsock...");
if (WSAStartup(MAKEWORD(2,2), &wsa) != 0)
{
printf("WSAStartup() failed.\n");
return 1;
}
printf("Initialised");
//Create a RAW Socket
printf("\nCreating RAW Socket...");
sniffer = socket(AF_INET, SOCK_RAW, IPPROTO_IP);
if (sniffer == INVALID_SOCKET)
{
printf("Failed to create raw socket.\n");
return 1;
}
printf("Created.");

Creating a Raw Socket:
Raw sockets offer the capability to manipulate the underlying
transport, so they can be used for malicious purposes that pose a
security threat. Therefore, only members of the Administrators group
can create sockets of type SOCK_RAW on Windows 2000 and later.

If anyone is getting this with Wine, you need to allow the wineserver to use Ping.SendPrivileged:
sudo setcap CAP_NET_RAW=ep /usr/bin/wine
sudo setcap CAP_NET_RAW=ep /usr/bin/wineserver
sudo setcap CAP_NET_RAW=ep YOUREXE.exe

Related

Why does binding socket to interface fail?

I'm trying to open a raw socket and bind my wireless interface to it. This is the code I am using:
//opening socket
if ((sockfd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL))) == -1){
//if socket fails give error
perror("socket");
}
//binding socket to interface
if (setsockopt(sockfd, SOL_SOCKET, SO_BINDTODEVICE, "wlp0s19f2u3", 4) < 0)
perror("SIOCGIFHWBIND");
But when compiling and running with sudo I get a "SIOCGIFHWBIND: No such device".
I first thought this is because there I miss spelled the interface name but my iwconfig output is:
wlp0s19f2u3 IEEE 802.11 Mode:Monitor Frequency:2.462 GHz Tx-Power=20 dBm
and it isn't an issue with monitor mode because running the code while my wireless card is in managed mode gives the same output and I need the interface to be in monitor mode.
Please help and have a nice day!
Thanks Mark Setchell, turns out the 4 was from example code where they used something like "eth0" which has 4 chars. So replacing 4 with a strlen() of your interface works great. Thanks once again.

Native SSL Support for WINAPI

I'm trying to make a simple IRC client, using the Winsock API, to which I want to add SSL support. Currently I just use overlapped socket I/O like this:
SOCKET sock = WSASocketW(AF_INET, SOCK_STREAM, IPPROTO_TCP, NULL, 0x02, 0x01);
if (!sock)
return;
struct sockaddr_in ircClient;
memcpy(&ircClient.sin_addr, he->h_addr_list[0], he->h_length);
ircClient.sin_family = AF_INET;
ircClient.sin_port = wPort;
WSAEVENT hDataEvent = WSA_INVALID_EVENT;
if (WSAConnect(sock, (sockaddr*)&ircClient, sizeof(ircClient), 0, 0, 0, 0) > 0) {
closesocket(sock);
return;
}
if (wsWSAGetLastError() != 0) {
closesocket(sock);
return;
}
Now, as I understand, for SSL support, I need to do SSL handshake after WSAConnect(). I found old Internet posts saying there are no SSL support in Winsock. It is now is year 2017, and 95% of websites work with SSL. Is there still no way to do this? I have found Using Secure Socket Extensions, but it is not SSL.
I've done years ago some SSL/TLS stuff over standard TCP connections using native windows API, but I'm not familiar with this specific "secure socket extension".
I can recommend using SSPI. It doesn't automatically transform your socket to SSL, but can be used pretty easy for generating SSL request/response/data packets on request.
Look for InitializeSecurityContext for more info.

One-way SOCK_STREAM

We're creating a socket using SOCK_STREAM over AF_UNIX (a local file). We have many processes on the system which are clients, and we are only interested in broadcasting messages to those clients. OS is Ubuntu 14.04.5 LTS.
This all works if the file permissions are 666, however as a security measure we want to change it to 644. However, this causes a permission exception when clients try to connect using the below code:
int XyzClient::establish_connection() {
int fd;
if ((fd = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) {
throw XyzException(strerror(errno));
}
sockaddr_un addr = {};
addr.sun_family = AF_UNIX;
strncpy(addr.sun_path, DEFAULT_SOCKET_PATH, sizeof(addr.sun_path)-1);
if (connect(fd, (sockaddr*)&addr, sizeof(addr)) == -1) {
// connect failed, close fd and throw exception
close(fd);
throw XyzException(strerror(errno));
}
return fd;
}
Presumably the issue is the above code tries to establish read-write access to the file and which is causing the permission error.
Is it possible to do a one-way SOCK_STREAM such that we can lock down the file to be read-only by everyone except the owner/broadcaster?
It is not possible to make a read-only unix domain socket and enforce this with file permissions. From the relevant man page unix(7)
On Linux, connecting to a stream socket object requires write permission on that socket; sending a datagram to a datagram socket likewise requires write permission on that socket. POSIX does not make any statement about the effect of the permissions on a socket file, and on some systems (e.g., older BSDs), the socket permissions are ignored. Portable programs should not rely on this feature for security.

Bluetooth with C++ and winsock

I'm finding it very hard to get information on Bluetooth communication in C++. Specifically I want to avoid using any third party libraries and I simply want to connect to a device already paired with my computer.
The device has already had its passcode entered and is available in the 'Show Bluetooth Devices' under my devices and printers. I'm using Windows 7 and visual studio 2013 professional for development in C++.
I've got some example code (from here http://www.winsocketdotnetworkprogramming.com/winsock2programming/winsock2advancedotherprotocol4k.html) which displays information on my Bluetooth radio and then displays device information and it seems to work well. Although it's printing out every Bluetooth device already paired with the computer, not ones which are within range, but that may be me misinterpreting what the code is suppose to do.
I've been looking through the Bluetooth reference page (http://msdn.microsoft.com/en-us/library/windows/desktop/aa362930%28v=vs.85%29.aspx) and all the functions are just to do with setting the Bluetooth radio availability and other things like that; no sign of connecting to a found device at all.
I must be missing something, using wrong key words when Googling or something, because I've found nothing about connecting to a Bluetooth device!
If anyone has any suggestions, code, or links that would be great! I can connect to my device using the serial functionality (very easily) but I have to manually enter the COM port it's registered on, which isn't very user friendly. I want to scan and select, or enter a Bluetooth device name, and connect that way.
Cheers
EDIT:
BitBanks answer pointed me in the right direction. Only thing missing was a WSAStartup request before any socket requests:
WORD wVersionRequested;
WSADATA wsaData;
int err;
/* Use the MAKEWORD(lowbyte, highbyte) macro declared in Windef.h */
wVersionRequested = MAKEWORD(2, 2);
err = WSAStartup(wVersionRequested, &wsaData);
if (err != 0) {
/* Tell the user that we could not find a usable */
/* Winsock DLL. */
printf("WSAStartup failed with error: %d\n", err);
return 1;
}
If you have a bluetooth address from discovery or the paired-devices list, you can connect to it like this (error checking needs to be added):
#include <winsock2.h>
#include <ws2bth.h>
SOCKADDR_BTH sockAddr;
SOCKET btSocket;
int error;
btSocket = socket(AF_BTH, SOCK_STREAM, BTHPROTO_RFCOMM);
memset (&sockAddr, 0, sizeof(sockAddr));
sockAddr.addressFamily = AF_BTH;
sockAddr.serviceClassId = RFCOMM_PROTOCOL_UUID;
sockAddr.port = BT_PORT_ANY;
sockAddr.btAddr = <your bluetooth address>
error = connect(btSocket, (SOCKADDR*)&sockAddr, sizeof(sockAddr));
Some devices advertise the SerialPortServiceClass_UUID instead of the RFCOMM_PROTOCOL_UUID. You also may need to retry the connection several times. Certain poorly implemented bluetooth devices (cough PowerA Moga cough) require multiple tries to connect.
This may not be the official way to do it, but I get the 6-byte BT address of the device I'm interested in from the paired list like this:
unsigned char *p;
ULONGLONG ullAddr;
p = (unsigned char *)pwsaResults->lpcsaBuffer->RemoteAddr.lpSockaddr; // point to addr
memcpy(&ullAddr, &p[2], 8); // copy Bluetooth address of device we found

Socket Exception: "There are no more endpoints available from the endpoint mapper"

I am using winsock and C++ to set up a server application. The problem I'm having is that the call to listen results in a first chance exception. I guess normally these can be ignored (?) but I've found others having the same issue I am where it causes the application to hang every once in a while. Any help would be greatly appreciated.
The first chance exception is:
First-chance exception at 0x*12345678* in MyApp.exe: 0x000006D9: There are no more endpoints available from the endpoint mapper.
I've found some evidence that this could be cause by the socket And the code that I'm working with is as follows. The exception occurs on the call to listen in the fifth line from the bottom.
m_accept_fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if (m_accept_fd == INVALID_SOCKET)
{
return false;
}
int optval = 1;
if (setsockopt (m_accept_fd, SOL_SOCKET, SO_REUSEADDR,
(char*)&optval, sizeof(optval)))
{
closesocket(m_accept_fd);
m_accept_fd = INVALID_SOCKET;
return false;
}
struct sockaddr_in local_addr;
local_addr.sin_family = AF_INET;
local_addr.sin_addr.s_addr = INADDR_ANY;
local_addr.sin_port = htons(m_port);
if (bind(m_accept_fd, (struct sockaddr *)&local_addr,
sizeof(struct sockaddr_in)) == SOCKET_ERROR)
{
closesocket(m_accept_fd);
return false;
}
if (listen (m_accept_fd, 5) == SOCKET_ERROR)
{
closesocket(m_accept_fd);
return false;
}
On a very busy server, you may be running out of Sockets. You may have to adjust some TCPIP parameters. Adjust these two in the registry:
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
MaxUserPort REG_DWORD 65534 (decimal)
TcpTimedWaitDelay REG_DWORD 60 (decimal)
By default, there's a few minutes delay between releasing a network port (socket) and when it can be reused. Also, depending on the OS version, there's only a few thousand in the range that windows will use. On the server, run this at a command prompt:
netstat -an
and look at the results (pipe to a file is easiest: netstat -an > netstat.txt). If you see a large number of ports from 1025->5000 in Timed Wait Delay status, then this is your problem and it's solved by adjusting up the max user port from 5000 to 65534 using the registry entry above. You can also adjust the delay by using the registry entry above to recycle the ports more quickly.
If this is not the problem, then the problem is likely the number of pending connections that you have set in your Listen() method.
The original problem has nothing to do with winsock. All the answers above are WRONG. Ignore the first-chance exception, it is not a problem with your application, just some internal error handling.
Are you actually seeing a problem, e.g., does the program end because of an unhandled exception?
The debugger may print the message even when there isn't a problem, for example, see here.
Uhh, maybe it's because you're limiting greatly the maximum number of incoming connections?
listen (m_accept_fd, 5)
// Limit here ^^^
If you allow a greater backlog, you should be able to handle your problem. Use something like SOMAXCONN instead of 5.
Also, if your problem is only on server startup, you might want to turn off LINGER (SO_LINGER) to prevent connections from hanging around and blocking the socket...
This won't answer your question directly, but since you're using C++, I would recommend using something like Boost::Asio to handle your socket code. This gives you a nice abstraction over the winsock API, and should allow you to more easily diagnose error conditions.