Windows - “A computer is like air conditioning – it becomes useless when you open Windows”
Linux - “Linux is only free if your time is worthless”
Linux - “Linux is only free if your time is worthless”
Thursday 27 October 2011
Monday 24 October 2011
Simple Hacking Of MAC Filters for WiFi
Origin :-
The idea for MAC Filters for WiFi was taken from the wired networks.
The simplicity of spoofing MAC Address on any OS makes this very insecure.
Even then it works well for wired networks, except of course the insider attacks.
WiFi MAC Filters :-
Although this is not part of the 802.11 Standard, it is a Network Layer feature provided by the Access Point manufacturers.
Wireless MAC Filters allow only whitelisted MAC Addresses to connect to the AP.
Problem with MAC Filters :-
The WLAN Header field consist of the Clent MAC Addresses in plain text.
Hacking MAC Filters :-
Anyone who can sniff packets off the air, can read the MAC of a client.
This MAC can then be used to connect to the AP by MAC spoofing.
The idea for MAC Filters for WiFi was taken from the wired networks.
The simplicity of spoofing MAC Address on any OS makes this very insecure.
Even then it works well for wired networks, except of course the insider attacks.
WiFi MAC Filters :-
Although this is not part of the 802.11 Standard, it is a Network Layer feature provided by the Access Point manufacturers.
Wireless MAC Filters allow only whitelisted MAC Addresses to connect to the AP.
Problem with MAC Filters :-
The WLAN Header field consist of the Clent MAC Addresses in plain text.
Hacking MAC Filters :-
Anyone who can sniff packets off the air, can read the MAC of a client.
This MAC can then be used to connect to the AP by MAC spoofing.
Friday 21 October 2011
Web Services Intro
Introduction :-
Web Services can convert your application into a web-application, so that it can publish its function or message to the rest of the world.
The basic Web Services platform is XML + HTTP.
Web Services are published, found, and used through the Web.
What are Web Services?
How Does it Work?
The basic web services platform is XML + HTTP.
XML provides a language which can be used between different platforms and programming languages and still express complex messages and functions.
The HTTP protocol is the most used Internet protocol.
Web Services platform elements:
SOAP (Simple Object Access Protocol)
UDDI (Universal Description, Discovery and Integration)
WSDL (Web Services Description Language)
Example :- With Web services, your accounting department's Win 2k server's billing system can connect with your IT supplier's UNIX server.
What is SOAP?
SOAP is an XML-based protocol to let applications exchange information over HTTP.
Or more simply: SOAP is a protocol for accessing a Web Service.
What is WSDL?
WSDL is an XML-based language for locating and describing Web Services.
What is UDDI?
UDDI is a directory service where companies can register and search for Web services.
Web Services can convert your application into a web-application, so that it can publish its function or message to the rest of the world.
The basic Web Services platform is XML + HTTP.
Web Services are published, found, and used through the Web.
What are Web Services?
- Web services are application components
- Web services communicate using open protocols
- Web services are self-contained and self-describing
- Web services can be discovered using UDDI
- Web services can be used by other applications
- XML is the basis for Web services
How Does it Work?
The basic web services platform is XML + HTTP.
XML provides a language which can be used between different platforms and programming languages and still express complex messages and functions.
The HTTP protocol is the most used Internet protocol.
Web Services platform elements:
SOAP (Simple Object Access Protocol)
UDDI (Universal Description, Discovery and Integration)
WSDL (Web Services Description Language)
Example :- With Web services, your accounting department's Win 2k server's billing system can connect with your IT supplier's UNIX server.
What is SOAP?
SOAP is an XML-based protocol to let applications exchange information over HTTP.
Or more simply: SOAP is a protocol for accessing a Web Service.
- SOAP stands for Simple Object Access Protocol
- SOAP is a communication protocol
- SOAP is a format for sending messages
- SOAP is designed to communicate via Internet
- SOAP is platform independent
- SOAP is language independent
- SOAP is based on XML
- SOAP is simple and extensible
- SOAP allows you to get around firewalls
- SOAP is a W3C standard
What is WSDL?
WSDL is an XML-based language for locating and describing Web Services.
- WSDL stands for Web Services Description Language
- WSDL is based on XML
- WSDL is used to describe Web services
- WSDL is used to locate Web services
- WSDL is a W3C standard
What is UDDI?
UDDI is a directory service where companies can register and search for Web services.
- UDDI stands for Universal Description, Discovery and Integration
- UDDI is a directory for storing information about web services
- UDDI is a directory of web service interfaces described by WSDL
- UDDI communicates via SOAP
- UDDI is built into the Microsoft .NET platform
Monday 17 October 2011
Nessus Port Scan Engine
Port Scanning
Whether you are doing a network penetration testing or a web application audit, port scanning is always effective. Port Scanning helps us find which services are running on the well-known and not so well known ports (i.e. which ports are available). Essentially, a port scan involves sending a message to all of the ports, one at a time. The response received indicates if the port is open or not and if open, and then determine which service it is running.
NMAP is the tool of choice for Port Scanning, but even when scanning a network with Nessus, some testers still rely on NMAP to cross-verify with the Port Scanning results of Nessus.
Then there's also the myth that Nessus uses NMAP port scanning engine.
By default Nessus has never included or used NMAP for port scanning, though prior to 2.2 versions of Nessus used some NMAP code in the port scanning plugin. Nessus has its own port scanning engine, with various features and functions.
There are three different port scanners in the Nessus Port scanner system.
TCP Scanner :-
It initiates a full TCP connect with the target hosts, by sending a sequence of packets, thus completing the three way handshake everytime. The TCP port scanner tunes it's speed using logic as the scan progresses.
The TCP Port scan does not work on Windows and Mac OS, but only on Linux OS. It is a feature rich scanner, capable of handling different complex situations.
TCP Scanner Settings :-
Automatic (normal) - This is the default option, where it can identify a firewall located between the scanner and the target.
Disabled (softer) - For hosts that you know are not firewalled, this option can be used. If the ports are taking more time to respond, the scanner assumes it as a sign of network congestion.
Do not detect RST rate limitation (soft) - To increase reliability on slow networks, this options can be used. It disables the ability to monitor how often resets are sent.
Ignore closed ports (aggressive) - Whever a scan runs for more than 40 minutes, this options is turned on by Nessus. If any packet filter sends an ICMP unreachable in return, in which case TCP connect() scanner can't distinguish it from a RST, of course this is not a probelm for a SYN scanner.
2) SYN Scanner - Fully supported on Windows, MAC OS and Linux, the SYN Scanner behaves a bit differently, than the TCP scanner. It simplifies the process by sending packets and waiting for a response, but not initiating the full three-way handshake. It does not open sockets, but generates raw packets using low-level libraries. The SYN scanner has logic to compute the rate of packets to be sent and the amount of time to wait for a response. It will constantly recompute the optimal throughput as it scans periodically, so the calculations are happening several times throughout the scan to maximize the scan’s efficiency. The SYN scanner tends to be slower, but more reliable. The rate of packets for the SYN Scanner can now be controlled in Nessus 4.
The same options that are available for the TCP scanner also apply to the SYN scanner.
3) UDP Scanner - There’s not much you can do to make this one go faster (you can cheer it on, but that just helps pass the time) as the UDP scanner will generate UDP packets and send them to the target. Some operating systems respond with ICMP messages, others may crash and some just silently ignore the request. The big problem is that there is no reliable way to know if a port is open because a UDP-based listening service usually won't respond to a probe and also will not respond if the port is closed. Another problem is when ICMP messages are received from a target in response to the UDP probe. Certain operating systems respond slowly and rate limit the response to 1 packet per second for each response. This means a scan of all ports may take as long as 65,535 seconds to complete (approximately 19 hours).
Conclusion
Using the port scanners options in Nessus can be of great benefit in tuning your scans. Knowing which situations the SYN or TCP scanner are best utilized in will result in more accurate and faster vulnerability scans. You can refer to the Nessus product documentation for more information about the port scanner settings.
References :-
http://www.nessus.org/plugins/index.php?view=all&family=Port+scanners
http://blog.tenablesecurity.com
http://blog.tenablesecurity.com/2011/01/nessus-mythbusters-edition.html
Whether you are doing a network penetration testing or a web application audit, port scanning is always effective. Port Scanning helps us find which services are running on the well-known and not so well known ports (i.e. which ports are available). Essentially, a port scan involves sending a message to all of the ports, one at a time. The response received indicates if the port is open or not and if open, and then determine which service it is running.
NMAP is the tool of choice for Port Scanning, but even when scanning a network with Nessus, some testers still rely on NMAP to cross-verify with the Port Scanning results of Nessus.
Then there's also the myth that Nessus uses NMAP port scanning engine.
By default Nessus has never included or used NMAP for port scanning, though prior to 2.2 versions of Nessus used some NMAP code in the port scanning plugin. Nessus has its own port scanning engine, with various features and functions.
There are three different port scanners in the Nessus Port scanner system.
TCP Scanner :-
It initiates a full TCP connect with the target hosts, by sending a sequence of packets, thus completing the three way handshake everytime. The TCP port scanner tunes it's speed using logic as the scan progresses.
The TCP Port scan does not work on Windows and Mac OS, but only on Linux OS. It is a feature rich scanner, capable of handling different complex situations.
TCP Scanner Settings :-
Automatic (normal) - This is the default option, where it can identify a firewall located between the scanner and the target.
Disabled (softer) - For hosts that you know are not firewalled, this option can be used. If the ports are taking more time to respond, the scanner assumes it as a sign of network congestion.
Do not detect RST rate limitation (soft) - To increase reliability on slow networks, this options can be used. It disables the ability to monitor how often resets are sent.
Ignore closed ports (aggressive) - Whever a scan runs for more than 40 minutes, this options is turned on by Nessus. If any packet filter sends an ICMP unreachable in return, in which case TCP connect() scanner can't distinguish it from a RST, of course this is not a probelm for a SYN scanner.
2) SYN Scanner - Fully supported on Windows, MAC OS and Linux, the SYN Scanner behaves a bit differently, than the TCP scanner. It simplifies the process by sending packets and waiting for a response, but not initiating the full three-way handshake. It does not open sockets, but generates raw packets using low-level libraries. The SYN scanner has logic to compute the rate of packets to be sent and the amount of time to wait for a response. It will constantly recompute the optimal throughput as it scans periodically, so the calculations are happening several times throughout the scan to maximize the scan’s efficiency. The SYN scanner tends to be slower, but more reliable. The rate of packets for the SYN Scanner can now be controlled in Nessus 4.
The same options that are available for the TCP scanner also apply to the SYN scanner.
3) UDP Scanner - There’s not much you can do to make this one go faster (you can cheer it on, but that just helps pass the time) as the UDP scanner will generate UDP packets and send them to the target. Some operating systems respond with ICMP messages, others may crash and some just silently ignore the request. The big problem is that there is no reliable way to know if a port is open because a UDP-based listening service usually won't respond to a probe and also will not respond if the port is closed. Another problem is when ICMP messages are received from a target in response to the UDP probe. Certain operating systems respond slowly and rate limit the response to 1 packet per second for each response. This means a scan of all ports may take as long as 65,535 seconds to complete (approximately 19 hours).
Conclusion
Using the port scanners options in Nessus can be of great benefit in tuning your scans. Knowing which situations the SYN or TCP scanner are best utilized in will result in more accurate and faster vulnerability scans. You can refer to the Nessus product documentation for more information about the port scanner settings.
References :-
http://www.nessus.org/plugins/index.php?view=all&family=Port+scanners
http://blog.tenablesecurity.com
http://blog.tenablesecurity.com/2011/01/nessus-mythbusters-edition.html
Tuesday 11 October 2011
Subscribe to:
Posts (Atom)