Can't overwrite rip with address in simple buffer overflow (Ubuntu x64) I wrote a simple c program in order to test an buffer overflow.
My goal is to overwrite the rip so it points to the beginning of the buffer.

The code:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main(int argc, char **argv) {
char buffer[256];
strcpy(buffer, argv[1]);
printf("INPUT: %s\n", argv[1]);
return 0;
}

When i write
r python -c 'print "A"*264 + "BBBBBB"'
in gdb the rip is correctly overwritten with:

RIP: 0x424242424242 ('BBBBBB')

The beginning of the buffer is at 0x7ffffffede20.
So i tried
r python -c 'print "A"*264 + "\x20\xde\xfe\xff\xff\x7f"'
in gdb to overwrite the rip but it doesn't work anymore.
This is the content of rip (copied from gdb):

RIP: 0x7fffff050800 (<__libc_start_main+192>:
add    al,BYTE PTR [rax])

Why does it work with the "BBBBBB" but not with the address?
And i also tried

r `python -c 'print "\x90"*264 + "\x08\xde\xfe\xff\xff\x7f"'`

And for some weird reason this works again with the address
0x7ffffffedf08.
But just not with the one i need.

(Compilation:
gcc mybof.c -fno-stack-protector -z execstack -o mybof)

Please explain what you mean by "doesn't work". I am not able to comment because of my reputation.

I tried out your running your program and I used the same exploit. The exploit works fine.

I am able to think of 2 reasons of why it may not be working.

I hope you have disabled ASLR. Even if it is disabled, sometimes, the addresses change. But the change won't be as random when ASLR is on. So, make sure you take care of this.
Another reason why you feel/think it is not working could be the following:

This is the exploit code in the stack(buffer):

0x7ffffffede20: 0x90909090...................9090-0x20-0xde-0xfe-0xff-0xff-0x7f-0x00-0x00

The first 264 bytes are NOP bytes. Next 8 bytes is the Address of buffer.

RIP value will be the address of the buffer and then control is transferred to the beginning of the buffer.

Now, all the NOPs get executed one after another. When it encounters the bytes 0x20-0xde-0xfe-0xff-0xff-0x7f-0x00-0x00, this is no more an address. This is just 8 bytes which will be executed. I hope you get this point. They will be executed only if they are valid instructions. If they are not valid, the program SegFaults.

This is what the processor interpreted those 8 bytes as: (output of gdb-peda)

[-------------------------------------code-------------------------------------]
    0x7fffffffd975: nop
    0x7fffffffd976: nop
    0x7fffffffd977: nop
 => 0x7fffffffd978: jo     0x7fffffffd952
    0x7fffffffd97a: (bad)
    0x7fffffffd97b: (bad)
    0x7fffffffd97c: (bad)
    0x7fffffffd97d: jg     0x7fffffffd97f
                                                             JUMP is NOT taken

Continuing, the program got killed due to SIGILL - (bad) instruction.

When it run normally without a debugger , it is seen as a Segfault.

This may or may not be the reason.

Would really help if you show some output of what is happening, why it is not working. We can dig deeper and find the cause.


Block mobile tethering on android phones from Windows (DLP) In our small organisation I have tried my best at implementing DLP by:

Making sure users access all files from the server
Local disks are denied access (forced to work only on network drives)
Disabling mass storage
Implementing IPSec to block users from communicating with any other IP except the server IP and Firewall (cyberoam)
Blocking as much sites as possible in cyberoam like file storage sites, mails etc.

But there are 3 major problems I have not been able to solve with the above methods:

Ultrasurf
Proxy sites
And the biggest problem of them all, using android phones internet via USB mobile tethering to bypass cyberoam.

I have spoken to cyberoam about the above 2 problems and they are working on it.
Any solutions how to prevent the 3rd problem?

Any help on how to implement a cost effective DLP solution would really be helpful.

Some antivirus software like Sophos can disable network bridging, which will prevent any wireless from been connected while the network cable is plugged in. We use this to stop people tethering while connected. You will need to block USB/Bluetooth at the OS to stop tethering there.

Once a users laptop network leaves the premises you can use group policy (if Windows) to black/white list SSIDs. If you don't do this then nothing to stop a laptop user from going down the street to a coffee shop for the same effect.


Which real time cross-platform chat applications exist with end-to-end encryption? I am looking for an instant messaging / chat application which can be used securely across different platforms, eg Windows, Linux, BSD!

Do any exist?

http://www.cypherpunks.ca/otr/ is a plugin for several clients. I've used it with Adium on OS X and with Pidgin on Windows. It also works with Pidgin on Linux.

The greatest part of this is that it is protocol independent -- you can use it to secure conversations on Google Chat, Jabber, AIM, etc.


Is it okay for our IT support contractor to remote in without authorization? We are a healthcare IT company.  My machine has PHI on it.  Our IT contractor verbally asked if he could remote in to fix my printer so I said sure.  I expected some sort of prompt to allow it but he was just in.  Some form of VNC I guess.

Is this okay?  In regards to HIPAA?

You haven't actually provided enough details to say one way or the other.  The fact that you didn't see an authentication prompt doesn't preclude there from being one.

The remote access tools I use in my job (which also deals with HIPAA) both require me to authenticate with my domain admin credentials and do not prompt users to accept the connection, because I've configured them that way.


Why the need to hardcode passwords? Many IOT devices and routers manufacturers hardcode plaintext default passwords in their devices.
Why don't they store the hashed password instead?
For what functionality do they need the plaintext password?

I think you may be getting confused with server-side password hashing.  Server-side password hashing is essential for any system worth its salt (pun intended), to prevent users' passwords from being leaked in the event that the user database is compromised.  But, it only works because the server just needs to verify when a client provides a correct password; the server never needs to provide the password. IOT devices, on the other hand, are usually clients. So, they need to provide the password to authenticate with the server. Therefore, IOT devices need the actual password, not the hash of the password.
See https security - should password be hashed server-side or client-side? for more information on common misunderstandings about client-side password hashing.


What maximum password length to choose when using bcrypt? When I generated password for GitHub with KeePass I got a message on GitHub site that said the limit for password length is 72 characters. It seemed weird it not being a power of 2 so I googled a bit and it appeared that 72 is the max bytes for brypt algorithm. So it seems logical to restrict the number to 72 as longer passwords would be truncated to 72 anyway.

Then I generated password for Discord and it appeared that the max length is 128 characters. But I thought that I'll check if the first 72 characters from my password would suffice. And yes, my 128 character password is also truncated to 72 first ones, so I guess Discord is also using bcrypt.

So the question is, is it better to just set the password length limit to 72 characters or let users choose longer passwords (how long? 128, 256 bytes?) even though they will be truncated?

The first criterion is security and only then usability, storage or difficulty of implementation.

I don't favor silent truncation because it misleads the users into thinking that their entire password was accepted when it wasn't.  I'd prefer a system just set a maximum length, if necessary, and restrict the user to that during password input.  One bad scenario I've heard of is a code change that begins processing characters beyond the previous max length and suddenly the longer password users can't log in.  The system only has a record of the first 72 characters and their longer string doesn't match that without the old system truncation.  That leads to frustrated users.

As an alternative to truncation at 72 characters you should consider pre-hashing the password with something like SHA-256.  The allows the user's entire password string beyond 72 characters to be considered while still providing the computational protection of bcrypt.


Potential DOM Based XSS? I am currently working on exploiting a potential DOM based XSS on a web app. Currently all of my XSS attempts have been thwarted by Internet Explorers XSS auditor, even after disabling it. While investigating I noticed that the query parameter was outputting weird results if I replace the "=" with "[ ]" which reflects on the web app.

Example site: www.example.com/search/?q=apples

 Output: expected

Removing the "=": www.example.com/search/?q[1]

 Output: {"1"=>nil}

The {"1"=>nil} reflects in the website, so the URL is being interpreted with odd results in the website.

Another example: www.example.com/search/?q[Object.prototype.foo][cool]=chill

Output: {"Object.prototype.foo"=>"chill"} permitted: true>}

From my understanding, the above is Ruby. Could this be exploited with the DOM based XSS?

Currently the vulnerable libraries the web app is using are:
     jQuery v1.12.4
     React v0.13.3
     React (Fast path)v0.13.3
     Moment.js v2.13.0

Any help would be greatly appreciated.

If your exploit works but is being stopped by the XSS auditor then you have found a real and reportable XSS vulnerability.  The XSS auditors are very finicky, all of them have workarounds, and they have already been deprecated in the latest versions of Chrome.  Therefore, if you are seeing the XSS auditor take action then you have found an XSS vulnerability that will be causing real world trouble shortly.

If you're doing penetration testing, I would try to figure out how to disable the XSS auditor in your browser.  Just pretend it isn't there, because for the purposes of bug bounties it really shouldn't matter.

Of course it is always possible that a company somewhere may reject a vulnerability report because when they try to reproduce it they are stopped by the XSS Auditor.  However rejecting a vulnerability for that reason would represent a gross misunderstanding of the purpose of the Auditor, and the simple fact that browsers have started removing it because it causes more problems than it solves.  It is certainly a point I would argue.  The Auditors are meant to be a stopgap measure, not an actual line of defense (and will be gone soon enough).  However if a company stands firm in rejecting a vulnerability report because of the Auditor stepping in, then you would obviously have to find a workaround for it.  As I mentioned, all the Auditor's have workarounds, but they are also browser dependent which can make it a bit tricky.


Differences between using Tor browser and VPN I can't quite figure out the differences between using the Tor browser and using a VPN (like concretely proXPN). From what I understand the idea is the same, that they both hide the IP address. The only difference that I can see is that Tor seems slower because it has to pass through several computers.

So is using the Tor browser better in terms of hiding your identity and online traffic? Is there a difference between who can see your traffic?

(I am guessing that there is a difference.)

(I see this question Which is more secure - a VPN, a proxy-server, Tor, etc.? And why so, exactly? was closed as being too broad, but I hope my question is a bit more concrete.)

TL;DR

Tor provides anonymous web browsing but does not provide security.  VPN Services provides security (sort of) and anonymity, but the anonymity might be more in question depending on the service.  Since you're depending on them not logging pieces of information that may or may not be able to be traced back to you.

VPNs

Traditional
A traditional Virtual Private Network does not extend your ISP.  A VPN extends an existing private network across a public network.  For example, let's say my company has a private network with email servers, web servers (intranet), and DNS setup for company related services.  It's a private network for company employees only.  However, some employees want to work from home.  A VPN is set up so that employees can securely connect to the private network remotely.  This provides two features:

Authentication - Users present their credentials to gain access to the VPN
Encryption - The entire tunnel between the remote user and the private network's gateway is encrypted.

Take that last statement: "The entire tunnel between the remote user and the private network's gateway is encrypted."  Once you're through the gateway, communication is un-encrypted. Unless the services within the private network itself use another means of secure communication.

Keep in mind that no anonymity is provided by this setup.  In fact, the company knows exactly what IPs are connecting to its private network.

VPN Services
Nowadays VPN seemingly takes on many meanings, and online/cloud/[insert Internet buzzword here] have complicated things.  We see questions now, "Which VPN takes your anonymity seriously?"  What has happened is that VPN Services have become a kind of "secure anonymity service".  A service will provide secure communications to a proxy server that will then dump your communication out into the clear to whatever your destination.

This is kind of like what a traditional VPN does, except now the statement of "a VPN extends your ISP" is kinda true.  Now you're just encrypting the first half of your communications.  It extends in the sense that you can access websites and services you might not normally be able to due to your geographic location.  But "extends" really isn't the right word to use.

Take ExpressVPN for example, it advertises the following:

Encrypt your Internet traffic and hide your IP address from hackers and spies.
Access any website or app without geographic restrictions or censorship.

Take out "Encrypt your Internet traffic" from the first statement, and you basically have an anonymous proxy.  But now that the tunnel is encrypted it's a VPN to your anonymous proxy (gateway) that then forwards your traffic on, into the public Internet.

Tor Browser

Onion Routing

Onion routing was designed to provide complete anonymity to a connection.  It accomplishes this with encryption.  Three layers of encryption.  When using the Tor Network a path is determined with a minimum of 3 nodes (can be more).  Encryption keys are setup and exchanged between you and all three nodes.  However, only you have all of the encryption keys.  You encrypt your data with each of the nodes' keys starting with the last node's (exit node) and ending with the first (entry node).  As your data moves through the network a layer of encryption is peeled off and forwarded to the next node.

As you can see the exit node decrypts the last layer, and forwards your data to its destination.  Which means your data is in "plaintext"1 at this time, but complete anonymity is accomplished.  With at least 3 nodes no node knows both the source and destination.

Anonymity not Security
Tor does not promise secure communications.  Encryption is only used to provide anonymity between nodes, your data is not encrypted otherwise.  This is why it is still highly encouraged to use HTTPS-enabled websites while using Tor.  As @LieRyan mentioned in another thread's comment, sending personally identifiable information through Tor without using other security measures will break any anonymity that Tor provides.

Traffic Visibility

As far as traffic visibility if there is an admin on the network they will be able to see your traffic. Let's take a situation with a VPN: you have your remote laptop R and your private network gateway/secure anonymous proxy (G).  Now you have a private network IP that is encrypted from R to G.  A network admin sitting on G can see your plaintext1.  As stated above if you are using another secure protocol like SSL/TLS through the VPN/VPN Service then the "plaintext" is really encrypted, and the network admin would not see anything but encrypted data.

So this really depends on where the network admin is sitting in the connection, and whether or not you use a secondary secure protocol underneath the VPN.  This same logic applies to Tor.  Because as I stated earlier encryption is only used for purposes of maintaining anonymity.

Both traditional VPNs and VPN services are to protect against external visibility into the network.  Neither of them will protect you from authorized administrators for the network you're on.  It's all about protecting your data from unauthorized eyes.  Even with SSL/TLS, a website that you're visiting sees your decrypted traffic.  It has to in order to process the request.  Admins on that website can see those same requests and/or log them.  It's the security protocols used initially and in between that make the biggest difference in the security of communication.

1 It's plaintext as far as the data that was sent is seen here.  If the data is encrypted with something like SSL/TLS before going through the onion routing then the encrypted data would be seen at this point.


Can I check the content of a suspicious file directly on the server using an editor, e.g. vim? in the Wordpress directory I found some suspicious-looking files with random strings in their name e.g. uxs5sxp59f_index.php. Can I safely check their content ? I have a suspicion that the site has been infected because some of its links on external portals to the site with the malware.

In order for the opening of the file to pose a risk, the file would need to include an exploit for the specific text editor you use. Then when you open the file, the exploit would trigger.
While possible that's not very likely. It certainly isn't common.
The far more likely threat is that there is malicious PHP code in the file that triggers when the file is executed by a PHP server.
But all that aside, I'm not sure why you are questioning whether you have been infected when you are looking at files being served that you did not create and there are links to malware. You've been infected. Start with that assumption...


Security Implications of Google's Two Step Authentication’s Backup Codes Sometimes, when I log in to Google, it asks me to print out some backup codes for the two step verification process. This seems like a big back door that breaks the whole point of two step verification to me. None of Googles help articles address this concern at all.

What are the security implications of printing out backup codes?

Think of it as writing your log in password in a piece of paper since they both serve the same function. The risks associated with it are related to physical access to where the print out is stored, accidental snapshot (office pictures) and the like, in some odd cases even a print queue could allow to print a second time.

At the same time think of storing sensitive information in usb sticks, you may consider encrypting the files or the entire usb drive, but you are still prone to losing it.

Shoulder surfing is also a risk, if you need the piece of paper 5 times a day that's 5 times a day someone can be looking over your shoulder and writing down a couple of digits.

You are right in that this method of authentication is less secure, Im sure they faced a scenario where this was necessary but I would say unless you yourself are faced with that specific situation going with 2-step authentication methods is in general safer. For example, if you use your phone to receive a token, an attacker would need access to your phone, and would need to unlock your phone, which although not impossible it adds an extra layer of complexity.


Using stored creds in a metasploit module Metasploit smartly stores your creds in its internal database, whether you've manually entered them by using a previous module or whether you've dumped them with smart_hashdump. You can view stored creds with creds.

I've searched, but without result, if there is a way to "plug" stored creds into a module. For example, when using psexec exploit, is there a way I can tell metasploit to use a set of domain/login/hash from the creds DB?

Something like "set creds admin", where admin is the username associated with stored creds.

If i remember correctly, psexec is part of the smb exploit kit. I think what you are looking for is the complimentary scanner kit.

use auxiliary/scanner/smb/smb_login

then go through and set the common options the same as you would in your smb exploit except there is one option here

db_all_creds

set this to true, and run the scan. you will now know which users to use in the psexec exploit.

is that what you are looking for? The reason most exploits don't plug like that is that sometimes you will break whatever it is you are exploiting, running it against multiple hashes might be worthless, and misinformative.

so first you scan what users can connect. Then run the corresponding exploit with those accounts.


How many bytes should an authorization token have? Assuming I generate random bytes with a secure PRNG, how many bytes do I need to make authorization tokens secure?

Specifically, when users log in to a website, a token will be generated and stored in a cookie to authorize future requests.  Server-side, the token will be stored in a database and looked up when a request is received.

Since authorization tokens are random, your primary attack vector is brute-force guessing.

In an online attack, your defense strategy may limit the guess rate or total allowed guesses and therefore limit the necessary bit length.

An offline attack is more interesting, if such an attack is possible in your environment. With today's technology, 64 bits (between 10 and 11 characters alphanumeric) is just at the edge of guessable given a fair amount of time and a silly amount of money. On the other hand, 128 bits (between 21 and 22 characters alphanumeric) is beyond the reach of brute-force attacks pretty much indefinitely unless our understanding of time thermodynamics drastically changes.


With openssl des3, what are the passphrase parameters? I'm using OpenSSL's des3 tool to encrypt a file, e.g.

openssl des3 -salt -k SUPER_SECURE_PASSPHRASE < inputFile > outputFile

Everything's working, but now I have to choose a final, fixed encryption passphrase. It doesn't need to be memorized, so obviously I'd choose some sort of randomly generated characters. However, how random is useful, and how long is useful? I'm concerned that I'll unknowingly be throwing away useful entropy.

For example, AZQBB would be a poor passphrase, probably both because of length and limited character set. But, would kecqnutaspyyhgheikfzuwkjaoitqooasujjfhhsiiwqoekihaeyhflpijfmnhssdyyy be poor due to its limited character set? Or, would dU# i?|m:v be poor due to its length? It all matters how openssl uses the passphrase to generate the bits of the encryption keys, and I haven't found that documented anywhere.

As another example, if openssl just gets its 156 bits from the 8-bit ASCII representation of the first 21 characters of my passphrase, then if I restrict myself to non-control-character low-ASCII I'll be throwing away approximately 30 bits of entropy.

So, for a highly secure passphrase, my questions are:

How long a passphrase do I need?
How diverse a character set do I need?

"openssl des3" is really "openssl enc -des3". The password-based key derivation is a custom, undocumented scheme which, as far as password-based key derivation schemes go, is quite weak; see this answer (especially at the end) for some details. Basically, this is equivalent to hashing the password with a couple of MD5 invocations.

What matters for passwords is entropy, i.e. not the password length or the type of characters used; entropy is a measure of what the password could have been. See this answer for details on how to compute entropy. Remember that entropy is not computed on the password itself, but by analysing the process that generated the password.

Since the key derivation scheme used by OpenSSL is quite bad, you need a lot of password entropy to achieve decent security. As a rule of thumb, the limit of computational power of serious attackers is 280 invocations of a cryptographic primitive like MD5 (rich attackers like the NSA would have much trouble reaching such computational levels; even very rich organizations like Google or Apple would find it quite challenging, and would not be able to do it discreetly). In this case, since trying a password means roughly computing two MD5, this means that the password entropy should exceed 279 -- i.e. "79 bits" because entropy (in cryptography) is normally expressed in bits (which is a logarithmic scale).

IF you generate your passphrase as a sequence of random characters in a given alphabet, with each character being selected randomly, uniformly, and (crucially) independently of the other passphrase characters, THEN entropy can be easily computed: if you use n lowercase letters (26 choices for each character), then entropy is 26n. With n = 17 (17 random lowercase letters), then entropy is close to 280, i.e. 80 bits, which, as explained above, should be sufficient. Even a small character set can be compensated for by using a long-enough passphrase, because what really matters is the entropy, not the length or the kind of character.

If you try to generate passphrases that "make sense" in some way for a human, then entropy is a lot more difficult to compute, because human psychology is very bad at randomness. Again, see the answer on entropy computation.


Does Skype Trump SSLStrip? I am using SSLStrip against my own computer, but am not being redirected to HTTP. Skype automatically starts up and logs in at my computer's startup, so I was wondering whether the fact that port 80 is already in use (by Skype) defeats SSLStrip. It is my understanding that except for the fact that they are being redirected to a non-encrypted connection, it is impossible for a victim (or their AV) to tell SSLStrip is being used against them. If that is correct I would like to know if anyone has a way to cause Skype to restart on the victim computer so I can get port 80.

SSLStrip does not downgrade from HTTPS. It tries to prevent upgrade to HTTPS.
I think this is a misunderstanding of how SSLStrip works.
The idea is that SSLStrip stops plain text HTTP sites from upgrading to HTTPS. It will not work if you start by entering "https://" in your browser right away.
What it does is that it installs itself as a man-in-the-middles and then transparently forwards traffic largely without changing it. HOWEVER: If the HTTP page contains any HTTPS links then SSLStrip will "strip" these HTTPS links out and replace them with plain old HTTP.
So if your web server does not even speak plain text HTTP, on default port 80 or elsewhere, then you can't upgrade to HTTPS either. And in that case SSLStrip is not the right tool for whatever you're trying to do.


Keyloggers - Ports used by keyloggers According to this article, keyloggers usually make use of the FTP ports and email ports:

http://rbmikrotik.blogspot.com/2011/07/how-to-block-port-frequently-keylogger.html

My question is, can a keylogger software make use of other ports within the network so that it sends the information to the attacker?

A keylogger can use literally any form of communication to send its data back to the attacker.

Common methods:

FTP upload
Email
IRC
HTTP POST
Connect-back (i.e. attacker connects to a service listening on your machine)
P2P network (e.g. Gnutella or BitTorrent)
Custom protocol running over TCP or UDP, directly to the attacker.

Note that any of these services can be set up on any port, since the standard port is just for ease-of-use. As such, you might find an IRC server operating on port 50321 rather than 6667, or an FTP server operating on port 80 rather than 21.


Masking configuration of physical workstation Environment:

Physical workstation, HP, Dell, etc
Windows 7,8,10, no matter
Windows executables

Our goal:

For additional privacy, is it possible to wipe/change all configuration that can be read by windows executable? (Including mac address, list of software, keys, fonts and other hardware related information) basically I’m interested if there is such software already developed to generate fake configuration for windows OS.

Please share any ideas you have on this matter.

There are myriad of ways to fingerprint a system from the OS version, registry entries, functionality advertised, driver versions, applications, hardware available (chipsets, drivers associated, etc.).

Trying to fool all methods of fingerprinting a system is likely a task that's not worthwhile.

You may accomplish a similar result by sandboxing applications which you would like to hide this information from.

Alternatively you could use a virtual machine since they typically look very similar to each other (hardware emulation) but that doesn't hide the OS or other applications.

Attempting to fool applications can also lead to unexpected and potentially damaging behavior. A program which thinks it's running on Windows 98 is going to behave differently than one that thinks it's in Windows 10. This may result in security issues if programs attempt to use "compatible" but insecure methods (e.g. SSL 2, or 3 instead of TLS; MD5, RC4, etc. )


3000 new contacts being added to gmail after receiving an email Recently I realized that there are three thousand contacts with same name and email address in my Google contacts. The name belongs to an email that I have recently received and responded to, nothing special existed about the email.

Could this be an attack or simply a bug in the services which I use? I use my android smartphone synced with my account as well as gmail itself.

It seems to me that, as a hacker wouldn't, to my knowledge, benefit from this at all (unless it is some kind of attack meant to overload a process??? seems unlikely...) this is almost certainly just a glitch. By default, Google usually adds anyone you respond to to your contacts; in all likelihood it just had a minor glitch. If the hacker thought you would not know how to remove contacts en masse he might have thought to exasperate you and make you decide just to leave the contacts there after a few hundred deletes. I think e-mail from contacts goes to your inbox automatically, even if it does not pass spam filters, so it might have simply been phase one of a spamming scheme? Maybe check your spam periodically to see if there is anything in there from this address - just out of interest.


Is there a solution for runing processes in encrypted mode on runtime? Is there any solution for securely running encrypted processes on an untrusted machine over the WAN?

In public clouding, you can split your processes and send process request over the WAN, but you can not detect whether machine who wants to run your processes is secure or not. If there is malware running with sufficient privileges, it will have access into all resources of remote machine. Therefore, the system is not secure for running our processes over the WAN.

This is important because when we send a process request for a machine we must check the result is correct or not. We can check it by using some models like SHA or MD5 hash code but there is a problem. In this model of public clouding, the insecure destination machine will create hash code. Therefore, we can not trust on that hash code because we don't know how many machines that received our code were compromised and we don't know returned results that we received are correct or not.

Because of this problem we can not trust into result of processes over the WAN.

Is there any solution for resolving this problem? Is there any solution for running a process over the WAN in trusted mode? in every operating systems we had this problem. We can access on resources of a system by using low level programming and because of that there is no protected memory option in any operating system that I know.

This is a fundamental problem with using a system you don't control. You don't control it and cannot force it to behave.

You hinted at one solution in your question. Send a single request to multiple remote systems and compare the results. If they are different, one of them is wrong. It doesn't matter if it's compromised or buggy. As long as you have enough systems to reduce  the likelihood of compromised systems outnumbering secure systems, you can use the result agreed by most systems. This is what NASA does to deal with cosmic rays flipping bits.

You could ask them to perform hard operations whose results are easy to verify. For example, let the remote system find all prime factors of a large number, then you multiply the result together to determine if the result is correct.

Another option is to send the remote system only the data it cares about. If the result is wrong, only that system('s user) cares and is the only one penalized. For example, if they need to answer a question correctly to earn money, and incorrect answers won't earn money, then they will want to get the right answer. If they fail to secure their system, they are harmed but not you.

If you are trying to hide a secret from the remote system but still want the remote system to operate on the secret, then you cannot send them the secret. You may be able to send them part of the secret, from which they are unable to reconstruct the original secret. There is a branch of cryptography related to operating on encrypted data. In theory, this would let you send data to a remote system, the remote system would operate on the data, and you would check the result. Last I heard, that's not really viable because you can only perform ne add/multiply operation on the data before you have to decrypt and re-encrypt. The crypto will be more expensive than the add/multiply operation and so doesn't help us with anything. Yet.


How to step through malicious JavaScript? There's a Facebook virus doing the rounds: Your face in 20 years (safe link, but don't follow the instructions).

It clearly grabs some Javascript from a url (e.g. changeups.info/age/u.php?0.5069423061795533) and runs it on your page, which posts on the walls of all your friends. The problem is I can't access the script (and investigate what it's doing) without being signed into Facebook (since it's a Facebook page, using the API, it'll just ask you to log in if you go to the url), which I obviously don't want to do.

Is there a way of safely stepping through Javascript so that I can download the script and avoid the malicious effects of it?

Don't step through it, instead use an interactive proxy (I'm partial to Fiddler, there are many others...).
When the javascript is downloaded, it will first pass thru your proxy tool - you can grab it, save it out, and then block it from going on down to your browser.

Since you know it's malicious, you'd be better reviewing the source rather than executing it, especially in the context of your account.

If that's not good enough, and you want to execute it, create a new account and login with that, from a throwaway VM.
No reason to try and sanitize potentially obfuscated and evasive malware... Just isolate it.


Is a company's dark web search really effective at proving my info is not there? Prompted by this question. My take is that the security companies and banks that offer identity protection services use the phrase "dark web" as a scare tactic to get you to subscribe. And then when they say they don't find your info in the dark web, you are safe. My guess is that most if not all dark web sites don't even allow anyone to scrape for info. "Legitimate" users of dark web sites will have exclusive access to the data store there.

Do these security companies provide any value by "searching" the dark web?

This borders on being a scam. The "dark web" does not contain what people think it does, and it is not vast or all-encompassing. Hackers do not just randomly put stolen information on the dark web, and the overwhelming majority of underground transactions involving stolen data do not occur on it. What these companies actually do is scan public databases such as public leaks and Pastebin posts for certain keywords, and alert you if any are found. They use the term "dark web" for marketing reasons only.

Now, I'm not saying that these companies are completely useless or that they are never able to identify stolen information, but they do not do so by searching anything you would call the "dark web". In fact, it is so much of a buzzword that what they are doing now is no different from what they were doing before the term became well-known and before it became entwined with so much mysticism and FUD.


Web Security Cheatsheet / ToDo list Can anyone suggest a cheatsheet or ToDo list of web site and application security?

A local small business owner prompted a question about web security, basically her company website just got XSS attacked last week.  I spent some free time to highlight where she should spend time on fixing in the future.  Given that she outsourced her web site, is there a cheatsheet or ToDo list online about web security that I can share with her - i.e. A list of TODO for smart average joe / SMB owner?  (Not limited to XSS)

There is always the OWASP top ten web vulnerabilities list
A little summary of each from OWASP's report:

Injection - Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data.

Cross-Site Scripting - XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

Broken Authentication and Session Management - Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.

Insecure Direct Object References - A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

Cross-Site Request Forgery (CSRF) - A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

Security Misconfiguration - Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date, including all code libraries used by the application.

Insecure Cryptographic Storage - Many web applications do not properly protect sensitive data, such as credit cards, SSNs, and authentication credentials, with appropriate encryption or hashing. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes.

Failure to Restrict URL Access - Many web applications check URL access rights before rendering protected links and buttons. However, applications need to perform similar access control checks each time these pages are accessed, or attackers will be able to forge URLs to access these hidden pages anyway.

Insufficient Transport Layer Protection - Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic. When they do, they sometimes support weak algorithms, use expired or invalid certificates, or do not use them correctly.

Unvalidated Redirects and Forwards - Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.


Clearing/changing session id on logout While reading through the newes OWASP ASVS standard (still beta) I have found a requirement V2.6 saying

  Verify that the session id is changed or cleared on logout.

I do not see a clear point why it is necessary to have the session id changed or cleared after logout. It is necessary to have the session invalidated so after logging out no protected resources can be accessed. But why should I want to change the session id? Defense in depth?

EDIT: Another answer to the question.

Because of possible session fixation: http://en.wikipedia.org/wiki/Session_fixation

  In computer network security, session fixation attacks attempt to
  exploit the vulnerability of a system which allows one person to
  fixate (set) another person's session identifier (SID). Most session
  fixation attacks are web based, and most rely on session identifiers
  being accepted from URLs (query string) or POST data.

Another problem: if user has same session id after logout (even if session contents are cleared), attacker gains possibility to prolong usage of stolen session id.
Alice logs in to some site;
Attacker steals cookie with session id;
Alice logs out of site;
Attacker can't use stolen cookie to access the site;
Alice logs in to the site;
Attacker can use stolen cookie, because Alice's session id is the same;

Rule of thumb is to change session id as often as you can.


Is it safe to log JavaScript exceptions to the error console? I know that on the server side it's very bad to display system-level errors instead of logging them to disk, because it could expose potentially sensitive information, but do the same concerns apply to client-side languages like JavaScript?

e.g.,

try {
    foo();
} catch ( exception ) {
    if ( window.console ) {
        console.log( exception );
    }
}

Since everything is already accessible to the browser/user, I can't think of real problems.

The only thing I could find on the web was one example of outputting a password on a login form:

  But the troublesome thing is that there may be an easy temptation to console.log() something very sensitive, like console.log(password_entered). [...]  the fact that they obviously have a process in place which does not properly filter out [temporary debugging output] means that at some point they may accidentally expose something they would otherwise not want to (or their users wouldn’t want!).

I'm as paranoid as the next guy, but that seems a bit silly. Even in an extreme case like a password being exposed, wouldn't an attacker who was able to view it already have all the access they need? Or am I overlooking something?

It is safe as everything on the client-side is, by definition, already accessible client-side.

If you're worried about the password being exposed and read by passers by of the user's screen, then normal users will not have the console active. If they did, it would also be possible to see the password entered via the Network tab:

Screenshot taken from this question.

It would be best practise though to disable console debug output on production sites. For pre-production it might be wise to filter out passwords in case they are accidentally copied into bug reports, but these being test accounts the risk should be low.


Is user-education considered a security measure? Some people reason that an iOS device is safer from a security context than an Android device, because an iOS device does not simply allow users to install apps from any source other than the App Store while Android has a user configurable setting for this. Obviously there are many more reasons why one or another is safer, but those things left aside. Other real life examples can include warning the user that he or she is connected to a public network or even blocking the use of a program when connected to a public network.

Especially in the last example the user is not in control and this made me think about the line between security (if this even is security) and "user freedom".

Is user-education a security measure in context of the given examples or do we have different names for these kind of measures?
Bonus: Are there security guidelines or best practices on when to educate the user (warn) and when to block the user from doing specific things (like installing an app)?

Yes, users security awareness and training is an integral part of a global security policy.

Humans are often told to be the weakest point in the security chain, as you can patch a software vulnerability but you cannot patch a human. The best you can do is make people aware and regularly maintain their attention on potential security issues affecting their daily activities.

Generally, when a tool is available (I mean it is there, ready to deploy) which allows to enforce your policy, there is no reason not to use it. If this tool affects your users negatively, this does not mean that the tools shouldn't be installed, this means that your policy may need to be reviewed.

But sadly not everything can be automated, and there is a lot of areas where there will simply no tool. No tool will prevent a user from giving his password over the phone, opening the door to someone else or sharing his access badge.

The goal of security awareness training will be both:

To address these areas where security nearly solely relies on the user behavior because there is no practical technical way to enforce the policy (either because the tools do not exist or because the company has chosen not to implement them: maybe they are to expensive, too complex, etc.).
To prevent the users from bypassing current technical measures: security measures should help the users to respect the security policy, users should not see them as obstacles to bypass otherwise your global security will quickly get weaker.


cc-memtest for testing memory security for OpenBSD http://blog.acumensecurity.net/revisiting-wx-with-openbsd-6-0/

http://blog.acumensecurity.net/fpt_wx_ext-1-a-rundown/

Has anybody got the cc-memtest binary or source code or cc-memtest?

A program that can test the following:

The assurance activities direct the evaluator to:

Acquire or construct a test program which attempts to allocate memory that is both writable and executable. The evaluator will run the program and confirm that it fails to allocate memory that is both writable and executable.
Acquire or construct a test program which allocates memory that is executable and then subsequently requests additional write/modify permissions on that memory. The evaluator will run the program and confirm that at no time during the lifetime of the process is the memory both writable and executable.
Acquire or construct a test program which allocates memory that is writable and then subsequently requests additional execute permissions on that memory. The evaluator will run the program and confirm that at no time during the lifetime of the process is the memory both writable and executable.

From the blog you cite:

  ..Attempting to run my test application, cc-memtest, ...

Which means its the authors own test application so please contact the author of the blog article.

Apart from that it should not be too hard to construct a program which does these tests as long as you understand mmap(2) and mprotect(2). You will even find some code if you look closer at the pictures in the article. But help in this area (i.e. programming) is off-topic here and I recommend you just read the man pages.


Write-protection at hardware level for security It seems to me that to maximise server security, one ought - in addition to the usual security measures implemented in software - to prevent the overwriting of certain parts of the server system, such that only physical access will circumvent this write-protection.

Rationale

If a remote attacker who has been successful enough to gain arbitrary code execution privileges can modify the following, then that server is significantly less secure than it would be if such an attacker could not modify them:

pre-boot process (e.g. BIOS or equivalent)
CPU firmware/microcode
boot processes

This is a defence in depth rationale.

Questions

My questions are as follows:

BIOS

Is it possible to write-protect BIOS chips at the hardware level, e.g. with a device having a similar form-factor to a BIOS Savior but instead possessing a hardware switch that physically prevents current from reaching the circuitry capable of overwriting the BIOS? (NB: The NSA's "ANT division [has] a clear preference for planting their malicious code [in] BIOS.")

CPU

Similarly, is it possible to write-protect processors at the hardware level, e.g. with a device having a similar form-factor, mutatis mutandis, to that described above for the BIOS, i.e. sitting physically between the CPU socket on the motherboard and, the CPU itself, and again possessing a hardware switch that physically prevents current from reaching the circuitry capable of overwriting the CPU's firmware?

Operating system storage

It is already possible to write-protect the storage medium containing the operating system installation at the hardware level by utilising a read-only optical drive for that storage (e.g. CD-ROM, DVD-ROM, etc). Other options would include write-protected USB flash drives, or forensic USB write-blockers installed between the USB port and the drive containing the OS.

Even though Live CDs are often used for testing or experimentation, this does not seem to be common practice in deployment. Perhaps this is because sysadmins would prefer not to have to gain physical access to every server for every OS update, even if it would just be a matter of replacing a DVD-ROM and rebooting; but I do not share that preference: to me, security is more important.

Are there any server OSes/distros designed to support this sort of configuration out of the box?
Are there any information resources (books, websites) dedicated to deploying and maintaining servers in this fashion?

Quis custodiet ipsos custodes?
Before I begin, I'd like to explain a bit about the term trust as it is used in an information security context. In infosec, trust often has the opposite meaning of what would seem logical. You want less trust. An untrusted component of a system is good, and the more untrusted components, the better. Trust means reliance. If you trust a component, you rely upon it to be honest, correctly implemented, and secure. If you do not trust a component, it means even compromise or malice will not allow it to do harm to you. In a secure computer, the Trusted Computing Base (TCB) is the sum of trusted code on any given system. The smaller the TCB, the better.
This brings us to the question, who watches the watchmen? In infosec, the highest watchmen are the TCB. The fewer there are, the safer the system. While it is impossible to completely solve this issue, one common effective solution is to implement trust in hardware, which is much harder to tamper with than software. Hardware verifies a small amount of software. This small software verifies larger software, and on and on. This is explained later in this post.
Answering your questions

Is it possible to write-protect BIOS chips at the hardware level, e.g. with a device having a similar form-factor to a BIOS Savior but instead possessing a hardware switch that physically prevents current from reaching the circuitry capable of overwriting the BIOS?

Some older systems required jumpers to be set in order to write to the BIOS. Now days, it's almost always in software. You would want to use a modern computer that supports BootGuard in order to mitigate this. BootGuard runs in the CPU before the BIOS even loads and verifies a digital signature in the BIOS to ensure it has not been tampered with. Boot will only resume if the signature is valid.

Similarly, is it possible to write-protect processors at the hardware level, e.g. with a device having a similar form-factor, mutatis mutandis, to that described above for the BIOS, i.e. sitting physically between the CPU socket on the motherboard and, the CPU itself, and again possessing a hardware switch that physically prevents current from reaching the circuitry capable of overwriting the CPU's firmware?

CPUs do not have firmware. In fact, they have no permanent storage at all. Intel even has a "statement of volatility" in many of their documents, essentially saying that a second-hand CPU will not contain any personal information or permanent changes from its previous owner. For example, from the Xeon E5 v4 datasheet, section 1.1.4 contains the following:
1.1.4   Statement of Volatility (SOV)

        The Intel® Xeon® Processor E5 v4 Product Family does not retain any
        end-user data when powered down and / or the processor is physically
        removed from the socket.

Technically, CPUs do have a small amount of permanent storage called OTP (One-Time-Programmable) fuses, but they are used for permanently changing some basic settings, such as whether or not BootGuard is active. It does not contain anything executable.
You are probably thinking of microcode. Microcode is a way that CPUs can modify the behavior of certain instructions by routing through a microcode table. This is used to fix buggy instructions or even disable them completely. However, it's not built into the CPU, and can only be loaded at runtime. Once a CPU resets, microcode is lost. There are two main ways a CPU can load microcode:

The BIOS, which often contains microcode from the time of manufacture.
Software, which downloads the latest microcode and inserts it.

Microcode is verified using a signing key known only to Intel. To insert malicious microcode, one would have to be in the position to both get you to run it, and to obtain Intel's signing key.

Are there any server OSes/distros designed to support this sort of configuration out of the box?

Tails is specifically designed to do this. It is an amnesic live system that keeps data only in memory. It uses a special type of filesystem called a union to fuse two other filesystems. Specifically, it fuses the read-only squashfs, present on a USB stick or DVD, and an in-memory tmpfs. Any changes to the union filesystem are written to tmpfs. This provides the illusion of one, large, writable filesystem, when in reality there is only one that is never-changing and another that exists only in memory.

Are there any information resources (books, websites) dedicated to deploying and maintaining servers in this fashion?

You may want to look into diskless servers. These are common in clustering and boot over the network. All data they have, unless saved over the network, is lost on reboot.
Other hardware that can be modified
The list of hardware you provided is not exhaustive. There is plenty more on a modern motherboard that can be modified, for example:

Both HDDs and SSDs have writable firmware powering their microcontrollers.
Option ROMs are present in nearly every PCI device and are executed by the BIOS.
GPU firmware is usually not writable over software, but it is not write-protected.

There is more, and unless you have a way to verify your boot process, trying to write-protect everything will be a cat-and-mouse game.
Measured boot
With some effort, even using software (on modern hardware) alone, you may still be able to verify the integrity of your hardware, sharply reducing the number of components you have to trust. It is even possible to do this remotely for a computer you do not have physical access to! This is called remote attestation. Usually, this is done using the TPM.
The TPM is a small hardware component (though often emulated in firmware in newer processors) which is designed to be tamper resistant and secure. It has minimal functionality, and can only do a few things. Primarily, it is used to combine the hashes of various components of the system, and they will unlock (unseal) themselves when the hashes match a known value. Various pieces of software send copies of parts of the system to the TPM to be hashed. As a result, the TPM's hashes will change if any component of the system changes. This all starts with the trusted CRTM (Core Root-of-Trust for Measurement), which is a, usually, read-only component of the BIOS that sends a hash of the BIOS itself to the TPM. If the CRTM and TPM are trusted, then the rest of the system is untrusted.
A TPM verifies several different components of the system and stores in it PCRs. Each PCR has a different purpose, and verifies a different part of the system (taken from another post):
PCR 0 to 3 for the BIOS, ROMS...
PCR 4 - MBR information and stage1
PCR 8 - bootloader information stage2 part1
PCR 9 - bootloader information stage2 part2
PCR 12 - all command-line arguments from menu.lst and those entered in the shell
PCR 13 - all files checked via the checkfile-routine
PCR 14 - all files which are actually loaded (e.g., Linux kernel, initramfs, modules...)
PCR 15 to 23 are not used for SRTM

An important thing to remember is that the TPM cannot act on any detected tampering. In fact it is fundamentally not able to, being positioned on the LPC bus. All it can do is verify that the hardware is in a sane state, and refuse to unseal itself otherwise. The sealed data could include a disk encryption key (ensuring the system will not boot if the system has been tampered with), or a secret known only to you and not guessable (and thus not spoofable) by attackers, such as a string (which is how Anti-Evil Maid from ITL works).
The end of this process is that you have reduced the TCB for your entire system down to the small, read-only CRTM, and the secure TPM chip itself.
Resources / pointers
Since you asked for some resources, I would look into the following things for improving improving the security (reducing the trusted computing base) of a COTS workstation:

Measured boot
Remote attestation
Trusted Platform Module (TPM)
Static Root-of-Trust for Measurement (SRTM)
Dynamic Root-of-Trust for Measurement (DRTM)

Some other questions that may be relevant and could help you understand this process:

Anti-Evil Maid - Invisible Things Lab
Trusted Platform Module - Wikipedia
Link
Link
Link
Link
For remotely unlocking LUKS volumes via SSH, how can I verify integrity before sending passphrase?

TL;DR
Write protection is a game of cat-and-mouse. The only practical solution is to use measured boot.


Fundamental differences between digital ID and SSL security certificates I was reading http://www.symantec.com/verisign/digital-id and  http://technet.microsoft.com/en-us/library/dd351044(v=exchg.150).aspx. The articles are treating ssl cert and 'digital id' as if they are two different concepts. I was under the impression that they were the same thing, just different names.

Are there any differences between Digital Ids and SSL Encryption/Digital Certificates?

"SSL certificate" is an informal name used to refer to the X.509 Digital certificate that is used when communicating over the SSL protocol.

"Digital ID" is a Symantec product name. They don't give much technical information about what it is, but it sounds like an X.509 certificate that you can use for various things, mainly encrypting/signing emails or word documents.

So, they are (probably) the same thing, but are being used for (probably) different purposes.


PCI questions regarding software As a software company who is looking at writing something that could handle debit cards can I self certify my software or do I have to have it tested by a 3rd party company?

You'll need to look at the PA-DSS certification process from the PCI Security standards council.

They have information on the standard and certification procedures on their website https://www.pcisecuritystandards.org/hardware_software/


PCI DSS - VPN network? My network is segmented into internal (which holds private cardholder data), DMZ and VPN. There is a gateway in between which restricts access, for example:

VPN: 10.0.0.0/24
DMZ: 10.1.0.0/24
INT: 10.2.0.0/24

GW / firewall has ip .1 in all three networks. Access from DMZ to cardholder (INT) is limited via FW and access from public networks to cardholder (INT) is completely prohibited.

I'm confused about one thing: if I connect to the VPN network from my workstation, am I allowed to make connections to servers in the INT network? For administration purposes, I need ssh access to those nodes, and it seems logical to me that connecting to them from VPN IP, through gateway/firewall, should be OK.

But, I'm getting fuzzy responses from other colleagues working on these issues. They think access from VPN to INT should be forbidden, and the only way to connect to INT servers should be by connecting to VPN, then ssh-ing to one of the DMZ servers and then hopping into INT. I can't find any such notion in PCI DSS docs...

Is the reason for this explanation that the VPN connecting machine is not under PCI DSS scope, so it's treated as unsecure/public access, or does VPN eliminate that notion?

According to PCI, you have 3 kind of networks:
1. INTERNAL (Cardholder Data Enviroment)
2. DMZ
3. INSECURE

If your VPN network is considered as DMZ network, then it's under PCI scope, just like every other device in DMZ zone.

If your VPN network is considered as INSECURE network, then you shouldn't allow direct connection to the servers in INTERNAL network.

So, either you are in PCI scope, or you are INSECURE. Firewall should be configured to not allow direct communication between INSECURE and INTERNAL network.


Online Banking Two-Factor Authentication Security Lets take a closer look if transaction authentication numbers  (TANs), such as: mTAN, chipTAN and pushTAN  fulﬁll the requirements of a secure two-factor authentication method.

description of each of them:

mTAN: The authentication number is sent to the customer’s phone via SMS.
chipTAN: The customer owns a special device where she inputs her bank card, scans a bar code from the bank’s website, and a freshly generated authentication number is shown on the small device screen.
pushTAN: The number is received by a special, separate application on the customer’s phone which is not the banking app.

I am interested in both mobile application banking and bank's web portal banking.

Here are my thoughts about them.

a) Mobile Application.

mTAN: In this case the attacker other than username/password attacker only needs to have access only to the mobile phone of the victim to achieve his goal. So the second factor authentication does not really add much security. Overall - Not so secure ?

chipTAN: In this case except the username/password attacker needs to physically have the mobile phone, tan generator device and the bank card of the victim for success, which adds basically three more security levels. So I think this one qualifies as a secure method?

pushTAN: Here again attacker needs to have access to the victim's phone, since the separate application is also installed on the same smartphone. So this is similarly (non)secure as the MTAN?

b) Bank's web portal:

mTAN: This is basically the same as the mobile application version of mTAN.

chipTAN: In this case attacker does not need to have access to the mobile phone, but only the username/password, tan generator device and the bank card. This one seems still secure for me.

pushTAN: I am not quite sure how to connect pushTAN and web portal based mobile banking, but attacker would have to have the username/password and also access to the mobile phone.

Basically my 'task' is to state if the above mentioned two-factor authentication methods are secure and if not to describe the attack.

Please correct me if I said anything wrong and I would appreciate if you could suggest me some attacks which can be successful against those methods.

Sounds a bit like homework to me (?)

  Is mTAN two-factor authentication secure?

You don't get security by using a single technology or device. The question would have to be extended: Does it guarantee authentication under such-and-such conditions, with attackers having this much resources available? Security is a (relative) property of systems, not single components. Also, authentication is mostly a means to get security.

You could ask "does mTAN fulfill its purpose" , and the answer would be yes, since two factor authentication is supposed to make it necessary to provide two things (in this case, something you know and something you have) to authenticate yourself instead of just one (usually a password, eg something you know).

Two-factor authentication closes off some venues of attack, but its purpose isn't to make all attacks fail. Its just to raise the bar.

You can always find attacks against authentication schemes. Imagine you install the best lock ever designed on your apartment door and reinforce all the windows and walls. Is this secure? Not against someone willing to steal your key. Would it be better to provide your thumbprint? (something you are) Well, that can be defeated in various ways, the most brutal one looks like this: Your password gets tortured out of you and they cut off your thumb in the process. Bang, two factor authentication failed. It can fail with less fireworks, too: You can be forced by a judge to give up both factors, or tricked into providing both factors via social engineering, and so on.

So forget about an authentication method being secure  in and of itself. Ask about how much effort it is to circumvent or break it. Your three TAN schemes will vary in which attacks are the most feasible, cheapest, inconspicious etc.


How can LetsEncrypt and other similar services verify ownership of a domain over insecure http? LetsEncrypt allows you to verify ownership of your domain using the .well-known thing, but since the site is http before the first certificate is issued, couldn't somebody do an MITM attack to give letsencrypt the response it wants without actually owning the domain? I'm pretty sure the people at LE know what they're doing, I just want to know how it works.

EDIT:

To clarify, I am talking about spoofing the entire process, not just guessing the nonce used after a legitimate owner begins the process. I am talking about an attacker running certbot and doing the entire thing.

couldn't somebody do an MITM attack to give letsencrypt the response it wants without actually owning the domain?

Yes, someone who knows the response Let's Encrypt expects could provide it. But, the response is created by using a private key only known to the owner of the server where the matching public key is known by Let's Encrypt. Thus it is practically  impossible for some man in the middle to guess the correct response.

For more details see How It Works from Let's Encrypt which includes the following description:

  Along with the challenges, the Let’s Encrypt CA also provides a nonce that the agent must sign with its private key pair to prove that it controls the key pair.

Of course, if the attacker fully controls access to the domain he can create a new account with Let's Encrypt and get a certificate for this domain. But in this case the attacker is essentially owning the domain not only from the perspective of Let's Encrypt but also other third parties.


How to make sure my web application is secured? My backend is hosted on AWS-EC2 running ruby on rails.
My frontend is hosted on aws-s3 using angular-js.
My DB is MongoDB.

All APIs have an authentication token for user security. Every server is https enabled with cloud-front aws. My backend have only 80/443 port opened, and 22 for my private IP.
My clients ask me about the security features of this iot-system.
What are the habits that I need to keep in mind to make the system secure from external threats?

External threats include someone hacking the data on my DB?
someone stealing user account details/credentials using phishing?
DNS spoofing?

P.S.: I use CloudFront for SSL certificates and they route my data using https, convert all connections from HTTP to https. All of my stacks is on AWS from DNS to my frontend.

To be the one to make this comment: you can never be 100% sure.
But you can:

Use vulnerability scanners (credentialled and uncredentialled) regulary (every week?) to make sure public vulnerabilities have been patched and you have not accidentally opened your webserver up to the outside world. Try using OpenVAS or Nessus (or any other) for vulnerability scanning. Try using OWASP ZAP every now and then to see if you have any webvulnerabilities
Run the SSLlabs scanner on your site every month to make sure you are still up to date with encryption
Run your code through a source code scanner (can someone say which one is easy and good?)
Think of secure processes to run through when administrating your website. So how do you work with passwords and autorisations (I do not know if you have employees)
Take the OWASP testing guide and try to run through it yourself. Also look at the OWASP cheat sheets for administrating and developing your website and webservices
Hire a pentesting company once a year to do a real "once over" to see if you have vulnerabilities that you yourself and the automatic scanners do not have the expertise to find (mostly in business logic and more indepth vulnerabilities)

I am assuming here that you are not a security professional, so cannot do everything yourself. But I think if you make use of automated scanners and hire pentesters once a year you are as secure as you can be in normal circumstances. If you have no money for pentesters you will have to try to do most things yourself (OWASP testing guide is a real help!). If you have tons of money you should hire a security professional to constantly help in improving the security of your organisation.


Information Security Audit - Employment Contract As part of a a security audit, a customer has asked for some documentation - usual stuff - data classification policy, incident management policy etc. They have also asked for a blank employment contract. I don't see what use this could really be to a security audit, what is it they are looking for in this document?

Employment contracts do things like describe limits of liability, employee responsibilities, remediations, punishments, etc. There's a lot in there that will tell an auditor about how the company views security and data protection.

As someone who had to supply all this documentation, it was not an unusual request from 3rd party auditors.


Is the RHEL 7 version of FreeRadius not affected by RHSA-2017:1759 (or similar)? In July 2017, multiple security issues have been found in FreeRadius 2.x.x and 3.0.x.  RHEL 6 uses FreeRadius 2.x.x and Red Hat has released security advisory RHSA-2017:1759.  However, for RHEL 7, no security advisory exists, as far as I can see.

However, the latest version on RHEL at the time of writing this is freeradius-3.0.4-8.el7_3, and the issues are fixed in FreeRadius 3.0.15.  I know that Red Hat can backport certain fixes from newer versions in its packages, but is this what happened?

How can I find out if I'm secure against these issues?

If you dig into the CVE detail listed for the first CVE on that RHSA, it appears that RHEL 7 is affected but not yet addressed.  Since it is listed as "affected" and not "will not fix", Red Hat will likely release a new RHSA or update the existing one as soon as they have the fix backported for RHEL 7.

Note that there is an RHSA titled "Red Hat Enterprise Linux 7 (freeradius)", but it is older (RHSA 1581 vs. 1759 for the new RHEL 6 RHSA) and addresses a different CVE.  It is, in fact, the one that produced the freeradius-3.0.4-8.el7_3 that you're looking at.


Security-wise, is an in-browser JavaScript implementation fundamentally different from a server-side language (e.g. Python) implementation? As I understand it, JavaScript implementations running in browsers need to run untrusted code and operate on untrusted data in a secure manner. Language (e.g. Python) implementations running on a server, OTOH, run trusted code and only need to securely handle untrusted data.

Does this difference mean that the two language implementations need to solve fundamentally different problems, security-wise?

Are there attacks which are possible via untrusted code and data, but not via untrusted data only? If so, presumably a Python implementation can afford to ignore these types of attack, but a JS implementation would have to be secure against them?

Or should all attacks that are possible via untrusted code also be considered possible via just untrusted data? In which case Python implementations should employ as many security features as JS implementations?

In other words, is it a simpler task to secure a language implementation against malicious data only, compared to both malicious data and malicious code?

Are there attacks which are possible via untrusted code and data, but not via untrusted data only?

If you can trust the code you can usually use this trusted code to validate the untrusted data before further processing the data. If the code is untrusted too this is not possible. That's why the Javascript engine inside the browser (which is executing untrusted code) is running inside a limited environment (sandbox) so that the untrusted code cannot do harm to the underlying system. This means for example that file and network access is severely limited.

There are cases where the attacker manages to inject its own code into trusted execution environments. If this is the case the attackers code has the same level of trust then the other trusted code and can thus cause massive damage given that the assumption for the environment was that the code can be trusted. A typical example of such injection is to call eval on attacker provided data, thus interpreting these data as trusted code.

  In other words, is it a simpler task to secure a language implementation against malicious data only, compared to both malicious data and malicious code?

Yes, if the code can be fully trusted no additional restrictions need to be done to the execution environment since it can be expected that the trusted code properly validates the untrusted data. Of course restrictions are recommended nevertheless as part of defense in depth since most complex code has bugs.

If on the other hand the code cannot be trusted it is essential to limit what the execution environment can do. This makes it more complex since this protection is needed additionally to the existing language. And, all the bugs in the last years within the Java Sandbox show that designing and implementing such a restricted execution environment is not easy.


Should each radius client have its own key? If I have many Cisco switches connected to Windows radius, should I assign a different key to each switch? Is it a best practice? If I leave the key same on every host, it would ease my deployment.

As mentioned in the comments, yes you should definitely. Especially if this is on a production network even more specifically if it's a customers production network.

It may "ease your deployment" but it wouldn't help at all if the network was breached. Please use different keys for each Radius client, it's not even a "best practice" it is purely common sense.

As Schroeder has stated it's the same thing with using different passwords for different accounts; you're only harming yourself by using the same "password". It may save you time now but it adds time to the aftermath of a breach.


Should login/refresh authentication routes return new tokens if an existing, valid token is present? My server sets cookies with the JWT and refresh tokens on login, and likewise when the refresh route is hit. If a valid JWT cookie is found in the request for these routes, should a new one be issued? If so, should the old be blacklisted? And if not, what would be a valid response code?

Use Case

Lets say you have two endpoints /secure and /token

Hitting /secure with a valid access_token, returns 200 Success

Hitting /secure with an invalid access_token, returns 401 Unauthorized

Hitting /token with a valid refresh_token, returns a new access_token and refresh_token and this should remain consistent, regardless of wether the access_token is valid or invalid.

Refresh Tokens Lifecycle

It is best to invalidate the previous refresh token. This is because you do not want more refresh tokens then there needs to be. It is very important that the refresh token is stored securely if it is going to remain valid for a long time.

Access Tokens Lifecycle

Usually the lifecycle of the token is determined by its expiration date.

If it was a requirement to invalidate old access tokens, then you would have to persist an identifier for them, and check that each time you received a token.

This removes the stateless nature of using JWT in this way, but eliminates the same user having multiple access tokens, the reuse of a previously blacklisted token, or replay attacks.

Design Concerns

In this architecture, you want a separation of concerns between the access_token and refresh_token, wherein the refresh_token is uses for (re)authentication and the access_token is used for authorization.

This means that if you do blacklist access tokens it should be handled by the /secure endpoint, because only it is in charge of its authorization (who is allowed to do what).

The use case for refresh and access tokens using JWT, avoids the need for cookies, allowing authentication and authorization with different clients: SPAs, Mobile Apps, Web Apps, Desktop Apps, other servers etc. that may not have the use or access to cookies to persist session data.

If you stick strictly to the design pattern, then you would avoid cookies all together. If you use cookies, the the answer to your question is: you probably shouldn't use cookie when hitting /token.

If you use the cookie in /token you could end up not creating a new access token when an old one is about to expire and the call was intentional, or have some complex logic to determine when to generate a new access token. Or even worse, not use the JWT access token to determine its own lifecycle.

Appendix

For checking the time based validity of the JWT access_token:

I recommend you utilize the "exp" claim in the JWT. This would be a good baseline determining factor to expire the tokens. Referenced in Section 4.1.4 of RFC 7519. But if you are putting the token inside of a cookie, you could also have the cookie expire after a certain amount of time

For blacklisting certain access_tokens:

Section 4.1.7 mentions the "jti" claim which could be used for black listing tokens with certain identifiers.


Appropriate response to 2014 Russian Security Breach (CyberVor) The report from Hold Security says that 1.2 billion sets of credentials are in the possession of this party. I have a feeling that this report may be a hoax or a partial hoax due to grammatical errors ("while we getting our full service ready") and self-advertising of their electronic identity monitoring service. If it is true, how should I respond to this mass credential theft? The report recommends identity protection services but would it be enough?

The report is authenticated at Russian Hackers Amass Over a Billion Internet Passwords - NYTimes.com.  But much remains unclear, and even the times didn't note the conflict-of-interest that Hold Security is setting up by speaking in scary but unspecific terms about this, and only offering their own paid services to help victims out, as you allude to.

I'm surprised that there is no discussion of the importance of properly salting and slowly hashing passwords before storing them in password databases, as discussed here at 'passwords' tag wiki.  If a site does that, and the passwords are strong, a hacker couldn't learn the passwords just by downloading databases from the web site.  They'd need to modify the web site authentication code and capture passwords interactively as users log in.  They would thus only slowly get the passwords of active users, and that kind of attack on a site is much more likely to be noticed.

But of course many web applications don't follow even these basic practices, as discussed for example at cryptography - Looking for example of well-known app using unsalted hashes

End-users should use this and other reports of web site hacking to motivate them to be careful about which web sites they interact with, and to be smart about how they deal with passwords.  Using web sites that support the use of a well-protected web sign-on service that requires two-factor authentication is better than working with a less-well-resourced web site that manages their own password database.  See also techniques for dealing in a sane way with a large password portfolio at How to help users manage password portfolios based on risks of compromise? - Information Security Stack Exchange.

If you've re-used passwords for important sites on other sites, you could benefit from changing those passwords, e.g. if the important site is not vulnerable, but another one with the same password has been hacked.  But since many of the sites with problems remain vulnerable, just changing your password now on one of those may not help much.  And as noted in the password portfolio discussion, changing passwords for sites where you really don't have any information or assets at risk is far less important.


Slow Hashing Without a Salt? I'm trying to design a security scheme that involves a shared secret but isn't a traditional account password situation. The server would store a set of "keys", each of which has a blob of data associated with it. In order for anyone to access the data for a given key, all they need to know is the plaintext name of the key. So if Alice creates data using "pineapple" as the key, Bob can ask the server for the data for the key "pineapple" and the server will return the data.

It's completely intentional that Bob could share the secret word to other people, or for people to randomly guess "pineapple" and accidentally get the data. I only want to avoid someone being able to brute force very large numbers of keys for common dictionary words easily. I would like none of the plaintext data to ever be sent to the server, so that the people running the server could not spy on the user data or even know what the plaintext keys are. And ideally if the server was compromised, it would take a long time to brute force each of the plaintext keys and/or decrypt the corresponding data.

My idea for how this could work, is that if Alice wants to create new data, their client takes the key "pineapple" and runs a very slow hash algorithm on it, eventually creating the corresponding hash code for pineapple. Then their client encrypts the data package with "pineapple" as well using some sort of encryption method that is difficult to brute force. Alice would then send both to the server, which would check to see that the hash doesn't already exist, and then store the hash/data pair. Later, Bob could repeat the same process of creating a hash code for pineapple, then ask the server for the data for that hash, and finally decrypt the returned data using pineapple as the key. The process of creating the initial hash would be slow, but both Alice and Bob could store it locally in their client so it would only have to be done once per key.

Is there any better way of doing this? Are there slow hash algorithms that don't involve using a salt, which would prevent Alice and Bob from figuring out the same secure hash code without communicating with each other? Is there some way of using a salt but still using this general method where the server never sees any plaintext? Are there security concerns with this sort of scheme that I'm not considering?

Key Derivation Functions

What you are describing is really no different than the key derivation functions (KDF) already used in many encryption/password hashing contexts.  Plenty of KDFs have a configurable cost parameter that can allow you to increase or decrease the total "CPU Time" (I'm simplifying) needed to generate the actual key from the password.  In this case what you call the key (i.e. "pineapple") would effectively be a password that is run through a KDF to generate a cyrptographic key, which is then used for encryption/decryption of the data.  You would never have to send the password along to the server - just the generated key, which is always built using the KDF on the client side.

Cost factors

That last bit (generating the key client side) would be important, because for what you are talking about the cost factor would have to be very high.  That might be a detail you are missing.  The only way to both let people share a password and even guess passwords, but not be able to effectively brute force random passwords, is if the KDF is very slow.  Normally the cost parameter is tuned so that the time to generate the key on "good" hardware is, for instance, 0.2 seconds (I'm over simplifying and skipping lots of details for the sake of example).  The reason you pick a timescale like ~0.2 seconds for key generation is to balance the desire to make brute force expensive, but also make it so that your system can actually perform the necessary operations itself in the timescale that users are willing to wait (i.e. no one wants to wait 30 seconds each time they login).

The trouble

However, even if an attacker can only check one "password" a second, there are still 86400 seconds in a day, which means that you can get through the entire oxford english dictionary (~170,000 words) in just a few days.  As a result, to stop someone from feasibly brute-forcing common dictionary words, you're talking about a key generation process that would have to take at least a few minutes, and I doubt that would stop a dedicated attacker (especially if they have top end hardware that can run the KDF in less time).  If you do that though, that means that your legitimate users will also have to wait those same minutes before they can get results out of your system.  After all, there is no way to differentiate between a legitimate user of your system and an attacker, so the only way to slow down attackers is by slowing down everyone.  So to do what you want to do you will have to slow down your KDF so that it takes some "long" amount of time to run, but it is quite possible that the level of "slowness" you need to secure to the level you desire (i.e. stopping brute force of common dictionary words) will be so slow that your users are unwilling to wait for your system to do its thing.  Ultimately, finding that balance between usability and security will be up to you and your users.

A possible solution

You can fix some of the trouble by using server-side throttling instead of making an arbitrarily large cost factor.  Imagine if the API calls where the user says "give me data for this key" does not immediately return results but instead generates a queued request that only responds after X period of time.  This would allow you to block brute-forcing regardless of what level of hardware the attacker has access to, would not slow down your server with a lengthy KDF process, and also would not penalize users with slow hardware.  The disadvantage of course is that it is a server-side control, so if your database leaked a hacker could go to town on brute-forcing at the speed of their hardware.


Should I let users set rel="canonical"? There is a website where users can post content. Often, users repost content they’ve made on other websites, to this website. (For example, their blogs, Facebook, news website, etc.) Because they repost things, they often want to set a <link rel="canonical" /> on their content, pointing to the original content. This could be any URL they want. Would it be safe to let them do that? Could they do anything bad to other users? Could they use it to make users viewing the content make requests to arbitrary locations? Could they negatively impact the SEO of other pieces of content?

According to the MDN documentation for the HTML link element, a <link> points to a resource at a different location, and describes the relationship between the current page and that external resource. This is primarily used for the purpose of organizing content in regard to search engines. When that piece of content can be found on multiple websites, the rel="canonical" bit will essentially tell the search engine "This is the original source for this piece of content." Any search engine or other user accessing this information can either use this information or not, depending on what they want to do with it, but it doesn't inherently enable additional functionality like sending requests on the user's behalf. You can read more about canonical link elements on their wikipedia page.


What number of bits does a browser use to generate a key? The question comes from the accepted answer in this thread:
My understanding of how HTTPS works (gmail for example)

The Gmail server sends your client a certificate.
The certificate includes the Gmail server's public key, and some evidence that this public key actually belongs to gmail.com.
Your browser verifies the evidence in the certificate, to confirm that it has the proper public key for gmail.com.
Your browser chooses a random new symmetric key K to use for its connection to Gmail. It encrypts K under Gmail's public key.
Gmail decrypts K using its private key. Now both your browser and the Gmail server know K, but no one else does.
Anytime your browser wants to send something to Gmail, it encrypts it under K; the Gmail server decrypts it upon receipt. Anytime the Gmail server wants to send something to your browser, it encrypts it under K.*

Regarding this step, "your browser chooses a random new symmetric key K", what is the number of bits in this key that the browser generates?

From another thread I posted (see: Understanding 2048 bit SSL and 256 bit encryption), I get the impression that it's a 256 bit key.

How can I verify this?

As per the SSL/TLS standard, the gory details are the following: if the cipher suite which the client and server agree upon mandates RSA-based key exchange, the the client generates a 48-byte (384 bits) string, beginning with the protocol version over 2 bytes, then 46 random bytes (i.e. 368 random bits). This is the PreMasterSecret (see section 7.4.7.1). This is the string which is encrypted with the server's public key.

When both the server and the client have the 48-byte pre-master secret, they use the PRF (the kind-of hash function described in section 5) to deterministically compute, from the pre-master secret, the encryption and integrity keys used to protect the data. If the cipher suite calls for 256-bit encryption keys, and 256-bit encryption keys will be thus generated.

To see from within the web browser (assuming the SSL client is a Web browser), see this answer.


Is an identity certificate the same as a public key? I'm new to public key infrastructure but I think I understand how public key encryption works, conceptually. So a public key is, by definition, public and not a secret.

Recently when I came across the term identity certificate and read about it, it sounded very similar to the public key of an entity. But, it was not explicitly stated whether they are the same or different.

My questions are:

Is an identity certificate same as a public key? If no, then is an identity certificate considered a secret?
How are they related?

Is identity certificate same as public key?

No, a certificate contains a public key but is not the public key itself.

  If no, then is identity cert considered a secret?

Usually not, it usually contains only information not considered secret.

  How are they related?

A certificate is the public key of an identity together with more information about the identity and usage restrictions. All together is then signed by the certificate issuer.

Which identity information are included depend on the specific use case but usually contain state, country, organization, name, maybe email, ... . Usage restrictions contain the time period when the certificate is valid, if it can be used for signing, if it is a TLS server or client certificate or a certificate authority (CA) etc. The signature by the certificate issuer is needed to protect the information in the certificate against tampering and also to create a trust infrastructure which can later be used to verify the certificate - see wikipedia: Public Key Infrastructure for more on this.


How to decrypt data with a pem file? I have the following:

A pair of keys generated with openssl in the manner described here.  The keys are called rsa_1024_priv.pem and rsa_1024_pub.pem.
An encrypted message, file.enc, which was generate through this test page I created.

How can I decrypt file.enc from the command line?  What specific command do I need to give?

I figured it out!

base64 -D file.enc > binary_messge.bin
openssl rsautl -decrypt -in binary_message.bin -out decrypted_message.txt -inkey rsa_1024_priv.pem

The problem was that the encrypted data needed to be base64 decoded before I could decrypt it.


Is there a reason to protect SIM with PIN? If the phone would be stolen then the SIM card will be thrown out by thieves just after the theft so that they can't be found.
If the phone would be lost then it will be harder to find an owner for people that found it if the SIM is protected with PIN.

So is there any reason to protect SIM card with PIN?

When SIMs were introduced, the purpose was to contain the user's identification for the sake of the mobile network. The small, relatively cheap physical objects were a convenient way of deploying subscriber identities separately from the bulky, expensive phone that may or may not have been supplied by the network operator. (Hence the name subscriber identity module.) The primary asset on the SIM is the identity of the user (in his role as subscriber to the mobile phone service); a secondary asset is the cryptographic key that protects it. See Security Engineering by Ross Anderson, §20.3.2 (§17.3.3 in the first edition).

You'll note that this is an asset of the network operator. The user has little incentive in protecting his identity. In practice, the loss of this asset means that the phone has been stolen. The loss of the phone is usually a higher cost than the possible loss of communication credit to the thief.

Over time, phones started to have more and more features. In particular, on basic mobile phones, the SIM tends to contain private data such as an address book. This private data is an asset of the user. With the move towards feature phones and smartphones, the private data escaped the SIM, which went back to containing little more than the subscriber's identity.

When you boot a basic phone, you're typically prompted to enter a 4-digit code. That's authentication for the SIM: basic phones tend not to have any authentication. When you boot a smartphone, it prompts you for its own authentication, and most users don't bother with a SIM PIN on top. I don't have figures, but I believe that most people do have one PIN (or other authentication factor such as gestures) for their mobile device, either for the SIM or for the phone. Miraculously (well, it's partly by design), the authentication or lack thereof correlates with the value of the assets to the user.

Access to the SIM allows the thief to impersonate the user, but only for a limited time, until it is reported stolen. If the thief has an unlocked SIM, he can access the user's voicemail and SMS history. This is a reason to protect your SIM even in a smartphone, but a weak one for most people: mobile phone theft is predominantly about the value of the phone, also more and more about leveraging smartphone data, but rarely targeted at the victim's private information. If you're likely to be targeted for your private data (say, if you regularly negociate multimillion deals on your phone), you'd better protect your SIM.

An unprotected SIM allows the thief to make phone calls without paying, and most importantly, anonymously. There are two main ways to make anonymous mobile phone calls: with a stolen SIM, if the thief isn't caught; and with a prepaid SIM, if it is bought anonymously (typically for cash or with a stolen credit card). A stolen SIM is inconvenient for that purpose in that it has a limited useful life (only until the SIM is blacklisted, which the operator can do). If the stolen SIM can go undetected for long enough to be fenced, it is much more valuable, as it makes the link between the SIM and the thief hard to trace.

If the thief uses the SIM, his approximate location becomes known. This is rarely a concern. The location of the theft is broadly known anyway. The identity of the thief is not known a priori; what is valuable is “where was criminal X at time T?”, not “where was the thief of this SIM at time T?”. The thief location is only useful if you can correlate the stolen SIM with the criminal in the first place. In practice, the phone is more likely to be traced than the SIM (both are equally traceable by the operator or law enforcement).

Note: this answer assumes that the thief is unable to guess or bypass the SIM PIN. This is a realistic assumption in most situations, as the SIM will lock after 3 invalid guesses, and the cost of breaking the SIM is typically higher than the assets.