Determining Network Resources, finishing out the series on software assessment, let's discuss how to determine the network resources required to operate the software. For this you will need a protocol analyzer to be able to capture the transactions that are happening. For my testing, I use Wire Shark, I am not going into great details on how to use Wire Shark, the documentation on Wire Shark is very detailed and easy to understand.
The basic process is to start a capture with Wire Shark, and then open the software and perform some basic functions. I usually go through the menu system and try out the features. We are especially looking for features that cause network traffic. The vendor documentation can be useful by giving a clue to what ports and protocols the software uses to connect to a server or other clients. Once you are finished trying out features in the software, stop the Wire Shark capture. Now it is time to analyze the capture file.
After reading the Wire Shark documentation and you have basic idea of TCP/IP protocol you should have the basic idea of how to look at the packets. One of the useful features in Wire Shark is follow TCP Stream, which shows the conservation between the software and the server or clients it is talking to in one screen. Of course this is only helpful if the software is using TCP. Also ensure that you have a filter set to only show traffic from the computer you are testing and only run the software under test, it can be annoying to have to sort through network traffic that has nothing to do with the software that is being tested.
While reading through the capture file, keep track of all the ports and protcols that are being used. Usually the software will select random ports above 1024 to send packets on, the random ports are not as important as the listening port on the server or client that is recieving the packets. The endpoint conversation window can be useful to view the ports and IP addresses that were connected to during the test.
What are we looking for?
- Ensure the software will comply to current firewall policy, if the software requires a range of ports to be opened on the firewall this can be a risk, I have seen software that requires 1,000 ports on the firewall to be opened to allow the server to make connections to the client, this was considered too much risk and the software was not allowed to be used. Now if the network communications are contained within the LAN instead of connecting outside to the Intrenet, this could be considered a lower risk.
- Is the data being encrypted or passed in clear text, In the past when security was an afterthought, we used to see username and passwords passed in clear text, some protocols are designed like this such as telnet and ftp this is why sftp and ssh were developed.
- Bandwidth, How much bandwidth does the software require, will it cause a denial of service to the other programs running on the network. If the software is downloading large image or video files constantly then this could tie up the network and not allow other services required to operate. This is a judgement call, but Wire Shark will give you an idea of the amount of traffice that is being generated and based on your current network use you should decide if the network can handle this new software.
An interesting example is you have a software product that performs periodic updates to istself, and we see this type of dialog
DNS request for the vendor website
Connect to the website, website sends a list of the program files with version numbers
Client checks the versions it recieved with the versions installed
Client downloads any files that have a newer version
Is this a risk?
If I was attacking this system, all I would have to do is ensure the DNS request points to my malicious server, then the client would automatially download any file I deemed as an updated. It is not that diffcult to modify and add code to a dll that is called evertime a program is run. Without any logins or encryption this could become a serious risk, the risk also depends on how important is the system that is running this software.
The basic process is to start a capture with Wire Shark, and then open the software and perform some basic functions. I usually go through the menu system and try out the features. We are especially looking for features that cause network traffic. The vendor documentation can be useful by giving a clue to what ports and protocols the software uses to connect to a server or other clients. Once you are finished trying out features in the software, stop the Wire Shark capture. Now it is time to analyze the capture file.
After reading the Wire Shark documentation and you have basic idea of TCP/IP protocol you should have the basic idea of how to look at the packets. One of the useful features in Wire Shark is follow TCP Stream, which shows the conservation between the software and the server or clients it is talking to in one screen. Of course this is only helpful if the software is using TCP. Also ensure that you have a filter set to only show traffic from the computer you are testing and only run the software under test, it can be annoying to have to sort through network traffic that has nothing to do with the software that is being tested.While reading through the capture file, keep track of all the ports and protcols that are being used. Usually the software will select random ports above 1024 to send packets on, the random ports are not as important as the listening port on the server or client that is recieving the packets. The endpoint conversation window can be useful to view the ports and IP addresses that were connected to during the test.
What are we looking for?
- Ensure the software will comply to current firewall policy, if the software requires a range of ports to be opened on the firewall this can be a risk, I have seen software that requires 1,000 ports on the firewall to be opened to allow the server to make connections to the client, this was considered too much risk and the software was not allowed to be used. Now if the network communications are contained within the LAN instead of connecting outside to the Intrenet, this could be considered a lower risk.
- Is the data being encrypted or passed in clear text, In the past when security was an afterthought, we used to see username and passwords passed in clear text, some protocols are designed like this such as telnet and ftp this is why sftp and ssh were developed.
- Bandwidth, How much bandwidth does the software require, will it cause a denial of service to the other programs running on the network. If the software is downloading large image or video files constantly then this could tie up the network and not allow other services required to operate. This is a judgement call, but Wire Shark will give you an idea of the amount of traffice that is being generated and based on your current network use you should decide if the network can handle this new software.
An interesting example is you have a software product that performs periodic updates to istself, and we see this type of dialog
DNS request for the vendor website
Connect to the website, website sends a list of the program files with version numbers
Client checks the versions it recieved with the versions installed
Client downloads any files that have a newer version
Is this a risk?
If I was attacking this system, all I would have to do is ensure the DNS request points to my malicious server, then the client would automatially download any file I deemed as an updated. It is not that diffcult to modify and add code to a dll that is called evertime a program is run. Without any logins or encryption this could become a serious risk, the risk also depends on how important is the system that is running this software.
0 comments:
Post a Comment