I tried for my first time the fast and capable masscan, which is the best Open Source Network Security Scanner I ever used. It allowed me to scan and map a large IP address space covering over million hosts.
once I identified a specific vulnerable pattern on a machine, I could easily cross reference this pattern with over the millions of discovered hosts in #masscan database.
For more information and to try out the masscan-web-ui for yourself, you can check out the GitHub project page.
Curated list of awesome honeypots, tools, components and much more. The list is divided into categories such as web, services, and others, focusing on open source projects.
Discover more on github below link:
Google has announced the acquisition of an Israeli startup SlickLogin, a company that has reinvented password authentication processes using sound.
Security using two-factor authentication activated may be winning by decreasing their hacking chances, but will no doubt have come across frustrating login situations. SlickLogin aims to make this process more seamless by allowing users to complete the two-step process simply by placing your phone next to their laptop or tablet. The startup claims its technology offers "military-grade security" using "fortified protocol model".
Summary: South Korea is considering a nation wide block of port 25, as a anti-spam countermeasure aiming to reduce the volumes of spam affecting the country.
the recent OWASP AppSec DC presentation on Slow HTTP POST DoS attacks, the issue of web server platform DoS concerns have reached a new high. Notice that I said, web server platform and not web application code. The attack scenario raised by slow HTTP POST attack is related to web server software (Apache, IIS, SunONE, etc...) and can not be directly mitigated by the application code. In the blog post, we will highlight the two main varieties of slow HTTP attacks - slow request headers and slow request bodies. We will then provide some new mitigation options for the Apache web server platform with ModSecurity.
Whereas network level DoS attacks aim to flood your pipe with lower-level OSI traffic (SYN packets, etc...), web application layer DoS attacks can often be achieved with much less traffic. The point here is that the amount of traffic which can often cause an HTTP DoS condition is often much less than what a network level device would identify as anomalous and therefore would not report on it as they would with traditional network level botnet DDoS attacks.
Ivan Ristic brought up the concept of connection consumption attacks in his 2005 book "Apache Security":
5.4.3. Programming Model Attacks
The brute-force attacks we have discussed are easy to perform but may require a lot of bandwidth, and they are easy to spot. With some programming skills, the attack can be improved to leave no trace in the logs and to require little bandwidth.
The trick is to open a connection to the server but not send a single byte. Opening the connection and waiting requires almost no resources by the attacker, but it permanently ties up one Apache process to wait patiently for a request. Apache will wait until the timeout expires, and then close the connection. As of Apache 1.3.31, request-line timeouts are logged to the access log (with status code 408). Request line timeout messages appear in the error log with the level info. Apache 2 does not log such messages to the error log, but efforts are underway to add the same functionality as is present in the 1.x branch.
Opening just one connection will not disrupt anything, but opening hundreds of connections at the same time will make all available Apache processes busy. When the maximal number of processes is reached, Apache will log the event into the error log ("server reached MaxClients setting, consider raising the MaxClients setting") and start holding new connections in a queue. This type of attack is similar to the SYN flood network attack we discussed earlier. If we continue to open new connections at a high rate, legitimate requests will hardly be served.
If we start opening our connections at an even higher rate, the waiting queue itself will become full (up to 511 connections are queued by default; another value can be configured using the ListenBackLog directive) and will result in new connections being rejected.
Defending against this type of attack is difficult. The only solution is to monitor server performance closely (in real-time) and deny access from the attacker's IP address when attacked.
The issue at hand with these attacks is that the client(s) are opening connections with the web server and sending request data very slowly. For those of you familiar with the old LaBrea Tarpit app for slowing down network based worms, this is somewhat of a reverse approach. Instead of the defender (LaBrea) sending back a TCP Window size of 0 to the attacker (worm) which would force the TCP client to wait for a period of time before resubmitting, in this scenario the attacker is the one forcing the web server to wait. If a web client opens a connection and doesn't send any data to the web server then the web server will default to waiting for the connection's Timeout value to be reached. Wanna guess how long that time interval is in Apache by default? 300 seconds (5 minutes). This means that if a client can simply open a connection and not send anything, that Apache child process thread will sit idle, waiting for data, for 5 minutes. Ouch... So the next logical question to ask from the attacker's perspective is - What is the upper limit on the number of concurrent connections for Apache? This depends on your configs but the main ServerLimit directive has a hard coded value of 20000 (most sites run much less). This limit makes it very feasible for a much smaller number of DDoS clients to take down a site vs. the extremely large number required for network-based pipe flooding.
There are two types of attack to cover when a malicious client never sends a complete Request as specified by the HTTP RFC:
Firesheep banks on the fact that most social sites default to the HTTP protocol because it’s quicker. The already existing Firefox extension Force-TLS attempts to circumvent this by forcing those sites to use the HTTPS protocol, therefore making user cookies invisible to Firesheep.
Like the alternative option HTTPS Everywhere, the Force-TLS Firefox extension allows your browser to change HTTP to HTTPS on sites that you indicate in the Firefox Add On “Preferences” menu, protecting your login information and ensuring a secure connection when you access social sites.
HTTPS encrypts user data, so if a script like Firesheep’s like tries to pull it, it can’t be read. Force-TLS forces a number of sites to make all of their requests over an SSL secured channel and while some sites, like Amazon, don’t currently have the secure option, the majors like Facebook, Twitter, Google, etc all allow a HTTPS connection.
How to configure:
1. Download the plugin here and install into Firefox.
2. Open “Preferences” and add the domains you want to force the HTTPS connection with.
3. Restart Firefox.
Note: Unlike HTTPS Everywhere, Force-TLS relies on the user defining the sites they want to access through a secure HTTPS connection.
And while everyone know that there’s always some privacy risk when interacting online, hopefully the installation of Force-TLS will at least put less of a damper on today’s stint at your local “free Wifi!” boasting cafe. I’m also looking into the possibility of equivalents for this extension on other browsers and will update this post as soon as I have alternative options.
It's extremely common for websites to protect your password by encrypting the initial login, but surprisingly uncommon for websites to encrypt everything else. This leaves the cookie (and the user) vulnerable. HTTP session hijacking (sometimes called "sidejacking") is when an attacker gets a hold of a user's cookie, allowing them to do anything the user can do on a particular website. On an open wireless network, cookies are basically shouted through the air, making these attacks extremely easy.
This is a widely known problem that has been talked about to death, yet very popular websites continue to fail at protecting their users. The only effective fix for this problem is full end-to-end encryption, known on the web as HTTPS or SSL. Facebook is constantly rolling out new "privacy" features in an endless attempt to quell the screams of unhappy users, but what's the point when someone can just take over an account entirely? Twitter forced all third party developers to use OAuth then immediately released (and promoted) a new version of their insecure website. When it comes to user privacy, SSL is the elephant in the room.
Days at Toorcon 12 They announced the release of Firesheep, a Firefox extension designed to demonstrate just how serious this problem is.
After installing the extension you'll see a new sidebar. Connect to any busy open wifi network and click the big "Start Capturing" button. Then wait.
As soon as anyone on the network visits an insecure website known to Firesheep, their name and photo will be displayed:
Double-click on someone, and you're instantly logged in as them.
Firesheep is free, open source, and is available now for Mac OS X and Windows. Linux support is on the way.
Snort’s third operating mode – network intrusion detection – is when the magic happens. Here, Snort actually pays attention to the network traffic passing its electronic eyes and matches what it sees according to a database of updatable signatures as well as any custom user-defined rules. In this mode, Snort does for networks what anti-virus tools do for filesystems.
What’s best is it still runs when you’re asleep, processing packets, log files and more. Actually, you can configure it to send alerts via SMS or other means that can even wake up your network or security staff. Or, you could define rules so Snort blocks the suspicious traffic as well as other traffic from the originating host.
Where Snort isn’t so great is the massive amounts of disk space it chews up with the log files it produces as well as the signature files used to detect rule violations. It’s not unrealistic that Snort operating within a high-traffic site could consume up to 100Gb of disk space. Snort doesn’t especially require any particular level of processor but it really will need a fast disk controller and a lot of space – let alone a network card that is as fast as or faster than the rest of your network (or else you can miss packets.) If the budget can cater for it, really, the best advice would even be to dedicate a machine directly to Snort’s use.
Wherever you choose to run Snort, you do have to remember to place it on your network in a strategic location, because it can only see traffic on its own subnet. There’s little point running Snort on your office desktop computer if your public-facing web and mail servers are housed in a co-location facility, for instance. In fact, depending on the complexity and size of your network, you may want to consider multiple Snort installations, to ensure all your key assets are protected by having one Snort system within each key subnet
