No, this attack is not feasible. Believe me, I've tried. Now when I say I've tried it, I was not writing a virus or something to steal passwords, I was writing software where the user was fully aware that they were using a custom DNS server which intentionally lied (based on their rules) in conjunction with a HTTP proxy. This is exactly what you describe, "poisoning" the DNS to basically lie to the software making the lookup and point it wherever you really want to the traffic to go. There are several issues that arise once you throw SSL into the mix.

1) Even if you have a custom DNS server or piece of software monitoring and modifying the DNS packets, there is no way inside this protocol to tell if you are dealing with requests for HTTP/HTTPS, or who knows what. So, you cannot tell what protocol the request is for. Even if you inspect the packet and look for the hostname, it will appear as "mail.google.com", not "https://mail.google.com", as an example.

2) In order to bypass the browser warnings, you need a few things. First, you need a trusted root certificate for your proxy or malicious server. Not gonna happen. Even if you manage to get the user to accept and install it (which windows basically makes sure to make the user feel like they're accepting an envelope with anthrax if they say yes), most browsers have their own trusted root authority certificate stores that they check against. So now you've gotta get the user to go out of their way to install your cert in whatever flavour of browser they're using as well.

3) Step two isn't enough. Now, if you've gotten that far, you have your malicious cert for your malicious server. Now you need to dynamically issue certs for every single host that a HTTPS connection is made or else guess what, the alarms still go off. These browser warnings aren't like the old days. Google chrome won't even let you proceed when it detects this going on, no matter how much the user wants to be careless with their own security.

Also, without doing any of this failed trickery discussed in 2 and 3, you get even less. All you can see on a socket level is the socket open from the app requesting the lookup, you see the host resolution happen over DNS, then a new TCP socket open attempting to connect to the host requesting a secure connection. The socket header doesn't contain anything except this basic request. As soon as the connection is made with the server, a handshake takes place and the HTTP connection becomes secured, at which time the hope of screwing with any of the data is lost.

The point is that the likelihood of this attack succeeding is basically non-existent. The user would have to ignore Windows' doomsday style warnings about certs, pass the Windows request for elevated administrator permissions (assuming you're using malicious software to directly poison the DNS cache or tell the system to use a malicious DNS server), then they'd have to ignore the giant red-screen, doomsday style warning in their browser (if their browser even allows it). It would be exceptionally difficult to pull of and would have minimal success even if you could.

All of this said, I really hope you're requesting this information for the sake of the good, not of actually attempting things like this. Tinkering around and learning these things can be fun and can aid in protecting users. Yes it would be perfectly ok to set up your own test network and hack it for fun and education, but doing and learning all this stuff to exploit people makes you a thug and a criminal and a disgrace to higher learning. I'm not saying you are this, I'm saying people who do that are. I hope you consider and weigh out these moral and philosophical questions in your adventure to obtain knowledge.

See also, for proof of browser protection from this issue.

Chrome SSL Warning: "You cannot proceed because the website operator has requested heightened security for this domain. "


Was the Raspberry Pi-related NASA JPL network breach primarily caused by the failure to keep an updated list of authorized devices?

There's no one central cause, the breach was a product of multiple failures. Like space launch failures or airplane crashes it was a cascade of failures, preventing one of them would have at least lessened the severity of the breach:

Poor training and security awareness: putting a raspberry PI on the network was a big no-no, the user who did it shouldn't have done it and colleagues should have spoken up
Problems weren't fixed: the security operations group were massively behind in investigating incidents. Because it took so long to resolve tickets people may have stopped reporting issues, which may have contributed to 1
No VMS (Vulnerability Management System): A VMS is technology and process to scan for and remediate vulnerabilities on a network. The technology side is agent or engine based and set up to sweep an entire network in a discovery scan and then do a deeper scan on detected devices in order to determine a) what they are and b) what vulnerabilities they may have. The process side is for the the information to be used by automated systems or interpreted by people to find the threats. A halfway decent VMS would have found that PI and action would have been taken to get it off the network
Poor network protection: there's several issues, the firewall rules to limit access from one network to another were wide open, and access to the network wasn't limited to only recognized devices. If the firewall rules had been stronger or the JPL had been tighter in permitting only recognized devices on sensitive networks then the breach would have been mitigated or prevented

If I had to sum it up in a single line, the breach was due to the lack of a robust security program with a failure to maintain defense in depth.


Strange and unknown user name on Windows 10

Two potential explanations.  One, malware could have created the account.  Two, ESET has some anti-theft functionality which creates what they call phantom accounts.

The account name seems random so I would not expect to find that account name by googling it.

Suggestions for malware path:

ensure you scan the computer fully with your antivirus
learn more about the account - check the local group membership, see if there are any services set to run under it, or search your registry for this string.  All require some knowledge of system administration.  If you open command prompt and run the net user command for the account, you will also be able to see when the account was created, logged onto and group membership.  This could lead to attributing the account creation to your system install date, or antivirus install date, or that one time 6 months ago when you browsed to a porn site and some malware made your browser run weird.
depending on outcomes above, deal with any risks of leaving the account there, having a virus and anything else applicable

Suggestions for ESET path:

get ESET support to help you explain if their software does this, especially if you have anti-theft software from them


Win2012R2 TLS1.2 Mutual authentication - change cipher specs from server side after no certificate from client?

It is fully valid that the client responds to a certificate request by the server with an empty certificate. It is up to the server how to deal with this case, i.e. if it will treat a client certificate as optional or if the certificate is required.

I'm not familiar with SChannel but with OpenSSL you can set SSL_VERIFY_FAIL_IF_NO_PEER_CERT in SSL_CTX_set_verify if you want to make the server fail if no client certificate is send if you set SSL_VERIFY_PEER only than the client certificate is optional.

SChannel has probably a similar mechanism but it is up to the application to use it. Thus look into the configuration of your HTTP server. In case of IIS this is described in the documentation which says that you can configure client certificates to be ignored, accepted or required by the server.


If you are not using the HTTPS connection, then it would seem security is not a concern and it would be irrelevant whether the HTTPS is displaying and error. The certificate is part of what gives authenticity to the connection.

If you consider the HTTPS lack of a certificate to be a security issue, then just using HTTP itself would also be an issue. If the risk of attack does not justify using HTTPS in your scenario, you can disable it or advise users that the HTTPS version is not providing the full security, so they should not expect that (and just ignore the warning or use non-TLS/SSL HTTP).


Linux kernel 3+ system call table modification detection

It is impossible to detect kernel modifications from inside the system. Whatever rootkit detector you use, the rootkit can be programmed to lie to it. If someone controls your kernel, then they control your system, not you, end of story. GMER suffers from that flaw too, it is intrinsic in the operating principle: it only finds rootkits that aren't good at hiding.

It is possible to detect kernel modifications from the outside. A common technology for that purpose is a TPM, which is a piece of hardware. It's a bit more complicated than “check the system call table for modifications” because the system call table is just a small part of the kernel, a modification anywhere else can have similar-reaching consequences. TPM works by taking a snapshot of the system from time to time, and comparing these snapshots with a reference snapshot. The TPM stores only hashes, not the whole memory image, so the snapshots have to match bit-for-bit. Loading modules changes the kernel, so you need to have a fixed set of modules as well as a fixed kernel version.

Detecting a kernel modification is useful only if there is some place to report it to. The TPM can't tell the user, because it has no user interface. The way to leverage a TPM is when you use your computer to authenticate to a remote service. The TPM sends a measurement of your PC, and the remote service compares that with a reference value and decides whether your PC is in a known good state or not. An unknown state could be a version upgrade or a compromise, the remote service has no way to know, so usefully using a TPM requires more infrastructure to manage upgrades.

Instead of a hardware TPM, you can implement similar functionality in a hypervisor. This requires no special hardware, but of course implies that your system runs in a virtual machine.


What to make of inconsistent TFA/2FA verification emails from AOL

Per Filipe dos Santos' note in the comments I reached out to AOL support. It took some prodding, but it sounds like 4/8/variable length TFA codes are possible, "For more security"

The missing salutation is odd, but probably more to do with poor formatting.
I'd say in this particular case there's nothing nefarious/suspect. This experience reinforces for me that consistent behavior and user messaging helps encourage trustworthiness.


Yes, the VPN provider is able to see your data. If the data are not encrypted (i.e. HTTPS) the provider will be able to get to the clear text and will also be able to manipulate the data.
The usual protections of HTTPS apply, i.e. the provider will see which site you visit but not the clear text data itself because they are encrypted. The provider will also not be able to modify the data undetected. Based on traffic pattern (size, timing...) the provider might still try to narrow down the specific pages you visit on this site.


How customising a wordlist to make a bruteforce attack in leetspeak with hashcat or John the ripper

Yes, there is a program called 'crunch' that allows you to specify exactly what you need and it will generate a wordlist that you will then later pass into John The Ripper or hashcat. You can tell crunch to include or exclude specific letters,symbols and numbers. You can tell it which letters in which positions should be capital or lowercase. The possibilities are really endless, so I would definitely take the time to read the manpage I linked. Anytime I need to brute-force a hash, this is my go to because it reduces the time significantly.

Read the documentation thoroughly and look at the examples they provide and you should be able to construct a worldist to your exact specifications.

Crunch: http://manpages.ubuntu.com/manpages/zesty/man1/crunch.1.html


Evaluate this approach: set production DNS to point to 127.0.0.1

The vendor is shipping their private key to all of their customers, on purpose. Even if this shouldn't really matter since it's only used to encrypt traffic going over localhost, it demonstrates a severe lack of security knowledge on the vendor's part. My advice: avoid like the plague.


how does ASLR prevent return to libc / ROP and similar attacks?

brute force a vulnerable program with all possible addresses

Trying to brute-force the address space (there are 2^64 possible addresses in a modern 64-bit system) is supposed to be impossible in practice due to constraints on time (and resources). Also see: What is the largest performed/possible bruteforce attack to date?

On a more practical note, if you guess the address wrong there is a big chance of the program crashing due to for instance a segmentation fault. Since brute-forcing a 64 bit address can take long, these crashes can be detected.

Therefore, finding the addresses of the shellcode on the stack, the library functions (in the case of return-to-libc) or the gadgets (in the case of ROP) is too hard for the attacker.

Of course, there are other ways to bypass ASLR. Look into Pointer Leaks and memory layout attacks such as heapspray if you are interested.


You have interpreted the first one correctly.

The second one:

flow:established,to_server; content:"POST"; nocase; http_method; \
content:"/check.php?tcpc="; http_uri;                            \
content:!"User-Agent|3a|"; http_header; ...

This alerts if: method is POST, URI contains /check.php?tcpc= and it does NOT have a User-Agent. The ! in front of the content string means that it is a negated match. So it matches if it's absent from the inspected traffic.

Third one:

content:"&AFFILIATE="; http_uri; content:"&ID="; http_uri; content:"&ERROR=0

This matches if all of the contents are present. This is generally true for Suricata rules. All of the conditions have to match for a rule to generate an alert.

Suricata rule language documentation can be found here: https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricata_Rules


Are there any feasible solutions/workarounds for WPA2 hole196 vulnerability as of today?

There are solutions already on the market provided by several vendors. These include client isolation (clients are not allowed to talk to eachother using the wireless access point as medium).

Other mitigating techniques include wireless IPS which detect MAC spoofing. MAC spoofing is nescesary when the attacker wants to trick the client in thinking he/she is the gateway.

Of course these mitigations are not part of the protocol but rather additional controls you can opt to implement.


1. Kerberos

The best example of explaining Kerberos from a practical viewpoint I've ever come across, is Bill Bryant's Designing an Authentication System:
a Dialogue in Four Scenes. Originally intended to provide an understanding of the conceptual ideas in Kerberos, as a way to promote implemenations of KerberosV4, it does a decent job, and is quite amusing if you ask me.

2. SET

SET is not a de-facto standard, although intended and promoted as such during development. Even VISA, one of the sponsors and heavy proponents of SET, now promotes newer and more modern security standards for e-commerce.

3. X.509

The first practical case of X.509 certificates that comes to mind, is the widespread use of SSL/TLS to encrypt data transactions on websites over HTTPS


Host sending massive amount of TCP/IP Packets with RA Flag: Part of DDoS Attack?

I wrote a script that fetches the certificate from all hosts that where listed in the firewall with TCP:RA to port 443. The Results showed that ~70% of that hosts had certificates for *.dropbox.com and to some other cloud based solutions. Seemingly the connection of these clients had been reset by servers by sending a packet with the RST Flag set which terminated the State in the firewall. The firewall then blocked the RST,ACK Answer from the client. So no malware in most cases. One host was actually infected.


Can phone services be affected by DDoS attacks?

A denial of service with local impact against a single or a limited number of phone lines is easy: just call them and if they drop the call then call again. As long as you call them the line is blocked for any other calls, i.e. denial of service. Even phone numbers which can handle multiple calls at the same time (for examples emergency lines) can be flooded. This process can be easily automated, both for modern VoIP lines and also for old POTS lines (which can be usually reached by VoIP too). It does not even need to be distributed, i.e. with VoIP a single computer can be used to keep multiple calls at the same time open.

For more information see the numerous hits you'll find when searching for phone denial of service or voip denial of service, like:

Krebs on security: DHS Warns of ‘TDos’ Extortion Attacks on Public Emergency Networks
Cisco: The Surging Threat of Telephony Denial of Service Attacks


Mixing stateless and stateful firewall rules

Using state-based filtering across the board in an effort to make troubleshooting a firewall ruleset easier will not work out as intended. The result is likely to be quite the opposite.

State is just another characteristic to filter packets on. There is not reason that each rule in a ruleset should use the same characteristics. Or that "stateful" is somehow an inherently superior approach.

For a ruleset easier to be set up accurately, easy to troubleshoot and easy to update without breaking things it needs to be comprehensible to the administrator. It will be easier to understand if the rules are expressed as simply as possible. So additional filtering characteristics - particularly those such as state which are harder to follow in your head - should be used only when necessary.


How is password stolen over non-SSL connection?

When data is exchanged over the Internet, it hops from router to router, starting with the source (your desktop computer) and ending with the destination (the authentication server to which you are sending the password). All the routers, by definition, "see" the data. Moreover, all machines which are directly plugged with the link between any two routers can also see the data.

In practice, for low-level attackers, password sniffing mostly occurs through three mechanisms:

Close to the user (you). E.g. you are using your laptop and connecting through a WiFi access point; other machines connected to the same access point see all your traffic. Note that "taking steps" to prevent such local attackers can be quite difficult (for instance, forget it is WiFi is involved).
Close to the server. Typically, servers are mass-hosted in some shared facilities, and indelicate server owners may spy on their neighbours. Whether this is possible or even easy depends a lot on the competence of the network administrators at the hosting site.
Through active redirection. When you want to connect to a server, you actually type a name, and then the DNS finds the IP address which corresponds to that name. Your machine will send the packets to that IP address. However, the DNS, as a whole, is poorly protected, and can be altered by malicious individual. A bad guy may then transparently redirect your packets to his own machines; he may even inspect the data but still forward it to their true destination, which makes him a Man-in-the-Middle. At that point, the attacker sees all the data, including the password and whatever the password protects, and can hijack the connection at any time.

All three kinds of sniffing can be put into practice, and are actually applied, by students with a few hundreds of dollars of budget and a lack of morality. More advanced criminals can employ other active methods, e.g. trying to disturb dynamic routing mechanisms. Or simply bribe employees at network facilities (in particular Internet Service Providers).

SSL (now known as "TLS") fixes things in several ways:

It encrypts all the data with a key that only the two end points (your machine and the server) know, effectively keeping out passive eavesdroppers.
It uses the server's certificate, so that the client can gain some confidence that it is indeed talking to the intended genuine server, not an attacker-controlled fake. This is the point of the padlock picture and the scary warnings in Web browsers.
SSL ensures continuous integrity, meaning that an active attacker cannot simply put himself in MitM position, forward data bytes back and forth, and then hijack the connection after the authentication has taken place. The protection granted by SSL is both for confidentiality (data is unreadable by outsiders) and integrity (data cannot be altered by outsiders), and this encompasses the complete connection, not just the initial steps.

With SSL active and no certificate validation issue, you can send your password with reasonable guarantee that only the intended server will see it. How the server verifies the password is irrelevant here. Moreover, and again thanks to SSL, the server can assume that the initial authentication is valid for all subsequent traffic over the same connection, because SSL guarantees that it will be talking to the same client all along.


HIPAA: How am I required to secure PHI database access creds on my web server?

So, according to the HHS security guidelines, a username and password combination is a sufficient mechanism for authenticating an individual.   However... Storing user passwords in plaintext in a config file is not usually a recommended design pattern.  Certainly not a list of every individual user allowed to access the database along with their plaintext passwords.  I am not a PHI/HIPAA auditor, but I would strongly expect that if I were to present this design to an auditor, he might take issue with this.

Some measures that you could take to limit your risk:

1) Don't store passwords at all.   Rather, store only the password you need to access a user database for authentication, and not the password to the database containing the PHI.   The database password can be derived from the user's application password using a KDF, and it can be derived on authentication, rather than being stored.

2) Store the password, but encrypt the config file.  To prevent this from being simple obfuscation, you need to store the encryption key somewhere more secure than another config file, like in an HSM.

3) Ensure that indirect database access is blocked, in case of stolen credentials.  The database server should be firewalled and access should be via a whitelist.  In most cases, only the application (web) servers should be granted access to the database server.  This way, even if someone steals credentials, they can't simply log into the the database from their own machine.  Additionally, since the data by rule must be encrypted, if you decrypt using the application rather than database level functions, even if a malicious user does manage to access the database from outside of the application, they won't have access to unencrypted data.


Is it a good idea to give users an additional password that they do not control?

Most passwords these days only have to be good enough to defeat brute-force at the web interface, and to do that they don't have to be all that complex. Given how good password cracking is these days with GPUs, hash tables and rainbow tables if your password database is compromised you'd have to consider them cracked even if they are complex. Plus, if your password database was compromised you'd still want to send new passwords just to cover yourself.

Sure, you could give your users complex passwords which are so hard to remember they have to be written down, and then lost, requiring another one to be sent, which will then be written down and lost. It's a great way to piss off your customers without much net increase in security over simply enforcing good password standards.


Logged into same network of residence, owner knows my Mac address.. what can they see?

They can set up a packet sniffing program such as Wireshark to intercept all communications. As long as the websites you visit have an https - you're protected. As for apps and other things, try to find out if they use TLS encryption. Even with encryption/https they can see what IP addresses you connect to. If you don't set up your own DNS settings (with DNS encryption) they can see what domains you access. So if you type in google.com they can see your device made a DNS request for that but that's it they cannot see what you do on Google.

Perhaps you may be interested in using a VPN


How to store passphrase in this situation?

First, the login should be issued per-client, so it can be changed if leaked, or cancelled when a client's access to the service is revoked. This reduces the consequences of loss of the password to the smallest size, instead of losing everything when one client is compromised or goes rogue.

Once you have done that, your problem is simply to store a password which is used for this one client with this one service. This is a well-known problem with well-known solutions. Essentially, you should assume that the operating system is secure. (If it is not you have bigger problems.) So save it into a file, the registry etc, and protect it with an ACL. If you wish you can add obfuscation on top of that, or use CryptProtectData or similar, which can provide some protection against unsophisticated attackers.

But the bottom line is you need to accept that issuing, revoking, and resetting credentials is going to be a normal part of your operation. You will also want to monitor usage of the service so you can detect when credentials have leaked.


By statute and out of tradition, the NSA operates in hidden ways. So the exact reasons of why the NSA did something or did not cannot be rigorously known. However, one can make some guesswork.

A first thing to note is that suite B is meant for interoperability: it is a deliberately small list of algorithms and features with the official purpose of being implemented everywhere. For instance, for elliptic curves, they only list two specific curves among the 15 described in FIPS 186-3. So we can assume that NSA included only algorithms which were already implemented in various systems and libraries, or stood a good chance of being implemented in the near future. Nobody uses MQV and nobody really intends using MQV in the foreseeable future...

Now why nobody uses MQV in practice is another question, and the answer boils down to the usual three: patents, uselessness and weaknesses. The "uselessness" part deserves an explanation: MQV is an authenticated key exchange in that it tries to combine the key exchange with a mutual authentication of both involved parties. This is neat, but does not map well to existing communication frameworks, in particular SSL. In SSL, the client and server are distinct roles; the client gains assurance that it knows the correct server public key through the server's certificate, but the authentication of the client, when applied at all, is separated from the key exchange (the client computes a signature with its private key, and the algorithm for that signature needs not be related to the one used for the key exchange).

Another viewpoint on the subject is that if a putative SSL client has a certificate with a MQV public key (assuming that use of MQV with SSL was formalized and implemented), then the client can use that certificate only to authenticate with SSL servers who uses MQV and happen to have a MQV key pair which uses the same elliptic curve. This is rather restrictive, and contrasts with the usual situation where the client has a generic signature certificate which can be used in many other contexts.

Interestingly, use of elliptic curve cryptography in SSL/TLS is defined in RFC 4492, published in 2006, after a long sequence of drafts. The first draft, from 1998, includes MQV-based cipher suites. But the second draft, in 2001, does not. In the first draft, MQV was used just like it was Diffie-Hellman, so without any actual security benefit. In that context, MQV was just a more complex way of doing DH, and, as such, was removed altogether. The alleged benefits of MQV over DH (even assuming that the benefits are real, which is what Krawczyk denies) are made void by the structure of the SSL/TLS key exchange. So why bother ? DH is slightly faster and has a less clouded sky with regards to patents.

Summary: Even without taking into account the weaknesses revealed in 2005 (a few months after publication of NSA suite B), the security advantages of MQV over DH are any good only in specific contexts which are rarely encountered in practice, especially if we notice that suite B is about interoperability, i.e. by definition not about proprietary closed scenario. Correspondingly, nobody does MQV (or when they do, they don't aim at interoperability). In the contexts where the notion of "suite B" applies, MQV tends to have no benefit over a simpler (and faster) Diffie-Hellman. This alone justifies NSA not including MQV in their "suite B".


When pushing a DNS resolver to an OpenVPN client, does the resolver see the IP address of the client or the OpenVPn server?

The DNS server will be access based on the routing table and thus the answer depends how the routing is setup and where the DNS server is. Usually: if the DNS server is in the same subnet as the OpenVPN then it will see the OpenVPN specific IP of the client. If the DNS server is outside and all traffic is routed through the VPN then it will see the public IP address of the tunnel endpoint.


The Metasploit Framework is my go-to tool for pentest automation still to this day, however, I do like what I've seen of CORE INSIGHT and Immunity Security SWARM. There are a few tools such as Loki (or the older Yersinia tool), intrace, Chiron, mana-toolkit, mitmf, bettercap, and Responder.py that must be run outside of the Metasploit framework, but so many things can be done inside msfconsole these days (`load kiwi' comes to mind). If you want to see some amazing resources, check out this document which covers performing the full PTES using Metasploit.

Metasploit is catching up a little bit here and there (to nearly every tool and technique in existence!), such as the auxiliary/server (and capture) modules. However, many questions remain, such as performance comparisons between auxiliary/spoof/arp/arp_poisoning, arpspoof, macof, arp-sk, nemesis, and ettercap. Does auxiliary/sniffer/psnuffle work any differently than dsniff? What's the difference between Squirtle, auxiliary/server/http_ntlmrelay, and auxiliary/server/capture/http_ntlm? How does http_javascript_keylogger compare to BeEF? How do auxiliary/spoof/llmnr, auxiliary/spoof/nbs, auxiliary/server/wpad and auxiliary/server/capture/smb compare to Responder.py? Clearly others are simply superior, but I'd like to recode them (or see someone do this) to be part of MSF. For example, shouldn't dns2proxy (from sslstrip2's author) features exist in auxiliary/server/fakedns?

Much of the early work in network penetration testing is done with either nmap or unicornscan, although pbscan, zmap, and masscan have gained a lot of ground in recent years. In particular, dnmap is a sleek approach. There is even a web interface to dnmap called Minions.

Here are a few flags I enjoy with regards to nmap:

Slow scan (but not too slow), evades IDS, and gives the reason why the packets didn't make their destinations. Best performed one port at a time with data-length or string set when the destination protocol or port isn't known by nmap. Use robtex and csrecon to check your target IP prefixes. Try to identify one or two ports you can leverage that are not web servers, but that have historically been vulnerable to remote code exploitation (N.B., you may need to correlate this data with cvedetails.com or exploitsearch.net). You will notice I have chosen TCP port 623 (IPMI RMCP, an already slow-to-respond service that benefits from these slow scans) in the example, but you could easily change this (although I don't recommend obvious ones such as SSH or RDP -- at least check the Shodan HoneyScore before challenging these).

  -T1 --max-retries 0 --randomize-hosts --reason -n -Pn -sT -p 623

HTTP or TLS targets will typically run the default ports, so I like to SYN scan them first before scanning other HTTP/TLS targets on non-default ports. The second command will be very slow, but it will likely go under the radar (especially if you use this patch taken from this blog post), allowing full pivot to the web layer undetected. If you find that the web-related ports are open but the http-title script fails, then something is amiss -- potential honeypot warning! Look for correlation between an open port and a valid, corresponding HTML title element tag that matches the service name and purpose. If a particular IP always responds to any port, then use nmap's --exclude <ip> directive or --excludefile <filename> if you have a list of IPs (similar to nmap's -iL flag).

  -T1 --max-retries 0 --randomize-hosts --script http-title --reason -n -Pn -r -p 80,443

  -T1 --max-retries 0 --randomize-hosts --script +http-title --open -n -Pn -p 81,457,902,995,1100,1128,1241,1581,1883,1944,2301,2375,2381,3010,3037,3128,3780,3790,3872,4000-4002,4100,4567,4848,5000,5250,5800-5802,5814,5986,6060,6405,7000-7002,7080,7181,7272,7443,7510,7770,7778,8000-8001,8008,8014,8028,8040,8081,8085,8088-8091,8095,8140,8161,8180,8200,8222,8300,8400,8443,8500,8776,8834,8880,8883,8888,8980,8999-9000,9002,9060,9080,9084,9090,9191,9292,9389,9443,9495,9990,9999,30821,50000

If everything is in order, switch to faster scans and check for IDS/IPS. You'll know something went wrong when all of your scans stop, but you can be a little more efficient about it by using nmap's traceroute flag (or combine it with the firewalk script), intrace, lft, ttl-mon.py, or osstmm-afd to try and map out these systems. Typically, firewalls that include IPS/IDP functionality, network-based IPS/IDP appliances, UTM, NGFW, and similar network-stack gateways will only sample the traffic to be analyzed every 8-11 seconds. Longer delays between port scans (e.g., the 15-second default in nmap T1 scanning, or by setting a specific 12-second delay in T2 scans) and the lack of parallelization are typically what make these slower scans sneak by intrusion detection of all kinds. Repeat traffic, such as that which is directed to a single port, could also cause intrusion detection bells to go off, identifying traffic as an attack or automatically rejecting it. During the sampling period, intrusion detection might also look for sequential ports. There are a variety of factors to try and identify or play with. Thus, the next nmap flags seen below should be modified to test for this series of IDS-identification strategies. If the first test case (T2 scan with 12-second delay, no retries, and no sequential ports) gets by but the second does not, then you will want to figure out why. Nmap's packet-trace and traceroute capabilities are highly suggested, but other tools such as hping3 or nping may come in useful to support this effort.

If you find your traffic blocked (e.g., responses completely stop), you may need to switch the source public-IP (or LAN IP) you're coming from, so I suggest that you run most of these at Starbucks or off your primary, usual location (dnmap will likely also help here). Try not to hit any honeynets (e.g., Fortinet FortiGate, TrapX DeceptionGrid, etc) either, or at least identify them so that you can exclude them in future scans. The best way to avoid these traps is to leverage that scans.io and SHODAN data (and knowledge about the target environment, the kinds of technologies in use -- more useful when performing internal network scans), grab a scoreful of ports (nmap or dnmap at increasing speeds, each with 20 or so unique ports), and avoid the overly-shiny services that are potential honeypots, i.e., 21-23, 25, 53, 110, 135-139, 445, 1337, 1433, 1723, 3306, 3389, 5060-5061, 5800, 5900, 8080, 10000, 31337, and 44443 (N.B., DON'T scan these port numbers yet!).

  -T2 --scan-delay 12s --max-retries 0 --randomize-hosts --open -n -Pn -p26,66,79,113,389,407,465

  -T2 --scan-delay 9s --max-retries 1 --randomize-hosts --open -n -Pn -p512-514,523-524

  -T2 --max-retries 3 --randomize-hosts --open -n -Pn -p548,554,587,593,873,993,1026,1050,1080,1099,1158,1344,1352,1521,1604,1720,2202,2302,2383

  --max-rate 20 --max-parallelism 2 --max-retries 3 --randomize-hosts --open -n -Pn -p2628,2869,2947,3000,3031,3260,3478,3500,3632,3689,4369,5019,5040,5222,5353,5357,5432,5560,5631-5632

  --max-rate 40 --max-parallelism 4 --max-retries 3 --randomize-hosts --open -n -Pn -p5666,5672,5679,5850,5920,5984-5985,6000-6005,6379,6481,6666,7019,7210,7634

  --max-rate 80 --max-parallelism 8 --max-retries 3 --randomize-hosts --open -n -Pn -p8000,8009-8010,8834,9160,9999,11211,12000,17185,13722,19150,27017,30718,35871,49152,50030,50060,50070,50075,50090,52822,52869,60010,60030,64623

Written below is the next level of nmap scanning (default speed, no randomizing because of the qscan latency checks), giving you lots of detail and potential for movement. Use mostly port numbers you know are open, although select one port that is potentially not open (especially ones in the past that had ambiguous results). Avoid using dnmap or other inefficiencies that will break the qscan script. TCP (typically HTTP or SSL/TLS) ports could be behind reverse-caching proxies, load balancers, redirected at the network level, or similar. The qscan script should help identify these situations, although you will likely want to supplement them with other tools such as halberd (or additional NSE scripts such as http-affiliate-id and http-favicon). In this phase, you can use either IP prefixes, hostnames, or a combination. I suggest using one strong tool here, such as blacksheepwall. Be careful when targeting hostnames because Passive DNS sensors will give away your location and/or intentions much more easily than you think, leading to blocks similar to IPS or WAF (and at this point you will need to be able to distinguish between those three, as well as other defensive countermeasures). Keep testing all ports in the manner directly above until you've exhausted what you already know about the target network(s) and domains. If you have a target SSL/TLS port, the duplicates script will help you understand when a single host is speaking on multiple IPs or networks (typically multihomed).

  --script qscan --max-retries 7 --reason -Pn --version-intensity 0 -sV -p80,(other found-TCP ports)
  --script qscan,duplicates,ssl-cert --max-retries 7 -v --reason -Pn -sV --version-all -p80,443,(others previously-found)

Follow this line of thinking with some single port checks using a bad TCP checksum. Utilize your knowledge of the past and build on it. Before you proceed, make certain you have a good idea about the network paths and internals of every packet you send, and predict the responses from this point on out. If you want to build a little extra knowledge at this stage, you might want to use different tools, such as pbscan, portbunny, masscan, zmap, or unicornscan (the -w file.pcap flag could be repurposed here to allow for packet capture analysis much like MSF's pcap_log, but I don't necessarily suggest either approach as cool as they initially sound). If you do have a way (preferably a separate, inline system so that the disk I/O, CPU, and memory usage doesn't affect your scans) to perform packet capture, typically you will want a tool such as netsniff-ng to save pcaps (or a different tool if you require pcapng) and then process the results with p0f and/or PRADS. Fingerprinting can get complex, and there are a few tools besides nmap that you will likely want to leverage at this stage. Targeting port-specific versions isn't necessary quite yet, although it can be accomplished here. I suggest going heavy on the OS-level fingerprinting with "just enough" service identification to correlate. There are old techniques (such as a fork of nmap called cron-os) that should be ported to a newer tool with a fp database refresh to modern platforms (which is why I suggested p0f and PRADS earlier -- they tend to keep up with the constant change of technologies). Rapid7 has a big-data project for service fingerprinting, recog. Nmap's service versioning is only average when compared to tools such as amap, and there are many point-solution tools such as fpdns, ntp-fingerprint.pl, info2cpe, et al. Vuln scanners such as Nessus incorporate hmap (an HTTP fingerprinter), but there are many tools in that space as well (httprint, httprecon). It's annoying that OS fingerprinting and service versioning are highly problematic. I suggest you do the best you can with the methods and tools I described.

  --script qscan --max-retries 7 --badsum -v -O --osscan-guess --max-os-tries 1 --reason --send-ip --version-intensity 0 -sV -p80,(at least one closed port)

If, and when you do, run into any obvious IPS or other blocks, see the section far below which mentions sniffjoke and other advanced evasion techniques (AETs). If you can actually fingerprint the system(s) blocking your traffic then your best bet is to run a sniffjoke client/server pair in another similar environment where you have server access already (N.B., this could be from a previous pen test or from a lab or mock environment). The above badsum trick should preempt most IPS systems. Other techniques we've been through may have also uncovered these blocking systems. If you find a good AET then you will likely want to run all of your previous port scans over again to see if you have similar results. If you feel that SYN traffic is being throttled (one way to check is to use nmap against a bunch of known-open ports with full TCP connects and the same ports with standard SYN-only), see the below section about SYN-cookie evasion as well as the even-further section on using tcptrace to detect such issues.

Scan a few UDP ports, but check with a few different tools to be sure. Learn how to import Nmap data to MSF in order to leverage hosts -R in modules like empty_udp (but modify the script to remove 1-1024,2049,5060,5061). We aren't checking any low-range ports because of honeypots, intrusion detection, logging, or other inconsistencies at this time. If any UDP ports are open, this knowledge should supplement what we already know about the live TCP ports on this network. If, because of past knowledge about the target types (from OS or version detection) or target environment, you feel that you could gain more knowledge by scanning for IP protocols such as SCTP, ICMP, IGMP, or otherwise -- then, be careful, consider the consequences, and send out a few probes to verify or build on that knowledge.

  --max-rate 100 --max-retries 0 --randomize-hosts --reason -Pn -sUV --version-all -p500,523,623,1604,1645,1812,5353,5632,6481,6502,10080,17185

  unicornscan 10.0.0.0/24:500,523,1604,1701,1812,2000,3478,5353,5632,10080-10081 -Iv -mU

  for i in ike db2 citrix net-support netop ; do udp-proto-scanner.pl -p $i 10.0.0.0/24 ; done

  -T2 --scan-delay 1s --max-retries 0 --randomize-hosts --reason -n -Pn -sO -p132

  --max-rate 400 --max-retries 0 --randomize-hosts --reason -n -Pn -sY -p1167,1812,1813,2225,2427,2904,2905,2944,2945,3097,3565,3863,3864,3868,4739,4740,5090,5091,5672,5675,6704,6705,6706,7626,8471,9082,9084,9900,9901,9902,14001,20049,29118,29168,29169,36412,36422

  -T2 --scan-delay 1s --max-retries 0 --randomize-hosts --reason -n -Pn -sO -p1

  -T2 --scan-delay 1s --max-retries 0 --randomize-hosts --send-ip -n -PM -sn

  -T2 --scan-delay 1s --max-retries 0 --randomize-hosts --reason -n -Pn -sO -p2

  -T2 --scan-delay 1s --max-retries 0 --randomize-hosts --send-ip -n -PP -sn

  -T2 --scan-delay 1s --max-retries 0 --randomize-hosts --reason -n -Pn -sO -F --exclude-ports 1,2,6,17,132

  -T2 --scan-delay 1s --max-retries 0 --randomize-hosts --reason -n -Pn -sO --exclude-ports 1,2,6,17,132 --data-length 3

To be absolutely pedantic, run the below on every active host that responded to anything from past scans.

  -T2 --max-scan-delay 90ms --max-retries 9 -v -O --osscan-guess -n --send-ip -PE (or -PP if successful and/or -PM if also successful) -sTUV -pT:(at least one closed port but also one open if possible),U:(as T:) --version-all

After this most-recent run, you must know nearly everything you can about each host, each port -- it should be obvious to you if there is a honeypot or IDS/IPS/IDP/etc. You'll be able to group them into categories even if not absolutely sure, e.g., "probably Cisco", "flavor of Unix", "definitely IP phones or softphones of some kind", or "unknown hosts but these match a certain profile even though they have differing ports open". You feel ready to start vulnerability analysis and exploitation against these hosts and their identified and/or unidentified ports.

You will need to add ports previously found to the following nmap port list so that you get a suitable Nmap XML file for importing into Metasploit or querying with metasploitHelper. Be sure to add TCP/SCTP ports to the "T:" section and UDP ports to the "U:" section.

  --min-rate 100 --max-rate 400 --min-parallelism 16 --max-retries 9 --defeat-rst-ratelimit -sUS -n -Pn -pT:0,1,19,42,49,85,105,111,143,264,402,444,446,502,515,631,689,705,783,888,910,912,921,998,1000,1099,1211,1220,1533,1582,1617,1755,1811,1900,2000,2001,2067,2100,2103,2207,2362,2380,2525,2940,2947,2967,3050,3057,3200,3217,3299,3460,3465,3628,3690,3817,4322,4444,4659,4672,4679,5038,5051,5093,5168,5227,5466,5498,5554,5555,6050,6070,6080,6101,6106,6112,6503,6504,6542,6660,6661,6905,6988,7021,7071,7144,7414,7426,7579,7580,7777,7787,8020,8023,8030,8082,8087,8503,8787,8812,8899,9100,9200,9256,9390,9391,9788,9855,10001,10008,10050,10051,10202,10203,10616,10628,11000,11234,12174,12203,12221,12345,12397,12401,13364,13500,16102,18881,19810,20010,20031,20034,20101,20111,20171,20222,22222,23472,26000,26122,27000,27960,28784,30000,31001,32764,34205,34443,38080,38292,40007,41025,41080,41523,41524,44334,44818,46823,46824,50001,50013,55553,57772,62514,65535,U:19,42,49,69,111,161,631,1900,2049,2362,7777 -oX nmap_target1.xml

If you find a good target, you may want to utilize custom Metasploit resources (or "rc") files that consist of notes on modules, their settings, and how to run them. You can find port-number specific rc files here, which can get you on the fast path to a shell. It may require some troubleshooting, but attacking the infrastructure this early on could indicate IPS (network or host) presence or lack thereof. It could also get your IP address blocked, so proceed with caution. You also might want to run some of these port-specific NSE scripts, some of which have important script-args and other tuneables. If you already know for sure that a port is open, or even confident in the target OS/service, then you might as well do something to get more information about their runtime states. Your call, but at this stage in the testing automation you will definitely need to increase the information available to you for decision advantage.

Another possibility is to pivot to the web layer, which typically involves running carbonator after a little nmap and nikto action (N.B., you will want to modify your nikto.conf to modify the user agent to one of a normal web browser and perhaps comment out the two mutate lines). You will also want to discover more hostnames and IP prefixes at this time (domaincrawler.com, fierce, knock, dnsmap, and subbrute will help with subdomains and dnsrecon should handle all of the rest). If you have tons of targets then you may want to use webshot to drop images that you can sort through and triage your target selections. If you definitely know there is an IPS or WAF in place, then you may want to switch tactics.

  -Pn -p 80 --version-all -sV --script "http-waf*",http-devframework,http-enum,http-vhosts -oG - | nikto.pl -h - -Tuning x04689c -D 1 -output nikto.xml

  -Pn -p 443 --version-all -sV --script "http-waf*",http-devframework,http-enum,http-vhosts -oG - | nikto.pl -h - -ssl -Tuning x04689c -D 1 -output niktotls.xml

Now is the time to engage any anti-IDS mechanisms (e.g., sniffjoke, fragroute, and Evader) or run any last-minute SYN-cookie, IDS, IPS, and WAF detection checks. Finally, go for it! No sense in scanning a single port or small set of ports at this point.

  --script banner-plus --min-rate 450 --min-parallelism 20 --max-retries 5 --defeat-rst-ratelimit -n -Pn -p-

  unicornscan 10.0.0.0/24:a -D -L 20 -r 450 -Iv -mU

  unicornscan 10.0.0.0/24:9,42,49,67,88,135,139,162,213,259,260,407,445,464,514,517-523,546,631,657,826,829,1069,1194,1558,1645-1646,1900,1967,2055,2362,2427,2727,2746,3001,3283,3401,3544,4045,4500,4665,5060,5350,5351,5355,5405,5432,6481,6502,8905,8906,9999,17185,18233,26198,27444,32822-32823,34555,41250,47545,49152,49599,54321 -r 450 -Iv -mU

The above rates (--min-rate in nmap and -r in unicornscan) are measured in packets-per second (pps) and can be modified up to 10000 when on a local network or other ideal conditions. There are patches to change nmap's scan rate dynamically (interactively) here (amazing when combined with tcptrace.org looking for retransmissions and modifying either the min-rate, max-rate, interactive equivalents, min-parallelism, min-hostgroup, or max-retries until maximum bandwidth is acheived). It is difficult to get nmap into best-fit approach for bulk SYN or UDP scanning, even when using pedantic min-hostgroup, min-parallelism, and min-rate parameters. This is why many people turn to unicornscan, zmap, or masscan. If your target networks and services have very reliable and consistent round-trip times in their server responses (or if you have the time and patience to figure out the network characteristics), nmap/dnmap may be your best bet for tooling consistency if nothing else.

You may need to verify new IPs, hostnames, or ports that you haven't seen in the past (such as the honeypot ports we avoided earlier, including SCTP ports 5060-5061 with -sY). Go back to the stage where you ran qscan and retry scenarios using the new information. Continue to check for honeypots by using additional techniques such as Metasploit's detect_kippo module. Be sure to rerun metasploitHelper if applicable. Keep track of all of your information, perhaps by using Dradis, MagicTree, discover.sh XML to CSV conversions, Lunarline VSC, Prolific Solutions proVM Auditor, Cisco Kvasir, or FishNet LAIR. These are better alternatives to Notepad, etc because they are penetration-test data aware. Similar to earlier, you may find that the duplicates script helps identify multihomed hosts. Common scenarios include Windows machine with or without SSL/TLS -- or possibly a non-Windows machine running SSH, SSL/TLS, or both (although it is possible that a Windows host could be running SSH, but that's a severely strange corner case).

  --script qscan,duplicates,nbstat,ssl-cert --max-retries 7 -v -O --osscan-guess --max-os-tries 1 --reason -Pn -sSUV --version-all -pT:135,139,443,445,U:137

  --script qscan,duplicates,nbstat --max-retries 7 -v -O --osscan-guess --max-os-tries 1 --reason -Pn -sSUV --version-all -pT:135,139,445,U:137

  --script qscan,duplicates,ssh-hostkey --max-retries 7 -v -O --osscan-guess --max-os-tries 1 --reason -Pn -sV --version-all -p22

  --script qscan,duplicates,ssh-hostkey,ssl-cert --max-retries 7 -v -O --osscan-guess --max-os-tries 1 --reason -Pn -sV --version-all -p22,443

If you find any open ports with services (or apps of any kind) that require any form of authentication, then you will want to read and configure the protocol-specific scripts, but generically your nmap/dnmap command-line arguments should look like:

  --min-rate 100 --max-retries 5 -n -Pn --script brute,creds-summary --script-args unsafe,brute.mode=pass,userdb=usernames.lst,passdb=passwords.lst,brute.firstOnly,brute.guesses=2 --version-all -sV (-sUV or -sUSV, if appropriate)

The above could be performed with dnmap using a different passwords.lst file on each server in order to increase attempts, to brute from different IP addresses, or a variety of other scenario-dependent options.

Finally, let's talk about how nmap/dnmap can really shine -- by bringing it all together after you know that SYN scanning works, you have UDP probes figured out (note that many of the below are missing in the nmap-payloads, nmap-service-probes, Unicornscan etc/payloads.conf, and udp-proto-scanner.conf files -- so you may have to create them manually!) and that IDS/IPS isn't going to be a bother for your automation. Let's say you aren't just on a coffee break, you can't take "just another nap", and your significant other demands some attention and a normal 8-hour sleep routine. Well, fire up nmap/dnmap this way and you'll get some great results for when you come back to the console!

  --min-rate 100 --max-retries 5 --defeat-rst-ratelimit --randomize-hosts --open -Pn -v -O --osscan-guess --max-os-tries 1 -sUSV --version-all --script banner,duplicates,nbstat,ssh-hostkey,ssl-cert,vuln,vulscan,brute,creds-summary --script-args vulns.showall,unsafe,vulscanversiondetection=0,brute.mode=pass,userdb=usernames.lst,passdb=passwords.lst,brute.firstOnly -pT:0,1,19,26,42,49,66,79-81,85,105,111,113,135,139,143,264,389,402,407,443-446,457,465,500,502,512-515,523,524,548,554,587,593,623,631,689,705,783,873,888,902,910,912,921,993,995,998,1000,1026,1050,1080,1099-1100,1128,1158,1167,1211,1220,1241,1337,1344,1352,1433,1521,1533,1581,1582,1604,1617,1720,1723,1755,1811-1813,1900,1944,2000-2001,2067,2100,2103,2202,2207,2225,2301-2302,2362,2375,2380,2381,2383,2427,2525,2628,2869,2904,2905,2940,2944,2945,2947,2967,3000,3010,3031,3037,3050,3057,3097,3128,3200,3217,3260,3299,3306,3389,3460,3465,3478,3500,3565,3628,3632,3689-3690,3780,3790,3817,3863,3864,3868,3872,4000-4002,4100,4322,4369,4444,4567,4659,4672,4679,4739,4740,4848,5000,5019,5038,5040,5051,5060-5061,5090-5091,5093,5168,5222,5227,5250,5353,5357,5432,5466,5498,5554-5555,5560,5631,5632,5666,5672,5675,5679,5800-5802,5814,5850,5900,5920,5984,5985,5986,6000-6005,6050,6060,6070,6080,6101,6106,6112,6346,6347,6379,6405,6481,6503,6504,6542,6660-6661,6666-6667,6704-6706,6905,6988,7000-7002,7019,7021,7071,7080,7144,7181,7210,7272,7414,7426,7443,7510,7579,7580,7626,7634,7770,7777-7778,7787,8000-8001,8008-8010,8014,8020,8023,8028,8030,8040,8080-8082,8085,8087-8091,8095,8140,8161,8180,8200,8222,8300,8400,8443,8471,8500,8503,8776,8787,8812,8834,8880,8888,8899,8980,8999,9000,9002,9060,9080,9082,9084,9090,9100,9160,9191,9200,9256,9292,9390,9391,9443,9495,9788,9855,9900,9901-9902,9990,9999,10000-10001,10008,10050-10051,10202,10203,10616,10628,11000,11211,11234,12000,12174,12203,12221,12345,12397,12401,13364,13500,13722,14001,16102,17185,18881,19150,19810,20010,20031,20034,20049,20101,20111,20171,20222,22222,23472,26000,26122,27000,27017,27960,28784,29118,29168,29169,30000,30718,30821,31001,31337,32764,34205,34443,35871,36412,36422,38080,38292,40007,41025,41080,41523-41524,44334,44443,44818,46823,46824,49152,50000-50001,50013,50030,50060,50070,50075,50090,52822,52869,55553,57772,60010,60030,62514,64623,65535,U:7,9,11,13,17,19,36-37,42,49,53,67,69,88,111,123,135,137,139,161-162,177,213,259,260,407,445,464,500,514,517-521,523,546,555,623,631,657,826,829,921,1069,1194,1434,1558,1604,1645-1646,1701,1812,1900,1967,2000,2049,2055,2221,2302,2362,2427,2727,2746,3001,3283,3401,3478,3544,4045,4104,4500,4665,5060,5350,5351,5353,5355,5405,5432,5555,5632,6481,6502,7001,7004,7777,7983,8905,8906,9999,10080-10081,17185,18233,26198,27444,27960,31337,32767-32774,32822-32823,34555,41250,47545,49152,49599,54321

Just a little effort with nmap can save you a lot of time if you engage with OpenVAS or Metasploit later on. I prefer to run nmap and OpenVAS from within the msfconsole so that all of that data makes it into the MSF database. One could also export tool data to Metasploit-consumable XML, or use a tool like nmap2nessus. An important lesson to learn about vulnerability scanners is that they miss a lot of real-world vulnerabilities. By running nmap/dnmap overnight in the manner described above you will get to see the potential for every single vulnerability path. Most of them won't work at first shot -- nmap/dnmap will tell you that they failed (but not the real "why", even if you think its reason is valid) -- so it is up to you to figure out if the vulnerability can lead to exploitation or not. Go back to the earlier discussion about port-number specific Metasploit and Nmap NSE files, it is even more relevant now. Know the internals of these scripts and how to troubleshoot each line of code that they consist of. A little offset, a small parameter, or a few combinatorial tweaks will grab that shell that every other penetration tester would have missed.


Slash and dash DDOS - what are they trying to do?

This is called a Full Path Disclosure attack. This kind of attack allows the attacker to see the path to the webroot/file. e.g.: /home/omg/htdocs/file/. It keeps on adding slashes like /////  until it gets a file or anything interesting, and won't stop. It floods the site with slashes and special characters and the attacker may not know it but he is DDoSing the site. To stop this kind of attack you can use fail2ban or use nginx and set heavy caching of /.


You might want to read this http://www.x86-64.org/documentation/abi.pdf

Essentially x86 and x64 are different in the way that they work. The new ABI describes the new ways in which it does with Leaf and Non Leaf calls, exception handling and unwinding.

Since the purpose is to essentially overflow - you need to understand the new ABI how its working and where stuff is  as its now in slightly different places to be able to "insert" and "alter".


Is there a way to use multiple firewalls / antivirus for penetration testing?

It would be quite useless to install them at the same time because they will interfere with eachother. Most of the firewall and AV software have components you can't always shut off.

It is better to make a virtual machine you want to test on, clone this VM and then install other AV/firewall software on everyone of them. Then you can do different tests and see which one has a higher detection rate. I find this would be the most practical way as you can easily run multiple virtual machines on one physical machine.

By the way, if you want to check how different AV perform against each other, you can use https://www.virustotal.com/. You can upload a file and it will scan it with different AV's, after that it returns a list of AV that found something and which didn't.


Can you export a report from OWASP ZAP based off a individual website?

The ZAP reporting could definitely do with some improvements.
However you can access all of the alerts via the ZAP API in JSON and XML format.
If you enable the API (via the options) you can then access a URL like:

http://zap/JSON/core/view/alerts/?baseurl=http%3A%2F%2Fwww.example.com%2F&start=&count=

to get all of the alerts reported on www.example.com

FYI we do have a ZAP user group: http://groups.google.com/group/zaproxy-users which is also accessible via the ZAP 'online' menu.
That probably a better forum for ZAP specific questions :)


Which Linux kernel vulnerabilities allow installing a kernel-level rootkit?

Vulnerabilities in the kernel itself, whilst serious, are only part of the story for every day users.

The issue for "normal", "out of the box" installs are in fact vulnerabilities in processes running as root. Since these are trusted they can ask the kernel to do whatever they like - including inserting kernel modules or accessing /dev/kmem.

It is important to understand that, CPU-wise, root processes run as unprivileged processes as far as the CPU is concerned. On x86 we call this ring 3; on ARM processors the CPU modes are User, FIQ, IRQ,
Supervisor, Abort and Undef, where User is the unprivileged level used for processes (all the other modes are in fact privileged ones). Executing processes in User mode cannot modify other processes or the kernel directly; they must ask the kernel first. However, as they are trusted, the kernel does not "say no". So for an ordinary setup, it is enough to compromise a process running as root.

Now, in your setup things are a little different - you've disabled module loading and access to /dev/kmem. To do any serious damage, you need to get your rootkit to execute in supervisor mode (ring 0/any modes that are not User) or be able to manipulate /dev/kmem. Since you cannot modify the boot entries either, this leaves the hardware level as the major threat vector (or ksplice. You mention that on SO; it is most definitely a risk because you allow patching a running kernel with code! kexec is another potential problem because you replace the kernel in place).

So in theory, what you have is significantly more secure.

  Does it mean that the rest of vulnerabilities in that table (e.g., DoS, memory corruption, overflow) cannot be exploited for executing a kernel-level rootkit?

Well, to deal with the last bit first - you don't need to be able to exploit a vulnerability on a "normal" system because you can just insert a kernel module. However, in your case this is practically your only avenue; you would need to find a bug somewhere in the system that either lets you load code or otherwise can be exploited to control the kernel.

Now, on your zero bugs observation - as you say, there are zero known bugs in that time frame. That does not mean there are not bugs. Also, we should caveat this with:

Is this your distribution's kernel? Does it have patches not present in the vanilla kernel? These patches also add risk.
Does your kernel require extra third party code (graphics card drivers, virtualisation drivers)? If so, these also add risk.

Now, about those CVEs - yes, when they say no "code execution" that's what it means. The vulnerabilities present can corrupt memory and perform DoS but cannot actually run malicious code. Take a look at one of the code execution vulnerabilities:

  ...allow remote attackers to cause a denial of service (panic) or possibly execute arbitrary code...

So yes, as it stands there are no known code-execution vulnerabilities in the kernel at the time of writing Update in light of this answer I'm crossing that bit through - it's not clear from the site which entry represents the vanilla kernel and which represent vendor supplied kernels, or indeed what the difference is. Let me caveat that with in whatever definition of the kernel that was there were zero vulnerabilities, which is what I was trying to get at before with talk of vendor supplied patches/third-party code.


How to protect a LAN from WAN with some kind of authentication

Generally, this is done with some sort of bastion host that has access to both networks (internet and intranet). At the simplest, you allow SSH access to the bastion host (for authenticated users only, of course) and then people tunnel through the bastion to reach the internal hosts. That requires setting up SSH tunnels, though, which isn't always convenient or user-friendly. An alternative is to have a login web app on the bastion (or even just use something like TLS mutual authentication with client certificates), and after the user is authenticated the bastion acts as an invisible or reverse proxy, taking requests meant for the back-end hosts and getting their responses, then passing those responses back to the (authenticated) users via a secure connection (probably just HTTPS, unless you're using a non-HTTP protocol in which case you might have to get fancier).

You could also use a VPN server to bridge into the intranet. Users authenticate to the VPN, after which it's basically as though they are on the same local network the VPN server is on (i.e. the same one as your internal services) until the VPN tunnel is closed or broken. There are a number of VPN technologies and they aren't all equally secure (anything using MS-CHAPv2, for example, is pretty easy to break), but most OSes support a number of VPN technologies out of the box, and there's also third-party software like OpenVPN (F/LOSS) or various commercial options.

The bastion host / VPN server, being a bridge between sensitive and untrusted networks, should of course be as hardened as possible. Don't run any more services on it than needed (good advice for any server, really), keep the program logic running on it minimal (to minimize attack surface; no need to by fancy), and so on. Keep it updated, maintain audit logs, and all that good stuff.


How does Windows Server 2008 store local users' passwords?

The SAM database is stored as a file on the local hard disk drive, and it is the authoritative credential store for local accounts on each Windows computer. This database contains all the credentials that are local to that specific computer, including the built-in local Administrator account and any other local accounts for that computer.
  The SAM database stores information on each account, including the user name and the NT password hash. By default, the SAM database does not store LM hashes on current versions of Windows. No password is ever stored in a SAM database—only the password hashes. The NT password hash is an unsalted MD4 hash of the account’s password. This means that if two accounts use an identical password, they will also have an identical NT password hash.

In short, unsalted MD4.


What is the meaning of GnuPG's --list-sigs output?

Certification Levels

There are different classes of certifications. Quoting RFC 4880, OpenPGP, 5.2.1.  Signature Types:

[...]

0x10: Generic certification of a User ID and Public-Key packet.
   The issuer of this certification does not make any particular
   assertion as to how well the certifier has checked that the owner
   of the key is in fact the person described by the User ID.

0x11: Persona certification of a User ID and Public-Key packet.
   The issuer of this certification has not done any verification of
   the claim that the owner of this key is the User ID specified.

0x12: Casual certification of a User ID and Public-Key packet.
   The issuer of this certification has done some casual
   verification of the claim of identity.

0x13: Positive certification of a User ID and Public-Key packet.
   The issuer of this certification has done substantial
   verification of the claim of identity.

Most OpenPGP implementations make their "key signatures" as 0x10
certifications.  Some implementations can issue 0x11-0x13
certifications, but few differentiate between the types.

[...]

GnuPG displays the "normal" 0x10 signatures as sig and the advanced signatures distinguishing between different kinds of certification levels with a number following: 0x11 as sig 1, 0x12 as sig 2 and 0x13 as sig 3. rev indicates revoked signatures.

The output of --list-sigs is also explained by the GnuPG manual pages (man gpg):

--list-sigs
    Same as --list-keys, but the signatures are listed too.  This command has the
    same effect as using --list-keys with --with-sig-list.

    For  each  signature listed, there are several flags in between the "sig" tag
    and keyid. These flags give additional information about each signature. From
    left  to  right,  they  are  the numbers 1-3 for certificate check level (see
    --ask-cert-level), "L" for a local or non-exportable signature (see  --lsign-
    key), "R" for a nonRevocable signature (see the --edit-key command "nrsign"),
    "P" for a signature that contains a policy URL (see  --cert-policy-url),  "N"
    for  a  signature  that contains a notation (see --cert-notation), "X" for an
    eXpired signature (see --ask-cert-expire), and the numbers 1-9 or "T" for  10
    and  above  to  indicate  trust  signature levels (see the --edit-key command
    "tsign").

Vagueness

Also note the first paragraph of the specification's section, which indicates there is no general, rigid definition of the certification levels:

  There are a number of possible meanings for a signature, which are
     indicated in a signature type octet in any given signature.  Please
     note that the vagueness of these meanings is not a flaw, but a
     feature of the system.  Because OpenPGP places final authority for
     validity upon the receiver of a signature, it may be that one
     signer's casual act might be more rigorous than some other
     authority's positive act. [...]

Because of this, some people post certification policies. I provided some discussion in What are you saying when you sign a PGP key?


Whilst no single layer of security can provide complete protection from attack, adding a layer of containerization/virtualization to a solution adds a barrier which an attacker would have to overcome to attack the host system.

In the case of Docker on Windows (so running linux programs on a windows host), it makes use of Hyper-V virtualization so an attacker, to successfully compromise the application, would have to break out of both the container and the Hyper-V VM to compromise the underlying host.


What security threats do tradesmen face in their use of IT?

[This is a very general answer, pending more detail in the question]

So you're asking for help doing a security risk assessment specific to the electrician profession. I'm no expert in electrical work, but here's some things off the top of my head to get you thinking in the right direction, not by any means exhaustive:

Physical security

Leaving their truck unattended in odd locations.
Entering unknown homes / buildings
Connecting their equiment to potentially malicious / malwary circiuts? (seems low risk, I'm scraping the bottom here...)

Information security

Make a list of sensitive information they handle and classify how sensitive it is, ex.:

Schedule of where they will be at a given time [medium]
Customer addresses [low]
Customer billing information, possibly including credit card numbers [high]
Alarm codes or key locations to enter a customer's home or building [High]
Diagrams or schematics of customer buildings [high]
etc

Make a list of ways this information is stored:

Paper
On phone (in sms)
On phone (in company app)
On Laptop (in Word documents)
On Laptop (in login-protected web site)
etc

Make a list of ways this information could be stolen, copied, or tampered with, and assess its risk:

Paper left in truck
Clipboard left on table while they poke their head into something
Phone stolen (phone encrypted and password protected?)
Laptop stolen (laptop encrypted and password protected?)
Connection between laptop and server intercepted (using https?)
Customer shoulder-surfs info they shouldn't see from phone / laptop screen (including passwords, which raises the risk of phone / laptop theft).
etc


AES-256-CBC encryption IV vs salt when encrypting files with a secret key

As stated in this thread

  The OpenSSL developers preferred to derive the IV from the password, just like the key (i.e. they produce from the password a long sequence, which they split in two, one half being the encryption key, the other half being the IV).

The IV does not need to be provided for decryption since OpenSSL derives it from the password. The thread also mentions some drawbacks of using OpenSSL's file encryption method which is worth considering, like not having a MAC to verify the integrity of the encrypted file.


Does SSL communicate automatically using the most secure protocol available?

The SSL handshake ensures that the best protocol version supported by both client and server is chosen:
When the client starts the handshake it tells the server the best protocol version it supports. The server then responds with the best protocol version it supports which is equal or lower to the clients protocol version. The client will close the connection if the servers version is too low. Otherwise both continue with the best common version.


It's very possible:

texttexttext=function(){};alert(document.cookie);

Would give you execution of your code, regardless of what the string literal is.  You just make it into a unused function - and you execute everything after that.

Edit: plus - you can often use single quotes as a substitute for double quotes.


How to investigate an unknown 1.5GB file named "sudo" in my Linux home directory?

You probably made it by accident with a botched shell command. I've done stuff like that myself. As a result it is probably filled with innocuous data. Here are a few reasons why I would guess it is not malicious:

1.5 GB would be an extremely large virus. Since viruses are usually transmitted over a network, smaller is better.
It isn't executable.
Malware typically hides much better than this.
file thinks it is just a data file.

Of course none of that proves that it isn't malicious (a.k.a. viruses don't have to be small, just because it isn't executable doesn't mean it might not be part of a malicious payload, and sometimes they don't bother hiding), but I suspect this is harmless. This is probably too old, but I would see if your bash history goes to the day/time in question.

I realize I haven't given you any hints on how to analyze the file, but you've already hit the main helpers (file and strings), and they haven't helped!  A file filled with random data from an errant command would explain what you are seeing, and likely has a better chance of generating a file named sudo in your home directory than malware does, IMO.


This prompted me to download an authenticator by DUO security

This was merely a suggested app. It was basically an ad.

It now noticed I had installed the DUO authenticator, but instead
opened the Microsoft authenticator.

No, it didn't. I do not have DUO installed, but on my Instagram, when I tried to set up 2FA, it mentioned DUO, but it opened my Google Authenticator. It looks like the DUO mention is hard-coded on that page of the app.

could one put a fake authenticator (instead of the Microsoft one) on a
phone and fool instagram in using the fake authenticator and thus
extracting user login/password

Yes, it would be possible to put a fake 2FA app on a phone that might be recognised by another app. No, the app is not tied to the password, so there would be no risk to the password.


The Correctness of the "We Don't Track" Statement While Being on a Third-Party Cloud Platform

This is not a direct answer to you question but :
The "company" says to you : "We don't track" AND the third-party says to the "company" :"We don't track".
You can trust both but never in "THEY don't track"


Anyone who is watching network traffic on my web app can see the token
  (in headers) and can copy it and form their own malicious calls.

That is correct.  This is why you would want to make sure you use a secure connection (HTTPS in the URL), which will prevent man in the middle attacks.


Why does UUID v4 have the format xxxxxxxx-xxxx-4xxx-zxxx-xxxxxxxxxxxx?

Variants and Versions:

A UUID has variants and versions.

The 4 in this case tells you, that it is the version 4. Other versions range from  1 to 5.

Those versions have variants 8, 9, A and B, therefore the z in your UUID tells you which variant it is.

The variant is used for telling which layout the UUID has. Variants are also important when it comes to backwards compatibility.

Lenght of the strings:

As to why the strings have different lengths, a UUID has a certain parts, that you can use to generate a UUID depending on various parameters:

UUID =  time-low "-"
        time-mid "-"
        time-high-and-version "-"
        clock-seq-and-reserved | clock-seq-low "-"
        node

time-low has 16 bits, time-mid has 8 bits, ... The lengths were historically constructed so that they fit into the following scheme:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          time_low                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       time_mid                |         time_hi_and_version   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|clk_seq_hi_res |  clk_seq_low  |         node (0-1)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         node (2-5)                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So this should give you an idea, why the lengths of the strings are different.

UUIDs and security:

Usually UUIDs are not secure: https://littlemaninmyhead.wordpress.com/2015/11/22/cautionary-note-uuids-should-generally-not-be-used-for-authentication-tokens/ ... and see Michael Kjörling's comment for further examples and explanations.

UUIDs were not built to be cryptohraphically secure, so you should use something else made especially for that purpose.

The RFC for UUIDs even has a section, about security, warning users to misuse UUIDs for that:

  Security Considerations

  Do not assume that UUIDs are hard to guess; they should not be used
  as security capabilities (identifiers whose mere possession grants
  access), for example.  A predictable random number source will
  exacerbate the situation.

See the RFC for the technical details: https://tools.ietf.org/html/rfc4122


It is impossible to offer a definitive answer given the current information (call it an undecidable problem, if you prefer). Both of your suggestions are possible: it could have been a chance, or the spam email could have been triggered by your searches.
As some comments above mentioned, your activities online are monitored and targeted by advertisers. This is (unfortunately) the norm, so your computer can hardly be considered "breached".

No alerts from Anti-Virus.

This is expected: receiving spam emails is not malware. An antimalware solution cannot raise this as a positive event, unless the email itself contained some malware.

I didn't click on anything there.

Generally speaking, it's enough for you to view the ad. The ad networks tracks who clicks on what ad, but also who and how many people actually see the ad. The only way to lower the chance of this happening is to run an adblocker in your browser (or, arguably even better, at the network level).


Microsoft SQL server 2000 sp3a - isn't it oudated?

There could be a few factors.

Like ekaj stated, price could be a prohibitive factor as some companies might not be able to afford or justify the cost of upgrading to the newer version, particularly if they do not take security threats seriously.

Another factor could be the need for backward compatibility. I do not have experience with the Microsoft SQL server, so it might not apply in this particular case, but sometimes upgrading software can break compatibility with existing products/solutions. The company in question might not have the people with the right expertise to ensure that the upgrade does not have any compatibility issues.

A quick search of CVE databases turns up a few potential vulnerabilities which may or may not be serious enough to warrant an upgrade.


For high entropy credentials, is SHA256 hashing good enough?

Yes. Salt is used to prevent precomputation attacks, but random 256 bit strings are too large for precomputation. Slow hash functions with many iterations are meant to slow down dictionary attacks, but random 256 bit strings are too big for a dictionary or for exhaustive testing. So a single SHA256 hash is secure for long, cryptographically secure random inputs.


How practicable is application whitelisting

If you whitelist a directory, then sure, any malware in that directory can run.

That's why you don't whitelist directories.  Instead, you whitelist programs, and you take precautions to ensure those progrms aren't modified.  For example, instead of whitelisting "c:\Program Files\Internet Explorer", you whitelist "c:\Program Files\Internet Explorer\iexplore.exe with SHA-256 checksum c09bc04058f1e2d4eae481490b998381486311e02ff782e99383c16d77c1b3bc".


Very little work has been written on OS X security, especially malware issues. The book Incident Response & Computer Forensics, Third Edition, 3rd Edition's Chapter 13 covers investigation of Mac OS X system integrity breaches. Of perhaps primary interest would be the section on system auditing which includes information on OpenBSM configuration and analysis.

The best recent work is from Yelp with the FOSS project -- https://github.com/Yelp/osxcollector -- based on the original -- https://github.com/jipegit/OSXAuditor

They link out to some additional resources on this page -- http://www.mac4n6.com/resources/

Another book, The Art of Memory Forensics: Detecting Malware and Threats in Windows, Linux, and Mac Memory, covers OS X malware from a memory capture assessment perspective. It links out to a few blogs, such as ones that cover techniques and others that provide case studies and downloads of live OS X malware samples.

Be sure to check out the recent news from this year's BlackHat US and DEF CON. Stefan Esser's public exploit was discovered in the wild shortly thereafter and OS X malware made a lot of fanfare during that time period, including a more-recent one from Luca Todesco.


For a simple solution I would say to implement an exponentially increasing delay per user per IP address.

Required delay between attempts 1 and 2 from IP a.b.c.d for user x: 1 seconds

...attempts 2 and 3: 2 seconds

...attempts 3 and 4: 4 seconds

...

...attempts 7 and 8: 1 minute 4 seconds

That way an adversary can't DoS access from an IP address or an individual user and you've pretty effectively mitigated brute force because the delay rapidly becomes unreasonable. Even if they have access to a large number of IP addresses, there likely wouldn't be enough to brute force the password keyspace, just some dictionary words.

This would allow for brute-forcing users with the same password, but if you're seeing that number of failed requests you should probably flag it anyway (in that a user with multiple bad attempts is probably not uncommon, but multiple users with bad attempts from the same IP address in rapid succession would be suspicious).


What are the drawbacks to automatically deleting web server access logs?

Disabling logs may deny you the ability to properly audit security events when they are noticed. If erasing IP addresses is a concern, there is an approach that will allow you to retain useful information without storing the actual IP address - tokenisation. You could convert the IP addresses to opaque hashes that allow you to track a source IP's activity in the logs without knowing the exact IP. If an IP is found to be behaving in a malicious way, you could then check recent logs/new connections for any IP address that hash to the same output. At the least, you will have a better chance of reconstructing what went on.

You may also wish to consider log aggregation solutions.


Why not signing a certificate with more than one Certification Authority

I don't see why the proposed model would not be better but maybe I miss something ?

The approach of requiring multiple valid trust anchors instead of one is a sound approach in theory and is actually used in practice within OpenPGP. There the trust into a key depends on how many trusted endorsers have signed the key and how much trust one itself has into these trusted endorsers etc - a web of trust.
Unfortunately, while this concept is useful in theory, it adds lots of complexity on multiple levels. The technical implementation is likely less a problem as the example of OpenPGP shows. In the simplest case the whole process of CA's would work like before but the TLS server would send multiple leaf certificates with multiple chains like suggested in Why do we not require websites to have several independent certificates?.  See also Multiple CAs signing a single Cert/CSR?.
But apart from the technical issues: how many certificates should be required in which context and from which CA. Are there any CA which are more trusted than others, depending on the context (like CA from China are less trust in US and CA from US are less trusted in China). How many less trusted CA together can achieve the same trust level as one more trusted CA etc. One cannot expect this decision from most end users, so browser makers and certificate authorities have to make the decision for the end user - with many discussions and likely also nasty politics involved. In other words: there is lots of organizational complexity on top of the technical problem and this is likely the harder one to solve.
And what is actually the gain for the end user? If it is about reducing the risk into a single CA (i.e. compromise) - there are other approaches for this. With CAA one can restrict which CA is allowed to issue certificates for one owns domain (although this is only checked by the CA itself), Certificate Transparency ensures that no "hidden" certificates are in use but everything is done in the public,  blacklisting of CA or sub-CA which showed problems contains the impact of a compromise. This is far from perfect, but much less complex and disruptive then the proposed approach.
In summary: the approach by itself is sound. Implementation in practice is limited by technical and organizational problems. Also additional hardening of the PKI system was done by other approaches already so that there is less need to implement such approach.


What does working in cybersecurity look like?

The term cyber-security is large enough to represent many different sub-fields. As in many fields, there are theoretical approaches and more practical ones.

For instance, I now work at the Center for Cybercrime and Computer Security, and within the same place, there are people working on cryptographic protocols (quite theoretical/maths), people working on collaboration with the police, e.g., to work with battered women, people working on usability aspect of security, people working on quantitative techniques (probability/uncertainty) of security mechanisms, and that's just on top of my head.

If you take a look at the Information Security Group, where I was working before, you'll find different profiles, and different aspects of cyber-security. In both of these examples, and in many others, you can both do a Master and a PhD. And, of course, I'm only talking here about places I know for working there, but there are plenty of them in the world.

It's quite frequent that security groups are started by people whose primary background is not in security, and that's why there are many approaches: algebra, formal methods, quantitative, psychological, distributed systems, operating systems, networks, etc. So, to answer your question precisely, yes, there are many places where to get a proper formation in cyber-security, and you will probably find one that suits you best.

EDIT: As another example of great place to look at, since your profile indicates you're in Switzerland, the ETH Zurich is considered as one of the top places in the world, and their Information Security Master is probably very interesting (although with perhaps a more theoretical/academic aspect rather than concrete/applied).


Are Content-Security-Policy nonces designed for production use, or as a stop-gap when implementing a CSP?

In so far as major browser support and working as advertised, then yes CSP nonce is suitable for production use. For cases where business reasons prevent changes to the website then it is still superior to not having a CSP or one that allows all unsafe-inline sources.

However as you hint at, using inline sources should be avoided where possible and nonces are meant as one way to work around the problem. The CSP specification even goes to note:

  Using a nonce to whitelist inline script or style is less secure than not using a nonce, as nonces override the restrictions in the directive in which they are present. An attacker who can gain access to the nonce can execute whatever script they like, whenever they like. That said, nonces provide a substantial improvement over 'unsafe-inline' when layering a content security policy on top of old code. When considering 'unsafe-inline', authors are encouraged to consider nonces (or hashes) instead.

One of the biggest security benefits of CSP is exactly to prevent the running of inline scripts and inline styles. Hence the nonce and hash solutions should only be used if you really have no other choice.


Do mobile phones automatically connect to spoofed cellular tower antenna?

Yes, your phone will not be able to differentiate between a regular and a fake cell tower and will connect to whichever has the strongest signal.

As for the encryption, not really sure what you mean. Since the attacker owns the base station, he can monitor all the traffic going through there. The over-the-air encryption between the phone and the fake base station doesn't really matter here - the only traffic that an attacker cannot see is data that is end-to-end encrypted between the phone and, say, a web service it accesses.


OWASP (The Open Web Application Security Project) provides a lot of resources for developers and pen-testers.

  OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security.

To the degree that web applications qualify as web services, are accompanied by web service APIs, or can be hardened/probed using the same techniques as web services, OWASP is a great resource.

You might start at their Web Services page.


CSP allowing Base64 encoded images without unsafe-eval

A base64 encoded image inside a <img src="data:..."> will not execute any script, no matter if unsafe-eval is enabled or not. It will only display the image. It does not matter if the image contains any script since the browser will  treat it only like a dumb image inside the context of the img tag.


If service is http over TLS/SSL is communication completely safe?

No. The extra Root Certificates in your browser's (or computer's) key store/wallet can be used to engage in Man-in-the-middle attacks should anyone in the Internet providing chain be able to get a signed certificate for the web server you're connecting to from one of those extra Root CAs.  For example, say you've got a Turkish Root CA in your key store on your Mac.  If your ISP can get the Turkish Root Authority to issue a server certificate for the host www.whatsapp.com (bribe, intelligence service in Turkey) then your connection from your computer or phone to whatsapp.com can be routed to a middle server for an MITM attack.

Remove those untrusted Root CAs and you'll be safer. You may have a problem with the new logjam attack, which is a cipher suite downgrade attack, or with using an algorithm that cryptographers now strongly believe can be broken (a handful of commonly used DH keys of length 1024 bits or lower).

See these answers on How NSA can break Web and VPN sessions and MITM attack against SSL.

I've never studied Skype's security.


What data is sent between an NFC/BTLE FIDO U2F device and Chrome (or other agent)?

Regardless transport (NFC, USB, BLE) The U2F client (Chrome) merely repacks and forwards the challenge to the device. All crypto is done in the device's secure element.

Basically, the device signs the challenge (provided by the relying party), along with some meta data (provided by the client) such as what URL the browser was currently visiting, etc (to prevent phishing).


The bad press Java got in the past years which might lead you to the preconception that the whole technology is a "horrendous piece of malware-magnet" applied mostly to the Java browser plugin. This plugin allows to run Java applications embedded in websites (Java Applets). Applets are supposed to be sandboxed so that they can't do any harm, but that sandboxing concept wasn't always as thorough as it should have been. This allowed java applets embedded in malicious websites to do things they were not supposed to do on the visitor's computer, in some cases even install malware.

When you install Minecraft, its Java Runtime Environment doesn't install the Java browser plugin in any web browser you use, so you won't get exposed to drive-by malware in form of malicious Java applets while web browsing.

A JRE being somewhere on a system doesn't provide much attack surface. When an attacker obtained the means to get their malicious Java application onto your computer and invoke the JRE to run it, then they are very likely also able to run any non-Java application they want.


Is there any way to force browse HTTP if all the traffic is redirected to HTTPS?

A redirect (to https, or anywhere else) is a "302" return code from the server

https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

which your browser honors, and then re-requests the redirected page.

If "nikto [...scans...] the site at port 80 [and] list a lot of vulnerable links"

then the server is still returning a page.  You would need to use a modified web client which doesn't follow the "302" redirect, the way nikto apparently isn't.

That still seems odd though, as most web serves which send a redirect do not also send the original/old page.  You may want to be sure nikto isn't just showing you the contents of the page after silently following the redirect to the https site.

Finally, the software running port 80 and 443 might be the same.  A single web server can handle both http and https connections, and serve out the same or different pages in response


Yes.

This exposes an whether an account exists for that email address. An attacker would know that is a valid account.

This is really a usability versus security question.

Do you want your site to deceive users if an account doesn't exist and not give up information about which emails have accounts? Then claim a mail was sent.

Or do you want to leak whether an account exists or not and give a more meaningful message to users? Then tell users they haven't registered with the service yet.

You need to decide what is more important, the usability or security.


User-defined HTML
You're attempting to sanitize user input by blacklisting things you don't want to allow.  Unfortunately, especially given the very large list of options for HTML5, it's quite easy to miss something.  Missing something will result in a potentially dangerous XSS vulnerability, which you really don't want.  To pick some random examples off the top of my head:

Do you know that SVG tags can execute scripts in some (limited) circumstances?
In your list of on event attributes you banned, did you make sure and get the onbounce event attribute of the obsolete (but still available) marquee tag?
Are you going to make sure and keep track of any changes to the HTML spec that might roll out over the next X years, just in case one might add a dangerous tag/event?

There can be so many gotchas that securing input with a blacklist is nearly impossible.  Moreover, you're approaching the problem from the wrong perspective.  In security the approach you want to start with is the Principle of Least Privilege.  Rather than asking, "what should I stop my users from doing", it's much safer to ask, "What should I allow them to do?".  Therefore you need a two step process:
1. Robust Parser.  You need a very robust parser.  This is surprisingly difficult because browsers are so very forgiving when it comes to parsing HTML.  If an attacker gives you bad HTML and your parser stops trying and says, "There's no HTML here - you're safe!", but the browser takes the same input, takes some guesses at what the HTML was supposed to be, and ends up with something malicious, you have an XSS vulnerability.  This is even more difficult that it sounds because different browsers can apply different "corrections" when processing HTML input, making the already difficult task of parsing HTML reliably even more difficult.
As an example of browsers playing fast an loose with HTML, you can save this HTML to a file and load it in your browser:

<img src="1" <table onerror="alert(1)"

hi

If you load it up with Chrome and inspect element on the page, you'll see that the browser actually rendered this (probably depends on your version though):
<img src="1" <table="" onerror="alert(1)"
hi

That's an image tag with an active XSS payload (which is mildly obfuscated by the fact that a table tag and the p turned into meaningless attributes), a literal string hi, an empty p tag, and an empty table tag.  The end result is quite different than the input.  I haven't tried very hard to hide the payload, but would your parser have understood it the same way?  Perhaps your parser would have tried to ignore the img tag inside of the table tag since anything not in a td tag would technically be illegal.  Maybe your parser would have been confused by the <table inside the img tag and ignored the onerror since a table tag doesn't technically have events.  As it turns out though, none of that stopped the browser from executing my javascript payload.  Would your parser have caught it?
2. Whitelist allowed tags and attributes Once you've parsed the user's HTML, you don't want to compare with a blacklist and remove disallowed tags/attributes.  Instead you want to compare to a whitelist and remove anything that you haven't specifically vetted and approved as safe.  This puts your security on much stronger footing and - let's be honest - do you really want your users to use the marquee tag anyway?
Most importantly though, building a robust HTML parser is surprisingly difficult.  If you try to do it yourself you'll spend a lot of time and probably get a lot wrong.  Under normal circumstances, you'll be much better off just finding a well supported third party library to use.
Alternate Suggestion
A different tactic I would normally recommend would be to not let user's use HTML at all.  Rather, allow a more limited language (like the markdown used for writing questions and answers in stack overflow).  The more limited language specification makes writing a parser much easier and less error-prone, and the process of converting markdown to HTML makes it easier to guarantee "safeness" (note: easier, not guaranteed - markdown to HTML converters still suffer from occasional XSS vulnerabilities).  There is a slight disadvantage that it limits the sort of formatting options users have (although I don't really consider that a disadvantage under most circumstances), but you also have a nice advantage that markdown parsers and HTML-converters are available in a wide variety of languages.  A more limited option like this is typically a good trade off between usability and security.  You can even add in a WYSIWYG editor that builds the markdown for users.