If I am obliged to store a password/certificate on a client side, how can i make sure that it is protected? In certain cases we need to establish a key/password/certificate as a first timer and then as a client we need to use this key/password/certificate to get authenticated. Therefore the key/password/certificate should be stored at client side.

How to secure this key?

Of course we can hash it but we still need the key and not the hashed value to login again.

Considering your comment up top, I would say that while this is possible, it is quite complicated with numerous likely pitfalls.

Though it is not yet so common, I would strongly recommend you look into CardSpace (nee InfoCard). Basically this provides a very secure implementation of what you're looking for, and additional benefits (e.g. the user has more control of what information is sent to whom). Of course it is not without tradeoffs, e.g. users are less familiar with it, and it's a bit complex to implement...


Signal protocol implementations: pub key authentication and inspectability? (Allo, WhatsApp, FB messenger, Signal) A critical part of the Signal protocol, used by Google Allo, WhatsApp, Facebook Messenger and Signal, among others) is a public key infrastructure. Public keys are needed to set up sessions. As far as I can see, it doesn't specify a way to authenticate the keys. Ie, when Alice sets up a session with Bob, how can she be sure she receives his public key and nobody else's?

Secondly, assuming the above question has a satisfying answer, can we check what happens on the wire? Ie, can Alice (having access to her private keys) examine the protocol on the wire, extract Bob's public key and authenticate it by hand (fingerprint it, call Bob and ask him to compare)?

This probably differs per implementation, I guess. As a start, I don't see an answer in the WhatsApp encryption overview whitepaper. So how is this implemented?

In a broader context the real question is of course: to what extent do we need to trust the implementations, i.e. the service providers? Honestly, it's strange to me that there's so much fuss over these services being end-to-end encrypted; it seems to me (NOT an expert on the protocol!) that it's easy enough for the service providers to eavesdrop, if they'd want to. They may not want or intent to, but for whomever privacy is important enough, it's still a liability.

when Alice sets up a session with Bob, how can she be sure she receives his public key and nobody else's?

She currently can’t. (A better question would have been: how can Alice be sure that the client uses Bob’s public key for setting up the session, and not one of a malicious user?) The WhatsApp security whitepaper says:

For authentication, users can manually compare public key fingerprints through an outside channel.

There are two problems with this:

Alice has to rely on the client to generate the public key fingerprint / QR code. You may see the problem with relying on the client to verify that the client is using the correct keys.
Which brings us to the second problem: even if Alice can fingerprint the public key that the client stores for Bob without using the client, then how can she be sure that the client uses this key when she communicates with Bob, instead of e.g. using the public key of some malicious user? Verifying the protocol on the wire is what is needed here. The client being closed source doesn’t make things any easier either.

  can we check what happens on the wire?

Not as far as I know. In the Reddit thread relating to this question, one commenter notes that better documentation for the Signal Protocol will be published soon. Hopefully this will help. But what we really need for this are detailed instructions on verifying the traffic.

  to what extent do we need to trust the implementations, i.e. the service providers?

First of all, as far as I can see the Signal protocol includes basically everything that is required from an encryption protocol to set up secure e2e channels. If key exchange ever becomes secure, we have all ingredients needed for e2e communication.

But with the current implementations we’re not there yet.

So as an answer to this question, I’d say we should assume that the secrecy of our chat messages fully depends on the good will of the service providers.


HTTPS enable for proxy server or web server Say I have 2 separated servers which are one web server (apache) and one proxy server (nginx), I want to use HTTPS for the website running on the Apache.

Do I enable SSL on apache or nginx or both?

If enable on both, is it duplicated setup? because my internal network (between apache and nginx) are very secure.

If both using HTTPS, the speed will be affected than only one HTTPS connection (between internet and proxy).

It's common to terminate SSL (ie. decrypt traffic) at the first point where your network receives the traffic assuming your internal network can be considered secure. Often this is at a load balancer or caching proxy.

In your scenario I'd terminate the SSL at nginx.


If one HashiCorp Vault Policy allows a capability, and another denies it, how does it decide which Policy to honor? HashiCorp Vault is an open source tool for secrets management.

I'm using it for this purpose, and have come across a minor issue. I seemingly cannot deny access to a specific API path.

I've tested this on 2 different Vault clusters. And it seems like I can't deny access to the "sys/leases/lookup" path.

Do "deny" capabilities trump the parts of policies that give explicit capabilities on a path?

It seems that that's not the case, since the capabilities from the default policy are being favored over those in my "deny-leases" policy.

The default policy allows lease lookup:

# Allow looking up lease properties. This requires knowing the lease ID ahead
# of time and does not divulge any sensitive information.
path "sys/leases/lookup" {
    capabilities = ["update"]
}

And my creatively named "deny-leases" policy, well, you might say that it doesn't allow lease lookup:

~ |  vault policy read deny-leases
path "sys/leases*" {
 capabilities = ["deny"]
 }

Let's make 'em fight!

~ |  vault token create -policy=deny-leases
Key Value
--- -----
token s.10yrKnAdsBaxTErxXxXvAuLt
token_accessor 2c8beef0kPVLuSjtSsStONgs
token_duration 768h
token_renewable true
token_policies ["default" "deny-leases"]
identity_policies []
policies ["default" "deny-leases"]
~ |  export VAULT_TOKEN=s.10yrKnAdsBaxTErxXxXvAuLt
~ |  curl --silent --header "X-Vault-Token: ${VAULT_TOKEN}" --data '{"lease_id": "auth/userpass/login/heyitsme/deadbeefdeadbeef85cbd6edf586527d824e09560987654321123817e96234e93"}' --request PUT "${VAULT_ADDR}/v1/sys/leases/lookup" | jq
{
 "request_id": "f98e2444-357b-bcof-feef-74b58443feef",
 "lease_id": "",
 "renewable": false,
 "lease_duration": 0,
 "data": {
 "expire_time": "2019-01-21T17:03:41.72395079-05:00",
 "id": "auth/userpass/login/heyitsme/deadbeefdeadbeef85cbd6edf586527d824e09560987654321123817e96234e93",
 "issue_time": "2018-12-20T17:03:41.72395019-05:00",
 "last_renewal": null,
 "renewable": true,
 "ttl": 1049229
 },
 "wrap_info": null,
 "warnings": null,
 "auth": null
}
~ |

Looks like the default policy "wins", here, because its explicit allowing of that capability overrode the explicit denial in the deny-leases policy.

How does Vault decide which policy "wins", and how would I restrict access to the lease lookup?

The short, and unsatisfying partial answer, here, is to just modify the default policy to remove or "comment-out" (I know) the sys/leases/lookup stanza.

#path "sys/leases/lookup" {
#    capabilities = ["update"]
#}

Still doesn't answer the broader question of the nitty gritty details of how one set of Policies' deny capabilities might or might not override capabilities allowed in another Policy, and where.


Webserver DDOS protection without giving away private keys (https, tls, ssl) What are the possible ways to protect an organization's web servers from a DDoS attack without giving away your web server's https private keys?
Many of the common solutions for DDoS protection of a web server (eg CloudFlare) require you to give a third party either your https private key or (worse) give them the ability to mint their own valid certificate for your domain (eg control of your DNS for ACME).
I don't feel comfortable giving a 3rd party my website's private keys.
How can I protect my web servers from a DDoS attack without giving my private keys to a thrid party?

The reason 3rd party DDoS protection services require your private keys, is so they can actually inspect the traffic and act upon that.
Without that, they're just analyzing IP streams of encrypted data. DDoS protection is still possible in that case, but only really effective for all attacks based OSI layer 3 and 4. For example, UDP floods, TCP SYN attacks, specific hosts generating a lot of traffic, etc. can be detected and mitigated with no problem at all.
However, it's impossible to detect Layer 5-7 attacks, because that's all encrypted. So attacks on specific URLs can't be detected for example.
On-premises equipment can be a solution for doing the Layer 5-7 attacks yourself. However, for those Layer 3/4 attacks it isn't always a solution. For attacks small enough that they don't fill up your upstream connection(s) it could work, but not everyone is able to handle DDoS attacks of over 100Gbps in their own network, and in that case an external scrubbing centre could be a solution.
So if you really don't want to share your keys, combining a Layer 5-7 on-premises solution with a Layer 3-4 remote scrubbing center could be an interesting combination. That's from a technical perspective of course, there may be financial or other reasons not to do that. And everything depends on which type of DDoS attacks you want to protect against.


How does a browser stop malware from executing? When it comes to infections with viruses, in almost all cases the initial infection requires some sort of user interaction - apart from those cases where a plug-in has some sort of security flaw which gets abused.
While the why is clear - you simply don't want your browser to execute random binaries it found on the web, the how is another question.
In a sense, the browser is just a piece of software running on your machine, so similar to how a Python script can execute a binary from a path or the bash can do the same, it should be possible for the browser to download an executable and run it.
Additionally, the browser already has access to the disk for specific files, like its cache or maybe an encrypted password storage. What keeps it from looking around for a passwords.txt and reading it out?
Is it the browsers themselves that just "don't do that", i.e. a malicious dev could release a fork of Chromium which just accepts binaries to run them and could read all files the current user has access to?
Is it the various protocols like HTML and so on that don't support these security-related actions? Could the malicious dev here code an HTML page which wasn't fully "up to spec", did some malicious readout and as long there's a custom browser on the other side understanding these additional features, one could have a data breach?
What is the fundamental design decision which protects users from drive-by infections and requires at least some user interaction for a virus infection?

Is it the various protocols like HTML and so on that don't support these security-related actions?

Since it is at the end the browser which downloads the content and interprets the content (including the HTML), it is also the browser which decides what the content is allowed to do. On top of this modern browsers have a robust security architecture with sandboxes which prevent most attacks even if the attacker could exploit bugs in the browser.

...  i.e. a malicious dev could release a fork of Chromium which just accepts binaries to run them and could read all files the current user has access to?

There is noting inherently magic in handling content from the internet, which might prevent an arbitrary program from interpreting it in a malicious way. Thus  it is of possible to create a browser which does not have any security protection. One might even create a browser which already has a back door or similar already built in, i.e. no download of additional content needed.
And this problem is not restricted to browsers. That's why it is important to not just install arbitrary software from the internet, no matter if it is claimed to be useful, secure, profitable or whatever.


Preventing replay attacks with JWT I am currently building a RESTful API that will be used for a web and mobile app. Authentication to the API will be done using JSON Web Tokens.

When using JWT, we can use the exp claim to expire the token after a specific time. This, combined with the jti claim is useful to prevent replay attacks, and something that will be built in to our app. However, for user convenience, we do not want to keep asking them to log in with every request or after short intervals of say, 30 minutes.

So, I'm thinking of the following situation:

User logs in using their email address and password
Server sends back a JWT with an expiry in 1 hour
The client makes another request to the API, passing the JWT in the header
If the JWT is valid, the API sends back the requested data, and another JWT, which again expires in 1 hour

If the client does not make any further requests within the allocated 1 hour expiration time, a subsequent request would ask them to log in again.

My question: is this the best solution trade off between usability and preventing replay attacks?

I think you need to separate you concerns. Protecting the JWT on the client side is the job of the application using the JWT, not the API. If this line is blurred than you may need to re-engineer you application as it's probably more monolithic, rather than service driven.

JTI, EXP and IAT are designed more to give you the tools to mitigate an attack if it's been compromised. TLS is used to prevent snooping of the JWT while in transit. Shortening the window for the EXP will limit the exposure of the single token, but ultimately if they got the token via the application, the EXP is mute, they'll just grab the next token.


How did the spam email sender get my name? Some time ago I bought something online from a reputable website. I paid through my credit card and everything worked fine. The thing which is important to note is that the name used on the credit card is different from the name I use everywhere else on the internet. Now I am getting spam emails with the name on my credit card to buy stuff. These emails are not from the website from which I bought the product. I do not understand how they managed to get my details. I use Windows 7 with Microsoft Security Essentials.

It is MoneyBookers. I am not blaming them. Just curious how it happened.

Under the "How we use your information" section of their privacy policy, Moneybookers/Skrill has this to say:

  [in order] to provide you with information, products or services that you request
  from us or which we feel may interest you.

and this:

  We may disclose your personal information to any member of our group,
  which means our subsidiaries, our ultimate holding company and its
  subsidiaries who are based in different countries within the EEA and
  in the USA.

They appear to have enough loopholes in the agreement that you voluntarily accepted to allow them to pass your information along to a third party, or to act on behalf of a third party.


Spoofing USSD messages I'm looking into USSD messages for a project I'm currently working upon and hoping someone can shed some light into spoofing.

Firstly, I know it should be possible if you have the relevant information (correct IMSIs and global titles etc.) and access to a telco environment. But how easy is it for a malicious user to send out a spoofed USSD string? What sort of equipment will be required?

I've never done this myself but it was done by Chris Paget at Defcon in 2010 successfully for an equipment cost of about $1500.  You can find more information on what he did at the following links:

http://www.wired.com/threatlevel/2010/07/intercepting-cell-phone-calls/

http://www.darkreading.com/security/news/226500010/researcher-intercepts-gsm-cell-phones-during-defcon-demo.html

http://www.theregister.co.uk/2010/08/02/gsm_cracking/


GDPR Deletion Request Tracking Paradox - Suppression Lists I work at a large-ish tech company with hundreds of websites and some large web applications with a very large number of users.

I am planning to propose that we have a central system to track deletion requests to ensure if a person requests we delete their details they are deleted everywhere.

If a database is restored any users deleted record will return so deletion requests cant be one-off requests that are never recorded, we would need a record of users who have asked for their details to be deleted (unless there is a better idea).

It sounds self defeating and likely non-compliant to be storing details of users who have asked for their details to be removed.

It also feels like this is likely a previously invented wheel.

Is there a recommended or widely accepted practice for this?

I was thinking maybe a hash of the users first name, another hash of their surname and lastly a hash of their email address, and development teams could hash emails on their system and check for matches.

Edit: To aid search queries, I found the standard term for this is 'suppression list' after some further googling.

It is exactly the right thing to have a deletion request management system. In fact, given the importance of this function, the timeframes for response, the workflows to coordinate, it is almost certainly necessary.

GDPR does not prevent companies from storing personal details of their users/customers/etc for legitimate purposes. Instead it is intended to generate more thoughtful practices around the management lifecycle typically associated with this sensitive data.

For instance, what teams in companies do to record interactions with different flavors of users is track relevant and often personal details in whatever workflow tool the particular team happens to prefer. Maybe this is Salesforce, or JIRA, or email. Whatever.

This careless sprinkling of personal details around team-specific workflow infrastructure is one of the anti-practices a successful GDPR implementation will ideally deprecate.

So a deletion request management system needs store personal information that is used to match in other systems. It needs to be sufficient to identify the person requesting the deletion. That data can be retained for the duration of its legitimate need. When that need has expired- the deletion workflow is completed- this system is no different from any other. Personal details get deleted from the deletion request management system as well. (The exact policies and timing around this are of course decided by the legal team).

In terms of practices, the likely common practice with databases is scrubbing. IDs of records with scrubbed fields need to be retained, both for future validation and also to support the scrubbing process being applied following a restore of production data from backup.

When it comes to matching, one nit- my understanding as a non-lawyer is that what is considered to be personal information is not just identifying information like first and last name. Personal attributes that may not be identifying but are nevertheless unique and characterizing of a person are also subject to deletion/scrubbing.

Using hashes to efficiently match fields across systems may help, but with names, there are numerous spelling and other variations. Doing this sort of matching is its own data management practice that companies that have had to consolidate customer databases are likely familiar with.


How to encourage my ISP to use better security One day, I was playing around with my router configuration. As the result I was able to view TR-069 configuration. I was able to see that the updates server was using HTTP protocol, instead of HTTPS. This made me worried about my router security. From Defcon 22 ( https://youtu.be/rz0SNEFZ8h0 ) I know that TR-069 should be used together with HTTPS protocol, to minimize risk of attacks.
I have disabled my TR-069 at my router to not be vulnerable.

Today however I received an email from my ISP, asking me to format my router using reset button on back. While the email does not explain why this is needed, I expect this to be because of disabled TR-069. For now I ignored the email, however if my ISP requires me to have TR-069 enabled, I at least want to be sure that such things can not put my security at risk.

My question is how can I encourage my ISP to use better security?

As a side note I would like to point out that I live in UK, and I would not like to get into any troubles.

Tell your ISP about the issue. It's unlikely to do anything, but you should do that for ethical reasons before you take the next steps.
After they ignored you for a few weeks, report the issue to any technology-oriented news websites which are popular in your location so they can shame them.
Should the websites be uninterested in running the story, or should the ISP not consider it worth their while even after they got publicly shamed, look for a different ISP.


Is it safe to open a message in inbox? (but not the GIF itself?) I received message in my inbox of facebook which says my friend sent me a gif.
Now, is it safe if I only see the message? By seeing the message I mean "just" the message itself, and not click on the "gif". is it safe?
Or it is not possible to safely open such a message?
I am concerned about virus.

Why are you concerned about malware? A GIF is just a image format, which may contain animations. It's rather old, and the code is fairly well tested, so there's quite low chances of security problems in gif handling code.

Furthermore Facebook is quite good at filtering out malicious content - especially in messages.

In sum: the chances of getting malware from viewing a image on the internet is next to zero. The chances of getting malware from clicking on something in a message on Facebook, without further action, such as downloading files, is low.

Note that FB Messenger also supports gifs from a approved palette. In case it is one of those gifs, it's absolutely safe.


Tor via Python - can the real IP address leak? I was thinking about how safe it really is to use Tor as a "local proxy" to grab information from webpages anonymously. Is it possible that the real IP address can be seen?

On the official Tor homepage they claim:

  Tor does not protect all of your computer's Internet traffic when you
  run it. Tor only protects your applications that are properly
  configured to send their Internet traffic through Tor. To avoid
  problems with Tor configuration, we strongly recommend you use the Tor
  Browser Bundle. It is pre-configured to protect your privacy and
  anonymity on the web as long as you're browsing with the Tor Browser
  itself. Almost any other web browser configuration is likely to be
  unsafe to use with Tor.

  The Tor Browser will block browser plugins such as Flash, RealPlayer,
  Quicktime, and others: they can be manipulated into revealing your IP
  address. Similarly, we do not recommend installing additional addons
  or plugins into the Tor Browser, as these may bypass Tor or otherwise
  harm your anonymity and privacy.

Is this something of concern for me when I run the script below (with Vidalia/Tor enabled)? Would my real IP be revealed if I ran the script on different webpages? The webpage in the code below (my-ip.heroku.com) is very simple and only returns my IP address. But how exposed would I be for example on webpages with browser plugins such as flash, realplayer, quicktime etc.?

import socket
import socks
import http.client

def connectTor():
    socks.setdefaultproxy(socks.PROXY_TYPE_SOCKS5 , "127.0.0.1", 9050, True)
    socket.socket = socks.socksocket

def main():
    connectTor()

    print("Connected to Tor")

    conn = http.client.HTTPConnection("my-ip.heroku.com")
    conn.request("GET", "/")
    response = conn.getresponse()
    print(response.read())

if __name__ == "__main__":
    main()

In this case, no it won't leak.

What you're doing in Python here is simply making an HTTP request via a proxy that happens to be Tor's local SOCKS proxy. The response of this request will basically be some text. Regardless of the actual content of this response, your Python "client" will not actually parse the response or user plugins to run certain contents. The HTTP request is passed through Tor and no subsequent requests will happen depending on the response.

So, plugins or not, JavaScript or not, it all won't affect your case. Also, when calling setdefaultproxy(), you're setting rdns to true which will prevent DNS leaks by performing the DNS lookups remotely.

The quote you posted is written in a slightly paranoid language. They obviously don not mean that 100% of the cases your IP will leak if you don't use Tor Browser Bundle. They just mean that it's far more likely that you'll miss something while using your own browser, like that DNS setting, not disabling plugins, and so on.


Are files created in Chrome OS developer mode tracked by Google? If I enable developer mode, then open a shell and create /some/directory/temp.txt, it is invisible to me through the Chrome Filesystem API. But does this mean that it's also invisible to Chrome OS itself?

This is a follow-up to this question.

You're asking two different questions here, so I shall address each:
Is a file I save in dev mode tracked by Google?
Yes, yes it is, Google doesn't really respect privacy, even if they say they do, and if you are in developer mode, you are a far more interesting target for tracking.
Is it invisible to Chrome OS if I save files in dev mode?
No, again - everything is visible, this is configurable in the settings (think of Windows OS with the hidden files option).
On a side note, a file is never truly "invisible" to an OS, there is always a way to make invisible files visible.


Steganography - outguess vs steghide Looking for some steganography guidance

This maybe a noob question, but what is the difference between outguess and steghide? Are all steganography tools alike? Can I make a secret text file image in outguess and then open it up in steghide? I am not using a passphase at the moment, just researching this topic.

Thank you for your time!

Are all steganography tools alike?

No. There are various techniques you can use to embed data into an image starting from just embeding black-white images in the least significant bit of each color channel to more sophisticated methods to methods that only work for specific image formats etc. There are methods that require a key and methods that don't require a key (or passphrase).

Not all stegonagraphy uses images. You can use txt files, you can use html files, you can use word documents, you can use audio files... you can hide pretty much "anything" in "anything" - but it depends on how much secret data you can hide in non-secret data so depending on the methods you use you're limited in how much data you can hide.

If you want to know how each individual tool works... you gonna have to read the documentation of the individual tool and hope they document how they do it or you gonna have to read their source code.

Addendum:

People think data is somehow "typed" or has an innate format of some sort. But this is obviously false. If you see 8bits 10101010 you have absolutely zero clue as to what these bits represent. It could be a character, it could be 8 single bits, it could be 2 4-bit unsigned numbers, it could be a pixel in an image, it could be 8 pixels in a black white image it could be a 1 byte instruction. Bits have no inherent meaning. WE give them meaning by associating a type & encoding with it. That's why you can hide almost anything in anything.

You can hide text in html by abusing the fact that multiple spaces are rendered as a single space so when you open the file in a browser you see nothing. But these spacings you can use to encode bits. For example: 2 spaces -> 1 bit, 3 spaces -> 0 bit so this text in html:

This  is   a  short   text.

Which is rendered as

This is a short text

BUT

This  is   a  short   text.
     1    0  1       0

contains 4 bits of hidden data. You can give meaning to things in some format that don't have meaning in their intended format. Or you can abuse the fact that humans can't see the difference between a pixel 11111111 and 11111110 so you can use the last bit to encode your data.


Does TLS authentication encrypt username as well as password? I connect to my VPN provider using openVPN.  The server uses a combination of username / password and TLS authentication.

If I am on a public wifi and connecting to my VPN, is my username encrypted?

In other words, could my username be sniffed out?

If I'm reading your question correctly, you're connecting to your VPN using a combination of TLS client authentication and username / password combination.

In this case a MitM attacker can read the full contents of the client certificate (link to the relevant message in the handshake protocol), which may include your username. The attacker can not read the username / password combination because they're sent after the TLS handshake is completed and thereby encrypted.

The mitigation is simple on the protocol level: Don't make a mutually authenticated connection to the server outright, but a unilaterally authenticated one and then let the server initiate a renegotiation with client authentication. This is different, because the conection will be encrypted using the cipher suite from the first connection and so an attacker can't eavesdrop on your client certificate.

If this mitigation isn't possible for whatever reason, you can try and make the two user names unique and distinct. For example you could assign the user a fully random common name in the certificate, which is checked in the internal database / access control list to a) be allowed access and b) match the readable / human-chosen password. This way an attacker can not learn the user name needed for the username / password pair. As far as I can tell, such a setup is possible with OpenVPN.


Cross-domain session standardization I am looking into cross-domain sessions. These are sessions which are shared between two domains like google.com and spotify.com. I'm not looking for information regarding cross-domain sessions between sub-domains since they can be shared by broadening the scope of the cookies that carry the session identifier. play.google.com and mail.google.com can therefor easily share the same session and this session sharing does not require a complex set u redirects and/or ajax calls.

I would like to know if there is a formal standard in setting up such a cross-domain session. It seems as if every framework has it's own mechanism, many of them using redirects, others using JavaScript. As part of research in this domain I am looking for anything that can be seen as a  widely used standard to achieve these cross-domain sessions. Also information regarding informal standards (widely used mechanisms) is highly appreciated.

Edit based on Neil's answer:
I realize now that I have indeed made some mistakes in my reasoning. It is not a cross-domain session that is required for SSO but actually a cross-domain state. Correct my if I'm wrong but, if a server is able to provide a whitelist of domains for which a cookie is valid, SSO would become far simpler without it being a security issue. You would just create a cookie with all the authentication information (uid, roles, idp, etc) and make this cookie shared between all domains you want to include in the SSO sope. You need to build in a mechanism that checks with the other domains in the whitelist, if they allow the first domain to set cookies for this domain.

I'm a bit confused about your vernacular. But I'll try.

I believe you are using the word "session" to refer to single sign-on (SSO). This is functionality that allows you to sign into one site and have that sign-on propagated to other sites without requiring re-authentication. There are several standards for this. They include OAuth1, SAML, and OpenID Connect.

SSO is not the same thing as a shared session. A shared session implies some shared state beyond authentication while SSO only affects authentication. Sharing state across multiple websites tends to be difficult due to security features in the browser, the same-origin policy probably being the biggest. Features like supercookies and Flash cookies are sometimes used to implement shared sessions, but they tend to be very limited in functionality due to the browser's security protections.

Regarding the example you gave of Google and Spotify, they do not share a session. Instead, they use OAuth to allow a Google login to be used to create a new Spotify account. Once created, the accounts are disconnected. For example, logging out of one service will not log you out of the other one.

1Technically, OAuth is an authorization protocol, but it frequently looks like an SSO.


Automating tests for XSS in bash? The book:"Web Security Testing Cookbook
 By Paco Hope, Ben Walther" is the only source I could find which covers the topic. They use cURL. I just want to write some scripts to automate testing for xss. I'm just gonna run it on a site like demo.testfire.net for example.  I know there are allot of tools available for the job though but that won't teach me anything. Thanks.
If someone could perhaps post a one-liner example of testing with cURL. I don't really get how the example in the book works, besides that it assumes that if you get a popup then you won't get any errors for example an error that says:"Characters not allowed or 404 error."

Anyways my real question is what is a good way of automating tests for xss? Would be cool if someone could suggest a way of doing it in bash. Perhaps commandlinefu would be a better place to ask but I thought I'd start here. (Without using tools made specifically for the purpose.)

Why in Bash?  I guess technically you could use curl to post data and then see if the data gets echoed back to you without being escaped... but really, why limit yourself to bash?

Take a look at "Gray Hat Python", "Coding for Penetration Testers: Building Better Tools", or "Violent Python: A Cookbook for Hackers, Forensic Analysts, Penetration Testers and Security Engineers" for Python examples that do this.

See also: https://www.owasp.org/index.php/Testing_for_Cross_site_scripting


Is an XSS attack possible under these constraints? The output is:
<img src="http://example.com/[input]" oncontextmenu="openUrl('http://example.com/[input]')">
Where [input] is the user input, which is sanitised through this function:
a => {
  a = String(a);
  a = this.replaceAll(a, "&", "&amp;");
  a = this.replaceAll(a, '"', "&quot;");
  a = this.replaceAll(a, "'", "&#39;");
  a = this.replaceAll(a, "<", "&lt;");
  return a = this.replaceAll(a, ">", "&gt;")
}

in other words, we seemingly can't break out or use quotes of any kind?
Is an XSS attack possible at all under these constraints? Or is it possible to redirect the user to any domain besides example.com? Or indeed, load an image from (or make a request to) evil.com? Thanks!

Yes, XSS is possible.
The first injection into src is secure, as " is HTML encoded, which is a proper defense against XSS in a HTML attribute value context.
The second injection however is insecure, as it takes place in a JavaScript attribute context. Here, HTML encoding is not a proper defense and XSS can be achieved by injecting ');alert('1, which would give you (I replaced the undefined openUrl function for a self-contained POC):
<img src="http://example.com/[input]" oncontextmenu="console.log('http://example.com/&#39;);alert(&#39;1')">

While this may look secure at first sight, it is not. Right-clicking on the image will execute the payload. This is the case because the HTML parser first decodes the HTML-encoded &#39; before passing it to the JavaScript interpreter.
The proper solution here is a bit tricky. You do need the HTML encoding for ", but you also need to backslash-escape ' (either in its HTML-encoded or basic form). \ will also need to be escaped.


Webrtc privacy issues? I've been reading about WebRTC, and I'm interested in using it for a drawing web application that uses real-time collaboration. However, as I understand, WebRTC communication requires all parties involved to know each other's IP address.

If one of the users had a small following on social media and decided to collaborate with strangers, would there be a danger of them being targeted by a stalker and located? Or am I worrying too much about this?

Yes, for sure:  WebRTC    relies on JavaScript that can leak your actual IP address even from behind your VPN.

The members involved in the peer-to-peer communication using this protocol can not see each other's IP but there are two cases where this is possible: you as te owner of the web application, and an attacker who compromises your website.

There are alternatives for using WebRTC and preventing, in the same time, such leaks. For exampple Google Chrome offers WebRTC Leak Prevent extension for this purpose.


List wireless stations around me I'm looking to find a specific wireless user around me, I have his MAC address, I even have the channel he is on.

I've tried iwlist peers, to no avail, as well as airodump. I have seen his mac pop up under airodump, but it is quickly buried under all the noise...

A little info on the environment: it is a heavily,heavily saturated WiFi area, upon opening airodump-ng the list becomes full of APs too quickly to see any clients. What I need is either a way to grep airodump for clients only / or another utility to view only clients (stations) around me, and their power output (so I can tell when I am close to the person).

Any suggestions?

The solution for grepping airodump for specific mac:

airodump-ng mon0 2>&1 | grep "de:ad:be:ef:de:ad"

Thanks Kolanich. airodump prints to stderr, which had to be redirected to stdout to be greppable.


Is it possible to brute-force the original message of SHA-256 given the size of original string? Given the SHA-256 hash, the size and the encoding of the original string, is it possible to recover the string via brute force? How many string of a given size will result in the same hash?

Given the original length L of the string, you could consider that the effort to retrieve it is 92 power L (92 is 26 lowercase + 26 uppercase + 10 digits + 30 punctuation) instead of 2 power 256.
So if your string is more than 39 chars long, knowing the lenght gives no help.
EDIT: we should consider that an opponent which tries to recover the original string will not actually bruteforce each character. He will bruteforce words.
Except if the string contains a random password, an unknown lastname or something else which is not in a dictionnary, this is the best approach.
With an upper bound of 1,022,000 words and a lower bounds of 171,476 words (words currently used) the order of magnitude can be calculated by 1000000 power N (N is the number of words in the string).
So if the sentence is less than 13 words long, it could be broken before the hash.
However, we have to consider that all the words permutations are not relevant. the opponent could use a smart approach in the building of the candidates to avoid meaningless sentences (for example testing "the" after another "the" could be avoid, testing "than" after "most" makes no sense too).
Following this approach, knowing the number of characters of the string is helpful for the opponent because it will exclude many candidates.
But I'm not sure that the time spent to test the length and the meaningfulness of the sentence is not bigger than just hash it and compare it.


Whatsapp analysis on Wireshark I have been asked to do a paper on Whatsapp for Networks (college class). As far as I know, it is based on XMPP. But I can't find any of its packages on the WireShark process (using whatsapp web), only TCP protocols.

I have downloaded the Packet Tracer for Android and it has given me some TCP packages on hex.

How can I analyze it? Is it XMPP? Is it TCP? How can I have the ACK or the SYN ACK bits on the tracer? what about the RTT?

Is there any better program for this analysis?

You won't see anything relevant in Wireshark because the communications between WhatsApp users happen using private and public keys. Here's how it works in practice:

A wants to send a message to B.
A firstly asks B for his public key (every user generates around 100 public keys attached to one single private key).
A then encrypts the message using B's public key and sends it.
B recieves it and, using his private key, decrypts it.

So, without breaking this scheme, you won't be able to read those packet's data.

In case you are just analyzing TCP, you will be able to see the handshake as usual with it's ACKs, FINs, etc.


Company does not want any names on phishing reports We have been recently contracted to run phishing tests for a company. Let's call it a company but basically they are obligated, by law, to assess the security of their environment with phishing campaigns.

We ran our first campaigns not too long ago and the results were pretty bad. Over 70% of their users trusted the "malicious emails" we sent and did whatever the email asked of them.

After it was over, we of course had a out brief detailing our findings. Long story short, they did not want ~any~ Identifiers (email, username, whatever) of who fell for the phish. They wanted "X out of 300" failed to identify the email. Their reason was they did not want to offend anyone. (I wanted to say your customers feelings will be hurt when your employees fall for a potential attack and leak info) I politely accused them of checking a box and not actually being interested in educating their users. They weren't very happy. I should elaborate by saying they didn't even want 2 reports, one showing the emails and another not showing them. I offered it to them because at least they can see how these individual people react to different campaigns overtime. This would absolutely help if user "Sam" clicks on every single link in a email every time over the course of ten campaigns. Surely you would want to educate Sam differently than other users?

My question is, does this not defeat the purpose of phishing campaigns and improving the security of information in your network? Is this even normal?

This initial campaign established a baseline first.  So, yes, it's normal.  "How do we as a company stand?  To what level do we need to train?  Do we have, as a whole, secure users or do we have, as a whole, unsecure users?"  This report establishes this and the extent to which management needs to engage in phishing training.  Were only 5% of users to fall for the phish attempt, then the training focus would be very different. As it stands, now management knows that they have, essentially, a corporate-wide problem and that a phish campaign basically stands a 70% chance of succeeding.

Now, when the company does future phishing training, they can compare results and determine whether the training was successful.  "We initially fell for it 70% of the time.  This time, we fell for it 68% of the time.  It was therefore, not successful." Or "We initially fell for it 70% of the time and now fell for it 50% of the time.  We're doing better, but need further training."


Does using GUIDs for IDs make IDs unpredictable? Say I have a website that stores credit card information and on that site I have a page where users can edit/delete their credit card information.

For the sake of the example lets say the HTML looks like this:

   xxxx-xxxx-xxxx-1234
   Delete

and that clicking on the Delete text would make a call to delete the credit card with the id in data-ccid.

Is it safe to assume that it would be impossible for someone to predict another credit card ID in the system and fire off a call to delete a card other than their own?

Let's go with the assumption you are using tokenization/encryption techniques sufficient to meet PCI DSS.

No we are looking at an abstract problem of can someone predict a value. The risk factor is that if the value can be guessed or follows a known pattern, one could then delete at will.

The issue of the GUID is irrelevant, because the attack vector is still a brute force attack. While knowing the pattern or algorithms used to create your unique id can certainly help reduce the possibilities to more of a dictionary-bounded attack, the knowledge of the ids ahead of time is not necessary to delete records indiscriminately.

You address the problem by implementing additional controls. First, if this is in a database, you have sufficient logging and transactions in place.

On the way to perform the deletion, there should be additional controls in place. Let's start for the user side: If the record is associated with the user, only the user should have the ability to delete his/her own records. If the user is not authenticated or does not own the records, do not allow the deletion procedure to continue forward. Does the user need to provide a special authorization? Is another variable set in the database or in a the session to allow the deletion (e.g., they need to authorize before the action goes throught?) If there is a sufficient risk, you can implement an out of band confirmation, such as sending a SMS message or maybe a confirmation via email is acceptable. In this scenario, its probably low risk if a user knowingly deletes their own credit card records because they can enter it in again later.

If you have strong authentication, authorization, and transaction controls it will limit the ability to indiscriminately delete values, even if they are known.

As an additional precaution, you may wish to implement heuristics and attack detection algorithms. For example, limit the number of deletions from the same IP address per day. Roll back transactions if there are too many deletions in a given day considering normal deletion patterns, etc.

It sounds from your description a simple POST command is being performed, I would ensure this only happens if there is TLS/SSL, the user is authenticated, there is a CSRF token in the request, etc. I would ensure that all deletes are logged and can be rolled back. Since the deletion would not result in exposure, you can also rely on a post-action notification to the users, "We Confirm you have deleted your credit card on file. If you did not do this, please contact us immediately" etc.


How critical is it to keep your password length secret? Is keeping your password length secret critical to security?

Does someone knowing that you have a password length of say 17 make the password drastically easier to brute force?

Well, let's start with math: If we assume that your password consists of lowers, uppers, and numbers, that's 62 characters to choose from (just to keep the math easy, real passwords use symbols too). A password of length 1 has 62 possibilities, a password of length 2 has 62^2 possibilities, ..., a password of length n has 62^n possibilities.

So that means that if they know your password has exactly 17 characters, then they can skip all the passwords with length less than 17, and there are only 62^17 passwords to try.

But how many passwords are there with length less than 17, compared to 62^17?

Well, if we add up 62^n and divide by 62^17 we get (sum from n=1 to n=16 of 62^n ) / 62^17 = 0.016 (link to calculation), so checking only passwords of length 17 is only 1.6% faster than checking all passwords up to length 17

If we have a password scheme which allows all 95 printable ASCII characters, then the savings from not having to try passwords shorter than 17 drops to 1.06%
 (link to calculation).

An interesting mathematical quirk about this ratio of the number of passwords shorter than n, over the number of passwords of length n, is that it doesn't really depend on n. This is because we're already very close to the asymptote of 1/95 = 0.0105. So an attacker gets the same relative, or percentage, time savings from this trick regardless of the length of your password; it's always between 1% - 2%. Though, of course, the absolute time that it takes grows orders of magnitude with each new character that you add.

The maths above assume a simple brute-forcer which will try a, b, c, ..., aa, ab, ... Which is a good(ish) model for cracking properly-random computer-generated passwords, but is a terrible model for guessing human-generated passwords.

Real password crackers are dictionary-based, trying words (and combinations of words) from the English dictionary, lists of leaked passwords, etc, so those calculations should be taken with a grain of salt.

Another effect of knowing your length is that they don't have to try any passwords longer than 17, which for brute-forcing algorithms that try combinations of dictionary words, could actually be a huge savings.

As mentioned by @SteveSether, @xeon, and @CountIblis, disclosing the length (or entropy) of a password can also effect whether an attacker even attempts to crack your password by deterring them away from strong passwords and instead attracting them to weak ones. So if you know you have a strong password, then disclose away! However, disclosing the password lengths (or entropies) for all users in a system has the effect of making strong passwords stronger, and weak passwords weaker.

Bottom Line:

Telling someone the length of your password isn't the worst thing you can do, but I still wouldn't do it.


Malware From from external drive How do malware start from external drives?
Especially on Windows (from > Windows 7) commands like Open=Example.exe on an autorun.inf file have been defaulted disabled to not allow auto run when an USB is instantly plugged in.

So how come I see hackers achieve such abilities to spread hidden malware through USB's to the next computer?

Most of the infections come from computers where security is poorly managed so the autorun feature isn't disabled.

Moreover, USB devices are inherently insecure as their firwmare can be rewritten for malicious intent.
From SRLabs BadUSB:

  Reprogramming USB peripherals: To turn one device type into another,
  USB controller chips in peripherals need to be reprogrammed. Very
  widely spread USB controller chips, including those in thumb drives,
  have no protection from such reprogramming.

  (...) Once reprogrammed, benign devices can
  turn malicious in many ways, including:

  1) A device can emulate a keyboard and issue commands on behalf of the logged-in user, for example to exfiltrate files or install
  malware. Such malware, in turn, can infect the controller chips of
  other USB devices connected to the computer.

  2) The device can also spoof a network card and change the computer’s DNS setting to redirect traffic.

  3) A modified thumb drive or external hard disk can – when it detects that the computer is starting up – boot a small virus, which infects
  the computer’s operating system prior to boot.

  Defenses? No effective defenses from USB attacks are known. Malware
  scanners cannot access the firmware running on USB devices. Behavioral
  detection is difficult since behavior of an infected device may look
  as though a user has simply plugged in a new device. Blocking or
  allowing specific USB device classes and device IDs is possible,
  however generic lists can easily be bypassed. Pre-boot attacks may be
  prevented by use of a BIOS password and booting only to the hard
  drive.

  To make matters worse, cleanup after an incident is hard: Simply
  reinstalling the operating system – the standard response to otherwise
  ineradicable malware – does not address BadUSB infections at their
  root. The USB thumb drive, from which the operating system is
  reinstalled, may already be infected, as may the hardwired webcam or
  other USB components inside the computer. A BadUSB device may even
  have replaced the computer’s BIOS – again by emulating a keyboard and
  unlocking a hidden file on the USB thumb drive.

  Once infected, computers and their USB peripherals can never be
  trusted again.


Requesting administrative access in a company I have been given the task of defining a process for assigning administrative access. One of the requirements for this processs is that if a subject wishes to gain adminstrative access, only the subject's manager can make the request for the client. Both the VPs of IT and Security must approve the request. How does this entire process work in general, and why? I always thought that if you required administrative access, you would probably be an administrator yourself, which would not be a problem since you already have an administrator account.

This is probably not the answer you'd expected, but bear in mind that whatever solution you come up with must work for all stakeholders, including the employees who are requesting access.

Who are these employees? What do they need access to? Typically, what for? You should probably talk to your colleagues and ask them, in fact. For instance, what do you do if:

the authorized person goes on annual leave and a colleague needs temporary access to the system to continue providing service to clients?
the manager in charge of validating authorisation requests goes sick, missing or is just generally slow?
the IT people in charge of reviewing and revoking permissions don't know why a person had a permission in the first place?

Some hints on these typical organisational security questions in the excellent "How Users Bypass Access Control and Why: The Impact of Authorization Problems on Individuals and the Organization" paper!


Statistics on purposes of viruses/malware Are there any resources that analyze the purpose or goal or the major viruses/malware out in the wild today? For example, what percentage are used to construct botnets (for DDoS or something else)? For sending spam? For keylogging and collecting passwords or financial information? For destroying information on the machine? etc.

It's unlikely to find open resources that will give you this information in the format you are looking for.

However, you may be able to mine that information out of annual reports published by major Antivirus vendors like Microsoft, Symantec, etc. As an example, Microsoft publishes all its findings in its Security Intelligence Reports every 6 months which is a pretty comprehensive report of all malwares discovered in the wild.


How does adding a random serial number improve a certificate's security? This article says:

  "Finding collisions is a tricky process, since it requires you to muck
  with the bits of the public key embedded in the certificate (see this
  paper for more details). Also, Microsoft could have prevented this
  somewhat by adding a random serial number to the cert, which they
  didn't do."

My question is how does adding a random value to a certificate improve security?  Couldn't the attacker simply generate a serial number to create a MD5 collision?

Update:

Here is information on how Microsoft implements randomization in a CA key.  I'm not sure of the benefits and drawbacks of each.

  Configure Serial Number Generation

  In a Windows 2000 CA, two types of fixed-length serial numbers are
  generated. The registry can be modified to generate one or the other
  type. The default serial number is (from high to low): a DWORD from
  GetTickCount() + a USHORT CA cert index (0 to start) + a DWORD
  RequestId (10 bytes/20 hexadecimal digits). The alternate form is: one
  byte derived from the registry + a DWORD RequestId + 8 bytes of
  CryptGenRandom output + a USHORT CA cert index + a DWORD RequestId (19
  bytes/38 hexadecimal digits).

  To enable the alternate form and set the byte derived from the
  registry, use the following command:

    certutil –setreg ca\HighSerial 0x33

  The byte value specified will be modified to clear the sign bit and to
  set a bit in the high nibble to work around serial number encoding
  ambiguity bugs in certain non-Microsoft PKI applications.

  In a Windows Server 2003 CA, three types of fixed-length serial
  numbers are generated. The default and alternate forms are the same as
  in Windows 2000. The Windows 2000 alternate form uses a new random 8
  bytes generated by CryptGenRandom for each serial number. The new
  alternate form for Windows Server 2003 uses a fixed random 8 bytes
  from CryptGenRandom, generated during the first attempt to issue a
  certificate, and saved in the registry as 8 bytes of fixed
  CryptGenRandom output + a USHORT CA cert index + a DWORD RequestId (14
  bytes/28 hexadecimal digits).

  To enable the new alternate form in the registry, use the following
  command:

   certutil –setreg ca\HighSerial 0xffffffff

  Since the fixed random 8 bytes from CryptGenRandom are encoded as a
  string and saved in the registry, you could set them directly and
  cause them to be used for new serial numbers. In fact, any length
  hexadecimal string could be set in the registry (but there must be an
  even number of digits). The number of bytes used from the registry
  will be reduced if it would overflow a total of 19 bytes for the
  serial number. The high byte is manipulated as described previously to
  avoid problems with certain non-Microsoft applications. The IETF
  standards specify a maximum of 20 byte serial numbers.

Short answer. The benefit is from an unpredictable serial number, not from any old serial number.

Indeed, a sequential serial number adds no security, as it is easily predictable.  But randomizing the serial number (so it is hard to predict) does make it harder to exploit the known collision attacks on MD5 to get a forged certificate.  Let me explain.

Background. When a CA issues a cert, it includes a signature on MD5(P), for some certificate payload P that includes a public key, a domain name, and a serial number.  The known collision attacks on MD5 allow the attacker to choose two values P and Q that have the same MD5 hash.  This can be used to attack CAs that use MD5, as follows.  The attacker uses the MD5 collision attacks to find P,Q with the following property: P is a benign certificate payload that the CA would willingly sign (e.g., a cert for some new domain that the attacker controls), but Q is an evil certificate payload that the CA would never sign (e.g., a cert for microsoft.com).  The attacker sends a cert request corresponding to P to the CA; the CA signs it and returns the signed cert; and then the signature on this cert will also be a valid signature on Q.

Note that this attack requires the attacker to predict the value of the serial number that'll be used when the CA signs the cert for P.  If serial numbers are assigned sequentially, this prediction task is easy.  But if serial numbers are (say) a cryptographically-random 128-bit number, then the attack no longer applies.  Therefore, some have suggested using random serial numbers as a mitigation.

Further details.  See the following research paper for more details:

Short Chosen-Prefix Collisions for MD5 and the Creation of a Rogue CA Certificate, Marc Stevens and Alexander Sotirov and Jacob Appelbaum and Arjen Lenstra and David Molnar and Dag Arne Osvik and Benne de Weger, CRYPTO 2009.
Website: http://www.win.tue.nl/hashclash/rogue-ca/

Recommendation. The best defense is: don't use MD5!  Just stop using it.  CAs should use a modern hash like SHA1 or SHA256 or SHA2.  They should never use MD5 when issuing certs.

But if for some reason you are forced to use MD5, randomizing your serial numbers is a reasonable mitigation.  Actually, using a random serial number might not be a bad idea, no matter what hash algorithm you use, as a form of belt-and-suspenders defense-in-depth.


Which systems in a network are able to spoof a TCP handshake? I am reviewing for my final exam tomorrow, I came across a past exam question.

An attacker wants to initiate a TCP handshake with a target to make him think E initiated it, attacker knows IP address of E

(B, C, D, R), which ones can attack if the target is A?

(A, B, D, R), which ones can attack if target is C?

(A, B, C, and R), which ones can attack if target is D?

Am pretty much stuck on how to go about this, I would assume A, B, C, and R would be able to attack themselves since they are on the same network. But E seems to be too important, I don't really know why.

(B, C, D, R), which ones can attack if the target is A?

B and R.

Both B and R can spoof the IP address of E and can see the SYN-ACK reply packet from A to get the sequence number for the final ACK.

C cannot because the ACK will be sent via R that will route the packet out onto the internet.

D cannot because it will not see the SYN-ACKs over the internet.

  (A, B, D, R), which ones can attack if target is C?

R.

R has visibility of all packets on the network, so can view the SYN-ACK and sequence number.

A and B will only be able to view packets for 192.168.150.0/25, packets destined for C will be sent over the 192.168.150.128/25 network only.

D cannot because it will not see the SYN-ACKs over the internet.

  (A, B, C, and R), which ones can attack if target is D?

None. They will not have visibility of the SYN-ACK to get the sequence number.


Kerberos replay attack Suppose I want to send a command to a print server on a netwerk that has been secured with Kerberos. To do so, I authenticate myself to the KDC and get a TGT, and then another ticket from the TGS for the print server. I then authenticate myself to the print server and I can then send it a print command, signed with the session key. But suppose someone is listening on the network and sniffs the command I sent it, what prevents him from replaying it to the print server and thus being able to print the same file I just printed during the same session (so same session key)? A solution would be to get a new ticket (and thus new session key) from the TGS for every command you send to the print server but I don’t think this is required in the Kerberos protocol?

This is stopped by authenticators. Whenever you present a Kerberos ticket, it must be accompanied by an authenticator, which is encrypted using the session key and contains (among other info) a timestamp. The server checks that the timestamp is recent (in Kerberos 4, this means "within 5 minutes;" in 5, it is configurable, but 5 minutes is the default) and that it has never seen that authenticator before. The authenticator just relies on the session key, so can be generated by the client; a new authenticator is created every time you send a ticket.

To answer "what if they're using the same session," the basic Kerberos protocol doesn't handle it. Kerberos, at its core, authenticates the user opening a connection; it does not have to do anything more. Application protocols are responsible for handling protection of further messages if that's important; Kerberos provides two ways to do so, or can supply data from the authentication to whatever system the application protocol uses, but an application protocol need not use Kerberos at all other than for initial authentication. Everything after that depends on the application protocol.

Kerberos has two options for Kerberos-protected communication beyond the initial message (one authenticates, one encrypts and authenticates); an application protocol may use them to protect later communication, but does not have to. Both of these use a timestamp and/or a sequence number to prevent replays; the sequence number protects against dropped messages and message reordering, while the timestamp is forgiving if that's not a concern (but prevents an attacker from just delaying a message, as a delayed message will be rejected), but both prevent replays.

If you are concerned about a malicious user tampering with the data stream to the print server, you can define the print server protocol to use KRB_SAFE or KRB_PRIV (respectively, "authenticate only" or "encrypt and authenticate"); both protect against replays. Or you can use some other system that takes a sub-session key from the authenticator as a pre-shared key and has replay protection; a TLS-PSK protocol with the sub-session key as PSK would probably work (TLS protects against replay attacks). The point is, Kerberos does not inherently protect against that sort of replay, because it says nothing about how to do the rest of the communication; to protect against attacks on the communication post-authentication, you need to either use Kerberos's KRB_SAFE or KRB_PRIV or use something else that protects that communication.


Does Nextcloud installation gives passwordless access to all files by default? I used this guide to install Nextcloud instance on a Raspberry Pi. The installation went smoothly and in the end I could open the Nextcloud login page which, once presented with the right password, gives access to various resources which I assumed were therefore password-protected. That is, until I tried to log out and type https://server/nextcloud/data/user/files/, which, to my surprise, showed a directory listing of Nextcloud files belonging to user, without requiring a password at all!

Is Nextcloud really missing any data protection whatsoever in its right-out-of-the-box state, or did I miss something obvious?

The problem isn't with Nextcloud, but rather with the random guy's installation guide that you chose to follow. Had you followed Nextcloud's official one instead, then that attack wouldn't work. The problem is that Nextcloud uses a .htaccess file to protect that directory, and the random unofficial installation guide didn't bother to tell you that you needed to enable .htaccess files in Apache's config (AllowOverride). This mistake is common enough that under "Security & setup warnings" under Administration -> Overview, it will self-test and warn you about it if it detects it.

Further, following Nextcloud's hardening and security guidance would also stop this, as they recommend that you set the data directory to be somewhere that's not under the document root.


How an ISP can detect if someone having a WhatsApp call or video call? without detecting or blocking the rest of the app I am asking the questions because of the latest news: https://www.bbc.com/news/world-middle-east-50095448

I wonder how the ISP can detect the use of call and video calls, without detecting or blocking the rest of the app?

ISPs in general can detect VoIP connections because these network flows in general have specific network metrics such as , constant rate, a relationship between up stream and downstream and some more. However, some applications such Skype the embed all encrypted traffic on one network flow, make impossible to know how many messages has been sent. In the case of whatsappp you can take some samples and analyze but I suspect that works in a similar way as skype.


404s with /like and /undefined We recently got hacked and after cleaning the virus from our machine we pushed out site to go through cloudflare. Although I've noticed scanning attempts on the site have dropped we do for some reason get hundreds of 404s to oursite.com/undefined or oursite.com/like

When there is a 404 i get an email with browser type/ip address/cookie information etc and it's always different, except that the IPs are on the same subnet or the same.

Any ideas as to what they are trying to accomplish. I've for now created a physical directory called undefined, but still a little worried

Attackers need to identify what applications are hosted on your domain. They can identify them by scanning for common files and directory structures on your platform. For example, if you run Wordpress, an attacker can look for /wp-admin, and if it returns a 200, they know you are running Wordpress.

Once they know what framework or application you are running, they will start to navigate through known vulnerabilities, or even a 0day, until they are able to compromise your platform.

Now, keep that in mind because CloudFlare simply serves as a ReverseProxy to help protect you. This means, that the incoming requests to your server will be sourced from CloudFlare, not the attacker.

Think of it this way:

[Attacker] -----> [  YourSite  ]
                  [ CloudFlare ]   ----->    [Your Server Request]
                  [ CloudFlare ]   <-----    [Your Server Response]
[Attacker] <----  [  YourSite  ]

CloudFlare looks like your physical server to the attackers. They perform queries, gets, posts, etc to your domain. CloudFlare receives the request first, and then performs some inspection on the request and forwards it to your physical server.

So when you see the requests coming in from CloudFlare, it's because they are serving as a reverse proxy. The /like and /undefined could still be an attacker trying to identify known vulnerabilities on your site.


What are the basic certification course for beginners? I am an application developer in MNC with 2 year experience. What are the basic certification or course should I do what can help myself to shift in security field?

My employer required CompTIA's Security+ certification for entry-level positions.
It will give you the basics. Despite criticism for its form (multiple-choice answers), by actually doing the course and studying on areas where you lack knowledge, you will get a decent start about security. After that it may become a matter of choosing where you want to go next such as malware analysis, penetration testing, intrusion analysis, forensics, etc.

So start with Security+. It's the most basic and possibly the most common entry level certification.


Password creation characters Why do some apps/sites require you to use or not use certain characters when creating a password.

For instance below are JetBlue's requirements.

Your password must be 8 – 20 characters long. Only alphanumerical characters, spaces, dashes and underscores are allowed.

Both the use/restriction of special characters in passwords is related to improving different aspects of security.

When a site requires you to use passwords with certain minimum length or include atleast one numeric character, special character and so on. They want to force the user to create a strong password that is less susceptible to brute force attacks (i.e.. 12345 is not gonna fly).

Similarly, restricting certain characters/length can be considered a (weak) defense mechanism against attacks like SQL injection. Although keep in mind that front end restrictions can be easily bypassed by an attacker. In addition, websites may place restriction on certain character (like whitespaces) depending on how they parse/process passowrds.
In general, limiting passwords is in itself not a good idea.


Why doesn't the HTTP/2 spec require TLS? Although no browser implements the full HTTP/2 spec right now limiting themselves to just the TLS part there are stories on the internet that this incomplete implementation of the spec is a way of resisting against the 'evil' lobbying of mobile service providers which want to inject ads and shape traffic. Now, I of course understand that analyzing, shaping and even altering traffic is possible on unsecured connections, but is it actually true that the lack of consensus on required TLS was caused by the lobbying of internet service providers? And secondary, is there reason to believe that if that's the case, that this was for the claimed reasons primarily.

There is no technical reason to limit HTTP/2 to TLS. Communication without TLS has its technical use, no matter if this is unencrypted traffic or if the traffic is encrypted by other means (VPN etc).

Restricting HTTP/2 to TLS in the standard would bind the use of the HTTP/2 protocol to the use of TLS for political(*) reasons only. Such bindings for non-technical reasons are usually avoided: If you look for example at the RFC for HTTP/1.1 they explicitly keep the transport layer open, i.e. acknowledge that HTTP/1.1 is usually used on top of TCP/IP but might be used on top of other protocols (RFC2616, section 1.4).

Thus while one might think that there was some evil lobbying I think that simply the majority found that standards should be a place for technical details but not  for political(*) statements.

An interesting mailing thread in this context is Mandatory encryption is theater on the IETF HTTP WG mailing list in 2013 which highlights the diversity of opinions among the technical users. And is also visible from this thread that this is not a lobbying from some ISP or similar but that there are technical reasons to not bind HTTP/2 too much to TLS, because TLS is known to be not the optimal solution for the diversity of authentication, encryption and privacy problems: in some cases you want to have better protection than TLS can offer and in other cases you don't need the protection but the overhead of TLS is bothering you.

(*) To make more clear what I consider political: It's less geo-politics or company-politics but mostly personal opinions influenced by these larger politics. This leads to arguments based on the personal view of how the world should work and not based on technical reasons. Sometimes this political arguments are even blind to technical arguments because they don't fit into the  personal view of the world. This includes the argumentation that all use cases require privacy (which TLS does not offer fully anyway), that small systems without large resources should just grow up or not use HTTP, that caching is an unimportant thing which does not need to be considered (i.e. we have lots of bandwidth and don't care if others don't) etc.


Assessing security tradeoffs with LineageOS on older Android phones In setting up an Sony Xperia ZR smartphone manufactured in 2013 and running Android 4.4.1, I am working on understanding the trade-offs involved in loading the custom ROM LineageOS 14.1, which is based on the AOSP version 7.1.1.

The phone is too old to receive regular security updates from the manufacturer. LineageOS users have weekly updates pushed and have access to nightly builds. The LineageOS maintainers seem like they are fast to address security issues. However, in order to install a custom ROM, I need to unlock the bootloader, which can be achieved with a code available from the manufacturer. I read that unlocking can open the phone up to some security vulnerabilities, but the best information I've been able to find are that:

"a tech-savvy thief could fully wipe your device with this option enabled, which means you would no longer be able to track the device's location using Android Device Manager"

and that an unlocked bootloader could allow the loading of software not approved by a mobile carrier, which could be malicious.

In what contexts/situations would leaving the phone as is provide better security? In what contexts/situations would installing LineageOS provide better security?

You have essentially the following options:

Throwing the phone away or keeping it off the networks (which makes it useless for many users) since the OS has known security issues but there are no more security updates for it.
Accepting the risk of running a phone with known security issues, which depending on the issues might be exploited just by surfing the internet or receiving a MMS or simply by having WiFi active. Note that such exploits can very deeply infiltrate the system since many of the exploits allow to run code with root or even kernel permissions.
Unlocking the bootloader and installing an up-to-date alternative OS and accepting the risk of having an unlocked bootloader. This risk of having the bootloader unlocked can be an issue if somebody else gets physical access to the device for some time or if a serious OS exploit with root or kernel level access is possible. The last risk is hopefully mitigated mostly by having an up-to-date OS.

None of these options is without some risk or at least serious usability or cost issues.  But in my opinion the last option of unlocking the bootloader and installing an up-to-date OS (and keeping it updated) is far less risky then the second option of running an OS with known and serious security issues.


How to exploit vulnerabilities found from OpenVAS? I could not find any match for the vulnerabilities with their CVE numbers found from OpenVAS scanner with exploits using sites such as Rapid 7 Vulnerability DB and Exploit DB, or by using a command like 'search cve-xxxx-xxxx'. Do you have any suggestions/commands for msfconsole or other ideas for finding matching exploits?

You can search within metasploit using the search command for example :

msf>search ms08-067

you can also search by the name of the program that has a vulnerability using:

msf>search name:windows

http://www.offensive-security.com/metasploit-unleashed/Msfconsole_Commands#search


Bypassing closed or filtered ports I recently setup a basic Ubuntu Server at my home and while at school can't access it because the SSH port (22) has been closed. This lead me open up different ports on my server for SSH so that I could access via an open port at my school. I ended up opening port 21 typically for FTP because I did a network scan and found it was open on the school network. I tested SSH from my home network onto the server using port 21 and was successful but upon attempting it at school I was unsuccessful. My question is why was it unsuccessful? And what can be done to fix it?

I am aware that I shouldn't be trying to circumvent there blocks but I am really curious on why it isn't working.

Yo're assuming the problem is at the school, but you may be wrong; the problem may be at your ISP or your router. Have you done a portscan on your public IP address using an online portscanner? Does it report port 21 at your public IP as open?

It sounds like you set up a server at home. So to reach it from school, you must pass the schools firewall, the ISPs firewall and the firewall installed on your home router. Outgoing firewalls are usually configured to allow traffic to common services such as ftp, so while possible, its unlikely that your school would deny an outgoing ftp connection.

Incoming connection attempts are a different story. ISPs often configure their firewalls to block common ports to protect their clients' home networks from attacks. The same goes for your home router.

Even if port 21 on your public IP address is accessible from the internet, to reach your server, you must configure your router to forward connections to port 21 to the server machine. If you don't do that, you try to reach your router's ftp port, which will be closed or filtered.

Your server is reachable from home because it sits in the same network, so there are no firewalls to pass through which could block traffic.


How can I encrypt a file with .NET and have the same file size of the original file? I'm using .NET and I've written an awesome routine (xD) that encrypts and decrypts a file using AES256 CBC. It works perfectly, but now they told me that the encrypted file must be of the same size of the decrypted one. (There is a problem with some other API's, not my fault, I swear.)

So, I've tried everything that I can find, but nothing works.
The .NET Framework has a CipherMode.CTS that looks exactly like what I need, but unfortunately it is not currently supported.

I tried to set the padding to none, but of course I've got errors because the block size is less than what it's supposed to be.

Ideas?

Edit:
I've managed to solve this problem in 2 ways:

With .NET API
    SymmetricAlgorithm alg = new RijndaelManaged();
    alg.Mode = CipherMode.CFB;
    alg.Padding = PaddingMode.None;
    alg.FeedbackSize = 8;

With BouncyCastle API's
IBufferedCipher cipher = new CtsBlockCipher(new CbcBlockCipher(new AesFastEngine()));

Hope this can help others with the same problem :)

Even if you use CTS, you still need an initialization vector (IV) which MUST (I insist, MUST) be generated anew for each file with a cryptographically strong pseudo-random number generator. So you will not be able to fit all of it without increasing the size. This is unavoidable, as long as you use a "normal" block cipher.

Also, if you need encryption, then you most probably need integrity, i.e. a MAC, which, intrinsically, requires a bit of extra space.

What you could try is to compress the file before encrypting it (System.IO.Compression.DeflateStream); this could give you the extra breathing space you need (not in a guaranteed way, but it will work, especially if the file you need to encrypt is an XML file or something like that, with a lot of structure).


How to revoke certificates, or generate CRL files with Keytool I didn't find how to use java keytool to revoke certificates or generate CRL files.

Is it possible to do that with keytool?
If no, how to do it with openssl ?

keytool does not provide the necessary functionality. As for openssl - there are several extensive documentations (like this) which are trivial to find. It makes no sense to replicate everything here again.


On an embedded system with no external input, can haveged provide entropy? Take an example embedded system:

Microprocessor
Flash memory
SDRAM

There is no UI and no network connection.

Can the CPU timing jitter that is used by haveged provide adequate true entropy to seed /dev/urandom?

This will depend on the exact system.

Haveged is highly dependent on the rdtsc instruction. For the vast majority of embedded systems in production today this is going to be extremely difficult (to the point of effective impossibility) to estimate.

With a basic enough stripped out OS (or no OS) on a single core CPU where the execution of every line of code on the device is both predictable and independent of external state then it may be closer to realistically possible.

Although on a device with absolutely no external input (other than power up/down) i'm struggling to see the use case for an CSRNG?


HOTP/similar - how about standard backups of mobile devices? I was considering adding HOTP as an option to my website (alongside things such as SMSed one time tokens which I already have). But I was considering one issue that HOTP inherently has:

Things such as the iPhone usually get backed up along with all app data. That would mean, say I'm using Authy to generate my OTP tokens, the secret keys from within Authy would get included in such backups as well. Well, the entire purpose of OTP is so that information on the computer is not enough to break into an account and you need that second factor just in case something such as malware gets onto the computer (if I understood properly). But this backup means, if I have access to your computer, I can get your password through conventional manners such as a keylogger, but I can also look through your mobile phone backups for the HOTP secret key and without your phone, successfully log in.

So what's keeping people from doing that, and why should I also offer HOTP or is it better for me to still just stick with only SMSed tokens?

Some phones send SMS messages to a computer in realtime when nearby it (Samsung has a little thing for their android phones that does this, or did), and if the phone is plugged into a computer and supporting Hayes modem commands, those can read text messages in realtime too.

Really, what OTPs get you is protection against people guessing passwords, though they are sometimes helpful with stolen ones too.  That said, TOTP would be better for this given that it is ephemeral and thus the chances of getting it right don't increase as the number of attempts do.  The HOTP is really not much better than a password consisting of the key and counter (in my opinion), except that it effectively comes with its own challenge auth for anti-replayability.

If you need to be secure against people stealing the tokens from phone backups or whatever, you really should issue hardware tokens.


Can I test ssl connection locally with a valid certificate (CA) with local dns? I have a wildcard valid certificate signed by Certificate Authority. Is it possible to test the https locally from the server without a registered DNS?

My idea is to bind the domain name with 127.0.0.1 in /etc/hosts.

The HTML is running on Nginx container and I am using centos 7.

Is it possible to make an SSL handshake with curl https://<dnsname>.<name>.com:443 or it needs to be public DNS?

Note: ICMP is disabled but the server is connected to internet

For validating the certificate it is relevant that the domain in the URL matches the certificate. The certificate itself can be provided from any IP address, i.e. it does not have to be the public visible IP address but can also be a local one like 127.0.0.1. The mapping of domain to IP address is usually done by DNS but can also be done with a local hosts file, i.e. /etc/hosts in Linux.


Retrieving CSRF token from third party website form using XHR (JavaScript) I know they say CSRF tokens are the most secure way to prevent CSRF attacks but what if someone uses XHR to retrieve the page containing the csrf token along with the form and then use that token for his attacks?

Why they don't say "Referer" header is the most secure way to prevent CSRF attacks? Afterall nearly 99% of the currently in-use browsers will provide "Referer" header and the attacker cannot change it in anyway. (Yes, he can't, unless the browser/OS itself is compromised)

Now that I protect my website using "referer" header, do I really need csrf tokens? All my important requests are using POST and not GET method.

...  but what if someone uses XHR to retrieve the page containing the csrf token

The capabilities of such a cross-site XHR are restricted by the Same Origin Policy and could be extended by CORS. Without CORS explicitly allowing cross-site reading and also sending of the credentials (session cookie) it would not be possible for an attacker to do an XHR where the attacker can read the response in the first place and where CSRF tokens in the response are associated with an existing user session.

In other words: you will not be able to get useful CSRF tokens through your proposed cross-site XHR unless the server explicitly allows it.


How a professional hacker would penetrate a computer in a network? Which kinds of vulnerabilities or security holes a hacker would use to penetrate and take over a computer in a network, like a normal PC in a default network (Wireless-LAN).

I often hear that the computer of a person got hacked, but it was not a webserver, so the attacker could not exploit a SQL-Injection or a LFI vulnerability or something like that. Is the only option or possibility to hack a computer of a person (not a webserver) with Phishing or Social Engineering (Tronjans, Backdoors end etc.) via email attachments or something like that?

This is an extremely broad question.
When you're learning about security and penetration-testing, you're
supposed to learn all these techniques.
There are loads of techniques each with it's own purpose, situation,...

To give a small answer on your question,
Social engineering is often used, and so are backdoors.
Lastly I had to write a PoC (Proof of concept) for a webshop.
They had a design-flaw and XSS-error, the point is, that I could hack the
computer of each visitor (not user, just visitor); this attack was a mix of:
Website exploitation (XSS & the design flaw), basic social-engineering, exploiting a browser-vulnerability using BeEF & Metasploit, triggering a backdoor (reverse_tcp_meterpreter) on the user's machine.

Like you see, this attack took four to five different things in order to succeed, but at the end, I had control of the user's machine (my own machine of course in this example, it was a PoC).

Other ways to attack a machine on your network, is by seeing if he uses a specific service which has a vulnerability using port-scanning.
On your computer you have specific services running which need to listen to a specific port, most of the time, a port-number is related to that service. (e.g, 80 & 443 are HTTP(S) and thus mostly browsers). You can scan a machine on 'open' ports, if a port is open, you can look the port-number up to see if it matches a specific service. If it does, maybe the victim is using an old version of that service-software and that vulnerability can be exploited through that port.

When software has e.g a buffer overflow-vulnerability, it can be exploited. No matter if the payload is coming from an user-input or from a socket (port).

Than, you also have frameworks like e.g Metasploit who specialise in exploiting systems like Windows. In some cases you can get shell to another user's computer without none or very little user-interaction.
Metasploit relies on vulnerabilities in the system's software like flaws in platforms like Adobe, Java,...
Maybe you also remember that a few years ago a few people took down the Playstation & Xbox-network on Christmas?
They did that with programmatically exploiting a network-vulnerability which allowed them to infect the systems on that network with a backdoor/trojan.

But if you're in the same network itself (e.g, you hacked the Wi-Fi password, or it's a public network,...) you can do things like MiTM-attacks (Man In the Middle, intercepting and manipulating packets) with almost none user interaction, or something similar like network-sniffing.

But getting access to another computersystem without any user-interaction is hard. When you e.g deploy malware to a user, and it's e.g a trojan which needs to communicate to a C&C (Command-and-control server), your trojan needs to bypass the firewall in order to be able to communicate with the outside-world. This can be done with social engineering and than user-interaction is involved (e.g tricking the user on clicking "Accept firewall exception").
If you'd do this without any user-interaction, you'd need to be able to add your firewall exception programmatically (which ain't a problem with the Windows API), but then yet you'd need to privilege escalate to get root access, to actually add the exception.
Privilege escalation without user-interaction or social-engineering would be done by first finding a system-vulnerability which allows that, and than exploiting that vulnerability programmatically.
With luck, you can use already found vulnerabilities and pre-made exploits with e.g Powershell-scripts, to use that as payload, in your actual payload.

As you see, tons of options; but your question is hard to answer because it's too broad, and it differs from situation to situation.


What is a safe way to exit a user's shell? If I change to a potentially compromised user in Unix, for example by using su or sudo -i, then exit with exit, the compromised user could alias exit to something which drops me into a fake shell which has a keylogger. For example, I might:

su to compromised user
exit back to safe user, but it doesn't actually exit
Use sudo to do something as root, but since I'm still in the compromised shell the compromised user could have set up a keylogger
Compromised user has root.

How can I safely leave a shell of a compromised user?

Do not drop to a lesser user using su or sudo from a shell.

While what you propose is a valid risk, there is another, much bigger risk when dropping to a lesser user and then exiting, called the TTY pushback attack, using the TIOCSTI IOCTL. This allows arbitrary data to be sent to the calling shell from the child.

From http://www.halfdog.net/Security/2012/TtyPushbackPrivilegeEscalation/:

  When su -s /bin/bash [user] is called from interactive shell, the input queue data pushed back as the target user will be executed by the interactive shell calling su.


Storing sensitive documents in a password manager Like a lot of people, I use a password manager (Keypass). For convenience I have this stored on Dropbox and is a part of the various backups that I do (Both local and offsite).

I am thinking of storing sensitive documents in this file (i.e. Passport, Drivers License etc) for convenience and [physical] safety but I am a little concerned that if the encryption is hacked and the file gets in the hands of bad people that they can now compromise a whole lot more than just my passwords.

Is the storage of such items on my password manager a good idea? Is there a better way of storing such items so that they are accessible, but more secure than using a password manager alone?

Keepass uses state of the art encryption and is considered safe now. The same holds true for alternatives for encrypting files in a public cloud drive, like a Veracrypt container or a stacked filesystem (like gocryptfs or cryptomator).

But (there is always a "but"), if you put anything encrypted into someone else's hands, he can run an offline attack against it, which is the easiest way of attacking, since no rate limiting can be applied. He can run this attack right now (which will probably only successful if you picked a weak password), or he can run it at any point in the future (when the algorithms used have been compromised).

So, if you picked a really good password and the documents you are storing are only short term (like an Id which expires every few years) and can not be exploited after their expiration (a credit card number usually stays the same on the next card, for instance) then it is probably safe to store such thing encrypted online, otherwise not.

Generally speaking, you should always ask yourself the question. "Do I really need to put this file online? Do I really need to be able to access it from all my devices at all times?". If you do not have a good reason for doing so, let it be.


Securing AES 128 encrypted ZIPs against brute force attacks How long would it take to brute force decrypt an AES 128 encrypted zip file if the password is 8 characters long in the range of A-Z, a-z, 1-9?

Does it make any difference if .NET's System.Random object was used to generate the password or if System.Security.Cryptography.RNGCryptoServiceProvider was used?

I'm writing an application and I want to make sure I get the security right. In the worst-case scenario, if an attacker got access to the client's computer, he would have a few dozen zip files to attack but they all have the same password. I want to ensure that the application is secure against this kind of offline brute force attack. The attacker would not have access to any other randomly generated passwords or zip files encrypted with a different randomly generated password.

System.Random is not cryptographically random (see http://msdn.microsoft.com/en-us/library/system.random.aspx). It's predictable enough to weaken your crypto considerably.

See Tie-fighter's answer below for the keyspace calculation (which I got hopelessly wrong by using 61^8 instead of 61^8)!

I'd be more concerned with how that password is stored. Surely your application needs to decrypt the zipfiles on the (potentially-compromised) computer in order to use them? Is the password to do this stored on the same machine?

Also, to throw a spanner in the works - surely your 'worst case scenario' is that an attacker gets access to the client's computer and watches the screen while the legit user does work with sensitive data?