I have built a Dynamic Virtual Channel for RDP and it works fantastic in most cases, but there are some cases that I cannot get it to work and I am out of ideas as to why.
Here is what I have tried and what works:
Running the DVC plugin in proc on a 64 bit client connecting to a 64 bit server
Running the DVC plugin Out of Proc in a 64 bit COM server with a 64 bit client connecting to a 64 bit server
Here is what I have tried and fails:
Running the DVC plugin in proc in a 32 bit client connecting to a 64 bit server
Running the DVC plugin out of proc in a 32 bit COM server with a 32 bit client connecting to a 64 bit server
Running the DVC plugin out of proc in a 32 bit COM server with a 64 bit client connecting to a 64 bit server.
In all cases of failure, the plugin is loaded by the RDP client OK and I get all of the standard calls (Initialize, Connected, Disconnected, Terminate), I can even successfully call IWTSVirtualChannelManager.CreateListener OK (meaning no exceptions), but the IWTSListener is always null when it returns.
Does anyone have any ideas why IWTSVirtualChannelManager.CreateListener would not create a new listener and still return S_OK?
Related
I have a small "lab" trying to pentest at home, and I have my main OS and on a VM I'm running Windows XP SP3 (ENG). I use the ms08_067_netapi and the reverse_tcp as a payload. When i use the exploit command this is what I get.
[*] Started reverse TCP handler on 192.168.1.69:4444
[*] Automatically detecting the target...
[*] Fingerprint: Windows XP - Service Pack 3 - lang:English
[*] Selected Target: Windows XP SP3 English (AlwaysOn NX)
[*] Attempting to trigger the vulnerability...
[*] Exploit completed, but no session was created.
What I can understand from that is that the exploit works, but the payload isn't able to function. The first thing I did was to change port from 4444 to 80 just in case, firewall was blocking the payload. I got the same reply, trying with both 80 and 443 as LPORT.
Do you have any suggestions on what else I could do?
https://security.stackexchange.com/questions/112601/ms08-067-netapi-not-performing-as-expected-on-windows-xp-sp1-sp3
The Answer is in that thread
There are many reasons for this exploit to fail, in short:
The target is patched.
'Not supported language' error from the target.
The payload can't execute correctly.
Networking errors 'reverse connection through NAT'.
From experience with the same issue, I recommend to do the following:
Try not to use VMs.
Try another payloads, away from reverse connections.
Try other versions of Windows XP.
Change system languages 'sometime it works!'
We have to migrate a System with our software from a Windows Server 2003 to a Windows Server 2012 R2. At this project we just changed the server hardware (to a HP ProLiant Server), the OS and the ISDN card with the CAPI driver. On this server there is a C++ application which filters a 30 byte character string out of the ISDN D-Channel and send it over a TCP socket (localhost, port 30000) to a JAVA application. The message comes every 30 seconds and has always the same format.
The problem is: Every 6 minutes the TCP socket is getting deleted/cleared/doesn't work. Both applications log the broken communication in their log files, build and open the socket again and the game goes on without any problems for another 6 minutes.
At the old system, this software works for years without any problems on Windows Server 2003 on 9 sites.
What we've already done without any positive effect:
deactivate the firewall completely
change the port to different ones (30001, 30500, 16000, 997)
use the own IP (10.16.58.30) instead on localhost
put several timeouts to the TCP Parameters at the registry (e.g. KeepAliveTime)
update JAVA to the last version
install all recommended updates for Windows Server 2012 R2
strip both applications down to just the socket to ensure that the software itself hasn’t any problem
using a standard message ('1234567891234567890') instead of the incoming ISDN message to exclude malfunction from strange input data
checking the message length to exclude a length of 0
checking all buffers on both sides to exclude buffer overflow
checking if any other software on the server is using 'our' port
The problem doesn't appear, if we're sending the messages from outside manual or in different message cycles with a bash script to the server port of the JAVA app.
We are now thinking that this can only be some kind of checking mechanism of the operating system that forces our socket to stop communication. Any suggestions, what that could be?
My problem is that I have two servers, one running MQ Server and one running service which will get MQ messages from the former. However easily it sounds, I cannot make the latter to connect to the queue manager on the first server. I tried the following actions:
Ping the first server from the second one: it works just fine
Telnet the first server from the second one, using specific port used to connect MQ Manager on the first server (1416): it also works find
Now it comes the weird part: I created one Queue Manager on the second server (there is also a MQ Server running on that machine), with the same name with the MQ Manager on the first server that I want to connect, then I can only connect to this queue, although in the ChannelInfo I specify exactly the first server's IP address, not the second's.
After deleting the MQ Manager on the second server, it just gives me error 2058: MQRC_Q_MGR_NAME_ERROR. I checked the MQ Mananer name on the first server, it was correct.
It is possible to connect from other servers to the first server's MQ Manager.
More information that I doubt it is the source of my problem: the first server running Windows 32 bits and the second one is running Windows 64 bits. Moreover the second one is fresh installed, so I think it might have problem with some sorts of permissions. However searching around didn't help me so far.
I really appreciate if someone here could shed some lights on my problem. It made my project overdue deadline for a week already.
Thanks in advance!
No the error is not due to 32/64 bit Windows platform.
On both 32 bit as well as 64 bit Windows platforms queue manager runs as a 32 bit process.
So that's not the issue.
Obvious things to verify on the first server:
Have you defined a listener for the queue manager to listen on port 1416? If yes, is it running?
Have you defined a server connection (SVRCONN) channel on the queue manager?
How does your service(running on second server) attempt to connect to the queue manager? Is it bindings or client mode? In bindings mode, an application can connect only to the queue managers running on the same machine. In client mode, applications can connect to queue manager running on the same machine or a different machine. Your service must use a client mode connection to connect to remote machine.
To connect to remote queue manager, the application must specify the host name, port and channel name.
My company is currently using TortoiseSVN 1.6.16 32-bit on Windows XP to connect via HTTPS to a VisualSVN-Server 2.1.19 running on a Windows Server 2003 residing in the same network (no proxy). We use a self-signed certificate and Kerberos authentication using windows credentials (I suppose this is a VisualSVN-specific feature). In this setup, everything works dandy.
When my company decided to move on to Windows 7, we tried TortoiseSVN 1.7.6 64-bit on Windows 7 64-bit which resulted in the following problem:
Any operation involving the server (repo-browser, checkout, update, checkin, ...) is unbearably slow e.g.
opening the repo-browser (10 projects): 15 min
update on a fresh checkout of 50 files: 1 min
checkin of a single empty file: 30 sec
Tortoise shows alternatively normal transmission speeds and 0 byte/s. Many small files seem to be slower than a few big ones.
The slow connection results in various failures when using neon as http-lib (serf is still slow, but operation finishes successfully without errors)
EasySVN, SmartSVN and the SVN command line client that comes with TortoiseSVN show the same behaviour. Same with TortoiseSVN 1.6.16 64-bit.
Changing the server protocol to HTTP (no SSL) does not improve the situation
On the other hand
TortoiseSVN 1.7.6 32-bit on Windows XP works fine with our server
Access via browser/WebDAV works well even under Windows 7
Server side logs do not show errors or even warnings
I found several posts which also complained about slow behaviour on Windows 7, but they didn't fit my bill because they were local operations or were restricted to TortoiseSVN.
As there is no indication that there is a general problem with Subversion on Windows 7, I suspect that it could be our OS' networking parameters or protocol versions. Are there any parameters which are known to influence Subversion's performance?
I have to admit I am not familiar with how exactly Subversion (or rather neon/serf) relies on the OS and on which parts. Any information on that would be greatly appreciated.
Are there any parameters in the subversion 'servers' file which I should test? How would you consider my chances that Wireshark'ing the connection will help me?
Similar experiences, opinions, hints, help and straws are welcome.
Wireshark shows sporadic gaps of ca. 5 sec in the TCP stream apparently caused by VisualSVN Server.
https: the server acknowledges the client hello then waits for 5 secs before sending its server hello
https: the server acknowledges the client key and than takes 5 secs before supplying its encrypted handshake data
https: even outside the handshake, server sometimes sends an ACK (on TCP level) and then waits for 5 sec before sending something back to the client (the data is encrypted so it's hard to tell whether the break occurs at some point of interest)
http: at both server side transmissions during the NTLM authentication
http: before server sending a FIN flag
A typical fail with Windows 7 against an older server is IPv6 networking.
If your machine does not have an SVN server listening on an IPv6 address Windows 7 might still try to do a TCP6 connect first (you can see it in Process Explorer if you look at the open sockets of the TortoiseSVN process while trying an operation), this has a timeout of a few seconds and then retries with IPv4.
Simple solutions are either upgrade your server to an IPv6 capable one or disable IPv6 for the Windows 7 clients.
Another thing you could verify (the answer above didn't work for us) is the Internet Explorer settings especially if you have IE9. We found that by disabling the option Automatically detect settings in the Internet Options -> Connection tab -> LAN settings, SVN started working normally again.
The issue was never properly cleared up. Most probably, the company internal network path between the client and the server was somehow at fault. The matter became obsolete when we moved the SVN server to another machine. The very same setup of server and clients works fine now, even with Windows 7.
I had the same symptom of a very slow repository browse, slow updates, slow everything.
My SVN server has two Ethernet cards, so it has two Ethernet IP addresses. The SVN server was only listening on one of the IP addresses. So a name resolution via WINS or NetBIOS could resolve to the 'wrong' IP address.
TortoiseSVN would retry, eventually the name resolution would find the 'correct' IP address, and things would work.
stupid problem. I get those from a client connecting to a server. Sadly, the setup is complicated making debugging complex - and we run out of options.
The environment:
*Client/Server system, both running on the same machine. The client is actually a service doing some database manipulation at specific times.
* The cnonection comes from C# going through OleDb to an EasySoft JDBC driver to a custom written JDBC server that then hosts logic in C++. Yeah, compelx - but the third party supplier decided to expose the extension mechanisms for their server through a JDBC interface. Not a lot can be done here ;)
The Symptom:
At (ir)regular intervals we get a "Address already in use: connect" told from the JDBC driver. They seem to come from one particular service we run.
Now, I did read all the stuff about port exhaustion. This is why we have a little tool running now that counts ports and their states every minute. Last time this happened, we had an astonishing 370 ports in use, with the count rising to about 900 AFTER the error. We aleady patched the registry (it is a windows machine) to allow more than the 5000 client ports standard, but even then, we are far far from that limit to start with.
Which is why I am asking here. Ayneone an ide what ELSE could cause this?
It is a Windows 2003 Server machine, 64 bit. The only other thing I can see that may cause it (but this functionality is supposedly disabled) is Symantec Endpoint Protection that is installed on the server - and being capable of actinc as a firewall, it could possibly intercept network traffic. I dont want to open a can of worms by pointing to Symantec prematurely (if pointing to Symantec can ever be seen as such). So, anyone an idea what else may be the cause?
Thanks
"Address already in use", aka WSAEADDRINUSE (10048), means that when the client socket prepared to connect to the server socket, it first tried to bind itself to a specific local IP/Port pair that was already in use by another socket, either an active one or one that has been closed but is still in the FD_WAIT state. This has nothing to do with the number of ports that are available.
I'm having the same issue on a Windows 2000 Server with a .Net application connecting to a SQL Server 7.0. There's like 10 servers with the same configuration and only one is showing this error several times a day. With a small test program I'm able to reproduce the error by just establishing a TCP connection on the SQL Server listening port. Running CurrPorts (http://www.nirsoft.net/utils/cports.html) shows there's still plenty of available ports in range 1024-5000.
I'm out of ideas and would like to know if you've found a solution since you've posted your question.
Edit : I finally found the solution : a worm was present on the server (WORM_DOWNAD.A) and exhausted local ports without being noticed.