Testing Digital signature on an incoming request via Apache I am creating an API endpoint that receives payload from a third party. The third party is signing the request with there X509 Certificate(Private Key). I have been provided with their Public Certificate. How do I verify that the incoming request has a valid Signature using the Public Certificate that I have via Apache?

I have tried a few of the things, which is not working:

I kept SSLVerifyClient require along with SSLVerifyDepth 10 in the Apache httpd config, and then kept their client certificate in the trusted Store.
I kept SSLOptions +ExportCertData and verified SSL_CLIENT_CERT Environment Variable at the application end whether I am getting there Client Certificate in the Request that I am receiving. Although the Environment variable does not have any Cerificate in it.

How can I verify the Signed Request? Please guide me if I am looking into a wrong direction in order to verify the Request.

The digital signature of the payload is from Docusign as you've stated in a comment. This payload signature is unrelated to HTTPS and thus can not be verified at the HTTP level in Apache. This means any attempts to use SSLVerifyClient or similar will not work.

From a short look at their documentation it does not look like that DocuSign employs some standardized signature format everybody could verify. Also their API and SDK seem to offer signing only but not signature verification. It might be part of their business model to control this part. But for more details look at their API documentation yourself (maybe I've missed something) or contact Docusign.


Secure application data I have a private client/server application that trying to secure the data transmitted through public network.  The encryption/decryption method is private too.  Client and server uses DH key exchange to agree a small size (8 bytes) session data key.   This 8-byte session key is used to encrypt/decrypt the data.
Since Encrypt/Decrypt method is private (derived from TDES), how secure is the data in public network?

If by "private client/server" you mean "nobody but me has access to them", what you're doing seem to be overkill. And since your Encryp/Decryp method is private and derived, it may weaken the encryption if not implemented correctly.

This seem to be a classic case for a symmetric key encryption; just generate a 128/256 bit master AES key, and embed it in both binaries. Generate an encryption key+IV on client, and send it to the server with a checksum, encrypted by your master AES key. Then use it for communication. No need for DH.


Risk of running services on ports >1024 In a Reddit thread on securing SSH access to a Raspberry Pi, one commenter recommended running SSH on a non-standard port of 8123.

Another commenter had this to say on the matter:

  Don't change your SSH listening port to anything >1024. An unprivileged rogue process can wait for the SSH daemon to terminate and establish a listening socket on that port. Ports <1024 are reserved to processes running as root.

I personally do not feel this is a significant risk with SSH as:

The rogue process cannot access the host keys, so would present a
different fingerprint to the user when connecting, alerting them to
an issue.
If key based authentication is in use, little can be
gained from intercepting communications.

However, not all protocols have this functionality. For example, web proxies running on port 8080 or 3128 generally have no authentication.

How significant is the risk of running on a port number > 1024?

Services running on ports < 1024 (at least on *nix servers) are generally considered to be more secure, because they require root (or a trusted user that has root privileges) to start them - whereas services running on ports >= 1024 could be run by an untrusted (possibly rogue) user on the server.

So, it is plausible that an attack like the one described in the reddit post that you copied could be pulled off by a malicious user on the server, without root privileges.

With regard to "1.The rogue process cannot access the host keys, so would present a different fingerprint to the user when connecting, alerting them to an issue.":  This is true - if a user had logged into the server previously, and his SSH client pinned the server's public key.  In this case, the user's SSH client would (presumably) warn him that the server's public key has changed, and the user would (presumably) know that something's up.  But, the user would only be warned if he had logged into the server previously and his client pinned the server's public key.

With regard to "2.If key based authentication is in use, little can be gained from intercepting communications.": I'm skeptical about this.  The user's SSH client would send its public key, as usual during the start of an SSH session, then the rogue SSH server could simply authenticate the client (as is normally the case when the client's public key is present in the server's authorized_keys file) and proceed with the session using the public key that the client sent.


How would someone find a phone number after they change it? Not sure if this is the place to ask this, but can't find a better SE section to ask on. I've been trying to help someone with securing someone's relocation from a domestic abuse case.

After changing this person's phone number, in under an hour, the spouse on the other end was able to continue calling that new number. As far as we know, we are the only people who know of the phone number change other than the service provider themselves. The phone is an iPhone 6. How would someone have gone about doing this, assuming no associated people have told the spouse the number and the spouse also did not have access/credentials to the service provider account that the number was associated with? And, what further precautions should be taken to prevent this from happening again with another phone number change?

The service provider can sometimes retain that same number, and when a person attempts calling it again the service provider may redirect the call to the new number, as they would assume the person calling is trying to get in contact with the person whom changed their number.

A precaution would to be to contact the service provider (assuming you are a legal figure) and tell them to disallow any further phone number changes.


Does Git usage raise a valid security concern? If so, how? This is about pure-and-simple Git; NOT the security concerns of using third party services like Github or Gitlab.

While working on a closed source security project, during a meeting, one of the senior developers on a sister team implied that Git makes code less secure, especially with security-related products. This was pretty shocking for me to hear, and quite frankly, I don't believe it. (And yet this strange viewpoint from the senior developer was not met by clear and immediate incredulity by others present.) This senior developer did not comment further, and does not work in the same location as me; and is generally pretty unreachable. (I also don't want him to think I'm trying to discredit him, but rather seek to understand.)

And so I now question my understanding of the security of Git, however baseless it may be.

Is there one or more valid security concern(s), however obscure, about using Git?

Aside from the fact that git is a program, and any program can have bugs, the only issue I can think of is the fact that git uses SHA-1, which has been recently shown to be vulnerable to a collision attack, which has some impact on git. The transition away from SHA-1 to a more secure and modern algorithm is being discussed. However, collision attacks against SHA-1 are still incredibly difficult to achieve. Furthermore, existing collisions can be detected, as GitHub currently does.

Overall, I would say that the senior developer either does not know what he is talking about, or is of the opinion that git makes programmers "lazy" (a somewhat common but misled opinion). Or it's possible that he is under the incorrect impression that SHA-1 is vulnerable to preimage attacks.


My school wifi asks to 'trust' a certificate on iPhones. Does this allow them to view SSL traffic? There is a lot of confusion around this on here, so I am making this post to be sure to understand it correctly. My school uses Aruba networks wifi, and after I type my Active Directory username and password (RADIUS authentication), it tells me I have to trust a certificate from 'wifiaruba.myschoolname.com' (Organization: My School) issued by DigiCert SHA2 High Assurance Server CA (Issuer Name, at least that is what the certificate says). I click trust and it goes away. My phone does not trust this by default it seems. Is it because this theoretically allows my school to decrypt SSL communications? If it really were from DigiCert, surely my phone would trust it?

It's ok. The certificate you installed and trusted is used to provide you secure authentication against their RADIUS server and prevent you from connecting to rogue RADIUS server. If someone decides to steal your Active Directory credentials by installing a rogue RADIUS server your phone will pop up with a warning that RADIUS certificate is not trusted.

By trusting this certificate you are not risking with anything else. This certificate can't be used by school to read your SSL traffic or attempt to MITM your SSL traffic. From what I read in your question, your school does it correctly and cares about your security.

Regarding your question: why your phone does not trust that certificate (which is certainly issued by trusted authority). RADIUS requires explicit trust to particular RADIUS authentication certificate, because you don't know what AP you are connecting to. Otherwise, an attacker could get certificate from other trusted CA vendor (say, Let's Encrypt) and use it to impersonate school RADIUS server and steal your credentials.

This is not an issue in SSL context, because you know what kind of certificate you expect, because you manually type web site name in address bar. In wi-fi don't know to which AP you are connected and to ensure that it is legitimate, AP should provide RADIUS certificate you explicitly trust.


What are the implications of using an "unsafe" DNSSEC algorithm like RSA/MD5? Why is it unsafe to use the DNSSEC algorithm RSA/MD5?  In practical terms, how is DNSSEC weakened by the use of an algorithm such as MD5, which has a known weakness of collisions?

RFC 6944 states, under chapter 2.3 DNSSEC Implementation Status Table:  "Implementation status: Must Not Implement" about RSA/MD5.

Furthermore the RFC states:

  4. Security Considerations

  This document lists, and in some cases assigns, the implementation status of cryptographic algorithms used with DNSSEC.  It is not meant to be a discussion on algorithm superiority.  No new security considerations are raised in this document, though prior description of algorithms as NOT RECOMMENDED (see [RFC4034]) has been recast as Must Not Implement.

This is still a matter of debate, see for example recently: https://www.ietf.org/mail-archive/web/dnsop/current/msg19820.html
(and https://www.ietf.org/mail-archive/web/dnsop/current/msg19868.html )
In the sense that there is no known public attack against DNSSEC that is based on MD5 weaknesses (or SHA1 for that matter).

However, the IETF has clearly said that MD5 should not be used anymore, see RFC6151 :

  MD5 is no longer acceptable where collision resistance is required
     such as digital signatures.  It is not urgent to stop using MD5 in
     other ways, such as HMAC-MD5; however, since MD5 must not be used for
     digital signatures, new protocol designs should not employ HMAC-MD5.

For example, since the DS record is an hash of the key, if an attacker can construct a new key with the same hash as an existing DNSKEY in the zone, he would be able to deliver falsified but correctly DNSSEC-signed records.


Does my server need to fulfill PCI compliance if it only forwards the credit card number? I'm currently trying to implement a payment system (braintree) but I'm not entirely sure how this is supposed to work.

What I hope it works like:

User selects a product and clicks on "buy"
User enters a credit card to pay with and clicks "okay"
My client sends the credit card information to my server
My server forwards this to braintree (or paypal) and I get back a credit card ID token
Using that token I sign an agreement for the user, the credit card and my recurring billing plan and I notify the client whether it worked or not
User sees on the client that it worked and starts to enjoy the service

So, I don't want the user to require something like a PayPal account if possible. I'm also still not 100% sure how the braintree API works but from the looks of it I can create a Customer which has multiple credit cards. However, I'd need to transmit the credit card to my server which only forwards this information to the custodian.

If the answer to this is "yes, your server has to fulfillthe PCI compliance" then I'd like to know if it's actually possible to have a payment system that does not require a user account at the custodian.

Yes, your server as described has to be PCI compliant.  However, most processors support modes of operation, different than you describe, which will limit your scope*.

You say:

  My client sends the credit card information to my server
  My server forwards this to braintree (or paypal) and I get back a credit card ID token

If the credit card data is transmitted, stored, or processed by your server, then you server is in scope, and you are subject to a reasonably large set of PCI compliance such as SAQ C or SAQ D.

However, most processors support iframe and/or javascript technologies that will allow your server to be removed from the loop - the client sends their card data directly to the processor, and the processor hands them some chit which they can hand to you in lieu of a credit card to carry on the purchase.  You, in turn, cash in that chit to get a token representing the card data that they handed the processor.

When such a technology is in use, and insulating your systems from any direct involvement with card data, then your compliance requirements drop down to SAQ A or SAQ A-EP.

You should ask your processor "What offerings do you have for tokenization that will allow me to keep my servers out of scope and reduce my PCI compliance requirements?"  (If they say "huh?", find a new processor.)

  [if so, is it] actually possible to have a payment system that does not
  require a user account at the custodian.

No.  If you are allowing a processor to handle cards for you, then you must give them a bank account for use in transferring funds to (e.g., purchases) and from (e.g., chargebacks) you.  And when they want the bank account, they're going to want all sorts of tiresome information like who you are.  The processor is, in fact, sponsoring you into the card network.  They are liable for your debts if you behave poorly.

(And that's true whether they're managing the actual card data for you (tokenizing) or just processing transactions... Credit card numbers are not useful without processing by the card network; you can't charge them without a connection to the system, and the system isn't designed for anonymous members.  If you want anonymity, charge in Bitcoins or Simoleons instead of credit cards).

*If your business is accepting credit card payments, you're bound by PCI, even if you don't touch the actual credit card data yourself.  The best you can do is reduce your scope - if you are subject to SAQ A, for example, you'll have ~15 requirements instead of ~300 for SAQ D.


Could Diffie-Hellman be used to stop people who knows the PSK from snooping on your WiFi? One known problem with WPA2 is that anybody who knows the preshared key can snoop on the handshake and decrypt all subsequent traffic between any parties on the network. In the typical coffee shop scenario, where anybody who is willing to pay $2 for a coffee can get the PSK, this is a big problem.

Could Diffie-Hellman be used to mitigate this problem? In my understanding, what DH boils down to is a way for two parties to share a key without ever having to send it over the wire. Or as Wikipedia puts it:

  Diffie–Hellman Key Exchange establishes a shared secret between two parties that can be used for secret communication for exchanging data over a public network.

So my questions are:

Could DH be used to stop people who knows the PSK from snooping on your WiFi?
Are there any downsides to this that explains why it is not used in WPA2-PSK?
Are there any WiFi protocols that uses a solution like this?

In creating WPA2-AES, priority was given to 1) using the passphrase to ensure that the client was authorized to use the system, and 2) ensuring that there was no way for the client to inadvertently expose the passphrase to someone posing as the host. It succeeds at these two things. It was not created with the intention of providing full secrecy between clients, since they are often sharing the same layer two network anyway.

As your summary states, DH is designed for establishing an encrypted tunnel between any two hosts via a handshake that is (at this point) invulnerable to third party snooping. It does not provide authentication however. In order for WPA2 to take advantage of this it would need to execute the entire DH exchange, and then perform the WPA2 4-way handshake so that it can authenticate the client while still making it impossible for a malicious host to pick up the passphrase from an unsuspecting client trying to connect.  However, in executing the DH exchange the client still hasn't validated the host.  It would still be possible for a man in the middle to pose as the host, perform the DH exchange, and then pass the encrypted traffic on to the actual WPA2 host to perform the 4 way handshake, rendering the additional DH step useless.

WPA2-enterprise (using 802.1x and radius) allows for each client to create a passphrase and ultimately a key that is unique to their connection, providing inter-client secrecy.


Are these email captchas legitimate? The last week, I've been getting this kind of emails to addresses that I don't use:

  Dear Sir, Madam,

  For security reasons and as part of our ongoing fight against spam, it is our policy not to accept e-mail from unrecognized outside vendors.

  You are receiving this message because it is the first time that you have sent me an e-mail message.

  To ensure that your message is delivered to me, simply : click here to forward the e-mail.

  This identification step needs only to be completed once. All your future messages will come straight to me.

  Thank you very much for your help in the fight against spam.

  Sincerely yours,

I suppose it's just a trick to verify that email addresses are in use, or even to solve some captchas. Is there any program that actually does this, or can I safely ignore the emails?

This is almost certainly a scam, using the concept of "spam protection" to try to lull you into a false sense of security.

The email is likely one of three four things:

Spammers looking for real (active) email addresses, so they can focus their efforts.
Spammers using you to solve their captchas for them. Pretty sneaky!
A site stuffed with browser exploits, aimed at getting malware onto your box.
Phishing for personal details. Notice that they said the "identification step needs only to be completed once", implying that they're going to ask for personal details.

Each are viable, but I think #2 or #4 are probably most likely.

Either way, just delete them.


Is NAT Loopback on my router a security problem? Some DSL routers prevent NAT loopback. Security is sometimes cited as the reason. Is NAT loopback really a security issue? And if so, how is this exploited?

NAT loopback... where a machine on the LAN is able to access another machine on the LAN via the external IP address of the LAN/router (with port forwarding set up on the router to direct requests to the appropriate machine on the LAN). Without NAT loopback you must use the internal IP address of the device when on the LAN.

EDIT: The mentions of security are admittedly from unofficial sources, which is why I would like to clarify this...

From the BT Community Forums:

  This is not a fault. Most routers will not send out and receive data
  on the same interface (Loopback), as this is a security risk.

And further down the same page, from the same user:

  As a network engineer I work with Cisco and Brocade routers daily and
  these will not allow loopback due to the inherent security issues. BT
  have adopted an approach that security is very important and as with
  enterprise class routers, loopback is not permitted.

From a page on NAT Loopback Routers:

  Many DSL routers/modems prevent loopback connections as a security
  feature.

To be honest, up until now I have always assumed that failure to support NAT loopback was simply a failure in the hardware/firmware, not a 'security feature'?! It's omission is a far greater problem IMHO. (If you hadn't guessed, my router does not support NAT loopback.)

Most consumer grade routers don't have any prohibition against it, it just doesn't work.

Imagine the following scenario. This isn't hypothetical, just run tcpdump on your own computer and you'll see it happen right now. Captured from my Buffalo ddwrt moments ago just to verify.

Players: [Router: 10.0.0.1]  [Computer1: 10.0.0.3]  [Computer2: 10.0.0.4]
Outside IP: 99.99.99.99, forwarded to Computer2

Computer1 to Router  [10.0.0.3 -> 99.99.99.99]
Router uses DNAT to change the destination to 10.0.0.4 and pushes it back to the local network:
Router to Computer2 [10.0.0.3 -> 10.0.0.4]
Computer2 attempts to respond to the packet by sending to the source IP.
Computer2 to Computer1 [10.0.0.4 -> 10.0.0.3]
Computer1: WTF?
Computer1 was expecting a reply from 99.99.99.99, got one from 10.0.0.4 instead. Addresses don't match, connection failure, RST packet sent back.

Now, you ask, why doesn't the router SNAT the connection from Computer1 to the router's internal IP when it DNATs it to Computer2? Because the SNAT rule would make a mess of all the rest of the traffic which doesn't follow the pattern above.

SNAT really should only be used in one direction unless you're willing to put a lot of time and care into crafting and maintaining a NAT ruleset that won't bite you.

And to preempt anyone who says how about this:

iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -d 10.0.0.0/24 -j MASQUERADE

I would point out that this rule would affect not only to NAT-loopback traffic, but also to bridge traffic (e.g. WiFi network to Wired network), which would make a WiFi router frustratingly broken. The rule would have to be tailored to match ONLY the loopback traffic, which is slightly more tricky and probably involves marking packets. Not impossible, but not the sort of engineering and debugging that goes into most routers; and certainly fraught with peril.

Glossary:
SNAT = Source NAT (changing the source IP)
DNAT = Destination NAT (changing the destination IP)
NAT = Network Address Translation


Is there a hard-to-spoof identifier associated with a physical hard disk I would like to salt the pass phrase with the drive id in such a way that, if the disk were imaged to a new drive with a different id, (e.g. by a government forensics specialist) then the image would be unusable even with a correct pass phrase.

NB: Which hard disk encryptions schemes are tied to the original hardware? asks exactly the opposite question.

There is no benefit to using physical disk information as a salt. It's security by obscurity. The forensics specialist could just hard-code the previous drive's information into the decryption software.


How to open a file from the Internet in a secure way? Sometimes I have to open files (doc, zip, txt, pdf and some other) downloaded from the Internet (from unproven sites) on my computer.

How could I mitigate the risk and open them in a more or less secure way?

What types of files are more insecure than the other?

What I can suggest:

open files inside VM's if it is possible, or, as @Henri said, use sandbox;
run AV software, at least it adds some security level;
you can use online AV scanner solutions like virustotal.com;
never trust any file from any source - friends can also be compromised, they can spread malware without their knowledge;
use updated software;

You should take into mind that software does not guarantee 100% protection. Only right policy and your experience can help to decrease risk and mitigate attacks.


Kali.download website blocked by Kaspersky because of Trojan, is it safe? So when I tried to dist upgrade my Kali, at the end my Antivirus blocked it from downloading from this website

Do all Kali Linux operating systems try to download from this webpage (http://kali.download) or something malicious is going on?

Is it safe to turn off my Antivirus and continue downloading?

Why does Kaspersky think there is a Trojan in this link?  This is the error:

Download blocked;
http://kali.download/kali/pool/main/m/mimikatz/mimikatz_2.1.1-20180925-0kali1_all.deb//data.tar.xz//data.tar//./usr/share/mimikatz/Win32/mimidrv.sys;
Trojan-PSW.Win32.Mimikatz.gen;http://kali.download/kali/pool/main/m/mimikatz/mimikatz_2.1.1-20180925-0kali1_all.deb//data.tar.xz//data.tar//./usr/share/mimikatz/Win32/mimidrv.sys;
VMware NAT Service;
Trojan program;10/13/2018

Object-name : Trojan-PSW.Win32.Mimikatz.gen

Kali has many tools that are legitimately malicious tools. So, it is not surprising that Anti-Virus would detect and block those tools.

Mimikatz (the thing you listed as being blocked) is a tool on Kali and is a very powerful malicious tool.

We cannot say whether that particular download location is safe. It seems to be a domain run by Cloudflare, but it is not TLS protected, which is strange. There is a TLS version of the URL, though (certificate from Cloudflare).

We also cannot say if turning off your Anti-Virus is a safe. But what it is detecting is expected and normal for what you are downloading.


How can I securily use a pre-owned smartphone? Is there a feasible way to safely use a pre-owned smartphone?  For a PC/Laptop I would simply shred the contents of the hard disk drive before creating new partitions.  If feeling paranoid, I might even flash the BIOS (see also this question).  I'm considering to buy a used smartphone (for environmental purposes), but how would I make sure it is free from any irregular spyware (apart from the standard Google stuff)?  Can I take the same approach as for a PC and still use it as a regular smartphone after?  Rooting would give me "similar access to administrative (superuser) permissions as on Linux", although in reality I don't need root to shred a PC as long as I have physical access, although it may be harder to exploit physical access to a smartphone than for a PC.  Naively, I would expect:

Shred the contents of any read/write-storage on the smartphone, either by mounting it on Linux (assuming I get access to all storage media that way), or by booting it into the right mode (assuming I can get into the bootloader — perhaps I can boot into a custom OS from an SD-card?);
Repartition the disk (remark above applies);
Install a version of Android on the disk, presumably with something equivalent to a distribution so I have a kernel and a minimum of software for it to function;
Reboot and use it as if it was new.

Are such or equivalent steps feasible for an ordinary user with moderate technical know-how?  Or am I totally on the wrong track as far as making a pre-owned smartphone safe to use is concerned?

For the purposes of this question, assume a smartphone designed to run Android and released in 2015 or later.

Depends on the risks you are trying to mitigate. General rule of thumb is that once the evil maid has access to the end point, it's not a trusted platform.

Free from irregular spyware and presumably no other untrusted devices
on the handset. The risk is to the confidentiality of your data
mainly I think.  There is some risk to integrity and some to
availability but I think mainly its confidentiality.
Risk to your
personal freedoms.  There is a chance that the phone was used by a
criminal or actor being investigated by an agency.  Your phone will
have the same IMEI and therefore there is a risk that an agency might
want to speak with you and ask you to prove that you were not the
original owner.  Probably low impact to you, but no way of knowing
who comes a-knocking.
Risk to availability.  Battery. Dead. No call.
Risk of "I just can't get the damn thing out of Chinese/Russian/French/Yahoo mode".

If the phone you buy is rooted then, meh, game over.  There is practically no way you can know what is on the phone or what has been installed.

If it has not been rooted then later versions of Android claim to factory reset everything. But there is some research link to suggest that this is not the case and there there is data remanence after a reset.  You could flash from a known-good ROM but even then you can't know for sure if your specific hardware hasn't got something lurking.

So to answer your question, the answer is : Probably.

If you only use the phone for making calls on a PAYG contract then your maximum exposure is your remaining credit plus your call history. A factory reset is OK because low likelihood x low impact = low risk

If you use your phone for secret squirrel work then nope, you can't use it.  That's why UK Government has Good Practice Guides on the re-use of devices and the sanitisation required between users or different threat levels. Low likelihood x very high impact = high risk, plus it's government so no choice.

If you use it for calling plus some interweb stuff then it's possible your phone has a backdoor but it's very unlikely.  Not a probability of zero but close to it (happy to see some real peer reviewed data on the number of second-hand phones on sale with malware that has persisted over a factory reset though, as I could be wrong).  Add in that you will only be buying a second hand late model with some of the later protections then the low probability x medium impact = low-medium risk offsets the currency.

(In my final analysis and IRL for me the battery life makes it almost uneconomic for me to bother with a second hand phone because a battery is typically rated for 10,000 cycles which is about two years after which you have to buy a new phone anyway.)

edit: see this SE question
Cambridge University paper on Android factory reset still up to date?


precautions before conducting a penetration test According to me, The key here is to use virtualization. This is a main precaution that allows safe handling (isolation) of systems that could otherwise be exploited and leveraged as jump points into an organization infrastructure.

The point of a penetration test is to test a company's actual infrastructure as if the pentester were a real attacker. This way, the penetration tester can find security issues that the company has been unable to find by itself. Pentesters oftentimes find "bugs" in things that aren't software: some test physical security and social engineering as well.

While hacking into virtualized systems that are separate from the organization's actual infrastructure might be useful, it isn't a penetration test in the traditional sense.

Since the penetration tester is being paid by the organization they're hacking into, they're not going to do something that would actually harm the organization. Once they find a foothold into a system, they might exploit it and continue further inside the organization's infrastructure. However, they won't actually steal data or install malware like a real hacker would. The pentester usually has a contract that prevents them from being sued if something bad happens, but they'll still do their very best to avoid causing actual damage.


VPN on laptop/PC monitoring I work from home and use a VPN to connect to work.  Can my company tell which time I'm using my laptop and which time I am using my PC?  Is this something easy for them to check?  The VPN is through Citrix.

The VPN client can check your hardware, record asset information and provide that information to the VPN concentrator.  Often this is used to ensure you're patched, have antivirus and are using a corporate asset.  It sounds like your company isn't checking for corporate owned assets and is expecting you to use personal assets.  Although they won't flag you for connecting with a personal asset, they will be able to tell that you're using two different machines.

http://blogs.citrix.com/2013/12/10/netscaler-gateway-advanced-end-point-analysis/

If you have a legitmate business need to use both machines, ask them, else they might freak out when something else creates an indicator, e.g., you accidentally connect twice.


Suricata Signature Explanation I am trying to figure out some Suricata(or Snort) signatures, more specifically, what they mean, what they prevent and have some problems about meanings of keywords. I will not write irrelevant parts.
For instance:

 ...flow:established,to_server;  content:"/advert/get"; nocase; http_uri; pcre:"/\/advert\/get(?:ads|kws)(?:\.cgi)?\?(?:d|[ex]_dp_)id=/Ui";  classtype:trojan-activity; sid:2013983; rev:6;)

  "Produce alarm if payload contains /advert/get path and matches with pcre expression"

Which part exactly should pair with that regular expression? URI itself(advert/get) or after /advert/get/..... ?

Second one,

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

  "Produce alarm if http request method is post and payload contains /check.php?tcpc=" .

What does second content catch? I interpreted as "produce alarm if user agent is not empty in http header" Is it true?

And as a last one, assume you have multiple contents like

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

Should I interpret as "and" or "or".

  "Produce alarm if content contains &AFFILIATE AND &ID AND &ERROR" Is it sensible?

I am very confused and its documentation doesn't help, so any answer or resource that explains content more detailed would be awesome.

You have interpreted the first one correctly.

The second one:

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

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

Third one:

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

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

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


What is the connection between CORS and SameSite cookie attribute? For most of them may be its a silly question but I want it to know this in very simple language.

If an application is not using CORS at all then should we put this SameSite cookie attribute?

and if Application has subdomain like abc.domain.com then what is the role of Samesite attribute ?

If an application is not using CORS at all then should we put this
  SameSite cookie attribute?

In a very simple language as you requested, YES.

  if Application has subdomain like abc.domain.com then what is the role
  of Samesite attribute ?

Irrespective of domain and subdomains CSRF attacks will be able to originate the request from the browser to do an action on behalf of the user without knowing the cookie of the user. Samesite attribute can effectively protect against CSRF attack. There are other ways to protect against CSRF too but this is one of the easiest and recommended way to do it.


No Cipher Suite In common When i'm trying to intercept the mobile traffic using burp suite. Getting this error "No Cipher suite in Common" I tried to add all the available cipher suits in the burp but still getting this error. (i.e I'm trying to intercept instagram and facebook traffic)

Is this related to Certificate Pinning ??

Burp relies on the underlying Java platform for all key handling algorithms and SSL ciphers/protocols, so Burp will be constrained by whatever is available in your installation.

Are you using the latest version of Burp (2.0.12)? We made some changes to try to ensure that all available SSL ciphers are made available to Burp. Also, if you are using the plain JAR file, please try the platform installer, which comes bundled with its own JRE.


GPG key expiration and storage I hope I came to right place to ask about GPG.

I have created secret, public, and sign keys and set expiration dates for all keys in case I lose an access to them or forget a keyphrase, etc. I have read the GPG manual and a couple of blogs (e.g. this one) but I did not find answers to my questions.

What is the best way to store the keys if I have to reinstall a system?
Can I still have an access to expired keys and e.g. decrypt old files?

Make sure the keys are protected by a good passphrase and export them to some trusted storage, such as USB stick.
Yes. You can even change expiration date of your keys just for yourself to make them valid again.


Can an attacker extrapolate future codes based on past codes and their timestamps from a TOTP device? I recently started using a TOTP fob to secure some of my cloud hosting accounts, and I'd likely to familiarize myself with possible attack vectors I should watch out for while I use this system (my previous experience is with U2F/YubiKeys, and not TOTP, and I'm aware that TOTP has a fairly different working principle than U2F).

When I registered my fob with my cloud provider, I was asked for the hardware serial number of the fob, as well as for two consecutive codes.

My question is this: given just a number (not necessarily 2) of expired, but timestamped codes, could an attacker guess future codes?

What if the attacker had the hardware serial number of the fob as well?

Or are both of those attack vectors unrealistic (i.e., does the fob just produce difficult to guess, but easy to verify codes)?

It depends on the implementation of the token.
There is 3 types of implementations, and only first one is "vulnerable":

1: Some tokens are delivered where the seed can be calculated from the hardware serial in a determistic way. This can happen if you order a token where you can "use it with your own server without any need for API" or something similiar to that, something like a "universal TOTP token" or "universal HOTP token". You are then supposed to remove the sticker with the serial after having received the token, and usually the serial will be harder to guess.

In this case, someone with the knowledge of the serial will be able to calculate future codes.

2: You have ordered the token from the cloud service in question:
Then its no issue, as when your token is manufactured, a file with its serial numbers and secret seeds, are created and sent to your cloud provider. (Some token models even allow the cloud provider to "reinitialize" the token with their own seed)
Then, your cloud provider creates a database out of this file.

When you enter the serial on the cloud provider's site, they just look up the seed for that particular token and store that seed inside your account.

3: A token system with a API is used, where you order the token from a "token provider" that also provides a authentication API for third-party relying services to use:

Other token systems, like the Symantec VIP, instead relies on a API, where you only register the hardware serial with the cloud provider, only the serial is stored inside account. When a authentication happens, the cloud provider will send a request to the Symantec Server, asking if the code "xxxxxx" is a correct code to the token serial "xxxxxxxxxxxx". This is why a compromise cannot happen even if the same token are registred to multiple services.

And why you are asked to provide 2 subsuquent codes when registrering the token:

The reason you are asked to supply 2 subsuquent codes, is to ensure that the token is useable, so you don't accidentially lock yourself out of account. This process also works as a resync process, where the service will find the "initial sync" of the token, by searching for that particular window where these 2 codes exist, and the search could go through like tousands of codes to ensure that even a heavily desynced token can be registred with the service.
If only one code is supplied, theres a chance that the particular code exist somewhere else as 6 or 8 digits are pretty likely to repeat, and the server could accidentially set a wrong initial sync value to your token, leaving you locked out.

When you do a resync process, which can either be administrator/helpdesk initiated, or it can be a automatic process that is initiated by a number of invalid codes, you are aswell asked to provide 2 subsuquent codes. This time, its not to prevent a invalid resync as it is very unlikeable, but to increase security as the server will usually search about 50-100 codes forward, and also 50-100 codes backwards (configurable), which would make it likeable that a attacker could guess the code if only one was used, but of course the server will never go backwards past the last used code as this would allow reuse of token codes.

However, bottom line, is that you shouldn't share token serials anyway, because sometimes, the token serial can be partial authentication data for account recovery, so with the use of token serial, a attacker might be able to convince helpdesk personell into disabling 2FA for your account with like "My token have gone black, something is wrong with it" and such, and the helpdesk personell are just trying to help, and falling for the social engiinering trick.


How to properly create and use cross-signed CAs and certificates I'm trying to create an environment with cross-signed CAs, and verify a certificate issued against one of the CAs, all using openssl. The best I got so far is getting openssl into an endless loop while verifying (the loop is terminated at level 100).

I've published all of the certs I created. Now, there are a number of assumptions that I'm making, and largely based on this Oasis document to build the model. Here are my assumptions:

There should be 4 certificates, self-signed from authorities #1 and #2, and cross-signed, where authority #1 is signed by authority #2 and vice versa.
There are only 2 actual subjects (DNs) used (the same subject used by an authority for self-signed is what it has signed by the other authority, albeit in a different cert).
All 4 certificates should be the part of the end-user trust.
The keys used by the same authority, for both self- and cross- signed certificates should be the same
AKI should not be used (May be "shouldn't" is too of a strong word, but not using it shouldn't hurt. Because of the same keys rule, it shouldn't matter though)
I tried setting CA:TRUE for cross-signed certs, with the same result.

My understanding of cross-signing, is that it gives the verification process alternative paths. Considering that I see openssl loop, it seems to be picking cross-signed certificates every time. So the crux of the question is - what would make the verification process to favor the self-signed certificate over the cross-signed one, considering both have the same subject.

Here is a test leaf certificate, I can't make openssl verify to verify it successfully.

[vps@druid]~/ws/EF/pki3$  openssl verify -verbose -CAfile cas.pem cert.pem
cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2
error 2 at 100 depth lookup:unable to get issuer certificate

OK, this is the best that I came up with so far.

The problem with depth processing, I believe, is just OpenSSL's. It's not good that it can't build proper paths. RFC-5280, Sec 6.1 says:

  A certificate MUST NOT appear more than once in a prospective
  certification path.

OpenSSL probably violates that. However, I have to say that I don't quite see an explanation in RFC-5280 on how to build paths, except for its Sec 3.2; there are suggestion that paths must end with a single self-signed CA at the end of each chain (that, however, contradicts with statements that verification chain should not have trust anchors, but trust anchors may contain intermediate certs, which makes the post-chain side contain multiple certificates, where OpenSSL ends up with infinite loop). Either way, I don't agree with what OpenSSL is doing.

I also should say that what I was talking about is not just cross signed certificates, but mutually cross signed certificates. The obvious difference is that normal cross-signed don't create such a circular dependency, and is achieved by having a trust anchor from one CA that is signed by another CA (from the perspective of verifier, it's the same case as a trusted intermediary, AFAIU).

The way to make it work with OpenSSL, is by not adding cross signed certs into the trust list, but provide them as part of the intermediate certificates produced by the key holder.

If I put all self-signed in trust.pem, all cross-certs in untrust.pem, then verifier works, albeit spews intermediate errors (which makes sense as not all trees build/verify successfully):

Here is with both roots present:

$  openssl verify -verbose -CAfile trust.pem -untrusted nontrust.pem host1/cert.pem
host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2
error 24 at 2 depth lookup:invalid CA certificate
OK

Here is with only one or another root present:

$  openssl verify -verbose -CAfile ca1/ca1.pem -untrusted nontrust.pem host1/cert.pem
host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2
error 24 at 2 depth lookup:invalid CA certificate
OK
$  openssl verify -verbose -CAfile ca2/ca2.pem -untrusted nontrust.pem host1/cert.pem
host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
OK

Which shows the coolest part of the cross signing that we can nuke a CA, and still have original certs working.

HOWEVER

RFC-5246, Sec. 7.4.2 that documents TLS 1.2 says that the server has only one chain to present to the client (and vice versa). If the cross signed certs can not be part of the trust store, then then client has to provide multiple chains in order for the verifying side that there are options. So, yes, it works in theory, but not with SSL (it may work with other verification protocols, I didn't check), at least in OpenSSL implementation of it.


SSL Certificate Trust Model I have been looking at the SSL Certificate Trust Model, and there is something that does not make sense. If I am correct, the trust model makes it that if there is a chain of certificates with a trusted root certificate at the top of the chain, all certificates in this chain will be trusted. This does not make sense because then I could create a valid certificate for google.com with my own key pair. I would do this by taking the certificate chain of google.com, lets say Verisign, then google.com. I would leave the root certificate as it is, but modify the key pair in the google.com certificate. This certificate chain would be trusted because the root certificate is trusted, therefore all other certificates are trusted. This would allow you to create a man in the middle attack.

SSL certificates have an extension field that defines what a certificate is allowed to be used for.

When you buy a certificate from VeriSign with your certificate signing request, it typically will not include the extension permission for signing downstream certificates with your certificate; especially for any domain you don't have authority for.

Take google.com for instance (root to leaf node):

Equifax Secure CA - Root CA (hence implicit downstream signing authority)
GeoTrust Global CA - Has Certificate Signer property
Google Internet Authority G2 - Has Certificate Signer property but can only sign leaf nodes
*.google.com - Wildcard domain certificate with no authority to sign other certificates.

The browser checks validity from the root to the leaf. Any authority claimed by a leaf or intermediate certificate is assumed to have been authorised by the certificate that signed it; eventually culminating in the trust given to and from the Root Certification Authority.


How secure is a BIOS/UEFI hard drive password? I'm buying some new machines and am concerned about security of the data should the machine be physically stolen.  It's easy to take out the drive, image it, and read what you want.

I could use file level encryption, but that's insufficient: people will end up not encrypting each file, and, besides, there's too much stored in the swap, page file, logs, registry, caches, etc.

I could use BitLocker, or other OS full disk encryption, but have several issues with this, which I won't go through now.  In short, I want something at the hardware level, not software.

Now, Self Encrypting Drives (SED) seem like exactly what I want, but, they're expensive, especially for very large size (which I need) - I can't even find a 1 TB SED SSD.  I see that many machines have a BIOS/UEFI "hard drive password", but I can't find very much about it.  Is this just a BIOS password with a different name? Is there encryption behind it? Is it a check at the controller level? The disk interface? Will taking the drive out and imaging it bypass it?

If breaking the lock requires replacing drive electronics (ie it's a lock in the drive hardware, but not encrypted), that's sufficient.  If it's just a BIOS password which can be defeated with a screwdriver and a SATA bridge, that's a different story.

How secure are BIOS/UEFI hard drive passwords? How do they work? What type of attacks are known against them?

That password is enforced by the storage drive itself, so it can't be overridden by the system firmware; that doesn't mean it should be trusted though.

How the drive enforces that password varies and there is no clear standard (and if there is, there would be no easy way of verifying if the drive is actually compliant); so it is most likely either just a password enforced by the drive's firmware (with no encryption behind, so replacing the firmware is enough to disclose the data), or poor security-by-obscurity powered encryption that would get broken in a matter of days.

In short, consider those self-encrypting drives as if there was no encryption involved. You can use them on top of data already encrypted with something strong (LUKS, TrueCrypt/VeraCrypt or BitLocker if you don't mind Microsoft and the NSA peeking), but don't use them as your only protection.


How can you know what is distributed with your Linux I'm curious, in theory, how can one know if for example kernel that is distributed with Ubuntu Linux is really what is on https://github.com/torvalds/linux and not some modified kernel which contains tracking code etc...

I mentioned Kernel just as an example. The real question is, can you be sure that distributed open source software is really what you expect it to be?

I'm curious, in theory, how can one know if for example kernel that is distributed with Ubuntu Linux is really what is on https://github.com/torvalds/linux and not some modified kernel which contains tracking code etc...

Actually, what is distributed with your distribution usually isn't what's distributed via torvald's git tree. Your Linux distro is probably not vanilla kernel.

The reason for this is that distribution vendors usually backport fixes that may impact their customers from various sources. In Fedora, for example (these examples picked purely because I have recent experience custom building these packages):

The kernel (currently 3.11.4-201.fc19.x86_64 at time of writing` contains a number of patches for v4l, iommu fixes, drm-intel-nex, iwl (intel wireless) drivers and so on.
Grub2 contains a number of patches to resolve various (breaking) issues with its build, and patches to make EFI builds work.

On Fedora (and other yum-based systems) yumdownloader --source kernel will pull down the source kernel RPM - open it up and you'll find everything used to build the kernel packages.

So, no, your Linux (and even your packages) might not be vanilla vendor packages.
Now, next:

  The real question is, can you be sure that distributed open source software is really what you expect it to be?

Well, the point of the above was that your package database contents might not be what you expect them to be, but the question I guess is and could this have malicious content in it?.

The answer is that there is little way for you to tell as an end user unless you inspect the source and rebuild the package from that.

However, most package submission processes involve a little rigour. Usually, you can't just turn up and become a maintainer of a popular package. You would need to be known for contributions, approved by a staff member/committee member/whatever it is that gives you rights to push packages.

I can see this being a possible attack vector in obscure software, but major packages I think it is sufficiently likely that an attack would be detected eventually. Most packages are built from source and receive scrutiny due to bugs, user issues and so on. Development continues and packages are rebuilt. Patches may fail. Somebody, somewhere is likely to notice an oddity, basically.

On this basis, I think you have to make a risk based decision. Is what you intend to protect so valuable you believe highly capable and persistent adversaries are going to try to backdoor a package in a Linux distribution to get to you? If so, go ahead and build your own distribution (there is no reason you can't steal an existing distributor's packages and just carefully audit/compile your own, by the way - that's the beauty of open source).

If not, I would (personally) go with accepting the outside risk.


How to intercept url to disallow Forced Browsing in simple Dynamic Web Project? I found an issue related to Forced Browsing in my web-application.And I was able to verify that my static content(like text document...mainly help documents) can be accessed by simply hitting the URL like,

Example: http://www.example.com/example/example.txt

User was able to do that without authentication. I have a simple dynamic web application in java. I know spring can achieve this task using  tag but I doubt there is any way I can achieve the same using only the web.xml.

For information: the static content are located outside the WEB-INF folder.

Are there any suggestions of alternate ways I can safe guard my static content from being accessed by unauthorized users?

You can disallow direct access to your static content, and then build a dynamic page that checks the authorisation, and then serves the content if the user is authorised.

For example http://www.example.com/static.jsp?content=example.txt

If you do this then be very careful that this page can only return content you want users to access, for example, don't allow users to do things like this:
http://www.example.com/static.jsp?content=/etc/passwd or http://www.example.com/static.jsp?content=../WEB-INF/web.xml

I'd suggest using a white list of the static content that this page is permitted to return.


Access router if you don't know password At home I have a wireless cisco router. Unfortunately I wasn't smart to change its ip or passwords. So anyone who is connected to it can access 192.168.0.1 and log in as admin using password admin and do whatever they like.
However in order to connect to my router you have to enter the password which was blahblahblahblahblah (yes it is word blah repeated 5 times).

I came home tomorrow to find that my router password was removed and my network became public. Is there any way anyone could have been able to connect to my router without knowing the password and change it to public?

From your description, I suppose that your router was configured such that:

Using the WiFi entailed knowing the WiFi password, set to the password "blahblahblahblahblah".
When contacting the router over IP (whether from the WiFi, or from the outside -- a router, by definition, routes data, so it is connected to at least two networks), it is possible to access the administration interface with the login "admin" and the password "admin".

Then it seems highly probable that the intrusion came from the outside: someone, or some robot, simply connected to your router public IP address (the one facing the outside, allocated by your ISP, not the internal 192.168.0.1), tried to open the administration interface with the default password, and lo! it worked. You would not have been the first one to leave a default password. There is even a database of devices which have been left open. Maybe yours is referenced in there; you might want to have a look.

If your router was configured to deny access to the administration interface from the outer network, then the intruder must have come in from the WiFi part. Let's face it, "blahblahblahblahblah" is not the strongest password ever -- even if the rest of the WiFi was done properly (i.e. WPA2), such a password would not have lasted long against an attacker with a simple PC.

And, of course, there is always the possibility of a remotely exploitable security hole in the router software. Routers are, internally, small computers with software, which is not often updated (if at all), so they have bugs and holes. A simple search on "CISCO" in the published CVE uncovers 1418 entries.


Can you do a client and server side encryption I am creating a PHP website where users, among other things, can login and do administrative stuff. For their passwords i use password_hash($password) and to later verify with it, I use password_verify($password, $pass_from_db).

Since PHP is a server-side language, the password, before reaching the server is, in both cases, vulnerable for sniffing, and since they are cleartext, easy to take and use by man-in-the-middle attacking. Since I am going to use Ajax JS, I figured I would use a JavaScript encryption first, and then send the JavaScript encrypted value over the internet, and then create the password hash on the encrypted value like this:

HTML | password = "1234" | -> JS | encrypt("1234") = "ASU'2j3)k" | -> PHP | password_hash("ASU'2j3)k") = "AlD23J'#sC5"P" | -> Inserted in db

HTML | password = "1234" | -> JS | encrypt("1234") = "ASU'2j3)k" | -> PHP | password_verify("ASU'2j3)k", "AlD23J'#sC5"P" - 'Gotten from db') | ACCEPTED

Is this a good idea, or should I just send the password as cleartext?

You can, but you shouldn't. It doesn't increase security, since the client side encrypted password becomes the point of attack.

The other problem with client side encryption is that if you aren't using an encrypted channel to deliver the code, there is no way to prevent it from being tampered with en route - an attacker could simply modify it to send the raw password to them as well as the encrypted one to you.

The best practice for this situation is to use an encrypted channel to send the authentication details - https, in other words. This ensures that only your server can read the password, and then you can check it in your server side code.


Corporate IT monitoring and access to user private data (keylogging? https data transmission?) I work at a large company that requires employees to sign a digital certification saying that we recognize the right of the said company to monitor all data and communication on our work laptops, and that anything we do on the computer should have no expectation of privacy.

What I wonder is, as far as standard enterprise IT security software goes, how omnipotent and omniscient is the IT department likely to be in monitoring user data?

Two specific questions:

I store all my log in passwords (everything in life) on an excel spreadsheet, and password protect this spreadsheet. I understand that my company will have access to a copy of this spreadsheet since it's on my computer. But how likely is it that they can access its contents, perhaps using a keylogger to get the password for the spreadsheet, or screen capturing when I have the spreadsheet open with all the passwords shown?
I use my gmail at work. It's https enabled. Is IT likely able to see all the emails I send and receive, even though it's through https?

Again, I believe our company uses a standard enterprise security tool, so wanted to see if anyone knowledgeable can shed insight on how much of my personal data can be freely accessed by the IT department.

Thank you.

Ultimately if you are using a computer controlled by someone other than you (in this case your employer) they can get access to anything you process on that computer, including e-mails, passwords and pretty much anything else.

Whether they do or not is a different question. Depending on your location there may be legislation limiting what they can legally do (e.g the Data Protection Act and Regulation of Investigatory Powers Act in the United Kingdom).

Generally speaking I would say it would be unusual for a company to put key-stroke logging on their staff machines, unless perhaps that staff member is under investigation for something, even then the legality of that could be dubious.

On the Internet interception, it's possible (e.g. using something like bluecoat) for them to see inside SSL connections, but that doesn't mean they're looking at the content of your mails for anything other than malware...

I'd say that if you're not sure that you trust them to have this access the best option would be to only make use of your own computing devices for your personal activities.


How to distinguish between a scam and a genuine call? My bank called me the other day and the person who spoke to me failed to give me a single evidence that he is calling from my bank.

The bank number is hidden just like many other companies maybe because they use VOIP to make calls or they don't want you to ring them back on the number they call you from.
The person I spoke to refused my proposal to mutual verification of our identities when I asked him to tell me my account number since all the information he revealed to know about me was my name and phone number which are available to the public.

If you're worried about the authenticity of a cold-call, don't try over-the-phone authentication in either direction. Simply ask for some basic information you can use to refer to the issue in follow-up:

Name of the company/service the account is for.
What is the nature of the issue/offer the caller wants to discuss?
Is there a reference ID (e.g.: ticket #) for the call?
Name and/or agent ID of the caller.

Important: Throughout this process, you should not ever give the caller any more of your information. The main point here is to assume that someone calling you like this is an attacker, for the entire duration of the initial call.

Question #1 should be answered by the caller before you even have to ask. Be especially wary if it's not. My wife once argued for a good couple of minutes with someone calling from the "Account Services Department", before she finally handed the phone to me. When I interrupted the caller to ask "Account Services Department for whom?" the caller suddenly hung up.

After you've gotten all you can from the caller, hang up. Then, obtain legitimate contact information for the company from a reliable source (do not use any contact info given by the caller, without verifying it first).

Once you've got known-good contact information, call the company yourself and ask about your account's status. Use information obtained from the caller as needed, to reference the incident.


Reliability of windows OS security for "program files" safe guard I want to do inter process communication between Firefox (via extension) and my application. Both reside in "Program files" (of windows 7 OS). I also assume that malware is running in the system and have user level privilege (and not admin level).

Can I  rely on windows security to make sure that Firefox or my application is not modified by malware or new files are not added in program files?

OR; in other word is it safe to assume that operating system makes sure that  one cannot add or modify files under "program files" with out admin privilege?

If you're assuming that the malware is running as a UAC limited user, then you should assume that it has the capability to escalate itself to administrator. Privesc on Windows is trivial, since you can just trick the user into thinking a legit software update operation is occurring and they'll almost always accept the escalation prompt. There are many other avenues for escalation too.

That being said, if you're doing IPC, do it properly - use a named pipe. They're not tied to the filesystem permissions model, and you can set your own ACL on it. Even better, once you've created it and accepted the other endpoint, you can stop accepting new client connections, increasing security.


How can I practice using nmap without scanning some real site or performing computer trespass? I want to learn nmap and its various options. What can I do or setup in order to see examples of issues found by nmap - e.g., something with security holes on purpose.

There is a specific URL for that : scanme.nmap.org

  Hello, and welcome to Scanme.Nmap.Org, a service provided by the Nmap
  Security Scanner Project and Insecure.Org.

  We set up this machine to help folks learn about Nmap and also to test
  and make sure that their Nmap installation (or Internet connection) is
  working properly. You are authorized to scan this machine with Nmap or
  other port scanners. Try not to hammer on the server too hard. A few
  scans in a day is fine, but dont scan 100 times a day or use this site
  to test your ssh brute-force password cracking tool.

  Thanks
  -Fyodor

If you are looking for vulnerable webapp here are some good lists :

Hacking Vulnerable Web Applications Without Going To Jail
Deliberately Insecure Web Applications For Learning Web App Security


Hardening Web Browsers - Detailed Guidance Is there any specific and complete guidance on what is needed to harden a web browser given the number of attack vectors possible, particularly given that browsers allow so many varied plugins?

All I have managed to find are bits and pieces of stuff - including basic security settings, but nothing that is well thought out, defensible and complete from an IT Security perspective.

How are IT departments handling this?

Regards

Check out:

ISAE's Application Security - Browser Guidance

  The STIGs contain technical guidance to "lock down" information systems/software that might otherwise be vulnerable to a malicious computer attack.


Is my (Chrome) email address available to websites when I'm logged into Chrome? When I'm logged into Chrome (e.g. with my Gmail account) can websites view/obtain the email address associated with my Google/Chrome account? For example, as a means to "recognize" me?

No. Chrome doesn't disclose the email address associated with your Gmail account to websites without your consent. This would constitute an information leak vulnerability you could report to Google's VRP.

That said, they may be able to determine if you're logged, e.g. via timing attacks.

Even extensions need the chrome.identity API permissions to access your email address and other information about your account.


RBAC model: user in two roles access dilemma I am implementing the Role-Based Access Control (RBAC) model security system and I have a dilemma: one User1 is in Role1 and is in Role2. Role1 allows access to the Resource1 and Role2 denies access to the same one. It is a well known problem. Could somebody help me, how to resolve it, maybe some explanations. How to explain User1 why it has not access to some resource. Is any solution how to overcome it smarty.

Thanks.

It seems that you are conflating between RBAC and DAC (Discretionary Access Control): Deny Access is not typically employed in RBAC, but rather it comes from the DAC world. F.e. its common to see an NTFS ACL (Access Control List) with DENY in it.

You might be trying to implement a merged model (see the example in my response here) - e.g. building an ACL with ACEs (Access Control Entry) pointing to roles. E.g. using groups to grant access to folders...

There are two possible solutions you can use, perhaps even mix'n'match, depends on what makes sense for your system (I've built and used both, in different contexts):

Ordered ACL - i.e. the ACL is not a big pile of ACEs, but they're in a specific order: higher on the list takes precedence, keep evaluating ACE until you find either a PERMIT ACE, or a DENY ACE for that user. Whichever is first on the list, wins.
DENY ACE overrides all other ACEs. I.e., if the user is granted access via Role1, scan the ACL for any DENY that applies to the user, and then Role2 would block access no matter what.

Note that you might not be implementing this with a standard ACL model, but truly only checking the user roles - that's still fine, the above still applies (just harder to visualize and explain).

The real question you need to figure out is, What makes sense for your system? Are you trying to implement SoD (Segregation/Separation of Duties)? If so, it's clear that DENY must override any PERMIT. If you want the user to configure this (in which case its DAC, not RBAC), the first option gives the most flexibility, since there IS a way to work around it.


How can I know when a certificate was created? I want to know whether my various providers changed their certificate because of Heartbleed, or they are using an old vulnerable certificate. How can I know that? Is the "valid from" date also the creation date?

Heartbleed has pretty little relation with certificates. The only link is that a potential consequence of a successfully exploited heartbleed is a reveal of the SSL server private key. Therefore you might want to go to full paranoia mode and consider that any private key which was used in a vulnerable server is toast and must be replaced. This is quite extremist, and somehow misses the point because the same argument applies to every single remotely exploitable buffer overflow ever discovered in the server, and there are several of them each year; singling out the "heartbleed" bug is unwarranted.

Now a certificate contains two "validity dates", called notBefore and notAfter. Usually, the notBefore date is close to the date at which the certificate was actually issued, i.e. when the CA signed it. Normally, the notBefore date is slightly in the past because the CA wants to produce a certificate that the owner can immediately use even if his machines' clocks are not accurate. For instance, Microsoft's CA ("Certificate Services"), by default, will write "14:35" as notBefore time if the certificate was really issued at 14:45. Other CA may go further; I know of one CA which systematically used midnight (from the previous night) as notBefore time.

But you must note that this date qualifies the date of issuance of the certificate, not of the key. It is relatively common to "renew" a certificate by issuing a new certificate (with new validity dates) containing the same public key and identity as in a previous certificate. For the "heartbleed exploit" scenario above, you worry about whether the potentially leaked private key was discarded and regenerated or not. Nothing in the certificate contents will tell you anything about the time at which the private key was created (well, the private key existed before the certificate, but maybe long before, or maybe not; the certificate contents won't tell).

Let's get a bit more real here. Heartbleed is just one more potentially exploitable bug in an implementation; this is not the first one, and not the last one. Probability that any given server was exploited between the time the bug was discovered, and the time the server's code was fixed, is extremely low on average. The bug became all the rage overnight, but was not observed in the wild before.


Possible attack via Netflix; what action should I take, if any? Late last night I received a "password reset" email from info@mailer.netflix.com.

It looked legit, but I had not requested a password reset. I checked my account's "recent account access" but saw nothing unusual there.

I did not click through and did not reset my password via any other channel. I just left it.

Early this morning I received another email, approx 3 hours after the first

Subject line: - Netflix - Unlock your account -

Email Info:

    from:   Secured Customer <jammzy@hotmail.co.uk>
reply-to:   "info@gov.co.uk" <info@gov.co.uk>

Email contents:

- Encrypted attachment –

This message contains 1 encrypted attachment.

This message can only be opened by <my-email>.

PDF password : 2121

Attached is one file named "Netflix - Unlock -.pdf" which is 112K long.

Is there anything I should be doing about this, apart from ignoring it? (Either for myself, or as a socially responsible "netizen")

First, this is not an attack via Netflix, is an attack spoofing the email sender. It could be anything: Apple, NASA, whatever. Spoofing an email sender is as easy as writing any name and address on an paper envelope and sending it.

The PDF file is protected so some antivirus software and automated scanners will not be able to detect malware on it.

What you do? Ignore it.

Someone will probably tell you to send it to Netflix, but they have nothing to do with it, and cannot help but tell you this email is not from them.


How to build a hacking challenge that uses XSS? Security conferences often have hacking challenges. My colleagues and I have built a number of these. We've not yet done one that includes a cross-site scripting vulnerability.

I have seen challenges that do this. One approach was that a certain page (vulnerable to stored XSS) was requested by a browser on a periodic basis (every 10s I think). After successful attack, your payload ran in that browser and the challenge was to extract the cookie.

One issue with this approach is that when multiple people are working on the challenge simultaneously, they interfere with each other - and you can steal other people's ideas. An alternative idea was to have reflective XSS only, and a page where you can submit a link to the site, which admin will review before it goes live.

How long to have the browser stay open is an interesting choice. If it stays open a while (60s or so) then people can use tools like BeEF, which makes it a bit easier. If it's only open for 2s you have to script the attack.

There's a number of details that affect how well the challenge will work in practice. I'd prefer answers from people with experience running XSS hacking challenges that worked well. But failing that, I'll settle for informed speculation.

If it helps, we tend to attend technical conferences in the UK, e.g. B-Sides Manchester, SteelCon, SecuriTay.

Also, any hints about defending the browser from JavaScript exploits would be welcome!

The most common approach I've seen is to run a headless browser bot that gets vulnerable links through a submission system. It then visits each of these links for a few seconds with a magic cookie set.

An example can be found in the article "How to add an XSS-able bot to your CTF" where the bot is implemented as a headless PhantomJS instance. Similarly, the hackxor game uses HtmlUnit to simulate a browsing victim and this XSS challenge uses an instance of Zombie.js.

There are indeed several reasons to avoid stored XSS: Not only would players learn about the others' methods and eventually interfere with their payloads but people might start annoying others with redirects or infinite loops which will keep you busy with cleaning everything up.

Instead I'd suggest a reflected XSS vulnerability with a simple submission system where players can provide links that are then visited by the bot. Depending on the scenario, the submission could be put in the context of a contact form, a simple socket listener, a private IRC message, or, if you feel fancy, an email account where the links from incoming emails are extracted and visited.

I'd definitely avoid a system that requires manual interaction. Otherwise people will constantly inquire if their payloads have already run, if it can be visited again, etc. Depending on how aggressive the players are you should also think of a way to rate-limit submissions. (A CAPTCHA for the contact form would fit the scenario well.)


Can a domain be taken by someone else if custom nameservers are misconfigured? Example: I own the domain example.com.
Instead of using the nameservers set up by default by the registrar, I set up my own nameservers on my own machines with bind9. Let's say that at the beginning, before becoming more experienced with bind9, a few things are misconfigured for a few months. For example allow-transfer settings are not properly configured. (By the way, is it related to DomainStatus: clientTransferProhibited visible in WHOIS or not?)
In this context, can a malicious user gain permanent ownership on the domain?
Or is the ownership of a domain done at a totally different 'layer', and no misconfiguration of a nameserver can be used to take ownership on a domain?

Domain names are registered to your user account on the registrar website. So the only way to get permanent access to a given registered domain is to either:

take ownership of the user account (stealing credentials)
transferring the domain to another account

Now that second part is usually locked when you create your domain, and you need to take active steps from your registrar account to allow such transfer to happen. allow-transfert is an option to enable DNS server to work with a primary/secondaries setup, not to transfer ownership.
In the end, should the nameserver be compromise, you always can revert the configuration on the registrar to use their own DNS or a new one you've just configured.
Of course, if someone has access to your own NS, they can do malicious things with your domain name, such as redirecting users to their own websites.


Should statically-linked server binaries (daemons) be deemed more secure? For a long time I've pondered this question. I am aware of the benefits and downsides of dynamic libraries (shared objects), including the infamous article by Drepper.

All other things being equal, isn't a statically linked binary of, say Nginx or OpenSSH, less prone to stuff like library placement or other (non-kernel) attack vectors usually used by attackers?

From a security standpoint, static linkage has one advantage and one weakness:

The advantage is that a statically-linked binary is immune to library injection attacks.

The weakness is that it cannot be protected by ASLR: the address layout was determined at link time, so the OS is unable to randomize the location of executable code.

Library injection requires local access, while known-address attacks tend to be remote, so on the whole, I'd say that static linkage of server binaries is a net negative to security, in addition to its other drawbacks.


Risk of tampering when hardware shipment is delayed I am currently receiving an order of computer parts in the mail including an SSD. Tracking showed that the package arrived in my town on day X, and was originally scheduled for delivery on day X as well. Tracking now says it is going to be delivered on day (X+3).

Being the paranoid person that I am, is there a reason to fear that the SSD is being tampered with/malware installed on it?  Is there anything I can do before/when I install the OS in order to check for tampering?

If you don't want to be at risk, in the future get a third party to purchase stuff like this in cash, from a store not near your house or work.

You should see if you can download firmware for the drive from the manufacturer's site. Update the firmware on the drive, or at least check its signature.

Remember, it is near Christmas and shipping is likely to take longer than normal.


Anonymity against web analytics and site operators My question is not about people who are proficient in hacking. I am wondering about websites run by acquaintances or friends of friends, who can use website analytics services provided by the website hosts for business purposes. They may innocently enough decide one day that they want to look up how many visitors viewed their pages, the IP address that visited their site, the location, the service provider of the visitor, the entry and exit pages, the search engine query used to enter the website, etc. While they are viewing, their curiosity may be piqued, and they may attempt to identify a visitor based on the provided information. Then they may decide to stalk the visitor's movements, and may for example try to identify comments or user feedback left by the visitor. The visitor always wanted to remain anonymous, but risks their identity being revealed.

What precautions can be taken before the fact to protect from such an eventuality while retaining complete funcionality? I realize this may be a pretty broad question, because what is tracked by common site tracking services can vary, and the potential concerns of a visitor trying to be anonymous vary greatly too. But I would assume that the ability of a determined hacker far outpaces the reaches of a tech novice using a web analaytics. So maybe some measure input can be contributed if we were to consider granting a visitor the maximal protection from identification in these circumstances.

Of course using proxies, Tor, etc. would be great suggestions. But is that enough against web analytics tools? For example, would enabling scripts to run in Tor in order to view an ordinary video or youtube hosted on a regular site betray the IP address of the viewer, or is the vulnerability caused by enabling scripts in Tor beyond the capabilities of prevalent analytics services? Another example: As far as I know, Facebook doesn't currently allow for tracking. But hypothetically how would it be possible to retain anonymity from shared posts, photos and videos viewed if it some day would become possible or even retroactively viewable?

You don't really need to resort to Tor to avoid this kind of tracking, I would firstly just use a VPN to hide my IP (much quicker than Tor).

Beacon/analytics blocking comes down to selectively stopping the associated JavaScript. I would then just use my regular web browser with a beacon/analytics blocker such as Ghostery which has a huge database of analytic-script fingerprints. This app also does social media plugin blocking.

This solution is better for maintaining functionality because it doesn't block JavaScript all together like the noScript plugin. Of course if a new analytic script is created it might take a little time before it's included in the database.

As for your theoretical Facebook question; create an account not linked to your real identity.


Will separating internet activity and offline activity secure a host? Let the diagram below be a representation of a LAN.
- let R be the interface between the LAN and the internet.
- H be host connected to the LAN.
- F be a firewall implemented using a virtual machine controlled by H.
- V be a virtual machine controlled by H.
- F is also the interface between the LAN and V.
- F also blocks all traffic from V destined for H.

    R
    |
 +--+--+
 |     |
 F     H
 |
 V

Consider:
- H uses V for all insecure/casual internet activity
- H does all secure/private activity by itself (ie. banking)

How secure is this?

I know the user will be largely responsible for most breaches, like reusing passwords, or pulling files out of V, or using a VM that V can escape; but, aside from user error, is H safer?

Since V will be doing most of the insecure stuff, I can only see attackers targetting V because V is the only one that's out there that they can identify.  Any viruses/attacks from V would be blocked completely by F if F is set to block all traffic on the LAN between them too.  So, yeah, come break this setup.

I want to know if separating insecure activity with secure ones can make a host safer.

--- edit

So, probing the network will unveil H.  In terms of V getting infected, though, can any of its infections reach H?

And yeah, H should be behind a firewall of its own.

No, I think V is safer than H. For H you are going for the security-through-obscurity approach, which is always discouraged.

This is because, in my opinion, your assumption that attackers targetting V will not come across H is faulty. For example, most of the latest worms don't only attack a single target system but also try to discover the target networks' topology and neighbouring hosts. So in my opinion it will be better if you take H behind the firewall too and don't expose it directly to the internet.


Can I use a CA certificate for two ways (mutual) authentication I cannot get an answer from a CA company for this question.

I have to implement two ways SSL authentication between my server and my users computers. Users should access to my several API securly. I have an Comodo trial certificate and I use it on my web-server.

I'm wondering can I use this certificate on two-ways SSL authentication?

Some considerations:
I thought if I put a button on a web form and if a user can download the current web page's certificate when he presses the button.
This would be nice. However I cannot know when the certificate will be out of service by CA.

Ps: Actually I've been continuing to my implementation

No, you cannot use the same certificate for both server- and client-side SSL authentication.

(Well, technically, you can - it won't break anything - but it means that the server private key will be known to N clients, each of which can then impersonate it, so that's just not going to work out.)

If you wanted to do Client SSL authentication, you'd want to issue individual certificates to all your clients.  You can do that with your own CA, they don't need to be signed by a public CA, as long as your server can verify them against that CA.

See also this answer which might be useful to you.


How to treat/hash ECDH shared secret to use as keys for AES? I'm doing some studies/development for a security system that would use ECDH with ephemeral keys.

In my code I'm currently using a 256-bit EC, so when the two parts compute the shared secret, I get a 32B (256bit) array containing the shared secret.

Now, I would like to use this shared secret to compute a key for a symmetric key encryption algorithm, such as AES-128 (with a key size of 128 bits).

So my question is how to reduce the 256-bit shared secret to a 128-bit AES key? I have read that is better to hash the shared secret before using it as key for symmetric encryption, but with wich hashing algorithm? If I use SHA-256 I still get a 256-bit key. Is there any standard way to proceed to build a symmetric encryption key from a ECDH shared secret?

In general, producing symmetric keys from some "secret" is called key derivation and uses a key derivation function. There are several KDF designs out there; many protocols define their own (e.g. in SSL/TLS). In fact, exploring the details of SSL/TLS would be a good idea (pedagogically speaking).

There is a current "push" for defining a standard construction, backed by the IETF, and it is called HKDF; if you are in need of a KDF then you could do worse than choosing HKDF (though it is relatively recent, it benefits from a robust cryptographic foundation and appears at least as safe as any other competitor).

If you need only a limited amount of key material (e.g. 128 bits), then you can simply use one of the usual hash functions (say SHA-256) and truncate the output. That truncation is fine is not a consequence of the hash function being, say, resistant to collisions; however, it is still believed to be adequately secure with non-pathological hash function designs, in particular SHA-256.

As for standards, yeah, there is one. It is called ANSI X9.63. Since it is not a free standard (legally speaking, you must pay so see it), amateurs and students don't usually consider it, so it does not percolate to opensource software. Its KDF is based on SHA-1; it basically computes SHA-1(secret || counter) for successive values of the counter, which, as far as KDF go, is not a very attractive design, though not trivially weak (I only have an old draft; newer versions of X9.63 might use SHA-256).


Authentication with client certificate vs HMAC I'm designing an API intended for use by a very limited number of trusted clients, likely a server cluster. The API can be accessed only through HTTPS. To authenticate the clients, I'm considering 3 methods:

TLS client certificate. The certificate might be issued internally as both server and client are operated by the same organization.
HMAC-SHA1 over some data items: requested URL, date time,... for each request. The MAC will be put in HTTP Header. In other words, a simpler version of Amazon S3's REST authentication.
HTTP Basic authentication with pre-shared username & password.

To my understanding:

TLS certificate is the "most secured" of the three, while HTTP basic authentication is the "least secured". "Most secured" is in the sense that the method provides protection against all attacks also protected by others, and some more.
HMAC-SHA1 is vulnerable to replay attack, however since the communication will be secured by TLS anyway, there should be no problem.
HTTP basic authentication puts shared secret on the wire all the time (though still protected with TLS), so I have some (possibly unfounded) worries about it.

Are my points correct? Is there any other security issues I should be aware of?

I think you summed it up well.

A few additional points beyond the technical security of these solutions:

TLS certificates require management, they expire, etc. You should consider whether you have the resources (can automate to some extent) certificate management. A pretty bad scenario is when IT operations just gets fed up with all the issues and disables cert validation because that way it just works. ;)
An HMAC-SHA1 signature implementation is also reasonably good and you can limit the time window of a replay (and as you said, in TLS it's ok). However, the implementation is more complex than the other too. If it's a larger team that will maintain the code and especially if you have to change the implementation sometimes, there is a good chance that a flaw will be introduced. The other two are much simpler in terms of source code that needs to be written.
HTTP Basic is very simple and may be ok with TLS, but as you said, that I would say is the least secure of the three. Many people still think it's good enough for many purposes though, it depends on what you want to protect against. TLS is considered secure against MitM attackers. I think the biggest advantage is simplicity, there is not a lot to go astray.


Why are JWT's secure? I want to make sure that my use of JWT's in authentication is correct. There are a couple of issues that I don't understand. This is my current understanding:

When a user logs in, the server will create a JWT the third part of which is a signature that is created using a secret key.
In further calls to the API, the user can include the JWT in the header, and the server will be able to check the signature, again using the secret key. This means that an attacker that has intercepted the JWT cannot change the payload in any way, because if they do, then the signature will not match.

Questions

If an attacker manages to get hold of a JWT, will this not enable them to use the API as if they were the user that had originally authenticated?
I was thinking of including an expiry timestamp in the payload so that the user had to log in occasionally. Is this the correct way of expiring the JWT?

Thank you in advance.

Questions

  If an attacker manages to get hold of a JWT, will this not enable them to use the API as if they were the user that had originally authenticated?

Yes. Same thing as if an attacker manages to obtain a users session id. However, this is why you want to limit the lifetime of JWTs.

  I was thinking of including an expiry timestamp in the payload so that the user had to log in occasionally. Is this the correct way of expiring the JWT?

Yes. Plus you might want to add a revocation mechanism. This article provides a good introduction on the subject: https://stormpath.com/blog/token-auth-spa/


How do countries block encrypted protocols like Skype? I can't make Skype calls outside of my country because they are blocked.
As far as I understand, Skype uses strong encryption for the calls, thus, making Deep Packet Inspection unable to detect it.

If it's not DPI, then what it can be?

People I know suggested me to use VPN, but I can't understand why, because Skype implements encryption.

Payload encryption means they can't know what the communication content is, but in some cases they can still know what protocol you're using (In this case Skype). This is how countries block Tor, for example.

Methods to detect the protocol being used even if it's encrypted:

IP-based: TCP is not encrypted even if the payload is encrypted (So that computers can route your packets). The country can tell where the packets are going, and block them depending on their destination IP Address.

Port based: Same as above, but based on the destination port. For example: XMPP uses port 5222, if I block all packets connecting to port 5222, I block out XMPP even if it's encrypted (Unless users and servers use non-default ports)

Handshake based: Many (maybe all) encrypted protocols start the connection unencrypted, and then the two sides "shake hands", the handshake envolves sharing the cryptographic data needed in order to begin using encryption, so it isn't encrypted. Packet inspection can work here. For example, the first few packets of the https handhsake are unique, not encrypted and can be indetified.

VPNS are effective against all 3 methods mentioned above because they route everything through an already encrypted connection. TCP is wrapped by the VPN protocol and sent through the VPN Protocol. This means your country cannot see the destination IP, the port, or the handshake because it's all wrapped in an encrypted TCP connection originating from your machine and ending at the VPN server. However, your country might be blocking the VPN protocol in the first place. (Unlikely)


Why would attacking a DNS server have the affects it did? I'm somewhat confused as to the technical details of the Oct. 21 DDoS. Dyn is a company, which according to wikipedia

  is an Internet performance management company, offering products to
  monitor, control, and optimize online infrastructure, and also domain
  registration services and email products.

I'm assuming they own a popular DNS server which was attacked? I've heard two claims in the news which confuse me

certain geographic areas were affected, namely western US and western Europe
certain sites were affected, such as Twitter.

How could taking down a DNS server affect particular locations? Is the idea that people tend to use DNS servers geographically closest to them so it would be logical that those physically closest to the servers would be the most affected?

How could certain sites (such as Twitter) be more affected than others?

Is this likely the work of a state sponsored actor and if so, what's the point in pursuing them? It's not like North Korea's going to allow the FBI to extradite someone who attacked the US. Seriously though, are there any international bodies that could prosecute "crimes" (if it's considered one) like this?

The largest Internet sites, Content Distribution Networks (CDN's), search engines, and companies that do things like streaming video leverage geographically load-balanced DNS which means when you look for their DNS servers from different parts of the world or from different ISP's you get different results. The following are two tests run against github.com from different parts of the US. In the example below you might notice that an attack against dynect.com will affect the Dallas users but not the Seattle ones. This geographically load-balanced DNS is why it was affecting some people and not others. The fact that many companies use different DNS providers is why it only affected some companies.

dig -t NS github.com (from Dallas)

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

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

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

;; Query time: 2 msec
;; SERVER: 173.203.4.8#53(173.203.4.8)
;; WHEN: Sat Oct 22 06:24:33 2016
;; MSG SIZE  rcvd: 114

dig -t NS github.com   (from Seattle)

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

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

;; ANSWER SECTION:
github.com.     586 IN  NS  ns-1283.awsdns-32.org.
github.com.     586 IN  NS  ns-1707.awsdns-21.co.uk.
github.com.     586 IN  NS  ns-421.awsdns-52.com.
github.com.     586 IN  NS  ns-520.awsdns-01.net.

;; Query time: 78 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Oct 21 23:24:17 2016
;; MSG SIZE  rcvd: 165

Tests run within a minute of each other (clock offset because one was a server and the other is from my laptop).


What are the dangers of client side authorization? What are the dangers of client side authorization? Where client side authorization should and should not be used?

The server controls the important resources.  If the server cannot enforce access control then you have built a system without access control.