Is it unsafe to enter administrative Windows credentials when logged in as a regular user? I was recently advised that when a user is logged in as a regular user and they need an administrator to do something (i.e. install an application) that entering the administrator credentials when the regular logged in user is still logged in, puts the credentials at great risk and logging out as the regular user and logging in as the administrator is the recommended course of action.  Is this correct?

This is true. To input user administrator credentials on a normal workstation is a security risk.
There are various risks if the workstation is infected on your daily actions, like stealing hashes to later re-use them in pass-the-hash (PTH) attacks, installing keylogger, etc.

There's even a risk if you use a jump host, this is because upon creating a RDP session the hashes are still created on your workstation. Credential Guard is a great way to have a good protection from PTH attacks, but this still doesn't help if the workstation is infected with a keylogger.
https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard

Microsoft has introduced PAW Priviledged Access Workstation to have a secure mechanism of managing Administrative tasks. These are basically hardened Windows OS machines on which you perform Administrative tasks.
https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/privileged-access-workstations

If you would like to go a step further, you can setup a tiered architecture on your Active Directory infrastructure.
https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material


Can encryption twice with two keys in different sequences lead to the same result? I am looking for an encryption algorithm for one of my current papers. The basic requirement is that, suppose I have two keys k1 and k2, and the  E(k1,t) means encrypt t with key k1.

Are there any encryption algorithm satisfy that E(k2, E(k1,t)) = E(k1, E(k2,t))?

I know that Caesar cipher satisfies the requirement. But it seems too weak. Are there any more secure algorithms that can be used for my requirement? Thanks!

You may use any symmetric encryption which works by generating a key-dependent stream of bytes which is then XORed with the data to encrypt. This is the case of most stream ciphers; this also applies to a block cipher in CTR mode (which practically turns a block cipher into a stream cipher).

Such ciphers are a bit delicate to use, because you shall never reuse a given key-dependent stream (that would be the infamous "two-times pad"). This means that either a given key will be used to encrypt only one message, or that you use a stream cipher with an initialization vector which will need its own management. Crucially, in your case, this means that potential attackers should not be allowed to observe E(k1,t), E(k2,t) and E(k1,E(k2,t)), because this would enable them to recover t (namely by XORing all three streams together).

If your specific scenario make the stream cipher solution inapplicable, then you would have to use more esoteric solutions which are non-standard, thus cannot be recommended in practice (but are fine for research). For instance, given Diffie-Hellman group parameters (a modulus p, and a generator g which is such that gq = 1 mod p for a prime q which divides p-1), a subgroup element (a gx for some integer x) can be "encrypted" with key a by raising it to the power a (E(a,h) = ha mod p). "Decryption" implies raising to power 1/a mod q (inverse modulo q is computed with the extended euclidean algorithm). With this "encryption" algorithm, you get the commutativity you look for (E(a,E(b,h)) = E(b,E(a,h))) AND you can publish E(a,h), E(b,h) and E(a,E(b,h)) without revealing h.

... but that's just a variant of Diffie-Hellman. The good question is then: why do you want your commutative encryption thing ? What are you trying to do, that Diffie-Hellman cannot do ?


What is the job of an IT auditor? I am going through training in information security, as a part of the course they included compliance standards like:

PCI DSS
ISO 27001-2005
Cobit framework

So after searching over Google, I came to know that it is for "IT auditors" (correct me if I am wrong).

In layman terms, what is the job of an IT auditor?

An auditor examines an organization to determine if they appear to be compliant with a particular standard or regulation. They make their findings based on evidence, often directly supplied by the organization upon request of the auditor. And they are generally independent from the organizations they audit.

In the case of a security audit, the auditor may look for evidence that the organization has a security policy, that the policy is adequate to protect them according to the standard, and that the organization follows it. That policy will state practices to be followed, such as requiring code reviews. An auditor likely won't do a code review himself, but he might look for a documentation trail that demonstrates the organization does do code reviews. The standard may also require annual penetration tests, and he will examine documents produced by the penetration testers. He might also check with the pen testing company to be sure the organization wasn't lying about having pen tests. If he doesn't see such documentation trails, he finds that the organization is out of compliance.

An auditor can't verify that an organization is secure. He can only find that an organization appears to be trying to operate in a secure manner.


Isolate part of my PC to keep security for online purchases? Soon I'll doing some purchases online using my mother's credit card. She's pretty sceptical about online shopping but I convinced her. She's not so sure about how secure it is and since I'm not so sure if I have some malware running on my PC, I want to be on the safe side and don't want to risk it. I already ran scans with Avast and Malware Bytes.

My question is, is there any easy and fast way I can isolate a part of my PC so I can purchase from there? Would a VM work in this case?

Running in a virtual machine will generally provide a good amount of isolation. You can also use a sandbox tool which is included with many anti-malware packages or an independent one such as Sandboxie. Other alternatives include using a live cd that you boot fresh each time you want to have a known system state.

However, the reality is that malware on your local PC is not the only or most likely threat you face with online shopping. If the website from which you are purchasing has poor security, then the attacker may be able to intercept messages or to hack the company and steal your data from the company without compromising your machine.

Every day in life you need to take measured risks. If you are using a well known or generally trusted website (reseeller ratings, web of trust ratings, etc ) you have less risk. You also have a risk of using a credit card in a store like Target (which had a credit card breach last year), which then gets breached. The best thing to do is to check your credit report at least once a year (free for all in the US per law once per year from each credit bureau) and to always check your credit card bills; card issuers are generally responsible for reversing fraudulent charges if reported by the card holder. You could also purchase identity theft monitoring services for peace of mind.


Is it neccessary that website certificate must have site URL? While working on a scenario, I got the error message "Server's certificates doesn't match the url".

Is it necessary that the certificate given from the website must have its URL? Is it necessary that the certificate must have the complete name of the URL or will it also work if I use a part of URL?

First, it's not a URL, it's a host name or domain name. The host name is one part of the URL. http://security.stackexchange.com/questions/92838/is-it-neccessary-the-website-certificate-must-have-site-url is a URL, and the host name is security.stackexchange.com.

Next, yes, at least one host name in the certificate must match the exact host name used to access the site. You can get wildcard certificates, e.g. *.example.com, which would match <anything>.example.com (but not <anything>.<anything>.example.com or example.com).


Company decrypting SSL, is it common? We've just implemented a proxy that decrypts all SSL traffic in order to classify and scan it. Naturally a lot of our users feel concerned. We're a small company (100 users) owned by a big company (5000 users). What we hear internally is that "other companies doesn't do this". I think that this is the de facto standard for all major companies but I really don't know. Please elaborate your views, is this an exception or the de facto standard for companies (albeit primarily large, which we are counting with our parent company)?

Oh, we use proxy appointed by auto discovery but are about to block http/https bound traffic in firewalls. Yes, I know many ways to circumvent this and we will not be doing the cat and mouse game because I don't see how one can win that.

"SSL decryption" (through a firewall-controlled CA and on-the-fly MitM) is a feature offered on most "expensive" firewall appliances, so one can say that most big companies can deploy SSL decryption. Whether they really do it is another matter. Common reasons for not using that feature include:

Legal concerns. In many jurisdictions, employees are allowed some level of personal usage of the company-provided computers (in the same way that people can use the company phone for short personal calls), and snooping on a communication between the employee and his bank or physician would be food for litigation.
Compatibility. Many "SSL decryptors" do a somewhat flaky job; e.g. the fake server certificate that the client browser sees contains a 1024-bit RSA key that triggers warnings, or CRL/OCSP for that certificate is not properly supported. And, of course, that MitM breaks client certificates (e.g. smart cards).
User resistance. Users simply don't like the idea of their SSL data being inspected.

That last point is interesting. Firewalls that do SSL decryption use a special CA and on-the-fly fake server certificate generation for ease of deployment, but this is hardly the only method to do it. On a company-controlled office computer, the sysadmin may perfectly well install locally some software that hooks with the SSL libraries and inspects data as it flows, outside of the SSL protection. Most antivirus software do just that; and it does not cause so much user fretting. Therefore we may say that what users don't like is not that their data is inspected; what they really abhor is knowing that their data is inspected. Ignorance is bliss.

Personally, when I see such a "SSL decryption" system put in place, my first thought is not "OMG they are looking at my SSL !" but rather "At least they are open about it".

I don't have stats -- I think nobody has, except possibly appliance vendors, but they don't tell (honestly, who wants to say: "my product has a nice feature that nobody uses" ?). But my feeling and experience tell me that company-wide SSL decryption through a visible firewall-controlled CA is still something rare, whereas hidden, transparent inspection done directly on the client machine is highly prevalent. The "fake server certificate" method will become more common in the future, because it makes it much easier to support content filtering for user-provided devices (even if not going full BYOD, companies that provide a complimentary "external" WiFi for their employees prefer it when even that non-privileged network does not become a cesspool of malware and videos of questionable legalities).


Possible DOS Attack? And solutions for it? I don't know whether it's appropriate to post this question here but I desperately need help.

I've been receiving ping requests from 18 different IP addresses so far. Some of them are local, some are from US and Russia. In half an hour, my router dropped 220 ping requests.
And last night, my router logged that there's SYN Flooding attacks, TELNET requests, and SYN-FIN attack

It got me disconnected from the net quite a lot of times. So, are the ping requests a DoS attack or it's really THAT NORMAL to have so many ping in such a short amount of time. And also, any solutions will be greatly appreciated.

220 ping requests hardly qualify as DoS. A SYN flood is a kind of DoS, and if your router is reporting a SYN flood then chances are that there is someone playing at pestering you with low-scale DoS. The ping requests are not part of that attack, but may be used by the attackers to monitor whether the attack works or not (i.e. whether they could crash your router or not).

Usual mitigation against such attacks is simply to wait for the attacker to get bored or to reach the age of 13, whichever comes first. You may want to alert your ISP, though (don't tell them "I am being attacked" but rather "I get disconnected and my router shows this strange error message"; disconnections are part of the scope of their job and if some formal complain must be made with law enforcement agencies then having the ISP handle part of it would be a good idea).


Child iFrame hash verification of parent iFrame content Consider the following scenario:

Alice wishes to browse Victor's website while on the job at Initech.  Victor's website is hosted on an alternative domain name system to which Initech's DNS does not peer.  Eve (wishing to facilitate the free and open exchange of knowledge) hosts a webpage containing JS that performs domain-name resolution and URL masking such that when Alice visits victor.eve.tld an iFrame loads victor.alt based off of the static IP address Victor has designated in the victor.alt DNS record.

For seamless domain-name masking, Victor must place CORS authorization in the headers from his site to dance around the single origin policy.  However, Victor suspects that Michael is trying to hack into Eve's web server and plant malicious JS into Eve's webpage (the parent of the iFrame).  Victor wants verify that Michael has not modified the contents of the parent frame before he enables CORS authorization.

Victor has a copy of Eve's site and can include hashes of the material w/ out contacting Eve's server, so if he has read access, he can match the content.  Micheal does not have access to Initech servers and connections from both sites are secured using TLS: assume that Micheal cannot carry out a man-in-the-middle attack.

Is it possible for an iFrame to verify the contents of the parent window:

using any CORS configuration?
while allowing read-only access?
while limiting the the parent window's access to the content of the iFrame?

There are prior discussions regarding client-side JS verification from an untrusted cache (with a trusted connection, no MtM) but this situation requires validation by the material that is being fetched.  There are also numerous posts regarding the use of iFrames to sandbox untrusted code.  However, iFrame sand-boxing questions tend to revolve around a the parent window trusting the child, as does most of the external literature on the subject (frame-busting, etc).

Furthermore, Eve's server cannot actively participate in the process: she can only serve static HTML, JS, and CSS files.  Victor cannot proxy information through Eve's server, he can only interact with his own or 3rd party servers.

using any CORS configuration?

If Eve sets her CORS header to  Access-Control-Allow-Origin "victor.alt" Victor can verify the contents of the HTML it retrieves and verify all referenced scripts as well.

while allowing read-only access?
while limiting the the parent window's access to the content of the iFrame?

Neither of these exist, an iFrame cannot read the contents of another iFrame unless they are on the same domain.

However, you could push any user information you want to keep private from Victor into a sandboxed iFrame and using window.postMessage to communicate between frames.  Victor can monitor the activity between the two to ensure that no information is being leaked.


On TLS 1.2 with Diffie-Hellman Key Exchange, how does the client make sure the server has the certificate's private key? When RSA is used for Key Exchange, the pre-master key is encoded with the server certificate public key, so the server would not be able to decode it if it didn't possess the private key.
However, when ECDHE is used for Key Exchange, how does the client make sure the server is legit and possess the private key relative to the provided certificate?

The ECDHE key exchange does not care about the private key of the certificate. The private key is only used for authentication, which is like the key exchange part of the TLS handshake. But authentication is not part of the ECDHE key exchange.
Basically, the authentication is done by the server signing some data which are at least in part depend on client data. The client can  then verify this signature using the public key in the certificate.


What is a Shrink Wrap code attack? On my C|EH course I have heard about term "Shrink Wrap Code Attack", but we've only mentioned it.  Now trying to do some research and refresh the topics, I can't seem to find serious description of this attack type.

Looking at presentation PDF I received at the course, it only cites couple of sentences
illustrating the main idea (obviously these presentations are not intended for separate
studying)
it seems that this exact phrase is somewhat colloquial to C|EH, so Google is flooded
only either with instances of above or with quite useless re-interpretations of it

So what is this Shrink Wrap code attack about?

(Any good examples?  Or stories how it was particularly successful?  Or interesting links?)

Update: This Joel on Software uses the term "Shrinkwrap code" for general type of software that is produced and distributed massively.

  Shrinkwrap is software that needs to be used "in the wild" by a large
  number of people.  It may be actually wrapped in cellophane and sold
  at CompUSA, or it may be downloaded over the Internet. It may be commercial
  or shareware or open source or GNU or whatever -- the main point here
  is software that will be installed and used by thousands or millions of
  people.

Joel does not particularly mention security POV here, though.

Strictly based on the context in the presentation, it seems what EC-Council is calling a "Shrink Wrap code attack" is just the act of exploiting holes in unpatched or poorly-configured software.  To use the term another way, a "Shrink Wrap vulnerability" would be one which should only be seen in a product immediately after its initial installation - "fresh out of the shrink wrap" you might say.

Most of the Internet relies upon a relatively small number of different applications, frameworks, and OS's.  Because these platforms are shared across a large target base, and because so many organizations and/or admins choose to ignore the "low-hanging fruit", these sorts of vulnerabilities are often the first an attacker will turn to in order to quickly exploit a system.

Here are some general descriptions of what might be categorized as a "Shrink Wrap vulnerability":

A software bug present in the original version of a product, for which the vendor has released an update but the system admin has not patched.

Example:  CVE-2012-1528 in Windows 8, if the target system does not have the KB2727528 update installed.

An insecure default configuration option still in place after the system has been put into production.

Example:  Default (esp. when publicly known or easily calculated) account usernames & passwords left unchanged.

Debugging scripts or insecure test pages that are bundled with the software, which should have been removed prior to production use.

Example:  A "Hello World" script or page left in place, with an XSS vulnerability.

The above vulnerabilities are not, in most regards, very different from any other vulnerability.  What makes them stand out though, is that they are so easily fixable and really are not the types that should be found in production systems.  These are the types of vulnerabilities that should be resolved during the initial build process of the system or application, but too many sysadmins and developers out there will carelessly or ignorantly leave them open for the whole Internet to exploit.


How can I recover a GPG private key from a PC which has died? Long story short - PC with kleopatra processor died, and I only have a backup of my public key.

I've gone into the HDD and tried to re-jig kleopatra in the hope it would remember everything for me on another machine but that hasn't gone well...

Do I just need to get this HDD into a new PC and boot from it, then export my private key?

You cannot recover from a public key to a private one – at least not within any kind of reasonable (computing) time. Being able to calculate a private key from the public one would circumvent encryption and would lead all efforts to ad absurdum.

You need to either:

Try to recover from an old backup (like you succeeded to do following your comment)
Revoke the key (on key servers) if you published it using a revocation certificate (you hopefully created). If you haven't, do so now.

There is no way to recover control over a lost private key – if there is no copy left, you've lost control over it.


How bad it is to feed /dev/random with /dev/urandom? I have seen many blog posts, or blog comments which recommends to feed /dev/random entropy using output from /dev/urandom.

I'm not a crypto expert, but it looks like a good way to replace hard-to-predict numbers with much less random numbers. But is there any insight about how worse is it effectively?

If I ever find a server with such a configuration, do I need to invalidate tls certificates, ssh and gpg keys right know, like with the infamous debian bug CVE-2008-0166 ? Or is it more like a state-sponsored attacker may find my private key given a few billion euros?

I am assuming a Linux system here, on some OS like FreeBSD and Mac OS there isn't any difference between /dev/random and /dev/urandom, and yet others don't have those devices

Both /dev/random and /dev/urandom use the same entropy pool. The difference is that /dev/random "counts" how many bytes have been extracted, estimating the entropy left in the pool. If at one point it considers there's not enough entropy for what it is being asked, it will block, whereas /dev/urandom will provide the requested bytes.

The fact is, just /dev/urandom would have been perfectly fine (except shortly after boot up). Feeding /dev/random with /dev/urandom is a way of cheating, but shouldn't really break the security.

  do I need to invalidate tls certificates, ssh and gpg keys right know, like with the infamous debian bug CVE-2008-0166 ?

Not at all.

  Or is it more like a state-sponsored attacker may find my private key given a few billion euros

Even for a state-sponsored attacker, I don't think it wouldn't be tratable to figure out the random bytes that were extracted from the random pool on a normal system.

The exception are embedded devices, such as routers, where they too often are found to generate a random key (eg. for https or ssh) shortly after boot-up, where they actually have a quite deterministic state.

Still, for longterm keys like those you mention, you may prefer nonetheless to feed from /dev/random knowing that it will take longer, and just sidestep the usage of /dev/urandom. And that's fine, too.


VPN with client certificate via managed PKI - where did private key come from? $company allows Mac users to request a client certificate via Symantec PKI to connect to their SSL VPN server. This process involves going to a specific Symantec website (has some sort of ID to identify $company) and entering your name ("Common Name") and Email address. Once approved by a company admin it gives you a link which downloads a .cer file, and when this is imported into Keychain there is a user-named Certificate and a private key linked to it.

Where did that private key come from?  It doesn't appear in the .cer file (which appears to be 3 certificates bundled in PKCS#7 format).  Is there some trigger when imported that tells Keychain to go and fetch a private key from the PKI server?  Is there any generic tool (e.g. openssl) to do that on Linux?

Edit:

The .cer file contains a certificate with CN=MyNameHere (the user), an Issuing CA certificate belonging to $company, and an Intermediate CA certificate also belonging to $company.

Here's an article explaining how to export the private key under windows, but unfortunately doesn't explain how the private key got there either.

Here's another doc from a Mac perspective about exporting the private key, but again doesn't go into how the key gets there in the first place.

I am taking a slight guess, however, I suspect that in browser is using generateCRMFRequest and importUserCertificate in combination. An overview of the process is given by the deprecated Javascript_crypto documentation for Firefox.

Similar things can be achieved with Internet Explorer. I haven't looked but I imagine Safari has some level of support too.

These are entirely non-standard extensions, and according to this post on the CA/Browser forum, not the future.

The key is generated locally, however, it is hard to tell whether or not the key is also sent to the CA for "archival" as in generateCRMFRequest. Since the javascript has access to the generated key, it could conceivably send it over the internet.

Final bit of info, is there a generic tool to do this in Linux? Not to my knowledge. You can certainly go through the process of:

openssl genrsa ... -out private.key
openssl req -new ... -inkey private.key -out certplease.csr

sending certplease.csr to the CA. From them you would get back a PKCS#7 certificate signed by them (and possibly other certificates in the chain, in case they are needed).

However, I don't believe there is a standard user-based private key store in Linux - rather, each desktop environment has a slightly different one.


SSL security display Why does Firefox not display the SSL logo when viewing secure sites, i.e. sites with HTTPS? It used to display at the bottom of the browser window previously but I just noticed that that bottom toolbar is not longer displayed. When I try to find the option to turn it on in Firefox, there is no such option.

There is no such thing as a "SSL logo". However, there is a long-standing tradition (nothing as official as a logo) of making some ongoing SSL explicit with an icon figuring a padlock. In recent versions, Firefox decided to put that padlock on the left of the URL bar, like this:

The icon is actually redundant with the https protocol indication in the URL itself. However, many non-technically inclined people find the padlock icon easier to grasp.

The icon is also clickable; it will give details on the server's certificate, and the currently used SSL/TLS cryptographic algorithms.

Browsers are very susceptible to fashion; the padlock icon used to be in the bottom bar in the days of Netscape and early versions of Internet Explorer. It then gradually migrated up. Firefox is simply following the trend.


How to ensure that our production environment deployment process is PCI-compliant when we need to perform live code updates? In planning the next phase of our platform, I am trying to ensure that the production deployment process is PCI compliant.

We have a central platform which acts as a CMS, serving custom content based on an event type, that will reside in a hardened IIS server/environment.

Each new event has a basic splash screen and a custom domain name, i.e. www.myevent1.com, www.myevent2.com, etc.

The issue is that we will need to add new domain names frequently. Being PCI-compliant, we can't have developers accessing production servers.

PCI-DSS 6.4 states:

  A separation of duties between personnel that are assigned to the
  development/test environments and those persons assigned to the
  production environment.

I'm trying to maintain the separation of tasks per compliance specs.

Thus, I my thoughts were to maintain the CMS server as-is, fully hardened - no developer access.  Then have a secondary IIS server where developers can add new domains as needed, and upload the static splash pages that link to the CMS content.

Thoughts?

-- UPDATE --

We will be using PCI-DSS Level 4 compliance, so we won't have any card-holder data on our servers.  The payment processor will have this info.

Is there real need of having CMS inside of the CHD (card-holder data) environment? We always recommend to keep the CHD as small as possible. Isn't it possible to design it in another way where your PCI DSS environment will just process/transfer/store the CHD and pass something as "tokens" outside (i.e. to CMS) instead of storing the CHD directly in CMS?

Its hard to recommend anything here as I have no clue where do you store the CHD, what is the purpose of it and many many other things...

As @ISMSDEV said, why developers should access such the production area? Developer develops the code while app admin deploys it and maintains. I can't see any reason why developers should have access to production...

By the way, if you design PCI DSS environment and you plan to certify it, I would recommend to hire some consultancy company / person with deep knowledge of it. It will help you so much and it is worthy as it is really not easy to get everything compliant. While I consider PCI DSS as a best security standard I have ever seen it is really hard to fulfill all its requirements. Sometimes, even if you think you are doing things right the auditor tells you it can't be like that. Simply because you just wrongly understood the requirement or you can't see all aspects of it. And if he tells you this once you have complete design of the environment finished, applications developed, documentation written and you keep evidence of everything its hard and expensive to rework it...

If you don't store, process or transfer the CHD you DON'T NEED TO BE PCI DSS compliant in any way. Of so, you are lost.


Caching ARP to avoid L2 detection on switched network? Using nmap on a very large (/16) switched network can lead to an excessive number of ARP requests which can be detected by simple ARP counters listening to broadcasted ARP requests.

Is there a way to avoid ARP host discovery on local network ?
During port scan (TCP SYN), instead of slow down the scan speed (-T2 or less), is there any nmap parameters or external tools to fill and freeze the ARP cache ? Is it an effective way to handle L2 detection risk ?

There is no way to avoid sending an ARP request for each target IP address you intend to communicate with on your local link. This is because IP communication over an ARP-type link (like Ethernet or 802.11a/b/g/n) requires an ARP request and response to determine the hardware address (MAC) associated with the IP address you intend to contact.

As mentioned in the comments, Nmap has an option called --disable-arp-ping. However, this does not disable sending ARP requests; it simply offloads that responsibility to the scanner's OS, requiring network-layer (IP) responses to consider the target host "up". This actually results in more traffic being sent. It is really only useful in cases where ARP responses are being spoofed.

There are host discovery options using NSE scripts that do not require sending ARP requests to every possible target address, but they are likely to miss at least some hosts:

broadcast-ping will send an ICMP Echo Request to the interface's broadcast address. Some systems will respond to these, but not all.
targets-sniffer will sniff network traffic for a configurable time period and add any observed addresses to the target queue. This requires the targets to be sending traffic to the scanner, usually broadcast traffic.
broadcast-dns-service-discovery and lltd-discovery are two of many scripts that send broadcast or multicast traffic to elicit responses from particular services on a network.
The targets-ipv6-multicast-* scripts can be used to discover IPv6 addresses on your local network. In addition to directly scanning these IPv6 addresses, you can sometimes use other discovery scripts to gather the host's IPv4 addresses from various listening services.
Other scripts like ntp-monlist or dns-zone-transfer can gather lists of targets from certain services, but require you to know which hosts are running these services.


What benefit do Captchas provide? I have researched and found the following sites which will break captchas:

anticaptcha
2captcha

(links not included to prevent promoting the sites)

Given that these services can be used to break captchas, what is the benefit in using captchas, especially as they can impact human users?

"given that there are locksmiths, what's the point of locking your door?"

Just because something has limitations doesn't mean it's useless. Those services cost money, maybe more money than an auto-registered account is worth. There are also classes of attackers who don't have access to those kind of services. InfoSec is often a numbers game, and capthas are a cheap (not perfect) way to give bigger numbers to the good guys.


Has the leaked D-Link Windows signing key been revoked? Recently news broke as to D-Link mistakenly publishing a private code-signing key as part of an open source framework:

The D-Link key was leaked in late February, and expired on September 3, it appears.
That means during that six-month period, miscreants who happened across the key could digitally sign their malware so that it appeared to be a legit D-Link application. This software would be trusted by Microsoft Windows, and allowed to run and infect someone's machine.
...
The D-Link key may have been revoked, meaning any code signed by it should no longer be trusted by Windows. Even if it hasn't been revoked, it has definitely expired, so no new malware can be signed using it. (Malicious code already signed by the key will still be trusted until revocation occurs.)

Source: The Register, 2015-09-18, D-Link spilled its private key onto the web – letting malware dress up as Windows apps. (Archived here.)
Has said key been revoked yet?

Update 2016-12-28: I finally decided to check the CRL as well. And it turns out: Yup, certificate is in there still. Even long after its original expiration date.

$ openssl x509 -in 0.dlink.cer -noout -fingerprint | sed 's/://g'
SHA1 Fingerprint=3EB44E5FFE6DC72DED703E99902722DB38FFD1CB

$ openssl x509 -in 0.dlink.cer -noout -serial
serial=5067339614C5CC219C489D40420F3BF9

$ openssl x509 -in 0.dlink.cer -noout -text | grep CRL -A3 | grep URI | sed 's/^ *URI://'
http://csc3-2010-crl.verisign.com/CSC3-2010.crl

$ openssl x509 -in 0.dlink.cer -noout -text | grep CRL -A3 | grep URI | sed 's/^ *URI://' | xargs -- wget -q --

$ sha256sum CSC3-2010.crl
529d1b6a0588d91bf2f8dc25e35b52d54f2865499d2d4fd6153f488bb1e90e73 *CSC3-2010.crl

$ openssl crl -inform der -in CSC3-2010.crl -noout -text | grep -A1 "Serial Number: 5067"
    Serial Number: 5067339614C5CC219C489D40420F3BF9
        Revocation Date: Sep  3 00:00:00 2015 GMT

Further info on pastebin: CRL snapshot PEM format, CRL snapshot parsed text format.

Update 2016-09-29, 2/2: If you wish to try the openssl ocsp command for yourself: I have put the D-Link certificates and the verbose OCSP output on PasteBin.

Update 2016-09-29, 1/2: Coming back to this post a year later, I checked VirusTotal and, yes, they now list the file signature as revoked under the "File detail" tab. (But I don't know when exactly in the last 11 months that happened.)

Update 2015-10-02: Related question: Did D-Link's certificate revocation really only invalidate 1 day (of a six months long exposure)?

Update 2015-09-25. Revoked now.

OCSP via OpenSSL yields "revoked"

$ openssl ocsp -issuer 1.intermediate.verisign.cer -CAfile <(cat 1.intermediate.verisign.cer 2.root.verisign.cer) -cert 0.dlink.cer  -url http://ocsp.verisign.com
WARNING: no nonce in response
Response verify OK
0.dlink.cer: revoked
        This Update: Sep 24 19:26:52 2015 GMT
        Next Update: Nov  7 03:08:53 2015 GMT
        Reason: keyCompromise
        Revocation Time: Sep  3 00:00:00 2015 GMT

Weird Revocation Time

Timeline for perspective:

Jul  5 00:00:00 2012 GMT. Validity: Not Before
Feb 27          2015      Inadvertent disclosure
--- six months of nothing ---
Sep  3 00:00:00 2015 GMT. OCSP "revocationTime" backdated to this.
--- one day of invalidity (?) ---
Sep  3 23:59:59 2015 GMT. Validity: Not After
Sep 17          2015      Tweakers.net report
Sep 18          2015      TheRegister.co.uk report
Sep 20 14:00    2015      This question here posted.
Sep 20          2015      Answer posted. OCSP `good`
Sep 22          2015      Update answer posted. OCSP `revoked`

So: OCSP revocationTime is 2015-09-03. But when I checked on 2015-09-20 it was still good. So this seems backdated. (Correct me if I'm wrong.)

So if you backdate at all, then why not backdate directly to 2015-02-27? Does this even matter?

Microsoft blacklisted

Microsoft Security Advisory 3097966, 2015-09-24, Inadvertently Disclosed Digital Certificates Could Allow Spoofing

  Microsoft is aware of four digital certificates that were inadvertently disclosed by D-Link Corporation that could be used in attempts to spoof content. The disclosed end-entity certificates cannot be used to issue other certificates or impersonate other domains, but could be used to sign code. This issue affects all supported releases of Microsoft Windows.

VirusTotal still good.

Reason unknown. Might be because of the weird revocationTime.

Old messages below.

No. OCSP is still "good".

No longer valid. See 2015-09-25 update.
OCSP says it's still "good". CRL, I don't know. (And I didn't try CRL either.) CRL isn't supposed to (or mustn't ?) list any certificate that's already expired. And that D-Link cert expired about two weeks ago.

Checking with OpenSSL

$ openssl ocsp -issuer 1.intermediate.verisign.cer -CAfile <(cat 1.intermediate.verisign.cer 2.root.verisign.cer) -cert 0.dlink.cer  -url http://ocsp.verisign.com
WARNING: no nonce in response
Response verify OK
0.dlink.cer: good
    This Update: Sep 19 11:43:51 2015 GMT
    Next Update: Sep 26 11:43:51 2015 GMT

Checking with VirusTotal.com

Here's a sample file that was signed with that particular D-Link certificate:

https://www.virustotal.com/en/file/c25988e924a91a262029d8786c888bbc318d1500ddbd83e1cbe8c7e82f84e292/analysis/

VirusTotal screenshot

And as of now (2015-09-20) it still says "Valid" under File Details | Signers | [+] D-LINK CORPORATION | Status

I guess this status might change in the next few weeks.
Then it should say Signature verification:  A certificate was explicitly revoked by its issuer. Like these two certs here for example:

VirusTotal: Revoked Bit9 cert
VirusTotal: Revoked Samsung cert

Chain members

If you want to check yourself, below are the files I used.

0.dlink.cer

This is the certificate with the Serial Number and SHA1 hash that match with the screenshots in the Tweakers.net article.

$ openssl x509 -in 0.dlink.cer -noout -fingerprint
SHA1 Fingerprint=3E:B4:4E:5F:FE:6D:C7:2D:ED:70:3E:99:90:27:22:DB:38:FF:D1:CB

$ openssl x509 -in 0.dlink.cer -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            50:67:33:96:14:c5:cc:21:9c:48:9d:40:42:0f:3b:f9
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 Code Signing 2010 CA
        Validity
            Not Before: Jul  5 00:00:00 2012 GMT
            Not After : Sep  3 23:59:59 2015 GMT
        Subject: C=TW, ST=Taipei, L=TAIPEI CITY, O=D-LINK CORPORATION, OU=Digital ID Class 3 - Microsoft Software Validation v2, CN=D-LINK CORPORATION
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:e2:d5:cc:02:33:47:16:ea:79:bc:51:39:ae:c3:
                    f6:96:f6:43:73:68:6c:35:83:58:63:f6:46:d8:56:
                    48:df:48:fd:bd:b0:a6:0c:59:10:20:89:c0:cc:73:
                    59:2f:8c:1a:5a:fc:15:b7:b8:de:cc:4e:1b:3f:50:
                    4c:98:bb:53:33:fc:7b:13:15:b1:b5:c0:5d:97:95:
                    81:ab:9c:2d:0a:3c:e5:14:0d:03:3d:cd:6e:43:9c:
                    0a:75:04:00:b8:50:32:12:ba:9e:6f:ac:fe:93:c7:
                    93:53:c9:98:29:71:dc:85:fc:23:ef:8c:4a:6a:e7:
                    b9:c7:47:af:58:73:cb:29:e1:3b:ac:c9:55:71:89:
                    4c:d6:0a:7c:70:dc:bc:cb:f0:b4:dd:25:ec:72:96:
                    86:36:86:09:1c:c7:ba:5f:a4:37:2d:42:f0:ae:00:
                    fb:5d:97:52:ed:c6:e0:d5:bd:2f:71:fe:98:f6:b4:
                    40:d1:67:61:0a:41:ce:a2:32:6d:ce:90:d9:5f:09:
                    df:b3:c8:f9:8c:da:33:89:42:8d:72:1e:a2:39:c7:
                    2a:2d:b0:a3:91:aa:8a:e9:a9:e6:ab:24:7b:62:d2:
                    9b:35:22:0f:46:1c:87:8b:af:e1:19:98:b4:bd:cf:
                    6d:4c:c4:04:7f:cf:a1:dd:47:71:d8:fb:eb:33:3e:
                    09:d9
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://csc3-2010-crl.verisign.com/CSC3-2010.crl

            X509v3 Certificate Policies:
                Policy: 2.16.840.1.113733.1.7.23.3
                  CPS: https://www.verisign.com/rpa

            X509v3 Extended Key Usage:
                Code Signing
            Authority Information Access:
                OCSP - URI:http://ocsp.verisign.com
                CA Issuers - URI:http://csc3-2010-aia.verisign.com/CSC3-2010.cer

            X509v3 Authority Key Identifier:
                keyid:CF:99:A9:EA:7B:26:F4:4B:C9:8E:8F:D7:F0:05:26:EF:E3:D2:A7:9D

            Netscape Cert Type:
                Object Signing
            1.3.6.1.4.1.311.2.1.27:
                0.......
    Signature Algorithm: sha1WithRSAEncryption
         eb:4e:60:57:88:d5:ce:77:a1:94:32:9b:68:fd:3c:23:c4:06:
         fc:43:2e:d6:66:8c:9d:6d:7a:03:07:fb:7b:66:24:3b:30:99:
         9b:d1:3d:66:a9:ca:95:f0:e3:1c:e0:6b:45:03:51:f4:64:15:
         e8:8e:7a:98:17:8c:c0:95:56:58:55:54:ae:54:5d:8f:e2:65:
         0e:cd:79:17:87:0e:8a:2e:40:de:2e:1c:35:5b:6e:ea:23:5a:
         4d:70:8e:1d:05:c0:04:d6:2d:c1:26:80:cf:0f:f8:b6:84:4c:
         eb:82:44:c4:03:f0:65:9e:33:43:f0:e7:39:73:30:be:51:11:
         e8:70:b3:c3:48:77:fd:d2:e0:8f:fe:dd:89:27:b5:b0:31:ac:
         57:63:9d:29:68:9d:2a:8e:e4:d0:dd:5e:d0:6d:f3:bf:63:4d:
         fa:76:ff:f8:ad:a8:29:c9:90:32:f4:31:22:32:b8:67:92:00:
         15:3f:ae:cd:27:71:c2:01:80:24:52:09:6c:14:63:0b:c0:b6:
         69:16:5c:d4:34:a4:40:b0:c6:b6:c3:90:ef:64:fc:a8:b2:eb:
         d8:57:68:43:47:21:55:88:2b:f3:f8:e7:84:52:75:17:73:0c:
         8f:86:f7:b1:ea:66:4e:c5:47:7c:27:13:d0:f4:c7:c6:8a:8a:
         f0:df:d9:a5
-----BEGIN CERTIFICATE-----
MIIFazCCBFOgAwIBAgIQUGczlhTFzCGcSJ1AQg87+TANBgkqhkiG9w0BAQUFADCB
tDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDEuMCwGA1UEAxMl
VmVyaVNpZ24gQ2xhc3MgMyBDb2RlIFNpZ25pbmcgMjAxMCBDQTAeFw0xMjA3MDUw
MDAwMDBaFw0xNTA5MDMyMzU5NTlaMIGuMQswCQYDVQQGEwJUVzEPMA0GA1UECBMG
VGFpcGVpMRQwEgYDVQQHEwtUQUlQRUkgQ0lUWTEbMBkGA1UEChQSRC1MSU5LIENP
UlBPUkFUSU9OMT4wPAYDVQQLEzVEaWdpdGFsIElEIENsYXNzIDMgLSBNaWNyb3Nv
ZnQgU29mdHdhcmUgVmFsaWRhdGlvbiB2MjEbMBkGA1UEAxQSRC1MSU5LIENPUlBP
UkFUSU9OMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4tXMAjNHFup5
vFE5rsP2lvZDc2hsNYNYY/ZG2FZI30j9vbCmDFkQIInAzHNZL4waWvwVt7jezE4b
P1BMmLtTM/x7ExWxtcBdl5WBq5wtCjzlFA0DPc1uQ5wKdQQAuFAyErqeb6z+k8eT
U8mYKXHchfwj74xKaue5x0evWHPLKeE7rMlVcYlM1gp8cNy8y/C03SXscpaGNoYJ
HMe6X6Q3LULwrgD7XZdS7cbg1b0vcf6Y9rRA0WdhCkHOojJtzpDZXwnfs8j5jNoz
iUKNch6iOccqLbCjkaqK6anmqyR7YtKbNSIPRhyHi6/hGZi0vc9tTMQEf8+h3Udx
2PvrMz4J2QIDAQABo4IBezCCAXcwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCB4Aw
QAYDVR0fBDkwNzA1oDOgMYYvaHR0cDovL2NzYzMtMjAxMC1jcmwudmVyaXNpZ24u
Y29tL0NTQzMtMjAxMC5jcmwwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgG
CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMBMGA1UdJQQM
MAoGCCsGAQUFBwMDMHEGCCsGAQUFBwEBBGUwYzAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AudmVyaXNpZ24uY29tMDsGCCsGAQUFBzAChi9odHRwOi8vY3NjMy0yMDEw
LWFpYS52ZXJpc2lnbi5jb20vQ1NDMy0yMDEwLmNlcjAfBgNVHSMEGDAWgBTPmanq
eyb0S8mOj9fwBSbv49KnnTARBglghkgBhvhCAQEEBAMCBBAwFgYKKwYBBAGCNwIB
GwQIMAYBAQABAf8wDQYJKoZIhvcNAQEFBQADggEBAOtOYFeI1c53oZQym2j9PCPE
BvxDLtZmjJ1tegMH+3tmJDswmZvRPWapypXw4xzga0UDUfRkFeiOepgXjMCVVlhV
VK5UXY/iZQ7NeReHDoouQN4uHDVbbuojWk1wjh0FwATWLcEmgM8P+LaETOuCRMQD
8GWeM0Pw5zlzML5REehws8NId/3S4I/+3YkntbAxrFdjnSlonSqO5NDdXtBt879j
Tfp2//itqCnJkDL0MSIyuGeSABU/rs0nccIBgCRSCWwUYwvAtmkWXNQ0pECwxrbD
kO9k/Kiy69hXaENHIVWIK/P454RSdRdzDI+G97HqZk7FR3wnE9D0x8aKivDf2aU=
-----END CERTIFICATE-----

1.intermediate.verisign.cer

$ openssl x509 -in 1.intermediate.verisign.cer -noout -fingerprint
SHA1 Fingerprint=49:58:47:A9:31:87:CF:B8:C7:1F:84:0C:B7:B4:14:97:AD:95:C6:4F

$ openssl x509 -in 1.intermediate.verisign.cer -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            52:00:e5:aa:25:56:fc:1a:86:ed:96:c9:d4:4b:33:c7
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
        Validity
            Not Before: Feb  8 00:00:00 2010 GMT
            Not After : Feb  7 23:59:59 2020 GMT
        Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 Code Signing 2010 CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:f5:23:4b:5e:a5:d7:8a:bb:32:e9:d4:57:f7:ef:
                    e4:c7:26:7e:ad:19:98:fe:a8:9d:7d:94:f6:36:6b:
                    10:d7:75:81:30:7f:04:68:7f:cb:2b:75:1e:cd:1d:
                    08:8c:df:69:94:a7:37:a3:9c:7b:80:e0:99:e1:ee:
                    37:4d:5f:ce:3b:14:ee:86:d4:d0:f5:27:35:bc:25:
                    0b:38:a7:8c:63:9d:17:a3:08:a5:ab:b0:fb:cd:6a:
                    62:82:4c:d5:21:da:1b:d9:f1:e3:84:3b:8a:2a:4f:
                    85:5b:90:01:4f:c9:a7:76:10:7f:27:03:7c:be:ae:
                    7e:7d:c1:dd:f9:05:bc:1b:48:9c:69:e7:c0:a4:3c:
                    3c:41:00:3e:df:96:e5:c5:e4:94:71:d6:55:01:c7:
                    00:26:4a:40:3c:b5:a1:26:a9:0c:a7:6d:80:8e:90:
                    25:7b:cf:bf:3f:1c:eb:2f:96:fa:e5:87:77:c6:b5:
                    56:b2:7a:3b:54:30:53:1b:df:62:34:ff:1e:d1:f4:
                    5a:93:28:85:e5:4c:17:4e:7e:5b:fd:a4:93:99:7f:
                    df:cd:ef:a4:75:ef:ef:15:f6:47:e7:f8:19:72:d8:
                    2e:34:1a:a6:b4:a7:4c:7e:bd:bb:4f:0c:3d:57:f1:
                    30:d6:a6:36:8e:d6:80:76:d7:19:2e:a5:cd:7e:34:
                    2d:89
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Certificate Policies:
                Policy: 2.16.840.1.113733.1.7.23.3
                  CPS: https://www.verisign.com/cps
                  User Notice:
                    Explicit Text: https://www.verisign.com/rpa

            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            1.3.6.1.5.5.7.1.12:
                0_.].[0Y0W0U..image/gif0!0.0...+..............k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.verisign.com/pca3-g5.crl

            Authority Information Access:
                OCSP - URI:http://ocsp.verisign.com

            X509v3 Extended Key Usage:
                TLS Web Client Authentication, Code Signing
            X509v3 Subject Alternative Name:
                DirName:/CN=VeriSignMPKI-2-8
            X509v3 Subject Key Identifier:
                CF:99:A9:EA:7B:26:F4:4B:C9:8E:8F:D7:F0:05:26:EF:E3:D2:A7:9D
            X509v3 Authority Key Identifier:
                keyid:7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33

    Signature Algorithm: sha1WithRSAEncryption
         56:22:e6:34:a4:c4:61:cb:48:b9:01:ad:56:a8:64:0f:d9:8c:
         91:c4:bb:cc:0c:e5:ad:7a:a0:22:7f:df:47:38:4a:2d:6c:d1:
         7f:71:1a:7c:ec:70:a9:b1:f0:4f:e4:0f:0c:53:fa:15:5e:fe:
         74:98:49:24:85:81:26:1c:91:14:47:b0:4c:63:8c:bb:a1:34:
         d4:c6:45:e8:0d:85:26:73:03:d0:a9:8c:64:6d:dc:71:92:e6:
         45:05:60:15:59:51:39:fc:58:14:6b:fe:d4:a4:ed:79:6b:08:
         0c:41:72:e7:37:22:06:09:be:23:e9:3f:44:9a:1e:e9:61:9d:
         cc:b1:90:5c:fc:3d:d2:8d:ac:42:3d:65:36:d4:b4:3d:40:28:
         8f:9b:10:cf:23:26:cc:4b:20:cb:90:1f:5d:8c:4c:34:ca:3c:
         d8:e5:37:d6:6f:a5:20:bd:34:eb:26:d9:ae:0d:e7:c5:9a:f7:
         a1:b4:21:91:33:6f:86:e8:58:bb:25:7c:74:0e:58:fe:75:1b:
         63:3f:ce:31:7c:9b:8f:1b:96:9e:c5:53:76:84:5b:9c:ad:91:
         fa:ac:ed:93:ba:5d:c8:21:53:c2:82:53:63:af:12:0d:50:87:
         11:1b:3d:54:52:96:8a:2c:9c:3d:92:1a:08:9a:05:2e:c7:93:
         a5:48:91:d3
-----BEGIN CERTIFICATE-----
MIIGCjCCBPKgAwIBAgIQUgDlqiVW/BqG7ZbJ1EszxzANBgkqhkiG9w0BAQUFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMTAwMjA4MDAwMDAwWhcNMjAwMjA3MjM1OTU5WjCBtDEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg
aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDEuMCwGA1UEAxMlVmVy
aVNpZ24gQ2xhc3MgMyBDb2RlIFNpZ25pbmcgMjAxMCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPUjS16l14q7MunUV/fv5Mcmfq0ZmP6onX2U9jZr
ENd1gTB/BGh/yyt1Hs0dCIzfaZSnN6Oce4DgmeHuN01fzjsU7obU0PUnNbwlCzin
jGOdF6MIpauw+81qYoJM1SHaG9nx44Q7iipPhVuQAU/Jp3YQfycDfL6ufn3B3fkF
vBtInGnnwKQ8PEEAPt+W5cXklHHWVQHHACZKQDy1oSapDKdtgI6QJXvPvz8c6y+W
+uWHd8a1VrJ6O1QwUxvfYjT/HtH0WpMoheVMF05+W/2kk5l/383vpHXv7xX2R+f4
GXLYLjQaprSnTH69u08MPVfxMNamNo7WgHbXGS6lzX40LYkCAwEAAaOCAf4wggH6
MBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXAzBW
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsG
AQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwDgYDVR0PAQH/
BAQDAgEGMG0GCCsGAQUFBwEMBGEwX6FdoFswWTBXMFUWCWltYWdlL2dpZjAhMB8w
BwYFKw4DAhoEFI/l0xqGrI2Oa8PPgGrUSBgsexkuMCUWI2h0dHA6Ly9sb2dvLnZl
cmlzaWduLmNvbS92c2xvZ28uZ2lmMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9j
cmwudmVyaXNpZ24uY29tL3BjYTMtZzUuY3JsMDQGCCsGAQUFBwEBBCgwJjAkBggr
BgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDAzAoBgNVHREEITAfpB0wGzEZMBcGA1UEAxMQVmVyaVNp
Z25NUEtJLTItODAdBgNVHQ4EFgQUz5mp6nsm9EvJjo/X8AUm7+PSp50wHwYDVR0j
BBgwFoAUf9Nlp8Ld7LvwMAnzQzn6Aq8zMTMwDQYJKoZIhvcNAQEFBQADggEBAFYi
5jSkxGHLSLkBrVaoZA/ZjJHEu8wM5a16oCJ/30c4Si1s0X9xGnzscKmx8E/kDwxT
+hVe/nSYSSSFgSYckRRHsExjjLuhNNTGRegNhSZzA9CpjGRt3HGS5kUFYBVZUTn8
WBRr/tSk7XlrCAxBcuc3IgYJviPpP0SaHulhncyxkFz8PdKNrEI9ZTbUtD1AKI+b
EM8jJsxLIMuQH12MTDTKPNjlN9ZvpSC9NOsm2a4N58Wa96G0IZEzb4boWLslfHQO
WP51G2M/zjF8m48blp7FU3aEW5ytkfqs7ZO6XcghU8KCU2OvEg1QhxEbPVRSloos
nD2SGgiaBS7Hk6VIkdM=
-----END CERTIFICATE-----

2.root.verisign.cer

$ openssl x509 -in 2.root.verisign.cer -noout -fingerprint
SHA1 Fingerprint=4E:B6:D5:78:49:9B:1C:CF:5F:58:1E:AD:56:BE:3D:9B:67:44:A5:E5

$ openssl x509 -in 2.root.verisign.cer -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            18:da:d1:9e:26:7d:e8:bb:4a:21:58:cd:cc:6b:3b:4a
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
        Validity
            Not Before: Nov  8 00:00:00 2006 GMT
            Not After : Jul 16 23:59:59 2036 GMT
        Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:af:24:08:08:29:7a:35:9e:60:0c:aa:e7:4b:3b:
                    4e:dc:7c:bc:3c:45:1c:bb:2b:e0:fe:29:02:f9:57:
                    08:a3:64:85:15:27:f5:f1:ad:c8:31:89:5d:22:e8:
                    2a:aa:a6:42:b3:8f:f8:b9:55:b7:b1:b7:4b:b3:fe:
                    8f:7e:07:57:ec:ef:43:db:66:62:15:61:cf:60:0d:
                    a4:d8:de:f8:e0:c3:62:08:3d:54:13:eb:49:ca:59:
                    54:85:26:e5:2b:8f:1b:9f:eb:f5:a1:91:c2:33:49:
                    d8:43:63:6a:52:4b:d2:8f:e8:70:51:4d:d1:89:69:
                    7b:c7:70:f6:b3:dc:12:74:db:7b:5d:4b:56:d3:96:
                    bf:15:77:a1:b0:f4:a2:25:f2:af:1c:92:67:18:e5:
                    f4:06:04:ef:90:b9:e4:00:e4:dd:3a:b5:19:ff:02:
                    ba:f4:3c:ee:e0:8b:eb:37:8b:ec:f4:d7:ac:f2:f6:
                    f0:3d:af:dd:75:91:33:19:1d:1c:40:cb:74:24:19:
                    21:93:d9:14:fe:ac:2a:52:c7:8f:d5:04:49:e4:8d:
                    63:47:88:3c:69:83:cb:fe:47:bd:2b:7e:4f:c5:95:
                    ae:0e:9d:d4:d1:43:c0:67:73:e3:14:08:7e:e5:3f:
                    9f:73:b8:33:0a:cf:5d:3f:34:87:96:8a:ee:53:e8:
                    25:15
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            1.3.6.1.5.5.7.1.12:
                0_.].[0Y0W0U..image/gif0!0.0...+..............k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif
            X509v3 Subject Key Identifier:
                7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33
    Signature Algorithm: sha1WithRSAEncryption
         93:24:4a:30:5f:62:cf:d8:1a:98:2f:3d:ea:dc:99:2d:bd:77:
         f6:a5:79:22:38:ec:c4:a7:a0:78:12:ad:62:0e:45:70:64:c5:
         e7:97:66:2d:98:09:7e:5f:af:d6:cc:28:65:f2:01:aa:08:1a:
         47:de:f9:f9:7c:92:5a:08:69:20:0d:d9:3e:6d:6e:3c:0d:6e:
         d8:e6:06:91:40:18:b9:f8:c1:ed:df:db:41:aa:e0:96:20:c9:
         cd:64:15:38:81:c9:94:ee:a2:84:29:0b:13:6f:8e:db:0c:dd:
         25:02:db:a4:8b:19:44:d2:41:7a:05:69:4a:58:4f:60:ca:7e:
         82:6a:0b:02:aa:25:17:39:b5:db:7f:e7:84:65:2a:95:8a:bd:
         86:de:5e:81:16:83:2d:10:cc:de:fd:a8:82:2a:6d:28:1f:0d:
         0b:c4:e5:e7:1a:26:19:e1:f4:11:6f:10:b5:95:fc:e7:42:05:
         32:db:ce:9d:51:5e:28:b6:9e:85:d3:5b:ef:a5:7d:45:40:72:
         8e:b7:0e:6b:0e:06:fb:33:35:48:71:b8:9d:27:8b:c4:65:5f:
         0d:86:76:9c:44:7a:f6:95:5c:f6:5d:32:08:33:a4:54:b6:18:
         3f:68:5c:f2:42:4a:85:38:54:83:5f:d1:e8:2c:f2:ac:11:d6:
         a8:ed:63:6a
-----BEGIN CERTIFICATE-----
MIIE0zCCA7ugAwIBAgIQGNrRniZ96LtKIVjNzGs7SjANBgkqhkiG9w0BAQUFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMDYxMTA4MDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJpU2ln
biwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJp
U2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y
aXR5IC0gRzUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvJAgIKXo1
nmAMqudLO07cfLw8RRy7K+D+KQL5VwijZIUVJ/XxrcgxiV0i6CqqpkKzj/i5Vbex
t0uz/o9+B1fs70PbZmIVYc9gDaTY3vjgw2IIPVQT60nKWVSFJuUrjxuf6/WhkcIz
SdhDY2pSS9KP6HBRTdGJaXvHcPaz3BJ023tdS1bTlr8Vd6Gw9KIl8q8ckmcY5fQG
BO+QueQA5N06tRn/Arr0PO7gi+s3i+z016zy9vA9r911kTMZHRxAy3QkGSGT2RT+
rCpSx4/VBEnkjWNHiDxpg8v+R70rfk/Fla4OndTRQ8Bnc+MUCH7lP59zuDMKz10/
NIeWiu5T6CUVAgMBAAGjgbIwga8wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8E
BAMCAQYwbQYIKwYBBQUHAQwEYTBfoV2gWzBZMFcwVRYJaW1hZ2UvZ2lmMCEwHzAH
BgUrDgMCGgQUj+XTGoasjY5rw8+AatRIGCx7GS4wJRYjaHR0cDovL2xvZ28udmVy
aXNpZ24uY29tL3ZzbG9nby5naWYwHQYDVR0OBBYEFH/TZafC3ey78DAJ80M5+gKv
MzEzMA0GCSqGSIb3DQEBBQUAA4IBAQCTJEowX2LP2BqYLz3q3JktvXf2pXkiOOzE
p6B4Eq1iDkVwZMXnl2YtmAl+X6/WzChl8gGqCBpH3vn5fJJaCGkgDdk+bW48DW7Y
5gaRQBi5+MHt39tBquCWIMnNZBU4gcmU7qKEKQsTb47bDN0lAtukixlE0kF6BWlK
WE9gyn6CagsCqiUXObXbf+eEZSqVir2G3l6BFoMtEMze/aiCKm0oHw0LxOXnGiYZ
4fQRbxC1lfznQgUy286dUV4otp6F01vvpX1FQHKOtw5rDgb7MzVIcbidJ4vEZV8N
hnacRHr2lVz2XTIIM6RUthg/aFzyQkqFOFSDX9HoLPKsEdao7WNq
-----END CERTIFICATE-----


Could using a generated key from an online service be considered a risk? With some colleagues we're having a debate regarding the randomkeygen.com website.

I do think that there is a security risk using the generated keys of this (or any of this kind) website.

Why ? Here's my thoughts:

What prevents the owner of the website from storing generated password inside a database and releasing it as a dictionary attack?

I do know that generated password combinations are not infinite, but what if with this dictionary hackers try a password they know that has been generated (so more likely to be used)

We can even think of a heatmap used for Analystics to know which kind of generated passwords are used to narrow the scope of possibly used passwords (or even a Javascript that sends the password to the database once it has been copied into the clipboard, but that is a little too obvious for my demonstration).

PS: I do not work in security so I do feel sorry if I say wrong things. I know that my theory is not a big "security breach" but if we see it only in a statistic way, there's more chance if we reduce the number of possible password.

So, could using a generated key from an online service be considered a risk?

Nothing prevents him from storing the password
Yes it is a risk, because you do not know what is happening with the assigned key on the backend of the website

Writing a proper keygen isn't hard, there are many examples on how to write a simple script that does this for you. It's important however that you use the correct amount of entropy for the randomness of the generated key. Please refer to the Bear's answer here.


How secure is the SRP that Blizzard uses to protect passwords? Blizzard very recently announced that their network was compromised, but they assure users in their statement that the password information that the attackers had access to was saved in a secure way:

  We also know that cryptographically scrambled versions of Battle.net
  passwords (not actual passwords) for players on North American servers
  were taken. We use Secure Remote Password protocol (SRP) to protect
  these passwords, which is designed to make it extremely difficult to
  extract the actual password, and also means that each password would
  have to be deciphered individually.

I looked up SRP, and it seems to be a method of exchanging passwords securely. I'm familiar with using hashes to store passwords, but I couldn't find out how the SRP Blizzard uses compares to other common methods of hashing passwords like PKBDF2, bcrypt or scrypt?

How hard would it be to bruteforce (or use a dictionary attack) against passwords protected by SRP?

SRP is designed to protect the transmission of the password against brute-force attacks, even in case the password could be easily bruteforced.

However, if some Blizzard authentication server was compromised, the relevant attack vectors are different. Apart from the storage-scheme, the adversary can also listen in to ongoing transactions and, in parallel, store the temporary DH secrets generated by the SRP servers. The latter attack is a bit complicated and requires extensive preparation by the attackers, however, it would surely leak any logins used to authenticate to the compromised system.

The more traditional attack vector is the verification values. In SRP, the verifier values on the server side are not traditional hashes but results of an exponentiation, like in Diffie-Hellmann.

To my knowledge there is no detailed analysis of SRP vs. PBKDF2 or bcrypt. Somewhere on the SRP site (srp.stanford.edu) I once saw a note that people implemented a bruteforcer and found the required bruteforcing effort to be similar to traditional bruteforcing of hashes.

This is kind of expected: It is known that such exponentiations are hard to invert, just like a hash function. Assuming Blizzard implemented a standardized protocol like RFC2945 and did not try to invent the details on their own, these verification values will also contain a salt to make rainbow-tables impractical.

The main difference then is in the effort of bruteforcing individual verification values. Here, systems like bcrypt/PBKDF2 employ a scaling factor to increase the computational effort per password guess. The SRP schemes I know do not explicitly support this. Exponentiation is typically a bit more costly to compute than a hash, but this depends on the group (modulus) in which you're operating. I think increasing the modulus of the verification value in SRP is easily possible, but it will also increase the computation effort for 2 other exponentiations per peer that have to be done in every protocol run.

Update: Looking at RFC2945 once more, the password and salt is first hashed and then exponentiated. It would be easy to use PBKDF2 here instead of just hashing to implement a scaling factor for the bruteforcing effort without much impacting the rest of the protocol. Additionally, even when a small/unsuitable exponent N was chosen, the scheme is still as secure as a simple challenge-response-based pw-authentication.

Overall, Blizzard is probably a bit lucky as their kind of pw-storage is very uncommon and appropriate bruteforcers are not commonly available. However, for a determined attacker the SRP way of storing secrets is no more secure (possibly slightly less secure) than the state-of-the-art approach with a decent anti-bruteforce scaling factor. That being said, I applaud Blizzard for using some state-of-the-art crypto for their password-authentication, since online-bruteforcing is typically much more problematic.


fail2ban and iptables Should fail2ban be the master of iptables rules? For example, should I setup my firewall rules along side the fail2ban rules, or should I have all my services configured and managed by fail2ban?

Regards

fail2ban is not a firewall rule manager. Fail2ban is a piece of software that monitors log files for "failed" attempts to login to a device. If it see too many failed attempts, it will then "ban" the source by adding their IP address to firewall rules to prevent future connections.


Could a hardware keylogger be detected through measuring USB micro voltage? All in all, hardware keyloggers are harder to detect.

But if computers can measure the exact voltage consumption of their peripherals, could a hardware keylogger be detected by comparing the normal power consumption of the keyboard with the slightly higher consumption of the keyboard with a keylogger attached?

In theory, it's possible, but is very, very hard:

USB is, by definition, a serial bus. So you can have more than one device on a single USB bus. This defeats any measurement.
Monitoring minute changes on power consumption on a bus is not easily done, and it's easier to just open up the keyboard and search for a keylogger.


What audit procedures are applied to ENotaries and to the software they use? From a theoretical standpoint, the very notion of an electronic notary - ENotary implies a host of problems related to biometrics, signature revocation, timestamping, keeping a reliable electronic journal of notarial acts etc. While it is instructive to learn about those (there are some  - but not all - answers in the Model Notary Act of 2010 ), my question is simpler: what are the procedures applied to audit compliance of ENotaries and how do they compare to the ones used in other industries (say, PCI DSS etc.)?

Clarification #1: yes, I know there are few lawyers here... no need to prefix your answers with the five-letter abbreviation.

Clarification #2: answers don't have to be US-centric.

In some countries, there is a specific legal framework for such things; of course, every country has its own... In France, it is the Référentiel Général de Sécurité, which feeds on Common Criteria. The gist of the thing: the relevant administrative organization (the ANSSI) publishes a Target of Evaluation which describes all the features that a given service should have. This covers things like the precision of the clock of the time stamp authority, the process used to control physical access to servers, the background checks of the criminal and debt records of people who have developed the code, the compliance to relevant standards, and so on.

An organization who wishes to get its system "certified" then hires an independent audit firm, which verifies that the system complies with the rules in the ToE. It then talks to the ANSSI, which does a few verifications itself (in particular that the audit firm is indeed independent and trustworthy), then finally grants a formal recognition of the system as being compliant. This links to a set of local laws which more or less mean that when a certified notary system is used, the notarized documents are presumed valid, and if someone wants to contest their validity, then he has to bring proof elements (i.e. the burden of proof is on who contests rather than on who asserts).

It takes several months, a substantial amount of money (dozens of thousands of dollars), and a terrifying lot of paperwork.


Is there any use in an AIA Extension in a Certificate directly issued by a Root CA? While most documentation I've read states that there is no requirement to have the AIA extension in a self-signed Root certificate (logical enough), I can't find anything that tells me not to do so in the certificates issued by the Root.  In fact, most examples I've found has the Root CA issuing certificates with an AIA extension pointing back to the Root CA.

RFC 5280 gives two possible options for AIA:

the URL of the issuing CA's certificate.
the URL of the OCSP responder.

For now, I'm ignoring OCSP, and assuming we have at least one subordinate CA.

What would be the point of having a id-ad-caIssuers entry in the AIA extension within a certificate issued by the Root CA?  If a subordinate needs to check this to find the path to the Root CA then it implies that the subordinate doesn't know about the Root CA's certificate and therefore doesn't have it in it's collection of Trust Anchors. A URL to the Root CA isn't going to change matters - it still won't trust it!

Am I correct or have I missed some point?  If the latter, is there a situation where this AIA extension would be needed in a certificate issued by the Root CA?

Well, theoretically, you would never need to need the AIA.

RFC 5280 mandates, that you send along each necessary certificate. And optionally, you may send along the Root CA cert as well.

And that's the only certificate that is optional.

Now not everybody configures their servers correctly. And this is where AIA comes in.

If only the end entity certificate is sent along, then the client software will have more work to do. And some client software can do a thing called AIA chasing.

It will look inside the certificates it has and use AIA to download additional certificates. And if this doesn't lead to a usable path within 10 tries or something, then path building fails.

And building a path means: finding the certificates that lead to a trusted root CA.

If it leads to an untrusted root CA, then you can't trust the leaf certificate either. Either way, you will arrive at a decision about that leaf certificate. And that's what you want.

Related: InfoSec-SE: Steps to find out whether a SSL certificate is trustworthy

Edit 2015-04-28: AIA presents a root. You decide on trust.
What AIA chasing can help you with is to find one (or many) root CA. What it does not do is help you decide whether this CA is worth your trust.

But it will get you a root CA.

And even if it gets you a root CA that you don't trust, then it's still helpful, because then you know that the answer is "I'm not going to trust that". And then you don't have to keep on looking for an answer.

Further reading

RFC 4158 - Internet X.509 Public Key Infrastructure: Certification Path Building.
Whitepaper that discusses the, then new, AIA extention back in 2002: Steve Lloyd, Oasis PKI Forum, Understanding Certification Path Construction,


A solution for the absence of Certifying Subkeys in OpenPGP Certs As discussed in this answer, gpg does not offer the capacity for subkeys to certify (eg. "sign") other keys, though there may be good reason why it should, and they do sign at least one key.  As a practical matter, for those of use who keep our master secret key, in which resides the certifying capacity, offline, this is both a headache when trying to sign other peoples' keys, as well as a security risk.  As a result, I would like to "cons up" a certificate that effectively has a certifying subkey.  My idea is like this:
On my offline machine I generate:

Master key0 (C=certifying) - does not expire
Subkeys (E, S & A = Encrypting, Signing, Authenticating) - expires

Master key1 (C) - expires
No Subkeys

Now I do cross-signing, as discussed here:
key0 signs key1.
key1 signs key0.
I remove the key0 private key and keep it offline.
I take to my daily driver:

Master key0 (.public) + Subkeys (.public & .private) + key1 signature
Master key1 (.public & .private) + key0 signature

key1 is effectively my subkey with certifying authority.
My question is, have I missed anything here?  Besides cross-signing, is there any structure to an OpenPGP Certificate that I have failed to include, and which might be a security vulnerability?
Also, if someone were to sign my key, would it not be sufficient for them to sign the certificate containing key0?  Since I've cross signed with key1, trust of key0 should automatically mean trust of key1.

While I am still looking for an answer here, I have found some clarity on how cross signatures should be done.  I've given a full answer here, but basically, using --default-cert-level 3 would be sufficient.  It would also be necessary to attend to the trust model, which is described at that link.


Exclude passwords with repeating letters It would cut down a lot of time of the brute force attack if some of those passwords like "aaaaaa" wouldn't appear. How can this be achieved in Hydra or some other brute force software?

I think it's fair to say that 5 truly random letters are going to be less likely than 5 repeated letters, even if "aaaaa", isn't practical to type...the people who make these passwords have avoided much practical thinking.


How to source training data in ML for information security? A company entrusts a Data Scientist with the mission of processing and valuing data for the research or treatment of events related to traces of computer attacks. I was wondering how would he get the train data.
I guess he would need to exploit the logs of the different devices of the clients and use statistical, Machine Learning and visualization techniques in order to bring a better understanding of the attacks in progress and to identify the weak signals of attacks... But how would he get labelled data?
He might get the logs of attacks received before, but that might not have the same signature with the attacks that are going to come later? So it might be difficult to create a reliable product?

The domain problems in cybersecurity are too-narrow to willy nilly try to apply AIML or DL to.
Not saying to throw data science out the window. Saying you need way more domain expertise to make it go.
One excellent application of data science to the cybersecurity field is to understand the indicators, or IOCs, and how they are sighted (last seen, etc) in memory, on disks, and in network traffic (and positioned where in the network traffic relative to the sources, destinations, and passthroughs -- just like any dataflow). Instead of levering ML or DL, I would instead suggest to focus first on graph algorithms. Understand the relationships of these indicators and their interpretation as time series data

A File "Hash" (e.g., a SHA256 checksum of a file or a section of memory or network traffic of a process). Here is an example of the domain problems associated with cybersecurity. The way the our signatures (e.g., Yara rules) work on-disk vs. in-memory vs. in network traffic are obviously different code and data, and code and data paths. Parameters or arguments to processes also matter especially for script code
an IPv4, IPv6 address or path, and its associated network attributes such as BGP-4 ASN if registered with a Regional Internet Registry (RIR). There is often a history associated with these objects and narrowing into them may require understanding complex RWhois and SWIP registration processes
an FQDN, or Fully-Qualified Domain Name -- sometimes hostname and with Windows Server Forest/Domain bits, perhaps older namestays such as NetBIOS or MS-RPC Named Pipes. Cloud stacks such as Azure AD are changing this nomenclature as well, moving to tenants, subscriptions, resources, et al. A set of Whois records identifying each unique Internet Domain Name can come with its own set of relationships including a rich history of timestamps, owners, name servers, and email addresses
A credential, often an email address, e.g., bertrand.russell@math.onmicrosoft.com but also a cred user/pass pair, i.e., bertrand:MathIsK00lB00ksRul3 if known (often if compromised)

As a hint of what would be possible, check out the work here -- https://threathunterplaybook.com/introduction.html -- which pivots nicely off of the fields (and parsing languages) from Azure Sentinel and M365/Azure data models


Json Web Tokens. Headers naming conventions, formatting and security issues I implemented my own Json Web Tokens authentication and authorization scheme, which is based on three tokens - access token, reference token and refresh token. They are generated by backend or application code and all authorization logic is implemented in middleware (in Lua code embedded in nginx).

These are some questions that are bothering me:

Should I sign my reference token with RSA before I pass it to the client?
Should I sign my refresh token with RSA? Obviously, like reference token, it does not store any critical information and therefore I'm not sure of that.
Should I sign my access token with RSA, if it is never passed to the client and is only used on server side? I guess, I should, just like in case of hashed passwords stored in database.
What are naming conventions for HTTP header in which I pass my reference token from server to the client? Is it ok to use just some arbitrary header like X-Reference-Token?
In what header should I pass reference token from client to the server side? Should I use Authorization: Bearer ... (it seems like a standard convention) or is it ok to use just the same X-Reference-Token: ...
Is it secure (I guess, not) to pass refresh token to the client. And if not, how do they store it? Reference token is stored in client side cookies and passed with each request from client to the server, access token is never passed to the client and is stored in server side cache and where should I store my refresh token?
Is it secure to use raw reference token value as a key, by which I get access token from server side cache? Let's say, my reference token is just some GUID, is it secure enough to use this very GUID as a key by which my access token is stored? Or is it more secure to get this key from GUID by some transformations?

There are a lot of unknowns here but here is my shot at answering based on general security best practices.

  Should I sign my reference token with RSA before I pass it to the
  client?

Signatures can be used for authenticity, integrity, and non-repudiation. In this case, integrity is the only one which seems to make sense. If this is required, you should definitely sign the token. It is required, if the token is self-describing, i.e. contains data which may be manipulated by the client (like a JWT). I wrote blog post on integrity. RSA may not be required. A simple HMAC may be enough for you. Your use case really determines if you need asymmetric crypto here.

  Should I sign my refresh token with RSA? Obviously, like reference
  token, it does not store any critical information and therefore I'm
  not sure of that.

See 1. Since you do not pass it to the client and it seems to be an opaque token. You can get away with not signing this.

  Should I sign my access token with RSA, if it is never passed to the client and is only used on server side? I guess, I should, just
  like in case of hashed passwords stored in database.

See 1. Not passing it to the client, make it impossible to be modified by the client. Integrity may still be required, it depends on your use case.

  What are naming conventions for HTTP header in which I pass my reference token from server to the client? Is it ok to use just some
  arbitrary header like X-Reference-Token?

Yes, it is fine. Since the scheme is custom, I do not think there is harm in using a custom header for a custom piece of token.

  In what header should I pass reference token from client to the server side? Should I use Authorization: Bearer ... (it seems like a
  standard convention) or is it ok to use just the same
  X-Reference-Token: ...

Authorization: Bearer is probably better here. However it seems in 6. that your are using cookies for the reference token, in which case there is no need for an extra header to send it.

  Is it secure (I guess, not) to pass refresh token to the client. And
  if not, how do they store it? Reference token is stored in client side
  cookies and passed with each request from client to the server, access
  token is never passed to the client and is stored in server side cache
  and where should I store my refresh token?

Your scheme is a black-box to me, but it seems like the access token never hits the client, therefore the refresh token should not either. In a regular auth mechanism like OAuth these two tokens require the same amount of security. Not counting the fact that refresh tokens live longer.

  Is it secure to use raw reference token value as a key, by which I get
  access token from server side cache? Let's say, my reference token is
  just some GUID, is it secure enough to use this very GUID as a key by
  which my access token is stored? Or is it more secure to get this key
  from GUID by some transformations?

Again your scheme is a black-box. It seems to me that your reference token is actually a session ID. In which case it should not be a GUID, but a random opaque token, as described here. It is fine to store the session ID as the key to get the access token from your cache.

Anything I described above is based on my very limited understanding of your scheme. Generally, you should not run your own authentication/authorization scheme. It seems to me you have a web application with session management using cookies and an OAuth to access some resources on the backend.

Take a look at OAuth, it may well simplify your life quite a bit.


Are there any working proof-of-concept string comparison timing attacks? I've tried to reproduce a string comparison timing oracle in two languages (Java and Python), but I'm not seeing any correlation in the timing based on the input into the comparison.  Are there any examples out there, or do you see an issue with my code?  Note that I would like something simple, like the example I have given.  An attack on a large program "in the wild" is not a good example.

I've also not been able to find any simple and ready-to-run examples of timing attacks.  I believe I've disabled Java's optimization with -Djava.compiler=NONE.  It's taking a significant amount of time to run the code, so it's clearly not completely optimizing the code.

It seems odd that this is frequently talked about, but there are no actual easily-found examples out there.

Here is my Java code as it stands today.  The output varies a bit randomly with no apparently correlation that I have identified.  I've added some notes to the output so you can see which should be slower comparisons.

public class TimingAttackJavaTest {
    public static void main(String[] args) {
        TimeCompare("a0", "b0", "a, b      ");
        TimeCompare("aaaaaaaaaa1", "bbbbbbbbbbb1", "a*10, b*10");
        TimeCompare("aaaaaaaaaa10", "bbbbbbbbbbb10", "a*10, b*10");
        TimeCompare("aaaaaaaaaa2", "b2", "a*10, b  ");
        TimeCompare("a3", "bbbbbbbbbbb3", "a, b*10  ");
        TimeCompare("aaaaaaaaaa4", "bbbbbbbbbbb4", "a*10, b*10  ");
        TimeCompare("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa1", "a*100, a*100");
        TimeCompare("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa1", "a*100, a*100");
        TimeCompare("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa2", "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb", "a*100, b*100");
        TimeCompare("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa2", "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb", "a*100, b*100");

        TimeCompare("a", "a", "a, a      ");
        TimeCompare("aaaaaaaaaaa", "aaaaaaaaaaa", "a*1, a*10 ");
        TimeCompare("1aaaaaaaaaa10", "2bbbbbbbbbbb10", "a*10, b*10");
    }

    static void TimeCompare(String a, String b, String outputLabel)
    {
        boolean temp = false;
        long startTime;
        long endTime;
        long duration;

        startTime = System.nanoTime();
        for(int i = 0; i < 10000000; i++)
        {
            temp = a.equals(b);
        }
        endTime = System.nanoTime();
        duration = endTime - startTime;
        System.out.println(outputLabel + temp + "\t\t" + duration);

    }
}

Output (note that the first comparison is always slow, as the program gets started):

a, b      false     930418800
a*10, b*10false     513034800
a*10, b*10false     510905300
a*10, b  false      534267200
a, b*10  false      524720700
a*10, b*10  false       509250100
a*100, a*100false       516159000    **This should return slowly**
a*100, a*100false       508714700    **This should return slowly**
a*100, b*100false       511160700    **This should return quickly**
a*100, b*100false       522029800    **This should return quickly**
a, a      true      278492700
a*1, a*10 true      284238900
a*10, b*10false     506245000

Your example isn't working for several reasons, chief of which is the fact that you're using the best possible case data (i.e. least likely to display differences). If the difference in the strings was at the start, the early-out comparison should alert you. However, since you're using a JIT language, there are all sorts of weird possibilities that might hinder such a check.

The best way to demonstrate this type of attack is not with loops, but with a single measurement in a low-level language such as C.

Here's a quick example that works very well:

#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <time.h>
using namespace std;

// this is just strcmp() wrapped in timer calls
bool CheckEqual(char* a, char* b, bool show)
{
    int i, r, trv;
    long time_pre, time_post;
    struct timespec ts;

    if((trv = clock_gettime(CLOCK_MONOTONIC,&ts)) != 0) {
        printf("Timing error, pre. Code = %d\n", trv);
    }
    time_pre = ts.tv_nsec + (ts.tv_sec * 1000000000L);

    r = strcmp(a, b);

    if((trv = clock_gettime(CLOCK_MONOTONIC,&ts)) != 0) {
        printf("Timing error, post. Code = %d\n", trv);
    }
    time_post = ts.tv_nsec + (ts.tv_sec * 1000000000L);

    if (show)
        printf("Time: %ld\n", time_post - time_pre);
    else
        printf("First compare done.\n");

    return r == 0;
}

// this function helps us avoid the problem of the compiler being too smart.
// if we were to use string literals that were equal, it'd optimise compile-time
// constant strings into a single instance, so strcmp() would just early-out on
// the fact that the two pointers were equal, which is not what we want to
// demonstrate here - in reality we'd be comparing buffers that aren't static.
char* MakeStr(char c, int n)
{
    int i;
    char* s = (char*)calloc(n+1, sizeof(c));
    for(i=0; i<n; i++)
        s[i] = c;
    return s;
}

int main()
{
    // equal apart from last
    char* aa = MakeStr('0', 64);
    char* ab = "0000000000000000000000000000000000000000000000000000000000000001";

    // equal apart from first
    char* ba = MakeStr('0', 64);
    char* bb = "1000000000000000000000000000000000000000000000000000000000000000";

    // inequality in the middle
    char* ca = "0000000000000000000000000000010000000000000000000000000000000000";
    char* cb = "0000000000000000000000000000001000000000000000000000000000000000";

    // equal
    char* da = MakeStr('0', 64);
    char* db = MakeStr('0', 64);

    // first call to strcmp() and time functions will result in cache misses
    // so we call it once and don't display output to account for that.
    CheckEqual(aa, ab, false);

    printf("Equal but last, ");
    CheckEqual(aa, ab, true);
    printf("Equal but first, ");
    CheckEqual(ba, bb, true);
    printf("Equal but mid, ");
    CheckEqual(ca, cb, true);
    printf("Completely equal, ");
    CheckEqual(da, db, true);

    free(aa); free(ba); free(da); free(db);
    return 0;
}

Your output should look something like this:

First compare done.
Equal but last, Time: 345
Equal but first, Time: 229
Equal but mid, Time: 234
Completely equal, Time: 270

Notice the large difference between the first two? This is due to early-out optimisation, whereby the comparison exits as soon as it finds a difference. In the second comparison, it takes less time because the first character comparison shows it's not equal, so it can return early. In the third comparison, we see that this goes a little further into the string, resulting in a slightly longer runtime than the "equal but first", but shorter runtime than the "equal but last".

The completely equal one is an interesting beast. I'm guessing that, when the last character is not equal, there is some additional required logic. In comparison, the completely equal one takes less time, I assume because it just has to return 0.


Can still ping from secure network? I have a standard network and wanted to make a more secure one so I bought a second router and set it up as a separate network daisy chained so it can get internet.

I managed to make the setup, with one network having addresses from 192.168.1.60 - 192.168.1.253 (router was 192.168.1.254. The second router had addresses from 192.168.0.1 - 192.168.0.50 (router was 192.168.0.1). Subnet mask is class C 255.255.255.0.

However I found with this setup, I could still ping devices from the x.x.0.1 network to the x.x.1.1 network. Does this represent a security issue as I thought the two networks are separate and so should not be able to ping each other?

Does this represent a security issue as I thought the two networks are separate and so should not be able to ping each other?

Whether or not it is a security issue is up to you, but the router is behaving normally.

Because the router is directly connected to both networks, it understands how to send traffic between them. To avoid this, you can implement ACLs (firewall rules) or separate the traffic into vlans.

It should be noted that testing connectivity with ping is only testing the ability of ICMP packets to traverse the network. Your firewall rules can be set to block ICMP packets, so pings will fail, but there will still be connectivity. In order to truly segregate the networks you would need a deny all from one network to the other, or split the networks into two vlans and only allow each vlan to access to itself.


SSL Based Denial of Services due to Message Digest On a very high level, its known that SSL/TLS uses message digests to verify the integrity of the messages sent.
However, the question I have in mind is :
How does SSL ensure a DoS does not happen based on integrity verification ?

Consider this scenario where a handshake is taking place between a server and a client. These are all network packets that ARE going through the network as un-intelligble data. If there are message digests for every record, what would happen if an attacker kept changing one bit of every packet that passes through him (this is definitely possible right? )? Wouldn't that effectively lead to a DoS since the integrity check has failed, which would lead to the communication being stopped ?

Yes, this is possible. When the digest comes back as incorrect, the SSL implementation should drop the connection.

However, the attacker would need to be in a man-in-the-middle position, so he could equally just drop all traffic, or send TCP FIN / RST packets to close the connection itself.


Does https prevent man in the middle attacks by proxy server? There is a desktop client A connecting to website W in a https connection

A --> W

Somehow between A and W, there is a proxy G.

A --> G --> W

In this case, will G be able to get the certificate which A
previously got from W?
If G can get the certificate, does that mean that G will be able to decrypt the data?

How does HTTPS work?

HTTPS is based on public/private-key cryptography. This basically means that there is a key pair: The public key is used for encryption and the secret private key is required for decryption.

A certificate is basically a public key with a label identifying the owner.

So when your browser connects to an HTTPS server, the server will answer with its certificate. The browser checks if the certificate is valid:

the owner information need to match the server name that the user requested.
the certificate needs to be signed by a trusted certification authority.

If one of these conditions is not met, the user is informed about the problem.

After the verification, the browser extracts the public key and uses it to encrypt some information before sending it to the server. The server can decrypt it because the server has the matching private key.

How does HTTPS prevent man in the middle attacks?

  In this case, will G be able to get the certificate which A previously got from W?

Yes, the certificate is the public key with the label. The webserver will send it to anyone who connects to it.

  If G can get the certificate, does that mean that G will be able to decrypt the data?

No. The certificate contains the public key of the webserver. The malicious proxy is not in the possession of the matching private key. So if the proxy forwards the real certificate to the client, it cannot decrypt information the client sends to the webserver.

The proxy server may try to forge the certificate and provide his own public key instead. This will, however, destroy the signature of the certification authorities. The browser will warn about the invalid certificate.

Is there a way a proxy server can read HTTPS?

If the administrator of your computer cooperates, it is possible for a proxy server to sniff https connections. This is used in some companies in order to scan for viruses and to enforce guidelines of acceptable use.

A local certification authority is setup and the administrator tells your browser that this CA is trustworthy. The proxy server uses this CA to sign his forged certificates.

Oh and of course, user tend to click security warnings away.


Where do my keys come from for requests over SSL? From what I understand, when you send information to a website over SSL, you encrypt the information you send with their public key.

However, if you want to be able to decrypt the information they reply with, you are going to need a private/public key combination yourself. I don't ever recall having been prompted for an RSA key by my browser, or been required to generate one; where does this key come from?

If your browser creates one for you, is it generated once and then stored on your computer forever, or is a new key generated for every session or site?

During the TLS handshake the client will use the public key of the server, which it was passed following the ServerHello message, to encrypt a pre-master secret. It is not the entire session key. In the ClientHello message and ServerHello message the two parties swap random values.
The server and the client now use the pre-master secret and the random values to generate the same master secret, which can be used as a session key.

The server's public key is used because in asymmetric cryptography the only person who will be able to decrypt the message will be the holder of the private key.

Check out the wikipedia page for more details on the TLS handshake.


Website is behaving strangely - was it attacked? Our website was behaving strangely.

Sometime it was down and nothing was accessible.
Sometime it started loading but pages browsing was too slow.

We checked apache logs and found the below suspicious entries:

[Fri Dec 28 00:47:47 2018] [error] [client 212.237.1.209] File does not exist: /usr/share/phpMyAdmin/css
[Fri Dec 28 00:47:47 2018] [error] [client 212.237.1.209] script '/usr/share/phpMyAdmin/config.user.inc.php' not found or unable to stat
[Fri Dec 28 00:47:47 2018] [error] [client 212.237.1.209] script '/usr/share/phpMyAdmin/config_inf.php' not found or unable to stat
[Fri Dec 28 00:47:47 2018] [error] [client 212.237.1.209] File does not exist: /usr/share/phpMyAdmin/4.2
[Fri Dec 28 00:47:48 2018] [error] [client 212.237.1.209] File does not exist: /usr/share/phpMyAdmin/scripts
[Fri Dec 28 00:47:48 2018] [error] [client 212.237.1.209] File does not exist: /usr/share/phpMyAdmin/config
[Fri Dec 28 00:47:48 2018] [error] [client 212.237.1.209] File does not exist: /usr/share/phpMyAdmin/scripts
[Fri Dec 28 00:47:48 2018] [error] [client 212.237.1.209] File does not exist: /usr/share/phpMyAdmin/config
[Fri Dec 28 01:03:28 2018] [error] [client 115.159.111.47] File does not exist: /usr/share/phpMyAdmin/scripts
[Fri Dec 28 01:03:28 2018] [error] [client 115.159.111.47] File does not exist: /usr/share/phpMyAdmin/scripts
[Fri Dec 28 01:03:28 2018] [error] [client 115.159.111.47] File does not exist: /usr/share/phpMyAdmin/scripts
[Fri Dec 28 01:03:28 2018] [error] [client 115.159.111.47] File does not exist: /usr/share/phpMyAdmin/scripts

Our quick backup response was to block these IP-addresses

Moreover we also found the below entries in logs:

[Mon Dec 24 07:17:26 2018] [error] [client 91.121.134.18] Empty module and/or action after parsing the URL "/api/ip.php" (/).

Detail about above log entry: https://www.abuseipdb.com/check/91.121.134.18?page=2#report. We also blocked these IP-addresses

I want to know what was going on? Was it a DDOS attack or something else? For now I have blocked the suspicious IPs.

However what is the permanent solutions/tricks to limit/end these type of attacks?

My own apache logs are stored in:

/var/log/apache2/*.log

Typically each virtual host has its own access log, such as:

/var/log/apache2/vhost1_access.log
/var/log/apache2/vhost2_access.log

The entries are very similar to many entries in my own log files.  The IP addresses listed in your question each have been tagged by other web servers, probably automatically by programs such as fail2ban.  At least one IP address was tagged as using zmeu scanner.

Most these types of log entries indicate what I would describe as the low to medium hum of the open Internet; meaning automated bots looking for low hanging fruit in all corners of the IPv4 address space.

If your particular corner of the Internet is chosen by several scanners simultaneously, your small low-traffic server may experience some heavier than normal load.

Generally, I check:

The last command in order to make sure that I recognize all entries.
The lastb command in order to check how many username/password combinations have been attempted for the day.


what is the role of RADiUS server and Active Directory to increase the security in wireless networks? In the CBT Nuggets Video Training, one slide about Wireless networks :

i want to know about the role of Radius to increase the security and how? in this project:  Deploy Active Directory and IAS/RADIUS for wireless network authentication and authorization

How RADIUS Solve Enterprise Wireless Connectivity Issues, in wireless networks beside Active Directory. Did  Hidden wireless networks (that not broadcast their Network ID -SSID) + WPA secure enough our network?

No, because the accountability is too low and chances are high your WPA2 password would leak out. When using RADIUS all users have their own password and usernames to authenticate to the AP.

Chances of users sharing the WPA2 password to the wifi network is larger than them sharing their own personal username and passwords. This increases security in two ways:

not everyone will leak passwords
If you want you can track your users and see who's done what

The last part is not possible when using WPA2 with a shared password between  the users.