Why is GRE tunneling is needed when having a BGP based solution against DDoS? I understand that GRE tunneling is very handy when sending the data back to the client after scrubbing because it's designed to ensure that the data is sent reliably by initiating a private point-to-point connection. My question is, why is this needed? Why can't the data be sent 'normally', via the internet? Will data get lost if sent via the normal way? Is it to be sure that the data isn't intercepted over the internet?

This is done to prevent routing loops. BGP isused to reroute traffic towards the target IP range via the scrubbing center, but then the scrubbing center cannot use the public routing to reach the final destination, since those routes would point to itself.

By creating a GRE tunnel you can make sure there's a direct (tunneled) path without needing to rely on public routing and various networks between the attacked network and the scrubbing center. BGP can be used via that GRE tunnel to make sure the scrubbing center knows where to deliver the scrubbed traffic.

Instead of a GRE tunnel, a direct physical link or layer 2 path could be used as well, but often that's more expensive than using a GRE tunnel.

So to answer your final question, no, it has nothing to do with interception. GRE does not provide any security for that either, since GRE traffic is only encapsulated, not encrypted.


Security of cellular-connected devices The EFF Secure Messaging Scorecard lists a number of apps that meet all of its security criteria.  So assuming that end-to-end encryption is accessible for the majority of people in countries in which encryption is legal, how do intelligence agencies listen in?  It seems like in the case of a high-value target (Alice), the strategy would be to hack into Alice's endpoint.

I'm wondering about the security of mobile phones versus laptops.  Laptop users have a bunch of choices to increase their security (use Linux instead of Windows, use TOR, use TAILS, etc.).  But after reading this article I'm thinking about how cellular device users are stuck with a device with a baseband chip running a propriety O.S. that is in constant communication with a cellular company that is forced to cooperate with intelligence agencies.  In other words, can't the NSA just ask Verizon to send Alice's iPhone malicious data via cellular that will cause her baseband chip to read something from memory (like her private key) and send that back?

In light of this concern, is usage of a device NOT connected to a cellular network preferable for keeping your communications private?

Most phones have the cellular network interface share some memory with the main processor (I wonder if it's cooperation between manufacturers and carriers/law enforcement to give them potential access to the phones?). As a result, a compromised/malicious cellular NIC could take over the entire machine.

There are ways to mitigate this without completely disconnecting from the cellular network though. For example, this guide explains how to harden an Android tablet, and they use an external cellular modem connected over Wi-Fi (which limits its ability to do nasty stuff). USB dongles are also safe assuming you protect against BadUSB (if the dongle suddenly decides to turn into a "keyboard" and starts typing in malicious stuff). A separate mobile phone used as a hotspot would also be safe.

Basically all you need to do is get an "external" cellular modem, something that doesn't directly have access to your system's memory. Once that's done, the rest is standard network security techniques which are fairly well understood and there are many questions on the subject already (and a phone in this case is no longer that different from a standard networked computer).


Why are all cookies with same name included when asked by server? Doesn't it raise cookie's integrity violation chances? Cookies are set and stored as a name/domain/path to value attributes mapping, but only name-value pairs are presented to both JavaScript and web servers. This asymmetry allows cookies with the same name but different domain and/or path scopes to be written into browser; a subsequent reader can read out all same name cookies together, yet cannot distinguish them because the other attributes such as path are not presented in the reading process.

The Same Origin Policy creates a security boundary for client-side data defined by protocol, port and domain.

The Same Origin Policy for cookies is slightly looser, allowing the protocol and port to differ, and the domain can optionally share cookies with subdomains. Note, as you say, this is optional for the cookie writer only, not the reader.

That is, foo.example.com can write a cookie that example.com can read, even if it doesn't want to.

The solution to this is to only have one application per domain. That way two applications cannot set cookies for each other.

e.g. Vulnerable

Application running on example.com/foo which can set set cookies for example.com/bar

Not Vulnerable

Application running on foo.example.com - this is completely isolated from bar.example.org


Something is changing my hosts file without asking First: I can't find any information on this phenomenon, not anywhere on the net.

I don't know which application does it, but something in my Windows 7 Home Premium system (fully updated & legal) updates my hosts file. I have UAC enabled. To edit my hosts file, I have to run Notepad with admin privileges or else I can't save my file.

The line 127.0.0.1 ad.doubleclick.net has disappeared several times now. It looks like that is the only line to which this happens. I have other lines in the same file, and they are left untouched.

I suspect Google Chrome to be responsible for this, since the Google Updater probably has the permissions to modify system files - and it's in their interest to load their crap, but I am not sure. While I understand that I use their services and that ads pay for those services, I don't like the idea of software violating my system like that. And I am surprised that it's even possible, I thought Chrome installed within the user profile and didn't need system write access to install.

Can anyone else confirm this issue? Any experience with similar things happening to the hosts file?

Edit: I have ProcessMonitor running with a filter on the hosts file. Let's see what I can find... thanks for the suggestion, I hadn't thought of it initially.

Update: This morning, Process Monitor showed a bunch of file activity. And 127.0.0.1 ad.doubleclick.net is gone! It looks like Windows Defender did it. Read the Process Monitor log here:  http://pastebin.com/eJTf5qWs

Use Process Monitor with a filter to watch the hosts file. Run it long enough and you will see everything that changes the file.

http://technet.microsoft.com/en-us/sysinternals/bb896645


Comodo firewall: why an app set to "blocked" is in the "listen" state in network? Did I make a mistake, or is the Comodo firewall buggy?
I checked the blocked mode, it's supposed to block in/out requests.
(and by the way I don't understand why the "local address" is set to Adobe since the app that is supposed to be blocked has nothing to do with Adobe.)

The firewall blocks network traffic. Any process can be active and listening for network traffic regardless of what's going on with the firewall. It's like hoping for the phone to ring, but it never does.

If the firewall blocks traffic, then the listening process will never make any connections, but that does not stop the process from listening.

So, there is no bug and nothing is wrong. That process, if the firewall works, will simply never reach an 'established' state.


Security issues with concurrent sessions in iOS app and Safari browser We have two ways a user can buy products on our e-store. We have a mobile native app for iPhones and a mobile optimized browser experience from an iPhone default browser (i.e. Safari).

The iOS (iPhone) app establishes a HTTP(s) session on the server side after successful user login/authentication. Now at the same time the user can launch Safari browser on the iPhone or click on a product link that launches Safari browser, login and a HTTP(s) session is established on the server side. There could be two sessions concurrently established for the same user and same device. Sessions have idle time out of 20 mins and are independent of each other. My question is does this present any security risks because of two concurrent (separate) sessions for the same user from two different end points (iOS app & Safari browser) from same device?

No security issues will be caused due to two concurrent sessions on same device. As far as your server is concerned, the two sessions are two client endpoints it serves, doesn't matter where.


Is cloud storage safe to use if I use gpg and is my method secure? I have to regularly back up data and use google drive and sometimes sync.com. I have lots of images, videos and spreadsheets and sometimes my backups are 4 or 5 GB.

I typically add all the files to a folder. Then I use tar to create a single tar ball. Once the Tarball is created I use gpg -c with AES-256 encryption. For the password I use LastPass to generate a 100 character password consisting of lowercase, uppercase, numbers and some special characters.  I create a secure note in last pass documenting the password and file location. Then I use the split command to divide the .gpg file into chunks of 50MB rather than storing one huge file.

Then I upload the files to my sync or google drive where I have large amounts of data.

My last pass account is protected by a 30 character passphrase  which I can remember easily but it contains some numbers and special characters.

I specifically want to use sync.com or something equivalent rather than storing on my local Hard drive as I think the data is less likely to be lost or damaged.

Is my procedure of securing my data and photos secure? I don't want google employees or sync employees looking through my holiday photos.

Yes, this secures your data from Google, sync.com and from anyone trying to grab your data while it is in transit to Google.

Three things to think about:

Your lastpass password is far shorter and contains (the way it sounds) far less entropy than the one that protects your gpg tar file. Someone attacking this scheme would therefore most likely attack your lastpass account (since now it's public knowledge that your password there is weaker).
It sounds like you're using GPG in symmetric encryption mode (more on an alternative at the end of my answer). So: What's to stop a disgrunted lastpass employee with a bit of technical knowledge to steal your gpg password and sell it to an interested party at Google? Or if you find that problem too theoretical, what about an attack on the lastpass service which steals millions of user passwords and publishes them? Since you've conveniently added a note about where the encrypted files are located, you're basically handing your encrypted files over to anyone who can access your Lastpass account (well, in theory, anyway - he or she still has to get your Google Drive password...)
You're splitting your file into multiple files. Why exactly are you doing this? If you lose just one, you're running the risk of losing all your data. Say you lose file 20 (out of 200): You've lost all the content that was stored in files 20-200 forever. Keeping everything in one big file might make up- and downloading a bit more difficult, but it reduces the risk that you lose one of the files.

A few suggestions

Point 3 is also a problem with a huge file that accidentally gets a single bit flipped in transit. I'd think about redundancy a bit. There are ways to add error correction without having to double the size of the data. (I think some compression programs support it natively, even though you can't expect them to actually compress your .tar.gpg file...). Confidentiality is all well and good, but your scheme is a backup scheme, so you should also think about availability.

I would also suggest not storing your GPG password on an external service (Lastpass). If you're afraid of losing the 100 character password, write it down on a physical piece of paper and put it in a safety deposit box of a bank you trust.

Also, this might seem paranoid, but I wouldn't use the same passphrase over and over to encrypt your gpg files. Instead, I'd genereate a file containing a number of truly random bytes whenever I needed to upload a new backup and use that as a key for my gpg'd tar file. I'd then encrypt this random file with my 100 character passphrase and keep it on my computer, send it along to be stored at google / sync and maybe back it up to an additional location. (Basically, I'd create a session key with which to encrypt my data and use the 100 character string as a master key to decrypt the session keys). You can automate this fairly painlessly, and it gives you forward secrecy in case one of your backup session keys is compromised and the ability to decrypt any specific backup without losing control over your master key.

Finally, if you're really just using Google Drive as a backup and don't really need to decrypt the data except in emergencies, you could think about using gpg in it's public key cryptography mode. Make a backup key pair, and then keep your private key safely offline (in a bank deposit box, on a CD ROM, printed out on a piece of paper somewhere for safekeeping) while using the public key to encrypt your symmetric session keys (using public key cryptography to encrypt with gpg would make the manual session key step seem redundant - I'd still do it for better forward secrecy). So you'd never have to worry about your master key (private key) getting compromised by cyberattacks, even if you stored your public key at LastPass. Even if they stole it, all they could do with it is encrypt more data; they couldn't use it to decrypt your session keys.


How does FaceNiff work? FaceNiff is an Android app that sniffs Facebook session ids. You must be connected to the same WiFi as the victim. It is said to be working even when WPA2 is present. How is it possible? I can decrypt other connected users' communication in WPA2?

TL;DR:  FaceNiff probably exploits WPA's "Hole 192" and uses ARP poisoning to set up a Man-in-the-Middle attack.  The steps, in short, are:

Eve uses the Group Temporal Key (GTK) to inject ARP packets into the network, with the network's gateway IP paired to her MAC address.
Clients register Eve's MAC address as their new gateway.
Clients send packets encrypted with their private keys (PTKs) to the AP, but addressed to Eve.  (Packets must still go to the AP because it is the "hub".)
AP decrypts the packets, re-encrypts them with Eve's PTK (since they're addressed to her), and re-broadcasts them.  The packets are now effectively cleartext to Eve.
Session hijacking ensues.

According to an article at The Register, it would seem that ARP poisoning is indeed involved.
http://www.theregister.co.uk/2011/06/03/android_cookie_stealing_app/print.html

The app works even on networks protected by WPA and WPA2 encryption schemes by using a technique known as ARP spoofing to redirect local traffic through the attacker's device. An attacker would have to know the security password, however.

So, for WPA2 networks, FaceNiff is most likely exploiting "Hole 196".  AirTight has an article that does a great job of explaining exactly what Hole 196 is, and (pasted below) how it can be exploited so that Eve can sniff WPA2 traffic as if it were in the clear.
http://www.airtightnetworks.com/WPA2-Hole196

In a WPA2 network, a malicious insider broadcasts fake packets (with the AP's MAC address as the transmitter's address) encrypted using the shared group key (GTK) directly to other authorized Wi-Fi clients in the network. One example of an exploit that can be launched using GTK is the classic ARP poisoning (man-in-the-middle) attack (demonstrated at Black Hat Arsenal 2010 and Defcon18).
In the ARP poisoning exploit, the insider can include for instance an ARP Request message inside the GTK-encrypted packet. The ARP Request has the IP address of the actual gateway, but the MAC address of the attacker's machine. All clients that receive this message will update their ARP table - mapping the attacker's MAC address with the gateway's IP address.
All "poisoned" Wi-Fi clients will send all their traffic, encrypted with their respective private keys (PTKs), to the AP, but with the attacker's MAC address as the destination. The AP will decrypt the traffic and forward it to the attacker, now encrypting it using the attacker's PTK. Because all traffic reaching the attacker (from the AP) is encrypted with the attacker's PTK, the attacker can decrypt the traffic (including login credentials, emails and other sensitive data).
The attacker can then choose to forward the traffic to the actual gateway of the network, so that the victim Wi-Fi clients do not see any abnormal behavior and continue their communication.


Which of the TLS ciphersuites are more faste and secure in Handshaking? I know "SSL 3.0" and TLS 1.0 have weakness security, because using of "RC4" cipher. instead it, "TLS 1.2" have more security, now I want to use of a fast ciphersuite and a complicated handeshake method in "TLS" (for prevent of Man in the Middle Attacks).

It seems to me , key-exchange and ciphersuite methods should be as follows (priority respectively) :

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Now, which of Ciphersuites are fast and more secure in "TLS" handshaking?

DHE key exchange is very slow compared to ECDHE, so you should prefer the ECDHE ciphers.
ECDSA is faster than RSA for the same level of security, but of course you need a ECDSA certificate and not a RSA certificate in this case.
AES-GCM is faster than ChaCha20-Poly1305 on systems with hardware support for AES but slower on systems without hardware support. You usually have hardware support on desktop system but it is  missing on most mobile phones or tablets.
CAMELLIA seems to be in theory similar to AES regarding security and performance but usually lacks hardware support and is thus slower. See Why does nobody use (or break) the Camellia Cipher? for more information.


Is it possible to exploit unescaped user input into JavaScript form which only gets data via AJAX request? A logged in user can get to a page https://example.com/some/page which has an input field and some buttons. When user enters something into this field and clicks away on anything, the page makes requests to https://example.com/data to check if requested object is available and returns false if not.

In this case the page renders warning like Can't find $User Input$. So if users enters something like <script>alert(1)</script> it will indeed attempt to render it and display an alert. What is called "reflected XSS", I believe.

So here is the question. In the described example were

We clearly have unfiltered input field exposing reflection XSS vulnerability.
However, user explicit input is required (since no url can populate this field, for example), how should we evaluate the severity of this issue?

My general understanding is that even if I personally don't know how (if possible) one can use this exploit, I still should treat it as a critical vulnerability. But I lack I arguments to prove it for triage.

There's not enough information provided to correctly diagnose whether this is a vulnerability or not.

If it was possible to trick a user into making the request directly to /data and include the malicious payload (<script>alert(1)</script>), then yes it would be a vulnerability if the alert box appeared.

For example by tricking the user into visiting the attacker's site which contains a redirect to https://example.com/data?<script>alert(1)</script>
or contains a form that POSTs to https://example.com/data with the request body set to
data=<script>alert(1)</script>.

This would hinge on whether /dataresponds to none-AJAX requests also. Additionally, the content type returned would need to be text/html for any script to be rendered and executed by the browser.

Also, your payload might only be rendered with a form encoding type of application/json. If the /data handler only responds to requests with this encoding type then it is impossible to make these requests with a <form> tag.

If it is still renders the response with a different content-type specified, then you may be able to get it to render by "tricking it" with a text/plain form:

<form enctype="text/plain" method="post">

  <input type="hidden" name="{&quot;data&quot;: &quot;<script>alert(123)</script>&quot; }//" value="" />

  <input type="submit" />

</form>

The other avenue to explore is whether you can get /some/page to pre-populate the textbox with your payload. Try common parameters such as:

https://example.com/some/page?data=<script>alert(123)</script>
https://example.com/some/page?value=<script>alert(123)</script>
https://example.com/some/page?<script>alert(123)</script>
https://example.com/some/page?debug=<script>alert(123)</script>
https://example.com/some/page?test=<script>alert(123)</script>
https://example.com/some/page?id=<script>alert(123)</script>
https://example.com/some/page?etc=<script>alert(123)</script>

Have a look what you've observed on the rest of the site (e.g. check Burp's sitemap) and make a list of commonly used parameter names.

See here for my answer to a similar question.

If you cannot check these things yourself then you would need somebody with web security skills to verify whether this is a vulnerability or not. If it is not possible to hire somebody, then you would be best hedging your bets and fixing it anyway.


Timing analysis attack and cryptosystem Why is a “Timing Analysis Attack” a problem for a cryptosystem?

I've been trying to learn security, and have a question about timing analysis attack.

Timing attacks are a type of side channel attacks. From a formal point of view, a cryptographic algorithm (let's say an encryption system) takes some input and provides some output, and the attacker sees the two values and tries to work out the key from these values. However, in a realistic system, the algorithm does not happen "magically": it has to run somewhere, on a computer or some other circuitry, and the attacker may try to observe from the outside this operation and deduce some extra information.

A timing analysis (or attack) is about measuring the time taken by the cryptographic algorithm to execute a given operation. Informally, the attacker tries to make "informed guesses" which look like "mmh... the algorithm took 174 nanoseconds to execute, but if that key bit was a 1, it should have taken at least 176 nanoseconds, so the key bit was a 0".

Defence against timing attacks include tweaking the algorithm implementation so that it always executes in a fixed amount of time regardless of the key value and input data; or "randomizing" it so that the attacker can no longer make such guesses. E.g. with the core exponentiation of RSA, instead of computing md mod n (n is the modulus, d is the private exponent), the implementation generates a random value r modulo n, then computes re mod n and 1/r mod n, and computes ((m*re)d) * (1/r) mod n. This is called masking. Since a new r is generated for each RSA computation, this process effectively prevents the timing-based guesses from the attacker.


Can IPsec transport mode prevent DPI by your ISP? It is well known that ISPs use deep packet inspection to deprioritize certain types of network traffic, such as that belonging to filesharing applications.  If ISPs achieve this throttling of traffic by examining the payload of IP datagrams, couldn't encrypting the payload with IPsec prevent such throttling?

IPSec or other kind of VPN will prevent the ISP from using DPI to analyze the different kinds of traffic transported. But the ISP can detect that there is a IPSec/VPN tunnel and can treat it as low priority traffic, this way making it even worse for you.


Nmap not working as a root Hi I asked this questions on other forums, and searched on google, but nothing was useful to me. My problem works as a non-privileged used, but whenever I run it as a root, I get:

Starting Nmap 7.01 ( https://nmap.org ) at 2016-07-25 16:21 CEST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.26 seconds

I am working on a project, that is exploiting services and so on on vulnerable systems, such as Metasploitable. I would very much like it if someone could help me

Nmap uses different scanning methods depending on whether it's running as root or not.

The error you see is normal. Try adding -Pn and you will probably get identical results to the scan you ran as a regular user.


How can we protect signup APIs from brute force registration? This is a general question but its prompted by a fairly open API I have for a file storage service that needs to have its front door better locked down.

We have an API like POST '/signup' that just takes a username and password and creates a user. It is totally possible for someone to write a very simple script to call /signup with every letter combination that fits our username rules and effectively brick us from new signups.

I have not found a concise enumeration of all the possible signup security tricks, so I will start them now and ask for anyone to contribute what I have omitted or further implementation details on a particular item.

IP Throttling: For every signup, record the IP address and check it against a table of recent signup IPs to ensure number of signups and time since last signup at this IP is not suspicious. **
Other authorized login: Use verified email, phone number, or 3rd party OAuth logins
Human verification: Have the users complete a Captcha or some form of validation that is too computationally expensive for a script to manage

** IP throttling seems to be the only option that will not necessarily affect the client signup experience, although at the cost of implementing a new subsystem to orchestrate the storage and validation of IPs (Are there 3rd party services for this?). It also does not protect against the extreme case where a network of attackers (or attackers that can change public IP) distribute the attack across N IPs to make N usernames.

You could use a tool like Fail2Ban against the API logs to block an IP for 5 minutes (or whatever you want) after 3 (or any number) of account creation attempts.

http://www.fail2ban.org/wiki/index.php/Main_Page

It would also be wise to know some common API requests that are made by brute force attempts that do not exist on your site and automatically blacklist IP's that make those requests (at least for 30 minutes or so).

Blacklisting at the IP layer based on well set triggers is a very low cpu-cost way to deal with Brute Force attempts. It's also wise to whitelist known good IP's in your infrastructure when you do this.


What does a FIPS validation certificate cover? Just software version or OS and hardware too? As I understand it, if you want to be FIPS-compliant you have to use FIPS-certified components.  My question is how different can your use of the component by from what's on the component's validation certificate be for you to still be using a FIPS-certified component?

For example, here's a validation certificate for NSS:
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt1280.pdf

The certificate says the NSS software version is 3.12.4 and was tested on RHELv5 on an IBM System x3550 and on a HP ProLiant DL 145.

I assume (?) that I definitely need to use version NSS 3.12.4 since that is the version that certificate says was validated.  (For the moment I'm ignoring the possible existence of later certified versions of NSS -- pretend this one is the latest one if it's not).

But what about the operating system and server hardware?  If I run NSS 3.12.4 in an Ubuntu installation am I still considered to be using a FIPS-certified component?   What if I run it on RHELv5 but on hardware different from what was mentioned on the validation certificate?

Update:

I'll try to be clearer/more explicit...

Is NSS 3.12.4 considered validated/certified when run on any operating system or only when run on RHELv5?  And how does one determine the answer to that question?

They certified only the module described in the document.  They did not certify the ProLiant was FIPS compliant, and they did not certify that the Red Hat OS was FIPS compliant.  That just happened to be the machine and environment they used when they tested the compliance of the module.

According to FIPS 140-2 paragraph 10, they allow for the certification of a hardware module, a software module, or a combination of both.  It's up to the security system provider what they are requesting to certify.  But the only thing that is actually certified is what they write on the certificate.


Is OSX vulnerable / susceptible to Gameover Zeus I've heard a TON of vague info on Gameover Zeus recently. One detail I can't seem to find is if it affects OSX?

when I say I can't find it I mean from a credible source. I've found loads of people on forums saying the classic "Macs cant get viruses", but not any hard facts..

No. The Zeus family of malware does not infect OSX, only Windows. Macs can of course be infected with malware, anyone who says otherwise is sorely mistaken. Some more info, GameoverZeus is simply an improved Zeus. It is run as a P2P (peer to peer) network, and operated by an HTTP control panel. The source code of Zeus can be found with a Google search so that's how that happened. It's one of, if not the most sophisticated bots on the market next to TDL. It's even able to bypass two factor authentication, along with all of the plugins you would see in bots like SpyEye, ICE9, Carberp, and Citadel.


Possibly illegal material discovered through hacking - theoretical discussion Lets say for instance...

X has hacked Y.
X does not know Y but thought Y looked and sounded suspicious over social media.
X infiltrated their emails and discovered content that local authorities would be highly interested in.

The only issue is how would X inform the authorities about Y being a suspected criminal if hacking is against the law and X does not want to get themselves into trouble?

Truly speculative, just wondering, that's all.

What would you do?

X should do nothing. X likely broke a few laws by hacking into the system controlled by Y, so by reporting it they are incriminating themselves. Should it come to a criminal case against Y, the defense of Y will likely be that any evidence X claims to have found was forged by X to incriminate Y. X admitted to being a cyber criminal, after all, so X can not be trusted.

What X should have done is inform the authorities when they thought Y looked and sounded suspicious over social media, let them decide if they want to pursue the case or not and forget about it.


What may a Hungarian employer do with the employee monitoring logs? Employers often monitor employee network access, even install keyloggers on their computers, etc.

But the articles I found on the internet, is about the monitoring but not what they may do with the logs.

Let's see the following scenario: I'm waiting for an important e-mail so I keep my personal e-mail account web interface open, I just logged in, an waiting and not opening any of my e-mails. So my employer won't see my e-mails' content in the logs.

Since the user name and password passed through their network. They can obtain it from the logs.

May they use the username and password to log in, look at my e-mails and use the account on my behalf without my consent? (Just because they obtained the password)

I work here in Hungary, but the company is an international company, so the proxy is somewhere else (maybe in England).

An employer may not access your personal email without your consent iirc. (Consult a lawyer to be sure)

However almost all of the time when these type of practices are in place there is an acceptable use policy that also points out if you are allowed to use company ict infrastructure to read your personal email, what they will be logging and what they might do with that information.

In Belgium we follow European guidelines, our law states:

An employer can not monitor your surf and email behavior, unless he advertised this up front. (Like I said, this can often be found in the AUP)
Only after the consent of the employee an employer may look up how much he's using the internet or how much emails he is sending.
The content of a sent/received email can not be read unless the employee has opened them and has given consent. There are exceptions on this (for instance when the employee goes on leave and the emails need to be forwarded to another employee)

If information wants to be used as proof in court it will have to follow the above guidelines UNLESS:

There was a court order to gather this information
There was a "higher" cause, this being: theft, corporate espionage or accessing information considered illegal by the law (child porn, warez,...)
Employers are also encouraged to create a UAP and provide a detailed and comprehensive list of rules to tell the employee, what he can and can not use the company's ICT infrastructure for. A company can always prohibit the use of company ICT infrastructure for personal use (Facebook, personal email)

Whilst he can conclude you are using his infrastructure for personal use, he may not access the content and certainly not send emails in your name.

This will probably be similar for Hungary as this law follows European guidelines. But please refer to a lawyer to confirm!

Also my advice: If you know these things are being monitored, don't use them for any personal matter.


Client side password hashing Edit: Updated to put more emphasis on the goal - peace of mind for the user, and not beefing up the security.

After reading through a few discussions here about client side hashing of passwords, I'm still wondering whether it might be OK to use it in a particular situation.

Specifically I would like to have the client - a Java program - hash their password using something like PBKDF2, using as salt a combination of their email address and a constant application-specific chunk of bytes. The idea being that the hash is reproducible for authentication, yet hopefully not vulnerable to reverse-engineering attacks (to discover the literal password) other than brute force if the server data is compromised.

Goal:

The client side hashing is for the peace of mind for the user that their literal password is never being received by the server, even if there is the assurance of hashing it in storage anyway. Another side benefit (or maybe a liability?) is that the hashing cost of an iterated PBKDF2 or similar rests with the client.

The environment characteristics are:

All client-server communication is encrypted.
Replayed messages are not permitted. ie. the hash sent from the client cannot effectively be used as a password by an eavesdropper.
Temp-banning and blacklisting IPs is possible for multiple unsuccessful sign in attempts within a short time frame. This may be per user account, or system wide.

Concerns:

"Avoid devising homebaked authentication schemes."
The salt is deterministic for each user, even if the hashes produced will be specific to this application because of the (identical) extra bytes thrown into the salt. Is this bad?
Authentications on the server end will happen without any significant delay, without the hashing cost. Does this increase vulnerability to distributed brute force authentication attack?
Rogue clients can supply a weak hash for their own accounts. Actually, not too worried about this.
Should the server rehash the client hashes before storing?

Thoughts?

Hashing on the client side doesn't solve the main problem password hashing is intended to solve - what happens if an attacker gains access to the hashed passwords database. Since the (hashed) passwords sent by the clients are stored as-is in the database, such an attacker can impersonate all users by sending the server the hashed passwords from the database as-is.

On the other hand, hashing on the client side is nice in that it ensures the user that the server has no knowledge of the password - which is useful if the user uses the same password for multiple services (as most users do).

A possible solution for this is hashing both on the client side and on the server side. You can still offload the heavy PBKDF2 operation to the client and do a single hash operation (on the client side PBKDF2 hashed password) on the server side. The PBKDF2 in the client will prevent dictionary attacks and the single hash operation on the server side will prevent using the hashed passwords from a stolen database as is.


SSL MITM on the WAN side of my router Hi

I would like to try to sniff a typical CWMP conversation that my router does to his Auto Configuration Server (see TR-069 crash course: https://www.iol.unh.edu/sites/default/files/knowledgebase/hnc/TR-069_Crash_Course.pdf)

I know the server URL and the fact that it uses a self-signed certificate so I suppose that a MITM with a passive client could be tried.

The goal is to obtain the Voip credentials associated to MY ACCOUNT since my provider does not give them to me.

My hardware is a dual ethernet linux box.

My ideas are:

Use EBTABLES to manipulate layer 2 traffic and pass all the IN or OUT traffic on given ports and with source/destination IP of the ACS to iptables
Use IPTABLES to redirect traffic to a MITM SSL proxy and try to see the conversation in cleartext.

But:

Every example that I find is for a switched network with some sort of NAT/Arp spoofing etc. etc. I just have 2 IP and I learn one of them after PPPoE.
I want to intercept some kind of traffic and redirect it to my proxy, all other traffic shuld be untouched

A first POC would be to intercept traffic, mark it and log it in iptables anche forward it without notice by client/server, but I still can't figure out how to do it.

Thanks for any help.

If passive MITM is sufficient you don't need to reroute anything. What you are looking for is a so called "lan tap". There are plenty of hardware tools on the market but you will be able to construct one yourself quite easily. It only consists of several ethernet ports and maybe some capacitors. You will only need those in case you want to sniff a 1G line with a 100M ethernet port.

There is a lan tap on the market by Michael Ossmann here which I recommend looking at because he seems to be a great guy with lots of nice ideas.

Anyways you can easily build one yourself like e.g. in this tutorial. You can then put it between the WAN side and your uplink and happy sniffing ;)


Meterpreter on non-jailbroken Iphone I found this at github: https://github.com/AnwarMohamed/meterpreter-darwin

Does anybody know if this works on a non-jailbroken Iphone?

I downloaded it on my and double-clicked on the Makefile-icon, inside the OSX directory, but my OS just keeps saying: "Makefile" can't be opened because it is from an unidentified developer".

How can I run the Makefile?

Check out the iOS Hacker's Handbook, chapter 4, especially the (under "Downloads") downloadable material from chapter 4. It contains a meterpreter that runs on iOS 4 that could possibly be ported to newer versions -- I verified that it does work on iOS 5.

The targeted iPhone in chapter 4 is not jailbroken or otherwise modified.


SSL heartbeat design So, about Heartbleed again, why does SSL/TLS allow the client to specify the message and its length in the heartbeat requests, rather than sending a simple ping?

Heartbeat requests are intended for use with connectionless SSL over UDP.  A simple ping tells you only that the computer at the other end is up (or not); by including a payload, a program can associate heartbeat requests with specific transactions, detect dropped or out-of-order replies, and do other things that a simple "are you there?" can't do.

That said, I suspect the real reason that heartbeat requests have a payload is that they were modeled on ICMP "echo" requests, without understanding why ICMP echo permits a payload.  The ICMP echo payload is intended for low-level network troubleshooting.


Encrypting an object and storing the hash of its decryption key in the same database To meet one of my application's needs, I must store an encrypted object in the database. Sometimes, I need to verify whether the user holds the right decryption key without the need to retrieve (decrypt) the stored object, I just need to make sure the user is its original owner.

I've come up with the solution of storing the encrypted object (using say, Fernet) and also its decryption key (hashed, of course) in the same database (maybe even in the same table), so that if I need to verify the ownership of the object I just need to hash the provided password and compare it with the key stored, without having to actually retrieve the encrypted object.

Does this represent any security risk I'm unaware of?

Storing encryption keys next to encrypted data is always a security risk, even if the encryption keys are hashed.

Now if I understood correctly, the reason for storing the encryption keys is to check that the user can decrypt the data (since the key is hashed, you wouldn't be able to reverse the hash to decrypt the data). But for this purpose you can use an arbitrary piece of data that isn't the encryption key - just store that token and encrypt it with the same key.


Exploit Development - Find system address in a given libc If I have a libc file which is used on another server where the vulnerable binary is running, then how can I find the address of system in it?

I have both the vulnerable binary and the libc file with me.

Usually, on local system, I would use gdb to find system() address. But when I execute binary from on my system, it will be using libc from my system.

So, how can I make sure that the address I find using gdb is of the libc from another server and not on my local system?

Should I place the libc file (from another server) in the same directory as the binary so that it is loaded by default when it's executed instead of the libc of local system?

Thanks.

try leaking 2 libc addresses and matching their difference with a libc database on the internet. This will give you the libc version used. After that you can find the offset of system in this libc with pwntools by:
libc=ELF("/path/to/libc")
libc_system=libc.symbols["system"]


PGP encryption using .ASC file. I need to send a important file(i.e.: pdf) to someone. They gave me a .ASC file for encrypting the file i will send. What could be the procedure for encrypting the pdf using that .ASC file?
Please mention the options by which i can be sure i have encrypted it correctly.

If you are on windows, I use an open-source program called Gpg4win/Kleopatra.

Open Kleopatra
File > Import certificates... > browse for the .asc file

This will now allow you to encrypt files using that public key.

Open Kleopatra
File > Sign/encrypt files
Browse for .pdf file you wish to encrypt
(Follow the prompts) Next > select the certificate that you imported previously > Add > Encrypt > Finish
Send them the encrypted file.


Does BitLocker encrypt everything? just a quick question - does BitLocker encrypt everything including host protected area, device configuration overlay and bad sectors?

Bitlocker works at the volume level, replacing the file system metadata with its own and moving the FS metadata into the encrypted volume (for this reason, BitLocker needs to understand the file system format, so it knows where there is free space for the metadata, and how to mark that space as no longer free). It is Full Volume Encryption, not Full Disk Encryption, and doesn't touch anything outside of a logical volume (which might be a physical partition, or a RAID volume, or possibly something else).

I don't know if BitLocker has any special logic for dealing with bad sectors.


How to know somebody's IP? (Fraud victim) I was victim of fraud (fool me) in Mexico and my only hint is a GMail account, so I can contact him from an anonymous mail.

From what I've read, GMail's headers don't contain the sender's IP. What are my options to get the sender's IP? Some link that he can click and log his IP? I just want at least a hint on where he is.

If you can trick them into clicking something in an email, you can send them a link to any page that you have access to the webserver logs for and find the request in the log (along with their IP).  There are also a number of third party services to do this for you that are pretty easy to use (eg http://whatstheirip.com).

Now, that said, some of the scammers out there are highly dangerous individuals with organised crime connections.  Think twice before tangling with these people and consider the value of the money you've lost vs the potential cost to you and your family if they decide to try and hurt you.  These people may be quite comfortable resorting to murder or kidnap to get their way, do you really want to move out from behind a computer screen and face someone like this in person?


how to generate RSAES-OAEP keys? RFC4055 describes RSAES-OAEP keys and RSASSA-PSS keys.

OpenSSL's genpkey utility supports let's you generate RSASSA-PSS keys (you have to set the aglorithm parameter to RSA-PSS) but if it supports RSAES-OAEP keys the documentation certainly makes no indication of that.

My question is...  are there any third party tools that'll generate RSAES-OAEP keys for you?

I think, it can be achieved by passing -sigopt rsa_padding_mode:oaep to the openssl req command.


Why is ID token used instead of Access token to get temporary credentials in AWS? After a user logons to cognito, he receives access and ID tokens. the ID token contains sensitive info like phone number, email, etc..
From all standards - ID token should not be used to gain access to an API: https://auth0.com/docs/tokens?_ga=2.253547273.1898510496.1593591557-1741611737.1593591372
In the backend, to get a session credential (to work with AWS resources) - you typically do this:
identity_id_response = boto3.client('cognito-identity').get_id(
    IdentityPoolId=identity_pool_id,
    Logins={
        provider: id_token #ID token! not access token
    }
)

Then:
provider = f'cognito-idp.{region}.amazonaws.com/{user_pool_id}'

response = boto3.client('cognito-identity').get_credentials_for_identity(
    IdentityId=identity_id_response,
    Logins={
        provider: id_token #access token again
    },
)

Then, you can use AccessKeyId, SecretKey, SessionToken etc..
This is problematic as what if you want to send the ID token to multiple services (via SNS, etc..) so you could perform processing on behalf of the user? you basically send a sensitive token that contains sensitive user data over the backend.
So - it requires an encryption before sending this token, which seems like an overhead.
Any thoughts?

From Question:

From all standards - ID token should not be used to gain access to
an API:
https://auth0.com/docs/tokens?_ga=2.253547273.1898510496.1593591557-1741611737.1593591372

Example from Documentation:

 if there's an app that uses Google to log in users and to sync their calendars,
 Google sends an ID Token to the app that includes information about the user. ......
    In the Google example above, Google sends an Access Token to the app after the user logs in
and provides consent for the app to read or write to their Google Calendar.
Whenever the app wants to write to Google Calendar, it sends a request to the Google
Calendar API, including the Access Token in the HTTP Authorization header.

It seems the documentation is referring to the APIs on Identity Provider's end (Which is Google in this case). The example discusses a use case which involves both authentication and authorization. The ID token is used for authentication and the access token is used for the API calls (modifying Google calendar on behalf of the user, also called "delegated authorization"). Delegated authorization was the basic idea behind OAuth.
The message they want to convey is: use access token to write to Google calendar on behalf of the user and use ID token to identify the user as the relying party.
I am guessing your use case with Cognito only involves authentication hence the ID token is used. The access token is gibberish from the perspective of AWS STS.
More from question:
This is problematic as what if you want to send the ID token to multiple services
(via SNS, etc..) so you could perform processing on behalf of the user?
you basically send a sensitive token that contains sensitive user data over the backend.

I am not sure if I understand your use case. Why is it that the initial set of temporary security credentials returned by STS are not having the required access?


Isn't OpenID over HTTP (not HTTPS) fatally flawed when delegates are used? First, I have a private delegate set up on my web site for OpenID and pointed my SE account at the URL on my web site; SE has no knowledge of the actual OpenID provider endpoint until my delegate response tells it.

Second, when authenticating to SE et al I note that if I don't explicitly key in https://... it makes the request using HTTP instead of HTTPS.

Third, having associated my SE account with my OpenID endpoint, I am able to use either HTTP or HTTPS to login, despite using HTTPS when the account was associated.

Does this not, therefore, open me up to a MITM attack whereby the attacker simply modifies the response from my web server to delegate to their own OpenID provider, thereby gaining access to my SE account?

Note: I am not talking about the actual authentication step with the OpenID provider, which does use HTTPS and redirects to HTTPS if accessed via HTTP, I am talking about the initial request from SE to my delegate, which SE allows to be done using HTTP because they only store the URL from the base domain onwards (omitting both the protocol and the sub-domain) to use for matching up to an account instead of the full URL.

Yes, it is. So you should always use https.
Even worse, some service providers violate the specification:

11.5.2.  HTTP and HTTPS URL Identifiers
Relying Parties MUST differentiate between URL Identifiers that have different schemes.

Any consumer/service provider which violates this rule, is vulnerable to an attack. This is especially bad because a user cannot protect himself: He may use https every single time, but the attacker can just use http.
Furthermore a man in the middle vector is not required. It is sufficient for the attacker to be able to read the traffic to the identity provider; at a time of his choice.

When end user input is processed into a URL, it is processed into a HTTP URL.

So the behavior of StackExchange is in compliance as far as defaulting to http is concerned.
The specification continues:

[...] it is RECOMMENDED that a redirect be issued from the HTTP URL to the HTTPS URL. Because the HTTP and HTTPS URLs are not equivalent and the Identifier that is used is the URL after following redirects, there is no foreseen reduction in security when using this scheme.
If an attacker could gain control of the HTTP URL, it would have no effect on the HTTPS URL, since the HTTP URL is not ever used as an Identifier except to initiate the discovery process.

Note: This approach is still vulnerable on the very first discovery process.
Specification: http://openid.net/specs/openid-authentication-2_0.html#anchor45


How to steal source code through clickjacking? Is it possible to steal the source code through clickjacking, so that attacker can also steal the CSRF tokens?

This is a demo attack website:

<!DOCTYPE html>

DRAG ME!!

Now as you can see I am trying to steal the source code with the help of an alert box. But I didn't succeed in that.

What am I missing here?

It is not possible to use clickjacking to get cross-origin access to the source code of a web page. This access is restricted by the same-origin policy and clickjacking does not bypass it. This means that, similar to a CSRF attack, you can cause a cross-origin action with clickjacking but you cannot read back the result of this action.

Thanks for Arminius for pointing out in a comment that it was once possible to exfiltrate content using clickjacking by using cross-origin drag and drop. See for example Clickjacking 2.0 with drag & drop or this bug for Firefox. This seems to be forbidden in the browsers for a while now, i.e. modern browsers should no longer be affected by this.


Which IP / Client is being Ddosed? I currently have some Vps's and shared hosting plans with a few hosting providers. Recently one of my shared hosting accounts was suspended due to a denial of service attack. I understood why they had to suspend the account etc. But what I was curious of was how do they know which website was the victim? It is on a shared server and with a large company as well so I know for a fact there are numerous sites all sharing an IP and server.

I understand the concept of monitoring traffic but obviously never experienced monitoring a large scaled server which multiple people share.

Thank you so much for any input.

DDoS (Distributed Denial of Service) attacks are at their core near identical to perhaps more common DoS (Denial of Service) attacks, with one major difference in DDoS being, well, distributed. What that means though is that the attacker(s) will use multiple locations as a source of their attacks on your infrastructure, but more importantly, just like with DoS attacks, the attacker(s) will in both cases try to exhaust your infrastructure's resources. This is where booth DDoS and DoS might be the same, and is important to understand.

So, exhausting your infrastructure resources. What could that mean and how would an attacker do that? It turns out there are many ways to cause servers and other networking equipment to have more work with preparing and responding to external requests, than the attacker's own setup (distributed or not) would permit. So this is where the attacker takes the advantage - it is cheaper for him to send requests, than for you to respond to them. Given enough attack oomph by whichever means, one stronger adversary (DoS), or many weaker but greater in number ones (DDoS), your server's resources will be exhausted and cause denial of service to any other, legitimate traffic. Some of these techniques would be traceable to the individual Virtual Host responding on a certain HTTP(S) location, and others might rather target the infrastructure more directly and on lower levels, maybe the transport layer itself by abusing network protocols, both causing too many responses to be required than the infrastructure can handle.

So here's are two clues here:

The DDoS attack your provider mentions had to have been on the high level stack that would identify a virtual server in its requests, like for example on the HTTP(S) stack and requesting URLs pointing to your virtual server, and
Whichever resource was continuously requested caused the server your Virtual Host was hosted on to exhaust its resources by preparing a response. That could be any of the number of resources your VPS server had a limited supply of, or any of their combinations, like maybe continuously reaching local storage quota, system's memory, CPU cycles, e.t.c.

This might seem clear cut, but bear with me, because it really isn't in your case. Here's the thing; You mention you hosted your website on a VPS (Virtual Private Server), so in theory, all the resources your VPS server could have exhausted shouldn't have translated to any problems with other VPS's on the same physical hardware hosting them (i.e. it's supposed to be a Virtual Machine and isolated from any other VM's) and you have actually been paying to your provider maybe a monthly fee to use all those resources to your liking, as long as you're respecting their ToS (Terms of Service). And for any DDoS attempts to have directly identifiable target on this VPS/VM stack, their requests would have to be on the highest stack actually requesting a network domain (let's say it was on the HTTP(S) protocol, which would make it URLs then, for the sake of argument) and including enough information for the VM host to decide to which VM client (your VPS) to redirect requests to.

So we have this conundrum of either/or:

If the problematic requests were on the HTTP(S) stack and including identifiable request URLs, then this shouldn't cause any problems to your VPS host, but it would exhaust your VPS resources, something that you were paying for anyway, and
If the problematic requests were on the lower, network layer on the TCP/IP stack, then they wouldn't necessarily (and why would they?) include information in the request packets which specific VPS client they were targeting.

So this can only be answered in two ways:

Your VPS was actually the only VM that was hosted on the same IP address, and your provider could conclude your services were a target of DDoS attack like so, or
Your VPS provider is full of s***

Most likely though, you will never know which one of the two options was really the case. If it's all the same to you by now, you can post your IP and domain name in the comments below, and I'll check if there are any conclusive indications to be found in the various databases / resources on the Internet which of the two options might be more likely, but unless you get a full disclosure by anyone with direct access to the physical server in question, it will remain a mystery. It's up to you to decide, if you can deal with such unknowns and how much you're prepared to pay monthly to have this service, but I know which route I'd choose. Just saying... ;)


Is it possible to use more than one certificate on the same server at the same time? Is it possible to use more than one certificate on the same sever at the same time, on the same connection? If I have a certificate from Alice Keys CA and another from Bob Security CA, is it possible to serve both, for the benefit of those browsers that trust only AliceCA and those which trust only BobCA?

This is not the same as "Certificate verified using two different paths" question, because I'm referring to two completely different certificates:

ACA root certificate self-signed -> My A certificate for mysite.org
BCA root certificate self-signed -> My B certificate for mysite.org

Yes, you can have more than one trusted certificate path on a single server.

Regarding your concern, please note that certification path does not refer to certifying the server certificate, but its public key, therefore certification path might consist of one self-signed certificate only.

Speaking of server providing two self-signed certificates is equivalent to speaking of server providing two certification paths.


Can I use HTTPS to pass a symmetric key used for encrypting TCP packets? I am making a multiplayer game for fun and wish to keep it secure. The client is written in C# and the server in node.js with a working connection over TCP at the moment. I am new to this subject, and implementing something with RSA or Diffie-Hellman or TLS seems confusing and something that I could easily mess up. I have looked into using TLS, but have no idea how to do it without using a client certificate. Google is no help because it does not do well with negative searches if that makes sense; I only seem to get results for using client certificates in TLS. And so I came up with the idea of using HTTPS as a Diffie-Hellman substitute, connecting to the server using a self signed certificate (for clarification, the server is the one using the cert, english is weird), validating user login info, and passing back a key to use for symmetric encryption for the TCP packet transfers.

The general process would go like this:
1. Client initializes TCP connection with server and sends server a temporary ID.
2. Server marks the socket the user is connecting to with the temporary ID.
3. Client sends HTTPS post to server with login info and the temporary ID.
4. Server hashes/salts password and compares to database. On successful validation give authorization to the socket with the temporary ID what the validated user has access to. If either auth validation fails or no socket is found matching the temporary ID, return an error to the client(400). On success, generate a key to use for symmetric encryption and return it to the client(200).
5. The client recieves the symmetric key, and both client and server use it to talk in future communications.

The temporary ID serves the purpose of allowing the server to be able to tell which TCP socket connection to authorize when the HTTPS validates the login info. I think this would be ok against man in the middle attacks because the man would only get the temporary ID which is not used for anything else, and if it were changed the server would not find a socket with a matching ID during the HTTPS phase, and it would just return an error.

I think that this would be inferior to TLS because there will not be any packet signing going on in step 5 and future TCP communications, but it might be fine.

From what I understand about encryption, symmetric keys only act as a sort of cipher, so it probably is not too much overhead to deal with on server side.

Is this system viable?

HTTPS is TLS. Using HTTPS you already establish a symmetric key as part of setting up the TLS connection. You don't need to pass yet another symmetric key around in most scenarios. You definitely should not be dealing with RSA or Diffie-Hellman directly. Just use a well-established crypto library supporting TLS/HTTPS connections. The only thing you need to consider RSA or DH or anything else is in setting up the configuration or calling parameters for your chosen library.


Are there security issues with embedding an HTTPS iframe on an HTTP page? I've seen websites placing HTTPS iframes on HTTP pages.

Are there any security concerns with this? Is it secure to transmit private information like credit card details in such a scheme (where the information is only placed on the HTTPS iframe form, and not on the HTTP parent page)?

If only the iframe is https, the user cannot trivially see the URL it points to.  Therefore, the source http page could be altered to point the iframe anywhere it wanted to. That's pretty much a game-over vulnerability that eliminates the advantages of https.


Capture emails of users who clicked my link a follow up question to this: Tracking click-through for organization-wide phishing email test

I am going to send an email (fake phish) to all my org. users via email.
I want to test the users so if they click a malicious(fake) link their email address will be sent to a list (or I receive a notification saying user X click your test link) domain name will get logged/added to a list somewhere I can grab.

Method to capture the email address of users who clicked my link in a email.

Use a link like phish.org?email=user@domain.com.

You can use base64 or any other encoding to obfuscate the email address, but the principle is the same.


Is PPTP VPN ever secure? Under DD-WRT? PPTP is not an open, ratified standard the way that, for example, SSL/TLS is. (see: http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.2 and http://datatracker.ietf.org/doc/rfc5246/ )

The most popular (most widely deployed) implementation of PPTP came from Microsoft, in WinNT. This implementation was also used in many 3rd party applications designed to work with WinNT and its successors.

The MS implementation of PPTP (with MS-CHAP authentication) was publicly demonstrated to be cryptographically broken in 1998 (see https://www.schneier.com/paper-pptp.html ). And there are utilities available to sniff for MS-CHAP authentication sessions and automatically extract passwords from them (L0phtCrack v2.0, released 1997).

So, the question is: Does anyone know the details of the DD-WRT implementation of PPTP? I see that PPTP Server in "v24-sp2 mini" uses "MPPE Encryption" and stores "CHAP Secrets". Does it have the same vulnerabilities as PPTP/MS-CHAP did in 1997? Is this implementation of the protocol any better than it was 16yrs ago?
Or, for a home-grown VPN, do I need to I upgrade my hardware and firmware to use OpenVPN?

(Reposted from superuser.com/questions, following a user recommendation.)

PPTP is thoroughly broken. At this point nobody who cares in the least about the communications they intend to protect should be using it. And it's not a matter of choosing someone's implementation over another; its most serious flaws are in the protocol design and cannot be fixed.

MSCHAPv1 was broken 15 years ago, as you noted in your question. Its replacement, MSCHAPv2, has been known to be weak for nearly as long; now it can be brute forced in a matter of hours; this was demonstrated at last year's DEFCON and you can now use an online service to break it.

You can use EAP-TLS authentication with PPTP, though this requires a full public key infrastructure and isn't something you're necessarily going to put effort into unless you're building an enterprise VPN. There are a lot of moving parts, so it's not something you are likely to do for a personal project.

And then, the above only deals with authentication. The encryption, MPPE, uses RC4. But, there is no message authentication, so it is possible for an attacker to modify your traffic in transit, quite possibly without it being detected. And RC4 is getting weaker by the day (which is a whole other topic)...

Microsoft, for their part, recommend using L2TP or IPSec or SSTP. OpenVPN is also a possibility, especially if you are dealing with non-Microsoft systems.

Finally, the implementers of PoPToP, the Linux implementation of PPTP, recommend against using it, and have done so for almost a decade.


How long a lifetime of a DTLS session with an IoT device should be? I am using an application which is sending application data using MQTT-SN application Layer protocol. I have encrypted the UDP port using DTLS.

Now the question is if i have to reinitialize a handshake for every PUB/SUB packet i want to send through client or i can save that session once created and use it for indefinite period.

There are in fact two different questions here.

Q: Do i have to reinitialize a handshake for every PUB/SUB packet i want to send through a client?

A: No.

A DTLS handshake is very expensive, so preserving/resuming the same session for every subsequent pub/sub interaction seems like a very good idea, especially given a constrained environment (which is assumed to be in place somewhere for all of the MQTT-SN usage scenarios outlined in the section 3 of the spec).

In fact, RFC 7925 "TLS/DTLS Profiles for the Internet of Things", Section 7 "Session Resumption" strongly suggests exactly that.

Note that if your environment is not constrained in any way and doesn't have anything to do with the Internet of Things at all, you would want to consider replacing MQTT-SN with something else.

Q: Can I use a session created once for indefinite period of time?

A: Sort of yes, but depends on the period.

A DTLS session does not age given appropriate session ciphers, if this is the question. However, after a certain period of time you may still want to drop it and initialize a new one through a new handshake.

A simple example of when it makes sense to do so is when on January, 1st, you connect to a server with a TLS certificate valid till March, 1st. At the end of February you may want to re-check if the remote endpoint still operates the server name you're connecting to by requesting another handshake and checking if the certificate had been updated.

Depending on how the remote endpoint authentication (both for publishers and subscribers) is designed in your case (e.g. physical security tokens), there could be different restrictions that you may want to impose.


Is WEP still a thing? I was studying the Wi-Fi security section for a pentesting certification the other day and there is an extensive part about cracking WEP. Is going in-depth on WEP cracking worth it anymore?

According to this statistic: https://wigle.net/stats# about 7% of Wi-Fi networks still use WEP for encryption today. It's not a lot, but at the same time it is a lot considering that WEP was deprecated in 2004.

Thoughts?

Unfortunately, WEP is still present in the world. There are legacy systems and devices in certain environments that can only do WEP, plus a number of networks that have no one interested and/or knowledgeable enough to update. Like many advances in technology, phasing out the older technology takes time. Look at IPv4 vs. IPv6 after 20ish years and tell me which is still predominant.

That being said, WEP is no longer viable in modern 802.11 networking. Not only is WEP not viable in modern 802.11 networking, neither is TKIP (was initially used as part of WPA certification). Since the release of the 802.11n amendment to the standard, the use of either requires that devices disable the use of HT or VHT data rates.

In other words, the use of WEP or TKIP causes a modern 802.11 network (i.e. 802.11n or newer) to function little better than an 802.11a/g network. While you do pick up some of the advantages of newer standards, the performance (which is the typical driving force for people to upgrade) is negated.

But all that aside, I have to point out that Wigle's stats are a bit "flawed" unless you actually understand what it is you are really viewing. Wigle is a large, user collected database of information. However, as far as I know, they do not age out old data for a number of reasons (for instance, just because someone hasn't recorded updated information on a network doesn't mean it isn't still present).

So what you have is a large number of networks present in their data that are not present in the real world. If you check many of the WEP entries, they will not have been updated in 5 or more years. Many of these are likely gone or replaced.

In the graph on the Wigle statistics page, they are simply showing the percentage of their database entries that are using the respective technologies. They are not showing the actual technologies deployed in the real world at present. The shown decline of WEP is largely due to new networks being added to the database that are not using WEP, rather than WEP networks being removed from the database. Pulling from the Wigle.net API, these stats may present a more accurate picture of the decline of WEP:

All Entries
-------------------
464,429,878 (Total)
 31,800,699 (WEP)
---WEP: 6.85%---

Updated since 2014
-------------------
343,970,477 (Total)
  8,550,789 (WEP)
---WEP: 2.49%---

Updated since 2016
-------------------
233,996,263 (Total)
  4,374,629 (WEP)
---WEP: 1.87%---

Updated since 2017
-------------------
158,548,717 (Total)
  2,707,548 (WEP)
---WEP: 1.71%---

As you can see, while WEP is still certainly present, the real world statistics of WEP being in the wild is much lower than the 6-7% number to which you were referring.


Why attacker do not care about masking the IP of the infected device of botnet? I get a sentence:

  If an attack is created using a botnet the likelihood of tracking the attack back to its source is low. For an added level of obfuscation, an attacker may have each distributed device also spoof the IP addresses from which it sends packets. If the attacker is using a botnet such as the Mirai botnet, they generally won’t care about masking the IP of the infected device.

Why attacker do not care about masking the IP of the infected device of botnet?

Infected devices are not owned by the attacker. So, it doesn't matter to the attacker if the bots are found.

Mirai was so successful that if a device was found, the attacker could simply get another.

Other botnets might be carefully controlled and tended by the attacker. They might be difficult or costly to maintain or to add new bots. In these cases, the attacker would want to protect it as much as feasible.


Why limit passwords to ascii printable characters? Possible Duplicate:
  Do non-keyboard characters make my password less susceptible to brute forcing?

Every article on password security that I read tells people to make the password more complicated by using a wider range of characters. They say don't only use a-z but also mix in some A-Z, numbers 0-9 and some punctuation. Basically use all of the characters on your keyboard. However, I am building websites designed for a non-English speaking audience. Specifically Chinese users. I have noticed that many Chinese websites also ask for passwords to be made using the same set of characters. I am left with a puzzle as to why to limit to only the core ascii set. Why not use Chinese characters or an other script's characters?

For example, instead of using "!0*%y6#!7N@6" the user could use "胜0屿%y6#!7N景6", which is the same length but significantly more complex.

My application is built in UTF-8 and is compatible with Chinese and other complex scripts. So there is no programming problem for me to allow complex characters in passwords.

By extending the possible character set of passwords to include Chinese, Japanese, Korean, Arabic characters, I can increase entropy of the passwords to incredibly high levels without making the password longer or more difficult to remember. In fact it may be easer of my Chinese users to remember a Chinese password than a English language one. It would be very unlikely that someone could brute-force or use a rainbow table to crack the password.

I can understand the Character set limits on western users where the Characters used are all the ones on a keyboard and it is quite awkward to enter a Character that is not on your keyboard. However, Chinese users have to tools on their system to enter the full Chinese character set so there is no problem for them there.

So to put the question in short. Is there any security issue in allowing users to make passwords from characters beyond the normal keyboard set?

To expand and answer AviD's point below:

When a password is entered, it doesn't remain as characters but is instead converted into a sequence of bits. These bits are the real password. The process of converting characters to bits is character encoding. ASCII is one such encoding, though now rather old and limited in size. Another common one is Unicode which has evolved in the UTF-8 encoding that most websites are recommended to use today.

Unicode and UTF-8 are backwards compatible with ASCII so any ASCII based password would be the same in bits no matter what encoding was used when the password was entered. However there are some forms of encoding that are still popular that are not compatible with ascii many that are not compatible with unicode or UTF-8. These include encoding systems such as Big5 (used in Tiawan and Hong Kong) and GB used in mainland China.

If someone entered their password into a computer one day in one encoding and other day in another encoding then the sequence of bits send as the password would be different.

It is possible to detect the encoding system and convert at the server side. My applications already do that, converting everything that is entered into UTF-8. However, I wonder how perfect that conversion is. Would Big5 converted to UTF-8 give the same result as GB converted to UTF-8?

Additionally, there are some character encoding based XSS attacks that use sloppy character encoding and handling as their vector. Could a similar thing be use to compromise user passwords or my application where no, or little, limits are place on what characters can be imputed?

From a security point of view, it is desirable to have a huge character set to choose characters from, just as you said. The reason why some sites encourage users to stick to ASCII is for technical and organisational reasons:

If the software was written without Unicode in mind or using an environment which does not make unicode totally transparent (such as PHP, old MySQL versions, etc.), it requires a significant amount of work to add Unicode support.

Furthermore if the software is not targeted for the Asian market, the developing company might just not care. It may have no experience and knowledge to test those charsets. Think of resolving combined characters, characters that look exactly the same but have different codes, etc.

This might result in support requests that needs to be handled and therefore result in costs.

tl;dr: If your software can handle Unicode correctly and you can deal with support requests, go for the full range.


These kinds of requests are commonly used for server fingerprinting. By sending a request that is likely to trigger an error other than a common 403, 404, 500, etc. they hope that the site operator did not set a custom error page, and that it will return a default error page with server type and version information. You'll often see really long URLs used to force a HTTP 414 response for the same reason.

As to whether it's malicious; it's probably an automated bot rather than a targeted attack. What they do after scanning is what determines whether it's malicious or not. A lot of the time it's just internet survey bots like Shodan which you don't need to worry about.


Should I reject a CSR when the host emailed me the private key for SSL certificate request? I just requested a CSR from my shared web hosting provider, to generate a certificate which I will send back to them to install. (The certificate itself is to be generated properly by an organisation I work for who can provide certificates for our official use.) The hosting company promptly sent me the CSR but also the private key! They even CC'd someone else, and it's in Gmail so Google has presumably already ingested it for advertising purposes.

In my humble opinion this seems like a terrible thing to do. I am about to write back to them rejecting this one, and asking to renew the CSR and this time keep the private key - private.

Before I make a fool of myself, I'd like to confirm that the private key for an "SSL" (TLS) certificate should never leave the server?

I've been working in security-related industries for many years, and used to be a crypto programmer, so I feel I know the topic a little - but I know things change over time.

I have read this related question:
What issues arise from sharing a SSL certificate's private key?

Meta Update: I've realised I've written a poor-quality question format for Stack Exchange - as it's now difficult to accept a specific answer. Apologies for that - all answers covered different and equally interesting aspects. I did initially wonder how to word it for that purpose but drew a blank.

Update: I have followed this though with the host and they did "apologise for any inconvenience", promised to keep future private keys "safe" and issued me a new, different CSR.  Whether it's generated from the same exposed private key I am currently unsure of. I now also wonder, as it's a shared host, if they've sent me the key for the entire server or if each customer/domain/virtual host gets a key pair.

It's an interesting lesson how all the crypto strength in the world can be rendered null and void by a simple human error. Kevin Mitnik would be nodding.

Update 2:
In response to an answer from user @Beau, I have used the following commands to verify the second CSR was generated from a different secret private key.

openssl rsa -noout -modulus -in pk1.txt | openssl md5
openssl req -noout -modulus -in csr1.txt | openssl md5
openssl req -noout -modulus -in csr2.txt | openssl md5

The first two hashes are identical, the third is different. So thats good news.

Yes, you should absolutely reject the CSR. Additionally, you should change your hosting provider as it looks like they don't know what they are doing.

It is already bad enough that they sent you the private key via e-mail i.e. via an insecure medium. However, they also Cc'ed it to someone else, which is a complete breach of confidentiality.

Furthermore, I wonder why they sent you the private key -- it's supposed to be installed on the server, which is something they can do by themselves.


How long would it take to bruteforce a PGP-Encrypted-Mail? How long would it take to bruteforce a PGP-Encrypted-Mail? If I'm rightly informed, it depends on the bitsize of the encryption Key.

OpenPGP (including the widely-used "GnuPG" program gpg) typically uses two keys when encrypting an email: the content itself is encrypted with a symmetric key (which is randomly generated by the sender), and then the symmetric key itself is encrypted (by the sender) using the recipient's public key. Brute-forcing either of these keys is sufficient to decrypt the message.

However, asking "how long will it take to brute-force a key?" is kind of like asking "how long will humanity survive as a species?". There are some factors we can control today (key size, cipher used, and entropy source), some that we can imperfectly prognosticate about based on past trends (Moore's law, total amount of compute resources available to an individual or an organization, etc.), and some that are basically total guesses that might have a breakthrough tomorrow or might never get further (with specific relationship to the algorithms in question) than they are today (quantum computing, theoretical mathematics, cryptanalysis in general). Finally, who is doing the breaking? The NSA has access to a lot more compute resources, and possibly more advanced algorithms, than either of us is likely to have available. The timelines (for reasonable choices among the stuff we can control today) range from "a few months" to "beyond the heat death of the universe".

A few more specific points:

The asymmetric (public) key used to wrap the symmetric key is probably the weakest point most of the time. People tend to not rotate public keys very often, so they're most likely to have been generated relatively weakly (using strength that was considered sufficient years ago but might not be considered sufficient anymore) or using an old random number generator that was found to have weaknesses. For RSA public keys in particular, see https://crypto.stackexchange.com/questions/8687/security-strength-of-rsa-in-relation-with-the-modulus-size for a discussion of the relationship between key size and amount of entropy. For other public key algorithms, though, the relationship is quite different (elliptic-curve keys, for example, achieve what are considered the same amount of entropy as RSA keys in vastly shorter key sizes).
Public key algorithms in general (and RSA in particular) are also more likely to be vulnerable to quantum computing, if that ever goes anywhere. For a symmetric algorithm, quantum computing would probably roughly halve the effective key length; a quite-secure 128-bit key would become effectively a dangerously-insecure 64-bit key, but a 256-bit key would remain very secure at 128 bits of effective entropy. If you expect quantum computing to go anywhere within the time window that you need your email to remain secure, you may want to treat our current algorithms and recommended key strengths as being as obsolete as Enigma machines.

Some math (and its underlying assumptions):

Assume a modern cryptographic processor can try 2^30 (roughly a billion) keys per second. This isn't too far off from what a typical commercial Intel or AMD CPU can achieve using its hardware-accelerated support for the AES symmetric cipher.
Assume that the attacker has access to a decent cluster of such processors - nothing you'd need to be a nation-state to have, but something a well-resourced individual could assemble or purchase in cloud compute time - of perhaps 2^10 (1024) such processors.
Assume that the increase in compute power per money goes at a rate of doubling every two years (this is roughly in line with Moore's Law, a little lower than it historically ran but it has been seeming to run into limits recently).
Multiply that all up, and an attacker can try 2^40 possible keys per second right now, and that exponent will increase by one every two years.
Assume that if the brute-forcing attempt will take longer than 2^25 seconds (just over a year), it'll be faster/more effective to wait and build the brute-forcing rig with more-advanced future technology.
Assume quantum computing doesn't go anywhere, and there's no major breakthrough in cryptanalysis of the encryption or key-generation algorithms that were used.
Here's how long it'd take to fully brute-force a given key strength (measured in entropy; maps exactly to size for symmetric keys but you'll need to apply the appropriate transformation for asymmetric keys) given the above assumptions:

56-bit key: Less than half a day.
64-bit key: Half a year (starting today).
80-bit key: One year of brute-forcing after 30 years of tech improvement (or roughly 33 thousand years with today's tech).
96-bit key: One year of brute-forcing after 62 years of tech improvement (or over two billion years with today's tech).
128-bit key: One year of brute-forcing after 126 years of tech improvement (or many times the expected lifetime of the universe, with today's tech).
192-bit key: One year of brute-forcing after 254 years of tech improvement.
256-bit key: One year of brute-forcing after 382 years of tech improvement.

Remember that these are numbers for what a moderately wealthy / capable individual could do, and that we're assuming they're willing to work on it for a year per key. A large company, university, or government agency could certainly throw more resources at the problem, cutting the brute-forcing time to a fraction of the estimates above (or cutting a decade or more off the development time... but not both).

Of course, the high-end numbers are totally meaningless here; the sheer number of assumptions of "things continuing as they have" that go into them - including no major breakthroughs that make decryption easier, the continued increase in availability of compute power, and the continued existence of humanity or anything else that would care - mean that they have error bars possibly larger than their already-large timeframes.


Malware, RAT's and backdoors Is there any kind of malware or RAT that cannot be gotten rid of by a thorough wipe with DBAN, flashing the BIOS and re-installing OS? More importantly, if you've been ratted and did all these things, is there still a possibility that the attacker created a backdoor into your system? An explanation of what backdoors usually entail and whether taking the above steps would get rid of them would be appreciated.

Sure it's possible.  Look at the NSA ANT catalog.  You'll find devices like COTTONMOUTH, which are implanted in USB connectors and allow for re-infection; DEITYBOUNCE which implants malware in a Dell server via BIOS and the RAID controller (flashing the BIOS should prevent this); GINSU which installs itself from a PCI bus device; IRATEMONK which is implanted in the firmware of certain hard drives; and IRONCHEF which replaces the BIOS (replacing the BIOS with a variant that reinfects a BIOS during the reflashing operation would be possible.)  And many of their other devices, like HOWLERMONKEY, can intercept your information without infecting your system.

While it may be possible, a second question is "is it probable?"  Is someone as sophisticated as the NSA digging into your computer?  I don't know you, so I can't answer that.  But since the NSA can do it, others have taken this on as a challenge.  The NSA Playset is a collection of Open Source projects that attempt to replicate some of the NSA capabilities.  SLOTSCREAMER is a PCI based attack device; ADAPTERNOODLE is a USB based attack device.  They haven't replicated the hard drive firmware attacks yet, but it's on their list.


GPG unattended ECC key and subkey generation I want to generate an ECC key where the primary key is just for cert and has 3 subkeys for auth, sign, encrypt.

I've found 2 methods to generate it. But I want to use  unattended key generation via

gpg —-batch —generate-key

Work method

Interacitve mode

  In contrast to --generate-key the key is generated directly without the need to answer a bunch of prompts. Unless the option --yes is given, the key creation will be canceled if the given user id already exists in the keyring. -- 4.1.3 How to manage your keys

The following command works in interactive mode

gpg2 --expert --full-gen-key

Key info

sec   ed25519/0x5842AA66BB63DA36 2019-07-18 [C] [expires: 2020-07-17]
      Key fingerprint = FF1F E580 F6D3 453E BA88  DD98 5842 AA66 BB63 DA36
uid                   [ultimate] Name_test (Testing) <email_test@xxx.com>
ssb   ed25519/0x4F33E67F4B554A73 2019-07-18 [S] [expires: 2020-07-17]
ssb   cv25519/0xDE2253D7DAD20F1A 2019-07-18 [E] [expires: 2020-07-17]
ssb   ed25519/0x46A28F2FCC84A822 2019-07-18 [A] [expires: 2020-07-17]

Quick mode

According to

severfault - Add second sub-key to unattended GPG key
4.1.3 How to manage your keys

The following command works in quick mode

gpg --batch --passphrase '1Qaz@wSx' --quick-gen-key "Name_test (Testing) <email_test@xxx.com>" ed25519 cert 1y
fpr=$(gpg --list-options show-only-fpr-mbox --list-secret-keys | sed -r -n '$!d;s@^([^[:space:]]+).*@\1@g;p')

gpg --batch --pinentry-mode=loopback --passphrase '1Qaz@wSx' --quick-add-key $fpr ed25519 sign 1y
gpg --batch --pinentry-mode=loopback --passphrase '1Qaz@wSx' --quick-add-key $fpr ed25519 auth 1y
gpg --batch --pinentry-mode=loopback --passphrase '1Qaz@wSx' --quick-add-key $fpr cv25519 encrypt 1y

Key info

sec   ed25519/0xE8C6CF665ACABDB6 2019-07-18 [C] [expires: 2020-07-17]
      Key fingerprint = 03A9 E9BD CF6A BF7F 62B4  BBDA E8C6 CF66 5ACA BDB6
uid                   [ultimate] Name_test (Testing) <email_test@xxx.com>
ssb   ed25519/0xBA77943ABAE5F238 2019-07-18 [S] [expires: 2020-07-17]
ssb   ed25519/0x7272CF7C764BDB9E 2019-07-18 [A] [expires: 2020-07-17]
ssb   cv25519/0xB42F8319BA8D0CBE 2019-07-18 [E] [expires: 2020-07-17]

Unattended generation ?

I read How to batch generate ECC key, the config inside works.

Config contents

%echo Generating a OpenPGP key
Key-Type: eddsa
Key-Curve: Ed25519
Key-Usage: cert
Subkey-Type: ecdh
Subkey-Curve: Curve25519
Subkey-Usage: encrypt
Subkey-Type: eddsa
Subkey-Curve: Ed25519
Subkey-Usage: sign,auth
Passphrase: 1Qaz@wsX
Name-Real: Name_test
Name-Email: email_test@xxx.com
Name-Comment: Unattended Testing
Expire-Date: 0
%commit
%echo done

I get the error message

duplicate keyword

If I set Subkey-Usage: sign,auth,encrypt, it displays the error

specified Subkey-Usage not allowed for algo 18

This is because cv25519 for encrypt, ed25519 for cert, sign, auth.

If I just set

Subkey-Type: ecdh
Subkey-Curve: Curve25519
Subkey-Usage: encrypt

it works.

If I set

Subkey-Type: eddsa
Subkey-Curve: ed25519
Subkey-Usage: sign, auth

it also works, but sign, auth are listed in the same subkey.

How should I change the config file to make is work?

In the section above "Unattended generation" you list "Config contents" to batch generate a master key and then provide details for TWO sub-keys.

When the facility for batch file processing was added to GnuPG, the batch generation of a master key with only ONE sub-key was provided.

https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html

          "Currently only one subkey can be handled."

This is why you are getting the error message "duplicate keyword".

In order to add multiple subkeys to a key via a script, there is no builtin script support and you should take a look at the solutions provided at

https://serverfault.com/questions/818289/add-second-sub-key-to-unattended-gpg-key

There is also a further difficulty concerning ed25519.  Creating an ed25519 key or sub-key for "encryption" is only possible with GnuPG v2.1.7 and an ed25519 supporting version of libgcrypt.

https://www.gniibe.org/memo/software/gpg/keygen-25519.html

So unless you are using GnuPG v2.1.7 (with suitable libcrypt) trying to create an ed25519 key or subkey for encryption is going to fail with an error message.


Someone uses my service to spam people with sms. How to deal with this? Every time when user wants to login to my service it sends one time password (OTP) to the user's phone number, then this OTP is used to confirm login.
Someone uses my service to bombard people with sms notifications.
I already implemented various blocks:

no more then 1 OTP per phone number per minute
no more then 5 OTP per IP per minute

What else can I do? Will captcha work?

Consider the use of dynamic IP address blocking - I have a good amount of success with the following two free services:

https://sigs.interserver.net/ipslim.txt
https://api.abuseipdb.com/api/v2/blacklist this one requires the use of an api key, and update frequency is limited to four per 24hr period

The following command uses curl to connect to the AbuseIPDB, authenticate with the account token, and then download the result, with various parameters set according to the API documentation
curl --fail --write-out '\nCURL_%{http_code}+'$(date +'%Y%m%d%H%M%S') --silent --tlsv1.2 -H "Key: 7d467ef655e91e7db69f2078df1b0c2ccefb8eedc0372e9187b0d211aa1f336b73271e145f12aebc" -H "Accept: text/plain" -d countMinimum=15 -d maxAgeInDays=5 -d confidenceMinimum=90 -G https://api.abuseipdb.com/api/v2/blacklist

I access these services periodically, to extract the contents in the database, and create blocked ip address records as files within a tiered directory structure on the file-system: /OCTET1/OCTET1.OCTET2/IP4ADDR (dotted decimal). If the entry already exists, I touch the file again to update the metadata. Over time, this builds into a useful database.
Note to self: edit this answer to include the bash commands that prevent unbounded growth of the blocked ip files db...
In the context of Litespeed webserver running on Cloudlinux, I use .htaccess files to check to see if the remote ip address exists in a file on the file-system (representing a blocked address).
SetEnvIf Remote_Addr  '([0-9]{1,3})\.'              USR_RADDR_ONE=$1
SetEnvIf Remote_Addr  '([0-9]{1,3}\.[0-9]{1,3})'    USR_RADDR_TWO=$1

ErrorDocument 410 'Your IP address exists in an automated blacklist: connection refused.'
RewriteCond /etc/._ipblock_rbl/%{ENV:USR_RADDR_ONE}/%{ENV:USR_RADDR_ONE}/%{REMOTE_ADDR} -f
RewriteRule ^ /e410_deny_%{ENV:USR_RADDR_TWO} [G]

I can't take credit for this idea, which stops about 50% of our traffic at the gate, and hasn't resulted in a single complaint to request unblocking, in nearly two years of production use. I wish I could find the reference to the source, a European(?) German(?) author of a .htaccess help site ?? If anyone knows, could you please edit or comment? thanks!


Are there technical differences which make Linux less vulnerable to virus than Windows? What makes Linux so different than Windows in terms of anti-virus needs?

My question is not if I should get an anti-virus for my Linux. I perfectly understand why an AV is important.

I would like to understand if there are conceptual (technical) differences which make Linux less vulnerable than Windows (comparing for example Ubuntu 14 and Windows 7).

There are several reasons why Windows is so heavily inflated with anti-virus products. (I am pointing to out-of-the-box (OOTB) experiences).

Windows users are, by default, local administrators, so any social engineering done on Windows can usually lead to an execution of software. Modern Linux has users set-up as low-privilege local users. It requires your password to elevate privilege.

Windows tried to simplify as many things as possible including security and looking back at its history their butchering (Windows Vista anyone?) of security controls left their user-base numb to constant false positives about software. The proverbial "Do you want to install this software? Do you REALLY want to install this software?" lead to just click-throughs or disabling UAC.

Software repositories vs standalone installs:

Linux has had software repositories forever and they provide a good mechanism for installing software. These are usually signed, approved, software being protected by companies with budgets for security following standards for security. (I know about the breaches to repositories in the past, but this is generally good). Windows users are used to pulling sources from everywhere and installing on their system, unsigned or not.

Users generally have different mindsets:

Windows is an all-purpose, all-user platform. It generally tries to solve everyone's problems and in doing so, OOTB doesn't protect the user like it should. This why Microsoft pushes so hard to force every piece of software to be signed by a "trusted signer". There's plenty of debate on this, but generally from a security standpoint this is smart; Microsoft just happens to have a track record that leaves trust to be desired.

Linux users are generally technical and the systems are usually server systems. That's why software usually comes with GPG keys and/or SHA/MD5 hash for comparison, as these are from a Linux administrator perspective, de-facto processes for installing software. I know many Linux users who ignore this, but I have yet to see a Windows administrator even think about it.

So it does go beyond market share.

Expansion:

I will address a few things from the comments (which have valid points.)

Repositories:

From an OOTB experience modern Linux distributions have pre-signed packages which are more for identifying that a package works with the distribution, but also proves a secure method for verification.

Other package management system have been discussed such as pip and npm which are independent of the distributions themselves and are servers to install specific packages for their particular programming language. It can be argued that there is no inherent way for verification on these systems. This is primary because Linux has a philosophy of programs doing one specific thing and doing it well. This is typically why multiple tools are used such as using GPG or PGP for integrity.

Script Downloads

cURL | sh has been mentioned and are truly no different than clicking on a .exe after you have downloaded the file. To point out, cURL is a CLI tool for transferring data. It can do authentication, but it doesn't do verification specifically.

UAC vs sudo

Lastly, here are a few things about these two security features.

UAC is an approval process for untrusted software installation. A user which has local administrator rights simple gets a yes or no (the behavior can be changed, but it's not default). I am still looking to see if this behavior has changed on Windows 8+, but I haven't seen anything on it.

Sudo is a fine-grained permission elevation system. By default it's essentially the same thing as UAC, but it has more ability to be configured to limit accessibility.