Can someone please confirm one of these explanations of the DNSSEC chain of trust? Let me apologize in advance for this question has been answered. I did have a good look and if it is here somewhere I missed it. My question hopes to clarify exactly what happens when a validating resolver queries a DNSSEC aware nameserver for a RR. I thought I understood the process, then I read an explanation written by someone I would think can speak authoritatively (no pun intended) on the subject. I think the easiest way for me to do this is to explain what I thought the process looked like and then the contrasting version. And hopefully, someone among you all will be able to clarify where I might be going wrong.
Example A (or how I thought a DNSSEC query worked):

Host A sends a query to it's  recursive caching DNS server for www.example.com
The recursive server sends an iterative query to a DNS server that is authoritative for the root zone
The root DNS server can't answer the query directly so it responds with:

A plain text referral for the authoritative name servers for the  com zone

RRset of DNSKey records for the root zone (the root zone's PubKSK and PubZSK)
RRSig of the above DNSKey RRSet signed with the root zone's PvtKSK

DS record for the com zone (hash of the com zone's PubKSK)
RRSig of the above DS record (signed using the root zone's PvtZSK)

The recursive caching server hold's a copy of the Root zone's PubKSK so it verifies the above files as follows:

The RRSig containing Root zone's DNSkey record is decrypted using the Root zone PubKSK (already held)
The hash of the Root PubKSK from the RRSig is compared to a hash of the Root PubKSK already held by the recursive server, to verify the authenticity of the key.

If the hashes match the key is trusted and therefore the Root PubZSK is also trusted and can be used to decrypt the RRSig of the DS record for the com zone

Once decrypted the hash of the come zone's PubKSK is compared to that in the DS record to verify that the com PubKSK can be trusted.

This has been my understanding of how the trust chain works. Now that the recursive server holds the com zone PubKSK the process is repeated, down to the example nameservers that respond with the IP for the webserver for that domain.

Example B:

I recently read Josh Reed's explanation of a query in para. 1.5 'How Does DNSSEC Change DNS LOOKUP?' on users.isc.org and he explains it almost in reverse.

In his explanation:

Host A queries it's recursive resolver for info on the web server www.isc.org

The recursive server's requests on behalf of Host A will be answered by the name-servers responsible for isc.org and contain the records required by DNSSEC.

Validation now begins when the recursive resolver asks the isc.org name-server for the keys for it's zone. Once those keys are provided then the recursive server then queries up (the parent) to validate responses in reverse fashion to Example A, until a trusted key (presumably or typically from the root) confirms that the chain can be trusted.

The question:

Can I trouble someone with a better understanding to confirm that my understanding (as explained in Example A) is incorrect? I don't doubt Josh Reed but the second example seems to be less efficient.

Both explanations are correct, they are just summaries of what happens, so obviously the devil is in the details. Including what shortcuts are used for efficiency, the state of the cache, if QNAME minimization is into play, etc.

But you do not need to think about theories, you can observe in real life.

Use the delv  application. It is described as such:

  delv is a tool for sending DNS queries and validating the results, using the same internal resolver and validator logic as named.

So using it show exactly what a (bind) recursive nameserver does, both about records fetching and then DNSSEC validation.

Let us try with: delv +rtrace +vtrace www.icann.org

After some time you get the final results at the end of the output:

; fully validated
www.icann.org.      0   IN  CNAME   www.vip.icann.org.
www.icann.org.      0   IN  RRSIG   CNAME 7 3 3600 20191117090520 20191027015903 8150 icann.org. mmVZ3tzEr1rRDXIVF4TiqcnAwyNzA6kV+FXq1/8CSeZfVUa1260NfIxQ TzaV05NHSvW7CqeBXskzmPjCkSAGpF2breelu+k1Qd9CfJ7/+gp38mFO zTddZdZDL+ddU5rlaeaF17OokcPUnBtR23buBmWZ/mK83heXSKrWHfKn lNQ=
www.vip.icann.org.  30  IN  A   192.0.32.7
www.vip.icann.org.  30  IN  RRSIG   A 7 4 30 20191107231353 20191031231353 52760 vip.icann.org. jtvLS1ylxThi0xlObrrDA4nSM5GbpKeBvhcKlRn3em103AIxGAMu7o24 5uzhGQVZn4AsEH62/2JfWYQVavOnsb4rI8+rl5iw/XmUkoy7neBNybB6 kjrfcaUbCNhjgoipGotlUolqlNjKKzkMHbGLdUCMOzdlacfuK1gz825c PuA=
www.vip.icann.org.  30  IN  RRSIG   A 7 4 30 20191109071334 20191102071334 14702 vip.icann.org. LxEa+CV0bIB9I2s8v9MaK9JXoOEghUiYSotxACrxq2TxclX/6HPWBX+l SF5Y6iQ5ikMTjKd3XjmRO0Bawq+b7NWX2EToGGhGv51Vv69xi8++03zg JoSimnGmLPoOwK/RS8+MOouS2O629ycAa9JGtpy+Erx/tahCc5oRpXfg 6h4=

So first you see that, for this record, DNSSEC was fully validated, and then you see the records themselves (this name is a CNAME).

Now if you get back to previous lines of the output you see how this conclusion was reached.

First, the name resolution itself, and grabing the relevant DS and DNSKEY byt climbing back to the root:

;; fetch: www.icann.org/A
;; validating www.icann.org/CNAME: starting
;; validating www.icann.org/CNAME: attempting positive response validation
;; fetch: icann.org/DNSKEY
;; validating icann.org/DNSKEY: starting
;; validating icann.org/DNSKEY: attempting positive response validation
;; fetch: icann.org/DS
;; validating icann.org/DS: starting
;; validating icann.org/DS: attempting positive response validation
;; fetch: org/DNSKEY
;; validating org/DNSKEY: starting
;; validating org/DNSKEY: attempting positive response validation
;; fetch: org/DS
;; validating org/DS: starting
;; validating org/DS: attempting positive response validation
;; fetch: ./DNSKEY

So in summary:

first getting the record itself, showing it exists in the icann.org zone
so fetching DNSKEY records for icann.org zone
since they exist, we now need the DS records in parent zone, org
since they exist, we now need the DNSKEY records in org
since they exist, we now need the DS records in parent zone, .
since they exist, we now need the DNSKEY records of this . zone
and we stop here because we discover that the DNSEY records we got are in fact our trusted key (from delv documentation: "-a anchor-file
       Specifies a file from which to read DNSSEC trust anchors. The default is /etc/bind.keys, which is included with BIND 9 and contains one or more trust anchors for the root zone (".").
")

You can see that this first step, collecting DS and DNSKEY records, was bottom to top.

Now there is the second part of the output, validating th whole chain, and it goes like that:

;; validating ./DNSKEY: starting
;; validating ./DNSKEY: attempting positive response validation
;; validating ./DNSKEY: verify rdataset (keyid=20326): success
;; validating ./DNSKEY: signed by trusted key; marking as secure
;; validating org/DS: in fetch_callback_validator
;; validating org/DS: keyset with trust secure
;; validating org/DS: resuming validate
;; validating org/DS: verify rdataset (keyid=22545): success
;; validating org/DS: marking as secure, noqname proof not needed
;; validating org/DNSKEY: in dsfetched
;; validating org/DNSKEY: dsset with trust secure
;; validating org/DNSKEY: verify rdataset (keyid=9795): success
;; validating org/DNSKEY: marking as secure (DS)
;; validating icann.org/DS: in fetch_callback_validator
;; validating icann.org/DS: keyset with trust secure
;; validating icann.org/DS: resuming validate
;; validating icann.org/DS: verify rdataset (keyid=11324): success
;; validating icann.org/DS: marking as secure, noqname proof not needed
;; validating icann.org/DNSKEY: in dsfetched
;; validating icann.org/DNSKEY: dsset with trust secure
;; validating icann.org/DNSKEY: no DNSKEY matching DS
;; validating icann.org/DNSKEY: verify rdataset (keyid=18060): success
;; validating icann.org/DNSKEY: marking as secure (DS)
;; validating www.icann.org/CNAME: in fetch_callback_validator
;; validating www.icann.org/CNAME: keyset with trust secure
;; validating www.icann.org/CNAME: resuming validate
;; validating www.icann.org/CNAME: verify rdataset (keyid=8150): success
;; validating www.icann.org/CNAME: marking as secure, noqname proof not needed
;; fetch: www.vip.icann.org/A
;; validating www.vip.icann.org/A: starting
;; validating www.vip.icann.org/A: attempting positive response validation
;; fetch: vip.icann.org/DNSKEY
;; validating vip.icann.org/DNSKEY: starting
;; validating vip.icann.org/DNSKEY: attempting positive response validation
;; fetch: vip.icann.org/DS
;; validating vip.icann.org/DS: starting
;; validating vip.icann.org/DS: attempting positive response validation
;; validating vip.icann.org/DS: keyset with trust secure
;; validating vip.icann.org/DS: verify rdataset (keyid=8150): success
;; validating vip.icann.org/DS: marking as secure, noqname proof not needed
;; validating vip.icann.org/DNSKEY: in dsfetched
;; validating vip.icann.org/DNSKEY: dsset with trust secure
;; validating vip.icann.org/DNSKEY: verify rdataset (keyid=45993): success
;; validating vip.icann.org/DNSKEY: marking as secure (DS)
;; validating www.vip.icann.org/A: in fetch_callback_validator
;; validating www.vip.icann.org/A: keyset with trust secure
;; validating www.vip.icann.org/A: resuming validate
;; validating www.vip.icann.org/A: verify rdataset (keyid=52760): success
;; validating www.vip.icann.org/A: marking as secure, noqname proof not needed

As you can see now the process is top to bottom:

we validate the root key based on local data (trust anchor)
from that, we validate the DS record for org in root zone, as signed by a trusted DNSKEY
then the correspondig key is considered trusted and is seen as used in a DS record for icann.org
so we do the same step but one zone lower
and finally we validate the CNAME record for www.icann.org because this is the name we asked for
but since this is a CNAME and user (implicitely) asked for an A record, the resolution process continue
and the target of the CNAME record is in its own separate delegated record vip.icann.org so there is again a step of DS and DNSKEY records fetch and validation.
and all finishes well, with A record for www.vip.icann.org being fully validated.


Correctly disclosing Private API security shortcomings I am hoping I can get some direction on the correct way to go about properly disclosing serious shortcomings with a private web service API (closed source).

Initially I assumed that the API would be relatively well implemented, so I set about sniffing the traffic with Wireshark, intending to reverse engineer it firstly for the the challenge and secondly to hopefully implement it into another product I am working on (open source).

What I discovered plainly horrified me, there are major implementation issues which leave username/password details in clear text on the wire (as an example of just one issue).

The program is not widely used, however the user demographic it appeals to would likely be one where a 'valuable' password would often be used, and as such I feel this should be addressed by the author in some manner.

Naturally, and even though this will hamper my own efforts to integrate with the API if the author resolves the issues, I wish to disclose this to the author initially and then to the public, in the interest of having the problems resolved. To achieve these ends I would assume that I should follow Responsible Disclosure procedures.

This product does have some paying customers, however I am not one of these, and I only use the free version.

To the best of my understanding I should proceed as follows:

Contact the Author(s) privately, outlining the issues discovered with risks and mitigation options for each.
Determine a suitable time frame for patching the issues and releasing fixes with the program author.
Once the time frame expires, I release details of the problems and proof of concept code.

Some worries I have however are:

What is the best way to convey the message that I am not after any kind of financial gain, and that this is not personal and is not intended to harm the product or the company?
What if, despite best efforts, the author of the product decides to get 'legal' to try and hide the issues? (Of course you're probably not lawyers, advice will be general guidance only).
What is a valid release mechanism for the release of the details? I see announcements of this nature on the Full Disclosure mailing list often; is this generally regarded a suitable place for these?
Would this require applying for a CVE number for the problems found?
As I potentially would like to enter the information security field full time in the future, should I use a personal name on the disclosure? Or does this expose me to potential legal issues?

1) Just report the issue. Don't even mention "I'm not trying to extort you".

2) One way to completely avoid legal problems is to report anonymously. Create a webmail account using ToR, and do all communication through that. It's sad that we have to consider this, but legal issues can cause you great problems, even if you've not broken the law.

3) The most official disclosure route is bugtraq@securityfocus.com. Organisations like CERTs and Secunia will pick it up from there. The vendor will usually release their own advisory; your advisory is like a blog post that you'd promote: Twitter, Reddit, etc.

4) Apply for a CVE number at some point before you release the advisory. It's easy to get one and you only need to reveal outline details of the vulnerability.

5) If the issue gets fixed and the vendor is constructive, you could lift your anonymity. Pointing to advisories you've published is very helpful for technical infosec employment.

One other thing: I suggest you don't bring up time lines initially. Only do this if they seem to be excessively slow.


Point several HTTPS domains to the same web server We are currently running a SaaS over HTTPS(abc.net) and one of our clients(xyz.com) wants to do some custom branding. The client xyz.com will have their own subdomain xyz.abc.net which looks like its part of xyz.com when viewed from a web browser.

The client will add CNAME records to their DNS so that the HTTP(S) requests made towards xyz.com will be routed to xyz.abc.net.

The above should work in theory as both xyz.com and *.abc.net have verified Certificates.

But, what will be the certificate that will be visible in the address bar for an average user when they access xyz.com? If the user sees the Certificate of *.abc.net instead of xyz.com, is there any way to change it?

Since there already exists a certificate for *.abc.net, the customer cannot get a new certificate for their subdomain.

I already found this, but it seems a bit different from the above question. also the client does not want to proxy(which requires them to run servers).

There is no magic in there: the user will see what the web server sends, and the web server will send what you tell it to send.

You said that both URLs will share the same IP using a DNS CNAME entry, so you will encounter a different behavior depending on the browser supports SNI or not. SNI is supported by all decently recent browsers and allows them to indicate the server name during the early phases of the SSL handshake, thus allowing the web server to select the right certificate to show to the client.

With browsers supporting SNI you simply have to configure different virtual hosts (or equivalent depending on your web server) based upon the server name, each on referring to their own certificate but most probably sharing the same document root and other properties.
If you would like to support older browsers, when receiving a request from such a browser the web server, having received no server name, will always select the default virtual host and use the configuration contained therein.
If you would like to be perfectly clean and show the right certificate even for those clients, then you will need to use a different IP for each server name. Otherwise, it will be up to you (hem, your customer) to decide to what extent you tolerate a graceful degradation of your services for clients using old browser (the website will remain reachable in any case for these clients: older - and therefore by definition insecure - browsers will have a security warning mentioning the certificate from the other domain or a specially generated default certificate, depending on your configuration and choice).


What files would I be able to view as localhost? If I was able to view any page on a website as localhost using SSRF, what files should I check for? I checked to see if I could view robots.txt normally, and I couldn't, but using SSRF, I was able to. What other files are typical on websites that are normally hidden to the public, but would be visible on the localhost?

In a Microsoft environment, your best bet is probably the trace.axd file.  This is often enabled and is set to local only so you would be able to access it from localhost.

http://msdn.microsoft.com/en-us/library/vstudio/bb386420(v=vs.100).aspx

This tracing info can include lots of debugging material, developer output and environment configuration data.


oidc: do I have to verify the id token if I only use the access token? today we've had an interesting question over a coffee:

If I would implement my own client security for openID connect and use the authorization code grant - do I have to verify the ID-Token if I only use the access token?

The spec says "Clients MUST validate the ID Token in the Token Response ..." but does it make sense if I don't use it?

https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation

PS: no, I do not think about implementing my own security :-)

Not an expert but from my understanding so far..

You need to validate both access and ID tokens to ensure that the claims in them are trustworthy. You can validate in any of these ways:

Use symmetric key. In this case, the key should never reach the browser, and we need to be careful to only share with trusted entities.
Use asymmetric key. In this case we can share the public key freely with any client, including the browser so they can verify the key locally. The key can be part of the front-end code of your app or simply be returned by an endpoint from your application.
Use endpoint. OpenID Connect provides the access_token/introspect endpoint that let's us know if the access key is active. There is no standardized endpoint for the id token.

Now, in terms of validating the ID token, I think you shouldn't even request for it if you don't need it. That will make it also apparent if you need it or not. In practice, if you don't show any of the authenticated user's info in the interface (e.g. email, username, profile photo), you probably don't need it.


Storing AES password for verification I was wondering if such practice would be safe:

I have a table that stores encrypted notes
Every note has a data field and a password field
When a password is entered, i want to select all notes, encrypted with that password
For this purpose, i need to safely store the password next to the data
There can be many notes and many different passwords

To solve this problem, here's what i do:

Encrypt the data to be stored with an AES key, generated by PBKDF
Hash the key with md5
Store the md5 version of the key next to the data

Here's what i'm thinking:

MD5 is super insecure!
So we have a better chance brute forcing the MD5 hash to recover the original key
But ...
The key itself is 256 bits
So in theory, brute forcing such an md5 hash should still be a nightmare ... or am i wrong?

What would be a better alternative for storing a password hash (i only need it for determining which notes to select from db)?

Thanks for your thoughts

From Wikipedia:

  A 2013 attack by Xie Tao, Fanbao Liu, and Dengguo Feng breaks MD5 collision resistance in 2^18 time. This attack runs in less than a second on a regular computer.[2]

This means that there's a weakness in MD5's ability to distinguish between different input data - that two arbitrary inputs may calculate the same hash.

  In April 2009, a preimage attack against MD5 was published that breaks MD5's preimage resistance. This attack is only theoretical, with a computational complexity of 2^123.4 for full preimage.[40][41]

This means that there is a theoretical weakness in MD5, allowing you to locate a preimage from the result value. If your MD5 is 508e01033ebe14c9c339b9928d7ce4bd, someone may in the future (given enough computational power) use the preimage attack to find that the original password was hfghfhghfhgf.


Subdomain Bruteforcing when every request gets resolved? Is it possible for an attacker to get a list of the subdomains configured for my server, if every subdomain request gets resolved?

In the case of a subdomain that doesn't exist, the server simply resolves to a standard page. In my case it is the "Webserver Default Page" provided by Parallels Plesk.

As Schroeder stated, if the crawler is configured to not hammer your server with requests, it could most certainly enumerate each subdomain. If this is for hiding something like an admin panel, you would be best off relying on a secure login system rather than obscuring the site as you don't want to rely on security by obscurity.


How does pornhub infer gender? The adult website Pornhub (very NSFW) has an active data science blog (mostly SFW) that tracks usage statistics.

One frequently reported statistic is gender, as exemplified by the SFW post "Women and Tech" where age, OS, browser, location, access device, and gender are all reported on. While some of these variables can be inferred from IP and user-agent, I can't figure out how they determine gender or age. If this information is leaking from an ad network, how can I as a user see what is known about me?

I would go there and look right now but my Wife is right next to me so its probably a bad idea. A good place to find information about this is here: https://www.google.com/policies/technologies/ads/

Different sites use certain cookies that basically profile you and store that information remotely.  When you go to another site that is using the same services, they can request an ad, and something relevant to your past browsing history or location will be served up.

This is usually done by the use of cookies.  For example, google uses the id or IDE cookie stored in browsers under the domain doubleclick.net. Any site can use google's api to serve you content that is relevant to you.  There are many more sites and cookies that do the same.


Shall I set "RSAAuthentication yes" in sshd_config if I use only ECDSA key? In a context of proprietary client boxes and servers, I want to limit authentication to ECDSA keys. Historically, "RSAAuthentication yes" was used to enable authentication with RSA and maybe DSA keys. Does it mean "key authentication enable" or strictly "RSA key authentication enable"?  Should I set it to false?

The option names are not part of the SSH protocol; they are specific to a given implementation. I suppose you are talking about OpenSSH.

As per the documentation:

RSAAuthentication
    Specifies whether pure RSA authentication is allowed. The default is
    “yes”. This option applies to protocol version 1 only.

So this does not apply to your case, since you want to use ECDSA and ECDSA keys are supported only with version 2 of the SSH protocol.

Whether clients may authenticate with keys (instead of, say, passwords) is set with the PubkeyAuthentication option. The allowed key types does not seem to be configurable, though. A client key will be accepted if it matches the public key stored in the .ssh/authorized_keys file of the target account; thus, if you want to restrict key authentication to ECDSA, you should arrange for only ECDSA public keys to appear in such files.


How can a company tell if my password is similar to the previous 5 passwords? Closely related (but not a duplicate): Company can tell if new and old passwords are too similar. Is there a security problem?

Also closely related (but not a duplicate): How can a system enforce a minimum number of changed characters in passwords, without storing or processing old passwords in cleartext?

A particular company (I won't say which one) requires that my password not be similar to any of the previous 5 passwords.

According to the linked questions, when they check to see if your password is too similar to the previous one, they just force you to enter both the old and new password and compare them that way. I understand that, and there doesn't appear to be any security problem with that.

However, the company in question actually compares my password to the previous 5 passwords, none of which I enter. How might they be doing this? Should I take this as evidence that they're either storing my passwords in plaintext or that they're using a really weak hashing function, or is there a legitimate way that they could do that without potentially compromising my password?

The linked answer in the second linked question briefly alludes to this issue but doesn't really fully address how they might be doing this or how big of a security concern it is.

Could be done in a variety of ways:

Keep a list of the last five passwords used, hopefully encrypted.  Not the safest thing obviously, but certainly do-able.
Keep a list of hashes related to the last five passwords, e.g. full password, first X characters, last Y characters
Keep a list of characteristic patterns of the last five passwords, e.g. llllllllds.  l being letter, d being digit, s being a special character.  If the pattern is the same, but the hash different, then it's just too close.


Protecting an account after staying logged in in a public place I had forgotten to log out of my personal T-Mobile web account on my computer at work today. When I came home, I remembered, so I logged on to my account at home (different computer, different network, of course, from work), and changed my passwords, pin-codes, as well as security questions. In addition, I have 2FA on.

Is this sufficient? I want to make sure I am logged out of the work location before I go in tomorrow. I want to make sure no one else can make any changes to my online account.

Part of the problem you will face is based on how the site is designed. If you make all those changes at home, will the site force your work computer to require the user (whoever that is) to log back in before making changes? Good design says that it should, but it depends on that specific site.

If T-Mobile forces re-authentication, then you have done what you needed to do.
If T-Mobile does not force re-authentication, then someone could sit down at your computer and make their own changes even after all your work.

There is not a lot you can do to protect yourself in the second case. It then becomes a challenging customer support issue.


Making S3 objects viewable only for logged in users As a service provider, I allow logged in users to upload documents to a web server, and upload it to S3.  The logged in user should subsequently be able to view his own documents, and I want to serve it directly from S3, with some token-based authentication per request.
I thought that this was a pretty simple and standard use case for S3, but I am unable to find a standard way to this.
Does S3 effectively support per request authentication at object level, and what is the "correct" or "standard" way to do this.
I have read some documentation for STS, but am not able to find a clear way to solve this.
Pre signed urls almost works; the only difficulty is that that it seems to only work with a pre-set expiration time, and "logout" is not supported.

Would it be possible to grant the user an IAM role? If so, you can scope the roles so that each user can only see objects that begin with their prefix, e.g. username/*.
Each user's IAM role will grant them only access to objects whose keys begin with the specified prefix.
The other option would be to use lambda functions to generate pre-signed urls for the user on a per request basis (with very short lived time), hence removing the need for logout, (i.e user request a file, and gets redirected by lambda to the pre-signed url per request).
To the point though, there isn't a 'right' way of doing this as far as I know, and there might be many other options I'm not aware of either.


Website vulnerability scanner in Java && Open Source I am working on a Web platform that must-need-should have a good level of security.

Therefore, I am interested in a good quality tool to test my Web platform QA on security.

My main programming skill is Java.

Is there a really good and open source tool for the website scanning e.g. OWASP, auto cookie check's and similar things. Ideally written in Java(need to be able to customise it)

Looking forward to hear your suggestions,

You can do some automated scans with OWASP ZAP or Burp (Burp isn't free).


my site with joomla 1.5.14 got defaced and I'd like to know how he did it and stop it I am supposed to manage the content of a site and it got defaced.
The site is hosted on a Linux server running Apache.
Apache version: 2.2.13
Linux version is Debian 4.0(I think I don't really have access to anything more than a ftp account and phpmyadmin).
The index.php page was replaced with a blank page with the attacker's internet moniker.
I installed a Backtrack 5 virtual machine.
I ran Armitage on the site with a "Hail Mary" and it found no exploitable services
I ran joomla scan I got the following output(I'm only pasting the vulnerable bits for the sake of being concise):

# 1 Info -> Generic: htaccess.txt has not been renamed. Versions Affected: Any Check: /htaccess.txt Exploit: Generic defenses implemented in .htaccess are not available, so exploiting is more likely to succeed. Vulnerable? Yes

# 2 Info -> Generic: Unprotected Administrator directory Versions Affected: Any Check: /administrator/ Exploit: The default /administrator directory is detected. Attackers can bruteforce administrator accounts. Read: http://yehg.net/lab/pr0js/view.php/MULTIPLE%20TRICKY%20WAYS%20TO%20PROTECT.pdf Vulnerable? Yes

# 19 Info -> CorePlugin: TinyMCE TinyBrowser addon multiple vulnerabilities Versions effected: Joomla! 1.5.12 Check: /plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/ Exploit: While Joomla! team announced only File Upload vulnerability, in fact there are many. See: http://www.milw0rm.com/exploits/9296 Vulnerable? Yes

The conclusion that I drew from these 2 scans is that the attacker didn't compromise the system but only the web application.
I tried to reproduce the supposed TinyMCE attack but that got me nowhere.
I found the instructions here:
http://bl0g.yehg.net/2009/07/tinybrowser-tinymce-editor-plugin-1416.html

But they don't work for me I get "Restricted Access" when I try to navigate to those supposedly vulnerable urls and no folders or files are created as described in the document.
So I am stuck.
How did they do it?
How can I stop them from doing it in the future?
I cannot update the Joomla version this is a very old website and the theme stops working in newer versions of Joomla. I could modify it but that will eat up a lot of my time especially as I haven't worked much with Joomla since about 2008(other than simple content management and a few tweaks here and there).
I'd like a simple solution to keep attackers from defacing my site without modifying too much.
Thank you.

Upadte 1: w3af says: The URL: **/index.php/component/k2/itemlist/search is vulnerable to cross-site request forgery.
Could they have defaced my site with xssf? Isn't that just for compromising the machines of people that visit a particular website?

I'd bet the TinyMCE addon is how they got in.

Here's how I'd clean it up without trashing the whole box:

Make a full database backup. Check the users table and delete any you don't recognise.
Back up all media files (uploaded directory) and check through them for any shells / PHP files.
Download version 1.5.14 and install it.
Restore the old database.
Download the newest version of the 1.5.x branch and upgrade your installation.
Install the latest versions of your plugins.

You might want to take a look at some of the Joomla Security documentation too.


Software overflow exploitation lab Working through a binary exploitation course posted by RPI a few years ago. Currently on the ASLR lab and having some trouble with it (although not with the parts related to ASLR). I can't figure out how to exploit to begin with, to then deal with the additional complexity of the ASLR bypass.

Heres the code (running on 32 bit Ubuntu):
https://github.com/RPISEC/MBE/blob/master/src/lab06/lab6C.c

I would think since they have you compile without the canary that there's an overflow to exploit. Looks like all the sizes are checked correctly except for the one for loop but there's also some weird behavior I don't understand.

Things I do/don't know or have tried:
1. If I write 40 characters to the username, then the for loop overwrites one byte of the message length field.
2. If the username is very long, then part of the tweet field is overwritten and the user input for fgets on line 58 is skipped and the tweet is no longer empty (this is the part I can't seem to understand). In set_tweet, the memory is zeroed at the start anyway, so if there was old data there, how could it not be erased?
3. If I could overwrite more than 1 byte of the message length of the struct, I could transfer more of the large readbuf into tweet and overrun that structure into other memory. Test compilation with 41 instead of 40 in the for loop confirms this.

If I write 40 characters to the username, then the for loop overwrites one byte of the message length field.

You are right. This seems the key for the explotation here.

  If the username is very long, then part of the tweet field is overwritten and the user input for fgets on line 58 is skipped and the tweet is no longer empty (this is the part I can't seem to understand). In set_tweet, the memory is zeroed at the start anyway, so if there was old data there, how could it not be erased?

This is indeed unintuitive, and we need to dive into the way stdio works in order to explain it.

When we call fgets(readbuf, 128, stdin); (as in line 74), fgets reads from stdin into readbuf until it reaches a newline or 127 characters. However, when you write 128 or more characters (ie. at least 127 characters before a newline), the rest are kept in the stdin buffer, and extracted when calling fgets on line 58. That's why it doesn't need to ask the user again.

Suppose our username input is 01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567\n

After line 74 readbuf will be 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456

and on reaching line 58, readbuf will be set to 7\n.

  If I could overwrite more than 1 byte of the message length of the struct, I could transfer more of the large readbuf into tweet and overrun that structure into other memory. Test compilation with 41 instead of 40 in the for loop confirms this.

Well, you can only write up to 255 bytes :)

However, that's enough for explotaition. Note that sizeof(struct savestate) = 184, and after save the stack contains ebx, the old ebp, and ret.

The stack layout at handle_tweet seems to be like this:

0xffffd840  <local2>
0xffffd844  <local1>
0xffffd848  <save>  aka. ebp-0xc0
0xffffd904  <old ebx>
0xffffd908  <old ebp>  current ebp points here
0xffffd90c  <return address>
0xffffd910  previous stack location

Good luck!


Why not send a plaintext recovery password? It seems like plaintextoffenders.com sees sending a plaintext recovery password as wrong. Instead, a link to set a password is better. But what's the difference? If a user follows a link and sets a password, or gets a password, logs on, and changes it, the danger seems the same. If someone intercepts the email between following the link or between logging on and changing the password - they can both impersonate the user.

To be clear, I'm referring to a new temporary password. Only password hashes (PBKDF2, scrypt, ...) are stored on the server.

EDIT

Since I'm asked why I think plaintextoffenders include new passwords, take a look. Currently, the 5th, 6th, 7th, and 8th are explicitly new passwords.

If a user follows a link and sets a password, or gets a password, logs on, and changes it, the danger seems the same.

Based on all of the posts there I've looked at, I think the problem is with "and changes it". None of the emails there I've seen give any indication that the password is temporary and will need to be changed. Without wanting to bother creating a bunch of accounts myself, I would be conservative and assume that, if the email doesn't say you'll need to change the password, the site won't force you to change it after logging in.

You are correct that there is no real difference between a temporary password and a reset link as long as the password has enough entropy. As mentioned in the comments, if the password is too short and the user waits a while before logging in, it could be susceptible to brute force. Since password fields should allow pasting anyway, a 20 character alphanumeric temporary password would be perfectly fine. Both the reset link and the temporary password could be implemented nearly identically, it's really just the difference between a POST and a GET.


Consequences of using -s and -d arguments in iptables We are studying iptables for a Computer Systems Security course. We are confused as to what happens when the -s and -d arguments are both used in the same rule, such as:

iptables -A OUTPUT -s 10.7.53.2 -d 10.7.53.5 -j REJECT

We know how to block ports coming in and going out as well as ip addresses. However, we are unsure as to what the line above does.

At first we thought it blocks output from one ip address to another, but when we tested this theory we found the assumption was invalid.

As I understand:

Switch -d and -s are associated by a and expression.

But.

As you're talking about a firewall, and  iptables -A OUTPUT mean iptables -t filter -A OUTPUT, this seem not to be right:

chains INPUT and OUTPUT concern packet from or to the host (firewall).

This coud be usefull if your firewall hold many different IP address and want to make condition based on wich IP is used.

Even if 10.7.53.2 is the only (local) IP of your firewall, -s switch is clearly useless.

For blocking a traversing connexion, you have to instruct FORWARD chain.

iptables -A FORWARD -s 10.7.53.2 -d 10.7.53.5 -j REJECT


How to widely advertise a fixed important threat in widely used open source software? 6 months ago, I found a buffer overflow in git which has the same impact as this vulnerability (with the execption that it allow server side code execution). It got several cve assigned to it and was completely fixed upstream.

However, 2 months after the upstream fix, the cve details are still unpublished and near no Linux distribution updated their stable branch.
I even noticed that wikimedia gerrit and bitbucket.org were still vulnerable last week (I warned the appropriates persons and it got fixed on wikimedia).

I definitely can’t bring the information to every provider. I know it can take years for a cve to be published. But It definitely don’t break the news like cve-2014-9390.

How to widely advertise it so peoples and Linux distributions fix their machines ?

Unfortunately there are no hard and fast rules about this kind of issue and with the very wide use of open source components and libraries it's inevitable that some companies won't update even after a long time (for example 200k servers still vulnerable to Heartbleed a year after release)

In terms of getting people to pay attention and patch, unfortunately it still seems like the only way is to publish vulnerability information widely and publicly, after an appropriate private notification period.

Exactly how long you want to have for that period is a matter of debate, with people going from 0-days all the way up to many months.

Perhaps a decent guideline would be to follow Cert's Responsible Disclosure Policy which releases after 45 days.

From the timeline you describe it sounds like you're well past that point already, so really if you want to see more people pay attention the best way may be to write up a blog post describing the issue and potential impact and circulate it widely.

Whilst it may seem cynical to suggest this, in terms of getting people to pay attention, marketing the vulnerability may be the best way to go.  If you look at recent vuln's that get publicity most have a catchy name ("Drown", "Heartbleed" etc) and the write-ups explain in quite clear terms the likely impact.  Then it's a case of it getting picked up in social media (twitter, reddit etc) and starting circulation amongst the InfoSec community.


How are attacks and APTs attributed? It's increasingly common to see major attacks on governments and corporations attributed to a specific country or group.  Typically we don't know for certain, but it's at least suspected.

Given the general anonymity of the internet and the ability to hide behind proxies, exactly how do security experts go about determining exactly who perpetrated an attack?

As someone who runs personal honeypots and used to defend a massive global corporation, I can tell you that any attack leaves fingerprints. Styles of commands or command sequence, coding style of malware, as well as the paths used by attackers can all point in a direction of an attacker.

For example, I was able to positively identify someone trapped in my honeypot because they used their real name as their password (they didn't know I was recording their keystrokes). Using various correlation methods, I was able to attribute the pseudonym they were using on the site they used to distribute malware to their name, including finding out that they used the pseudonym on a single's site 2 years ago that they had deleted (but Google's long memory did not forget).

Once you start studying live attacks, you can really start to see the people "behind the keystrokes" and that's one reason why I continue to operate honeypots. I think I can tell whether an attacker is Asian or Eastern European, simply by their methods, and not by their IP. If I had enough data from a known attacker, I believe I would be able to recognize their actions in a new environment.


MQTT over TLS - ca certificate on client We are experimenting with MQTT in our project.

We have a secure connection to our mqtt broker, so mqtt over TLS (or mqtts) and we use a proper signed certificate (not self-signed) from a trusted source.

With some of our clients we have to pass the CA root certificate (of the certificate provider that signed our server certificate) to allow for a successful handshake procedure.

For example when using mosquitto:

# Publish
mosquitto_pub -h 'mqtt.example.com' -p 8883 --cafile "path/to/certificate/ca.pem" -u "username" -P "password" -t "planet/earth" -m "hello world"

# Subscribe
mosquitto_sub -h 'mqtt.example.com' -p 8883 -t "planet/earth" --cafile "path/to/certificate/ca.pem" -u "username" -P "password" -v -d

If we don't pass the CA-certificate in these examples above we cannot connect (connection is refused).

But when using this node MQTT client we don't need to pass the CA root certificate. Why not? I suspect that this node MQTT client uses the certificate store on my computer to validate our server certificate, but I cannot find any confirmation on this in the documentation.

I am careful and that is why I don't just want to jump to this conclusion, since there might as well be something wrong with the MQTT server/broker configuration that allows connecting without validating the server certificate properly?

So the question: does node-mqtt use the certificate store on my computer? Or does it have a store with trusted CA root certificates?

Lets start with TLS.

Certs to do two things Encrypt a connection and Validate authenticity of both sides of the connection.  All major web browsers have a list of Certificate Authorities included by default (ex Firefox).  These CAs are used to check all certs you generally come accost on the web. Likewise you also have a client side cert in your browser that is unique to you (unique to your session?), however, it is not signed by any type of CA and thus you have no way of proving to the HTTPS server that you are who you say you are.

It is possible to Verify the Identity of both sides of the TLS connection.  In order to do this a HTTPS server has to be configured with a list of client side certs to trust ... or a "Root" cert that all client side certs are signed with (think internal network https for a company).

Node.js is based on chrome and like chrome it uses a list of Certificate Authorities ref ... from a brief skim of my google search this list is configurable within node.js itself.

When I have configured MQTT for TLS in the past I have always done self signed certs for encryption not caring too much about verification of identity ... I would assume that you can configure a list of Certificate Authorities or a Root Certificate, but it is a guess at best.


How does this website prevent directing away from it I'm using the latest version of Firefox with Ghostery and Adblock plus installed. This website somehow prevents navigation away from it. How does it do this and how can it be protected against?

I can't even close the browser now.

http://www.imagesnake.com/ad.html
I didn't realize it at first as I was using Adblock Plus but the site causes popups containing pornography.

I did visit the page (from a safe place!) and it's triggering the  beforeunload event to change the URL, like this:

var exit=true;
var temp_url = document.location.href;
var url_pieces = new Array();
url_pieces = temp_url.split("/");
var goto_url = 'http://www.imagesnake.com/ad.html' ;
window.onbeforeunload = function () {
if(exit==true){
    location.replace(goto_url);
    return "   Special Offer: Free Porn Videos ";
}
}

I did this with Chrome, and got the "Page is asking if you want to leave..." dialog, and was able to close the page.  I can guess that, depending on the browser, one might not be able to get out.

There may be other tricks in the plethora of JavaScript the page loads.  This is the one that stood out for me, based on the browser dialog.


Why is a link in an email more dangerous than a link from a web search? Everyone knows of the common cybersecurity tips to be careful when you open links in an email. But every day we look for something on the Internet, clicking links which the search engine shows us, and we do not have the same fear. Why are the links in email considered more dangerous than links from web search results?
Maybe it is related to the fact that links in an email may contain a more personal attack malicious to you or your company?

The results of a search engine are based on previously collected data, i.e. the engine does not starts to scanning the whole internet when doing a search but it looks through an index of seen and stored sites. The results are also ordered, i.e. the sites which fit the query best and which also have the highest reputation for good answers in general are at the top. Thus, as long as fairly common search terms are used the top hits come from sites with a high reputation.
There are attempts to pollute search engines by returning different results to the search engines web bot than to the normal user. This is not new, so search engines partially try to detect such pollution by simulating normal users. They also include historic reputation information, i.e. sites which behaved shady in the past are considered shady for some time in the future too. New sites also have less reputation than established sites etc.
This together makes search engines results fairly good (but not perfect) curated data. Links in mails are the opposite of this: No up-front checks and curation are done to these links and it is all to the end user (or some security software in the path) to decide if this link is safe or not. That's why these links are far more dangerous.


Can I use Authenticator instead of phone number for Gmail 2FA? I want to enable Two-Factor Authentication for my gmail accunt, but when setting this up it asks for my phone number.

I don't have a phone (that I want to connect to Gmail), is there another way to enable 2FA? More specifically I'd like to use Google Authenticator, is that possible?

I'm actually surprised that Google doesn't clearly offer Google Authenticator as a 2FA method right away.

Google Authenticator worked for me - but it was a little bit tricky.

Go to https://myaccount.google.com/security and start the process of enabling 2FA
Google required me to enter my phone number - I could not find a way to enable Google Authentiactor without prior entry of a phone number. So do this and enable 2FA.
Once 2FA is active, you can add a second authentication mode (say Google Authenticator App).
Now you can make the Google Authenticator App your default and remove the phone number from the list of 2FA providers.

I don't know why there is no simpler way to enable the Google Authenticator App - this is really a bit strange. This answer is based solely on my own experience; it might be that I missed something.


Why are CA-issued certificates considered so much more secure than self-signed certificates I looked at other Stack Exchange posts explaining why self-signed certificates are not as secure as CA-issued certificates, and most of these pages say the same thing:

If it's self-signed, and the 1st client-server handshake is intercepted, the man-in-the-middle could receive the encrypted data from the server, decrypt it, do bad things with it (change it or send it to the hacker who now has your password), and encrypt it again with the fake certificate.

But this system is based on the fact that the CA makes sure that you actually own the domain. The way CAs check that is by sending you an email with a verification code. Everyone on this website knows that email is very insecure. It seems very strange that SSL certificates, which are all about security rely on such an insecure system. Why don't they use stronger verification methods, such as adding a piece of code to the homepage or create a DNS record?

CA signed certs are not actually more secure than self-signed certs, in the sense that the level of encryption is the same. But there is a big difference in the level of trust between the two. Visitors to a site using a self-signed cert have to trust that the cert was generated by the site owner, simply because the site says it is. There is no easy way to discern if there is currently a man-in-the-middle attack happening. With a CA signed cert, now the user can trust that both the site and a 3rd party are in agreement that the cert was generated by the site owner, so a man-in-the-middle attack would be much more difficult to pull off.

Note: the original question has since been edited; the following statement applies to the previous wording but I'm leaving it here because it is still informative:

  In your question you claim that some CAs will issue a signed cert
  without making sure you own the domain. If that were true, then
  perhaps there would be some validity to your assumption that certain
  CA certs are not more trustworthy than self-signed. Fortunately
  though, it is not true that any widely trusted CAs will issue a signed
  cert without verifying you own the domain. In your comment you mention
  that the verification may be as simple as receiving an email, and you
  question the security of that.

I think it is good to question how secure receiving an email is, but you must admit that receiving an email is entirely different than no verification at all. You do have a point in implying that the trustworthiness of those cheaper certs may not be as high as other validation levels, (which might include installing a code on the web server), and that's why there are different levels of validation. Arguably though, since most visitors do not inspect the certs, perhaps the more expensive certs are really not much better than the cheapest ones, with the exception of the most expensive "green bar" EV certs.

So, in a sense, I agree with your implication that perhaps the minimum standard for obtaining a CA signed cert should be raised to beyond simply receiving an email, but as it stands today, this is what we have, and it's still much better than nothing.


If service is http over TLS/SSL is communication completely safe? Last week at the country I live in there was an article in a newspaper with a list of people (journalists, businessmen, etc) that were being spied by the intelligence services of the country... They explained that this agency was spying all their whatsapp conversations, skype calls, cellphone calls, etc...

So when I read that I started to wonder HOW can they spy whatsapp conversations as they are over TLS, if they want to do a man in the middle attack they need to change the certificates in the device so they can attack the connection... is there another way??!?!?

This is a big surprise for me because I have nothing to hide, but I was happy just checking if the connections were https to feel secure as I thought that way nobody could see what I was sending/receiving (I know if they have access to the servers they can check anything but that's not a concern for me...)

And another question, how secure is to use Skype/Viber for calls? Is skype safer than a landline or cellphone line? Is telegram more secure than whatsapp?

No. The extra Root Certificates in your browser's (or computer's) key store/wallet can be used to engage in Man-in-the-middle attacks should anyone in the Internet providing chain be able to get a signed certificate for the web server you're connecting to from one of those extra Root CAs.  For example, say you've got a Turkish Root CA in your key store on your Mac.  If your ISP can get the Turkish Root Authority to issue a server certificate for the host www.whatsapp.com (bribe, intelligence service in Turkey) then your connection from your computer or phone to whatsapp.com can be routed to a middle server for an MITM attack.

Remove those untrusted Root CAs and you'll be safer. You may have a problem with the new logjam attack, which is a cipher suite downgrade attack, or with using an algorithm that cryptographers now strongly believe can be broken (a handful of commonly used DH keys of length 1024 bits or lower).

See these answers on How NSA can break Web and VPN sessions and MITM attack against SSL.

I've never studied Skype's security.


What did Blackberry do wrong? The NIST defines a vulnerability in RIM Blackberry encryption discovered last October.

Apparently, Blackberry's flavour of PBKDF2 was weak. They say:

  The offline backup mechanism in Research In Motion (RIM) BlackBerry Desktop Software uses single-iteration PBKDF2, which makes it easier for local users to decrypt a .ipd file via a brute-force attack.

[Note: emphasis added.]

What does "single-iteration" mean?

Does it mean that the fourth PBKDF2 parameter was 1? (Considering the function
PBKDF2 (HMAC, password, salt, nbiterations, length).)

Or do we actually have to feed the result of PBKDF2 to itself, over and over again, a great number of times?

Here's the PDF of the standard

ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2-0.pdf

That shows (page 4 & 5) that RIM set nbiterations as 1.

Here's a more general overview for people wanting a bit of easy to read background:
(It's a blog post of a company selling products which they mention on that page, with a single text link.)

http://blog.crackpassword.com/2010/09/smartphone-forensics-cracking-blackberry-backup-passwords/


Where do I get started in terms of learning how to exploit Java and Flash vulnerabilities? or browser exploitation in general Another Java 0day was discovered today which got me thinking how browser exploitation (remote execution on clients browser) works.

I am unable to find any books or resources online about browser exploitation, I can code and know how to use a debugger. However, I have no idea where to get started in terms on learning how to exploit browser using Java or Flash. Any resources or a list of prerequisites will be very useful.

Targeting sandboxed platforms like Flash and Java will be excessively difficult if you're just starting out, so I suggest you learn to walk before you try to run.

Some stuff you'll want to know:

How to code in a low level language like C.
What the stack, registers, heap, etc. do, and what happens when you overflow them in various ways.
At least basic x86 assembly.
Most of the API suite for your platform (e.g. Win32 APIs)
What an executable file really contains / how one works. For Windows, this is a PE file, for *nix it's ELF.
Exception handling mechanisms for your platform, e.g. native exceptions, SEH, VEH,

A few resources to check out:

Buffer overflows on Wikipedia
CoreLAN Exploit Writing Tutorials
x86 opcode reference (incredibly useful when manually writing payloads)
Smash The Stack CTF (especially io, which focuses on reverse engineering)

From there, you'll be on your way to understanding how browser vulns work. There aren't really any direct tutorials for that kind of thing, because the environment is so varied dependent on your browser and the plugins it is using.


Best way to encrypt data using php - I am not sure if I doing it correctly I want to encrypt some data within my php file when I add the stuff to my mysql database.

This is how I do it.

I create a static key like:

$key = md5("pass");

Then I have two functions called encrypt() and decrypt() and they do this:

function encrypt($string, $key){
    $string = rtrim(base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $key, $string, MCRYPT_MODE_ECB)));
    return $string;
}

function decrypt($string, $key){
    $string = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $key, base64_decode($string), MCRYPT_MODE_ECB));
    return $string;
}

I am not sure if this is best practice but like how do I generate a key other than md5?

There are at least two problems with this approach.

Your choice of key generation
Your choice of encryption mode

Key Generation

You're doing md5("static password") as your key. This is really bad. First, you're "only" getting 128-bits from MD5 and you're using 256-bit keyed AES, thereby wasting cycles (because AES-256 is slower than AES-128) on something you're not using anyways. Secondly, you password is weak. "pass" is not a secure password and I really hope you replace it with something much stronger for production use. Third, you're using plain MD5 for the password processing (also see our canonical answer on password hashing). This is as bad as it can get, because the ciphertexts could be attacked using precomputed (rainbow) tables and MD5 is a fast hashing function, allowing fast brute-forcing of your password. Fourth: Why are you even using a password!?. There's no logical reason to use a static (human-readable) password instead of a secure, randomly generated key of the desired size. This way you don't have to worry about brute-force, you don't have to worry about using MD5 (which will give bad press) you don't have to worry about your key to be too short.

Encryption mode

While you use AES-256 as encryption algorithm (which is OK), you're using ECB as your mode of operation for AES. This way you have two problems: a) you're leaking which AES blocks (16-bytes) are equal and b) you have to pad your messages to be a multiple of 16-bytes. To fix these problems you need to swithc the mode. GCM is the best option you have. Unfortunaly, this isn't properly supported by PHP until PHP 7.1 via openssl_encrypt() or mcrypt_encrypt() (which you really shouldn't use, because it's slower, no longer maintained and less hardened than OpenSSL). If you already have PHP 7.1, then fine, you can use AES-GCM with openssl_encrypt(), which will protect your ciphertext from being read and / or modified, provided you hand a unique (not secret) nonce over for each encryption. Until you have proper PHP 7.1 AEAD encryption, you have to use an ad-hoc construction. This means, you first encrypt the data using a (random) 16-byte IV with CTR mode and then you calculate the HMAC-SHA256 of the ciphertext and store the resulting tag, so you can verify it upon next read access.


Server vulnerability scanning How can I discover server vulnerabilities without using a scanning software such as openVas? is there any manual ways or steps to follow to assure server security.

Thanks in advance

So what does OpenVAS actually do? It fingerprints your server, does discovery scans, mappings etc. and then compares your system with an exploit database, identifying all vulnerabilities that are most likely affecting your system.

All these steps can be done by a human in a manual way. You can, for example

perform an nmap scan on your server,
grab the server banner and identify the OS/server version,
check for services that run on the server,
search exploit-db for exploits for the services you just discovered,
etc.

Depending on your server setting, this is an immense task and extremely tedious and time consuming - that's why automated scanners were implemented in the first place.

Also depending on your server setting (e.g. you own the server, have full admin access to it and to programs' source code), you can do manual audits, code reviews etc. to verify manually if there are any potential vulnerabilities or policy violations present. It all depends on how much time and pain you are willing to put into it.


Why don't OTPs have letters? Is there a reason why OTPs (one-time passwords) are only made up of numbers? I've seen OTPs of varying lengths but all of them are only made up of numbers. Why are they not alphanumeric?

Some systems do use alpha one time password. S/Key or the less old OpieKey are example of them
For OTP systems using hardware calculators, the price of the hardware matters, and digital displays able to display only digits are cheaper than ones able to display letters
The OTP is generally computed as a mere number (ie a sequence of bits). It can then be represented as a decimal integer (only digits), an hexa integer (0-9 + A-F), encoded in base64 (alphanumeric ASCII), or in a any other encoding. The already cited S/Key used a number of 4 letter words.


Allowing request to internal services only from specific IP addesses Suppose you have an app on the DMZ servers.
The app needs to access the internal services installed in the internal network.
The internal firewall between the DMZ and internal network has rules to allow traffic only from specific source (DMZ server) to specific ports (for the specific services).

Do you also block any requests from internal network as well? For example, have a white list of allowed internal IPs to call those services and others will be blocked from the insider threat perspective. That white list will probably be blank for PROD because for PROD, there is absolutely no reason other system (other than DMZ server) to access those services.

Is this the general practice in the wild? Any better suggestion?

Any app in the DMZ is at best only semi-trusted. Ideally apps in the DMZ should have NO reach into the internal network, data should be pushed not pulled so firewalls only need to open from the more secure to the less secure network not the other way around.

If that is not possible for some reason (and it would have to be a really good reason!), you need to make absolutely certain that the DMZ app has the minimum possible access to anything.

In addition, you don't really even want anything reaching out if you can avoid it. Every connection is a potential risk.

In most cases, you would even create a parallel network for management traffic so that you can further limit and reduce the available attack windows.

Blocking Insider Threats

Restricting internal networks to block insider threats is a sensible idea but don't loose sight of the value of your data and the relative risks involved. Most forms of security come with some cost maybe $$$ but maybe in admin overheads and user overheads so be sensible.

Having said that, it is very important to separate assets of differing values and security. So high security data such as your core PKI infrastructure or patient records, etc. should be kept separate from less important data such as management information perhaps (depends on your business). Segmenting data in this way can actually reduce costs in some cases because, even though the infrastructure and admin costs may be higher, the physical protection costs overall may be less than having to protect everything.

There isn't really a one-size-fits-all solution for this.

One other consideration. Internal controls are by no means just about stopping insider threats. Remember that most intrusions to large enterprise data lie undiscovered for 12m or more and often are only discovered by external parties. It is common practice for the bad guys to break into something innocuous and then slowly work their way up the food chain, keeping below the intrusion detection radar all the way.


What kind of vulnerability it may have for known ssh-hostkey? I saw there is NSE script in nmap that can retrieve the ssh-hostkey (RSA or DSA) from the target host.

For example,

22/tcp open  ssh
|  ssh-hostkey: 2048 f0:58:ce:f4:aa:a4:59:1c:8e:dd:4d:07:44:c8:25:11 (RSA)

Can anyone explain what could happen if we can get ssh-hostkey? Is it a kind of misconfiguration for ssh?

This script retrieves only the fingerprint of the public key (shown in your question) and on request the public key itself.

  Shows the target SSH server's key fingerprint and (with high enough verbosity level) the public key itself. It records the discovered host keys in nmap.registry for use by other scripts. Output can be controlled with the ssh_hostkey script argument.

source nmap.org

As the public key by definition is public this serves only informational purposes on the client and poses no vulnerability/security threat at all.

The informational purposes I mentioned might be in the line of:

prepopulating the list of known host keys for a SSH/SCP-Client
checking if the host keys of servers have changed (to trigger an investigation about the reason, for instance)

The fingerprint of a public key serves to identify that key (make it easier to recognize) because it might be difficult to see when the complete key (2048 bit = 256 characters) has been altered. The fingerprint (normally called a hash) will be completely different even if only a single bit has been changed.


Ensure web service only accessed by authorized applications Preface

My mobile app allows users to create accounts on my service. In addition to being able to log in with external authentication providers, like Facebook, I want to give the user the option to create an account using an e-mail address.

Normally, all calls to my web service are authenticated via basic authentication over HTTPS. However, the create account function (also over HTTPS) does not have any authentication - since the user does not yet have any credentials.

If I was writing a website, I would use Captcha to stop my database from being filled up with bogus accounts via script.

Question

How can I verify that new user requests are coming from an instance of my application and not from a bot?

If all data is sent over HTTPS, is it sufficient for the application to have a stored password to say "hey, it's me!"? What are the best practices for doing something like this?

Elaboration

The server is written in Java using the Spring Framework and Spring Security. It is hosted on App Engine. Cost is a concern (both network and computation). The app is a mobile game. I do not store sensitive information like credit card numbers. However, I do keep track of user purchases on the Apple and Android stores. My biggest concern is player experience. I don't want a hacker bringing down the system and ruining someone's enjoyment of the game. I also, need to make sure that the player faces as few obstacles as possible when creating an account.

Update/Clarification

I am looking for a way to ensure all calls to the service are coming from an instance of my application. User accounts are already protected because the stateless service requires that they send their credentials on every request. There are no sessions and no cookies.

I need to stop bot-spam on the unsecured calls, such as create-new-account. I cannot use captcha because it does not fit into the flow of the application.

The bottom line is that you will need to embed a secret into your app. It is an unfortunate truth that DRM (which is more or less what you are trying to achieve) is impossible. A person with access to your app will always be able to recover the embedded secret, no matter what you do to protect it.

That said, there are plenty of things you can do to make your embedded secret very difficult to recover.

Construct it at Runtime - Do not store the secret in a string or configuration file anywhere in your app. Instead derive it from a series of computations at runtime. This stops attackers from simply browsing your app with a hexeditor.
Never Send it Over the Wire - Use a challenge-response system of some kind with a >128bit nonce, that way an attacker cannot MitM the SSL stream (which is easy when he controls the mobile device remember) and see the secret in the clear.

In any case, try to find a tried and tested key-scrambling mechanism and authentication protocol. Do not roll your own.


Does a secured guest network on my router create significant vulnerability? Guests need to use Wi-Fi when they come by, so to minimize risk, I've simply kept a secondary secured router running for guests since it's not possible to understand anybody's computer & security habits with certainty.
The guest router is starting to go bad and the cost of new high performance routers are high. If I open a secondary secured guest network separate from my own, am I exposing myself to vulnerability? I keep the router firmware up to date, and it's not a model known for much vulnerabilities.

If the router has an explicite feature to create a guest network then it is likely separated from the normal network - but you still might be liable to what the guests do since they still share the internet access for you. If the router does not have an explicit guest network but instead something else you use as guest network than it is unknown how good the separation actually is.
Of course, this is only assuming that the guest feature is implemented in this specific router like it typically is (i.e. full separation from the other network) and there are no bugs. While this is probably the case one cannot be sure.


Security concerns allowing internet connected server to write on network server I don't know much about network engineering since I just started becoming a programmer. The situation is, that my company has a web-interface hosted on one of our servers that is connected to the internet. Employees of the company log into the web-interface with their password and fill out a form/upload data. Now i want this data to be put into a folder on another server that's used to store customer data. This second server is not connected to the internet.

If we allow the first server to write into the second one, is there a way to ensure it is only done by users in the web-interface and not by someone hacking into the server? Are there other security concerns we have to think about and what can be done about them?

When a hacker takes over the public server, you have to assume the worst case that they can do everything the public server is allowed to do. That means in case of a compromise, any security precautions implemented on the public server are inefficient. You can only rely on those precautions you have on the private server.

Make sure that the public server only has permission on the private server to store files in that one folder. You certainly don't want it to put some files into system folders.
Set file permissions on the private server so that no user is allowed to execute the uploaded files (but keep in mind that simply opening a malicious document might exploit a vulnerability in the reader software which might allow code execution).
Storing the files from the frontend should be the only purpose of that folder. There should be no other data in there which might get overwritten.
Setting a quota for the maximum size of that folder can also be a reasonable protection against an intentional or unintentional denial-of-service attack through filling the whole storage space of the server with garbage.
Having a virus scanner on the private server to scan the incomming files can't hurt. But don't trust it too much. Remember that a malware scanner can only find what it knows.
A sensible precaution can be to only allow files with specific extensions to be uploaded. But keep in mind that the file extension is not a reliable method to check for a type of file. Finding out that hello.jpg is actually a renamed executable is non-trivial. However, it prevents accidental execution due to double-clicking in most cases.

Another possible way of doing this is to use a pull-method. Don't have the public server push its files to the private one. Have the private server check for new files on the public server at regular intervals and pull them. This gives you greater control over what files to pull. You can, for example, only pull files with filenames matching a specific pattern.


what to do if your online banking has low security standards What can I do if I think that my online banking service is not secure enough? the bank I'm considering is hsbc us (but I believe such issues are common to many) and here's two items that I believe prove low security standards:

Your password is not case sensitive and must be between 8-30 characters. It must include letters, numbers and may contain these special characters @ _ ' . - ? ! $ * =.
they claim to use 2fa, but here's how.

is there any federal entity or perhaps website where a consumer can point such problems out? or what would you do?

Probably the best you can do is contact your banks branch manager and share your concern.

If he may understand and can share your view, he may take it up the hierarchy up-to CISO.

If they find it to be a serious concern they would look at the possibilities to improve it. Which involves efforts and financial budget..since it may require to change or upgrade their systems.
If they don't find it to be serious...u may keep banging ur head.

As for the any regulatory authorities I guess they can always only provide guidelines, can not force. since the security requirement is a personal choice of the individual, not a matter of govt body. Customers are always free to check all the details before becoming a customer. Check if ur netbanking form that u signed at the time of enrollment gives u any option for raising such concern.
U may consult an attorney for help. Banks and any service provider for that matter are free to choose any kind of computing as well as security mechanism they may find deem fit for their requirements.
If you feel you've been victim of cyber attack on ur banking account and that u can prove with solid evidence that it is due to the negligence of the bank and the way they have setup their IT systems, then man ur in commanding position. You may sue them for such negligence.

I don't think with the given information it can be claimed to be insecure.

change the bank if you are not happy with their services and ur so paranoid with their IT security. But this time study the potential bank's IT systems and other aspects of the services more thoroughly, so u don't end up being so paranoid.


Why adclick.g.doubleclick.net listens on all ports I have adclick.g.doubleclick.net listening on all ports. When I launch an application like Starcraft 2, for example, it is listening on localhost. Or for some applications, there was a connection from my hostname to remote address: adclick.g.doubleclick.net which is google server.

I thought doubleclick.net concerns only Chrome and web advertising. What does it have to do with other software installed on the computer? I already blocked it by mvphosts, but I am curious.

My guess: you modified your hosts file to include 0.0.0.0 adclick.g.doubleclick.net or 127.0.0.1 (same) as a way of preventing webpages (or maybe apps) from accessing that site, likely because you don't like advertising or consider it a privacy violation.

As a result, when tools like netstat etc try to display something that is using address 0.0.0.0 (which is actually the special value INADDR_ANY) or 127.0.0.1 (which is actually the loopback address used for localhost) they end up displaying the bogus name you assigned to that address. Try netstat -n to turn off name translation and see what is actually going on.


Who is author/designer/creator of PBKDF2 algorithm? Just consisting list of credits/references who's algorithms I've used in my software and found that I couldn't identify who is real author of PBKDF2

Can anyone hint me?

PBKDF2 (RFC 2898) was developed by RSA Laboratories as part of the PKCS series of standards.  While there has been no public recognition of the individuals who worked on this specific algorithm as far as I know, Burt Kaliski was the Chief Scientist and Editor of the PKCS at the time, (and author of RFC 2898) so its fair to give him some measure of credit for it.


Connecting trusted and untrusted networks We have two domains that are isolated. First domain is the Corp LAN, the second is an hostile untrusted network with untrusted clients that could contain malware.

Clients on the untrusted network create reports that need to be read by users on the Corp LAN. Currently the reports are copied from the untrusted network onto a USB scanned by the corp. AV then copied onto the Corp LAN.

We would like to remove the need of the USB transfer and simplify the process.

If we put a firewall at the edge of the untrusted network and a firewall at the edge of the Corp. LAN then in-between the firewalls host a staging server that the files can be stored.
We could then open the Corp. LAN firewall to allow users to get to the files.

Is this good practice?
What is the risk of malware hoping from one domain to another?
Are we opening up our corp. network to any risk?

diagram:

The networks are physically separate but on the same campus.
The Corp network is behind an existing firewall.

So what you're kind of describing is a DMZ or demilitarized zone. This is a common and widely accepted way for hosting quite a few different services. Such as Web Servers, Mail servers, FTP servers in a safe way.

Essentially for your particular use case and from what you've suggested perhaps using a Dual Firewall architecture DMZ with an FTP server in it, would be the best way to go about this

Because the DMZ acts as a buffer zone between the local area network and the Internet, it is a less secure network than the internal network.

For this reason, there are added security measures that are taken for a DMZ host which include, disabling unnecessary services, running the necessary services with the privileges reduced, eliminating any unnecessary user accounts, and making sure the DMZ has the latest security updates and patches.

The added benefit of the second firewall is that as you know the company from which you're expecting data, you can whitelist them for access  to the firewall. Which reduces the risk of an unpatched SFTP server being exploited. Although not fully, as the external company can still be used to launch the exploit.


Remote Biometric Authentication using mobile phones As Google endeavours to do away with passwords, biometrics authentication as a method of proving identity has gained popularity. Logging into a system using a fingerprint or other biometric data would be something that is very difficult to steal. HSBC and First Direct have opted for voice biometric verification for its personal and business accounts customers.

Would remote biometric authentication be as efficient, secure and robust as we would like it to be? What role could mobile phones apps (i.e. ios 7)play for remote biometric authentication applications?

Biometrics should never be used for direct remote authentication. It suffers two major flaws:

it must be stored in clear text or at least with an invertible encryption on the server - it has been discussed many times why it is not possible to store a hash of a fingerprint, mainly because what the captor sees may be slightly different on each time
it cannot be revoked if compromised

So if one server has an image of your fingerprint to authenticate you, and if someone manages to get an image of it (from the server, from your passport, from a beer glass, etc.) he will be able to authenticate on behalf on you and the only thing you will be able to do is to find another authentication method.

The correct way (which is described on a Microsoft's page about that is to have a private key on a local system (say a mobile phone) and that key is locally secured by your fingerprint. But even in that case, all is stored on the mobile phone(*) (the private key, and an image of the fingerprint in an invertible form), so if it is stolen you must immediately ask the server to revoke the current key. The good point is that as the key is an asymetric key independant of the fingerprint, you can easily revoke it, and create a new one to use on your new phone.

(*) That means that is the phone can be unlocked with the fingerprint, you have not a multi-factor authentication system, but only a something you have.

That being said, for securing a local device, a fingerprint is probably less secure than a good password because it may exist on your passport and on the last glass you have used, but certainly more secure than a trivial one and at least you should never forget it...


Are eavesdropping attacks possible on Ledger Nano S hardware wallets? Regarding the Ledger Nano S hardware wallet for cryptocurrencies, I've heard it claimed that the private keys for the wallet are securely stored on the physical device and protected even if the PC is infected with malware.

However, isn't it necessary for the private keys to be passed through USB into the client application's memory at some point in order to send money from the wallet onto the Bitcoin/Ethereum blockchain? Is that a possible attack vector?

Or is it possible for the client application to initiate a transaction without the private key, using some kind of derivative instead. If so, what if the malware was able to intercept this derivative?

Does someone with more technical knowledge of this understand how the security is maintained?

Properly implemented hardware wallets perform all operations with the private key on the wallet itself, and not in the PC connected to the wallet.  Only the inputs and outputs to the signing operations are sent over the USB connection, never the private key itself.

The user uses their application to specify that they want to make a transaction.
The (hardware-aware) application generates a transaction that is not yet signed with the private key, then sends it to the hardware wallet to be signed over USB.
The hardware wallet signs the transaction, using the private key kept in a secure element, and returns the signature over USB.
The application uploads the signed transaction to the pool to be included in the blockchain, finalizing the transaction.

In most hardware wallets (e.g., TREZOR and Ledger), there is a step between 2 and 3.  These wallets require the user to confirm the transaction using an interface on the wallet itself.  This is to protect against malware forging requests to the wallet to spend money (which could occur without the user noticing).

These concepts are not new to hardware wallets for cryptocurrency: many smartcard based systems have used these for years, such as the OpenPGP card for performing GnuPG-based operations.


Ways to certify a SaaS for security Is it common for small companies to get security certificates/compliance from audit agencies for their SaaS to present to customers for their assurance?

If so what are the suggested certifications?

It's something I've seen but seems to be most common with either larger companies or those serving markets that particularly need/value certifications (e.g. finance, government).

In terms of which ones to look at there's a couple of options that I'm aware of, some of which are geographic in nature.

ISO27001.  General InfoSec one, but very useful as evidence of security processes for a lot of companies
SSAE16 (Formerly SAS70).  US focused service organisation certification.  Again some US companies might well look for this
FIT 1/94 - Bit niche and UK based, only look at it if a customer asks.

The advantage of these certs can be that you can avoid customers who have audit requirements from coming and bothering you a lot (i.e. they can rely on the cert and don't need to prove control levels themselves)


Is Nokia's "institutional MITM" of SSL traffic vulnerable to CRIME attack? It's recently been in the news that some Nokia phones proxy all traffic, including SSL connections, through a Nokia proxy.  This is effectively an "institutional MITM" attack on users those phones.

Nokia is apparently doing this to save their users bandwidth.  Apparently, their proxy compresses data.  This is a laudable goal.  However, Thomas Pornin raises the question of whether this might make them vulnerable to the CRIME attack.  This is a troubling possibility.

So, my question is: is Nokia's system vulnerable to the CRIME attack?

(Opera Mobile and the Kindle Fire also proxies HTTP traffic, but SSL connections are not proxied.  However, I think Opera Mini does proxy even SSL connections, like the Nokia browser.)

In the system used by Nokia, the Nokia server runs a man-in-the-middle attack (Nokia denies it because they really do not like the term "attack", but this is still, technically, a MitM). Their servers obtain, even so briefly, the decrypted data. Therefore, if Nokia is the attacker, then Nokia wins, and has no need of playing elaborate games like the CRIME attack. Therefore, in this answer, I assume that Nokia is an honest player and that their servers are not hacked into. The question is: can an outsider run a CRIME-like attack on the mobile browsers without hijacking Nokia's servers ? This depends on several things.

But first, we must note that Nokia's browser has been updated and the new version (as of January 11th) no longer runs a MitM on HTTPS connections. This is probably in response to the news items about their use of MitM, which are "bad public relations" and thus needed fixing. Therefore, all I say below must be understood with an implicit past tense: this does not apply anymore.

Also, note that I do not own a Nokia phone, and I am here making inferences based on what has been described "on the Web", in particular Gaurang K Pandya's blog.

1. How is the interception performed ?

When doing a systematic proxying of Web traffic, there are several ways to do it. One way is to define your own protocol between browser and proxy, possibly quite different from the usual Web standards (HTTP and HTML). This is what Opera Mini does: the page rendering is done on the Opera server, and the result is sent to the browser.

Apparently, Nokia's browser does not work like this. Instead, the network traces obtained with Wireshark show that the connection between the browser and Nokia's server is a perfectly normal SSL/TLS handshake. Moreover, the proxy generates a fake server's certificate, issued by a special CA which the proxy controls. That the proxy even bothers with building a fake certificate means that the browser will validate that certificate as if it was a normal certificate. Analysis of the DNS queries shows that the browser does not try to obtain the IP address for the target server, but only for Nokia's server, which the browser knows under its true name. This strongly hints at the following setup:

The browser is a "normal browser" and does not implement a special proprietary protocol.
The browser is configured to use Nokia's server as a generic proxy (with the CONNECT method described in RFC 2817, sections 5.2 and 5.3).
In the set of "trust anchors" known by the browser, to validate server certificates against, is the "special CA" controlled by Nokia.

This kind of setup makes sense, economically speaking, because it allows reusing existing protocols and software; and, to a large extent, it allows switching back to non-interception on the server without changing anything on the clients. (That Nokia actually pushed an upgrade is a bit weird; apparently, they now tunnel SSL through HTTP with a yet unspecified protocol; this deserves further investigation.)

2. What kind of compression ?

Assuming that the browser is a "normal browser", then it would make sense that the use of compression follows a standard scheme. There are two standard ways to apply compression on HTTPS traffic:

Compression at the HTTP level. The body of requests and responses can be compressed with some algorithms, usually "deflate" and "gzip" (the latter being a very light wrapper over the former, they offer almost identical compression ratios -- see RFC 1951 and RFC 1952).
Compression at the SSL level. This one applies on every applicative byte sent through the tunnel; in particular, in the case of HTTPS, it covers both request headers and bodies. There again, "deflate" is used.

SSL-level compression is both simpler to implement (because you do not have to parse HTTP headers for that, you just compress the bytes -- and usual SSL libraries already support it out-of-the-box) and is likely to yield a better compression ratio (because, contrary to HTTP-level compression, it can exploit repeated sequences between successive headers and bodies), I deem it plausible that Nokia used SSL-level compression.

It could be verified by anybody with a Nokia phone (i.e. not me)(and not a phone which has been upgraded in the last few days). SSL-level compression is activated during the initial steps of the handshake, so it would suffice to have a look at the ServerHello message from the server: there is no encryption yet at that point. Wireshark can do that.

Of course, plain SSL-level compression is exactly what the CRIME attack needs.

Thus, my tentative conclusion is that it is plausible that the Nokia MitM/compression system leaves the browser vulnerable to the CRIME attack (actually, left it until two days ago, when they changed their system).

3. Can the attack be really executed ?

The CRIME attack relies on the ability for the attacker to insert some hostile Javascript in a page which the client loads, and to observer the data streams that emerges from the victim's browser and is directed towards a target server. This usually means that the attacker must be close to the victim or close to the target server. In our case, the SSL-with-compression is between the mobile phone and Nokia's server, and we assumed Nokia's local network to be honest and clean. Thus, the attacker must act in the vicinity of the victim.

Gaurang K Pandya uses WiFi: his phone acts like a basic laptop computer or tablet. Many smartphone users use WiFi whenever possible, because it is cheaper (WiFi usage does not count towards the monthly 3G quota), often faster, and possibly lighter on the phone battery. Thus, many smartphones can be configured to look for open WiFi networks, and/or WiFi networks for which credentials are known, and to use the 3G network only as a fallback.

WiFi is known to be susceptible to the redirection tricks that CRIME builds on. This is especially easy here: the attacker just runs an open WiFi hotspot. Phones in the immediate vicinity will see that hotspot as having a very clear signal, and will connect to it. If all data packets go through the attacker's hotspot, it becomes easy to intercept an HTTP page load, insert the hostile Javascript payload, and then run CRIME. Endgame.

If the smartphone uses 3G, things become harder. Javascript payload insertion can be envisioned with various tricks (e.g. with a HTML email or things like that). The part about observing the SSL-encrypted stream is harder, though. 3G connections are encrypted, normally with the KASUMI block cipher. An important point is that CRIME is all about the length of encrypted data. It is not strictly necessary to see the SSL records; the attacker just need to know the length of these records. The fact that the records will be encrypted with KASUMI does not hide their length (especially since, in UMTS, KASUMI is used in counter mode which means that it preserves the length of the data which is encrypted, with bit-level accuracy). Trickier would be the frame granularity: radio networks split data into individual, atomic frames, which hides part of the length information that the attacker needs. It can be repaired, though, with phasing: the attacker alters the length of his hidden requests so that the compression is at a threshold (that is, compression success, meaning one more cookie byte guessed, implies a SSL record which uses one less frame). Fine tuning would probably be a matter of delicacy.

Also, 3G interception means using a scanner and recognizing the target smartphone packets within the noise. Phones hop frequencies very frequently, and following one specific phone entails knowing where it will jump next, and that information is encrypted. I do not know enough about 3G to know whether this would be surmountable in the context of the CRIME attack.

4. Conclusion

Was Nokia's "institutional MitM" vulnerable to CRIME ? Probably.

Did their recent upgrade fixed that ? Probably.

Is Opera Mini also vulnerable ? Probably not because it is an off-loaded rendering, which means that Javascript does not run on the browser itself, but on the server. But a CRIME variant might still be applicable.