wget: what security issues am I not considering? Questions: based on the details provided below, (a) what potential security vulnerabilities and threats might I face in my use of wget and (b) what recommendations would you give for mitigating those vulnerabilities and threats?

Goals: as per a recommendation by @forest, these are my security goals:

successfully complete potentially lengthy wget jobs, such as mirroring a website or recursively downloading a large number of files from a website.
avoid attracting the attention of target website admin, others.
be untraceable to my actual IP.
avoid leaving traces that would enable a web admin or whomever to detect that different jobs are executed by the same person (me). For example, I might mirror a website roughly once a month, but with some variation; I would be displeased if despite my efforts to change headers and coming out of a different Tor exit node, it was clear to the other side that it was the same person. This one is less important than general traceability.
don't make myself vulnerable to exploits that a malicious actor without a high level of technical skill could pull off.

Background: I work in due diligence and am new to thinking about digital security. I often evaluate content from the websites of sketchy companies. To streamline, I use wget and try to do so in a secure and non-alerting manner. I take the following precautions:

initial evaluation of website's probable traffic level
only use wget through torsocks
provide randomly selected HTTP headers for each job
random wait between 0 and 600 seconds
all links converted to local references
cron scheduling varies with each ~weekly execution
jobs executed by RasPi modified for additional security
disconnect RasPi from network when evaluating content

Thank you.

There are several questions in here. You are asking how to avoid detection, how to avoid attribution, and how to avoid exploitation. Though you did elaborate on your goals, I still don't know your specific threat model. I can guess a few likely possibilities, and my answer is based on the best understanding I have on what you want to accomplish. I will edit my answer in response to question updates.
Your goals

avoid attracting the attention of target website admin, others.

Whether or not this occurs depends on how the target website is configured. Various spiders can be fingerprinted, so even if they are using a common user agent, they are still displaying some behavior unique to them. For example, the order in which client HTTP headers are sent, and even their case. There is no way to prevent a website administrator from knowing that you are using wget rather than a regular web browser if they are determined to do so or have software designed for such detection. Your techniques are probably sufficient to avoid tripping over a typical IDS, though.

be untraceable to my actual IP.

Since you said you were using torsocks, I think I should add some information on how it works. The way torsocks provides a Tor connection is by using LD_PRELOAD to hook network-related functions. When these functions are called, the function from the torsocks library is instead executed, and it redirects the connections to a SOCKS5 proxy. This is useful for applications which do not support the SOCKS protocol, but it can easily be bypassed, either accidentally or maliciously. If an application uses raw assembly to invoke a syscall directly, it will bypass torsocks. As the latest version of wget uses libc networking functions rather than invoking syscalls directly, this should not be a problem for it. Hypothetically, though, a compromised wget could easily bypass torsocks. The solution is to run it under a user where all non-Tor traffic is denied. This is possible by running a system instance of Tor under its own user (which is usually the default), and using iptables to block all outgoing connections from UIDs other than that of the Tor process.
I assume you are also aware of traffic analysis attacks which affect Tor and any other low-latency anonymity network. Judging by your goals, this is probably not an issue as a very large AS-level adversary is required to pull this off with any accuracy.

avoid leaving traces that would enable a web admin or whomever to detect that different jobs are executed by the same person (me). For example, I might mirror a website roughly once a month, but with some variation; I would be displeased if despite my efforts to change headers and coming out of a different Tor exit node, it was clear to the other side that it was the same person. This one is less important than general traceability.

Chances are, anyone who looks at the logs will be able to tell it is the same person. The chances that anyone else is using Tor and changing headers (which is not natural behavior) and is doing this roughly once a month and having the fingerprint of a spider is extremely low. While this does not allow the target to know who you are, they may still be able to tell that the activity is coming from the same person. Quite honestly, using regular old wget with no changes (or perhaps the bare necessary ones required to avoid triggering flood detection and such) may be better. People and bots use wget all the time, even with Tor, which means that randomizing your headers will make it such that you won't even be able to blend in with the (already few) people who are using wget and Tor on that site.

don't make myself vulnerable to exploits that a malicious actor without a high level of technical skill could pull off.

There have been multiple instances of remote exploits against wget in the past. This has ranged from fairly sophisticated, like buffer overflows, to much simpler, like providing a 301 redirect to an FTP link that overwrites a local file. You can either run as an unprivileged, isolated user to mitigate this, or use mandatory access controls like AppArmor to confine it to accessing only certain directories.
Your precautions
Some comments on a few of your precautions:

provide randomly selected HTTP headers for each job

HTTP headers are interpreted regardless of their order or their case. Because of this, each utility using the protocol may use a different order of headers or different cases, not just different headers. For example, curl gives the user agent header before the host header, whereas wget does it the other way around. Even when using identical header settings, they can still be distinguished.
For wget:
GET / HTTP/1.1
User-Agent: Wget/1.19.1 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: example.com

For curl:
GET / HTTP/1.1
Host: example.com
User-Agent: curl/7.57.0
Accept: */*

For Firefox:
GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1

So what happens if you set wget to use a Firefox user agent? Some IDSes can be configured specifically to detect discrepancies between the reported user agent and the behavior of any given connection. A discrepancy may allow the IDS to know what software is actually being used, or it might just alert it to the fact that the client is intentionally lying about who they are, resulting in the IDS loudly alerting the sysadmin. Take the following wget command, downloading a single page from a website while spoofing the user agent:
wget -U "Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0" "http://example.com/secretpage.html"

You would think that that would be indistinguishable from a Firefox user connecting directly to example.com/secretpage.html, right? An IDS would be able to quickly notice that it is really wget and not Firefox, because it would see the following being sent from the client:
GET /secretpage.html HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: */*
Accept-Encoding: identity
Host: example.com

Now compare this with the earlier example of Firefox headers. This is clearly not genuine Firefox, despite the user agent claiming it is. This is far more likely to raise an IDS alert than simply retaining the original wget user agent (after all, command line tools being used to retrieve webpages usually isn't a big deal to sysadmins).
Additionally, the patterns in which an application accesses resources can be used to determine the identity of the application. Wget has very unique behavior when used as a web spider in the order and speed it accesses resources, as well as which resources it ignores. Curl does not support being a spider so has no behavior. Firefox has some very complex behaviors involving the order in which resources are loaded and whether or not a given resource is pinged or preloaded. As you can see, it will generally always be possible to know that you are using wget if any in-depth analysis is done, and because most wget users are not changing their headers, this makes you unique.

random wait between 0 and 600 seconds

This should only be done if necessary to bypass automatic detection or to avoid flooding the website. While it is random, an administrator looking at the logs will still see that each connection is is waiting between 0 and 600 seconds. This itself is unique. It should not be done to try to act less "spider-like".
Making an automated spider behave as a genuine internet user is exceptionally hard. Many research papers have been written about it, and many research papers have been written showing how to detect it. Given that spammers are heavily invested in their bots behaving like humans, and anti-spam solutions are heavily invested in distinguishing such bots from humans, any solutions that you come up with like using random delays will not be able to get even close to the constant arms-race between spammers and anti-spam solutions. This is like trying to pitch to a major league batter. Any "clever" trick you can think up for throwing the ball will be thoroughly ineffective given the ever-escalating techniques used by major league pitchers and batters. Don't try to make your spider act like a human. You won't win that game. The only winning move is not to play.

all links converted to local references

This only matters if you are going to be browsing the site offline. I would not rely on that if you suspect that the website is malicious, because there could be many ways to embed a link to a website which is not detected and converted by wget, but which is detected and accessed in a standard browser. If you fear the offline mirror attempting to phone home, you should only connect to it from a user which does not have direct access to the content. It appears you are already doing this according to #8.
Threat modeling
Though you did add more details, you should still think about your threat model a bit more. What exactly is it you are trying to achieve by preventing them from realizing each month's scraping activity is related or that it is not natural traffic? I can think of only a few reasons this might be desirable:

You need the website contents for reconnaissance for later exploitation.
You don't want the website to notice and block Tor traffic or introduce captchas or delays.
You don't want the website to serve you with custom (malicious or dummy) content.
You are scraping an accidentally-exposed private area of the website, and bringing any attention to the existence of your traffic would result in the unintended access being closed.
The knowledge that someone is scraping it is enough for the administrator to realize who is likely behind it (e.g. if you are scraping a friend's personal site or a forum which you are active on).

Depending on which (if any) of these apply to your situation, you do not need to expend so much effort in avoiding attribution. Most website access logs are not manually analyzed in detail unless necessary for incident-response. Most even log with low enough resolution that things like specific headers are not saved. You can avoid most forms of throttling and blockage simply by using a private proxy (with Tor, if you need anonymity) and by setting all your headers to that of a popular web spider which uses wget. Throttle and ratelimit your own connections to avoid harming the server and forcing them to take defensive action. Remember Aaron Swartz, the man who was arrested and later committed suicide after being caught downloading a large amount of scientific journals at MIT? He used wget, and was only caught because he was using so much traffic and even evaded blocking attempts that JSTOR ended up banning the entire MIT address range and complained to them about the abuses. If he had used ratelimiting, he would have never been caught, would never have died, and Sci-Hub would be a whole lot bigger.
If the website is not operated by someone with at least a moderate level of offensive security knowledge and motivation to "hack back", exploitation of wget should not be your concern. While it is certainly possible, at sometimes more easily than other times, it is not going to be a likely response from a website administrator. I personally have never seen it happen in the wild, at least. This will be a bigger risk if you are, for example, accessing an accidentally exposed backend of a sophisticated security contractor. If you're trying to download Raytheon SI's internal wiki and all you are doing is using plain wget with torsocks, you are doing it wrong and should stop.
Without at least a little more information on exactly what you are trying to achieve, it will be hard to give you a single, satisfactory answer. The most likely complete solution? Use a VPS. Purchase the VPS anonymously (if that is necessary for your threat model), and connect to the VPS using Tor. Configure wget with some basic throttling and ratelimiting to avoid being blocked. This will not only raise no red flags due to Tor usage, but it will also isolate wget in the case that it is compromised.


John the ripper passwd file format with salt not working I'm trying test password strength in one of our e-commerce sites. I'm using john the ripper to brute-force a password file. The algorithm used by PHP is:

$hash = md5($salt . $pass)

No other transformation is performed nor in the $salt or in the pass, I've manually checked one example. I've found in the documentation that the sub-format that goes with the algorithm is dynamic_4. The problem is that passwd file format as written in documentation, doesn't seems to work, John is unable to load the hashes, this is the format that I've used:

// user:$dynamic_4$hash$salt
emi:$dynamic_4$83a3f08cfb2d9d0bac5d1a1619d8b7dd$Z3MkG2FZsaoV9EDCpmSRWvgANQAeXOeN7oadrAugu0rKEvfKqoNj6D9a

I've tried to change the salt for the hash but still nothing

I've tried the following parameters combination:

john --single passwd
john --format=dynamic_4 --single passwd
john --subformat=dynamic_4 --single passwd
john --format=md5 --single passwd
john --format=raw-md5 --single passwd

I've looked John the ripper source code and your syntax of using John The Ripper .

In john the ripper dynamic hash subformats salts lenght are limited .

src/dynamic_preloads.c:

static DYNAMIC_Setup Setups[] =
{
    { "dynamic_0: md5($p) (raw-md5)",           _Funcs_0, _Preloads_0, _ConstDefault, MGF_NO_FLAG, MGF_KEYS_INPUT },
    { "dynamic_1: md5($p.$s) (joomla)",         _Funcs_1, _Preloads_1, _ConstDefault, MGF_SALTED, MGF_NO_FLAG, -32 },
    { "dynamic_2: md5(md5($p)) (e107)",         _Funcs_2, _Preloads_2, _ConstDefault, MGF_NO_FLAG, MGF_KEYS_INPUT|MGF_SET_INP2LEN32 },
    { "dynamic_3: md5(md5(md5($p)))",           _Funcs_3, _Preloads_3, _ConstDefault, MGF_NO_FLAG, MGF_KEYS_INPUT|MGF_SET_INP2LEN32 },
    { "dynamic_4: md5($s.$p) (OSC)",            _Funcs_4, _Preloads_4, _ConstDefault, MGF_SALTED, MGF_NO_FLAG, -24  },
    { "dynamic_5: md5($s.$p.$s)",               _Funcs_5, _Preloads_5, _ConstDefault, MGF_SALTED, MGF_NO_FLAG, -12, 31, 56  },
    { "dynamic_6: md5(md5($p).$s)",             _Funcs_6, _Preloads_6, _ConstDefault, MGF_SALTED, MGF_KEYS_BASE16_IN1, -23, 55, 80 },
    ...
    ...
    ...

for example dynamic_0 is 32 byte,dynamic_4 is 24 byte,dynamic_5 is 12 byte, and ... .

You must modify the source code and recompiling JTR for supporting more than defualt value for salts .

dynamic_4 field is not allow in passwd file .

Simple of cracking a salted hash :

sajjad@xxx:~/Downloads/john-1.7.9-jumbo-7/run$ cat pass.txt
admin:d5fedea70cf14c3191fc8e94fe4ca8b9$Y0g7Wx78AdpjIdZd

sajjad@xxx:~/Downloads/john-1.7.9-jumbo-7/run$ ./john -form=dynamic_1 -w=password.lst pass.txt
Loaded 1 password hash (dynamic_1: md5($p.$s)  (joomla)  [128x1 (MD5_Body)])
admin            (admin)
    ...
    ...
    ...

In order to show the cracked password, use the --show option

sajjad@xxx:~/Downloads/john-1.7.9-jumbo-7/run$ ./john --show pass.txt


Hashcat: How to discard words of length less than N after rules have been applied? Hashcat: How to discard words of length less than N after rules have been applied?

I know of the rules <N and >N that discards the word if its length is less than and greater than N, respectively.

The problem is that these rules can only be applied using the -j or -k options of Hashcat,  which means that they operate on the wordlist itself, and not on the rules-transformed words.

Using "old" Hashcat I can use the <N and >N rules in the rule file itself, but then I can't crack using the GPU...

Any suggestions on how to discard rule-transformed words of length smaller than N?

The answer depends on the "speed" of the target hash:

If it's a fast hash (like MD5), Daisetsu is roughly correct - that it's not worth the trouble to worry about it (though it can vary based on attack and targets);
If it's a slow hash (like bcrypt), the GPUs won't be starved for candidate passwords, so you have the luxury of generating candidates externally (off-GPU) without slowing down your attack.

A common technique for the latter is to combine hashcat's --stdout option with your attack to generate your candidates, and then pipe that hashcat to another instance of hashcat (which does the actual cracking).

To inject length requirements into that pipeline, the hashcat-utils len utility works this very efficiently. If there are complexity requirements, the req utilities from hashcat-utils is also very efficient.

So you could do something like this to generate the candidates:

$ hashcat rockyou.txt -r rules/best64.rule  --stdout
123456
654321
123456
123456
1234560
1234561
1234562
1234563
1234564
1234565
[snip]

... and then pipe that to another hashcat (for example, assuming a requirement of length minimum of 8, and maximum of 11):

hashcat rockyou.txt -r rules/best64.rule  --stdout | len 8 11 | hashcat -a 3200 targets.hashes

... but keep in mind that this is useful only for slower hashes.

Note that if the hash is slow enough, you can use anything (Perl, shell scripts, crunch, etc.) to do whatever fancy candidate generating and sifting that you want. As the speed of the hash starts to increase, you'll want to benchmark your pipeline to make sure that you're not starving the GPUs (they should usually show 100% in hashcat's status output). hashcat and len are very fast, as are the other tools in hashcat-utils, so I usually point people there.


Methods for allowing restricted access to web applications Since I'm fully aware that allowing access for anybody to open web hosting control panel (login page), can be a little bit risky, I started to think about restricting access and allowing only for my users, but I'm not sure which method should I use.

I was thinking about IP restriction, but dynamic IP can be a problem, then proxy or VPN is also kind of solution, so any other ideas?

P.S. This issue is not only related to cpanel, but also for other web applications, where restriction should play a role.

I'm also planning to hide URL like in this example: https://website.com/51ca673ea8e89a868706fd309777a101ac63a409/phpmyadmin

I would suggest more VPN as some inside-webserver solution. The reason is, the problem of the authentication and encryption belongs to this specific software, while webservers have to fulfill a lot of other criteria, too. Calculating the working hours / security I would vote a VPN solution.

You have to solve 2 tasks:

authentication
encryption

Although the authentication part can be made also in the webserver. In this case, we can see the 3 points of the authentication:

what you are
what you have
what you know

I suspect you don't have too much control over your users, and over their systems. Thus (1) falls out. You can think on (2), i.e. on some hardware key-based authentication. In the case (3), you can use either the good old passwords, or some more tricky way (for example: one time password sent by sms).

On the encryption side: the VPN solves it. On HTTPS, it is not so easy. Use strong encryption algorithms with properly configured and authorized certs.


Why banking websites always ask me to authenticate my PC even after I'd chosen to "Remember my Computer"? Why banking websites always ask me to authenticate my PC even after I'd chosen to Remember my PC? This is the case with all banking websites

An aspect of security which more and more banks are implementing is to try not to trust anything sent by a computer, as an attacker could theoretically change the responses sent to the bank.

Imagine you have authenticated your PC, and an attacker has captured your traffic and has your cookies. If they then try to log on to your account and the bank doesn't ask them to authenticate their PC, that is one less hurdle for them to beat in order to get at your money. So the bank can insist that their cookies are not stored, or that specific ones are wiped on logout.

From a general security perspective, I wouldn't let my PC remember any details from an internet banking site, or in fact any site that could be used to steal sensitive usernames or passwords.


Verifying PGP Messages Is it possible to sort of verify a PGP message?

Alice sends a PGP Encrypted message to Bob.

I know Alice and Bob's public key, and I have their encrypted and plaintext message.

Can I confirm that the PGP Encrypted message is the same as the plaintext message without knowing any of their private key?
Can I confirm that the PGP Encrypted message is from alice or bob with only their public key?

No to both. Details:

PGP encrypts a random symmetric key with Bob's public key, and then uses that to encrypt the message. Since you don't have that key, you can't check to see if the plaintext and ciphertext correspond under it.
The public key of a message only reveals who can decrypt it. All you learn is that whoever encrypted it knew Bob's public key, which doesn't really narrow it down at all.


Is it necessary to encrypt an ASP.NET view state hidden field when using SSL certificate? If you have an SSL certificate for a web site, is it necessary to make the ViewState more difficult to decode.  Without any extra development, it appears that ASP.NET encodes it as a base 64 string.  I found some sample code to easily decode this hidden field "__VIEWSTATE".  Doesn't SSL encrypt this (along with other things) for you?

You have to distinguish two kinds of attackers:

SSL is used during transport to prevent a third person from reading and modifying the transmitted data.

The user who sends data to the server and  gets answers from the server, can obviously see and modify the data any way he or she wants. So the user can modify the hidden form field containing the view state. Base64 escaping does not offer any protection here, it is just a way to ensure that binary data is not messed up by character set conversations.

So in the likely case that your view state contains trustworthy information, that a malicious user must not modify, you need to enable encryption and signing for it.


Is a ZIP file password easy to break? I thought that ZIP file passwords were a fairly decent protection.

I came across this video, that seems to indicate otherwise.

https://www.youtube.com/watch?v=SqRSNuJSm4o [12 minutes view time]

Synopsis:

  The guy uses a zip2exe program to create a
  self-extracting archive from a password-protected zip file, which he
  then runs without using the password and unzips the archive.

What do you think of it? Does it only apply to his particular setup, and if so, what is it in his setup that makes it easy to break the password?

The ZIP format supports several variants of password-protection of a file.

The early password protection system in ZIP is known to be seriously flawed. However, later versions of the format provide far better protection, including support for stock encryption algorithms like AES to which no known attacks exist.

The author of the video appears to be using WinRAR. RARLabs, developers of WinRAR, try to promote their proprietary RAR format, and claim that ZIP does not support AES encryption. That's simply misinformation, considering that competing products like 7-zip do support it. I would suspect that they intentionally use a weak implementation of ZIP to make their own format look better in comparison.

But Nullsoft Installation System (NSIS) does not actually seem to contain a cracker for weak ZIP archives. Why should it? It's a sofware for building installers, not a cracking tool.

Notice that the presentator does not try to actually open any of the unpacked files. The directory structure of a ZIP archive isn't encrypted, so it can be read without the password. Working with encrypted archives is quite out of scope for an installer builder, so the developers likely didn't even bother to detect encrypted files. A telltale sign that the unpacked files are in fact just garbage is this screenshot from the unpacked directory at 11:00.

Notice something? Hint:

   The only visible file here shows a filesize of 0 bytes. The other unpacked files likely don't look much better.


How not to be hacked through Computrace? Computrace can be used by hackers.

I would like if someone can explain in plain language (for mere mortal) how in what circumstances Computrace can be used by hackers (Am I vulnerable always or if I use administrator account etc) and what to do to avoid it.

Although the vulnerabilities associated with Computrace provide a large attack vector, the simplest way of protecting yourself is by not buying a machine that comes with it pre-installed. It's extremely difficult to remove it, and besides, you don't want 3rd party mechanisms doing "strange things" under the hood. Also, in many cases it is enabled by default.

It's basically a rootkit waiting for remote exploitation, and you can do very little about it.

It's part of the BIOS and can run every type of code. You're always vulnerable. Computrace does not enforce encryption when it communicates and it does not verify the identity of the remote server from which it receives commands.

Generally, anything that permits remote control is a potential problem, but in this case, it's a bomb waiting to be detonated.


Is AES + MAC more secure than encrypting plaintext along with its hash Suppose I want to encrypt some plaintext and I can only use an unauthenticated AES mode like CBC.

One way of adding authentication is encrypt-then-MAC, where the two different keys for AES and MAC are derived from the same passphrase using a key derivation function.

Is the above more secure than encrypting the plaintext along with its hash? When decrypting, the hash is then separated from the plaintext and verified. So if the ciphertext is tampered with, the hash verification has to fail (as long as a proper cryptographic hash is used).

There are many small catches when it comes to the order in which to encrypt and MAC.

Encrypt-then-MAC in addition to being most secure has additional advantages. For example, when you receive a message, you first confirm the MAC. If it does not match, you don't even start the decryption. This makes it faster (less resource intense).

While it may be possible to devise a fully secure MAC-then-encrypt scheme, if you have to ask this question, you don't have the skill and knowledge to do so (Neither do I, very few people do). It is recommended to use Encrypt-then-MAC, because it is much easier to use securely.


How effective is Activesync Certificate revocation using CRL or OCSP We determined that a number of our account lockout issues are related to Activesync devices using old/expired passwords.

One way to remedy an account lockout issue is to issue and deploy certificates to our ActiveSync users.    I believe this will give us stronger security with Mutual Auth TLS.

Before we implement this, is this a valid solution to the account lockout problem?  (Will certificates properly prevent premature account lockouts?)
Do the devices (Windows Phone, Blackberry, iPhone, etc) all use a CRL or OCSP as expected or are there issues I should avoid?
Are there any best practices I should adopt?

This page seems to indicate that when client certificates are used, then clients are authenticated by the certificate only, with no reference to any password (just like what is done with smart card logon). No password implies no failed password entry, thus no password-related lockout. Of course, as with all things Microsoft, this requires some thorough testing.

Whether devices will properly download CRL or OCSP responses depends on these devices, and personally I doubt they will. Note, though, that the device authenticates the server certificate; validation of the client certificate happens on the server, so that's the server which should download CRL or OCSP responses when client certificates are used. Microsoft's software tends to do revocation checks more or less properly (i.e. they reject the connection when the CRL cannot be obtained).

My cynical part tells me that the best practice with PKI is probably to run away as quickly as possible when X.509 certificates are talked about. It is known that maintaining a PKI is a lot of work. Microsoft's PKI (Active Directory Certificate Services) does a lot of things automatically and works best when all the involved systems are part of the same Domain as the CA.


Why doesn't Gmail make it clearer that emails have been signed by DKIM and delivered over TLS? If a webpage is delivered over HTTPS, the browser makes this clear with a padlock symbol. It's something that people look for. My browser also makes it clear that a page is not secure.
Why aren't emails treated similarly? In Gmail, you have to open up a small pop-up to see that an email is signed by DKIM and delivered over TLS. Else there's no obvious indication.
I ask this because someone asked me to put a link to PayPal in an email but it's a bad idea due to the risk of phishing. Except this would be no more insecure than a website if users were on the look out for a secure symbol, as they are with a website.

TL;DR: Mail delivery using TLS and signing using DKIM are weak protections, compared to accessing a web site using HTTPS. They should not be assumed to provide the same security and the indicators better  should not suggest such interpretation.

... delivered over TLS?

Mail is delivered hop-by-hop between client and final mail server, i.e. there are multiple servers in between. TLS cares only about protection between these hops, not on these hops. Each of these servers has access to the plain unencrypted mail. The indicator in GMail shows only if the last hop of delivery was done over TLS - and this is all what the final mail server can control.
Because of this hop-by-hop even a TLS indicator does not  mean end-to-end protection of the email, i.e. from sender to recipient. Contrary to this HTTPS is end-to-end protection from browser to server. See TLS encryption email for more on this.

...  signed by DKIM

DKIM does not provide a cryptographic signature created by the sender - this would be done instead using PGP or S/MIME. DKIM is done instead by a mail server on the way. All it shows that the mail was (mostly) unmodified on the way from this mail server to the final mail server. It does not indicate that the mail was sent by a specific user, nor that it was unmodified between sender and DKIM signing mail server.
Note also that DKIM actually allows modifications of the mail. Depending on the method changes in white space are allowed but there can also be changes which completely change the interpretation of the mail - see Breaking DKIM - on Purpose and by Chance for more on this.


If someone has my email address can they get my IP address? I'm being stalked and the stalker is a hacker.  If he gets my new email address can he get my IP address from it?

The question was answered in the comments and summarized here in case someone else comes searching with similar questions.

The email address on its own won't reveal IP address of Sender.

One needs to have access to email sent from given address and email service provider has added to headers sender's IP address. One should note that many service providers do not add IP address of sender. Further, this applies to only emails sent out from a fixed line connections like Broadband or Leased Line etc. Emails sent out of mobile phone connections usually carry the service providers IP address and location information is out of reach for most people.

Edit: As @scott commented one can always find the incoming mail server IP address for the email address in question. If the given domain is hosted on mail services like GSuite, the IP address of incoming mail server will reveal very little or nothing.


How secure is the fingerprint sensor in the Pixel 3? As far as I understand different fingerprint scanners have different security levels. Old fingerprint print scanners could be fooled quite easily as the CCC (Chaos Computer Club) demonstrated.

How much can I trust the Fingerprint sensor in Google's latest phones, Pixel 3/Pixel 3 Xl?

For the sake of ergonomy, smartphones are equipped with small fingerprint sensors which means they are able to obtain only partial images of a given fingerprint. The chances of a partial fingerprint being incorrectly matched with another "user" fingerprint is relatively high. (cf: MasterPrint: Exploring the Vulnerability of Partial Fingerprint-Based Authentication Systems)

Recently (18 Oct 2018) researchers introduced the concept of DeepMasterPrints which is basically based on training a neural network on a set of real fingerprint images in order to create a synthetic fingerprint able to fool a fingerprint sensor, this is roughly done this way (cf: this paper):

So to answer your question:

  This work directly shows how to
  execute this exploit and is able to spoof 23% of the subjects
  in the dataset at a 0.1% false match rate. At a 1% false match
  rate, the generated DeepMasterPrints can spoof 77% of the
  subjects in the dataset.

And Google Pixel cannot be an exception.

This said if you're locking your phone to answer a"normal life" need...You do not have to worry :)


IPSEC - Remote Access Clients, Tunnel or Transport Mode? I understand that transport mode encrypts only the payload.

Do IPSec clients such as Cisco's AnyConnect and/or Cisco VPN Client use transport mode?  Or do these clients and others like them use tunnel mode?

Client-side VPNs (AnyConnect, RDP) use transport mode because they set up end-to-end or end-to-site encryption. They do not rely on any other security infrastructure to create and maintain the tunnel.

Tunnel mode is most often done between VPN gateways (routers) that maintain the tunnel without needing to install or configure the clients.

Some clients can make use of VPN gateways as well, but when your client is "all alone", they use transport mode.


Why are one time password reset links safer than one time passwords? Recently I applied for a job at a company creating

  security-critical solutions for military, aerospace, ...

After registering at their webpage, I received an email with my username and a plaintext one-time password. My first reaction was to jump in horror at their incompetence, especially given that security should be their core competence, but after giving it a second thought, I realized that I am a new user and that nothing is at stake yet. But afterwards I see that their password reset feature actually sends a plaintext one-time password.

This got me thinking, is it really so bad to send a one-time password in plaintext? Especially when someone who claims to make a living out of security does so?

I was reading this highly upvoted answer saying that you should never send any passwords by e-mail. Instead if your user forgets his password, you should send them a one-time password reset link.

But what is the fundamental difference between a one-time password and a one-time link?

So far, I couldn't find any. The closest two clues I got are:

The highly upvoted answer mentions that:

  Do all of this over SSL.

That is, send the one-time link over SSL. I do not understand this point at all. How can you send someone a one-time reset link (in email presumably) over SSL?
There was a comment by Anders under this question mentioning that a link will expire, but a one-time password will not. But again, I do not buy this. Passwords do expire if you want them to.

Furthermore, if the user has a username which is different from his email address, then a one-time password can be actually safer than a password reset link. Anybody can intercept the link, log in, and steal data, but if it is only the user who knows the username, then only he can use the one-time password.

You know how people dealing with information security react when they hear the words password and plaintext in the same sentence, right? If a one-time password reset link is just a one-time username+password, then this practice should be looked down upon even more, am I right?

All in all: Does sending one-time passwords over email in plaintext mean absolute incompetence?

This could be fine - after all a password reset email contains a "one time password", albeit one that is really a secret key and based upon a long, pseudo random sequence that is unfeasible to brute force.

Also, this could also mean there is a Denial of Service attack against a legitimate user:

Attacker goes to website, knows that Bob@example.com is a user (e.g. through a username enumeration vulnerability).
Attacker presses to reset Bob's password.
New temporary, secure password sent to Bob@exmaple.com
Bob, without current access to his email now cannot log into the system.

Password reset links do not have this flaw, however minor it may be to the system in question.

If temporary passwords are issued, it would be wise to generate one with at least 80 bits of entropy (the current NIST recommendation), and force the user to change it immediately on login, even if they "force browse" to any other URL in the authenticated section of your website. i.e. it should redirect them back to the change password screen until they do, and it should also make sure that they select a different password.

The other problem you've now got it that if the user does not use the temporary password immediately. You've got a password sitting in cleartext in the user's mailbox, which isn't the best location for password storage. You may have to expire this password somehow, leading to additional complexity in your application. Having separate password reset links simplifies things, as its only the instance of a link itself that expires, not their primary password.

In short, it is much easier and more secure to have a separate password reset mechanism that doesn't touch the user's password until they've confirmed that they can in fact access the mailbox associated to the account.


What is a good way to demonstrate the insecurity of common bad practices? A friend of mine teaches a "Basic IT Security" class at a .edu and asked what demonstrations he can do, live, to show why certain practices are bad.

Currently, we have cobbled together a Firesheep demo, which is impressive, but it's becoming unreliable as the browser ages (it only works on Firefox 3.6.x) and as more websites handle their cookies properly.

Can anyone suggest a good demonstration of why doing X is bad? The more "impressive" to a lay-person, the better

So far some ideas have been:

Use wireshark to sniff a password/email that has been insecurely transmitted
Show how a phish works from the attackers point of view
Perform a dictionary/brute force attack against a weak password
Pull the (unencrypted) HDD from a laptop and get some files off it

So far we don't think any of these are terribly impressive, from the point of view of a bored Joe Ordinary. Appreciate any suggestions!

So I am currently a student and have taught in a Security Club I have for a few years. Every year we start from square one and I end up teaching the same things over again. Here is some of the things I cover.

The Club is a "Cyber Defense Club" but we have found it extremely important to teach the offensive side. We usually cover these.

I also try to go over why they work...

ARP Poisoning (Cain)
DNS Spoofing  (Cain)
Password Cracking (John)
Buffer Overflows (C)
Metasploit Framework (...)
Port Scanning, Banner Grabbing, and Vulnerability Scanning (nmap, nessus)
The importance of Changing Default Passwords (I use xampp and let them try to change all the default passwords. Not many people have found them all)
Firewalls (Windows, IPTables, Cisco ASA)
System Hardening (Disabling unnecessary Services, etc.)
Incident Response (I teach this for our Cyber Defense Competitions. It isn't very practical in the real world)
HoneyPots (HoneyD)
Physical Security

This is just starters what you can teach.

Applied to your question you can do a lot:

Why Not Patching is Bad (Metasploit)
Why Using LMHash is bad
Why Not Changing Default Passwords is bad
Why Using strcpy, etc. is bad.
Why leaving unnecessary services open is bad.
Why Not having a firewall is bad.
Why Not Having Logs is bad.
(MORE) Why Storing unhashed passwords is bad.
Why no physical security is bad.
(MORE) Why Not following the OWASP Top 10 is Bad.

Intro Courses are the most fun because if the professor makes it great....they are really really great and can hook the whole class. I hope I was helpful :D

edit: I just read that your course is aimed at end users. My list was for Students who want to learn Security. Still hope you can use some of it.


Is there a reason to create a database user without schema privileges? One of the common things seen people setup is database users (for use by an actual application) that only have SELECT/UPDATE/INSERT/DELETE permissions. A separate user (that additionally has CREATE/ALTER/DROP/etc) is used to actually deploy schema updates (either an admin account, or a user dedicated for that purpose).

I am wondering what the rational behind this is.

There are two situations I am looking at specifically, both in a continuous deployment environment (so the application is automatically built and deployed):

A separate deployment system does schema upgrades while deploying the app itself.
The application does its own schema upgrades on initial startup.

Scenario 2 is often necessary when there are many environments being deployed to on separate networks (eg separate AWS VPC's).

In the case of Scenario 1, it's not a huge deal to have a separate user account
with schema privileges, but in the case of 2, it is.

The only rationale I've ever heard is the cop-out statement "less privileges are better for security". It's not that I disagree with this statement, but I'd like to understand why it is better for security.

I think this boils down to the question: If someone compromises the credentials... what can they do with schema privileges that they can't do with only SELECT/UPDATE/DELETE?

"Destroy" the database? DELETE is quite capable of that. UPDATE/INSERT is arguably even more dangerous as an attacker could subtly modify existing data in a way that won't cause an obvious catastrophic failure like dropping a table or deleting all rows would
Extract data? SELECT does that.
Modify the schema? Uh.. to what end? If done in a way that breaks the app, it's obvious, and either way, may be removed by the next app deployment.

Am I missing something else?

I'm not sure that this is always done for security from external users.  For instance - you might have a DBA who wants developers to be able to Select/Update/Delete records, but not start rolling their own schema changes.  So they setup an account to be used by developers while keeping the more powerful accounts for themselves.

In the case of an external user gaining access to your database through SQLi or something like that, I agree that they can wreak havoc with basic select/update/delete operations, but there are others things that they could do if they have the ability to say drop tables.  For instance - if the main page of an application queries a specific table and that table has been dropped, the attacker can essentially prevent the site from coming up.  Granted - if your db has been compromised you probably want to take the site offline, but ideally you decide when that happens and not the attacker.

This might be far fetched, but an attacker could also start tracking information that they might find useful by logging information to a table they have created using triggers or something like that.  If the database doesn't get a lot of attention this might go un-noticed and they could check back and use this information for more sophisticated attacks.

Those are some specific scenarios that come to mind.  I disagree with your assertion that creating accounts with the least privileges they need to function is a "cop-out".  Depending on how creative an attacker is, i'm sure there are other ways they could exploit these extra privileges to their own nefarious ends.  In addition I can't think of a reason to give accounts more power than they need.


What alternatives to IPSec for diversifyed redundancy? I need to provide redundancy to an IPSec link between two premises. I would like to have no single point of failure and to diversify technologies. What could I use please?

Are the following leads possible:

HTTPS link encrypted using PKI
4G link

If you're looking to provide redundancy between sites, you're right that a TLS would be a viable solution for an extra security protocol and a 4G connection has the potential to be a form of redundancy for the site-to-site connection.

Your question isn't really clear on what you're asking for specifically, because HTTPS and 4G work on entirely different levels. If you're talking about protocol redundancy, depending on your use case, you could easily use another encryption technology such as TLS or SSH to connect the two sites. If you're wanting connection redundancy I'd recommend using a secondary line from a different ISP or like you said, a 4G connection to maintain the connectivity in the event of your VPN having downtime. Obviously you can combine the two since, like I said, they work on entirely different levels. For example; you can get a 4G connection and use TLS over it.


Secure way to run Flash on Chrome? I kinda addicted to Little Big Snake, an online game that requires Flash. I'm trying to find a secure way to play this game on Ubuntu using Chrome.

I tried Firejail but the game is very laggy with it. The only thing I do for now to make it more secure is enable AppArmor. I hope you have better suggestions for me. For instance, can Incognito mode in Chrome mitigate zero-day attacks on Flash player?

"btw Incognito mode in chrome can mitigate zero-day attacks on flash player?"

No, no way. No. I have no idea how you figured that.

As flash is notoriously insecure, there is not much you can do other than sequestering the browser from the PC. Your best bet is probably virtualization. Either run a VM, or use Qubes, on OS that does that for you. Alternatively, you can try using OS run from a USB memory stick, that can not write to your HDD such as Tails. Without being able to read form/write to your disk, there is nothing very harmful it can do.


Browser fuzzing with Windbg the story looks like this: we have a browser, we have attached windbg to this browser,
we have a fuzzing 'page'. now, when browser will crash (and i.e. I know that bug occurs somewhere in the HTML code), how can I find that code which crashed the browser?
is there a way to find it during the windbg session?
appreciated for any help.

A simple approach would be:

Figure out how to crash it every time.
Attach a debugger
Break at the program entry point
Continue until the program asks for input
Provide input that would crash the program
Step over each call (there shouldn't be too many), don't step into. One call will crash it. Put a breakpoint on it and run again, but this time step in. Step over each call again, until it crashes, then move your break point one level deeper, etc.

It shouldn't take too long for you to reach the bottom.

Also some debuggers can break just before (or after) the program crashes. If you can do that, then you can do it the other way around, start at the crash place and work your way up to find a reason.


Display Full Credit Card Number and PCI compliance I've been reading through PCI compliance rules to see if it is ever PCI compliant to display the full credit card number on a webpage to a user.  I've found some info about paper receipts and rules dictating which digits are visible in the card number.  But there is also this blurb from the PCI Security Standards Do's and Don'ts document:

  Do not store cardholder data unless
  there is a legitimate business need;
  truncate or mask cardholder data if
  full PAN is not needed and do not
  send PAN in unencrypted emails,
  instant messages, chats, etc..

In my scenario, I have a PCI compliant way to accept card information and a PCI compliant way to store this information (through an external site).  I'm wondering if it is PCI compliant to display this information to the merchant that will be processing this card with their own payment system.  They would view this information after logging into a secure site with the data being retrieved from another site through an HTTPS GET request.

The PCI DSS permits the display of card holder data for valid business purposes - but that comes with taking on full liability and penalties if any of your customers' cards are misused for fraud. Such display puts you directly in harm's way, and from a risk avoidance viewpoint I would very strongly discourage your implementation of this function.

If you do choose to display card holder data, there are many additional rules around authentication, logging, auditing, etc., that you will need to follow. Plus, there is data you must not store and therefore cannot display, such as CVV.  Anyone using your data will be paying the maximum interchange rate for Cardholder Not Present (CNP) transactions.

At least check with your QSA to see what they will require of you before you start down this path. The cost of implementing it, plus the tremendous risk you will take on should give your upper management a lot to think about before approving a system like this.


Which forensic disk image format should be preferred? I want take a forensic image of an hard disk. However I am a little confused on which format should I take the image. DD (raw) or E01? What are the advantages and disadvantages of each?

It comes down to what you want to do with the image once you've created it. If you're going to be using Encase Forensic to dig through it, or performing lots of searches on it, you're probably better off going for E01 format, since it is optimised for those use cases. It also has built in checksumming, which is important if you are copying data over less than ideal means.

On the other hand, if you're looking to investigate the image using standard Linux tools, you can mount a raw image and operate on it without any third party tools. However, that's pretty much the only way to operate on it - which gets unwieldy with larger images.

E01 has built in compression support, when used with Encase software, but raw images can be compressed using third party software (although the amount of compression will vary massively based on the image contents). E01 files can also contain metadata, which is useful when you want to add notes to, for example, deleted files.

A good place to look for information on forensic tools and software is the Forensics Wiki - which has a list of different file formats and their pros and cons.


ISP provider does not giving permission to change my router password We have got a new connection from a local ISP provider, the provider supplied a router and other few devices, then he has configured the device with a password, but he does not allow us to reset or change the password for own. means we are unable to configure anything from our side, Is this good secure for our personal data?

No.

It means that your ISP provider can basically control your network. Change DHCP ranges, control port forwarding etc.

In a business situation, with sufficient contractual assurances, this might be possible. After all, some companies even outsource their complete IT.

In a personal situation, I would take a small SoHo router and connect only the WAN port to the ISP provider's router.


AES encryption do I need to use a Mode? I am currently working on a file encryption program using Java Cryptography Architecture.

My plan is to have a number of encrypted files where each file has a different AES key.
To keep track of the encrypted files I also include a metadata file which stores an entry for each encrypted file with the following values: plain text file name, cipher file name and AES Key.

The metadata file is then encrypted using an AES key that is derived from the user's password.

My question is should I implement a mode? and do you think keeping all the passwords in the encrypted metadata is acceptable practice?

Here is the code I have been referring to:

public class PasswordBasedEncryption {

PBEKeySpec pbeKeySpec;
PBEParameterSpec pbeParamSpec;
SecretKeyFactory keyFac;

// Salt
byte[] salt = {
        (byte)0xc7, (byte)0x73, (byte)0x21, (byte)0x8c,
        (byte)0x7e, (byte)0xc8, (byte)0xee, (byte)0x99
};
// Iteration count
int count = 65536;
int keySize = 128;

Cipher pbeCipher;
SecretKey pbeKey;
FileInputStream fis;
FileOutputStream fos;

/**
 * constructor given a master password
 * Use password based derivation function II to make AES key.
 * used only for the metadata file encryption
 * @param password
 */
public PasswordBasedEncryption(char[] password){
    try{
        keyFac = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
        pbeKeySpec = new PBEKeySpec(password, salt, count, keySize);
        SecretKey tempKey = keyFac.generateSecret(pbeKeySpec);
        pbeKey = new SecretKeySpec(tempKey.getEncoded(), "AES");
        pbeCipher = Cipher.getInstance("AES");
    }
    catch (Exception e){e.printStackTrace();}
}
/**
 * constructor given a generated AES key
 * each file has its own AES key to avoid known text attacks
 * @param key
 */
public PasswordBasedEncryption(SecretKey key){
    try{
        pbeKey = key;
    }
    catch (Exception e){e.printStackTrace();}
}

public void encrypt(String filePath, String cipherName){
    try{
        File clearFile = new File(filePath);
        fis = new FileInputStream(clearFile);

        pbeCipher = Cipher.getInstance("AES");
        pbeCipher.init(Cipher.ENCRYPT_MODE, pbeKey);

        CipherInputStream cis = new CipherInputStream(fis, pbeCipher);
        File cipherFile = new File(Path.TEMP + cipherName);
        fos = new FileOutputStream(cipherFile);
        int read;
        while((read = cis.read())!=-1)
        {
            fos.write((char)read);
            fos.flush();
        }
        cis.close();
        fos.close();
        fis.close();
    }
    catch(Exception e ){e.printStackTrace();}
}

public void decrypt(String cipherName, String filePath){
    try{

        fis = new FileInputStream(Path.TEMP + cipherName);
        File clearFile = new File(filePath);
        fos = new FileOutputStream(clearFile);

        pbeCipher = Cipher.getInstance("AES");
        pbeCipher.init(Cipher.DECRYPT_MODE, pbeKey);
        CipherOutputStream cos = new CipherOutputStream(fos, pbeCipher);
        int read;
        while((read = fis.read())!=-1)
        {
            cos.write(read);
            cos.flush();
        }
        cos.close();
        fis.close();
        fos.close();
    }
    catch(Exception e ){e.printStackTrace();}
}

/**
 * Generate secret password used each time a new file needs encrypting
 * @return
 */
public static SecretKey genPass(){
    KeyGenerator keyGen;
    try {
        keyGen = KeyGenerator.getInstance("AES");
        keyGen.init(128);
        return keyGen.generateKey();
    } catch (NoSuchAlgorithmException e) {
        e.printStackTrace();
        return null;
    }
}
}

AES is a block cipher: it takes as input a key, and one block of exactly 16 bytes, and outputs another block of 16 bytes. That's the extent of what AES itself does.

So, if you want to encrypt a sequence of bytes which is not a single 16-byte block, then you must use a "mode of operation". And that is what you are already doing in your code. You just did not actually specify it in your code, and you let Java select one for you. Unfortunately, the default may be ECB, which is atrocious and weak; see this document which includes the following:

  For example, the SunJCE provider uses ECB as the default mode, and PKCS5Padding as the default padding scheme for DES, DES-EDE and Blowfish ciphers.

(No word about AES here.)

So, in any case:

You MUST understand what you are doing. Security cannot be tested, so the only way to make secure code, especially with cryptography, is to have a thorough and in-depth knowledge of what happens internally.
You MUST specify exactly what you are doing. Don't let your language select ill-defined default values.
You MUST NOT do it yourself. Writing secure crypto code is one of the hardest tasks in development, precisely because there is no way to know if you did it correctly (although experience shows that the answer "no, it's been done poorly, it is weak" almost always fits).


Own password manager. How to store passwords I want to play a little bit and create my own little password manager (with gpg) in node.js

My question is how I should keep those passwords:

In one encrypted file (let's say in json format),
Separate file for every entry and all files keep in hidden directory. Filenames will be eg. stackoverlow@username and inside will be all necessary credentials with additional data.

What do you think? Maybe there is a better solution?

Both approaches have been used in many password managers. Neither of them are, strictly speaking, more secure than the other, it's just that they both have different security model, leading to different solutions and different trade offs.

Most password managers stores all data in one encrypted file. This is the default approach most password manager use. This has the advantage of being simpler and possibly slightly more secure but less flexible.

The approach where you store every password in different GPG files have been used in pass. This had the advantage/weakness that the password file names are stored unencrypted, which allows many operations without needing to unlock the entire password store, you also have the flexibility of storing different passwords with different keys, or to share parts of your password directory.


IIS 7.5 WebDav Security Issues with Students Hello Currently I am setting up a server for college students (this includes tech-savy IT students as well) and I will be using IIS 7.5 with Webdav for the students to access their files from home. The built-in Webdav filters out all dangerous file extensions (php,asp,etc dangerous server code) and I was wondering if there is any way for them to break out of these extensions and/or compromise the system. The new version of Webdav seems good enough for me to trust and I was wondering if anyone had some experience or advice with the newer versions of the file system.

Also I am not looking for suggestions on different types of file servers, I know a few I could use and I already have the files on my server ready for IIS 7.5.

Thank you

I'd go the other way round, disable script execution for all upload directories.

http://www.aspplayground.net/community/Disable-script-execution-for-the-upfiles-folder-m376885.aspx

File extensions are not dangerous, code execution is. Depending on the server configuration it might be possible to rename a file through some backdoor or execute scripts even if the extension is wrong (I've seen webservers executing php in .html files, so it's not entirely impossible for someone to screw up the configuration so that the php interpreter runs over every file). Maybe updates break your security (.php6 suddenly might work, too) or someone installs support for a new language.

Also students might want to upload .php only to work on those. Especially if you are expecting IT Students.


Why is the first step for an attacker to get Reverse Shell after getting RCE? If someone is having a Remote Code Execution, that means, one can run the commands on the server, then why does he need to get the Reverse Shell?
Even though I can run system commands, then why do I go for Reverse Shell?
I am finding the primary reason behind it.

Remote code execution means you have successfully executed some specific code on the server. It does not mean you can execute anything else on the server, yet. The solution is to have the executed code make a connection back to you and allow you to send more commands for it to run. That's what a reverse shell is for. Without a reverse shell, you'd potentially have to re-exploit the server with a new payload over and over for each additional command you want executed. That would be a royal pain.


Shall I need to use MD5 algorithm in both JavaScript and PHP for login authentication? I have a login form with username and password. I post this form data to a PHP file. For security reasons I want to encrypt my password in the database and network. Now I have done now following steps.

Get username, password from user and using HTTP POST send data to login.php
In login.php get these username,password and using MD5 Algorithm with salt to encrypt password
Store the username and encrypted password in database.

I want to know, is it the correct way or should I use MD5 algorithm in JavaScript (login form)? Or do I need to add MD5 algorithm in both JavaScript and PHP?

If we disregard the actual algorithm choice and consider the question: "Should I hash on both client and server side?"

Hashing in Javascript is completely unnecessary since the idea is to protect against the password being sniffed during transfer. But if that is a risk then the communication with the server is not secure which means that there could already be a man-in-the-middle attack going on.

This means that the javascript hashing algorithm could have been delivered by the attacker instead of the server. The algorithm could then for example send the password to the attacker.

So, no. You should not hash in the browser but instead use a secure connection to the server.


Strongest cryptographic algorithm available in PHP 5.3 Which options are available in the default installation and which ones by third-parties like extensions or frameworks?

P.S. By Cryptography I mean algorithms which could be decrypted, not one-way encryption like md5.

As encryption primitive I'd use AES. Both AES-128 and AES-256 are strong enough. Numerically AES-256 is stronger, but it's very unlikely that AES-128 is the weakest point in your system.

Since php doesn't seem to support an authenticated encryption mode, you need to build that yourself. I'd use HMAC-SHA-256, possibly truncated to 128 bits.

To combine these operations I'd:

Generate a new random IV with mcrypt_create_iv(16, MCRYPT_DEV_URANDOM)
Encrypt the message with AES in CBC mode with that IV
Note that AES is always MCRYPT_RIJNDAEL_128 even with 256 bit keys
PHP uses zero padding by default which cannot unambiguously removed. A better padding is PKCS#7, but you'll need to add/remove it yourself. There are many existing implementations for that.
Concatenate the IV and the ciphertext
Calculate HMAC-SHA-256 on the result of step 3 (MAC must include both IV and padding)
Concatenate the result of step 3 with the MAC

To decrypt:

Verify the MAC in a way that's resistant to timing attacks
Extract the IV from the ciphertext
Decrypt the message

This is an encrypt-then-MAC scheme. It's recommended to use different keys for MAC and encryption. I recommend deriving both from a master key.


How to determine the make of a router from outside the network I've heard a lot about hackers gaining access to the network by trying default credentials on the router. Let's say an attacker somehow got the router IP of a victim. How would they even know what sort of router it is? Is it even possible to login into your router if you're not connecting to it from inside your network?

Is it even possible to login into your router if you're not connecting to it from inside your network?

Depends on how the router is configured. Although there is no reason to do this, some routers are still configured to have their administrative interface exposed to the internet by default.

How would they even know what sort of router it is?

Simply go to the router's administrative interface. Usually, the login page will provide enough clues to let you figure out which router it is.


Can a hacker use someone else's IP address when running a scam? I have a friend who works on a ship currently in Accra, Ghana.  We do video chats but his system is extremely slow and sluggish. There have been times where our only form of communication is IM.

A few times I have felt like I was not communicating with my friend. I started to make a note of emails that appeared to come from him but were not written in his 'voice'.

I recently checked the IP addresses of these unusual emails and found that they were connected to previous scams. However the IP addresses of his earlier emails did not have any red flags. So I am wondering if his system has been corrupted or hacked.

If so, what can be done to correct this?

If the suspicious emails are from a consistently different IP than the trusted emails, then it seems unlikely that his computer is compromised. Instead, it sounds like someone has found a way to spoof his email address, using their own computer to send it.

Without knowing more information, I can't really speculate as to why someone is doing this. However, there are steps that can be taken to verify that emails are actually coming from your friend, rather than a scammer.

One approach you could use is to sign the message using PGP. In order for that to work, you would both have to set up a mail client (or use a plugin) that knows how to deal with PGP signatures, and then your friend would have to generate keys and send you the public key somehow. At that point, you'd be able to verify that future emails are coming from the "correct" source - or at least, from the source that originally gave you a public key. To really be safe, you'd also want to confirm the key's fingerprint using a trusted channel (like voice chat), in order to verify that the public key is actually from your friend, rather than from some malicious third party.

There are other approaches that could be used on your end to check whether a message is legitimate, although those are likely to involve a bit more specific knowledge about the email servers involved. In comparison, PGP will work in any context, although it requires that both parties have at least a bit of extra cybersecurity knowledge.


How does one steal files by connecting to a laptop's WIFI / Bluetooth? I'm asking how does one steal files by connecting to a laptop's WIFI / Bluetooth and can it be done with the laptop powered off if there is a battery?

Could you please explain how you would connect to a laptop's WIFI / Bluetooth and brute force the login, step by step?

I'm not asking for a hacking tutorial as misunderstood by someone, this is for educational purposes so I can understand it better. There is no existing explanation of that online.

If they have physical access the laptop's wireless devices can be hacked, while it does not display as connected, it is connecting to a Wifi hotspot of theirs to send your files.
the laptop is on or in a suspended state and they are within Wifi range they can exploit vulnerabilities in the laptop's drivers and hardware and send the files.
WakeonWLAN could be exploited and the files sent when the laptop is running again.


What considerations do I need to keep in mind when enforcing passphrases? According to XKCD: Password Strength, if the password consists of “four random common words”, it will be secure and memorable.

I want to make a web application and make users create their passwords in this way. Each password should have at least 16 characters and must be sentence of at least 4 words to make it more secure and memorable. But this will make the attacker know that all passwords are like that. Is this a bad idea?

What better ways are there to force passwords that are more secure and memorable at the same time?

It is not necessarily a bad idea. The attacker can know the password is in that format, considering the 4 words are random enough. But here is the thing, there are other good ways to make a memorable strong password. Limiting your users to the one you like is not very nice. For example I use password manager with truly random long passwords, which is even better than what you propose, but I could not do that on your site.

More importantly, if the reason you want to do this is to force users to use strong password, then generate the 4 words password for them. You can generate such password by having a dictionary, then choosing random number between 1 and the number of words in your dictionary and taking that word. Do this 4 times and you have a password. You can get inspiration here. This is important, as most users may not choose 4 truly random words, but instead 4 easily guessable words. In such scenario, this would be worse then letting them choose any password.


Implications of using domain\computername$ account to serve SQL data to IIS One of our coders is trying to get Windows Authentication to work on a new web app that he's developing (.Net 4.0, MVC, via IIS 7.0/7.5).

The application connects to a SQL Server database back-end via a single SQL logon account:

Domain\Computername$

It is mapped to a User account of the same name within a single database, and given the following roles:

db_datareader
  db_datawriter

Windows Domain users are then somehow authenticated and allowed access to the DB.

Does anyone know if this presents any significant security risks if the web server (but not SQL server) is publicly accessible on the net?  It sounds to me almost as bad as giving those privileges to NT AUTHORITY\ANONYMOUS LOGON, but I must admit I'm not exactly clued-up in this area.

It makes no difference to the security of the web server.

In this case, the account you're connecting with will be the machine account, because the web application is likely running under the context of either:

The Network Service account
The AppPoolIdentity account.

In either case they're limited non-interactive accounts, and since the application is already running under the context of one of these accounts, there is no additional exposure to the web server or network that will be created by using the same account to access the database.  The expose to the database (and database server) will be determined by how you configure this accounts access, is is no different than the exposure created by using any other account configured the same way.

As to adding the account to the db_datareader and db_datawriter roles, that's not unreasonable.  It would be better if all data access were done through stored procedures and you could limit the account to the public role, but if it needs to directly access the underlying tables, then that is the minimum permission set required to access and update data and it's not terribly unsafe.  It does make it more important to account for any potential SQL injection attacks in your app.


How to direct devices by hacking a router changing the DNS settings? If I hacked a router's admin panel outside my network, is it possible to direct all devices in that network to any website I want by DNS settings? If it is possible, how?

If:

the devices have not cached the IP of the domain locally
the devices are configured to use the router for DNS
the devices can access the website you want them to go to
the original site (Facebook, Google, a bank, etc.) does not use TLS settings that prevent this sort of tampering
the router allows you to edit the DNS table to enter your own settings
the router does not override your new entries from authoritative entries from another DNS server

Then maybe.

As for how, you just create DNS entries.


Does browser 'view-source' mode avoid scripting attacks? Let's say there's a URL www.badjs.com which is untrusted and may contain bad scripts.

Intuitively, a view-source navigation to that URL does not execute any scripts so it should be safe. It would at least allow me to inspect the source safely.

But intuition is a terrible way to draw conclusions on security issues, so my question is:

Is view-source a safe way to look at a website from a js script injection perspective?

Yes, it is absolutely safe (in Google Chrome) to open an untrusted website in view-source mode. The key point to note here is that you should "open" the page in view-source mode, meaning you should not allow any rendering to happen by normally loading the webpage first and then viewing the source.

An example in Google Chrome would be view-source:http://www.badjs.com/

By design, Google Chrome will initiate a new GET request to the server and provide the client browser with the unrendered version of the webpage when in view-source mode.

You could also use a No-Script extension or add-on for your specific browser to prevent any scripting attacks.


How should I block BIS connections from accessing my Exchange Server BIS is a technology from Blackberry that allows end users to connect to an Exchange server without a BES server.

The problem is that BES asserts a security policy on the devices, and BIS does not recognise this, or support remote wipe functionality, local encryption (etc.).

How do I block (and optionally detect) BIS connections from my server?

The IP addresses for blocking BIS service are listed here (updated 11/10/11)

http://www.blackberry.com/btsc/KB11036

Preventing these IPs from accessing the OWA servers will prevent end users from bypassing security policy via BIS.


Pip verify packet integrity I've recently used pip to install packets inside of a public network without thinking about it:

pip install packetname

and I was wondering if pip does some sort of verification via hashing or PGP.

Aside from SSL based security aspect, when installing from PyPI pip has an MD5 based checking mechanism (though the hashing algorithm can be changed), which is designed to prevent/check download corruptions and not really be a security guard:

  PyPI provides an MD5 hash in the fragment portion of each package
  download URL, like #md5=123..., which pip checks as a protection
  against download corruption. Other hash algorithms that have
  guaranteed support from hashlib are also supported here: sha1, sha224,
  sha384, sha256, and sha512. Since this hash originates remotely, it is
  not a useful guard against tampering and thus does not satisfy the
  --require-hashes demand that every package have a local hash.

But, pip can also work in the hash-checking mode (which is not enabled by default), which allows you to validate against local hashes for each of the packages you install:

  Since version 8.0, pip can check downloaded package archives against
  local hashes to protect against remote tampering.

Check out this relevant thread as well:

Which security measures does PyPI and similar third-party software repositories take?


How is browsing from a virtual machine/virtual box preventing fingerprinting or tracking? Does it increase your internet security in terms of privacy/tracking/fingerprinting if you are surfing with your web browser in a virtual machine environment (virtual box + VPN) instead of surfing from  your normal windows operating system?

Or is a virtual machine not helping you in fingerprinting cases? I just want to understand if you can use a virtual machine as a additional privacy tool and if yes, on what aspects would it have an impact (IP address, virus infections, fingerprinting, etc.)?

User tracking is typically done at the level of the browser and not the OS. Insofar it will not help to use a browser in a virtual machine, as long as it is always the same browser.


ARP poisoning and port forward together Suppose these assumptions:

Router IP address: 192.168.1.1

Router MAC address: 00:00:00:00:00:00

My IP address: 192.168.1.2

My MAC address: 00:00:00:00:00:01

Victim IP address: 192.168.1.3

Victim MAC address: 00:00:00:00:00:03

Now if I perform an ARP poisoning attack using Ettercap between router and victim, if the victim wants to send a packet to external host this is what would happen:

Victim sends a packet with (according to what wireshark shows):

Source IP : 192.168.1.3

Source MAC: 00:00:00:00:00:03

Destination: IP 'DEST'. Where 'DEST' is some external IP like '47.32.1.6'

Destination MAC: 00:00:00:00:00:01

Because the packet should be delivered to EXTERNAL host, it should be first delivered to the router whose MAC address from victim's point of view is '00:00:00:00:00:01'

The router receives this packet and because the MAC is pointing to me (as the attacker) it forwards the packet to my interface.

Now Ettercap gets the packet and recognizes the source IP as victim's IP (which is '192.168.1.3') and the destination IP as the router (second victim), then sends this packet to forward the packet to real host and allow streaming:

Source IP: 192.168.1.3
Source MAC: 00:00:00:00:00:01
Destination IP: DEST
Destination MAC: 00:00:00:00:00:00

This process takes place for every packet receiving from victim to Ettercap, but if I use port forwarding by IPtables rules, then it seems that the received packet to my machine from victim should be sent to router twice, because:

Ettercap receives the packet and as far as it is from the victim, Ettercap forwards it to router.
The OS delivers the packet to local running app which is listening on predefined port. For example if I use the command below:

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080

then any packet targeting port 80 is delivered to local app listening on 8080 and then the app can send the packet to external host. (For example if it's a proxy)

But surprisingly this won't happen. In fact what does happen is only step 2. The packet is delivered to the local app and it processes ahead.

I think this is because OS changes the "destination IP address" of receiving packet to our interface IP address, so when Ettercap catches the packet and detects that the destination IP is the address of our own machine, it ignores the packet. But Wireshark shows the correct IP address, not the changed one. Can some experts please explain what exactly happens here?

PART 1: Generic explanation, unnecessary to read if you have read the question.

The first (how does the packet arrive at the attacker):

  Victim sends a packet with source IP '192.168.1.3' and source MAC
  '00:00:00:00:00:03' to destination IP 'DEST' and destination MAC
  '00:00:00:00:00:01'. Where 'DEST' is some external IP like '47.32.1.6'
  The router receives the packet and because the MAC is pointing to me
  (as the attacker) it forwards the packet to my interface.

The victim sends a packet with source IP '192.168.1.3' and sourced MAC '00:00:00:00:00:03'  to destination IP '47.32.1.6'. The victim cannot find a direct route to this address (as it is not in his subnet), so it sends the packet via the default route, to '192.168.1.1' (i.e. to the default gateway, the router in this case). However, as we are on ethernet, the victim needs a MAC address to send the packet. You mention that the router has MAC address '00:00:00:00:00:00', but the attacker has poisoned the victim's ARP table. Instead of the entry

192.168.1.1           00:00:00:00:00:00

the victim has the following entry in his ARP table:

192.168.1.1           00:00:00:00:00:01

(You can check this by opening a command line on the victim's PC, and running the command 'arp -a' before and after you started Ettercap).

This means that, whenever the victim tries to send a packet to the router OR to the external network, this packet will arrive at the attacker, until you 'RE-ARP' the victim.

The second (how does the packet arrive at its real destination):

  Now Ettercap gets the packet and recognizes the source IP as victim's IP (which is '192.168.1.3') and the destination IP as the router (second victim), then sends this packet to forward the packet to real host and allow streaming:

Before the poisoning starts, the attacker makes sure his ARP table contains the correct entries, like so:

192.168.1.1           00:00:00:00:00:00 (the router)
192.168.1.3           00:00:00:00:00:02 (the victim)

Now, in the first section, we stopped at the point where the external packet arrived at the attacker's PC, but of course, we need to make sure the packet reaches its 'real' destination. Otherwise, the victim would never get a real response, and would thus notice it fairly quickly that something's off. Therefore, the attacker wishes to forward the packet to its real destination: the default gateway (the router). This is possible, as the attacker knows the real MAC address of the router. It actually receives the following packet from the victim:

Source IP: 192.168.1.3
Source MAC: 00:00:00:00:00:03
Destination IP: 47.32.1.6
Destination MAC: 00:00:00:00:00:01
The fact that the destination IP is translated to the MAC address of the attacker, is because the victim will look up the destination IP in its routing table (route print), and it finds that it should send this packet to the default gateway. It therefore sends out an ARP request (or looks in his ARP table, arp -a), and notices that the MAC address the packet should be sent to is '00:00:00:00:00:01'

What's important here is the fact that the attacker sees that this is a packet that is actually not intended for him. A packet that would have been intended for him would look like this:

Source IP: 192.168.1.3
Source MAC: 00:00:00:00:00:03
Destination IP: 192.168.1.2
Destination MAC: 00:00:00:00:00:01

So, whenever the attacker receives a packet, he will check the source and destination IP, and forward it using his unpoisoned ARP-table, in this case to '00:00:00:00:00:00' (the router).

PART 2: Summary of the question asked

At first, the question was not fully clear to me. However, after CS explained it more carefully in chat, the question comes down to this:
In a set-up, where Ettercap is active AND a custom application listening on port 8080 is actively forwarding traffic (to the victim), and where port forwarding is active to redirect traffic coming in on port 80 to port 8080 (the custom app), why is it that the these packets (the one originally intended for port 80) arrive at the victim only once?

One might think that the following would happen:
- Packet comes in on port 80, actually intended for the victim, but redirected to the attacker because of an ARP poisoning attack
- Iptables redirects this packet to port 8080
- Ettercap forwards the packet to the victim
- The custom application, which is explicitly built for forwarding packets, also forwards the packet to the victim

However, the victim receives the packet only once. Why?

PART 3: The final answer

Ettercap will only forward traffic which has the following characteristics:

the dest mac address of the packet is the same of the mac address of the attacker
the dest ip is not the same as the ip address of the attacker

Now, the problem is that, by using the iptables REDIRECT command, the following happens:

the destination port is changed (from 80 to 8080 in this particular case)
the destination IP is changed to the main IP address of the device on which iptables is running.
as this is a PREROUTING rule, the above happens before the packet reaches Ettercap

It is the 'destination IP change' that answers the question why the packet is not forwarded twice. Imagine the following packet, intended for an external web server, coming from the victim:

Source IP: 192.168.1.3
Source MAC: 00:00:00:00:00:03
Destination IP: 47.32.1.6:80
Destination MAC: 00:00:00:00:00:01

If this packet were to arrive at Ettercap, the forwarding condition would have been fulfilled: The destination MAC of the packet is the attacker's, but the destination IP is not.

Now, this packet does not arrive in that form, the iptables REDIRECT command transforms it to the following:

Source IP: 192.168.1.3
Source MAC: 00:00:00:00:00:03
Destination IP: 192.168.1.2:8080
Destination MAC: 00:00:00:00:00:01

It does so, because 192.168.1.2 is the main IP address of the device on which the redirect command takes place. Thus, this packet will be ignored by Ettercap.

PART 4: Final insight

Now, the above is actually the same that happens in case you enable SSL dissection. To enable SSL dissection, the following lines need to be uncommented in etter.conf:

redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"

As you may notice, this is almost exactly the same command as the iptables command mentioned in the question. Therefore, the same applies: ettercap does NOT forward packets coming in on port 443. What happens is the following:

Traffic from the victim comes in, that is supposed to go to a https server
Because it is redirected by iptables, ettercap will not forward it anymore (as the destination IP is changed). This means all SSL traffic stays on the attacker's pc.
Ettercap then creates a fake server, with a fake certificate. It starts communicating with the real ssl server to provide HTML/JS, but the client talks DIRECTLY to ettercap. Packets are not forwarded anymore.

This is the same as in the case explained in the question, except for the fact that the SSL dissector does NOT forward traffic, whereas the application created by the TS still does.


Is using a CA more secure if I'm self-signing anyway? We have a web application that we run for clients at their booth on fairs. The communication between clients and the server was done over HTTP until recently.

We're currently working on improving several security-related aspects of this application. For example, I now implemented support for HTTPS and wrote a small script to generate a self-signed certificate for the server. The clients should add this certificate to their trusted certificate stores so that the browser doesn't complain about it. So far so good.

On chat, someone mentioned that I should never use a standalone, self-signed certificate and that I should instead use a certificate authority to sign my certificate, even if the CA itself is self-signed.

Given that I would still have to manually trust the self-signed CA on the clients, I don't see how this would have any benefit from a security standpoint. I guess it would be slightly more convenient in certain cases, but we usually erase the clients and server after each deployment and reimage the next time we need to set the system up.

The distinction depends on some details about the self-signed certificate and how the browser and the OS will react to it.

A normal certificate includes a Basic Constraints extension which contains a flag telling whether the certificate is for a CA or not; when the flag is TRUE then the certificate is considered acceptable as an issuer for other certificates. If the extension is altogether missing, then the certificate is to be considered as non-CA.

Root CA certificates are "special"; they are not true certificates. They are trust anchors; a TA is, nominally, a public key coupled with a name. It is traditional to encode trust anchors as certificates, and since a certificate includes a field for a signature, some bytes must be stored there; there again, Tradition says that we shall make the certificate self-signed. Nobody really checks that signature, though; junk bytes of approximately the right size would serve just as well.

The tricky point is then that the interpretation of the certificate extensions, if any, found in such a "root CA certificate", is non-standard. In particular, some historical root CA date from before the invention of the Basic Constraints extension; as true certificates, they would be interpreted as "not CA", but since they are trust anchors disguised as certificates, the normal interpretation rules do not apply.

So on some browsers or OS, a non-CA certificate (lacking a Basic Constraints extension, or even featuring one with the cA flag set to FALSE), once installed in the "root CA" store, may very well begin to be accepted as a CA. Thus, confidentiality of the private key for any certificate installed in the user's trust store is rather critical.

What's the difference in your case ? After all, in your situation, there are two choices:

You create a self-signed certificate for your server, and the user installs that certificate as "trusted".
You create a self-signed CA certificate, that the user installs as "trusted". You issue a normal certificate for your server with this CA.

In both cases, the user surrenders his security to some certificate from you, that the user installs as "trusted". So what would it change ?

The difference is that if you use a custom CA, you can store the corresponding private key with good protection. For instance, you do the CA business on a laptop which is kept offline at all times. There is no possibility of a remote exploit when there is no network at all. Root CA should always be offline, and used only as part of manual procedures and USB keys for data transfer. On the other hand, your server is, well, a server, so it is online and intrinsically exposed. An attacker who hacks into your server may get a copy of the server's private key. If the corresponding public key has been installed as "trusted root" in the users' machines, then the attacker gains a lot of leverage on these machines as well.

Briefly said, making a custom CA distinct from the server's certificate (as used all day long) allows for better protection of the private key, and thus a lower risk of catastrophic attacker's power escalation.

There are browsers which are not as vulnerable. What you really want, with a self-signed server certificate, is that the users trust that certificate only for SSL connections (not as a CA), and only for that specific server. Firefox knows how to do that; it is called a "security exception" in Firefox terminology (see the Preferences -> Advanced -> Certificates -> View Certificates, then the "Servers" tab).


SSL Inspection and privacy I know my company is testing something called "SSL Inspection" based on Websense, which is our proxy. I can not provide more detail about this, but does this mean that in principle all my SSL traffic, for example my web bank password or security PIN, could be actually read by WebSense ?

Yes, SSL Inspection is essentially a man-in-the-middle "attack" (except it's not really an attack since it's being done by the infrastructure owner) with the intention of being able to read all traffic originating from your company machine or crossing your company network, even if SSL is being used.

Consequently, you should not send anything from your company issue machine, or over your company network, that you do not want your corporate security team to read.

(Which is a good general rule in any case.)

Some other points to bear in mind:

A reasonable company will not care about your personal data.
An ethical security team will go to some lengths to avoid seeing personal data
A sensible company will have documented what they will and won't do - see what's been published.
There is a small but non-zero risk with any such system that a real attacker will compromise the monitoring system.
There are other methods available to a corporate security team for monitoring computer use - they can deploy keyloggers, for example.

If an organization has to implement a robust Data Loss Prevention system, they're going to have to look at everything - so even though they are implementing SSL Inspection it doesn't mean they have evil intent. Not much fun for their employees, of course, which is why transparency is so important.


PHPMyAdmin vs Remote client restricted by IP address I'm looking for a secure way to access a MySQL database. I'm currently using PHPMyAdmin but wondering if it would be better to use a desktop client and restrict access to only the IP addresses I know I will be accessing from.

Does anyone have any thoughts on the best way to go?

Sequel Pro offers some interesting connection methods that you just don't have with PHPMyAdmin.

With Sequel Pro you can connect to your MySQL Server via SSH. This means you can take advantage of the private/public keypair connection of your OS (that's heaps better than passwords).

private/public keypair is a better login option than passwords (so using SSH via Sequel Pro would be more secure than using passwords with PHPMyAdmin).

If you do want to use PHPMyAdmin you should consider these points:

Consider using HTTP Basic Auth in front of PHPMyAdmin
Always restrict access to only your IP Address if you can (this can help cut down on a number of login attempts)
PHPMyAdmin needs to be secured, and kept up to date
don't have predictable file locations such as /PHPMyAdmin (this cuts down on the attempts from automated scanners)
Make sure you use HTTPS
PHPMyAdmin configuration can store credentials, these could be compromised


How will SHA1 deprecation affect SHA1 roots in OS/Browser trust stores. I understand the SHA1 deprecation policy applies to CA's issuing SHA2 end-entity certs and intermediates starting Jan 2017 but how will this policy affect the actual root certificates in OS/Browser trust stores? Will the SHA1's be getting flushed out in favor of SHA2 roots? I know a lot of CA's are now going SHA2 up to the root but wondering if MS and the others plan on keeping SHA1's in the trust stores for a specified period of time.

(Edit 2014-11-25: Reworded flushed out to phased out.)
Short answer: From what I can tell, they will be gracefully phased out, not flushed out. (At least by Microsoft.) The old SHA1 root certs will expire regularly and Microsoft will no longer accept NEW SHA1-roots starting 2016. The old ones will stay in I guess, since they were compliant to the guidelines when accepted into their root CA program. -- The other 3 organisations I looked at had no limits on SHA1 roots.

Microsoft
Microsoft will no longer accept SHA1 for their root CAs after the end of 2015.
http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx

  Digest Algorithms
  SHA1 (until 1 Jan 2016)
  SHA2 (SHA256, SHA384, SHA512)

They did the same thing with MD5 a while back.
http://technet.microsoft.com/en-us/library/cc751157.aspx

  Hash algorithm must be at least SHA1. No MD2, MD4 or MD5 hashes accepted.

CABForum
CABForum disallows MD5 in roots starting 2010. But SHA-1 is (as of yet) still allowed for root CAs. (So while there is no security reason to mandate any digest algorithm the root CA self signature this shows that it has in fact been mandated before.)
https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf

  Certificates MUST meet the following requirements for algorithm type and key size.
  Digest algorithm: Validity period beginning on or before 31 Dec 2010:
  MD5 (NOT RECOMMENDED), SHA-1, SHA-256, SHA-384 or SHA- 512
  Digest algorithm: Validity period beginning after 31 Dec 2010  SHA-1*, SHA-256, SHA-384 or SHA-512

Apple
Couldn't find a rule against SHA1 there.
Apple don't mention SHA2 in their root CA requirements. Instead they require a SHA1 fingerprint on the application form.
https://www.apple.com/certificateauthority/ca_program.html
But since there are SHA-256 certs already in their store this seems to be a formal detail of the application form only.
See Yosemite included root CA certs here: http://support.apple.com/en-us/HT202858

Mozilla
Couldn't find a rule against SHA1 there.
Mozilla requires a SHA1 fingerprint on the application form.
https://wiki.mozilla.org/CA:How_to_apply
And, like with Apple: But since there are SHA-256 certs already inside their store this seems to be a formal detail of the application form only.
See Mozilla included root CA certs here: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/included/


Run metasploit console resource scripts Hi I want to do this in my lab environment:

When meterpreter shell is gained, automatically I want to execute console commands such as route add, jobs -K or use some other exploit or auxiliary modules. There is multicommand , multi_console_command  and other ruby scripts to do that using AutoRunScript option in msf handler. Unfortunately all of those scripts only run commands in meterpreter session and I want to change this logic. I want to run them in console. Consider this scenario, you want to kill job when session is come and add route then run another auxiliary module.

How to do that?

multi_console_command.rb (by darkoperator) uses the meterpreter APi cmd_exec() to execute a list of commands.

The metasploit API that allows us to use the shell interpreter is: session.shell_command()

Option 1:
build your own multi_console_command.rb module with session.shell_command() API
Option 2: build one resource file with those post-exploitation commands

My metasploit API cheat sheet list:
https://github.com/r00t-3xp10it/hacking-material-books/blob/master/metasploit-RC%5BERB%5D/metasploit-API/my-API-Cheat-sheet.md

My metasploit resource files cheat sheet:
https://github.com/r00t-3xp10it/hacking-material-books/blob/master/metasploit-RC%5BERB%5D/metasploit_resource_files.md