Is it possible to scan the whole IP range to find a domain behind the CDN? I am very curious if it is possible to find the real IP address of a domain "protected" by a CDN service.

For example, www.cnn.com uses Fastly service, and the domain name only resolves to a Fastly edge server's IP. If I scan the whole 4 billion IP range, sending HTTP GET request with header Host: www.cnn.com, how possible it will be that I can find the real IP of cnn's origin server?

Probably not.

CNN could be using a push CDN (where data is sent to the CDN) instead of a pull CDN (where it downloads from a central server).
Fastly also provides hosting services, so CNN could just be using them directly.
If CNN does run their own servers, they probably have firewalls in place so that their servers only answer requests from fastly.
And finally, some webservers are probably going to answer any request, without checking the domain first, so you'd have to sort out the "real" CNN from all the other servers that just happen to answer to any name.


Spam email sign ups from HeadlessChrome? I built a landing page with a "sign up with your email to get notified" sort of thing. The button executes some AJAX and submits to a PHP file which sends an email to me. Now, I'm getting a bunch of signups, but I've never advertised the link. I do see that it has been indexed by Google. These emails look semi-legitimate, but I checked my nginx access log and found they were all from HeadlessChrome (albeit from different IPs), and none of them have referers at all (I added the referer thing to the AJAX->PHP system).

So my question is: Is this spam or legitimate?

And as a follow-up, since I strongly believe this is spam, is this config in my nginx sufficient to fight it (given it's a tiny site) for now?

server {
 # (other stuff...)
        if ($http_user_agent ~ (HeadlessChrome) ) {
            return 403;
        }
}

Yes, it is spam.

I really doubt you have legitimate customers that subscribe to random forms using headless chrome.

No, it is not enough to block the user agent at nginx level. It would be trivial for an attacker to change the user agent, and even more so with your implementation to see you have blocked them.

At least, had you filtered it at the PHP file, you could tag them as malicious without hinting them. Anyway, just filtering the obvious cases doesn't mean you aren't receiving less-obvious ones as well.

An approach that can help to detect those is to build a database of blacklisted emails/ip addresses based on those known features. I suspect all of them to be spam, though.

The complete solution is that you should place a captcha system to avoid automatic sign-ups. And even then, to send before enrolling them in your mailing list.

There are two common reasons for doing this:

First is that they expect their spam reaches to you.
Second one is to provide the email address of a target they want to flood.

You need to provide a confirmation link before subscribing them in order to ensure the owner of the email address does want to receive your notifications.
You need a captcha in order to avoid flooding such targets with confirmation emails.

Please note that by not taking proper precautions, your form will be abused, and you will be penalized for that (your sending IP address, your domain more often ending up in spam, perhaps even your ISP getting complaints of your spam).


Are there any independent organizations doing (publicly available) IT security research? When looking up security risks on the net I find that all research being cited (if any is cited) always seems to come from the Anti-Malware companies. (just e.g., this article cites F-secure, AVG and McAfee).

I mostly do "research" of this kind to check how dangerous the latest IT security headlines in the media really are. (That is: Dangerous for my granny?, for my sister?, or for me? as someone who knows his way around.)

While I think myself not being prone to any "conspiracy theories", I find it a tad disappointing that all research and professional statements wrt. to security risks to me and my family that I seem to be able to find, seem to be by the companies trying to sell their Anti-* packages.

Are there any "independent" parties (like uni deps, gov agencies), that publish infos wrt. to new security threats?

(Note: I'm not saying that they'll be free of any bias, but they'll have slightly different bias, or so I hope :-) )

Edit: After a few answers and comments, it seems the case may be that (mass) media are very often citing the malware-companies, as these do easily quoted press releases on new security risks to consumers.

If you follow Full Disclosure (http://seclists.org/fulldisclosure/) and bugtraq (http://www.securityfocus.com/archive/1) mailing lists you can see that there are lots of security research by individuals or non-commercial entities.

You should join full disclosure and bugtraq mailing lists and also follow exploits and papers published by http://www.exploit-db.com/ . Some of the commercial vendor advisories are also based on these public advisories by third parties.


How can I as middleman verify whether a phishing site is valid if the scam listens only on the referrer link and blocks any other access methods? How can I as a trusted user of a middleman company (such as PhishTank) verify whether a phishing site is valid if the scam listens only on a unique referrer link(randomly created) and is blocking any other access methods?

To throw a threat scenario into scene.

An attacker sent an email to a local bank officer, the email looks very similar to a official email of an employee in their company at a higher tier and the time was planned. Later they detect it was a spear-phishing attack from an old employee. They report the attack on PhishTank (for example), but there they can't verify it because the link doesn't allow direct access (only with a unique referrer as in the email). How can they still verify whether it was a valid report of not?

Now the real question,

On a technical view, how does such an attack work?

Yes, this is a real problem and we have observed it in the wild.

As cloud-based malicious site detection systems get more prevalent, expect a corresponding increase in tightly targeted attacks that are invisible to such detection systems.

This kind of thing can be controlled by an .htaccess file in the payload directory.

HTTP Referer

Limiting access by referrer link (misspelled in the HTTP spec as "referer") won't work for phishing emails because there's never a referrer (unless the attacker uses a redirector service that happens to add one), but it could be done with a rewrite rule:

RewriteCond "%{HTTP_REFERER}" "!www.example.com" [NC]
RewriteRule "^"               "-"                [F,NC]

Restricting access by client IP

Here's another example that limits access by IP:

Require ip 127 172.16.0.0/12

This tells Apache and Apache-compatible servers that the current directory (and all subdirectories) should render a 403: Forbidden to any connecting IP that isn't localhost (127.0.0.0/8) or on the given private LAN IP space. An attacker could, for example, look up a region's IP ranges and explicitly require them.

If the detection system's IP range is known, you can reverse that:

# prevent access from these CIDRs
Require not ip 198.51.100.0/24 203.0.113.32/28

Solutions

  How can I as middleman verify whether a phishing site is valid if the scam listens only on the referrer link and blocks any other access methods?

You should do everything you can to look like a victim. If you have access to a VPN in the purported target region, use it. If you don't know how the attack is targeted, you'll have to guess.

Forging IP addresses is hard, but there's nothing to stop you from entering whatever you want as the HTTP Referer; it's just a header. If you have to guess, try the same page as you seek to visit. That at least works for most image hosting sites that are trying to prevent direct hot-linking of their content.


Shellcode parameter passing I am trying to use an environment variable to store my shellcode and then point my RET to it, so that I may get to execute my shellcode.
Here is my vulnerable program 'abc.c'

#include string.h
#include stdio.h

void foo(const char* str){
 char buf[100];
 printf("\n%p\n",buf);
 strcpy(buf,str);
}
int main(int argc, const char* argv[]){

 foo(argv[1]);
}

I've been doing the following steps so far

$gcc -z execstack -fno-stack-protector -o abc abc.c

Using getenv() inside another program I determined what the address of my shellcode was. Let us say it is some 0xbfffc209

Using
 $./abc $(python -c 'print "AAAA"*30')
crashes my program mercilessly, but if I use an address in place of the four A's my program cleanly exits.

Using A's

Now using an address in Intel format

As can be seen nothing has been overwritten. The output of ltrace with

$ltrace ./abc $(python -c 'print "\x09\xc2\xff\xbf"*30')
and also

$ltrace ./abc $(perl -e 'print "\x09\xc2\xff\xbf"*30') is

I'm totally baffled with an inexplicable behavior of this sort, and would be glad if someone can help me figure why this is happening so.

Thanks in advance

PS

I use an Ubuntu 14.04 32 bit VM
I get the same results thrown at me no matter what address I use

Not every character in your payload can be sent through the argv of your binary. There are some "bad characters" which you can't have in your shellcode. An example is "\x00" as you're using strcpy to copy strings and "\x00" is the delimiter for your strings. So first figure out what are the bad characters for your platform and then make a payload that is free of those bytes.

PS: I could have commented this but I only had 49 reputation.


Is storing my LastPass password in LastPass a security risk? While categorizing my accounts in LastPass, I had a dumb thought cross my mind.

  Can I store my LastPass password in LastPass?

Initially I thought this would be a completely pointless thought experiment. There's no way you could actually save your LastPass details in LastPass... right?

Even if a user did try to save their own LastPass password, surely there would be some sort of error or sanity check preventing this from...

...or I can add my password without any issue.

Obviously there isn't much point to this. Doing this is the equivalent of storing a safe combination inside said combination-locked safe. What I'm curious about is the security implications.

How insecure is it to store my LastPass password in LastPass? What potential security issues could it cause?

It is rather useless because you first need to type the password to recover it. But IMHO this does not really weaken the overall security of the password vault by itself. Assuming LastPass encryption is correctly implemented, the only way to access the encrypted master password would be... to find it by another way. And if an attacker ever gains access to the encrypted vault, then the master password does not protect anything else, since the whole vault is in attacker's hands.

IMHO it is still a poor practice, but mainly because as it is useless,  doing that could either give a false security feeling, or be an indicator of other weird usages.


Security of unencrypted wireless networks with authentication page Some wireless networks, such as those offered by hotels and hotspots, are not encrypted (they don't require a pass phrase to connect) but have an authentication web page. For example, you connect to an unsecured airport network, and it asks you to login using the credentials you were given when you paid with your credit card.

How secure are these type of networks? I would imagine that, since the connection between the client and router is not encrypted, and since authentication does not mean encryption, it would be entirely possible to sniff the data exchange. But if it's unsecured, why do so many universities, hotels, and airport hotspots use this system?

The page where you enter your login details is probably secured with HTTPS. As long as the HTTPS isn't compromised, the login data itself should be fairly secure. If there is no HTTPS to be found, I would definitely not give credit card details or anything similar (although a throwaway login code bought at the hotel lobby is hardly a big risk - worst case, you lose part of the credit you bought).

Note that wireless encryption by itself doesn't provide much security in this scenario - WPA2 and its siblings are intended to prevent unauthorized access to the network, but since the access credentials are the same for all machines, and there is no reliable way of allowing individual machines selectively (MAC addresses can easily be spoofed), your credentials on an encrypted hotel network would still be visible to everyone else on the same wireless network. It would keep a silent (passive) eavesdropper from outside the network from listening in on your conversation.


How can I securely identify mobile devices on a network without a lot of overhead? I am thinking there must be some alternative better than passwords, but not so complex and difficult to administer as a full PKI infrastructure with client certificates on every device.  My primary concern is to prevent malicious users from spoofing a device that belongs to someone else and then guessing the password.  We want to prevent identity theft in the mobile application, which is processing financial transactions.  Implementing too much security would negate the convenience of mobile access, and the users would not adopt a mobile centric workflow.  Is there an alternative, a middle way?

It sounds like your real concern is at the application level. You could secure your connection via VPN; In this scenario you block access to the app from the network that is just the WiFi and require it only come from the VPN's network or other approved network. You may also consider, possibly in addition, using some type of HTTPS, TLS, etc at the transport or application layer to encrypt the connection. If you are doing financial stuff, this should have already been a requirement.

Just because you are on the network, one should not be able to just get to the app. If you were talking about getting the WPA2 password, requiring encryption at layer 3 or above can help that. If you were talking about breaking a user's application password, there should be controls in place to limit brute force attempts and to ensure complexity rules are sufficient.

If you provide more detail in your question, I will update this response.


Hydra brute force error message hydra 190.13.132.90 -s 8081 -V -L /home/nicolas/Escritorio/USER -P /home/nicolas/Escritorio/passwords.txt http-post-form "/user=^USER^&password=^PASS^=Ingresar&culture=es-CL&mobile=0&clasica=1:F=Usuario inexistente:H=Cookie: stwa2={"lang":"es-CL"}"
Hydra v8.7-dev (c) 2017 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.
Hydra (http://www.thc.org/thc-hydra) starting at 2018-04-29 14:34:51
[ERROR] the variables argument needs at least the strings ^USER^, ^PASS^, ^USER64^ or ^PASS64^: F=Usuario inexistente

Could anyone write the correct string to use in hydra please? I’m a noob using hydra :)

The username is Gonzalo Sepulveda.

The full URL of the login is:

http://190.13.132.90:8081/

The http-post-form module requires three colon-separated arguments, like so:

/login.php:username=^USER^&password=^PASS^:login failed

The "variables argument" where you supply the POST data with username and password placeholders (which I made bold) is the second argument. But you gave the POST data as the first argument which makes hydra think this is actually the path.

So, with your command hydra thinks...

/user=^USER^&password=^PASS^=Ingresar&culture=es-CL&mobile=0&clasica=1

...is the path and...

F=Usuario inexistente

are the POST parameters - which don't contain ^USER^ or ^PASS^ and are therefore invalid.


How secure is this Diceware generator? I wonder, because you can visit the site offline and still create passwords.

Is this site safe and good for use?

https://www.rempe.us/diceware/#eff

Yes, this site is safe to use.
If you are still worried, run the application locally offline, as you mentioned, and take the proper precautions so the application can't "phone home".
From the GitHub page:

If you are security conscious you are of course encouraged to download the source code for this app and run it locally by simply opening the index.html file. If you run it from the web feel free to run it without a network connection to demonstrate nothing is sent or received from an upstream server once the initial page load is complete.

If you are extra paranoid, sift through the source code first.
If you are SUPER EXTRA PARANOID, take the advice, once again, found on the GitHub page:

If you want to be REALLY REALLY secure. Roll the dice with a flashlight under a black hood with a printout of the Diceware word list. No computers needed!
Not really kidding

The only issue I can think of is whether or not they are generating sufficiently "random numbers". That is for you to decide based on the method they use and the information they provide on the application page. IMHO, it's a safe enough method.


Multiple SSL Inspection I want to ask you if you think that doing SSL Inspection in proxy mode (Resign) could be a problem.

The scenario is the following:
1 --> 2 --> 3

Client web browsing
IPS device with SSL inspection (client trusts the certificate of the IPS because the IPS became a subordinate CA of the CA)
After that the traffic goes to the cloud where it is again resigned by the cloud proxy.

What do you think? Is it possible to realize it? The cloud proxy should be a subordinate CA of the CA?

I think that it is not a good idea as this deployment would defeat the basic idea of SSL/TLS: End-to-end encryption.

In practice, such a deployment can cause the following problems:

Sites, web services etc. that use Certificate Pinning (e.g., via HPKP) would stop working because the browser / client is suddenly seeing a valid but different SSL certificate.
Many smartphone apps do certificate pinning for their web service endpoints because there is only one client which makes public key pinning relatively easy.
Google Chrome and Firefox a predefined list of pinned certificates and hard-codes the Google certificates into the browser. So Google domains would not be accessible from the Chrome browser any more. Here you can find more information on that regarding Firefox.

Everything in the SSL/TLS world is going towards pinning certificates and narrowing the trust relationship between CAs and SSL/TLS-enabled domains. That's why I don't think that what you suggested is a future-proof network design.


question regarding php upload form security I read here http://blog.insicdesigns.com/2009/01/secure-file-upload-in-php-web-applications/ and question is related with text near

However, if the attacker is able to upload files, even outside the web root, and he knows the name and location of the uploaded file, by including his uploaded file he can run arbitrary code on the server.
The solution for that is to prevent the attacker from knowing the name of the file. This can be done by randomly generating file names and keeping track of them in a database.

I fully do not understand security risk. As i understand

attacker uploads malicious file
At the moment my php code converts file name to something random and with that random name stores in particular directory. But the malicious user can see that random name, for example with mouse right click Copy location and see https://domain.com/images/2014-05-16/339442/VH4AGExjRlw=/something_random.jpg. So just creating random name does not help?
As understand in mysql need to record real name of file and the name that user can see in url?

Can not fully understand. Aim is to prevent situation that user uploads file and then knowing file name, can access the file?

You are correct.  If the ultimate goal is to process the file on the server, then renaming it provides a layer of protection.  However, if you are going to redisplay the file, then renaming it hasn't helped; the attacker just uses whatever redisplay mechanism your site provides.

Let us suppose that your web users can upload pictures that are then displayed on the site.  As the article in your link says, an attacker can upload a picture that contains PHP (or JavaScript, or whatever) in the embedded comments.  If the web server program were somehow (mis)configured to send files with a .jpg extension to the PHP processor, the attacker could run arbitrary PHP code on your machine with the privileges of the web server process.

What this means is that the web developer must carefully sanitize files before allowing them to be redisplayed.  So, you'd:

upload to a random file name and keep track of the name
process the file to sanitize it; how to sanitize depends on file type
rename to an "internal" name; you probably don't want to use the uploader's filename anyway because of name collisions.
Place the sanitized file in a directory in or below the web root, or in a database, and set it up for display.

For image files, you can use ImageMagick to strip comments.  There is a discussion of using the -SET command to strip comments here: http://www.imagemagick.org/discourse-server/viewtopic.php?t=26106  Interestingly, there is also a link to an image, kitten.jpg, that contains embedded PHP.  You might use it to experiment.

Edited 2014-12-02 to add: As Gumbo has pointed out, such an attack can be mounted through a file inclusion vulnerability.  In PHP, all included files start in copy mode, so the PHP processor never sees the binary data of the image, it just scans for the XML processing instruction <?php (or any of the other valid introducers.)  That switches the PHP processor to interpret mode and the embedded PHP code is executed.  When the ?> is encountered, the processor switches back to copy mode and just copies the binary stuff some more.


Secure Radio Frequency TX, RX module from replay attacks Background

I am building a Home Automation system using RF 315/433 MHz Transmitter-receiver module, an Ethernet shield and AT Mega AVR Micro controller(ATMega328 PPU) that works as follows.

A set of REST APIs are integrated with a back end database. A web and mobile application interface with this DB to change settings. The AT Mega MC interfaces with the Ethernet shield connects to my home ADSL router.

AT Mega MC reads (HTTPS) API values via Ethernet shield and try to control devices (my roller door, light switches, heating  etc..) using a RF 315/433 MHz Transmitter-receiver module. The end point featuring by the RF Receiver and AT Mega MC sends control messages using the RF Transmitter.

Problem

I have the following security problems in this setup.

What is the most efficient way that I can encrypt my messages from the RF transmitter to receiver ? Right now I do a simple XOR operation to the control messages in both ends. So the value of the XOR is simply acts as a shared key. I know this is not secure at all! I cannot implement resource consuming algorithm in my end point (receiver end) because it is using the ATtiny85 MC.
Even If I encrypt the message from RF TX to RX, someone can intercept the outgoing message (using some tool like HackRF) and replay the message later. So they can do a replay attack easily and open up my gate any time later.

Questions

What are the best security precautions that I can use to secure my RF transmission?  Please remember that I am working with IoT devices which do not have extensive computing power.
How can I prevent this replay attack ?

IoT limitations will be serious to your system security. It may be fun to build but personally I would like strong security for the garage door. Anyhow, some general answers below.

AES is common secure alternative in the modern communication protocols. XOR will reveal your password to the eavesdroppers. Search e.g. "whats wrong with xor encryption" in this forum.
The TLS nonce is a good example of preventing replays. Its use is discussed here:
nonce in SSL/TLS handshake


Why did firefox remove Javascript injection on address bar? Why did firefox remove Javascript injection on address bar? Someone said it was a security issue. What security issues could there be?

It basically has to do with social engineering - you'd be surprised how many lay people you can convince to copy and paste *anything* in their URL bar.

You can still do it through the developer console and/or some add-ons, so it's not that it is completely disabled - it just takes a few more steps now to actually do it, and the rationale is that gullible people would just give up if they need to follow a specific set of steps. Thus - more of a security through complexity than a real security measure, but it should in theory prevent many of the URL-bar 'attacks'.

You can read the whole discussion about that issue at Mozilla's Bugzilla.


Protecting Uploaded Confidential Files We have a web application in Linux (App A) using PHP and Zend and another in Windows using Asp.net C# (App B). They both access the same database. App B is for internal use only while App A can be used accessed outside our network.

We got a request to allow uploading files from both applications and should also be accessible from both sides. The file will contain Personal Information so should be confidential and secured as much as possible.

We are considering on storing the files in the Database for it is easier to implement given the current situation that the apps resides in servers with different OS.

How can we at least add a layer of security (e.g encryption) to our applications so that the file will only be accessible to the approved users?

How can we protect the files from attack?

[UPDATE 2015-07-10]

We realized about the long term effect of saving the data to the database so we are thinking of saving it to a file server instead

There are numerous questions with answers on this site as well as Owasp guidelines that cover the risks of allowing file uploads and how to store files properly.

You may want to check the legislation that applies to your application and take necessary action to store files accordingly (encryption, access rights, data integrity, logging).

As for your idea to store files in the database I think it will cause a lot of stress (as well as storage overhead) to your server(s). It's more convenient to store files outside the web root with tight ACL (access control) and possibly encryption.

The database may be useful for storing metadata and access rights for users of the web application(s).

It's possible to share the files between servers/applications securely using standard protocols like rsync or even https.

You may also want to consider scanning uploaded files for malware and fuzzing attempts.

Find out what your requirements are, check legislation and produce an overview of how your solution should work and what precautions you are taking. Then consult an advisor/expert and revise.


How to extract data using SQL injection on a vulnerable ASP.NET application? I managed to find a vulnerability in a so-called friend of mines website and I want to show him that his website is vulnerable to data extraction.

When I use something like yes')-- as post I get the following debug info:

  You have an error in your SQL syntax; check the manual that
  corresponds to your MySQL server version for the right syntax to use
  near '%' ) or (r.nrinreg=1 and datainreg='01.01.2017' and r.adresant like '%yes' at line 3

So basically my input is inside some brackets. Doing yes%')-- results in a slow-loading page that results with nothing but blank. So that would result in something like this query:

or (r.nrinreg=1 and datainreg='01.01.2017' and r.adresant like '%yes%') -- whatever is after the comment

How can I get any data or MySQL version from that query knowing that the input isn't escaped?

Also, what is this kind of SQL injection called?

ASP.NET Version:2.0.50727.8762

Sometimes (most of the time) you can't. Its so called blind SQL injection. What you usually can do is to delete (you don't usually want to) or create or modify some data (yes, this is what you want to do) or to avoid some expression evaluation (ie password = password).

Typical tasks you want to do is to assign admin role to your account or to change admin password, force the application to present modified data to target users (stored XSS and many other things) or just to login without knowledge of username/password. Moreover, on MS SQL (if badly configured) you can also start system commands so in the end there are many possibilities to do including obtaining complete control over the server and further servers in the infrastructure.

Good luck but be ethical!


has scrypt withstood the test of time? I've always heard that scrypt was better than bcrpyt... because of memory causing GPU a very difficult time to crack. However, the notion always was that scrypt hadn't been tested, it was kind of a new crypt method, and that I should wait it to be tested before using it.

Has that time come where people have made scrypt the new standard to use? or is it still in beta phase?

Scrypt has mostly survived. It is not bad; it just turns out that the touted advantages of scrypt over the competition (mainly bcrypt and PBKDF2) might not be as marvellous as first claimed. As always, it is a trade-off: like any password hashing function, its role is to make password hashing expensive for everybody, attackers and defenders alike. Scrypt uses a lot of RAM in order to force the attacker to use the same hardware as the defender (a PC). The bad point, though, is that it uses a lot of RAM.

See this presentation for some information on the present of password hashing. An open competition is being run, to obtain, publish and analyse new and hopefully better functions (currently in the phase of gathering candidates).


TAILS or FREEPTO is better to stay anonymous on the net? Which is safest for security and being anonymous in internet?

I have heard TAILS is better because it was used by Snowden, but I don't really know FREEPTO.

The main difference in between Tails and Freepto, is that Tails routes everything through Tor, you have no way to disable this. Freepto does not anonymise your computer IP unless you choose to do that.
The projects have different targets, Freepto’s goal is to allow for a highly portable operating system and switch people from proprietary software into open source. The privacy tools that Freepto includes are there because activists need them to communicate safely, as an extra, not as the reason for the operating system. Tails reason to exist on the other hand, is to provide anonymity.
If what you want is a portable easy to use OS with discretionary high calibre privacy tools, use Freepto, if you are paranoid about privacy and want everything to be anonymous, then use Tails.

Also:

The operating system is fully encrypted with LUKS, you will be asked for a password before it boots, ...

http://www.hacker10.com/internet-anonymity/encrypted-operating-system-for-activists-freepto/


Purpose of Initialization Vector in File Encryption and Authentication (FEA)? I came across this schematic of FEA implementation using RSA and AES:

Suppose that PKB is Bob's public key, PKA is Alice's public key, SKB is Bob's private key, SKA is Alice's private key, Ks is the session key used by AES, IV is the iniitialization vector, and F is the plaintext.

Suppose Alice was to send Bob a message:

C = E_{PKB}(Ks||IV) || E_{Ks}(F) || Sig_{SKA} (E_PKB(Ks||IV) || E_Ks(F))

This ciphertext consists of three components:

E_{PKB}(Ks||IV) - the RSA encrypted AES session key along with IV
E_{Ks}(F) - The AES encrypted plaintext file
Sig_{SKA} (E_PKB(Ks||IV) || E_Ks(F)) - The RSA signature

When Bob receives the message, he will verify and decrypt the ciphertext.

This makes perfect sense except for the IV. I don't know what the IV is used for in this case. It seems that the IV is simply concatenated with the session key. How is this useful and how does Bob deal with the IV when decrypting the session key? What extra security does this provide? This was the schematic which my professor presented when talking about RSA. It could be possible that the IV is not needed at all.

Assuming AES is being used in any mode other than ECB, the IV is used in the AES encryption (the actual encryption is E_{Ks,IV}(F), not just E_{Ks}(F)). Every mode of operation for AES that I'm aware of except for ECB mode requires an initialization vector, that is used for different things depending on the mode (in CTR it's used to produce the keystream; in CBC it's XORed with the first plaintext, etc.) Now, the IV does not need to be secret, so you could just concatenate it to the whole message; I'm not sure why it's encrypted with RSA, instead of having

C = E_{PKB}(Ks) || IV || E_{Ks,IV}(F) || Sig_{SKA} (E_PKB(Ks) || IV || E_{Ks,IV}(F))

But that's why it's present in the first place.


Protect application from being modified I have a question about how to detect a program/binary modification assuming the program is able to communicate with a remote validation server. More specifically I'm asking for android APK file, but it can be for any other program as well.
I imagine the following hypothetical scenario:
There is an APK installation file that the user is downloading and installing on his device.
The application, after being installed and used is sending "some information" about its integrity to a remote server.
The server is validating that the program is OK or is modified by hackers.
Given that scenario and the fact that APKs are written in Java, what are some ways that a developer can use to generate a hash value of his application files, so later this hash can be sent to a remote server that in turn will be able to validate that hash - hash over files sizes, or some other kind of structure?
I am interested in some ways to generate that "some information" which is sent to the validation server.
Please correct me if the question is not very properly asked as this scenario is not so clear to me and maybe there are other ways this can be achieved more easily. Thanks a lot!
--- EXTENSION ---
Hello and thank you very much for the answers!
I am surprised by the answers a little bit, because I didn't think too deep about the issue and I thought that there will be some easy mechanism to do this :) But now I hear that even TPMs cannot guarantee 100% protection...
As a lamer on the topic, I would like to ask something more. I don't want to protect the program from redistribution, like a copy protection mechanism. I want the program to be tested from time to time via validation server, that it's not modified.
This is the scenario:
The server that is distributing the application computes a hash of the program with some weird algorithm, if there is such.
Later the program uses the same weird algorithm to compute a hash of itself and send it to the server. The server then compares the two hashes. If someone has modified a file, a JMP instruction for example, the hash should be different and the app considered hacked. What are the flaws in this scenario? That someone will be able to disassemble the algorithm to compute the hash from the program and later modify the program to send the same value to the server?
And even if this is the case, do you think that this is still a lot of work for someone to do, and it may not be worth it?

The scenario you describe is very similar to the concept of "remote attestation". There has been a lot of research on this and there are two major results:

You need a trust anchor, such as the TPM or a trusted system service, to securely measure your app and report the results to the server. Otherwise you can always build a simulator that generates the correct responses[1].
Once you deploy and use all the trusted computing infrastructure, you still can't prevent or even detect exploitation of vulnerabilities in your app with any more assurance than by deploying today's standard anti-buffer overflow technology.

So, if you want to deploy this today, your best option is code obfuscation. Basically, you want to implement a copy protection mechanism, same as it has been implemented and broken for decades.

[1] There have been some very cool advancements that exploit computation and communication limits of the client platform, but this is still sci-fi.


What other place (besides libc) attacker redirect control flow to after an attack such as buffer-overflow succeeded I am not sure this is a right place to ask this question or not.

I want to know in previous or modern type of buffer overflow attack, when the attacker succeeded to overwrite return address, where he/she set the new return address to point to? As we know today because of new protection mechanisms it's harder to insert code and execute it (Data Execution Prevention), therefor attacker try to use address of existing code/library like "libc" to change control flow to them. I wonder beside "libc" what opportunity exist that can be used by them?

Update: You seem to be expecting more concrete information, so I expanded my post a bit. As far as I know, however, no code besides the actual program, libraries and kernel code is usually mapped to memory when your program is run in user mode.

There are several places you could redirect the control flow to, in case the stack is not executable:

ret2data: Place the exploit code into the data section and then point the return address there. Often not possible.
ret2text: Jump to existing code in the .text section of the exploited binary. This includes jumping to DLLs and other shared libraries (and theoretically even kernel code, without a mode switch).
chained returns: A technique that can be used to combine several methods. Basically, you prepare the stack so that the returning instruction of the first function will jump to the second function, and so on.
partial returns: Another technique. You don't have to jump to the beginning of a function, but can also jump in the middle or near the end.
ret2syscall: A practical example what you can do. Basically, you have an int 0x80 instruction (a linux system call that expects its arguments in registers) and any function that cleans up the stack, for instance pop eax; pop ecx; pop edx; pop ebx; ret; You fill the stack with the address of the pop eax instruction, then the values of the registers and then the address of the syscall.


Can I use an ID token as proof of authentication? I have a reverse proxy, configured as the Relying Party of an OpenID Connect identity provider. Then, it delegates the request processing to another web server, exposed on the internet. In order to secure and authenticate this data flow, I thought I could use the RS256 algorithm to sign the ID token and pass it along the request. With this, the second web server would be able to verify the authenticity/integrity of the token without sharing a secret with the identity provider.
This data flow would obviously be encrypted with TLS.
There's just one thing I'm not sure about: is it fine to use the ID token as a proof of authentication? The signature mechanism is designed to verify the integrity of the token, can it also be used to verify the authenticity? Is there a better practice in order to authenticate/secure this data flow?

Yes, a signature proves the authenticity of the data. In an asymmetric algorithm such as RS-256, a signature can only be generated by someone in possession of the private key, and this can be verified with the public key. As long as the private key is kept secret, nobody else should be able to forge valid signatures.


Which forensic techniques should I use to identify intrusion or monitoring of my computer or cellphone If I suspect my computer or cellphone is being monitored by an unknown attacker, what tools or techniques could I use to detect or identify such monitoring?

There's a broad spectrum of methods that could be used to monitor your communication.

External Monitoring ("Lawful Intercept")

Your attacker could be monitoring your communication upstream. This could be because they're working with your ISP, or they're sniffing your home network (wired or wireless). You said that your attacker knows things you typed... were you typing these over a clear channel?

Defense against upstream monitoring and local network sniffing: Don't send any communications in the clear. Use only encrypted channels, and use only protocols that provide you assurance that you know who is at the receiving end. The attacker will still see all of your communication, but (assuming the encryption is strong, you don't leak the key, and any passwords are strong) they will be unable to read it.

Defense against local network sniffing: Stop using wireless; disconnect the antenna from your access point, disable wireless in software. For your wired network, inspect your cables. If your cables go through the walls, run new cables between the router and computer that are exposed (visible). You may be able to detect sniffers through various techniques, but it isn't always possible.

Defense against anybody brute-forcing your encrypted communications: (Assuming you're encrypting everything...) Flood the attacker with noise. Through whatever communication channel you're using, make sure that you are always sending something -- random garbage. (It doesn't have to be random, anything will do -- the works of Shakespeare, the text of the tax code, etc.) It should still be encrypted; this makes it so that even if the attacker can feasibly brute-force your communications it is even harder because they won't know which comms are legit and which are noise.

Internal Monitoring (rootkit, keystroke logger)

If your attacker has hacked your computer or phone, there could be a monitoring process that is running and sending all of your keystrokes to the attacker.

Defense against rootkits/loggers: You can run a rootkit detector or anti-malware software to try to find it. If the attack is really clever or uses some new technique, you may not find the logger.

Defense to detect them: They have to get the keystrokes off the machine somehow. Run a sniffer. If you detect outbound traffic that is not yours, investigate it. It may lead you to the process that is sending your keystrokes. As another poster mentioned here, you can jailbreak your phone and run a sniffer to detect any unexplained outbound traffic. This is not foolproof; the logger could be using a covert channel that is not detectable using the common monitoring techniques. Careful analysis of a capture file might reveal a covert channel, but a sophisticated attacker might be using an out-of-band channel or other mechanism that is very hard to detect.

Defense to avoid them on your phone: Ditch the smart phone. Get a "dumb", disposable phone and a prepaid account. Use it for phone calls. Use your (wired) computer (see next item) for Internet commnication.

Defense to avoid them on your computer: Go to the store, buy a USB stick (best if you can find one with a physical read-only switch). From a reliable source, put a bootable copy of your OS of choice on the drive. Switch the drive to read-only. Boot from the drive. (This assumes that you are going to install a hardened copy of the OS onto your read-only drive.) For the most protection, don't access your existing HDD. Wipe it (with every reboot if you're paranoid) and use it as swap/tmp space.

Defense to distinguish between monitoring via rootkit and monitoring via network: Using a clean OS (see above), send a message that you want intercepted from your home network. If the message is intercepted, it is very likely that your network is compromised and not your computer.

Physical Monitoring

If the attacker has placed listening devices or cameras in your home, workplace, or other areas that you commonly use, they could be monitoring you that way. Keep in mind that you could be watched through open windows, or someone could listen through the walls of a neighboring apartment.

Defense to detect this monitoring: (Assuming that you can get feedback on whether particular messages are captured.) Assuming you can surreptitiously disconnect your keyboard from your computer, type something that you want to deliberately be intercepted (in a situation where the keystrokes would not be echoed to the screen). If you find out that the communication was intercepted, you can assume that there's something monitoring your keyboard. Repeat as desired, possibly moving to different rooms. Repeat with the keyboard connected to the computer and characters echoed to the screen, but actual network comms disabled.

If your messages are only intercepted when echoed to the screen, you could be subject to Van Eck phreaking. In this case, you would need to shield your LCD from leaking electromagnetic emissions.

Defense: If you think your home and/or office is bugged, don't communicate from those locations.

Defense: If you think your phone is bugged, get another phone (see above). Never let the phone off your person.

Defense: Hire a specialist to sweep your home for RF bugs. (Or move.) After it is verified clean (or you have moved), apply physical security measures to avoid physical compromise and/or at least have the ability to confidently detect it.

Finally, don't discount the possibility that the person you are communicating with has been compromised. Maybe their computer/phone has been hacked, they are being monitored, or they are otherwise providing with your attacker with info. It's also possible that any servers/services that are relaying messages for you have been compromised and are disclosing your messages.


Wordpress blog hacked? There is a Wordpress blog running on Wordpress 4.0. Anyone having the company webmail can signup to the blog using their Google+ account and submit blog posts. Once posted they will be sent to some moderators and once it is reviewed moderator can post it on the blog. Whenever anew blog post is submitted for review all the moderators will receive a mail saying to review the post.

Now the problem: The moderators are receiving spam mails. Mail says that there is a new blog post to be reviewed. To review goto this link. The link is a normal link. Nothing seems fishy. But the author details are interesting. The authors are not members of the organization and hence they can't create blog posts. So that I cant think of this as a simple spamming trick. How such moderator mails are getting generated?

The authors had an email addresses like name@h.maybebest.com and name@nokiamail.com. What am I supposed to do? Am I hacked?

EDIT

The emails are being received from registered mail server and the link looks like a normal edit blog post link. But since there are no such real blog post it redirects to the blogs homepage.

Recently I have deleted all the unwanted users from the website and watched the new users carefully. Within 4 days new spam users are getting registered to the site. Around 100 users were registered in 4 days.

I have the New user registration feature disabled. Still how this happens?

I'm assuming there is no relation between these mails and any actual new posts to be reviewed, right? I.e., just be cause you receive one of these mails, there does not need to actually be a new blog post to review?

If this is the case, then I can't see any indication of any relation between these mails and your systems (the WP system). In other words, I can't see any reason to view this as anything other than "regular" spam.

As for the links, the fact that they point to your moderation page does not mean an attacker has access to your site`s internals - the url is probably just a standard url for WP sites, with the root url replaced with your site's address.

Edit: As mentioned in the comments below, the real issue is that the mails appear to be coming from the internal mail-server. This could perhaps indicate a breach (?), but should be verified by checking logs for the mail server to make sure the mails are not just manipulated to look as if they're from your server. If logging is not turned on, change that now, and check the logs next time such a mail is received.

(Sidenote: Why would someone do this? Perhaps as a way to try to bypass any mail-filtering system you have in place, in order to sneak in spam that would otherwise be stopped?)


How can I create a secure password? I know the standard tricks, create a long password, numbers, symbols, capital letters, etc. My questions is how do I judge password security.

I heard different tricks to make secure passwords. For example, until the famous xkcd comic came out (correcthorsebatterystaple), that would be a perfect password. No cracker would target it per-se, and to brute force it would take forever. Now that the pattern is known, that password style is not nearly as secure, since cracking software is now made to target it.

So even though normally password security tools measure bits of entropy, there are techniques that crackers use to make passwords easier to crack.

How do I know that my password is really secure? Are there tools out there to check my password against real cracking software?

Strictly speaking, you cannot measure the entropy of a password. (Or if you like, you can measure it, but the value is 0.) There is no entropy in a password: the entropy is in the way the password is generated.

This is explained in the xkcd comic: “correct horse battery staple” is just one example, what the password illustrates is the procedure to generate that password. Namely: “four random common words”. The next panel gives the quantification “44 bits of entropy”, which is based on 11 bits per word (i.e. choose each word randomly among 211 = 2028 words). That password generation procedure has 44 bits of entropy, which means that on average, an attacker who knows how the password was generated will need to make 243 guesses to find the password. (On average, the attacker needs to enumerate half the password space.)

The comic does not recommend that you pick “correct horse battery staple” as your password. It recommends that you select 4 random words. The pattern is known, but not the random choices. Diceware is a popular variant of this method: you pick words on a list of 65 words by rolling five dice for each word.

To put it yet another way: there are two aspects in choosing a password, the randomness and the cleverness. The method is cleverness and does not contribute to the security of the password. The randomness makes the password secure, regardless of any cleverness. Cleverness is only useful to make the password easier to type and remember. If you're clever, you only get protection against attackers who are less clever than you.

A method like “pick random words” is easy to quantify because as long as the random choices are independent, the entropy adds up. If you add constraints (e.g. generate something and “smooth it out” to make it memorable), you need to count the number of possibilities that remain and take care if the smoothing can map several different random rolls to the same final password.

Yes, there are tools to check the strength of a password. They come in two kinds. The fast ones apply some heuristics. They don't always get it right, because they have no idea how the password was generated; they tend to favor passwords with clever bits over passwords with randomness. Since they see only the final result and not the generation method, they cannot take randomness into account. For example (picked at random — not in the cryptographic sense) passwordmeter.com tells me that “correcthorsebatterystaple” is weak (25%) and “homechasebogbigamy” (which I just generated randomly with the XKCD procedure) is very weak (19%). Yet if I'd only told you how I'd generated that second password and not what the random choice was, it would take 1000 computers about 3 year to find at 100 attempts/second/computer! In contrast, pass+word1! is rated strong (64%).

The second kind of password strength checker is… cracking software. This gives you the perfect measure of your password against that same cracking software. It doesn't tell you much about other cracking software.

The best way to ensure that your password is secure is to measure the amount of randomness that goes into it. N bits of randomness = 2N-1 guesses needed on average to crack it. Figure out how much you want 2N-1 to be and deduce N.

Exercise: to generate “homechasebogbigamy”, I used a list of 4172 distinct words in alphabetical order and generated each word by taking a random word among the first 2048. Assume that list is public. Does the fact that the list was sorted alphabetically reduce the entropy of the password? Is my claim that this procedure has 44 bits of entropy correct?


How to successfully prevent advance persistent threats With the topic of advance persistent threats (APT) getting common nowadays, how do you successfully prevent such an attack in the workplace? Do you have to purchase expensive tools, such as those from Fireeye, which provide sandbox environments, or can we just use simple tools such as network sniffers to detect abnormal traffic and stop them going out of the network at the firewalls? What about endpoints? Is application whitelisting sufficient?

"Advanced Persistent Threats" (APT) are primarily marketing language which  still has a true core. Lets analyze first the particular words to get to the core:

Threat: This means it is somehow dangerous for you, so that you will be scared and buy something in the hope it will protect you. Note that when you are scared critical thinking often is reduced so you might buy anything just because of the marketing and not because of the true capabilities.
Persistent: Attacker plans to have you infiltrated as long as possible. This might be the case because the attackers want to get as much as possible internal information from you, i.e espionage. Or they want to infiltrate your internal networks so that they will be able to disrupt critical processes at the right time, i.e sabotage. Or they want use you as a trampoline to hide attacks against other companies, by misusing existing trust relationships. Or something different.
Advanced: This just means whatever you use currently will not work to detect the attack. This is another way of selling you something new, often marketed as "Advanced Threat Protection" (ATP). The similarity between APT and ATP might be intentional but is misleading. In my eyes "Advanced Threat Protection" is just the new buzzword because everybody now claims to have a "Next Generation Firewall" and the marketing needed something new. So it is mostly the same with a different name. And it still can be trivially bypassed as I've seen in my research.

Thus at the end there is not much technical substance in the phrase "Advanced Persistent Threats", i.e. nothing which could suggest a specific solution. The main message of this phrase is that there is something unknown and dangerous where the current protection does not work and you need new one. But the "persistent" part at least tells you that you should assume that the attacker made it into your network, which means filtering at the perimeter is not enough. That's why a large part of the new products they sell are "Breach Detection Systems" (BDS) which are sold to help you in detecting and fighting existing infections.

There is no full protection against APT, same as there is no full protection against "regular" attacks. Thus at the end you want to reduce your risk to a level acceptable to you and only spend an acceptable amount of money and other resources to reduce the risk.  I suggest that you look closer at least at the following parts:

Evaluate your risks

Before you can protect something you must know what to protect. Then you have to put a value on it because it makes no sense to spend more resources on protecting something than it is worth. You also need to analyze the existing attack vectors. Only after an exhaustive risk evaluation you know how much money you should be willing to spend and how to use these money in the optimal way.

Also note that if environments change the risks change too, so you need to reevaluate the risks from time to time.

Reduce the chance to get infected at all

Once the attacker is inside the network it is much harder to get rid of the infection, because the attacker tries to behave as stealth as possible to keep persistence. Thus the best thing would be to make sure that you get not infected in the first place.

This means use of classical products like antivirus and deep inspection firewalls, web- and mail gateways ... This also means allowing only known good things, i.e. URL white lists, only executed signed code, only allow specific innocent kinds of mail attachments.. . While white listing is nice it is often impossible so at least have good black lists but be aware that they don't cover everything. And it means that potentially infected devices should be denied, i.e. no USB sticks, no BYOD (bring your own device) etc.

Awareness of the problems is absolutely important. This means lots training. Users with less awareness should work in a more restricted environments so that they can not cause that much damage. This often includes less tech savvy users like you will find in marketing and management. But even more knowledgeable users will be affected if the stress level increases. Thus an environment where users will get enough time to think about the problem is important too.

And of course malicious internal users can spoil any protection. Thus you should create an environment where users feel good but where they also notify you about potentially dangerous behavior of others.

Detect successful infections early

There will be a time when an infections makes it into the network undetected. Thus you need to monitor your network for abnormal behavior. This can be Command and Control connections from the malware to its masters. It can be access to sensitive files by users which should not access these files. It can be abnormal times when users access systems etc. You can also plant canaries (special user accounts, special documents...) in the network and monitor their usage.

The most important part for a successful monitoring of the network for abnormal behavior is that you know what normal behavior should look like. Otherwise it is easy for an attacker to blend into the normal network activities.

Awareness of the users is also important for this part. Users should be aware that the network might be infected and thus not fully trust it. If they see something strange they should feel comfortable in reporting at, i.e. they should be thanked for their awareness even if it was a false positive this time.

Reduce the impact of successful infections

You will not be able to find existing infections fast or even at all.  Typical APT attacks range from month to years before they get detected. Thus you must be sure that it is hard for an attacker to get to the core assets even if the attacker is inside your network. Therefore you should implement defense in depth. This includes segmenting your network into different security levels (guest network, developer network, marketing...) and reduce and monitor communication between these networks. It includes access control lists to files, which of course needs a proper user and permission management so that a user only has access to critical data as long as they are needed by the user etc.

Summary

Buying products will help, but only after you have evaluated your risk so that you know what you need for optimal protection. There are companies which help you asking the right questions and these should probably not the same companies which  create the products. Independent resellers of multiple competing products might be better in helping you with an evaluation, because they are not committed in selling a specific product.

There are lots of important things outside buying products, like training and the right working environment. These too should be part of the risk evaluation and of the implemented solutions.


Check TRIM space on SSD Is it possible to 'view' the space that TRIM would take care of to see if that space was really wiped? I am using both Windows and Linux.

TRIM is handled internally by the SSD controller. There aren't any standard ATA commands to obtain this information, and if there are vendor specific commands it's unlikely they are documented.
A simplified example of TRIM:

The OS writes some data to the disk at location 0. At this point, the OS can read the data back whenever it needs to.
The OS no longer needs this sector, so it marks it as unused with the TRIM command. The OS can no longer read the data back, the drive controller won't return it.
If you were able to inspect the memory chips (and make sense of their contents) the data would still be present at this point.
The drive is now free to erase the data as part of internal maintenance. This process is slow, and can only be done a limited number of times.
If you were able to inspect the memory chips this information would now be gone.

Control of step 4 is entirely internal to the disk. It may happen nearly immediately, it may be some minutes (or longer) until the drive conducts background operations. This will be vendor and likely drive specific. However, from the operating system the data is unavailable immediately after step 2.
It's important to note that TRIM is a block level command and does not relate to files. The OS doesn't delete one file using TRIM, it deletes an entire disk block. When this happens will depend on the type of filesystem and the OS. Depending on how the filesystem stores data it may take considerable time before a whole block is ready to be erased. Therefore it's still possible to obtain fragments of files, deleted files, old versions of data from an SSD.
The OS could of course read all sectors starting at 0, ending at the last one.  However, only current data will be read. Any sectors that have been released to the disk with TRIM will not be returned and are effectively lost.
Does this mean disk forensics is dead? Absolutely not. There is still plenty of useful evidence in file system structures, sectors which have not been overwritten etc.


Safely sharing session accross sub-domains So I have a web service that is to be split up over several sub-domains.

So app1.xyz.com and app2.xyz.com.

Because Safari (last time I checked) does not allow for cookies to be shared across sub-domains like other browsers I need an efficient way to keep a user logged in as they go between the different sub-domains, on the same session.

On the face of it this should be an easy as sending the session_id in a the URL over https.

But is this good enough?

Both a cookie and a URL are sent over https so there is the same risk from decrypting the SSL certificate by snooping.

Is there anything else about sending the session_id in the URL that may be a issue?

Is there a better way, that is not over engineering things. Using oAuth seems like overkill to me, but maybe I am wrong?

You've misunderstood the cookie issue for Safari/Chrome, I think. Both of them implement the RFC properly, whereas Firefox/IE have been more relaxed in the past.

The normal rules are:

Setting a cookie for xyz.com does not allow any subdomains to read it.
Setting a cookie for .xyz.com allows all subdomains to read it.
Setting a cookie for app1.xyz.com only allows the app1 subdomain to read it, but not other subdomains.

Some browsers bend these rules slightly, and instead allow cookies without the . prefix in their domain to be read by subdomains anyway, regardless of the fact that the RFC says otherwise. If I remember correctly, IE/FF used to do this, but I think they've come more into line in recent versions.

  On the face of it this should be an easy as sending the session_id in a the URL over https. But is this good enough? Both a cookie and a URL are sent over https so there is the same risk from decrypting the SSL certificate by snooping. Is there anything else about sending the session_id in the URL that may be a issue?

You should never put session identifiers in the URL. There are a bunch of reasons for this:

They're visible on screen, so they're susceptible to shoulder surfing or leakage via shared screenshots.
They get saved, unsafely, in browser history. This could be used to recover session tokens in a multi-user desktop environment.
URL parameters usually get logged by proxies, load balancers, and web servers, which means active session tokens are saved in the clear in your logs.

It's just bad practice to send them in URLs - if you did it, and I pentested your app, I would certainly flag it as an issue.

  Is there a better way, that is not over engineering things. Using oAuth seems like overkill to me, but maybe I am wrong?

As noted above, I don't think your original problem is actually a problem, you just need to set the correct domain for the cookie. Once you've done that, you should be ok.

Also, since you've mentioned that you're using HTTPS for everything, I highly recommend the setting the Secure flag on your cookies to ensure that they can't be transmitted over plaintext HTTP. You should also look into setting a HTTP Strict Transport Security header to avoid sslstrip attacks. But these are just additional suggestions to improve security cheaply, and aren't directly related to your original question.


Guessing speed in offline password cracking What is the current speed an offline password cracking attack can be performed in guesses per seconds?

It is for sure heavily influenced by the used hashing-algorithm and the used hardware. But I am more interested in the general top bar achieved by a reasonable price without a botnet.

Since I need this information for my thesis, I would be interested in citable sources where this information is published. A scientific paper would be ideal.

In the question How can hackers get 1 billion passwords per second? 1 billion guesses per seconds are mentioned but without a source.

The zxcvbn test lists a speed of 10B / second for a fast hash with many cores. But it is also without a source and I am not so sure about what the B stands for. Billion would be quite a lot.

It depends on several factors.  Primarily, how are the passwords stored?

The current best practices are to use a key stretching algorithm. The NIST specifically states using key derivation algorithms that are like PBKDF2 and Balloon (13th paragraph, 5.1.1.2, not counting the bulleted list as a paragraph). The community typically lists PBKDF2, bcrypt, scrypt, and Argon2, with PHP providing bcrypt and Argon2 for its password_hash() function.

The link for Argon2 is to its white paper. Between this and the NIST standards, these are hopefully citable documents, and the Argon2 white paper includes additional citations.

The reasoning behind making their use a best practice, is these methods have configurable difficulties, and an administrator setting up the authenticator for their system should tune their chosen method to make brute-force guessing prohibitively expensive.

If the cost is tuned to require enough work for a processor core to be tied up for a full second, this has little impact on, for example, a web server that occasionally handles authentication. A user can be reasonably expected to wait for a second, and other users will be minimally impacted, as many web servers have multiple cores.

On the other hand, a naive attacker will only be able to guess one password each second, per core, and some key stretching algorithms specifically target features that make (expensive) memory more valuable (Argon2, scrypt), or make parallel processing, such as with multiple GPU cores, much slower (Argon2, bcrypt).  While a dedicated attacker will generally have more resources to devote specifically to brute force verifying passwords, they would still only be guesses tens of passwords per second, rather than the millions or billions of guesses possible with modern ASICs attacking hash algorithms.

If the passwords are stored as just salted hashes, though, there exists hardware that is especially suited for a very similar task, and it would take very little to design an ASIC that performs comparably: Bitcoin miners. While a hash guesser would probably be far more expensive on a per-unit basis, due to the economies of scale that Bitcoin miners enjoy, a single $2,400 unit can perform 14 trillion bitcoin hash guesses per second.

General purpose GPU-based attacks against hashes and common password encryption/obfuscation systems that don't use properly configured key stretching algorithms can typically make millions to several billions of guesses per second, depending on the algorithm, as shown in the benchmarks that Luc linked in a comment.


Practical and Secure use of KeePass Currently I'm using KeePass as my sensitive data manager.
I use just a main password to encrypt the database, but it is not very secure: 9 characters, lower letters and numbers mix with no meaning. Something like bwkvu5m8i

I want to increase the security of the database, without sacrificing usability much.

The only additional option in KeePass is to use a key file, which I can store on an external USB flash drive and plug it into the PC whenever I want to unlock the database. Knowing myself I will probably keep it plugged in 24/7, thus not being much different than storing the key file on the internal hard drive.

So are there any other options that doesn't make using KeePass very cumbersome?

My main concerns are keyloggers or trojan horses - I am an advanced user and would definitely not open any unknown files, regardless of their origin, but still I'm have the fear of being compromised. Is that even possible?

There's no way to sugar-coat this one. A malware/keylogger installed on your computer means that your passwords are exposed. That's it, there's no way around it.

A malware/keylogger will log your master password, intercept the clipboard, somehow access the decrypted database in memory, etc.


Is OCSP Request Signing Necessary? We can directly request OCSP Server for certificate status. Then why is there an option to sign the request? Is it to identify incoming requests or something?

The best I can find is from a draft version 2 of X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP proposal, which later became RFC 2560.  It states that:

  The requester signature is used to authenticate the requester to the
  OCSP Responder.  It is used in conjunction with the requester
  certificate extension defined below.

This document is also the first instance of the signature in the ABNF breakdown of the request.  Later versions of the document say even less about the subject.

The signature has to be optional as many (if not most) relying parties will not have a public/private key pair with which to sign the OCSP Request.

In addition to this vagueness, the The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments protocol defined in RFC 5019 says the following about signed requests:

  Clients SHOULD NOT send signed OCSPRequests.  Responders MAY ignore
  the signature on OCSPRequests.

In neither documents is there a reason for expecting a client to sign the request.


Recommended asymmetric algorithms for JWT? I'm implementing JWT authentication for a new web service and am unsure which asymmetric algorithm to choose. I've searched around and haven't found any consensus or clear recommendations. According to the PyJWT docs there are a few different algorithms to choose from.

I'd like to use an algorithm that is secure (obviously), has low overhead and is future proof. Which algorithm fits the bill?

The short answer is to use RS256, to be understood as SHA 256 with RSA 2048 bits keys.
See RFC 7518 JSON Web Algorithms (JWA) for all supported algorithms.
On signing algorithms
There are two major signing algorithms supported by JWT: RSA and ECDSA.

RSA (as in alg:RS256) is the classic asymmetric signing algorithm based on prime factorization. It's very well understood and extremely widely supported. There is no reason to use anything but RSA in my opinion. Recommended key size is 2048 bits.

ECDSA (as in alg:ES256) is an alternative asymmetric algorithm based on elliptic curves. It started gaining traction in the 2010's as an alternative to RSA. It's not quite as widely supported as RSA but it has some support (notably for SSH keys) and it is growing. It's useful to have two alternatives if one of them turns out to be broken in the future. I don't think there is a point in using ECDSA besides being bleeding edge, because RSA does the job just fine while ECDSA libraries are not as prevalent and have had issues not long ago.

See noteworthy vulnerability CVE-2020-0601 breaking elliptic curves cryptography in all Microsoft products and libraries. In short there was a small bug in the implementation so verifying stuff would verify nothing at all. You will re-use random libraries from the internet to verify JWT tokens in your various applications in various languages, I'd be wary whether libraries can implement ECDSA well when Microsoft and consort couldn't. RSA simply doesn't have this sort of bugs because it's simpler and libraries have been reviewed over decades.

HS256 (as in alg:HS256): A pre-shared key mode. There is one single key to both sign and verify tokens. The client and the server must both know THE key. I am not aware of any use case for this, so do yourself a favor and ignore HSxxx modes entirely.

On hashing algorithms
There are three major hashing algorithms supported by JWT: SHA256, SHA384 and SHA512.
They have increasing length to resist advances in computing power.
SHA256 is secure enough, it cannot be cracked in a reasonable time with a whole datacenter, there is no reason to favor the stronger slower algorithms.
Note that SHA1, 160 bits, was never supported in JWT because it was considered insecure and not future proof in the 2010's when JWT was planned.
Performance
When it comes to RSA vs ECDSA, there is no general conclusion that can be made on relative performance. Either may be faster than one another.
It's entirely dependent on the library in use and the specific CPU.
One point of having standard tokens it to more easily support authentication across your different applications (Python, Java, C, C#, etc...) using different libraries so it would be really misplaced to make any general conclusion on performance. You should run a benchmark for yourself if you care about performance.
For reference, verifying tokens is in the order of a millisecond broadly speaking (read as: it's much longer than a microsecond and it's much shorter than a second).
Do not confuse password hashing recommendations with JWT recommendations. Most crypto recommendations you will find on the internet (including stack overflow) are oriented toward password hashing (often with one of PBKDFD2/bcrypt/scrypt/argon), that is a use case designed and configured to be slow, possibly up to a whole second to compute a hash. JWT tokens have to verified on every "call" and are meant to be fast enough for API usage.
Key size and robustness
Recommended sizing:

SHA 256 bits
RSA with 2048 bits key
ECDSA with P-256 curve

See RFC 7518 JSON Web Algorithms (JWA) for all supported algorithms.
These are the recommended settings for the 2020-2030 decade. This can resist an attacker dedicating a datacenter to try to crack the key.
Authentication systems (using JWT) are meant to support authentication for external customers on the web and for internal employees in a company. It needs to resist this sort of attack.
Note that all large companies, universities, research centers and government instituations (#NSA) have compute grids at their disposal so it is really "trivial" to procure few thousands servers to brute force a key.
(Recommendations may be revisited in 2030 when AWS/Google will be renting whole datacenters of 60 000 future GPU).


How do application specific passwords work in Google accounts? I turned on 2-step verification and had to setup an application specific password for Outlook. I noticed the password generated is actually weaker than the one I had before turning on 2-step verification. Is it worth it? How exactly does the application specific password work, for example after the first time the app logs in does Google somehow remember some sort of finger print of the app?

EDIT: after reading the possible duplicate it is a very similar question. However, even the answers to that do not address if 2-step verification it's necessarily safer. In a nut shell the answers given say that it is very difficult to brute force the generated application specific passwords, but the same could be said about a normal password (without 2 step verification) so in this sense 2 step verification would be pointless?

Google just associates that password with only that service. You could reuse that password for that account across, say, multiple email clients connecting to Gmail. But you wouldn't be able to also use that password for Youtube.

As far as password strength, they use a 16-letter random password. Simple arithmetic shows that the entropy in a random 16-letter string is a little over 75 bits (2616 is roughly equal to 275). This isn't quite strong enough to use as an encryption key, but is more than strong enough as a password, particularly if they also use a slow-hash for storage.


Why is my internal IP address (private) visible from the Internet? When visiting some websites like http://www.monip.org or http://ip-api.com, I get the following result:

Your current IP Address
 - IP:    197.158.x.x
 - Internal IP:    192.168.x.x

I understand that I can see my public IP address (197.158.x.x). What I can't figure out is that how come my internal IP address is visible through the Internet?

Those websites do not seem to use a Flash plugin, Java applet or other scripts. My ISP is performing a NAT of my internal IP address in order to access the Internet:

3G Wireless Modem [192.168.x.x] -------- ISP [NAT to 197.158.x.x] ------- Internet

So how is it possible for a website to see my internal IP address?

The most likely source of this information is your browser's WebRTC implementation.

You can see this in the source code of ip-api.com.

From https://github.com/diafygi/webrtc-ips, which also provides a demo of this technique:

  Firefox and Chrome have implemented WebRTC that allow requests to STUN servers be made that will return the local and public IP addresses for the user. These request results are available to javascript, so you can now obtain a users local and public IP addresses in javascript.

It was recently noted that the New York Times was using this technique to help distinguish between real visitors and bots (i.e. if the WebRTC API is available and returns valid info, it's likely a real browser).

There are a couple of Chrome extensions that purport to block this API, but they don't seem to be effective at the moment.  Possibly this is because there aren't yet the hooks in the browser, as that GitHub README alludes to:

  Additionally, these STUN requests are made outside of the normal XMLHttpRequest procedure, so they are not visible in the developer console or able to be blocked by plugins such as AdBlockPlus or Ghostery.


Network Poisoning Outside ARP and DHCP If there is a firewall that can protect an infrastructure from ARP and DHCP poisoning attacks, are there any other protocols that I can spoof to poison the network?

ARP spoofing and DHCP spoofing can only take place within a broadcast domain, so no firewall will protect against them (except insofar as it helps keep malicious people off machines in the broadcast domain).

Other equivalent vulnerabilities, such as LLMNR and NBT-NS poisoning, are also limited to the broadcast domain.  By definition, any spoofing attack which relies upon the victim making a broadcast for information is going to be local to the broadcast domain.

DNS spoofing is one form of spoofing that is not limited by the broadcast domain; getting a bad record in any upstream DNS server or cache is sufficient.  Firewalls also lack any particular defense against this.


Usability and CSRF tokens In a lot of different products the CSRF token is stored in a session.

Which means that if the session has expired then the next form submit will fail.

Example scenario: you open a login form, the session is implicitly created if you didn't have one yet and a CSRF token is persisted in a session and is put as a hidden field of a form.

Then you wait until the session is expired (and garbage collected), then you fill your credentials and submit it.

Now even if the credentials are correct you will see the ugly "CSRF token is invalid" (or something similar) form validation error message.

So the question is: is there a secure way to improve this flow?

PS: ... apart of using AJAX to periodically poll some endpoint to keep the session alive.

(this question might be better suited for the User Experience site)

Change the error message to "We need you to log in again because you were inactive for more than XX minutes." Problem solved.

Let the user know how long they have exactly, because if they have to submit a complex form they need to be aware that they will need to collect whatever information they need and prepare whatever text they must input within a set time. Even better, monitor on which forms sessions tend to reset and use that information to figure out if you must support longer-lasting sessions.

Sometimes users might make a token expire before they even logged in as you pointed out. In that case, a formulation that is generic enough to cover both use cases will remove the need for you to try and test how the session looked like before it expired. You still need to address the confusion that such a message can cause for users who were not logged in before (their mental model might not accommodate the idea that individual forms expire rather than actual sessions).

You can do so by adding a "learn more" or "more details" link on your error message. Clicking that link can then display an additional paragraph that explains (succintly, and in very simple prose!) that Web login forms expire after XX minutes for security reasons, and the user was inactive for too long. You'll still need to ensure that additional text is visible to users without JS.

At this point you might as well implement your idea of serving a fresh CSRF token via AJAX when the user has been inactive for long enough...

Edit: some services directly display a timer indicating for how long the current page will be valid. You could go as far as implement such a timer on a standalone login page. This will at least prepare users to the idea that the page has expired / will expire, and can be especially useful if the page must be entirely refreshed when the timer expires. This being said, thee proper approach remains to never invalidate the existing login page.


What are the security concerns for base64 encoded JSON files? In a REST API, I'd like to receive images as base64 encoded strings in a JSON objects fron user's post and save them to disk using  node.js fs module.

The request body are objects like:

 { file: 'data:image/png;base64,iVBORw0KGgoAAA...

I'm wondering if there are some vulnerabilities associated with such file storage and how to avoid them?

First of all, there's all the standard web service security risks (connection security, authentication, authorization, session management, denial of service, logging, patching, etc.). I'm not going to talk more about those for now, but do bear in mind that you need a secure environment for something like this.

As for the risks specific to your system and ones like it... The most obvious risk comes if the users have any control over the filename the service creates. If so, you have risks such as file system traversal, overwriting of others' files, and so on. It doesn't look like you plan to do this, but it's something to bear in mind.

There's also the risk of uploading content that could be used to attack either the server or the other users. These attacks are easiest if the attacker can control the filename, but are possible if all they can control is the extension (and they learn the file name), and if there's a web API to download the file. To attack the server, upload a malicious file that the server will treat as executable (for example, a PHP page if the server supports those) and then navigate to it; this may not be possible if you're using a well-configured Node server. To attack other users, upload a malicious HTML file and try to trick other users into viewing it in their browser (resulting in stored XSS); this can be mitigated by making the files retrievable only from a different domain than the one for which the user has cookies / authentication, and/or forcing the browser to download the file rather than display it.

There's denial of service via simply uploading too much data. Consider how much data you'll allow users to store, and how you enforce that limit.

There's the risk of illegal content. The standard example here is child pornography; if users upload such content to your server and you are then found to be "in possession" of it, things could go badly for you. I'd recommend checking local laws, and ideally asking a lawyer, what your rights and responsibilities are when it comes to hosting user-uploaded content.

There's some risks to your JSON or base64 parsers, though these formats are simple and widely-implemented, so I wouldn't expect problems there. I don't understand why you want to use these formats, though; MIME content types are the standard way to upload files to a web server (and therefore feature built-in parsing in most web servers) and are less wasteful of bandwidth (base64 expands all encoded content to 4/3 the size, but there's no reason an HTTP request body needs to be composed only of printable characters).

Since you're storing a lot of user data, you need to consider at-rest data security. Encrypting the files individually, encrypting the whole volume, or using a transparently-encrypted external store are all potential ways to achieve this, but they also present the issue of key storage (as nearly all cryptosystems do). Don't forget to ensure your backups are also protected; tons of sensitive data has been leaked or stolen after somebody got ahold of the backup tapes or similar.

You may also want to consider the issue of user privacy. While not exactly a security feature, privacy (preventing unauthorized users - potentially including you, the service operator - from seeing what was uploaded) involves a similar mindset and is often provided using security tools (such as encryption). You tagged this question as "file-encryption", but you don't actually talk about encryption at all (base64 is an encoding, but there is no key involved; anybody who wants to can decode it, so it isn't an encryption scheme).


What is the impact of controling the content of a webview in Android? I'm learning android application pen testing and I'm kinda lost about what can do an attacker that control the content of a webview ?

I guess if there is no javascript enabled there is no impact, right ?
But if there is JavaScript enabled but no JavaScript interface or other dangerous setup, what can do an attacker ?

I know he/she can make an alert box or write anything on the page but it doesn't provide impact.

Is there some other things an attacker can do with javascript enabled and nothing else ?

Thanks

it depends on who the attacker & who the victim is in the whole equation. If we're talking about the attacker being an external party, who can potentially get some javascript executed in a vulnerable page inside the webview, then yes, to some extent your assumption is right. Without javascript interface enabled, there is not much that the attacker would be able to do to abuse the underlying app (the victim in this case).

However, if it's the other way round, where the victim is the page getting loaded inside the webview of the app (attacker controlled / malicious), then there's a lot that can be done to harm the victim, of course depending on how sensitive the victim page is.

I recently wrote a blogpost explaining this exact exploit scenario in (too much) details. You may want to check it out.


Is it possible to use Certbot for automating SSL certificates with CAs other than Let's Encrypt? Is it possible to use Certbot for automating the renewal process of the SSL certificates with CAs other than Let's Encrypt?

Yes, as long as the CA supports ACME. ZeroSSL and BuyPass offer free certificates with ACME. DigiCert seems to support requesting paid certificates through ACME.
To use this, you need to pass extra arguments to certbot, most notably --server.


Best password storage scheme for high entropy, unique passwords which is failure resistant What is the best, most secure, easiest way to:

store unique, strong passwords for every service which requires authentication
make the system resistant (total loss of security is avoided, breaches are contained) to multiple potential points of failure including:

loss of the password list
loss of any master password protecting the password list   - loss of a password
loss of two or more passwords which can be linked to the same person
keyloggers

While that technique may work for you, and will give you reasonable strength (from my quick skim through), the simple problem that at least 95% of the planet would have is:

It's way too complicated

Humans (generally) just won't remember those rules, and they'll lose the piece of paper

So while a quick answer to the specific question may be "it looks okay", its applicability is minimal.


How can I stop this DOS attack? I have this entry appearing constantly in my router logs:

[DOS Attack] : 5 [RST Scan] packets detected in last 20 seconds, source ip [xx.xx.xx.xx]

They just never stop.  It doesn't seem to affect anything, so should I be concerned?

Is there anything I can do in my router to stop the RST scan?

That seems to be a NetGear log entry, there are two possibilities for this:

SYN Port Scan: Someone (very likely automated, by an infected machine) attempting to scan your machine. They send a SYN packet to you, then your machine responds with an ACK packet. In order to prevent a connection from being established, they send you an RST (Reset) packet. (More likely)
DoS Attack: Someone (again, very likely an infected machine) attempting to flood you with RST packets. (Less likely)

In both cases, your router's internal firewall is responding by dropping those packets. You don't need to worry about that at all. You're on the Internet, something will always attempt to attack you.

And just to be sure, I've checked the IP address bothering you, it seems to be blacklisted for

  Portscans or hacking attempts were seen against an UCEPROTECT-System

Update: Just to keep the information up to date, I'd like to mention that the IP address is no longer blacklisted, which suggests that the infection is likely to have been cleaned.


Enabling virutalization, addressing the bluepill risk? Background to this question is the ambivalence I assume with virtualization. Also to start directly with clarity: the term bluepill should here be a placeholder to denote "malware that uses virtualization to hide and fixate itself on an attacked system".

My question is how I should deal with the risk of a bluepill when enabling virtualization on my computer? And more specific if there is a way to enable hardware supported virtualization Intels x86/i64 CPU's vt-x feature that would yet protect me from bluepill attacks?
To counter/address the risk that there might not be a 100% definite answer, I would consider it a big step forward (and an accepted anser) the enumeration of a set fact  based "best practice rules to enable vt-x and to prevent bluepill-type malware".

This could include i.e. a suggestion for a way to check for a bluepill infection? (i.e. using that during shutdowns/reboots bluepill would need to store/conserve itself and hece become detectable on the harddisc)

The motivation to the question is:
On my system Intel iCore processor's the vt-x cpu feature can be enabled and disabled in the kernel.

disabled: bluepill attack impracticable, but no virtualization based security benefits
enabled: bluepill attack possible, but virtualization based security benefits enabled.

I have gone through "The How secure are virtual machines really? False sense of security?" which has not given no consideration to the bluepill aspect yet. Therefore I think this question can enrich the topic of virtualization-security.

There are two aspects to bluepill: how the infection happens and whether you can detect it once it happened.

The first aspect is the same as for all malware really. The novelty aspect of bluepill was the "it's undetectable" claim.

There was extensive research on that, and several methods have been devised for detection.

You should note that, as of yet, there were no bluepill threats seen on the wild.

Detecting if the OS is running inside a VM

The first published methods for detection involved timing. From an interview with Anthony Liguori:

  Hardware virtualization requires a technique know as “trap and
  emulation”. The idea is that the hardware traps certain instructions
  and the VMM emulates those instructions in such a way as to make the
  software believe it is running in a virtual machine.

  Software emulation implies that these instructions take much longer to
  complete when executed under a VMM then on normal hardware. This fact
  is what can be used to detect the presence of a VMM.

  I approached Rutkowska about this and she attempted to address it in
  her prototype by adjusting one of the processors clocks on every exit.
  However, there is nothing that she can due about external time sources
  and she’s admitted to this on her blog.

  She refers to this as a theoritical weakness in her system but I
  assure you that it is quite practical to exploit.

The original author of the bluepill concept (Joanna Rutkowska) also published another paper (RedPill) which might be leveraged to detect a BluePill rootkit.

I couldn't find the paper, but found this excellent summary:

 int swallow_redpill () {
   unsigned char m[2+4], rpill[] = "\x0f\x01\x0d\x00\x00\x00\x00\xc3";
   *((unsigned*)&rpill[3]) = (unsigned)m;
   ((void(*)())&rpill)();
   return (m[5]>0xd0) ? 1 : 0;
 }

  The heart of this code is actually the SIDT instruction (encoded as
  0F010D[addr]), which stores the contents of the interrupt descriptor
  table register (IDTR) in the destination operand, which is actually a
  memory location. What is special and interesting about SIDT
  instruction is that, it can be executed in non privileged mode (ring3)
  but it returns the contents of the sensitive register, used internally
  by operating system.

  Because there is only one IDTR register, but there are at least two OS
  running concurrently (i.e. the host and the guest OS), VMM needs to
  relocate the guest's IDTR in a safe place, so that it will not
  conflict with a host's one. Unfortunately, VMM cannot know if (and
  when) the process running in guest OS executes SIDT instruction, since
  it is not privileged (and it doesn't generate exception). Thus the
  process gets the relocated address of IDT table. It was observed that
  on VMWare, the relocated address of IDT is at address 0xffXXXXXX,
  whereas on Virtual PC it is 0xe8XXXXXX. This was tested on VMWare
  Workstation 4 and Virtual PC 2004, both running on Windows XP host OS.

Another method is reviewed in this article is from 2008:

  The idea is to intercept a hypervisor's start by another hypervisor
  (let’s call the latter a Virtual Intrusion Prevention System, or
  VIPS). When any hypervisor (malicious or legitimate) starts, it turns
  VM root mode on. This event can be easily intercepted by a VIPS. So
  what's next? There are 2 ways to handle this event: blocking a
  hypervisor completely, or allowing it to work through emulation.

  The first way consists in emulating a PC with disabled HVT feature in
  BIOS. This will block a HVT rootkit from working.

  The second way consists in allowing a hypervisor to work through
  emulated hardware virtualization (or nesting). This should be done for
  legitimate virtualization software.

  In both cases (blocking or emulating), a VIPS intercepts a hypervisor
  at the moment it tries to start. VIPS can read the hypervisor’s body
  and analyze it. A notification message can be shown.

Is this really a threat

Then there's the practical aspects of the attack to consider.

A bluepill rootkit needs to implement xen or something similarly complex, which is a huge endeavor. Since there really is no guarantee it won't be detected or blocked anyway, attackers will choose an easier path which is classical rootkits.

I believe this is part of the reason why bluepill rootkits haven't been seen on the wild.


Is there a risk to a business that is using a shared certificate? I was looking at my bank website's certificate and discovered that it's issued to multiple websites, and the bank's domain name is only listed among many other domains in the 'alternative names' field.

Is this considered a bad practice? What risks are their customers subjected to? (man in the middle? impersonation?)

It is a certificate of a content delivery network – a U.S. company Incapsula Inc. – intercepting your whole communication with the bank. The certificate itself does not pose a direct risk to customers' data, but:

  Is this considered a bad practice?

Unlike the other answers, I would say it is not normal and the situation indicates a certain level of incompetence on the bank's side.

According to Incapsula's pricing plans, your bank might be using $59/month, while the company offers custom SSL for $299/month (feature "Supports custom SSL certificates") and a real plan for enterprises.
Even if the bank pays more to CDN, the bank is using functionality aimed at professional blogs and not using the features their plan/agreement offers.
Your bank may be violating privacy laws in your country by letting a company from another country, under a different legislature, process customers' personally identifiable data.

  What risks are their customers are subjected to? (man in the middle? impersonation?)

The data in a encrypted between your browser and the CDN's endpoint. The private key is (hopefully) stored only on CDN's servers, so there is no risk other companies from the list could impersonate the bank.

As long as security standards are met on a link between CDN and the bank, the MitM is technically not possible either.