how to detect an encrypted virus a virus code (x bytes long) is XORed with a x bytes long word (we call this T). This word T is built repeating multiple times a 8 byte secret key.

the infected file contains this XORed (obfuscated) virus code, the 8 bytes secret key, and a loader. We don't know the location of those 3 entities inside the file.
The loader, when executed, uses the secret key to build T and extract the virus code.

If I have the original virus code (but not the loader nor the secret key), how do I determine if a file is infected?

You can't. You'll need to detect the loader, and either mark all files containing the loader as virus, or detect where T and the encrypted area is and decrypt the encrypted area to check whether the encrypted area contains the virus you are looking for.


Multi-byte character exploit I read this answer, It explains how a multi-byte character exploit works in a decent way, the only way I could think of avoiding this problem is whitelisting all single-byte characters because of the fact, as D.W. mentioned in the linked answer, that

there are also multi-byte sequences that the database might decode as a single quote, and that do not contain the 0x27 byte or any other suspicious byte value. As a result, standard quote-escaping functions may fail to escape those quotes.

Can anyone suggest some other way to tackle this problem?

Parameterized queries solve this problem as it separates the parsing of the query from the handling of user supplied data.


File signed with maliciously installed certificate on machine Let's assume we have a system delivering files (such as updating a program) that are digitally signed with a trusted CA. If an attacker somehow manages to install custom certificate as a trusted source on victim's machine, and then man-in-the-middle changes incoming files to other signed with this custom certificate, is there a way to prevent this? For example: can you check against only a pool of trusted-by-developer certificates?

Yes, this is called certificate pinning.  You would simply verify the signature against a particular public key rather than any trusted public key when doing the verification of the signature.

That said, if the attacker has already compromised the local machine and installed a root certificate, they are unlikely to need to mess with your update mechanism to compromise your software anyway since they are already performing trusted actions on the client.


SQL injection in Windows Services? I have many Windows services which run on the server side only. It performs few CRUD operations on a database (MySQL).

There is a client application which allows a user to upload files through it to the server. When the file gets uploaded to the server, Window Service performs required operations on this file and update the details in Database through SQL queries.

Client App(Desktop App) -> File -> Upload on Server -> Window Service Process File -> Database Entry

I was wondering if such kind of architecture really requires
parameterized query to prevent SQL injection?

Parameterized queries are a good idea in almost every case.

All it takes is one mistake in the service which processes the uploaded file and you could have SQL injection issues.

Security is about defense in depth, meaning you use several layers of security in case there's a hole in another part of your system.  I would recommend following best practices for SQL queries.  In the end it's not strictly required, but it would present an unnecessary risk considering how little effort it takes to parameterize queries.

It can also improve code readability by eliminating the constant opening, closing, and appending of strings where it's easy to miss quotes for a string type parameter.


Is there any point in having the HSTS header enabled when using HTTP/2? As a protection against attacks such as SSLstrip, the HSTS header prevents an attacker from downgrading a connection from HTTPS to HTTP, as long as the attributes of the header are properly configured.

However, HTTP/2, whilst not making encryption mandatory is implemented with mandatory TLS connection in modern browsers, according to wikipedia.

In that case, is there any point in having the HSTS header enabled when using HTTP/2? Can an attacker force the client to use HTTP/1 and in turn SSLstrip the connection? Is HTTP/2 enough, does it make the HSTS header obsolete?

Yes, HSTS is still needed, including HSTS preload.

The way a browser connects to HTTP/2 is through a URL that looks exactly the same as the URL for HTTP/1, so it doesn't know that it must be HTTP/2 just from looking at the URL. It will try plain cleartext HTTP if it is given a http:// URL. In order for the browser to not try plain HTTP (and not be subject to attacks from rogue WiFi AP, etc.), the URL must be https:// (and then HTTP/2 upgrade will happen through ALPN), and the way to ensure that regardless of what the user types in the address bar or an external links says, is using HSTS.


HTTP Authentication with bcrypt done right I have an android app that connects to a server through HTTP (notice the abscence of S, also android means Java, so nothing I'll hardcode in my app will be unreachable).

I want to store the password securely on my DB, so I wanted to use bcrypt (with password and salt)

My issue is the following : since I'm on HTTP, I don't want to send the plain password to my server.

Since I'm on mobile and 3G is very slow, I don't quite want to send the salt to the phone first so he can send the already hashed password to the server. (two queries instead of one)

Is there a way to make it work other than using the login + a fixed string as a salt ?

Thanks !

You want to use bcrypt for storage on the server side: that's good. You have to remember why you do that: it is because you fear that the server's storage area may be plundered in some way, and you want an extra layer of protection. The point of bcrypt (or any other similar password hashing function) is to make dictionary attacks more expensive: there is a salt (to prevent parallel attacks on many hashed passwords, and precomputations), and there are many iterations (to make each guess expensive).

You thus want to maximize the number of iterations. This implies that the hashing has to be done on a fast computer. A smartphone running Java code is not fast (a recent enough Android version includes a Java VM with a JIT compiler which will offer not-too-pathetic speed, but the result will still be uncompetitive with the server's abilities). Therefore, you really want the bcrypt to happen on the server side. Even if obtaining the salt from the server was acceptable (from a network latency point of view), the lack of CPU performance on the client side would be debilitating.

Therefore, your problem really is about how to transfer a very sensitive information (the password) from the smartphone to the server, making sure that it does not get intercepted while in transit. Since an app cannot contain secrets (because reverse engineering works, and that's not exclusive to Java), you will have to use asymmetric cryptography, with a public/private key pair, such that the server owns the private key, and the client can make sure that it uses the right public key (and not a fake attacker-controlled key). At that point, you are pretty close to SSL.

Using HTTPS would be the simplest method to achieve what you seek; in particular because the phone already includes all the needed code.

It might be argued that HTTPS implies too many network round-trips. It is conceptually feasible to do better when what you want is a one-way transmission of some secret data to the server; in that case, you can mimic the email model, which then points at OpenPGP. You could asymmetrically encrypt the password to send, using the known server's PGP public key (hardcoded in the app -- that's not a problem, it is a public key), and sending the result as a single HTTP request. This minimizes network traffic, while still relying on an encryption format which has survived some amount of external review. A Google search on "android openpgp library" yields a few useful pointers for the actual implementation.


Are popular browser extensions for anonymity as safe as Tor? There are many different browser extensions that people use in order to hide their IP addresses and protect their anonymity. Can the reliability of these proxy extensions be considered as being on the same level as that of Tor?

Tor works fairly slow, but it is relatively reliable service. Browser extensions allow more quick surfing. Due to the lightness and quickness during work with all these extensions I feel that it is probably not as safe as Tor and I should not consider it as a reliable service for anonymity. But I may be wrong.

No. They are different safe than TOR!
Anonymity is complex and there is no "X is better than Y" answer.

If the extension uses a simple unencrypted proxy, for example, everyone between you and the target server can read all your data. The proxy server provider knows your IP and can log everything you do.

If it is a encrypted VPN, between you and the VPN Provider, no one on that path, like your ISP, can read your data. The VPN provider can see all your data, log everything you do and knows your IP.

If you use TOR, the data is encrypted between you and the TOR exit node in multiple layers. The TOR exit node owner (some random person which you can't identify) can read all your data. She doesn't know your IP, but does know everything you send over the connection. There are some malicious exit nodes!

In all cases, everything you do over an unencrypted connection (not https) can be read by someone.


Can a website keylog you outside a virtual machine I came across a suspicious website called keylog.me (you can already tell from the name).
I was as curious as heck to find out what it does, so I got on a VM (Fedora Linux which I reinstalled later) and went to it but the VM crashed.
So then I went on it again with NoScript and there was a script embedded in an image (though, I couldn't see what it was because the first time the VM crashed and this time I had NoScript). Only after did I find out that keyloggers can be installed through webpage scripts (I was using firefox on the VM).
Also, I found out that a keylogger may be able to escape (and of course I had internet enabled) a VM. So now I'm concerned about my data, thinking that I'm being keylogged right now typing this question (and more sensitive data).
Currently, my OS is Ubuntu, but I have Windows 10 on a separate partition which as we all know is nothing in comparison to Linux systems in terms of security and I have sensitive data there too.
If there is a keylogger tracking me how can I get rid of it and can website keyloggers escape a VM?

TL,DR: Don't be worried, you are probably safe.
Usually malware cannot escape the VM onto the host OS. There are exceptions, as some malware are designed specifically to break from the VM into the host, but those are very, very few and usually are seen on targeted attacks, not on a public internet site.
Cross-OS malware infection are even rarer. Malware infecting your Ubuntu installation and jumping to Windows are plausible but mostly theoretical. A malware that escapes Firefox sandbox, infects the guest OS, escapes the VM, infects the host, discovers other OS installation and infects it too? No, I don't believe such thing would be available on a public facing site. It would be a weapon so powerful that nobody would admit to have it, even less go using it left and right.


Money stolen via Android malware Port 4000 remote anything exploit As background, my business bank account was compromised. The compromise also involved call forwarding of a smartphone. So they got bank credentials and cell phone credentials.

I initially suspected key-loggers on compromised laptops, compromised networking equipment at home or office, or social engineering. But it finally dawned on me that my Android phone was another possible source for the breach.

Last night, using an Android network scanner, I scanned my home network and saw that my Droid Turbo had two services running, one for Port 4000 and I believe the other was Port 4500. Port 4000 was "Remote Anything slave" and a quick Google let me know that this gives a hacker complete control of my device. Other Android phones in the family did not have these services running. I quickly shut the phone down and am going to buy a new phone this morning.

My assumption at this point is that the phone hack allowed them to get my cell phone company passcode that allowed them to forward bank activation codes; the bank and phone company confirm this happened.

I guess my question is whether every computer and phone on my networks (business and home) are now likely to have malware? From the phone, can the malware go to the router and then go put malware on other devices. Is there likely to be malware on the router? I'm trying to understand what needs to be replaced. I should add that I don't recall going to the bank website on my cell phone but it's possible. I don't have the bank app but I might have logged in on the train ride home to do something.

Any and all advice is appreciated. Surprisingly, the bank, the cell phone company and Google don't seem all that interested in investigating, so I guess I am on my own.

Stuff like this happens everyday.  It's not a surprise that any of the companies don't want to investigate.  It's too small of a scale and not in their best interest to do so.  Now as for your questions...

Network Devices: Home/consumer network devices are typical not kept as secure or firmware updates released as often for.  The best thing to do would be to check the manufacturer's website of your router/AP/switch to see if you're running the latest firmware.  A hard/factory reset of the device would be prudent.  While it's unlikely that the malware on the phone was able to infect your router in any way, it's not impossible.  Also, if your home router allows you to implement policies, consider blocking unnecessary outbound traffic.  This can deter malware applications from reaching their host if they are not using a default http/https port.
Other computers/phones: You should start by changing Administrator passwords on each device and running full AV scans.  If you use any cloud-based file sharing services (i.e.- Google Drive, Dropbox, etc.) you'll want to scan those as well.  Certainly try and target the services you used on  your infected phone first.  Any accounts that were tied to your phone should have their credentials changed, including username, if possible.  If you're not already doing so, make sure you're running a software firewall on each of your machines.
Gmail: I'm assuming that you have a Gmail account and that several of your services are tied to this account.  Consider using the Google Authenticator service that Google provides.  It requires a 6 digit PIN whenever you try and use your Google account for ANYTHING that isn't already approved.  Your email account generally is the apex for many other accounts.  Set a password on it that is different from all other accounts (which you should always do anyways) and implement the maximum security your provider allows.
Additional Security Moving Forward: For credit cards and bank accounts, setup email/text notifications to notify you when charges are made or when new devices are used to access your accounts.  Most banks offer this.  Also, be very careful about the applications you install on your phone.  It's possible the the infection came from an application that was installed by you to begin with.


how to identify whether my page is phished or normal page? Usually I differentiate phished page and normal web pages by seeing https before the address of the web page, as the lock symbol will help us to identify.

Are there any other methods to differentiate phished login pages and normal web page?

Doing a test login with fake credentials I think is the best way. You could examine the Net using debuggers as FireBug (mozilla plugin) or Chrome debugger to look where the information is being sent, or if you are being redirected to other web etc.

Also you should pay attention to the domain, thisisalongdomain.com and thisisalongdoman.com might seem equal, but if you look carefully you will notice the difference.

Other way is searching it on google (or other search engine). Usually the real website would appear before, (but this is not 100% secure). Or you might even find that that phising web have been reported.

Usually checking the https is a good option, but if a trusted CA gets compromised, bear in mind that you could end up in a https web that is not the real web.

Edit: For users with not enough IT knowledge, I recommend not to trust links on unsafe environments, like an email from an unknown sender, a chatroom or a forum since most phising attacks rely on those mechanisms to succeed. I will be surprised if a phising website gets to the firsts possitions of a search engine...

Apart from paying attention to visible (at first sigh) things as the url, as I said before, or the httpS as vignesh said, there is little more they could do by theirown if they fall in a phising website.

I think they should totally use antivirus, nowadays they tend to warn you if a website is a phising website (at least Norton and McAfee do), this could safe lives, but of course, with new phising websites, I guess they will not warn you.


Use mining to prevent DDOS attacks on websocket: Is this a viable solution? I'm thinking whether the following way is a good way to completely and totally prevent ddos on my server. My idea is to use the same mechanism of cryptocurrency mining (bitcoin, with sha256 or any other hash) to prevent DDOS.

Note: I'm not suggesting to mine cryptocurrency per se. I'm suggesting to use the same mechanism to avoid Sybil attacks.

Why does idea look appealing to me? Because creating a mined hash is expensive, but verifying it is super-cheap. it costs only calculating a hash once.

What does mining mean, in a nutshell? It means that there's a specific chunk of data (say a session id, or a JWT token, that can be stored in the server in a performant NoSQL server), and the user (or the miner in cryptocurrency) has to create a hash that matches certain criteria. For example, if we use SHA256, we can define the difficulty as the required number of the leading zeros in the 256-bit resulting number from the hash. More zeros make the probability of finding that hash more difficult.

How does it work?: A user would take the session token (which is created by the server), and combine it with a nonce (number used once), and calculate the hash in their frontend (through WASM, or otherwise with javascript). Since the user cannot reverse-engineer SHA256, all he can do is keep changing the nonce again, and again and again, until he finds a nonce that creates a hash that satisfies the required difficulty.

The graph shows the probability of finding a block (finding the correct nonce) in Bitcoin, where the difficulty is chosen to make it 10 minutes. Changing the difficulty will shift this curve and change its width proportionally.

How long does it take the server to verify? Practically zero. Just calculate the hash once and ensure that it matches the given difficulty, and that authorizes the user to make any anonymous request. Notice that none of this requires authentication with usernames and password. This is all anonymous. Authenticated users don't need to do this as their credentials can be banned from the system. This is all for anonymous users (and possibly attackers).

The result: The user will have to calculate this hash with this difficulty before making any request to the server. Once the user succeeds, the mined authentication token can be stored in a cookie to be reused by the user. If the user fails to provide the requested hash, his connection request will be abruptly reject, and thus preventing a DDOS attack with sock-puppets.

ASIC resistance: Using SHA256 is not recommended because there's specialized hardware that can calculate it very fast, leading to a possible coordinated attack. There are hashes that are hard to print on hardware, such as Scrypt and Argon2.

Choosing the difficulty: The difficulty can be static (which I wouldn't recommend), or can be dynamic to change with the load on the network. When a high network load exists, the required difficulty is increased. This basically will act as a filter and protect the network during DDOS attack times, and never affect the users, as users normally wouldn't care to wait 10 seconds to create a session. In case of really high load, the users can either choose to compute the expensive nonce, or come back later. The hosting company also can decide whether an expansion of the infrastructure is required based on the difficulty chart over time.

Is this a sound plan to protect against DDOS on websocket and similar public protocols? I would like to implement this on my server.

EDIT: Just to be clear, this is not a silver bullet to all kinds of DDOS. But this prevents the users from manipulating the internal functionality of the server + makes it difficult to use the server functionality to exhaust bandwidth. I would be interested in knowing why this may or may not work, more than a summary on whether this is new or old.

TL;DR: This is not a solution against typical DDOS. It might be a protection against some very application specific DOS.

Taking away all the mining stuff your idea essentially means that the client connects to a server to get some hard to solve task and later comes back to present the easy to verify solution for this task.

The problem with this approach is that the clients needs to connect to the server first and that the server needs to be able to reply with a task to the client. This means your idea cannot protect against the most common bandwidth oriented DDOS attacks which simply send more traffic then upstream systems or the server can deal with. Neither will it help against simple DDOS attacks which try to exhaust resources of the server itself, i.e. things like SYN flooding or Slowloris.

It can actually help against attacks which are targeted at later stages of the processing, i.e. attacks specific to the application.  But it isn't actually a new idea in this area, it is essentially just another Proof of Work System as they are known for many years.


Security Implications of Neglecting the Extra Byte for NULL Termination in C/C++ Arrays Please Consider: English is my second language.

On the Security Now! podcast episode 518 (HORNET: A Fix for TOR?), at the 27:51 mark Steve Gibson quotes an example of vulnerable code in C/C++:

  "[...] one of them [problems with vulnerable code] is creating a new array
  of a certain size [...]. And the fix is 'of a certain size + 1'. So,
  [...] it [the vulnerable code] was just one byte too short. Probably a
  NULL terminator, so that when you fill the array with size objects,
  you would have one extra byte of NULL that would guarantee NULL
  termination, and that would prevent that string from being overrun. But
  that's not what the coder did: they'd forgotten the '+ 1' [...]"

I understand what he means: when you create an array, you need to allow one extra byte for the NULL termination byte. What I would like to achieve with this post is to get a pointer for further research into the impact of having an array whose last byte is not the byte terminator; I don't understand the full implications of such negligence, and how this could lead to an exploit. When he says that having the NULL termination

  "would prevent that string from being overrun",

my question is "how is it overrun in cases where the NULL termination character is neglected?".

I understand that this is a huge topic and therefore do not to impose on the community too comprehensive of an answer.  But if anyone could be kind enough to provide some pointers for further reading, I would be very appreciative and happy to go and do the research myself.

String Termination Vulnerability

Upon thinking about this more, using strncpy() is probably the most common way (that I can think of) that could create null termination errors.  Since generally people think of the length of the buffer as not including \0.  So you'll see something like the following:
strncpy(a, "0123456789abcdef", sizeof(a));
Assuming that a is initialized with char a[16] the a string will not be null terminated.  So why is this an issue?  Well in memory you now have something like:
30 31 32 33 34 35 36 37 38 39 61 62 63 64 65 66
e0 f3 3f 5a 9f 1c ff 94 49 8a 9e f5 3a 5b 64 8e

Without a null terminator standard string functions won't know the length of the buffer.  For example, strlen(a) will continue to count until it reaches a 0x00 byte.  When is that, who knows?  But whenever it finds it it will return a length much larger than your buffer; lets say 78.  Lets look at an example:
int main(int argc, char **argv) {
    char a[16];

    strncpy(a, "0123456789abcdef", sizeof(a));

    ... lots of code passes, functions are called...
    ... we finally come back to array a ...

    do_something_with_a(a);
}

void do_something_with_a(char *a) {
    int a_len = 0;
    char new_array[16];

    // Don't know what the length of the 'a' string is, but it's a string so lets use strlen()!
    a_len = strlen(a);

    // Gonna munge the 'a' string, so lets copy it first into new_array
    strncpy(new_array, a, a_len);
}

You've now just written 78 bytes to a variable that only has 16 bytes allocated to it.
Buffer Overflows

A buffer overflow occurs when more data is written to a buffer than is allocated for that buffer.  This is no different for a string except that many of the string.h functions rely on this null byte to signal the end of a string.  As we saw above.
In the example we wrote 78 bytes to a buffer that is only allocated for 16.  Not only that, but it's a local variable.  Which means that the buffer has been allocated on the stack.  Now those last 66 bytes that were written, they just overwrote 66 bytes of the stack.
If you write enough data past the end of that buffer you'll overwrite the other local variable a_len (also not good if you use it later), any stack frame pointer that was saved on the stack, and then the return address of the function.  Now you have really gone and screwed things up.  Because now the return address is something completely wrong.  When the end of do_something_with_a() is reached, bad things happen.
Now we can add a further to the example above.
void do_something_with_a(char *a, char *new_a) {
    int a_len = 0;
    char new_array[16];

    // Don't know what the length of the 'a' string is, but it's a string so
    // lets use strlen()!
    a_len = strlen(a);

    //
    // By the way, copying anything based on a length that's not what you
    // initialized the array with is horrible horrible coding.  But it's
    // just an example.
    //
    // Gonna munge the 'a' string, so lets copy it first into new_array
    strncpy(new_array, a, a_len);

    // 'a_len' was on the stack, that we just blew away by writing 66 extra
    // bytes to the 'new_array' buffer.  So now the first 4 bytes after 16
    // has now been written into a_len.  This can still be interpreted as
    // a signed int.  So if you use the example memory, a_len is now 0xe0f33f5a
    //
    // ... did some more munging ...
    //
    // Now I want to return the new munged string in the *new_a variable
    strncpy(new_a, new_array, a_len);

    // Everything burns

}

I think my comments pretty much explain everything.  But at the end you've now written a huge amount of data into an array most likely thinking that you're only writing 16 bytes.  Depending on how this vulnerability manifests itself this could lead to exploitation via remote code execution.
This is a very contrived example of poor coding, but you can see how things can escalate quickly if you're not careful when working with memory, and copying data.  Most of the time the vulnerability will not be this obvious.  With large programs you have so much going on that the vulnerability might not be easy to spot, and could be triggered by code multiple function calls away.
For more on how buffer overflows work.
And before anyone mentions it, I ignored endianess when referencing the memory for the sake of simplicity

Further Reading
Full Description of the Vulnerability
Common Weakness Enumeration (CWE) entry
Secure Coding Strings Presentation (PDF automatically downloads)
University of Pittsburgh - Secure Coding C/C++: String Vulnerabilities (PDF)


CT logs for non browser applications Most what I read on CT logs is about browsers checking the logs for websites.
But what about normal applications or updates for operating systems (like apt-get over https, windows/osx updates  ...)
Is checking CT logs mandatory for those too?
Is it up to the program developer to implement this?

Is it up to the program developer to implement this?

that's correct, it is up to developer to include CT log support in non-browser applications. CT Logs are required by CA/Browser Forum and this covers only web browsers.


VPN IP address leak while establishing connection Even if I have a VPN configured to auto-connect in Linux, there is a brief moment where it is connected to the Internet, but not utilizing the VPN. Doesn't this provide a vulnerability? How can I protect myself?

Depending on your vpn software that's normal behaviour.

Configure a firewall that only allows connections to your vpn provider over the public network and force everything else to go over the vpn.

For instance:

iptables -P OUTPUT REJECT
iptables -A OUTPUT -d <VPN_SERVER> -j ACCEPT
iptables -A OUTPUT -s <VPN_ADDRESS> -d <VPN_NET> -j ACCEPT

Where VPN_SERVER is your VPN provider's public address, VPN_ADDRESS is your address on the tunnel interface and  VPN_NET is the VPN network in CIDR notation.

You can also do this with routes instead. When you setup your internet interface, instead of loading a default gateway you load a static route to your vpn server. No host other than your local neighbors and your vpn server will be reachable until you get a default route from the vpn provider (through the vpn).

Both approaches get the job done, but the firewall approach includes an insurance policy for free.


use namespace and cgroups or seccomp to implement online judge? I'm writting a online judge(support C/C++、GoLang). I want to implement a sandbox by myself. my idea:

namespace and cgroups

compile user's source code statically
run executable file in a complete new namespace (CLONE_NEWUSER,CLONE_NEWNET,CLONE_NEWPID,CLONE_NEWIPC,CLONE_NEWUTS,CLONE_NEWNS)
use PivotRoot to set a new root(nothing in root except executable file)
use cgroups to control resource(memory/cpu/pid)
set timeout(use time.AfterFunc of GoLang)
because resource limit and complete new namespace, I will not filter any system call

seccomp

use seccomp to filter bad system call
set timeout and limit memory

the online judge is write for my school. there are not sensitive data on where my sandbox running.

which one is better or safer? or any other good idea?

Comparison between namespace/cgroup with seccomp is not a good idea. These are intended for different purpose as you explained. Basically you should apply a combination of these, that is

Filter all critical system calls with seccomp
Isolate you service from accessing other process resource using namespace
Limit the resource usage (cpu, memory, core etc) using cgroup


Are there any downsides to using Let's Encrypt for a website's SSL certificates? On the advantages side, I see several benefits to using the Let's Encrypt service (e.g., the service is free, easy to setup, and easy to maintain). I'm wondering what, if any, are the disadvantages to using Let's Encrypt? Any reasons why website operators -- whether big like Twitter or small like a local photographer -- should not consider replacing their existing SSL services with companies like GoDaddy with this service?

(If the service is not yet available, this disadvantage can be ignored -- I'm more wondering about disadvantages once it is available for general public use.)

Let's Encrypt is a Certificate Authority, and they have more or less the same privileges and power of any other existing (and larger) certificate authority in the market.

As of today, the main objective downside of using a Let's Encrypt certificate is compatibility. This is an issue that any new CA faces when approaching the market.

In order for a certificate to be trusted, it must be signed by a certificate that belongs to a trusted CA. In order to be trusted, a CA must have the signing certificate bundled in the browser/OS. A CA that enters the market today, assuming they are approved to the root certificate program of each browser/OS from day 0 (which is impossible), will be included in the current releases of the various browser/OS. However, they won't be able to be included in older (and already released) versions.

In other words, if a CA Foo joins the root program on Day 0 when the Google Chrome version is 48 and Max OSX is 10.7, the Foo CA will not be included (and trusted) in any version of Chrome prior to 48 or Mac OSX prior to 10.7. You can't retroactively trust a CA.

To limit the compatibility issue, Let's Encrypt got their root certificate cross-signed by another older CA (IdenTrust). This means a client that doesn't include LE root certificate can still fallback to IdenTrust and the certificate will be trusted... in an ideal world. In fact, it looks like there are various cases where this is not currently happening (Java, Windows XP, iTunes and other environments). Therefore, that's the major downside of using a Let's Encrypt certificate: a reduced compatibility compared to other older competitors.

Besides compatibility, other possible downsides are essentially related to the issuance policy of Let's Encrypt and their business decisions. Like any other service, they may not offer some features you need.

Here's some notable differences of Let's Encrypt compared to other CAs (I also wrote an article about them):

LE doesn't currently issue wildcard certificates (they will begin issuing wildcard certificates on Jan 2018) LE is now issuing wildcard certificates using the updated ACMEv2 protocol
LE certificates have an expiration of 90 days
LE only issues domain- or DNS-validated certificates (they don't plan to issue OV or EV, hence they only validate ownership and not the entity requesting the certificate)
Current very-restrictive rate limiting † (they will continue to relax the limit while getting closer to the end of the beta)

The points above are not necessarily downsides. However, they are business decisions that may not meet your specific requirements, and in that case they will represent downsides compared to other alternatives.

† the main rate limit is 20 certs per registered domain per week. However this does not restrict the number of renewals you can issue each week.


How can Bitwarden claim it cannot access your passwords if the vault password is the same as the web account password? Bitwarden claims that it is more secure than traditional cloud password managers (such as Google) as it only stores the encrypted version of the passwords database. But for some reason the password you use to authenticate on their website is the same as the vault password - meaning that the company could potentially decrypt your entire vault when you login or simply store the password in plaintext to be able to decrypt anyone's vault at any time.
I've tried looking into their settings and I don't see a way to enable separate passwords for the vault and for the Web UI. Am I missing something or is Bitwarden actually extremely unsecure, presuming you don't trust the owners of their backend?

The user password is pre-hashed with a slow password hashing function on the client side, twice, using different algorithms and/or salts. One hash is used to generate a login token (used like a password) which is sent to the server (where it gets additional hashing, and possibly also requires stuff like MFA). The other one is used as a "password-derived key" that is the first step to obtaining the master key for decrypting the database.
Typically the master key is stored on the server, alongside the user's data, in encrypted form. This encrypted master key, along with the encrypted data, is transmitted to the user upon successful authentication. A simple implementation is to encrypt the master key with the password-derived key; this encrypted master key can only be decrypted on the client (the server never sees the password-derived key). More advanced schemes involving public key cryptography are sometimes used to enable sharing select data with other users, without giving them access to your master key or any data you didn't want to share. The password-derived key is not itself used to encrypt/decrypt the data, because then if the user changed their password it would be necessary to re-encrypt everything. Instead, changing a password just requires decrypting the master key with the old password-derived key, and re-encrypting it with the new one.


What information is collected because of signing into Windows 10 with a Microsoft account? The question is specifically as stated - "because of signing into Windows 10 with a Microsoft account". Not including what is collected even when using a local account. And not including what is collected by using apps that are available only to Microsoft accounts.

In other words, what privacy is lost by switching from using a local account to using a Microsoft account, when continuing to use the same programs that have been used before the switch?

This question bothers a lot of our customers. There are three major effects switching from a local-only account to a Microsoft account:

Identification

Microsoft will be able to identify the users from within different applications, websites and services. Even if they are using other hardware after a successful login (e.g. mobile phones or your friends computer).

This identification might lead to a advanced profiling which may cause highly personalized ads. The same effect can be observed on other OS ecosystems with advanced cloud technologies like Apple iOS and Google Android.

Synchronisation

Microsoft is using Windows 10, Office 2016 and other products of the current line-up to push their cloud services. In case of Windows 10 this includes synchronization of settings between devices (e.g. theme, browser settings).

This might also include passwords (browser, WiFi) which would increase the risk of breaches. However, Microsoft is using transport encryption and I assume they are also using some kind of encryption for the stored data. This would limit the risk of an incident. But still: Your sensitive data is leaving your local storage which increases the attack surface.

The same goes for OneDrive which is used to sync files between devices (like Dropbox). You are able to define OneDrive as your main storage which causes additional security-related and in some cases even legal-related implications. Under some circumstances and in some sectors this might not be allowed. This is one of the problems Swiss financial institutes are facing with Windows 10.

Linked Services

Some features and services require a Microsoft login to be used. This might include the Windows Apps Store and Cortana. Using these services might introduce additional risks of profiling (Personal Ads), data leakage (Cortana phones home) and further exploit vectors. But this is nothing new and also part of every other OS and online service. I don't have good example (yet?) where an exploitation of Windows 10 was only possible because of a Microsoft login.


Is Whonix 100% Anonymous? I have imported and run Whonix - Anonymous Operating System appliance in my VirtualBox. I am seriously excited about anonymity that given by this OS. How can I trust and verify the anonymous state of this OS?

No, but it helps a lot.

Your usage habits themselves, what time you use a computer, common sites you visit, even the speed at which you type certain phrases, and the phrases you use all help to paint a digital fingerprint which can be used to identify you as a user.

This may not happen in real-time as some correlation is involved but if you frequent a site like Stack Exchange and always create new accounts at a certain time, post a three sentence question to security, then view tor.stackexchange.com, bricks.stackexchange.com, and then finally blender.stackexchange.com in a fairly repeatable pattern. An organization may be able to correlate your current activity with your past activity before you were using Whonix or even when you did the same pattern from your cell phone on vacation. These human patterns are not really as anonymous as you would think.

Similar things happen to different types of users. For an attacker, they may always do a specific type of recon first or check for new exploits before working. A journalist may read a news website or two before communicating with a whistle-blower. Basically, the things you do, even with Whonix and Tor eventually reveal some things about you. So no it's not perfect anonymity.

This said, the more you know about this tool the better you will be at using it. If you are just looking to avoid your local ISP from recording your traffic this will probably work great.


Security risks posed by user generated filenames on a webserver Do filenames themselves pose a security risk?

We have a webserver, users can upload files to the server.  The files are temporarily stored on the server, then moved to S3.  The filenames are recorded into our MySQL database and eventually included in the HTML & CSS that our webserver produces.  The filenames themselves are never changed from what the user uploads.

In terms of security, is there any vulnerability that can be exploited with a mere filename?  Should we be changing the filenames of uploaded content, or is it safe to simply store the filenames as they are?

Yes, all user controlled input poses a potential security risk and should never be trusted.

But, if the file name is a threat to your application depends on how you process the file and the file name internally. I would suggest to sanitize the file name when the user executes the file upload.

For test cases, best practices and prevention methods see the Unrestricted File Upload page at OWASP.


Static Key Ciphers and key persistence A vulnerability report states the following:

  The server is configured to support ciphers known as static key ciphers. These ciphers don't support "Forward Secrecy". In the new specification for HTTP/2, these ciphers have been blacklisted.

From what I could find, the lack of forward secrecy is due to the fact that multiple sessions use the same key.

My question is: How/where are the keys persisted and for how long? Can this compromise sessions which will happen in a relatively far future, say half a year from now?

From what I could find, the lack of forward secrecy is due to the fact that multiple sessions use the same key.

This is not about using the same key inside multiple sessions.

All ciphers using the RSA key exchange lack Forward Secrecy since an attacker could passively sniff the traffic and later decrypt the sniffed traffic if the attacker gets access to the servers private key. This is not possible with ciphers using Diffie-Hellmann (DHE, ECDHE), i.e. these ciphers provide Forward Secrecy.

Or as written at Wikipedia:

  A public-key system has the property of forward secrecy if it generates one random secret key per session to complete a key agreement, without using a deterministic algorithm.

With RSA key exchange there is a deterministic algorithm based on the servers private key, with DH there is no such determinism.

  How/where are the keys persisted and for how long?

Forward Secrecy (or lack of) is not about the persistence of the keys but about the ability to recreate the keys in a deterministic way, in case of RSA key exchange based on the private key of the certificate.

  Can this compromise sessions which will happen in a relatively far future, say half a year from now?

This is about a "compromise" of a session but that the encryption keys can be recreated if the session was sniffed and later the private key gets known. This can be years after the session got sniffed.


Is it possible to redirect someone to a fake site without changing the hosts file? Is it possible to redirect someone to a fake site without changing the hosts file?  When I access a bank site, I receive a fake page. But my hosts file does not have any changes to do this. Is it possible?

There are lots of ways besides editing the hosts file:

Your web browser got hijacked by some malware to request a different domain than you entered.
Your router got hacked. Remotely exploitable vulnerabilities in consumer-grade routers are not unheard of. Or you are using a public network which isn't trustworthy.
Your DNS server might be compromised. You can verify this by using a different DNS server like 8.8.8.8 (Google DNS server)
When you are using a proxy server, VPN or some anonymizer like TOR, that service might redirect you. When you are using such a service, try accessing the website directly. Check the network settings of your browser if there is any proxy server.

And these are just some which come to mind at first though.


Preventing deauthentication attacks I am helpless against some kiddy with backtrack who repeatedly uses aireplay-ng to deauthenticate legitimate users on my Wifi work network.

I captured and analyzed the network traffic on my Wifi work network, and I noticed a remarkable amount of 802.11 deauth packets. I realize it may not be possible to catch him, or even know where the attack came from.  I just want to know: Is there any way to prevent such an attack?

Realistically, you cannot stop a bad guy from sending deauthentication packets.

Instead, you should focus on ensuring you are resilient to a deauth attack.  Make sure your network is configured in a way that the deauth attack doesn't enable an attacker to compromise your network.

To do that, you need to make sure you are using WPA2.  If you are using a pre-shared key (a passphrase), make sure the passphrase is very long and strong.  If it is not already, change it immediately!  If you are not using WPA2, fix that immediately!

The primary reason why bad guys send deauth packets is that this helps them execute a dictionary attack against your passphrase.  If a bad guy captures a copy of the initial handshake, they can try out various guesses at your passphrase and test whether they are correct.  Sending a deauth packet forces the targeted device to disconnect and reconnect, allowing an eavesdropper to capture a copy of the initial handshake.  Therefore, standard practice of many attackers who might try to attack your wireless network is to send deauth packets.  If you are seeing many deauth packets, that is a sign that someone may be trying to attack your wireless network and guess your passphrase.

Once the attacker has sent a deauth packet and intercepted the initial handshake, there are tools and online services that automate the task of trying to recover the passphrase, by guessing many possibilities.  (See, e.g., CloudCracker for a representative example.)

The defense against this kind of attack is to ensure your passphrase is so long and strong that it cannot possibly be guessed.  If it's not already long and strong, you need to change it right away, because someone is probably trying to guess it as we speak.

(The other reason a bad guy might send deauth packets is as an annoyance.  However, as most users probably won't even notice, it's not a very effective annoyance.)

To learn more, see these resources:

How does deauthing work in aireplay-ng?
Can someone get my WPA2 password with honeypots?


What is the web of trust? I'm studying network and system security and I came across the phrase "web of trust". From Wikipedia:

  In cryptography, a web of trust is a concept used in PGP, GnuPG, and
  other OpenPGP-compatible systems to establish the authenticity of the
  binding between a public key and its owner. Its decentralized trust
  model is an alternative to the centralized trust model of a public key
  infrastructure (PKI), which relies exclusively on a certificate
  authority (or a hierarchy of such). As with computer networks, there
  are many independent webs of trust, and any user (through their
  identity certificate) can be a part of, and a link between, multiple
  webs.

I want a clearer definition and some example if possible.

A hierarchical public key infrastructure is when some Certification Authority (CA) issues certificates to a lot of sub-entities: the CA signs certificates to guarantee the link between an identity and the public key owned by that entity. The PKI is hierarchical in that there are few CA and each CA signs certificates for a lot of people.

In a Web of Trust, everybody is a CA. Every user signs certificates for whoever he wants.

In mathematical languages, a hierarchical PKI naturally implies an acyclic certification graph, usually a tree: trust percolates down the tree from a single root CA, or a small set of root CA. Whereas the WoT is a super-connected generic graph with cycles and many paths between any two points.

Politically, the hierarchical PKI is a military-inspired structure, with a central chain of command; while the WoT is an anarchist hippy utopia in which trust emerges semi-magically from the assembled people (or the mob, from another point of view).


How DHCP client can determine that 802.1x Port based authentication has been completed and its time to trigger DHCP discover I have a Supplicant running on 1 Linux box attached with a Free radius server on other linux box with cisco catalyst switch (with 802.1x Port based access) in between. Now I have been able to successfully complete the authentication and want to create a separate DHCP thread/application to initiate the "DHCP Discover " to get an IP Address.

How will this DHCP client determine that port based access has now been enabled and DHCP messages can be transmitted now? Is there some standard way or do I need to make my application do this some other way?

This can be done in two ways. 1st, if the DHCP client is in application control that has responsibility to perform authentication then DHCP DISCOVER can be sent once authentication has been completed and client knows that data access has been allowed.

If a DHCP client is out of application control i.e. Linux self DHCP client then DHCP manages it internally. When client transmits the DHCP discover message and switch doesn't replies client will keep retrying the message and the switch can use this message to trigger authentication.


Mobile apps and apps store security This question is with regards to mobile apps and apps stores.

Is it possible to program a mobile app that looks like a legitimate app, say for a bank, with the aim that people will download and use it, and key in their user id and password.

This 'fake' mobile app will then capture their password and send this info back to their own servers.

Is this possible ?

Well, the app is certainly possible. If the app was created for good by a bank, it can be recreated for evil. Especially if the evil app doesn't actually need to handle banking transactions. It could just scoop the credentials and crash.

I think the other half of this question is "Are people dumb enough to fall for this?" Absolutely. Stupid is a renewable resource. Not everyone will fall for this (app distributors wouldn't ever publish it) but some will have that killer combination of ignorance and hubris and get their bank credentials stolen.


How does a country block/censor an encrypted website (HTTPS)? Given that Site X uses HTTPS, how can it be blocked by a country?

My browser reads: 128-bit encryption | ECDHE_RSA as key exchange.

I say it's blocked since when I use Tor, it works fine.

One important thing to point out is that it's not blocked in the typical sense we are used to see, which clearly shows a page that says it's blocked, instead, site X is blocked in a way that my browser just doesn't load the page and displays the error:

  This webpage is not available, Error code: ERR_CONNECTION_RESET

for the HTTPS version, and that regular "page is blocked" page when requesting the HTTP version.

Note that no other HTTPS sites are blocked! Just this one! I assume this is evidence that excludes port blocking and protocol blocking. However, it leaves DPI; but there are other HTTP-blocked websites which have the HTTPS version still working! If they can DPI-block site X, why can't they block the other HTTPS sites the same way?

TL;DR: TLS only secures the content of a message. Not the metadata.

When communicating over the clear net, it's important to remember that there are some portions of a given communication that cannot be secured using standard technologies. Unless you use something like TOR, your ISP will be able to determine who you're talking to even if you're using TLS.

To use an analogy, imagine sending an envelope via the postal service. The contents of the envelope are completely inaccessible to anyone other than the recipient. Even if a postman were to somehow view the contents, they wouldn't be able to comprehend it (Perhaps you ran it through a Caesar cipher first? Hehe).

However, in order to have the postal service send it to the correct address, the outside of the envelope must be marked with a plainly readable representation of the destination address. If the postal service didn't want anyone to be able to send letters to "Joe Schmoe, 123 Fake street," then they could just not deliver any letters with that address.

Since the postal service can't read the contents of the message, they have no way to identify the intent of the letter. The only information that they have is the fact that the intended recipient is Joe Schmoe. They can't screen only the letters that they deem to be malicious; it's all or nothing.

Similarly, the IP protocol (the routing protocol that TCP runs on top of) has plainly marked "sender" and "receiver" fields. TLS cannot encrypt this for two reasons:

TLS runs on top of TCP/IP, and thus cannot modify parts of the packets that belong to those protocols.
If the IP section was encrypted, then the carrier service (ISP routers) would not be able to identify where the packets need to go to.

The firewall that your ISP or country is forcing all of your traffic through cannot inspect TLS traffic. They only know the metadata supplied by the TCP/IP protocol. They have also deemed that the site you want to access is more bad than good, so they drop all of the traffic to and from the site regardless of the contents.

There is a method to secure even the metadata of online communications, but it is slow and not very scalable. TOR hidden services are one attempt at implementing this. Of course, hidden services only work within the TOR network, which can only be accessed by first connecting to a machine over the clear net. This means that the ISP or firewall still knows that you're proxying your data through the onion. No matter how you try, you will always leak some metadata. If they wanted to, they could reset all connections to TOR nodes in addition to the site they're currently blocking.

If you are trying to establish a direct connection to a specific IP through a firewall, and the firewall has explicit rules to kill any traffic to or from that given IP, then connecting to that IP directly will always be fruitless. You will have to connect to it indirectly, either through TOR, a VPN, or some other proxy service.


Why is the OS obfuscation defense against "It's a Unix system!" not widely implemented? The Jurassic Park scene referenced in the title is infamous for how ludicrous it sounds to those who are tech literate.  But it also illustrates what seems to me to be a glaringly huge hole in web security, particularly IoT devices--as soon as attackers find out a server or camera or baby monitor is running linux, they instantly know volumes about how it works.  They know that commands like sudo are big juicy targets and they know that shell access will bring with it gobs of useful tools like ls and cat.

So why isn't OS obfuscation more of a thing?  I'm not talking about just hiding the version in web headers.  Similar to JavaScript minification or obfuscation, I'm talking about changing the names of binaries and filepaths in the OS itself. Wouldn't entire classes of attacks be practically useless if the OS had ha7TrUO and RRI6e29 commands instead of sudo and ls?  Imagine a hacker that somehow gained remote root access--what are they even going to do if they don't know any commands?

Implementation would be fairly easy for compilers.  Take the simplest case of "rename this function and all calls to it." You could give an OS compiler and an application compiler the same randomized names and they'd be able to talk to each other. But even if the application has poor security and is vulnerable to bash injection, such attacks would be fruitless.

Obviously this technique can't be used in all scenarios.  Setting aside scenarios like servers maintained by human sysadmins, it seems to me that any device or server managed by automation is a prime candidate for this defense.

I guess the question(s) needs to be a bit more concrete:

Is OS obfuscation as described used widely and I just haven't encountered it?
If not used widely, what are the practical or technical barriers to usage?

Before I tear your idea apart, let me say that it's a really interesting idea and it was super fun to think about.
Please continue to think outside the box and ask interesting questions!
Alright, let's do this!

Let's take a step back and ask why that baby monitor is running Linux in the first place? What if there was no operating system and the application was written in bare microcontroller code (think arduino code)? Then there would be no sudo or ls or even a shell for the attacker to use, right?
I'm not an expert here, but I expect that we, as an industry, have gravitated towards putting Linux on anything big enough to run it largely for developer convenience:

Reducing dev time: When building your WiFi-and-bluetooth-capable web-administered cloud-syncing self-patching whizpopper with companion Android and iOS apps, Linux comes with all the libraries, utilities, and drivers you need to do that.
Increasing testability: If the device is running bash or busybox with an SSH port, then it's super easy to connect in and figure out what went wrong during your product testing phase.

For your obfuscation idea to work, you'd need to obfuscate not only the names of command-line utilities like sudo and ls, but also every Linux kernel API to prevent the attacker from dropping in their own compiled binary that calls the kernel directly. So let's take another look at your idea:

Implementation would be fairly easy for compilers. Take the simplest case of "rename this function and all calls to it." You could give an OS compiler and an application compiler the same randomized names and they'd be able to talk to each other.

You'll need to do this randomized compilation yourself; otherwise someone could look up the mappings on google.
So, you'll need to build the kernel from source with your "obfuscating compiler" so that only you know the mappings of the obfuscated kernel APIs. (ever built the linux kernel from source? It's certainly more of a chore than docker pull alpine, which is the direction that dev culture seems to be going).
But an operating system is more than just the kernel. You want drivers for the Broadcom BCM2837 wifi chip that comes on that mini-pc device? You'll need to build that driver against your obfuscated kernel with your compiler, if Broadcom will even give you the source code. Then you'll need to build the entire GNU wifi and networking software stacks. How many other things will you need to find source for and add to your build pipeline before you have a functioning OS?
Oh, and if the upstream repos of any of those things issues a patch, you're now responsible for re-building it (assuming you saved the compiler obfuscation mapping files that match your kernel binary) and pushing it out to your devices because - by design - your devices can not use patch binaries produced by the vendor.
Oh, and in order to foil hackers, there'll be none of this "Here's the binary files for Whizpopper 1.4.7", oh no, you'll need to build a uniquely obfuscated version of everything from the kernel up per device that you ship.

So to your questions:

Is OS obfuscation as described used widely and I just haven't encountered it?
If not used widely, what are the practical or technical barriers to usage?

I think the answer is that what you're describing pretty much completely defeats the purpose of using pre-existing software components if you need to find and build literally everything from source. It might actually be less effort to ditch the operating system entirely, pretend it's 1960, and write your application directly in CPU microcode.
I like security more than most developers, but like f* that.


Risky Connection Blocked by McAfee McAfee has been blocking a connection from a certain IP address (I found the IP Adress to be from Hong Kong). Should I be concerned? McAfee says the program is "SYSTEM". Also if I should be concerned what could I do about it?

If the connection is originating from your computer, you should investigate why

Determining which process is attempting the connection

There are several tools in the [Sysinternals Suite] that can help you understand what program is making the connection. The TCPView program may show you the attempted connection, but as I understand it, it is basically just a GUI on netstat, so you might miss the connection.

The process monitor (ProcMon) tool will capture many different kinds of events concerning network connections, the file system and the registry (and much more). This page has details about how to use ProcMon to trace network connections to the responsible process.

Additionally, you can use the new sysmon tool. This page has some details on how to setup and use sysmon.

Once you determine the process that is sending the connection, you can use Process Explorer to submit the program to Virus Total. Virus Total will scan the sample across a few dozen AV products. A non-finding of a malicious signature doesn't necessarily mean it is benign, but its a good start. Launch procexp.exe as Administrator, locate the process via it's PID and right click to select "Check VirusTotal".

Determining what the process is trying to send

Using a program like wireshark, you may be able to determine what the program is trying to send. If McAfee is blocking the connection then, then nothing may be sent because connection is blocked. However, if you can determine what DNS entry is being used (if one is being used at all), then you can edit your hosts file to your local host. You can then set up a temporary webserver, (I like using python's python -m SimpleHTTPServer 80) to allow the connection to be established.

Follow Traditional Malware Investigatory Practices

If you can't track down the network connection, follow traditional approaches to determining if your computer is infected with malware. This post has many areas to investigate. Further, you can use tools like volatility to investigate your computers memory. Volatility can be especially helpful if a rootkit has been utilized to hide processes.


Meterpreter Session died [Bwapp] I just set up a lab with bwapp and wanted to jump straight into webshell.
I used Unrestricted file upload vuln --> uploaded my perfect shell created with msfvenom.
My only problem is that my session doesn't seem persistent as I'm getting Meterpreter session opened and then died.
For more context, bwapp is on a bridged network vbox and my kali is also bridged.
php/meterpreter_reverse_tcp etc etc.
Any ideas...
I need persistence (RCE)

I Found the issue here.
I was using msfvenom payload @ php/meterpreter_reverse_tcp but my handler was php/meterpreter/reverse_tcp when I changed it to match (php/meterpreter_reverse_tcp) exactly then my session was established.


What techniques and tools do you use to relate security events? You have central logging going, detailed app logging/alerting (e.g. modsec), network based security alerting (e.g. snort), and whatever else feeding your observation deck.

Do you have any cool techniques you’d like to share for how you relate security events?

How about tools?  (in-house is fine, just describe what it does)

Enterprise tools which correlate related security and logs events are generally called Security Information and Event Management (SIEM) systems. Most are designed to accept data from common log formats, IDS alerts, antivirus, firewall rule changes etc.

LogRhythm
http://www.logrhythm.com
Used by many companies around the world.
IBM QRadar
http://www-03.ibm.com/software/products/en/qradar-siem
Cisco MARS
http://www.cisco.com/c/en/us/products/security/security-monitoring-analysis-response-system/index.html
Intel McAfee NitroSecurity
http://www.mcafee.com/
ArcSight(purchased by HP)
http://www.arcsight.com/
Very expensive. It's a beast to setup, a beast to use, but the correlation engine is really impressive. A few years ago when I used it, it was able to correlate multi-stage attacks (ie trojan on host a, allows host b to be reachable to external ip, and also know host b firewall rule allows snort attack seen on IDS c to occur.
Looking at arcsight express (and asking my vendor for the price), it may be a nice fit for smaller shops (under 500 hosts) but it needs to be backed up by people able to interpret and analyze alerts.

Other tools that I know about:

OSSIM, The Open Source SIEM
http://sourceforge.net/projects/os-sim/
One of my interns has played around with this, with generally favorable reviews. For a project, or a small shop, this is probably your best bet.
Intellitactics (aparrently now owned by trustwave)  http://www.intellitactics.com/int/
They were another big player when SEIM first started, they were unique in that they were using a text database (as opposed to Oracle like ArcSight and the rest). I heard they were going to stop using a text db and move to something else, but never heard anything from then in a long while.
RSA enVision
http://www.rsa.com/node.aspx?id=3170
This was regarded as a pile of crap, talking to the new product manager of the team at defcon, they were re-banging the product, using business intelligence tools and techniques (column store databases, etc). What I was told was EMC (the parent company of RSA) bought Greenplum (a ZFS based BI system) for this project. I would be watching them closely, and maybe get under an NDA and get the real story.

I'm using older information here, would love to hear whats correct and whats not.


Why store the password salt instead of generating it? So, reading through this article: http://crackstation.net/hashing-security.htm it says that storing the salt is fine in plain text because it renders the lookup/rainbow tables ineffective. I get that, but why not generate the salt from the submitted password and then never store that separately either?

Something like this:

<?php
$pass = '12345';
$salt = '';
// generate the salt somehow... probably not like this
$hash1 = hash('md2',$pass);
$hash2 = hash('md4',$pass);
for($i = 0; $i < strlen($hash1); $i += 2){
  $salt .= $hash1{$i} | $hash2{$i};
}
// hash the results
$hashedPass = hash('bcrypt', $salt . $pass);

If the salt is a function of the password, then two exact passwords will produce the same hash.

For an arbitrary hashing function H() and an arbitrary salt generation S(Password), then

H("Password_1", S("Password_1")) = H("Password_1", S("Password_1"))

While if you use a random salt generation function RS() then

H("Password_1", RS()) != H("Password_1", RS())

As an attacker, nothing can make you happier than seeing two (or more) hashes used in two (or more) different accounts. This means at least one of two things

The password is weak (because two different users chose the same password), then the attacker could concentrate his computational cracking powers on those hashes.
The attacker can attack two (or more) accounts using the same computational effort only once.


What happens if multiple Strict-Transport-Security headers are set in the HTTP response? If multiple Strict-Transport-Security headers are set with different settings (e.g. different max-age values), how will the browser behave? Does the browser just follow one of them, or simply error out and discard all? Is this behaviour different across various browsers?

According to RFC 6797, 8.1, the browser must only process the first header:

If a UA receives more than one STS header field in an HTTP
response message over secure transport, then the UA MUST process
only the first such header field.


Malware ad.adsmatte infection My PC is infected with malware, whenever I open a webpage and click on it a new tab opens on "ad.adsmatte.com". I scanned my PC with Malwarebytes but was unable to resolve the problem. So I reinstalled my Windows with factory settings but still "ad.adsmatte" keeps coming. I don't know what to do. Is my router infected? I checked the DNS service but it was set to obtain IP address automatically.

Please help, I have been stuck with this problem for 2 days and also have tried Google search and followed the instructions mentioned on various websites.

I'm using Google Chrome as Browser and Windows 7 as OS.

Edits: If my router is infected how come my android device which uses same router to access internet runs fine?

I had ads and redirects via ads.matte.com on many devices on the network including android phones, PC's and IPads. I found out that going through a VPN service fixed the problem completely but didn't want to run a VPN service on all devices.

The solution for me was similar to some other contributors but very simple to do. All devices used DHCP from the main router. I checked the DNS settings within the Internet settings (not DNS within DHCP settings, this should be the same address as your main router gatweway address, commonly 192.168.0.1 etc.), and usually the Internet DNS servers would be provided by your ISP or you may be using google 8.8.8.8 or another DNS service.

In my case I didn't recognise the DNS server number so I looked it up and it turns out to be some Eastern Block country with the website friendhosting.net using IP 185.82.216.99 . I changed the DNS server to google 8.8.8.8 and cleared the cache and cookies from the browser in my PC and the problem was fixed. I cleared the cache and cookies an a couple more devices and this immediately fixed the problem on these devices too.

On one device I deliberately didn't clear the cache to see what happens and I went straight back to rubbish served by adsmatte.com . I then cleared the cache and cookies on this device and the problem was fixed immediately. The same fix was applied for the remaining devices and the network is back to normal.

One point to note - I logged onto a different network whilst having this problem and the problem remained, which made be think the problems was mainly due to a hijacked browser. I think what happened here was that the cache and/or cookies were still causing the problem and had I thought to clear them once connected to this other network then the problem would have probably been fixed too, providing their router had not been hijacked too.

So how did the router address get changed? The problem network is another family members so I've no idea what they may have done or downloaded but it's fixed for them now. As a bit of added protection I changed the DNS to OpenDNS (208.67.222.222 and 208.67.220.220) and it works really well.


Shutdown if case opened Assume the user has a full disk encrypted HDD in which their OS and files reside. They also have made attaching USB or any other device without first allowing it cause an automatic shutdown which subsequently wipes the RAM clean (the same way Tails OS does).

The adversary in this case decides to go for a hardware attack, specifically opening the computer/laptop case and removing the RAM to then dump the contents before searching for the password.

What would be the easiest (free) way to cause an automatic shutdown if the case is opened while the computer is turned on?

I also know basic OpSec is to never leave your machine unattended. Lots of other things could happen, user could even melt the screws to make opening the case extremely difficult... but this is not the question! Please focus on this one issue.

Be nice and play ball with this question. Yes it is a "tinfoil hat" question, but this kind of stuff is interesting for some of us :-). Thank you!

I've seen this done on old Compaq servers. The side panel had a pin that fit inside the power switch. When the panel was opened, the pin came with it, shutting off power. In fact, the system would not even power on without that side panel (more specifically, the pin) in place.

It was quite a surprise when I was called in to service a server off-hours and I was unfamiliar with this mechanism. I was hoping to diagnose a problem without any server downtime, but I was foiled.

Short description:
PC Mag article


Why might malware make a DNS request for an epoch time converter? I am analyzing malware and I see that two executables when run in a sandbox made DNS requests for www.epochconverter.com

Why would an attacker risk detection by making a network request to epochconverter.com? What is it necessary for?

Let me put it like this,

Nowadays malware are often connected to a CNC ( Command and Conquer ) Domain, they often communicate with this domain to inform the hacker that the malware is now active and is pending for future commands to execute, this is part of the sophisticated approaches that is being used today.

The malware enters your environment.
Calls the CNC to make aware of his activation.
The CNC replies with more commands to execute.
Often the malware would use DNS Ex filtration to encrypt the data gathered and sending it to the CNC for decryption and is the hardest thing to catch without the correct tools.

The domain you have mentioned would look offline, however could be a dns server that would relocate any data posted from the pc to an XML storage space.

if the website is not accessible through a browser or through a ping test .. it could be accepting requests only from signed calls.


What are the risks of connecting to my company network from outside? What are the risks of using an Android phone as a modem to connect my netbook to my company network from outside the office?
Is it better to use a cable to connect them both or bluetooth?
I've read that using VPN is good enough to protect my data, is that right?

A few points immediately come to mind:

If you're using a vpn, the medium over which you send traffic is of reduced importance. The whole point of a vpn is to create a virtual distributed private network which uses an untrusted network to transmit traffic. As long as the vpn is properly configured (aggressive mode disabled, strong encryption etc) then it is of questionable importance how you gain access to the wider internet.
If you are using an IPsec VPN then the security features are implemented within the IP layer of the network protocol stack. This means that all layers under this (data link, physical etc) benefit. Therefore if your connection to your bluetooth device occurs at a lower protocol layer, even if it is compromised, an attacker will not gain access to the higher layer (transport, application etc) data.
Regardless of the potential to break the security of your vpn connection, bluetooth is widely considered to be vulnerable to a number of attacks. I'd be suprised if you found a security professional that made anything more than the absolute minimum use of bluetooth for any purposes. If you have a usb cable handy, you may as well use it!


Why is the BCrypt text "OrpheanBeholderScryDoubt" I'm looking for a reference about the weird initial BCrypt text "OrpheanBeholderScryDoubt"

Why was this string used?
Would using 192 zeros or ones not have worked well in practice for some reason?
Was that just four random dictionary words (orphean, beholder, scry, doubt), or is there some special meaning to the bcrypt authors, maybe some kind of cryptography joke that flew over my head?

The google results have so many hits where the magic string is mentioned, in pseudocode or description of the implementation, that I am unable to find relevant historical explanations (if any exist).

OrpheanBeholderScryDoubt
This isn't authoritative, since I couldn't find a reference, but I found the commit where the string was introduced dated 1997/02/16.
The earlier version used the string OpenBSDbcrypthashfunc, since it was designed to be used with OpenBSD (it is the default on OpenBSD). The new string keeps the same initials OpenBSD (OrpheanBeholderScryDoubt`) as a nod to its origins.
So all things point to it just being a 24 character string with a nod to OpenBSD.


Can you directly view a malicious PDF on Linux? There have been questions on safe viewing of malicious PDFs on OS. I would like to know if it's okay to directly open them to view them in a Linux OS because the OS is said to be secure and malware-proof most of the times. I am working on a project to detect malicious PDFs. Should I work only on a VM or not open the file at all but work only on the source code?

To say Linux is malware-proof most of the times is incorrect, it's just that much malware focuses on other OS'es (but there is nothing preventing an attacker from targeting more than one OS). Avoid opening the PDF on your box unless you are absolutely sure the malware wasn't written for and won't execute in Linux.

If you are trying to perform analysis then use a sandbox, such as Cuckoo. With that said, some malware is sandbox aware and will try to avoid detection/analysis.


Apart from the lack of native Outlook support, why should one prefer S/MIME over PGP/MIME for email? From my (still quite subjective) point of view, GnuPG/PGP is superior to SSL (or more specifically, PGP/MIME over S/MIME; maybe in other areas SSL is the better choice), e.g. due to the support of subkeys to separate signing and encryption certificates and the Web of Trust instead of having to blindly trust a CA - including the ability to revoke certificates without a CRL or OCSP.

But in contrast to S/MIME, PGP (MIME or not) requires some additional user effort, and seamless integration (such as Enigmail in Thunderbird) in Outlook ≥ 2010 (unfortunately widely used in the business world) requires a plugin (the only usable one I found is the Outlook privacy plugin, which does currently only support plain-text PGP).

But apart from this usability issue, is there a sensible reason to prefer S/MIME over PGP/MIME?

The main reason to prefer one technology over the other is usability. Regardless of the tools you use, email security will depend mostly on how well the users cooperate -- most of the confidentiality of their emails rests on their ability not to do anything stupid with their data, and to react appropriately in unusual conditions. You will get decent security only if the tools they use are available, easy to use and reliable. Therefore, it is difficult to compare S/MIME and OpenPGP in abstracto.

However, we can still make some distinctions on the PKI model. S/MIME relies on X.509, a behemoth of a standard which is meant to support a hierarchical PKI with controlled trust delegation from a limited set of trust anchors and down short paths. OpenPGP uses a Web of Trust which is decentralized. Your expression "blindly trust a CA" says a lot on your own preferences, but is quite subjective.

If you look at how X.509 and OpenPGP operate, you will see that in the Web of Trust, everybody is a CA; hence, while in X.509 you put your trust into a handful of CA, in the Web of Trust you put your trust in... everybody ? That's because most people forget half of the WoT system. In a true WoT, the graph of certification (i.e. who signs the key of who) should be overconnected.

When you want to validate the public key of someone (let's call him Bob), then you need to find certification paths which lead from you to Bob; such a path begins by your public key (which you know "absolutely") and each step is a signature computed over the public key of the next individual in the path. Security in the WoT model comes from the verification of many paths which all begin by you and end on Bob, but with no other individual being common to any two paths. When everybody can act as a CA, any single path is "potentially suspect": when people sign other people's keys late at night and under the auspices of heavy alcohol drinking, you cannot expect all paths to be 100% reliable. An attacker intent on forging a fake key for Bob will just have to find a few gullible or intoxicated individuals. The WoT credo is that "the crowd is right": an attacker may subvert some people, but not most of them. Thus, if you can find many valid paths which lead to Bob, then Bob's key is probably genuine, because bribing or deceiving that many people would have been "probably too hard".

Bottom-line is that the Web of Trust is hard. The description above uses the fuzzy terms "few", "many", "most" and "probably". We do not know how to estimate the number of paths which must be built in order to achieve a given level of security; in fact, we do not know how to quantify a "security level". It is unclear whether WoT can work at all. OpenPGP implementations tend to use a "reliability percentage" which is a totally unsubstantiated guesswork. Of course, in practice, nobody spends time to rebuild many chains; you are already lucky if you find one chain.

When I must exchange confidential data with customers, I use OpenPGP -- but not the Web of Trust. I use OpenPGP because the usual implementations have the ability to bind keys to indentity permanently: if I can make sure once that the key is genuine, then my software will remember it and things will be safe thereafter. So the customer and I exchange the key fingerprints when we meet in person, or over a phone call (which we assume to be safe from impersonations -- eavesdropping is not an issue here).

Such binding is not supported by S/MIME implementations. They could do it (although certificate expiry makes it slightly more difficult) but they do not. It is not intrinsic to X.509 (the X.509 model makes it possible to change your certificate every five minutes, but it does not make it mandatory); but deployed implementations work that way. Usability trumps the PKI model, as I said above, so that's OpenPGP for me.

(Note: in another context, HTTPS relies on the X.509 hierarchical PKI with a few dozens of hardcoded trust anchors, and the same issues arise there too; e.g., see Convergence, which is a proposal to, indeed, bind keys to servers in a semi-permanent way, and which relies on the same "crowd is right" mantra as the WoT. And yet they do that with X.509 certificates, which shows that the actual format for certificates is not that important.)


From how far away can passive RFID tags be read? I have been told in the past that with specialized equipment, passive RFID tags could be read at 1100 feet. This seemed a bit far fetched to me, and sure enough, a quick Google search turned up something closer to 20 or 30 feet. That being said, I know that some of the people who told me this are MUCH smarter (and much better at this) than I am, and the people on the sites I was reading obviously weren't TRYING to get as high a range as possible. Without using something ridiculous like a flatbed truck and some satellite dishes, is it possible (and/or plausible) to read an RFID badge from that far away? If not, how far?

At least 217 feet.

Please keep in mind this is an Ultra High Frequency UHF Gen 2 RFID tag meant for use in item sales, tracking, and inventory.  This is not the same RF technology in use by access cards. Those are generally Low Frequency (LF) and have a much longer wavelength, which results in a shorter demonstrated distance of 12-19 inches, although that is much farther than the distance claimed by the access card vendors in the interests of system security.  Most door badge readers are designed to require a distance of less than two inches.

Near Field Communications (NFC), found in credit cards, cell phones, and other payment systems, use High Frequency (HF) which falls in-between the two, and they will have a range somewhere between the two.  They have an intended operating range of only a few inches, but with an antenna and receiver designed to read them, they may have a much longer eavesdropping range, probably in the 10 foot range.  I don't know of specific experiments in distance eavesdropping on credit cards from long ranges; most such attacks have been demonstrated by disguising the reader in a backpack and reading victims' cards through their wallet on a bus or train.

Also, you should not discount specific antenna or receiver technology.  If there is value to be had in scanning an RFID tag from across a parking lot (surveillance of a person, that sort of thing) then you can be assured that someone will find a way to abuse it to obtain that value illicitly.  They may hide the antenna in a canvas-sided truck to commit their surveillance.


How does the PIN work in the RSA SecurID phone app? I use the RSA SecurID phone app to connect to the VPN at my work. I run the app and type a 4 to 8 digit PIN. Then the app gives me a 6 digit code to connect to the VPN. Does the PIN change the result? What if I type the wrong PIN?

The phone app has an algorithm to generate a new 6 digit random number every 60 seconds. Your PIN is simply added to that number without carry.  If you want to see the random number, just enter nothing for the PIN (or all zeros).
For example if the random number is 334455 and your PIN is 781923, then the resulting code will be 015378.
because
3 + 7 = 0  (throw away the carry)
3 + 8 = 1  (throw away the carry)
4 + 1 = 5
4 + 9 = 3  (throw away the carry)
5 + 2 = 7
5 + 3 = 8

I don't see how this information would be ever useful, but it seemed interesting.


Ransomware in virtual machines. Running Locky for testing security measures We have several binaries of the ransomware Locky. We tried to run it in a virtual machine, which has several storages like Samba, etc. attached, in order to see how the files are going to be encrypted.

Basically it starts, spawns its process and then quits for no apparent reason. Nothing happens.

What could cause such a behaviour?

Many instances of modern malware are VM-aware to make exactly such examinations more difficult. The malware will attempt to detect if it is running inside a VM as one of its first functions and then simply terminate if that is the case. This will be done prior to the remainder of the payload being decrypted in order to expose as little as possible to forensics examiners.

I don't know about Locky in particular, but it would not be surprising in the least if Locky's authors were using this very common tactic.

See here for a good overview of this phenomenon:
https://blog.malwarebytes.org/intelligence/2014/02/a-look-at-malware-with-virtual-machine-detection/


How SSL/TLS identify a legitimate user? My question is what happen if an attacker takes an encrypted packet from the network and send it on his/her behalf to the server. How server will identify that it is not a legitimate user. In HTTP using cookies we get the identity of a user otherwise, HTTP is stateless protocol, Now how does HTTPS makes it stateful?

You mentioned that the attacker is "taking an encrypted packet from the network". The packet is encrypted, so the attacker can't read it or modify it. If the attacker could read it or modify it, he must know the key (or have broken the encryption, but that is very unlikely for modern cipher suites). HTTPS does not protect against an attacker who knows the key. Knowledge of the key is the identification of the legitimate user.


Why is the password field blanked in the registration form if the validation fail? Is it really a problem if you send back the password when the validation fail on a registration form?

I understand that the html that is sent back could be cached on the computer of the person registering and then if a malicious person later access that computer he could see the password that user entered by looking into his cached files.

BUT... Aren't you already screwed when someone get physical access to your computer? If he can look at the cached files of your browser chances are that he could install any program he wants on the machine. Also, many people store their password directly in their browser without a master password. If he has access to the computer he could just check all the passwords that the user saved.

EDIT : This is a similar question : https://ux.stackexchange.com/questions/20418/when-form-submission-fails-password-field-gets-blanked-why-is-that-the-case

If you're ever able to "send back" the password, through any channel, then you're not handling passwords correctly. Period.

If the password can be retained in the form via client-side caching, that's perfectly fine. Arguably still riskier than not, but certainly much safer than: (a.) sending the password over the wire (in any form) more times than necessary, and (b.) giving the server more access and time with the plaintext password than necessary.

Once a server receives a password, it should be put through whatever hashing process is required for comparison against (or insertion to) the database and then the plaintext should be immediately discarded. There's very few - close to zero - cases where any additional server-side handling of the plaintext is appropriate, and all of them increase its risk of compromise (even if only by increasing the time it's retained by the server).


Can Netsparker detect a CVE in an open source library packaged in a WebPack bundle? In a recent Netsparker scan, a CVE against an open source JavaScript library was reported (as expected). I'm trying to understand exactly how Netsparker determines:
 1. Which JS library is being used, and
 2. Which version of the JS library is being used

My guess is that it is parsing the version info from the comments in the header. However, if a JS library is combined with others using WebPack to create a bundle, can Netsparker determine that multiple libraries are being used and detect CVEs for all of them?

I looked on the Netsparker site, but couldn't find enough information. I'm asking this because I don't have a copy of Netsparker that I can arbitrarily run.

There are a few of ways to do the check:

Parse the version information.
Hash the JS file and check it against a known list of software versions.
Build a database of pattern checks that identify software and its version.

Option 3 would detect old JS embedded inside a combined file.

I don't know which of these Netsparker actually uses, but you could ask them at the helpdesk.


Found my iPhone 6 somewhat open (possibly right after airport security), what (if anything) might have been done to it? I was traveling by air very recently, and once I got home I noticed that the button on my iPhone 6 seemed to be more deeply recessed. After a while I realized that this did not make any sense mechanically, so I removed the Rhinoshield phone protector and discovered that the front of my phone was slightly pulled out!!

How this happened I do not know, but the timing seems to be related to my last trip through airport security; Hong Kong. However the phone is old and was opened several years ago for a screen repair, so I supposed it might have somehow spontaneously popped open.

I don't know if it was surreptitiously opened or not, but if so, why might this happen, and what if anything might have been done to it?

The poor quality photos are from my laptop. I have turned off the power of the phone right now for safety reasons.

I thought about deleting the question, but leaving an answer in this case might serve as a good example. In a comment above it was pointed out that a failing iPhone battery can sometimes swell and cause problems like this.

This is in fact the case that my battery is failing. I never thought to connect an electrical phenomenon with an opened phone, but batteries can be clever this way.

So by far the simplest explanation is that my known-to-be-failing battery swelled and popped the display out, and the timing is pure coincidence.

The level heads at stackexchange have once-again prevailed.

Here's what the battery looks like after I had it replaced:


Are passwords for Windows accounts always stored in cleartext in memory, while the account is logged on? Are passwords for Windows accounts always stored in cleartext in memory, while the account is logged on?

Using Mimikatz I've seen lots of examples where passwords are stored in memory, either for domain/local accounts or service accounts.

Therefore I want to know, if passwords for logged on Windows accounts are always stored in memory, or if there is an exception to that rule?

Is it enough for Windows to only store NT hashes (local accounts) and MsCacheV2 hashes (domain accounts)?

Not always; as usual there are a few measures to take that provide a defence in depth against Mimikatz.

In Win 2012 R2, you can (and should) utilise the new group in the 2012R2 schema called 'Protected Users', described in this TechNet article: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn466518(v=ws.11)

You already practice the principle of least privilege, another, more general defence.

If you have older Windows machines in your domain, install KB2871997 which should backport the 'Protected Users' group into Windows versions still under support.

Finally, and this might be the most effective and easiest to push out via GP, there is a registry setting that you may set to prevent passwords being stored in plain text in RAM:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest, Key Value 'UseLogonCredential' and set to '0'.


How does the DNS-spoofer know the original destination of the packet? It's perhaps my lack of deeper knowledge of how the DNS, NAT or TCP works, but I have been thinking about the following scenario and can't figure out the following problem which arises in DNS-spoofing MITM attack:

Imagine a MITM attack, which is carried out using DNS spoofing. A victim tries to connect to server A (www.example.com), but since it uses a rogue primary DNS, it gives him a false IP address of other server B. Now since the victim thinks it has the correct IP address it starts some communication with B. The attacker wants just intercept the traffic and forward it to it's proper destination, so he doesn't raise the victim's suspicion. How does the attacker know the original destination?

In case the communication is HTTP, then this is easy since every request carries its URL. But what happens in more general case of just some ordinary TCP packet (non-HTTP). Since TCP header now contains the attacker's server B IP address, how does the attacker know the original destination of this packet?

My particular thought is that the attacker spoofs 2 or more domain names pointing to servers running services at the same port numbers.

HTTP protocol

For HTTP this could be generalized to

  How does webserver hosting more websites knows which one to host?

This is through technique called Virtual Hosting in which browser appends Host header to every request send and webserver serves the content of the wanted site, deciding via the header. So if I host foo.com and bar.com on the same server and want to visit my foo site, browser will append (determining by URL address in the browser) "Host: foo.com" header.

More info on Wikipedia

Other protocols

Here you have a problem - you do not know. Either you can just capture DNS request (which is also very useful) and send it to it's original destination or you can spoof the destination, but then you need to have some listener on the given port waiting for a specific trafic. This could be used to steal authentication credentials or something like that, but it's very targeted attack.

Otherwise it's very protocol specific.
Maybe the application layer protocol supports something similar to Host header as HTTP.

Lets presume you know the foo.com is also listening on port 21 (FTP protocol). If you knew this, you can spoof the DNS to redirect to your server where your FTP server is listening and steal his credentials.

If you don't have a server listening - by spoofing his traffic, all you can do is DoS him, as your rogue DNS is pointing him to places which don't exist.

Hope this answers your question correctly.¨

M