Is breaking out of a Java binary serialized string possible? During an assessment of an android application I discovered a file which contained serialized data from a standard call to ObjectOutputStream.writeObject(). A string serialized in the data is potentially under attacker control. I wonder if it is possible to create an input that breaks out of the delimiters that start and end the string such that I can write arbitrary values into the file and have them executed by the consuming application on load, possibly via a gadget chain. Does any reader know of such a technique?

Let's look at what a serialized String actually looks like when serialized to a byte array. I grabbed sample code from this guide.

Code:

// Java code for serialization and deserialization
// of a Java object
import java.io.*;

class Demo implements java.io.Serializable
{
    public String s;

    // Default constructor
    public Demo(String s)
    {
        this.s = s;
    }
}

class Test
{
    public static void main(String[] args)
    {
        Demo object = new Demo("helloWorld");
        String filename = "file.ser";

        // Serialization
        try
        {
            //Saving of object in a file
            FileOutputStream file = new FileOutputStream(filename);
            ObjectOutputStream out = new ObjectOutputStream(file);

            // Method for serialization of object
            out.writeObject(object);

            out.close();
            file.close();

            System.out.println("Object has been serialized");
        }
        catch(IOException ex)
        {
            System.out.println("IOException is caught");
        }
    }
}

If I look at the serialized binary file file.ser I see: (in a text editor that property handles binary, uploading a screenshot because the SE editor won't handle the non-printable chars properly)

If we break that down, we see:

The name of the serialized object: Demo
The name of the serialized member object: java/lang/String
The data of this object: helloWorld

Summary:

If you are only allowing the attacker to modify the contents of the String (ie "helloWorld", then no, I don't believe it is possible to break out. However, if you are allowing the attacker to modify the entire byte stream, then they can replace the class name (ie "java/lang/string") with whatever gadget class they want and compromise your application.

UPDATE to address this comment:

  isn't that where visibility comes in handy for security? e.g. if the 'injected' class is not in the package or private .. no chance of accessing it. am i right?

I would say no. I'm not an expert, but my understanding is that the deserialization code is part of the core JVM and therefore completely ignores access modifiers like protected, private. Proof of concept, consider a serializable class with a private member:

class Demo implements java.io.Serializable
{
    public String pub;
    private String priv;

    // No-args constructor
    public Demo() {
      pub = "Public data";
      priv = "Private data";
    }
}

When you serialize this and send it over the network, you need to include the private member, and the deserializer at the other end needs to be able to re-construct it:

Let's shake the myth that the java keyword private has anything to do with security. It's a way for the developer who wrote the class to say "Hey, you shouldn't be accessing this directly" to the developer using the class, but in no way prevents you from using java reflection to read / modify private members or classes nor does it prevent data in private members or classes from being serialized / deserialized.


Salting a public hash Does it make any sense at all to salt a hash which might be available publicly?

It doesn't really make sense to me, but does anyone actually do that?

UPDATE - Some more info:

An acquaintance of mine has a common salted-hash function which he uses throughout his code. So I was wondering if it made any sense at-all, to do so.

Here's the function he used:

  hashlib.sha256(string+SALT).hexdigest()

Update2:

Sorry if it wasn't clear. By available publicly I meant, that it is rendered in the HTML of the project (for linking, etc) & can thus be easily read by a third party.

The project is a python based web-app which involves user-created pages which are tracked using their hashes like myproject.com/hash so thus revealing the hash publicly. So my question is, whether in any circumstances would any sane programmer salt such a hash?

Question:
Using hashlib.sha256(string+SALT).hexdigest() vs hashlib.sha256(string).hexdigest() , when the hash isn't a secret.

Yes. It's normally taken for granted that the salt will be available to an attacker. The salt does not need to be kept secret to be useful.

Salting a hash is done primarily to protect against a dictionary attack. A dictionary attack works by hashing common words (e.g., everything in a dictionary, thus the name) and then comparing hashed values to those from the dictionary. If you find a match (and for things like hashed passwords, you usually will) you know what word produced that hashed result.

The salt simply makes this type of attack consume a great deal more time and (especially) storage space. Just for the same of argument, let's say a relatively complete dictionary (including lots of names and such) with hashed results took 3 days to compute and occupied up a gigabyte of storage.

If we add, say, a 16-bit salt, the computation would now take roughly 65536x3=196,608 days = ~538 years. Storing the result would require roughly 64 terabytes instead of one gigabyte. In fairness, most people won't have 65536 users (for example) so the attacker would probably collect the salts and hashes, and only do a dictionary attack on the salts you actually used. This still means one dictionary attack per user (or whatever) rather than one for everybody.

For most purposes, that makes the difference between something almost anybody could do just because they felt like it, and something that only an fairly determined attacker (and probably well-funded) attacker would even contemplate.


Why does checksec.sh highlight rpath and runpath as security issues? The tool checksec.sh is used to examine compile time hardening options such as NX, RELRO, PIE and so on.

It also reports if the binary has RPATH or RUNPATH set, using the following logic:

These are flagged as red when present.

What is the security risk of having RPATH or RUNPATH set?

TL;DR: R*PATH has an unfortunate history of introducing new ways of
running untrusted (attacker-controlled) libraries. RPATH/RUNPATH
is usually avoidable and should be avoided.

Firstly, it might be worth reviewing the non-security reasons for why
we want these binaries flagged: distros (Eg. Debian Wiki on
RPATH) don't like that it takes precedence over the local
LD_LIBRARY_PATH and /etc/ld.so.conf settings/configs and
conventions. It makes it harder to reason about libraries through more
visible means than running readelf for every binary we want to think
about, and it complicates life for maintainers who are juggling a lot
of intertwined dependencies through these other mechanisms which are
easily broken by RPATH/RUNPATH. But there are exceptions - here's
Debian's policy:

  The only time a binary or shared library in a Debian package should set RPATH or RUNPATH is if it is linked to private shared libraries in the same package.

Secondly, relative RPATH (i.e. foo.so rather than
/usr/lib/foo.so) can go quite wrong: your user might be running from
a working directory (Eg. /tmp) that's subject to attacker control
who could plant a malicious version of /tmp/foo.so. This was an
observation made in Debian bug #754278 against openjdk.

This might sound benign, but it can lead to privesc particularly on
setuid/setgid programs like IBM's DB2 privesc CVE-2014-0907:
simply run the suid binary from a directory primed to abuse whatever
RPATH is set, and your code will run in the context of the
privileged program. Other examples include Slackware's packaging of
llvm CVE-2013-7171, Gentoo's packaging of Imagemagick
CVE-2005-3582, SuSE's packaging of CVSup CVE-2004-2133, ..).
It's been such a steady trickle that Apple's equivalent avoids relative RPATH in "restricted" (suid/sgid) binaries.

Thirdly, the special $ORIGIN variable (calling executable path) has
been one way of avoiding an absolute path, while anchoring the search
somewhere. But it's had issues: glibc CVE-2011-0536 failed to
expand it properly which gave attackers an equivalent of the relative RPATH case where the author of an executable using $ORIGIN thought they were getting something slightly more robust.

With that in mind, you probably really do want checksec.sh to flag
RPATH/RUNPATH - it's not always bad, but checksec.sh doesn't
have the bigger picture available to make that call for you like the
distro linters can, so it needs manual review.

Addendum: Breaking the links: Exploiting the linker by Tim Brown was mentioned in the replies to your Twitter conversation, this is a great paper on attack surface more generally for POSIX style linkers and astute readers should definitely take a look. The most pertinent thing there not covered already is this:

  On GNU/Linux at least, when the DT_RPATH or DT_RUNPATH exists within the ELF headers of a binary then these will be honoured first when looking for shared libraries. Additionally, the keyword $ORIGIN within this header is expanded to be the path of the directory where the object
  is found, while both . and the empty directory specification are honoured, even for binaries with the setUID bit set. From an attackers pespective, setUID binaries with DT_RPATH are particularly nice, since we can make use of hard links to manipulate the runtime linker into using an $ORIGIN
  which we can control.

... as observed elsewhere in the paper, most systems ignore user-supplied environment variables such as LD_LIBRARY_PATH on setuid binaries most of the time, but as you can see a careless RPATH gives the attacker an equivalent gift.

2nd addendum: ContextIS have a great writeup covering RPATH attacks.


Egress filtering - can it be relied upon on the Internet? My understanding is that IP address spoofing would not be possible if all ISPs would be doing egress filtering. That is, each ISP would not allow any IP packet to go outside of it's network if it sees a source IP, which does not belong to the source sub-network.

But what is the modern empirical evidence of it actually happening? How many "spoofed" packets manage to go far enough on the Internet highways that they can reach the destination, given that this destination is on another continent for example.

I understand that for a spoofing attempt to be effective, it needs to make sure that a response is also routed to the "malicious" destination. But I'm more interested in the initial "request" IP packets and the "real life" experience of spoofed packets on the Internet managing to get far outside the real source ISP.

Egress filtering is not what you want to do because you don't always have authoritative proof of the source of the traffic (the Internet is a mesh, not a hub/spoke). Ingress filtering is a more effective tool.

With ingress filtering, you know whether or not an IP is within your IP range. If a packet comes in with a source that was supposed to be from your network and you never saw it leave your network, then you know that something is wrong.

That's more difficult with UDP (connectionless), and the resource overhead is high.


Certificate chain mantainance According to standard rfc5280 , when user wants to validate a certificate, one step is to build a certificate chain, then check whether it is complete. I understand the idea to make a list to implement this requirement as the RFC 5280 stated. Meanwhile, I'm wondering is there any published library available to build a certificate chain if I just throw all certificates to it?

Yes it is totally possible. Common Crypto Libs like OpenSSL and Bouncycastle will do exactly that for you. You provide a list of trusted (root) certificates, a list of chain certificates, and you provide them the certificate that you want to check. It will use just those certificates needed between all you provided to chain up to a trusted root and validate the certificate. You may also get the chain if needed, as described here: http://www.nakov.com/blog/2009/12/01/x509-certificate-validation-in-java-build-and-verify-chain-and-verify-clr-with-bouncy-castle/

However, since the main topic here is security, not how to use a lib, except you are just doing it to study or by any reason you really want to get the chain (ex for displaying it), just verify using the standard verify methods, do not try to reimplement RFC5280 by yourself. There are many things to get wrong there.


How does sign-in with Social Login work for a 3rd party relying party I am trying to understand how to add social login and registration to a service.  After reading many blogs posts, many reminding me of the pitfalls of designing such a system, of the fact that Oauth is for Authorization not Authentication, most written by people exploring this topic as they write, all with different opinions on what OpenID/OpenID connect/etc is all about, I am finding myself more confused than before I started.

My understanding is that with Social Login the ID-provider does the Authentication.  When the user is authenticated, the client (or the user agent) must be in possession of something (a secure token?) that indicates that the user managed to prove their identity.  On subsequent requests to /the/ API, the server, which from the point of view of the ID provider is a 3rd party (called a relying party in some documents?) would need to be able to verify this "token" and needs to be able to derive from this "token" who the actual user is.

So, in practical terms:

What would the API receive from the client when a user signed in
using with Social Login?
What would the API receive from the client when a user registers with Social Login?
As a minimum what do I need to store about each user for authentication purpose (User-ID?  Email for recovery/linking multiple accounts?  ID-provider (in what format?), List of current sessions/expiry dates? Last access/update time maybe?  What else?)

The current system (a REST-full API) issues a token when the user signs in with email/password with a post to api.example.com/session.  In this case the API is able to check that the user supplied the correct credentials.

I gather that many articles online talk only about how to use the tokens to consume the resources provided by that same organisation, eg Facebook login for consuming Facebook APIs.  This might just be my misunderstanding though.

Some specific questions:

What does this token look like?  Does it reveal the Identity Provider or how to verify the validity of the Token?
Does the token give the relying party (The API backend servers) a way to obtain, say for example the user's Full Name or Email Address? Or would that be functionality delegated to the Client?
Who determines what information this Token provides - The ID provider or the client application?
What about the case of a Web client where the client and user-agent is not running on the same device?  Can the client or user agent "build" a new token which can be used to sign requests to the API, and include the important details (User-ID, ID-provider, expiry date, client-ID)?
Can the API "session" endpoint be extended to handle "social login" tokens or is that not the correct approach?
Is it important to Identify / Authenticate the Client?  If so how - I believe mobile clients cannot securely store a signing key!?

A note about oAuth and Authorization:  I don't think I need authorisation here.  The API already determines whether requests are authorised based on the identified user.

I would suggest that you start with some of Dominick Baier's courses on Pluralsight.  In particular, you might want to start with his Introduction to OAuth2, OpenID Connect, and JSON Web Tokens (JWT).

If you are writing services that require the user to login every time to use, then I don't think you want to use OAuth.  If you are writing some kind of mobile or service app which needs to later login to these services on the user's behalf, then yes, you should consider OAuth.  As Dominick Baier explains, the OAuth spec is a bit of a mess, and OpenID Connect is even more so.

I would suggest you do the following:

Use a "Federated Secure Token Service (STS)".  The purpose of the Federated STS is to issue your application with authentication tokens which contain "claims" that your application understands.  For example, these claims could contain the user's email address, full name, etc. -- whatever you specify.  When the user tries to access your services, they are re-directed to this "Federated STS" which offers the user choices at to how they want to login (Facebook, Google, Live, LinkedIn, etc.).  The user then logs in, the Federated STS receives the authentication token from Facebook or LinkedIn or whatever, transforms the token and its claims into a format your app understands, and your app then consumes this nicely made authentication token.  There are a number of Federated STS services, including Azure ACS, Azure Active Directory, etc.
You probably want the token to be a JSON Web Token (JWT).  In the configuration of the Federated Identity Provider, you specify how you want it to "transform" claims into a format your application can understand.  For example, if you application wants a "Full Name" field, and Facebook returns a "First Name" and "Last Name" field, you can instruct the Federated STS to convert the Facebook information into a "Full Name" field.
Here is an example of what a JWT looks like:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}
but you can choose to have whatever fields you want.
After the client logs in, is authenticated, and redirected back to your API, the API will typically receive an HTTP header with the JWT token, although there are other schemes.
You can configure the Federated STS so that it will also return the name of the Identity Provider the user chose (Facebook, LinkedIn, etc.)
I don't completely understand your question about the "client and user-agent" not running, but you might want to look at OAuth2 and "refresh tokens" for this.
Yes, it is very important to authenticate the client.
Rather than extend the API to handle different kinds of authentication schemes and tokens, I think you should use the scheme I advocate above to offload all the authentication to a "Federated Identity Provider/STS" so that your code is not tightly coupled to authentication, and so that you can add new "Identity Providers" and "claims transformations" to the Federated STS in the future without any code changes.


Does LoraWan protocol's Over The Air Activation run Diffie Hellman? I am looking at the LoraWan protocol specification and I want to capture the over the air activation of a device. So far I have seen the:

https://zakelijkforum.kpn.com/lora-forum-16/over-the-air-activation-otaa-8323

As it seems that it is using nonces in order to generate the key, I thought, "Hey it seems like Diffie Hellman to me."

Is the Over the air activation in LoRaWan is as the link mentions?
If yes, is Diffie Hellman the key exchange being used?

Let AppK the Application Key. The Application Session Key (AppSKey) and the Network Session Key (NwkSKey) are generated by using only the AES algorithm without adopt the Diffie Hellman protocol.

Let us suppose that we have a Device Node that generates a 16 bits pseudorandom nonce namely DevNonce. This nonce is sent to the application server. The application server generates a 22-bits pseudo random nonce namely AppNonce that is sent to the Device Node.

The Network ID, called NetID is pre-shared between the entities. Moreover a standard 32-bit code (for NwkSKey this is 0x01, for AppSKey this is 0x02) is used.

Finally the resulting message is padded to 128-bits.

NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16)
AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16)

However I advise you this link to deepen the LoraWan Security.


In the context of security engineering, is trust an equivalence relation? This is the definition of an equivalence relation according to Wikipedia:

In mathematics, an equivalence relation is the relation that holds between two elements if and only if they are members of the same cell within a set that has been partitioned into cells such that every element of the set is a member of one and only one cell of the partition. The intersection of any two different cells is empty; the union of all the cells equals the original set. These cells are formally called equivalence classes.

My question is: In the context of security engineering, is trust an equivalence relation?

TL;DR: No, it's not.

The definition of "equivalence relation" that I'm familiar with in mathematics is, while equivalent to yours, much simpler to use to evaluate if something is or isn't an equivalence relation. An relation ~ is an equivalence relation if and only if it is:

Reflexive: A ~ A for all A. In this case, it means "A trusts A." This is generally the case (it's not always the case, but people generally trust themselves to not be malicious to themselves).
Transitive: If A ~ B and B ~ C then A ~ C. This is sometimes true for trust, but not always. I might trust that my friend won't lie to me, but just because he trusts someone who trusts you doesn't mean I trust you at all. This is a key concern of public-key crypto, as you can't directly trust everyone's key who you want to communicate with. Trust transitivity is complicated, and doesn't really hold in full generality (hence why PGP doesn't make "trusted introducer" transitive - your trusted introducer's trusted introducer isn't automatically trusted by you). Part of the issue with the CA system for TLS is it treats trust as transitive (if you trust someone to be a CA, and they trust someone else to be a CA, your browser automatically considers the someone else a valid CA). This is very much a "maybe" then, but it certainly doesn't exist to the degree required of an equivalence relation (for an equivalence relation, if A ~ B ~ C ~ ... ~ Z, then A ~ Z; the same is not true for trust).
Symmetric: A ~ B if and only if B ~ A for all A,B. This is definitely not true of trust: you might well trust someone else who doesn't trust you. You implicitly trust your bank to some degree to manage money; they trust you far less (consider how much they pay you to keep your money and how much you pay them to borrow their money). You might trust Google with your data, but they aren't about to repay the favor.

(Your definition is equivalent to this: A ~ B if and only if A and B are in the same equivalence class. The definition I used is used to show something is an equivalence relation, because it's nice to work with that way. Once you've shown something is an equivalence relation, then you break out your definition and divide some set into equivalence classes using it.)

Lastly, there's a technical requirement that trust doesn't satisfy:

Excluded middle: For an equivalence relation (in fact, for the more general class of binary relation), either A ~ B or !(A ~ B). There is no middle ground. This is certainly not true of trust: You trust different people different amounts; you might trust your spouse completely, trust a friend for the most part, and trust a drinking buddy only a little bit. So trust isn't really even in the class of things that can be an equivalence relation. The problem of transitivity is partly due to this -- transitivity means if A ~ B and B ~ C then A ~ C, and does not allow A to only sort of ~ C. You might trust a friend of a friend, but less than you'd trust that friend; at 10 degrees of separation, there's basically no trust left over.

So trust not only doesn't fulfill the technical requirements to be conceivably an equivalence relation, it doesn't fulfill two of the substantive requirements (it's not really transitive within the meaning of an equivalence relation, and certainly isn't symmetric).


How to treat non-optional bad security questions? Every once in a while I have to set up an account on a site that, while apparently at least not storing my password in plaintext, still force me to choose from a limited set of security questions that can be used for password recovery purposes. Since the questions are usually moronically easy to answer by some googling or social engineering (à la "What's you mother's maiden name?") what is the correct approach when I cannot avoid using this account?

"Security questions" are just an alternative password which is not used often, but which, presumably, will not be forgotten by the user. Since it is a password-equivalent information, treat it as such: use true, high-entropy passwords as answers to security questions. Of course, since you will not enter these often, you should write them down on a paper, stored in a safe place (they are meant to be used as a backup for the "true" password; you do not need them often).

(Note: most systems will handle responses to security questions in a case-insensitive way, which decreases the "entropy" of that password -- hence, make it even more random. 15 random letters would be enough.)


Why is it so hard to close onion domains (e.g. The Silkroad)? A few months ago when I started to experiment with bitcoin I came across  The Silkroad (only accessible via Tor)

For those who do not know what Tor is and who do not want to waste their time installing and checking what is there - you can read this and this comprehensive paper regarding The Silkroad.

In the paper, researchers stated that as much as USD 1.9 million/month is circulated on The Silkroad and most of this money are generated by drug products.

My question is - how it is possible that this site (aside from being completely illegal) was not closed? At one point in time it was quite notorious and there was even a hearing in the senate, but nothing came of it.

What makes onion domains so special that even knowing it carries large amounts of narcotics-related transactions it is still impossible to close it.

Have you seen the Tor document on how a Tor Hidden Service works?

Essentially, in the same way that it's hard to find the source of traffic from a Tor exit node, it's hard to find the server operating a Tor Hidden Service. Authorities can't shut down the server, because they can't find out where it is.

The .onion TLD is not really a TLD (so there is no domain registrar to shut down), but it's recognized by Tor.

There are other methods for tracking it down - checking cash flows, poorly anonymised Bitcoin transactions, even good "old-fashioned" anonymous tips to the police. So far it seems none have been sufficient.

Edit:
Ah, I think I understand the confusion. You're expecting that by flooding the Tor network with malicious exit nodes, you'll eventually create one that's used for the "exit" to a .onion. You'll know it's the target (e.g. Silkroad) because you'll be able to see the traffic contents. This does not work against .onion hosts, because unlike an exit node connection to a "normal" host on the public internet, traffic to .onion hosts is end-to-end encrypted.

So even a malicious exit node does not know that it's connected to the Silkroad host, because it can't see the traffic content.


Is it safe to suspend my computer if I'm using encrypted hard drive? I'm using disk encryption to protect my data and sensitive information - but only one partition.

I used to suspend my computer instead of shutting it down because of very fast resume and very low battery usage.

My question is: Is it somehow possible to access the temporarily decrypted data while my computer sleeps? or Is it insecure? Should I rather shutdown the computer instead of suspending ?

UPDATE

I'm using ecryptfs for encryption. So when I log in it uses my 27-long password to decrypt my data and when I log off or unmount the encrypted partition it wont be readable anymore. Probably logging off and then suspending the computer might be a solution but it isnt my question.

The decryption key is in active memory so it's not benefiting you.  You're depending on the physical and OS level security features (exposed ports, screen locks, file shares, device drivers).

A sophisticated advesary could capture the active key or attack the operating system.   Side channel attacks (e.g., http://en.wikipedia.org/wiki/DMA_attack ), weak passwords, information leaks from your running programs and operating system vulnerabilities (present or future) are all realistic attacks against such a machine.

Most theives would probably not expect encryption.  They'd turn the machine off to try to get past the login screen, losing the decryption key and protecting your data.

If you're not dealing with sophisticated advesaries (e.g, law enforcement or governments), then you're probably fine.  Probably.

"Hibernation" may be more secure, as the system will be "off", with the active memory stored on the encrypted volume.  It depends on the details of the implementation of your hardware, encryption software and OS.


Should OAuth2 Access Token support multiple audiences? I am considering a usecase where an OAuth2 client obtains an access token to access multiple resource servers.

Based on spec, to protect against token redirect attack:

  to deal with token redirect, it is important for the authorization
  server to include the identity of the intended recipients (the
  audience), typically a single resource server (or a list of resource
  servers), in the token.

This means that in our usecase, the access token can have a list of audience URIs and then each resource server would then verify the token has access to its resource.

However, according to the draft spec of the Resource Indicators for OAuth2, the authors state:

  I continue to question the value of allowing multiple resources vs
  the functional and security complexity that comes with doing so.
  Writing the preceding paragraph just underscores that concern. So just
  noting it here.

I have also noticed that identity management providers such as Auth0, only support single audience field values and instead point to using a combination of scope and audience for multiple resource servers.

Other providers support multiple audiences.

So... is there a security problem with having multiple audience values?

It seems to me scope and audience have different intentions and so mixing them up is not necessarily the right approach. According to:

  Scope, from Section 3.3 of OAuth 2.0 [RFC6749], sometimes is
  overloaded to convey the location or identity of the resource server,
  however, doing so isn't always feasible or desirable. Scope is
  typically about what access is being requested rather than where that
  access will be redeemed (e.g. email, user:follow, user_photos, and
  channels:read are a small sample of scope values in use).

Any thoughts on this would be appreciated. Thank you!

Note:

Token redirect:  An attacker uses a token generated for consumption
      by one resource server to gain access to a different resource
      server that mistakenly believes the token to be for it.

Under some authorization models, when you first receive an access token, only you (and the authorization service) know a secret that provides access to the token's audience.

When you present the token to a service in order to authorize yourself, that service also knows a secret that provides access to the token's audience.

If the audience is within a single trust boundary, even if composed of different services, then this does not increase the privileges of the receiving service.

However, if the token can be used by the receiving service to access another service to which it would not otherwise have access, then there is the possibility that it is a bad actor who will abuse this increased privilege.

Hence, an access token should typically have an audience that is within a single trust boundary.

I read the Auth0 link as suggesting that multiple API's within a single trust boundary can rely on a single access token, but use scope to control which API's the user can access, which is consistent with your other quotes.


Protecting data through an XOR operation with sufficiently long keys Suppose two parties S and D would like to protect a communication channel. Therefore, S and D exchange two sufficiently long key sequences SB und DB of random bits over a secure channel [e.g not over the internet]. After this exchange, both know each other's keys.

For example, S and D might (physically) exchange 64 GByte USB-Sticks which contain the other's key sequence.

If S wants to send a message M to D, S actually send M xor SB*.

If SB and DB contain enough entropy [thus are based on a good random source],
and SB and DB are sufficiently long
would this technique protect the message M against third parties?

How would a third party compute the keys SB and DB?

Doesn't this sound much line a one-time pad?

While I used XOR, I actually mean a simple mathematical (e.g. bitwise op + addition) operation.  In general, I thought about the question, if strong cryptography with simple mathematics is possible.

What you are describing is one-time pad.

Assuming that you each bit of the key is used only once, the one-time pad is considered a perfect cipher. Of course, if you reuse any part of the key, the whole scheme becomes laughably weak.

The biggest weakness of the scheme is the difficulty of the key exchange method. The keys used in the one-time pad must be of the same or longer length as the message. If you have a secure method of transferring an arbitrary amount of information for use as key material, why not just use the same transfer method to transfer the actual message?

Also, the key material must be truly random.


Cannot interpret maldet results After executing sudo maldet -a /
LMD provides the following report:
HOST:      foo.bar.baz
SCAN ID:   210117-2223.1145531
STARTED:   Jan 17 2021 22:23:26 +0000
COMPLETED: Jan 18 2021 22:01:12 +0000
ELAPSED:   85066s [find: 42s]

PATH:          /
TOTAL FILES:   579780
TOTAL HITS:    2
TOTAL CLEANED: 0

WARNING: Automatic quarantine is currently disabled, detected threats are still accessible to users!
To enable, set quarantine_hits=1 and/or to quarantine hits from this scan run:
/usr/local/sbin/maldet -q 210117-2223.1145531

FILE HIT LIST:
{HEX}php.cmdshell.antichat.201 : /home/foo/maldetect-1.6.4/files/sigs/rfxn.yara
{HEX}php.gzbase64.inject.452 : /home/foo/maldetect-1.6.4/files/clean/gzbase64.inject.unclassed
===============================================
Linux Malware Detect v1.6.4 < proj@rfxn.com >

I struggle to interpret the results of the two hits. Is it in the home directory and what does HEX mean?

To quote the README from maldetect:

Let us assume for a moment we have malware that we want to clean and
it trips with the signature "{HEX}php.cmdshell.r57.89". The actual
signature string in this is "php.cmdshell.r57", the "{HEX}" just
defines the format and ".89" is the variant number.

"format" in this will be either MD5 or HEX, the two types of maldetect signature.  Quoting again, "The signatures that LMD uses are MD5 file hashes and HEX
pattern matches..."
The two files that had 'hits' were both part of the maldetect distribution that foo unpacked under their home directory:
/home/foo/maldetect-1.6.4/files/sigs/rfxn.yara is a Yara signature file.  It must contain a string that matches malicious software, but which also matches the tests that maldetect runs.  It is not actually malicious.
/home/foo/maldetect-1.6.4/files/clean/gzbase64.inject.unclassed is a cleaner file, which contains malicious strings to be matched and erased from infected files.  Again, it contains a string which matches a test that maldetect runs, but it isn't actually malicious.
The moral of this story is: don't scan the scanner directory.  Here's someone else with the same problem.


What does ModSecurity bring to my hosting account? I read about the hack at Ubuntu Forums yesterday. Since we hold customer data things like this always makes me worried, and I look to minimise our risk of attack.

There is an option to enable ModSecurity in my CPanel. I assume this is done without breaking anything on the site? But what extra security does this bring against hackers and does it allow notification of hacks?

what extra security does this bring

Out of the box? None. You need to add rules to the system in order to start restricting access. The problem is that some of these may break your application.

We don't know what your magic button in cPanel does. I would recommend you have a look at the OWASP rules. If they don't make any sense to you then you need to work on your knowledge of HTTP, attack methods and mod_security before you press that button. And you should be asking the people who provided the button to tell you what it does.

You didn't say if this was a VM, container or shared host.

  I look to minimise our risk of attack

Is that your question or are you only asking about mod_security? Your biggest risk is probably the applications you are running on your server. Keeping them patched and up to date will therefore give you your biggest security wins. Similar for the underlying OS and distribution.

The attack you reference in your post was possible because the admins had not installed a patch available from the software supplier.


Beginner level security for a CS student I am a final year CS student, and would like to study info sec. Till today, I've been reading infosec mailing lists, some Phrack papers etc., but all in a very casual way.

I am interested in learning security in depth, and have gathered that there are some courses like Network+, Security+ etc that provide good exposure. But such courses are not an option for me due to the cost.

I found these to be of interest:
Metasploit Unleashed,
OWASP,
Google Gruyere

How do I really start? Please provide pointers to any online resources if possible. As said earlier, I'm a CS student, and am pretty confident with my programming and networking.

Read Cryptography Engineering (an update from the bible Applied Cryptography) and keep it next to your bed.

Implement some of the code yourself, just so you understand what is behind most of the cryptography code. And then, start coding with OpenSSL.

Understand X.509, PKI and the core of the trust on the Internet. That's a must and you need to know it down cold

Know your network protocols as best as possible, and be able to start tcpdump/wireshark any time you need it, and follow a tcp/udp/ communication.

Security is about understanding how a system works to find its loopholes. Security is not about firing metasploit on random windows exploits and gaining a remote shell. That's for script kiddies.


LFI php://input returning initial argument? TLDR: Trying to execute commands on site thats got a LFI vuln.
So I am making my post request to my vulnerable site and
import requests
header = {
            'User-Agent':'Mozilla/5.0 (Windows; U; Windows NT 6.1; rv:2.2) Gecko/20110201',
            'Accept-Language':'en-US;',
            'Accept-Encoding': 'gzip, deflate',
            'Accept': 'text/html,application/xhtml+xml,application/xml;',
            'Connection':'close'
}

command = "<? system(\"echo does this work\");?>"
requests.post("https://www.vulnsite.com/pog=php://input", headers=header, data=command)

then if i look at the actual response it returns:
<? system("echo does this work");?>
why isn't it returning "does this work"? how can I get it to execute actual commands? what am I doing wrong?

Maybe the your syntax isn't correct inside the system function, and the error output isn't printed. Try your request in the web browser buy using the source mode view with CTR+U.
Inside the system function should be called like this:
<?php system(\"echo 'does this work'\");?>


Is it possible to setup 1-way TLS client authentication without server certificates? Is it possible with TLS to only authenticate the client? In other words can one-way TLS be setup in such a way that only the host initiating the connection uses a client certificate and the second host in the transaction does not require a server certificate?

"Client" and "server" can be vague terms if multiple layers (TCP, TLS) are involved. It is possible and even the most common case that only a single certificate is used inside the TLS handshake, i.e. one party is properly authenticated in order to detect man in the middle attacks. This party is commonly the TCP server but it might also be the TCP client.

If a TCP connection is created from a TCP client (calling connect) to a TCP server (calling accept) then it is possible that the TLS handshake is initiated by the TCP server, thus essentially making the  TCP server the TLS client (calling SSL_connect) and the TCP client the TLS server (calling SSL_accept). This way the certificate is provided by the TCP client (which is the TLS server).


MITM based on ARP spoofing I fail to understand how a MITM attack sniffs packets and modifies them.In the case of ARP spoofing although the attacker has spoofed the MAC address of a host, how does he modify it?
if he listen to the message between the sender and destination  and after the message delivered to destination he sent gratuitous ARP reply ? when he know the message  delivered to destination ?

Generally, to perform MITM attack between A & B, you must apply 3 steps:

Trick A to think you're B
Trick B to think you're A
Enable packets forwarding

To answer you question, there are 3 types of ARP packets, the normal send and reply packets, and gratuitous packets.

Using gratuitous packets, the attacker can modify or 'poison' the targets cache, so he can trick both A & B, and stay in their ARP table as a legit part of the connection.

Note that this kind of attacks can be stopped using some kind of switches which is able to sniff the network for gratuitous arp packets and re-send the correct data through the network.


Persistent Connection Attempts By Akamai Technologies I have seen this question asked in different places, but have never seen a satisfactory answer:

On different computer builds, ASUS/GIGABYTE/MSI, I constantly have outgoing connections to XXX-XXX-XXX.deploy.static.akamaitechnologies.com over HTTP Port 80, and if the connection attempts are denied, the network card (or at least internet connectivity) stops working... LAN connections still appear to work. The outgoing connections occur on every restart, and must be allowed for the network card to function properly. If the attempts are denied, the system must be restated so that the connections will be attempted again and can be allowed.

This post suggests narrowing down an offending application, but I don't see how akamai technologies can be so intertwined in so many systems, cut-off connectivity if not allowed, etc. Something about it feels like unauthorized (or at least unwanted) information transfer, at the very least a phone-home, but I have no Wirshark captures to confirm this :)

My primary guess after looking at all the symptoms: the connection attempt is trying to see if there is internet connectivity, and if the attempt fails Windows assumes there is none... But this sounds really, really dumb.

CDNs commonly serve their pages based on the geographical allocation of the ip addresses of the connecting user. You could use a proxy server for all your http requests but directed at a country that is nowhere close to where you are located. At the end of it, if the requests still head off towards those ip addresses, you'll know that something isn't quite right.

However, that was a while back. Now CDNs also serve contents such as updates, etc. So if you can corroborate the connection as a valid service for something like Apple updates, especially with real life users, then you can be sure that it is a valid request.


Should I client hash user and password, HTTPS to password_hash on PHP/MySQL server? Following on from my earlier question Do I enhance security by appending all passwords with a fixed long string? I believe I can use PHP password_hash function with bcrypt on my server.

Two questions...

Do I hash the user so that I can search for the user with a fixed string in the database, then compare the password_hash() stored value with password_verify() and client hash pass ?

Do I have any advantage to hashing the password, or do I just send it unaltered over the HTTPS wire? I read elsewhere that this is fine but it leaves me unsettled.

I have resolved - this is the process I am following in case anyone is interested.

During initial registration, user enters a login and password. Both are hashed, sent over HTTPS to the server.

Server DB saves the client login hash and the output to password_hash($pass,PASSWORD_BCRYPT, ["cost"=>12]) to the db.

Later, during login process, user enters login and password. Both are hashed, sent over HTTPS to the server.

Client requests server to search DB for the loginhash, retrieves the password_hash output.

if password_verify($clientpass, $dbpass) return true, then password is valid, else false/password invalid.

This works for me.

Why do I hash the user and the password on the client even though they go over the wire as https? Because fixed lengths are faster to search for in the DB (I mysql prepare all my queries to ensure not to depend on dirty client data). Also because even though the data goes encrypted, I prefer a long sequence of characters over the wire as opposed to a short sequence which a username/password might contain - in my world, it feels better though I believe from what I read I don't get if anything extra for the effort.


Sulley - optional element and command check I'm currently using Sulley to fuzz my FTP server, but I'm having problems. I want to specify the STRU command, which has a syntax:

STRU [<SP> F|R|P] <CRLF>

I tried to specify the optional F,R,P arguments to the STRU command like the following:

s_initialize('DataSTRU')
s_static('STRU ')
s_group('struv', values=['F', 'R', 'P'])
s_block_start('strub', group='struv')
s_block_end()
s_repeat('strub', min_reps=0, max_reps=1, fuzzable=True)
s_static('\r\n')

This sends the right commands to the FTP server (STRU F; STRU R; STRU P), but the problem is that is it. It doesn't try to omit the character or fuzz it, which I would also like. I know I can just specify the argument to fuzz, but I would like to fuzz the argument as well as mutate the valid arguments. Any ideas how to apply the optional+fuzzable argument to the above code?

Another problem is that I don't know how can I check which command is currently being used - I'm using the commands inside s_block_start and I'm iterating through the s_group element like the following:

s_initialize('DataSet')
s_group('commands', values=['MODE', 'PROT', 'STRU'])
s_block_start('DataBlock', group='commands')
s_delim(' ')
  // TODO: how to check whether:
  // if   [current_command == 'MODE'] do this
  // elif [current_command == 'PROT'] do this
  // else [current_command == 'STRU'] do this
s_static('\r\n')
s_block_end()

That's it. Any ideas and recommendations are welcome. Thanks

Since both of your questions relate to groups, we should look at how they're used first. The purpose is to bind block data to a set of static values -- sulley iterates through the list of values and generates block data for each one.

The example in the docs uses HTTP, where the block data is a simple HTTP request and the group values are HTTP verbs ('GET', 'POST', 'PUT', etc). In the example, sulley generates and fuzzes the data block (the request) for each HTTP verb in the s_group:

# define a new block named "HTTP BASIC".
s_initialize("HTTP BASIC")

# define a group primitive listing the various HTTP verbs we wish to fuzz.
s_group("verbs", values=["GET", "HEAD", "POST", "TRACE"])

# define a new block named "body" and associate with the above group.
if s_block_start("body", group="verbs"):
    # break the remainder of the HTTP request into individual primitives.
    s_delim(" ")
    s_delim("/")
    s_string("index.html")
    s_delim(" ")
    s_string("HTTP")
    s_delim("/")
    s_string("1")
    s_delim(".")
    s_string("1")
    # end the request with the mandatory static sequence.
    s_static("\r\n\r\n")
# close the open block, the name argument is optional here.
s_block_end("body")

From the doc:

  When this defined request is loaded into a Sulley session, the fuzzer
  will generate and transmit all possible values for the block "body",
  once for each verb defined in the group

Now for the first question, you're getting only the 'STRU F' 'STRU R' and 'STRU P' strings because each value in the list supplied to s_group() is treated the same as a string created with s_static() -- they aren't mutated.

You can try this:

s_initialize('DataSTRU')

for op in ['', 'F', 'R', 'P']:      # trying to include your missing-arg case
  s_block_start('stru-%s' % op)
  s_static('STRU')
  s_delim(' ')
  s_string(op)
  s_static('\r\n')
  s_block_end()

Which is closer to what you were aiming for, but you can probably get away with just this:

s_initialize('DataSTRU')
s_block_start('stru')
s_static('STRU')
s_delim(' ')
s_string('F')
s_static('\r\n')
s_block_end()

Which fuzzes the space (s_delim()) and the parameter (s_string()).

For your second question, you don't need to check which command is being used. If the blocks are specific to a command, just define them separately:

s_initialize('DataSet')
s_block_start('mode')
s_static('MODE')
# MODE-specific primitives
s_block_end()
s_block_start('prot')
s_static('PROT')
# PROT-specific primitives
s_block_end()
for op in ['', 'F', 'R', 'P']:
  s_block_start('stru-%s' % op)
  s_static('STRU')
  s_delim(' ')
  s_string(op)
  s_static('\r\n')
  s_block_end()


how would a 12-digit password be a safe guard in this situation? So guys, I messed up with the configs in a computer and let the SSH server open to the wild with ROOT login enabled. I'm trying to assess the potential damages, which I may never know for sure.
Regrets apart, this mistake lasted for over a year until I verified several SSH authentication attempts in secure.log (bots and/or skiddies) with random users, but some tried with root. The secure.log shows that all root connection attempts failed and no break-in evidence, but I may not rely on those logs anymore.
My hopes resort in the fact that I changed the default SSH port (not really a security measure) plus a 12-digit password (capital and noncapital letters plus symbols, so 72^12 possibilities), however I don't know if a 12-digit password is really worth a security matter these days. Even considering a swarm of bots (between 300k to 6M), it would take years to break the password, but DoS and DDoS are other possibilities and I wanna try to reach some peace of mind.
Unfortunately, I had to format and re-install Linux in this computer given ongoing needs, but I've kept /var/log/ files in case of an investigation. The network admin (the computer wasn't at my home) didn't notice any suspicious activity, then I came up with a few possibilities after some research:

OK scenario: password was worth its length and it managed to hold any intruder.

Possible solution: I'd harden my security configs and (even) consider to keep the OS.
Comment: the intruder may have cleared the logs to trick me, so better to be sure and format anyway.

Bad, but manageable scenario: someone managed to connect and setup a botnet/spammer/bitcoin miner.

Possible solution: I'd format the computer and harden my security configs.
Comment: no suspicious network activity had been noticed and I'd have noticed some CPU stress and/or other symptoms, but none seen. However, I used only SSH terminal with no graphic interface (tty) in this computer, so symptoms would be possibly less evident (?).

Really a bad scenario: intruder accessed my computer, stole my data and/or ransomware.

Possible solution: I'd format the computer and harden my security configs.
Comment: OK I'd need to live with that, but the hardware would be reusable. Otherwise I'd know it for sure if my data were encrypted by the intruder in view of a ransom.

Worst-case scenario: intruder break-in plus a rootkit/keylogger/sniffer/worm.

Possible solution: I'd format the computer and harden my security configs, unless a more serious intervention had been done, like BIOS or HDD/SSD firmware virus/rootkit.
Comment: I believe a hardware-level threat means game over for MB and SSD/HDD.
In summary: (1) would be fine; (2) seems very unlikely, since no alarms were triggered, (3) is bad, but hardware still OK, and (4) is the worst scenario. I believe a compromised root password is way worse than getting a rootkit from some suspicious downloaded app (just guessing), especially if it is nested into the hardware.
Therefore, scenario (4) worries me and I presume I don't have any means to find out if my computer had an intervention at hardware level. Per my research, BIOS and SSD/HDD firmware hacks are possible and usually meant for high-level targets (not my case), but rare for ordinary users and very hardware-dependent (I found lots of debate on internet).
So, did my 12-digit password play a good defense in this case?
If not, any thought/ideas/suggestions in ways I could verify my hardware are appreciated.

I used to exclusively use fail2ban in conjunction with blocklist.de to mitigate and report ssh brute force attacks.  As I have gotten older and more experienced I  have found that although this is effective it is not the best security model and it makes unnecessary server load.  Now that I am older and more experienced I use ssh key pairs.  This is what both Amazon and Microsoft use for their cloud services.  I recommend doing this instead of relying heavily upon passwords.  You can protect yourself with just an ssh key, and ssh key and a password or even an ssh key and a physical token like a yubikey.  I have never set up a yubikey for ssh but I understand this has been implemented recently into ssh.  If you want a good primer on generating and setting up ssh key pairs I recommend using the documentation written by github for setting up ssh key pairs. This is the most comprehensive documentation I have seen and I used it myself when I had to create a new stronger key when at a previous job because of the risks of an older encryption method.


What is the implication of HSTS on unsupported browsers? HSTS is currently available only on Edge and IE11. What will be its implication on lower browser versions (IE9 & IE10)? How will HSTS behave? Will there be any impact on the site?

A website implements HSTS by sending a Strict-Transport-Security header. A browser that doesn't understand the header will simply ignore it, just like any other custom or malformed header.

  Will there be any impact on the site?

The impact will be that the user becomes vulnerable to attacks that HSTS is supposed to protect against (i.e. HTTPS downgrade attacks). That is, if the user visits the site, their browser won't notice that the sites instructs them to remember to only connect to the host via HTTPS for a specified amount of time. So, if the user types in mybank.com, their browser will always attempt to connect to the site via HTTP first instead of recalling the HSTS directive.

Besides the MITM threat (and the risk of running an outdated browser), there will be no impact on their browsing experience.

Somewhat related:

How can a web application protect users when the browser doesn't support HSTS?


Does this look like a DDOS attack? I've put up a small proof of concept web api on AWS infrastructure (elastic beanstalk) using their free tier. My app is working fine, but I'm seeing a lot of this in the access logs:

172.xxx.xxx.xxx - - [18/Jun/2017:10:18:59 +0000] "POST /device/enabler/linear HTTP/1.1" 403 362 "-" "Mozilla/5.0" "149.100.171.172"
172.xxx.xxx.xxx - - [18/Jun/2017:10:18:59 +0000] "POST /device/enabler/linear HTTP/1.1" 403 362 "-" "Mozilla/5.0" "2.227.202.134"
172.xxx.xxx.xxx - - [18/Jun/2017:10:18:59 +0000] "POST /device/enabler/linear HTTP/1.1" 403 362 "-" "Mozilla/5.0" "93.44.33.132"
172.xxx.xxx.xxx - - [18/Jun/2017:10:18:59 +0000] "POST /device/enabler/linear HTTP/1.1" 403 362 "-" "Mozilla/5.0" "93.37.77.196"
172.xxx.xxx.xxx - - [18/Jun/2017:10:18:59 +0000] "POST /device/enabler/linear HTTP/1.1" 403 362 "-" "Mozilla/5.0" "151.62.133.102"
172.xxx.xxx.xxx - - [18/Jun/2017:10:18:59 +0000] "POST /device/enabler/linear HTTP/1.1" 403 362 "-" "Mozilla/5.0" "95.249.219.42"
172.xxx.xxx.xxx - - [18/Jun/2017:10:18:59 +0000] "POST /device/enabler/linear HTTP/1.1" 403 362 "-" "Mozilla/5.0" "2.34.37.138"

I'm seeing about 7 hits per second, and it's always a POST to /device/enabler/linear.  The URL is not part my app at all.  I've reverse DNS'ed some of the IP's, and they all seem to be from Italian ISPs (not sure if that is relevant).

It's not a massive issue at the moment as it's not preventing my app working (so not really sure if it counts as a ddos?), but it is a nuisance, and it has caused me to take the service down (so arguably has succeeded).  And it will start to cost me money at some point because the access logs are being written to much faster than I anticipated so I will exceed the S3 puts that are in the free plan.

I'm in the process of working out how to configure the AWS EC2 firewall stuff (I think that's what I need to configure to allow access access from my client)

Has anyone seen this type of thing before? Could it be a ddos? has anyone seen hits to this url like this (I've googled for it and drawn a blank)

Appreciate any advice anyone can offer;

It's not a massive issue at the moment as it's not preventing my app
  working (so not really sure if it counts as a ddos?)

let's state some definitions

Denial of service : If service has not been denied by the attack, It's not DoS nor DDoS. It might be abusive, but that wouldn't be quite the same stuff.

Assumption

93.44.33.132, 2.227.202.134, 93.37.77.196, 151.62.133.102, 95.249.219.42 and 2.34.37.138 have a negative reputation, says symantec.
Regarding a DDoS attack, 7 requests per second are not a lot. The post request size might be a hint. For instance if the size is greater than 1 Mo, yes, it can be a DDoS attempt.
The numbers 403 and 362. Assuming those numbers is a response code, it looks like your app is denying the access with a 403 Forbidden, 362 may state why the access is forbidden. <- i might be wrong with this point.
So what do we have ? We know that some low reputation IP are making 7 POST request / sec. On a URL that doesn't exist. From my experience, we do not have enough info to determine if this pattern is a DDoS attack. We have to go deeper.

Going deeper

For further investigation, i will start by fetching three entire post requests and their responses (with different source IP).

the goal is to:

Know the size of the 3 requests/responses.
Find any payload in the request's header or content.
what data those requests are posting.
what are the responses and how your app handle those requests.

Not in the question range

Knowing if a reverse proxy is present between the client and the app might be interesting too. For instance, those requests might target the proxy and not the app, for cache poisoning purpose.


Attacking WEP/WPA/WPA2 When attacking WEP/WPA/WPA2, I see people buy a wireless network adapter (e.g. Alfa). Why can't an inbuilt adapter in a laptop work? Or in other words, is there a quick way for me to check if the inbuilt adapter in my laptop could work for this attack? A simple command perhaps?

Relating to Baron's answer, he stands corrected with supporting packet injections, but they also need to support monitor mode too. For example, when I run:

airmon-g start wlan0 - This will convert my wlan0 to mon0 or mon1 depending on the interface chipset. Inbuilt can work, but they're sometimes not as powerful as they need to be and again, some don't support the correct requirements.

  Usually the wireless adapter is unable to transmit in monitor mode and is restricted to a single wireless channel - source

To check if it supports monitoring mode, type iwconfig and you'll see wlan0 or something similar. If you have a pentesting distribution or the aircrack package with airodump etc. You can type airmon-ng start wlan0 which will place your adapter into monitor mode and changing the interface from wlan0 to mon0 or something similar.

Edit:

Adding some more info on the channel limitation, see here.


How can I set my server to only accept requests from my own client app? (similar to SSL Client Certificates) I'd like to have my server APIs only accept requests from my own app, to prevent other "rogue" clients of my service.

As i understand it, the way to do this would be with a "client certificate" that the app sends, and that the web server is configured to verify.

However, I'm hosting my app in Heroku, and I believe it's not possible to do that, so I'm looking for something as good as possible that would allow me to achieve this.

I thought that maybe I could have a key pair, where the client uses a private key to sign a certain agreed-upon token (plus some random salt, so that the encrypted string is always different), and the server uses the public key to verify the token (and rejects duplicate salts to prevent replay). Or maybe the client signs the whole request with its private key, or something like that.

The idea would be that even if someone manages to get around our SSL pinning (with something like iOS kill switch, potentially) and inspect our traffic and figure out how our API works, they still can't call us unless they reverse engineer the binary to extract that certificate / private key. I understand that it's possible to do that, I'm just trying to put up as many barriers as possible.

What are good ways of doing this?

This type of problem lends itself to Cargo-Cult Security type "solutions".

In the real world there is no possible mechanism that can prevent a rogue client from connecting to your service. A VPN is a proven security system that allows trusted clients access to a trusted network,  but the internet is inherently untrustworthy.  The attacker will have access to any secret embedded in your app,  or stored in app memory,  TLS client certificates rely upon a secret.

When designing a web service never forget: "The client is the attacker,  and can never be trusted."  If you have made this mistake,  then you need to go back to the drawing board.


How to configure .NET's PBKDF2 implementation (Rfc2898DeriveBytes) in 2019? I want to use .NET's Rfc2898DeriveBytes functionality in order to store my passwords in a database. In order to use it, I still need to make several decisions which will influence the level of security provided. These decisions are:

Salt length
Add pepper before hashing or not
Pepper length
Iteration count
Algorithm choice (MD5 vs. SHA1 vs. SHA256 vs. SHA384 vs. SHA512)
Hash length
How to combine the parts for the DB
The size of the DB field(s) needed

What are sensible values for these (in the current year 2019)?

Salt length

As mentioned at some point in this answer

  16 bytes are enough so that you will never see a salt collision in your life, which is overkill but simple enough.

Pepper

According to a comment under this answer, you should indeed use it:

  You make a pepper look as something only useful with a HSM, which it is not. Its purpose is to have different salts on different places, thus forcing the attacker to compromise all of them. Typically, the salt is stored with the username in the db but the pepper is stored in the login server. Thus making some leaks resistant to offline guessing: A broken RAID disk from the database server is leaked, but the pepper was stored in the web server; or the db was obtained through a SQL injection but the configuration file is not.

However, according to this question, the server side key should not be a "pepper" (= added to the cleartext password and then hashed):

  There is a better way to add a server side key, than using it as a pepper. With a pepper an attacker must gain additional privileges on the server to get the key. The same advantage we get by calculating the hash first, and afterwards encrypting the hash with the server side key (two way encryption). This gives us the option to exchange the key whenever this is necessary.

Instead, the result of the hashing process should be encypted with a secret key which is kept out of the database (for example, it can be kept in the code). By using (two-way) encryption for this, it can be re-encrypted in case the key has been leaked. Example code for doing this  can be found in this answer(using 2 distinct keys instead of one in this case).

Iteration count

This needs to be tested on the actual hardware. More iterations make it take longer for an attacker, but also for your users. An often stated goal is to make it take around a second to log in.

Algorithm choice, Hash length

According to this answer:

  Choosing a derived key length that is less than the output length of the hash function makes little sense, [...] I'd suggest SHA-512 as the PRF, with a 512-bit derived key

So SHA-512 as algorithm, and in C# we would use .GetBytes(64) on our instance of Rfc2898DeriveBytes in order to get a 512-bit derived key.

How to combine the parts for the DB

There are several ways to do this. I would advise the following pattern:

{hasherVersion}${encryptionVersion}${payload}

hasherVersion is a number for the "version" of the hasher. Every time you change your way of hashing - be it increasing iterations or switching the algorithm entirely - you increment this number. This way, you can see if it was stored with an older version and can update it accordingly (e.g. when a user logs in).

encryptionVersion is pretty much the same, but for the encryption. Additionally, this allows you to update encryption in the database in parts.

payload is the actual encoded password. In order to create the payload, the steps are:

Create the random salt
Using the salt, create a hash from the password
Concatenate salt and hash into a single byte[80]
Encrypt that byte[], using the server-side secret
Convert the resulting (encrypted) byte[] to Base64

The size of the DB field(s) needed

120 characters should be enough for a long, long time:

108 characters for the Base64-encoded salt+hash
2 characters for the 2 delimiters
5 characters each for hasherVersion and encryptionVersion

The first 2 are hard numbers. For the versions, well, probably 3 each is already enough (if you need to change those more than 999 times, you should probably try something else), but 5 each gives us a nice round end result of 120 characters.


Cannot figure out how to bypass this function for lfi I'm currently doing some practice about security and facing challenges provided in a website.
One of them talks about LFI and I did figure out what to do, but I have no idea how to do this, so let's show you the problem:

Here is the url to hack:

http://example.com/challenge27/?page=contact

I'm asked to get the password in /etc/passwd, so the first idea that comes is to try some directory transversal:

http://example.com/challenge27/?page=.

This throws an exception:

Warning: assert(): Assertion "strpos('includes/..php', '..') === false" failed

What is obvious is that the strpos detects every occurrence of '..' in the path and the assertion checks that this function returns a false value

Then I try it by adding a null byte at the end of the same url

http://example.com/challenge27/?page=.%00

which gives me another hint:

Warning: file_exists() expects parameter 1 to be a valid path

But here I'm blocked, my goal is to inject the path to /etc/passwd like this:

http://example.com/challenge27/?page=../../../../etc/passwd

I feel like I can exploit the null byte solution but after trying many different urls either I got the file_exists() warning or the assert() one, I'm running out of ideas now, does somebody have one more hint to give?

Usually it will be the path, followed by null byte in order to terminate the string when the C code runs that actually retrieves the file:

http://example.com/challenge27/?page=../../../../etc/passwd%00

Note that null byte characters don't work in up-to-date versions of PHP.

The other challenge is to get .. past the filter.

Try these to see if they can bypass this checking:

Try using 16-bit Unicode encoding (. = %u002e).
Try double URL encoding (. = %252e).
Try overlong UTF-8 Unicode encoding (. can be %c0%2e, %e0%40%ae,
%c0ae)


What can I do with blind SQLi if the database is encrypted? During a pentest engagement, I found a blind SQLi and I can read all tables and data in them. There is just one problem. They are using a static AES key (defined in web.config and I don't have access to it) and all CMS login credentials are encrypted. All critical data are encrypted at cell level, even first name, last name, email, etc,

Although client accepted the finding, they say its not too critical as I couldn't really get access to anything, I couldn't even login to CMS, I couldn't really do "anything" other than reading encrypted BLOBs. I know finding is enough, I just want to be able to prove my point and take it to the next level.

The server is MSSQL 2012 and Win server 2012, web app is written in C# / ASP.NET. I read everything in DB, but the web app's SQL user is low privilege, I only have blind SQLi (time based, slow and no stacked queries, just reading data) and MSSQL port is not open to internet.

Am I missing something here? Can I do more here? Can I get more access than I got? I just want to prove a point and don't like how client downplayed my finding by (rightfully) claiming that my finding didn't really amount to "something". Please advise. I have full sqlmap sql shell here, I even ran custom queries, got stored procedures list, got list of all DBs, all tables, etc but as I said, they wrote some code and using a static (unknown to me) key, everything is encrypted at cell level.

You already cracked half their defenses. Now all that's left is a compromise of the AES key. That should be a reason to worry. Especially because changing that key won't be trivial, because they would have to re-encrypt the whole database to do that.
Symmetric encryption with a static key on cell level means that duplicate values stay duplicate values. This can give you a hint about the content of some fields. For example, if you know that a certain database row has the value "HIV positive" in a specific field, you can now identify all other rows which also have that value.
When you have a blind SQL injection, you might be able to destroy data using UPDATE or DELETE. You can also INSERT data, but without the encryption key you can only insert gibberish. This might still cause trouble, though.
You said you can get the stored procedures. Those might do something useful even without having to encrypt or decrypt anything.


Browser Fingerprinting and Passwords stored by browser I am using the Firefox browser on a Linux system and it came to my knowledge that it is possible for sites to take a fingerprint of the user visiting their homepages.

So I actually have four questions regarding the thread:

1) It was written in the article I read that it is even possible for them to learn my computer name, is that true?

2) The passwords I have stored in Firefox, are they also possible for them to get via fingerprinting techniques?

3) I just did a test on panopticlick and realized that my noscript addon seems to prevent a lot of fingerprinting on their site, how accurate is this test and are there more advanced fingerprinting tests on the web or is this really all that can get fingerprinted with modern techniqes?

4) Is there away to check if a site is using fingerprinting on me?

Browser fingerprinting does not go so far as to reach into the computer name
Fingerprinting does not reach into secured data areas, so your stored passwords are safe from this technique.
panopticlick does not appear to disclose what updates they have made, so it is not possible to determine how accurate it is against the most modern techniques.

Edit
4. Most browser fingerprinting techniques are passive, so you won't know it is happening. There ARE some active fingerprinting techniques that you might be able to detect.


Is this password-less auth flow secure? I'd like to implement a password-less auth flow for my mobile app that only requires a user clicking a link in their email to log in. Similar to how Slack handles auth. I'll be using node and jwt for this implementation.

I think I've come up with a secure design, but I'm sure I'm missing something. I would love some critique from the community.

Here we go:

User opens the mobile app.
We check to see if user has a token in their local storage.
If they do, we add that token to their headers and send to the home page of the app.
Else, we prompt them to enter their email to get started
When they click "Submit", we POST that email address to the requestMagicLink endpoint on our server.
The server checks the database for a user with that email address
If we find a user with that email, we take the id from that user
If the user does not exist, we create a new user, and get that id
We use JWT to generate a token with the id, and our secret that expires after 1 hour
We send that token to the user via a link in an email.
Upon being clicked, that link sends a GET request to our server at the magicLogin endpoint with the token in a query param
We verify that the token is correct using JWT and our secret.
If it fails verification, we redirect the user to the screen where we prompt them with their email to get started.
If it's successful, we generate a new JWT token using their id, and our secret that doesn't have an expiration, then pass that back to the user in the params of a URL that redirects them to a success page in our app.
The app takes the token from the param and stores it in local storage until the user chooses to logout, and the user is redirected to the home page.
The requests to the api all now contain the token in the headers, and the user is good to go.

EDIT (adding additional thought):
Something I'm considering to make it more secure: What if we split the token into 2 pieces, and send half to the mobile device and the other half to the email. That way, only the user with access to that email AND access to that specific device will be able to authenticate.

The main concept of your flow (magic links) is one of the more well known password-less alternatives for authentication. The general consensus seems to be that the security of such schemes (as has been noted in comments) is not any worse than that of a system that allows 'forgot password' email reset mechanisms. This does make sense considering that the point of failure is now in the email part.

Email servers are generally not encrypted and mail can end up stored in insecure locations such as the user's mail client. You will also have no control over how securely the user sets up their email account. It might also be useful (since it's often compared to it) to remember how hard it is to implement a password reset securely. In the end whether or not this should worry you is really dependent on your threat model and the value of your app's data.

Sources that I can find that support magic links and other password-less schemes are mostly from vendors who have a vested interest in pushing their own implementations of this system (e.g. Auth0, okta) and there are some big names that already support it such as amazon-cognito. You can also take a look at similar questions from this stack:

Password-less authentication in web apps - How safe it is?

Passwordless login over email - security considerations

As for your custom implementation there are several concerns worth mentioning:

Don't create users whenever there is no existing email-address. Endpoints and web forms are regularly spammed and you'll find your DB filled with junk.
There might not be a need to send a token in the email and instead just send a link directly. Just make sure that the link URL is generated randomly and that again the expiration is set to disable use.
As mentioned above emails can easily be compromised so you should set a shorter expiration to mitigate. In most cases your users will be accessing their email directly after anyway so I would keep it in the range of 5-10 minutes.
After login the JWT should also have an expiration even if it's a long one. You don't really want the tokens to be valid indefinitely.

To be honest I wouldn't recommend setting this up yourself if you can avoid it; Try to find libraries that already support this functionality.


How can Microsoft validate a shorter password on Microsoft accounts (MSDN)? I recently ran across this when logging into MSDN. (I saw this screen after typing my initial credentials.)

I have a 20+ digit password, however there's apparently a new requirement for Microsoft accounts for password to be no more than 16 digits in length. If I type in the first 16 digits of my password, I'm able to log in.

That got me thinking: if passwords are being stored as one-way hashes, a hash from a 16-digit password and a 20-digit one are not remotely similar. You cannot validate a 20-digit hash using only the first 16 digits.

If Microsoft is properly-storing passwords (salt & hash), how can they validate a shorter version of my password?

Three possibilities:

Microsoft was always truncating it and you just were not aware.  Can you use the old system with a 16 character password and wrong characters at the end?
They were storing the passwords in plaintext (or equivalently encrypting the passwords, allowing them to decrypt the password to truncate it).
When you first migrated accounts (or secretly in anticipation of you eventually migrating), they required you to enter the full 18-character password, checked that you were who you said you were against that, and then created and stored a new 16-character hash of the truncated password for the new system.  This is unlikely but possible.

Regardless, truncating passwords or forcing short password lengths is bad password policy.  It prevents easy-to-remember moderately strong passphrases; e.g., correct horse battery staple which is 28 characters long.  Password lengths should not be truncated until at least ~50 characters or so.  If your database requires a fixed maximum length, it probably makes sense to truncate somewhere around 100 characters or so at which point it is allows passphrases which probably have more entropy than can fit into a 128/256 bit hash which are perfectly strong hash lengths.


What to do after a BadUSB attack? I'm asking myself what to do after a user gets attacked by BadUSB? (Full scan, boot-time scan, ...?)

Is the "bad usb" stick even able to infect the user's system with malware or other spy tools?

The problem with someone being able to execute commands on your machine is that they don't really need a virus at that point. They can use perfectly legitimate tools/commands to obtain and retain ownership of your machine, so anti-virus is rather moot.

The only "right" suggestion for what to do after being victim of an attack is to format the machine and start again. And hope that you were being diligent with your backups.


Is there a way to report IP addresses scanning for Exploits? We're currently running a web site using .NET, and I'm using the Elmah package to look at some errors and issues in real time.

I've noticed that there are a number of errors in the log from IP Addresses that seem to be scanning for PHPMyadmin exploits, etc.

While we're not affected by these particular scans, I'd like to report these IPs so that others may possibly be protected.

What is the proper way to report this, and who should I report it to?

The proper method is to contact the provider's abuse email which is almost never answered. You will waste an enormous amount of time trying to report addresses. Further, most machines scanning for exploits, are often compromised machines in their own respects. You can try going to an upstream provider, but I can assure you, said providers are often overwhelmed with so many requests, it will go unnoticed.


Someone detected my location on Omegle I was in Omegle and was chatting with someone when he told me "wanna make a bet?" and I say sure why not.

He tells me he can identify my location and proceeds to put all my internet connection information and computer.

Then he tells me the town city and country I live in (not my complete address)
Should I be worried?

TL;DR - No, this is common on omegle..

In order for Omegle to work. It connects every pair via UDP. This exposes the currently paired client's ip address. They were simply running wireshark, found your IP address and ran a lookup on it.

Here is a youtube example of this.


How secure is HTTPS with weak ciphersuites? Today I came across the website https://mtgox.com/, which claimed to be secure because of the Verisign certificate. I checked the certificate out of curiosity (it's the first thing they claim, let's see how secure "secure" is), and it was 128 bits RC4 with MD5 for message authentication.

As far as my knowledge goes, is AES the best current symmetric encryption algorithm. RC4 seems okay too, but Wikipedia argues against its use in new systems. And then MD5... Despite the loads of criticism, is seems actually secure enough when you don't have a big enough bounty on a hash, but there still is a lot of criticism on using it.

Also note that the cleartext is partially known here, like parts of the <head> and certainly the doctype. I'm not sure if this can be used in an attack with RC4 though.

So how secure is this ciphersuite really? What would it take to tamper with this connection? Or what does it take to read the transmitted data, given unlimited time? And are there even lower suites in use, for example in common but somewhat dated browsers (like FF3.6, IE8, etc)?

RC4 is now not considered secure, there are documents that explicitly forbid its use in TLS: RFC7465.

You should not use RC4 currently.

post updated as obsolete information about crypto is dangerous

Obsolete information, as posted in 2012:

RC4 is secure, in fact, if you're not using TLS 1.2 then you should be using RC4 to protect against BEAST.

MD5 is insecure, but if it's used as a MAC function it's not yet broken

To their credit, if you have disabled MD5 hash, it will negotiate with SHA-1, in fact, if you disable RC4 it will negotiate AES: https://www.ssllabs.com/ssltest/analyze.html?d=mtgox%2ecom&s=72%2e52%2e5%2e67


Is this code vulnerable to any attack? I found the following code on this page. Is this indicative of a security problem.

;}else{str=" Following ";}
document.getElementById("follow_"+count).innerHTML=str;}
function checkLoginForFollowWidget(root_imageurl,company_id,flag,count)
{ajaxController.isUserAuthenticated(function(response){if(response!=null){i

I got this when I submitted null search box. Is this a vulnerability? I think displaying the code on the main page is like code is getting exposed on the webpage?

When I put this in Google search, I get many websites having such information on their webpage.

Seems to be by mistake, I saw it on many of these small job boards / platforms but not on other websites.

The code looks like some part of a social media widget which was pasted in a job posting by accident as it seems.

Also the code is harmless.


Does DTLS support SNI? The client hello record format in DTLS RFC at https://tools.ietf.org/html/rfc4347#section-4 does not mention this. However, since SNI is mentioned in TLS extensions RFC at https://tools.ietf.org/html/rfc6066 and DTLS RFC seems to be  silent on how to handle TLS extensions, I am not sure what is the official word on this. Any inputs appreciated

Applies, but was forgotten in spec.

Judging from the IETF mailing list it was forgotten inside the RFC document.

Relevant mail is the second in the thread:

  Good point.

  DTLS is intended to support extensions--and OpenSSL, at least,
  supports them in the same way as it does for TLS.

  There probably should be a definition of ExtendedClientHello
  in 4346 and 6347, but it's exactly the PDU you would expect.
  I.e., the extensions come after the CompressionMethod.

  -Ekr

Full thread

There is a nicely rendered thread on GMANE. And the individual posts are as follows:

[TLS] DTLS lacking TLS extensions ?, Martin Rex (Archived here.)
  Re: [TLS] DTLS lacking TLS extensions ?, Eric Rescorla (Archived here.)
    Re: [TLS] DTLS lacking TLS extensions ?, Martin Rex (Archived here.)
      Re: [TLS] DTLS lacking TLS extensions ?, Marsh Ray (Archived here.)


Why not ask for a password and 2-factor token at the same time? I have observed a number of web-based login forms that offer 2-factor authentication do token entry on a second form after validating your username and password.

Is there a reason not to ask people for their 2-factor authentication token at the same time as their username and password?

A login form could detect a username that has 2-factor authentication enabled before they complete the login and present them a token-entry box on on the login page.

This would leak whether any given username had 2-factor authentication enabled, but wouldn't confirm a valid password without a valid token.

Many OTP systems allow you to receive an OTP by SMS/email. So the system has to know when to send you an OTP.

You might suggest that there could just be a "request OTP" button next to the form. But then anyone can repeatedly click on the button, meaning that you will receive a huge amount of spam email/SMS.

You might suggest fixing that issue by limiting the rate of OTPs. But then I can cause you a denial of service by requesting your full quota of OTPs so that you can't log in.

A simple solution to this is to only send an OTP to a user that has provided a valid password.


Linux file information leakage What information is kept in a linux file about the user and/or system that created it?

I want to make some files publicly available, posted on another server such as GitHub or FTP, but I'd rather the original user & system information not be included.

How can my intent be implemented?

The information you're talking about (UID, GID, timestamp, et.c) is stored in the file's inode. In UNIX systems, the inode is created whenever a file is created and it stores meta information about the file. When copying a file from system A to system B, a new file is created at B, thus a new inode is created for it. This inode now contains information about the file at system B, not about the file at system A. Both inodes can be completely different, depending under what user FTP was running, when it was uploaded, etc.

However, the file itself could contain sensitive information (like David Tonhofer mentioned), so make sure there's nothing like that.


How to synchronize changing password in my app with the server? I have already finished a web app with a secure backend and hashed passwords and now I'm working on an Android version. I store all of the crucial data in an encrypted database using SQLCipher and use the user's password to encrypt it. And I'll try to show you where my problem is:

User logs onto the web app
User changes password
USer logs onto Android app
Now that the password has been changed, I have no way to decrypt my database because I no longer have access to the password which was used to encrypt it.

I don't want to store the user's password in plaintext anywhere and sending it from the server is also not an option. How do I solve this problem?

Would it work to have the user select a list of devices to update when they change the password on the website?

If so, the app could generate a key pair, and post the public key to the server once they have connected/authenticated (they only need to do this once/rarely).  When changing the password, you would encrypt the new password with the public key and store it somewhere for the Android app to check on next boot.  Nobody will be able to decrypt the new password apart from that particular device.

(If the Android device is compromised and the private keys are read, then presumably the same thing would happen to any rotated password.  Maybe this is why the user is changing their password, at which point "select devices to update" is an important step.)


Should an app remove or encrypt locally stored user data after a user logs out? I’ve been poking around in the Application Support folder of a popular app, trying to extract some chat logs. (By “popular”, I mean that most people reading this will have heard of it. I’m not sure if it’s a good idea to explicitly name them here.)

I was able to find my chat logs, but I also found data for somebody else (a friend who had once borrowed my device to send a few quick messages, but logged out afterwards). All of this data was stored in an unencrypted form, and it would be relatively trivial for me to extract what is potentially sensitive data.

I’ve begun writing a bug report to the developer in question, because this seems like a really bad thing to me. I can see the potential benefit: when a user logs back in, all of their data is waiting for them. But I think it’s a really bad thing to store this all in an unencrypted way, where somebody malicious could find it.

My question is this: am I being naive in thinking this? Is it actually a bad idea to store user data this way, or am I overly paranoid?

Anytime you use a computer of unknown provenance, you are at risk. It could have a hardware keylogger, a rootkit, or sketchy SSL certificates, etc. You really have no idea. It's best to do your sensitive work on machines you trust -- in this case I should think your friend trusts you.

You actually asked two questions though: should an app remove OR encrypt local user data?

Let's start with encryption. Yes, an application should encrypt data if it is considered sensitive enough. I personally doubt that chat logs are sensitive enough, but if a program is storing credit card numbers or SSNs, then it would be reckless and irresponsible not to encrypt that information. If you believe your chat logs are truly sensitive, then you are probably the type of person that should be using whole disk encryption (WDE).

Of course, when implementing encryption, you run the risk of muffing it up. If you do manage sensitive information, please use a well-known framework rather than writing that code yourself. For example, on OS X, you can use Keychain Services to store credit card numbers and social security numbers.

Now let's consider removal. One of the growing niches in security is privacy, and we're seeing more and more now that it's not acceptable to capture information about a user without that user's permission, especially if the information capture isn't obviously required to perform whatever tasks the application is supposed to do.

In client-server applications, there have been some obvious examples of failures in this regard, such as Path uploading all of your contacts. However, even storing user data on the client side can be a major privacy breach, as seen when Apple accidentally stored GPS tracking data on user's phones. Another example of this is malware that targets bitcoin files.

In the first two cases, the central issue seems to be the unexpected and indefensible collection of information that users did not expect them to be collecting. In Path's case, they should have never collected that data in the first place. In Apple's case, they have a valid use case for recording recent GPS data, but a bug resulted in those GPS logs not being truncated properly. Apple should have been more up-front about why iOS collects that data, and they should have tested that feature more to make sure it worked right.

The bitcoin example is slightly different: in that instance, the user clearly expects that data to be saved, but does not expect that his/her data can be stolen so easily. In this case, the application managing that data should have encrypted it. It was reckless to design digital currency management software and not build encryption into the design of it.

Your question is actually very insightful. As an industry, we're still not 100% sure what the answers are to some of these questions regarding privacy and security. I believe that over time we will see more and more attention placed on the issue of encrypting or removing data collected about users.


Stolen laptop simulation - Pentest One of the risks being simulated for organizations are stolen laptops.

Was wondering if anyone had a methodology/list of items to check when assessing the security of Windows laptops.

Here is my list so far:

Check that disk encryption (using TPM) is in use
Trying to steal credentials from locked machine by abusing USB permissions Bash Bunny (quickcreds)
Spoofing various services that Windows relies on in enterprise environments (Responder)
Port scanning for open/vulnerable services
Vuln scan for cases where running unpatched version of Windows

What are some other things that can be tried that can add value to the test?

While some of the things you bring up are going in the right direction ... bottom line with a stolen laptop is

Physical Access is Root access

While locking down a laptop will help, ultimately it is just buying you time.

New vulnerabilities will be found
Encryption will eventually be cracked
Users love weak, repeatedly used passwords (often on a sticky note stuck to the keyboard)

IMO, best thing to do with a laptop is to not keep any damn-ing information on it ... and instead use it to VPN into the company and keep all company files on company servers.  In this case, if a laptop gets stolen and you have a VPN with 2 Factor auth ... the account can be re-keyed before the attacker can do anything dangerous.

YMMV


Proxy between web server in DMZ and SOAP-service in internal network? I have a web server which is located in a DMZ, and exposed to the internet.

I also have an application server hosting a SOAP-service in the internal network.

I need to access the SOAP-service from the web server.

I know could open a port and allow direct https access from the web server to the SOAP-service, but I don't want to do that.

Does it make sense to add a proxy-server in the internal network, and allow the web server to access only the proxy, via https?

The proxy would then forward the requests to the SOAP-service.

Is that an improvement in security at all?

Web Proxy vs Port Forwarding:

Proxy is easier to hijack and reconfigure (it's an application) then kernel routing tables etc. Additionally web proxy will create more load then kernel TCP/IP stack. So proxy i worse from security and machine load point of view.

Architecture Problem:

Every configuration where you allow connections from DMZ to internal network is bad and should be avoided. The problem is in

  I need to access the SOAP-service (internal network) from the web server (DMZ).

It's not how DMZ should work. We create DMZ to separate outside world (internet) facing services from internal network, so when (because it really is WHEN, not IF) they got compromised, attacker can't move easily to exloit local network.

Suggested Solution:

You can create second, restricted DMZ for SOAP-service and cofigure port forwarding only for traffic comming from your web service in DMZ and internal network. This way SOAP-service is protected in the same way as when it's in internal network, but in addition, when compromised, you don't open internal network to attacker.


Is there something like the OWASP top 10 for BizTalk applications? I'm familiar with the OWASP top 10, for web applications. Is there something simular for BizTalk applications?

The OWASP Top 10 is not language specific; it is applicable for all web applications.  The CWE Top 25 is the most generally used list for non-web applications. That's probably what you're looking for.

If you want something language specific, it'd be most helpful to look for a biztalk security guidance or a BizTalk hardening guide and also to obey common practices like treating all user input as malicious.


How to rate a "Ethical Hacking and Penetration Testing" task? Lets say I hire a person for "Ethical Hacking and Penetration Testing". He will try break the security of my system/web site.

Lets say then the hired person is not successful in the invade the system.

Obviously, I'm not a security expert, so how I can tell if:

My system is very safe! The "security expert" cannot invade it!
The "security expert" is not good enough to invade it...

When you hire a security consultant / penetration tester to perform an evaluation of your security posture for a Security Best Practices assessment, you should be receiving a report at the end of the penetration test. This is a large part of the job. As well, there are automated scanners that you can use against your network or web application which will give you a higher-level overview on the overall posture of the network.

When you receive the report from the tester, it is generally going to contain an Executive Summary, which is meant to provide an overall debrief regarding the posture of your security without going too deep into technical details.

Often times, and for numerous vulnerabilities, the tester will be able to confirm the presence of the vulnerability though it may not be a vulnerability that allows for them to gain remote code execution. RCE (or "getting in") is only one part of a large array of vulnerability exploitation.