Which access rights should be chosen for doku wiki? I'm currently making my first experiences with a CMS called "DokuWiki" (Link). This CMS needs only PHP and writes the information to files (seems to be /dokuwiki/data/pages).

At the moment I gave the whole dokuwiki-folder + subfolders and files the rights 777. I am the owner of the files / folders.

Which access rights should be given to the folder? Should I change the owner (e.g. to www-data)?

Do you know any attack based on to many rights for folders/files?
I could only imagine an attack which uses a PHP vulnerability to get access to the filesystem and then uses the rights to do harm.

edit: I've just found install:permissions. Is my assumption right, that the following set of permissions is the minimum needed by DokuWiki to run?

$ sudo chown www-data -R /var/www/wiki
$ sudo chmod 400 /var/www/wiki -R
$ sudo chmod 600 /var/www/wiki/data -R
$ sudo chmod 600 /var/www/lib -R
$ sudo chmod 600 /var/www/conf -R
$ sudo chmod 700 /var/www/wiki/data /var/www/wiki/data/tmp /var/www/wiki/lib var/www/wiki/lib/plugins /var/www/wiki/conf

Generally the best practice for web site permissions are to give the web user, in your case www-data, read, but not write, access to the data files. That is, something similar to:

chown root:www-data -R /var/www/html
find /var/www/html -type d -exec chmod 750 {} \;
find /var/www/html -type f -exec chmod 640 {} \;

The goal is to allow the web server application to read the files, but not be able to write anywhere. That way if the web service itself is compromised we have limited a malicious user's ability to drop arbitrary files. (Read up on chroot as a corollary, but is outside the scope of this answer).

Wikis, by their nature, must violate this practice for them to properly function. However, the key is to understand exactly which parts of the wiki software need higher privileges. In order to really decide, you have a choice:

Use the web interface for creating/editing pages only.
Use the web interface for creating/editing pages, as well as managing configurations.

Option 1
This will set up all of the file level permissions such that users can edit/create pages, but it will require you to manage configurations manually. If you (or whomever manages the wiki) feel comfortable with PHP syntax, and don't mind working on the config files then this is probably your best bet. So your permission set should look like:

chown root:www-data -R /var/www/wiki
chmod 750 /var/www/wiki -R
chmod 770 /var/www/wiki/data -R
chmod 750 /var/www/lib -R
chmod 750 /var/www/conf -R
find /var/www -type f -exec chmod -x {} \;

So what we've done here is given root read/write and www-data read only to all wiki files. Then given www-data the additional rights to write to the user data section.

Option 2
If you also want to manage the configs through the web interface then use the same setup as above, except swap out line 5 for:

chmod 770 /var/www/conf -R

Disclaimer: I've never run DokuWiki setup like this, but I don't see any reason why it won't work. Test it out first, eh?


BrowserID and HTTPS conflict? My flask-webapp was utilizing BrowserId. When I tried to extend my app further by redirecting all incoming requests to HTTPS. The HTTPS redirect worked fine but now the login feature results in a:

  login failure: error

What is causing this problem? What might I do to fix it? In case it matters here is my webapp.. I'm deploying on heroku using Gunicorn as the server. Here are the heroku logs for a failed login

I'm not familiar with Flask, but I suspect that this might be due to a problem with redirecting a POST request. In particular the POST request that the front-end sends to the backend in order to verify the assertion.

One thing you could try (to test the above theory) is to have your application not listen on port 80 and only on 443. That way there won't be a mix of HTTP and HTTPS and flask-sslify will not have to redirect anything.


Are login "certificates" more secure than standard username + password authentication? I just opened a new bank account which comes with internet banking. Unlike the others I have used so far, this one requires a personal certificate (a .p12 file stored on my computer) + password for authentication instead of standard username + password. This method is rather inconvenient... I have to store the certificate somewhere safe, I have to back it up, I can't access my account on any computer unless I have the certificate with me, the certificate has an expiration date and I can't simply generate a new one.

So... are there any upsides? I would assume that this method would be more secure, but I'm not sure about it. I don't know how the authentication process actually works but it seems to me that stealing a certificate from client's computer is just as easy/difficult as stealing his username. Personally, I feel better about my username stored only in my head than about a file stored somewhere on my hard drive.

The certificate protects users against the most common authentication security threat: password reuse.  Most internet users have a tendency to use the same or similar passwords across different sites, even banking sites.  When this occurs, it means the compromise of a password database from another site now allows access to the banking site.

Certificates also protect against the 2nd most common threat: phishing.  Using mutual authentication in TLS for the client verification makes phishing almost impossible.  (The attacker would need to plant a rogue CA in both sides of the connection, and if they're in a position to do that, they can do many worse things.)

You are correct that a certificate is not significantly harder for an attacker to steal than credentials, so offers little security to a user with a compromised endpoint.  The certificate does protect against two very real problems, however, and is thus a more secure option than a simple username/password.  As you've pointed out, this security comes with a usability cost, which is unfortunate.


Soft-fail vs Hard-fail SPF + Monitor vs Reject+Strict DMARC, could it be counterproductive? I have a ProtonMail premium plan with one custom domain and a single email address. My domain DNS is protected with DNSSEC.

What caught my eye were two things they recommended in the domain setup:

Soft-fail SPF (Sender Policy Framework - wiki) (~all):

Recommendation:

  v=spf1 include:_spf.protonmail.ch mx ~all

My setting (Hard-fail):

  v=spf1 include:_spf.protonmail.ch mx -all

Monitor DMARC (Domain-based Message Authentication, Reporting and Conformance - wiki) (p=none)

Recommendation:

  v=DMARC1; p=none; rua=mailto:address@yourdomain.com

My setting (Reject + Strict):

  v=DMARC1; p=reject; adkim=s; aspf=s

Is there even a point of setting a Soft-fail SPF instead of Hard-fail; why would anyone recommend this, and is there a situation where Hard-fail is counterproductive? The very same question I have for Monitor DMARC instead of Reject + Strict.

Note for completeness:

I have DKIM (DomainKeys Identified Mail - wiki) also.

Result of https://www.mail-tester.com

... is there a situation where Hard-fail is counterproductive

Some mail servers actually reject mails on SPF Fail. Given that SPF has known trouble with mail forwarding services and some mailing list this might lead to loss of mails.

For use with DMARC it actually does not matter if SPF is Fail or Soft-Fail. All what matters is if SPF is Pass and this result is the same for both kinds of policies.

  The very same question I have for Monitor DMARC instead of Reject + Strict.

DMARC depends on SPF and/or DKIM, i.e. at least one of these must be fine and must have the domain aligned with the From field of the mail header. If you don't have a DKIM policy it thus all hangs on SPF which as I said has its inherent problems. While DKIM is more robust in this regard it can fail too, for example if the mails gets transformed during transport from 8bit to some ASCII encoding (base64, quoted-printable) due to missing support for 8BITMIME in one of the MTA on the way.

Therefore, the recommend setting is to actually start with none, monitor for a while if problems occur and if no problems occur move to reject or quarantine.


nmap - how can I input a target to nmap from a file with the netmask attached? I have a c program that gets the router IP and netmask and puts it into a text file in the format of 192.168.1.1/24. When I issue the nmap scan command with the target text file I get the unable to split netmask from target expression error.

This should work... issuing the nmap command with the ip/mask specified rather than reading from file works obviously. Issuing a different nmap command when reading from file with just the ip address in works as well. Only when the /24 is on the end of the address does the error occur.

Is this down to a fundamental flaw in the nmap file reader or is there a way around this?

I am issuing the commands with the popen function in C

scan = popen("nmap -sn /tmp/file.txt", "r");

You need to use the -iL argument to nmap to specify the file it is reading, then it will properly expand any CIDR addresses in that file, as shown:

$ cat file.txt
192.168.0.1/24
$ nmap -sT -Pn -p 22 -iL file.txt

Starting Nmap 6.40 ( http://nmap.org ) at 2020-01-09 13:00 EST
Nmap scan report for 192.168.0.0
Host is up.
PORT   STATE    SERVICE
22/tcp filtered ssh

Nmap scan report for 192.168.0.1
Host is up.
PORT   STATE    SERVICE
22/tcp filtered ssh

...

Nmap scan report for 192.168.0.254
Host is up.
PORT   STATE    SERVICE
22/tcp filtered ssh

Nmap scan report for 192.168.0.255
Host is up.
PORT   STATE    SERVICE
22/tcp filtered ssh

Nmap done: 256 IP addresses (256 hosts up) scanned in 63.20 seconds


Is it practical and worthwhile to alternate penetration test vendors? Is it considered a best practice to alternate the vendor used to perform penetration tests? For example if it is your policy to conduct a third-party penetration test semi-annually you would have vendor A conduct the penetration test in the first half of the year and vendor B conduct another penetration test in the second half of the year.

[Edit]
Ideally you would be alternating between two trusted partners. The idea being that no one person/company is perfect. With that said is this practical and do the benefits justify expending the time/effort/money required to build two solid relationships.

Many (maybe most?) people consider rotating providers a best practice.

The most worthwhile benefit I typically hear is it enables you to compare the quality and value.

I also think there is room for you to be creative; for example, hiring a firm specializing in application penetration testing for one round followed by one specializing in social engineering, or soliciting multiple providers per round, or some combination thereof.

In all cases paying attention to the names and respective skill sets of the individuals performing the actual work is key to ensuring you are getting what you expect (i.e. you want to avoid bait and switch tactics and you want to track individuals that deliver high quality).


Security of damaged U2F key? U2F key is praised for its security features. But I am afraid of using something so secure that when it is damaged I couldn't access my own accounts. So I searched what is recovery scenario and for example Amazon describes it as following:

if you can't sign in with your MFA device, you can sign in by
verifying your identity using the email and phone that are registered
with your account.

Ok, so I could get my data without U2F, but then... the potential intruder would need no U2F too. Avoiding email/phone path was the whole point behind U2F device, right?
My question is as follows -- do I miss something or the case of damaged (true or false) U2F key is actually a weak spot? I mean either recovery is easy for user (and intruder) or it is hard/impossible for user (and intruder)? Are those only two choices, or there is some middle ground, where it is easy for the user but hard for intruder?

In most cases, you can configure OATH-TOTP access as a backup. Sometimes, you can also register more than only one U2F key.


How to filter evil Regex and filter input with regex in python? How to filter evil Regex and filter input with regex in python?

Is there security regex library or database that can use a list of regex to filter and check vulnerable input in python?
Some regex itself are evil too, how to filter evil or vulnerable regex to protect regex match and regex find etc function in python?
https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS

To prevent SQL injection you don't need any regex to filter input. In python use prepared statements. No matter what parameter you put to the prepared statement you have a quarantine that there is no SQL injection.


Return AWS signature over HTTP I am performing multipart upload to S3 straight from the browser, i.e. bypassing my back-end.

My JS code sends a hand-shake request to S3 (a POST), then uploads the file in chunks of 5MB  (a PUT for each) and eventually, finalises the file (a POST).

That works well. As you can guess, each request to S3 (hand-shake, part uploads and finalisation) has to be signed. It is of course out of the question to generate the signature in JS as it would expose my AWS secret key.

What I am doing so far is the following : before each request to S3, I send a request to my own back-end (to /sign?method=HTTPMethod&path=URLToSign) returns the signature string. This way, all AWS credentials stay in the back-end, as should be.

My question is the following : Is this secure?

I realise the /sign end-point could be used by anyone to sign anything into my S3 bucket. I can reduce risks by making sure the /sign request is an XHR whose referrer is my own domain.

Yeah the backend can be used in your case to sign anything into your s3 bucket.

You could block cross site XMlhttprequest for /sign but why you are letting others know that you are using some backend script.
For this thing you might have to be aware of XSRF called as cross site request forgery attack that can be performed.

Specifically saying this method is not so much secure as compare to using backend to send data to aws. Also there are many ways that have been online to do cross site xhr request.

For prevention of xsrf you might have to look here too

http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html
http://www.cgisecurity.com/csrf-faq.html

But i wont do your way.though its easy and good way but it has vulnerability that can be exploited.


How safe is TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA? I'd like to know how safe the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA Cipher (Cipher ID: [0xc009]) is. Alternatively, I'd appreciate to be directed to some sort of list that lists all available Cipher Suites from strongest to weakest.

It is safe, but not ideal. Let's break it up into its individual components:

ECDHE - This is the key exchange mechanism. It is diffie-hellman key exchange using an elliptic curve, typically a NIST curve such as P-256. It provides forward secrecy, because each key exchange uses a different, randomly generated private key.
ECDSA - This is the algorithm used to sign the certificate. Like DSA, each signature requires high-quality random numbers. The failure of the RNG during even one signature can reveal the private key. This makes it rather fragile, but when used correctly, it is secure. The alternative is RSA which is the industry standard, but uses bulkier keys and signatures.
AES_128 - The symmetric cipher is 128-bit AES, a secure block cipher and the NIST standard. Virtually all TLS connections use AES. Most key exchange algorithms do not provide much more than 128 bits of security anyway, so there is little reason to use a larger key size.
CBC - Block ciphers require a mode of operation, and CBC is one of them. While it is fine in theory, it is notoriously easy to get wrong and has been the source of numerous padding vulnerabilities in the past. Any modern version of TLS should not be vulnerable to these, even with CBC. CBC is an unauthenticated mode, which brings us to...
SHA - An HMAC, a type of keyed hash, is used to provide integrity. It is given a secret key which allows each side of the connection to verify that the data has not been tampered with in transit. In this cipher suite, SHA-1 is the algorithm used with HMAC. While SHA-1 has been found vulnerable to a collision attack, that is not relevant for its use in HMAC.

Rather than just using this one cipher suite, why not follow best practices?


SQLinjection prevention: parser + blacklist? I know the best way to prevent SQL-injection is parameterized queries. But this is not possible in the specific use case because the client has to be able to input SQL statements directly.
So what my client did was to use a blacklist, which could be easily circumvented (e.g. use 'DEL'+'ETE' instead of DELETE to prevent detection).
Would SQL injection still be possible if the user input is parsed by a parser first? The user inputs an SQL string, and if there's a blacklisted keyword, it gets omitted. If the input has something like 'DEL'+'ETE' in it, the parser would parse it to DELETE (which is blacklisted) and the request would be omitted.
Is there a way around this? How could injection still be possible? The parser that is used has no known vulnerabilities itself.
The only thing that google lead me to was Parse-Tree validation, which is also not possible because the user-supplied queries can have different parse-trees each time.
Thank you for your help.

Your approach could probably be bypassed as well, maintaining a blacklist is a "why not" but is definitely not efficient.
Depending on the technical stack you use, I'd suggest you use an ORM which will reduce your risque (but is not risk-free neither)
The best thing you can do is trust no-one: Assume all user-submitted data is evil and validate and sanitize everything:  Escape all user-supplied input; almost every programming language has a bunch of functions to sanitize user input.
Checking the length of the given pram before using it could help also. You can as well, in cases where params are ints, try to cast the string to int before using it.


How serious are security concerns of wireless healthcare devices? Back in 2008 a wireless defibrillator was shown to be hackable.  At this year's Black Hat conference a presenter showed exactly how to hack into a wireless insulin pump.  Both of these demonstrated the ability for the potentially lethal hacking of wireless medical devices.

(Here's a shameless plug.)  I and a couple other authors put together a book chapter that mentioned our concerns about security of various wireless medical devices available at http://www.intechopen.com/articles/show/title/wireless-telemedicine-system-an-accurate-reliable-and-secure-real-time-health-care.

While no known lethal viruses exist at this point, manual hacks becoming available brings the concept of such viruses one step closer.  Perhaps I'm a pessimist, but it seems to me that assassination attempts between countries or companies would have the potential for producing such a virus... or just dumb chance that another virus on wireless networks may trigger serious problems with such a devices.

Do you have similar concerns or am I being overly concerned?  Has anyone else seen or discovered lethal security issues with other wireless medical devices?

Consider this from the insulin pump story:

  in true hacker fashion, he has spent the last two years trying to hack it himself.

Given two years of dedicated effort, I suspect you could hack a whole lot of things.  Does that mean they are inherently unsafe or that we should take an alarmist approach?  I don't think so.  (btw, I'm not saying your question is an alarmist approach)

Any medical device must conduct a risk analysis.  Any risk analysis must take into account forseeable misuse.  In this day and age, network intrusion, viruses, etc. most assuredly falls under the category of forseeable, and will need to be mitigated.

I think the real question is how much mitigation is enough?  That can only be answered in the context of a particular device.


Can you set a custom x-forwarded-host header in a CSRF form page? Can you set a custom x-forwarded-host header in a CSRF form page (not xhr)?

You cannot explicitly set any HTTP headers in a HTML form apart from choosing the Content-Type between two predefined values. This means you also cannot set some x-forwarded-host header.


Is it safe to give credit card information by email? I had hired a shipping company and now they want me to send my Visa Card information by email to pay them. The method of payment was never discussed prior to them shipping my boxes. They did a good job and I want to pay them but I'm concerned sending my credit card information by email is unsafe. Are my concerns founded? Would telling them the information over the phone be any safer?

It is a violation of their merchant agreement

All credit card merchants are required to conform to PCI-DSS which spells out rules for handing credit card data.  If you check the PCI DSS standards, you'll find the following:

  Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).

(The "PAN" is the CC number, a.k.a. Primary Account Number).

They should not be asking you to send credit card information over email if they are a legitimate authorized merchant.

See also this answer.

See also this PCI DSS cheat sheet (check the sidebar on page 2).

If the vendor loses PCI-DSS compliance (and you can lodge a complaint and possibly trigger a painful PCI-DSS audit by calling Visa corporation) then they will lose their ability to process credit card transactions.

P.S. No, it's not safe.


A tiny version of wget (51 bytes?) On this ISC article on DVR compromise the author talks about the compromise of an embedded system. In particular, the attacker executes a series of echo commands on the remote host, and:

  This DVR has no "upload" feature. There is no wget nor is there an ftp or telnet client.

  ...

  The first echo writes 51 bytes to "/var/run/rand0-btcminer-arm" and
  the second echo returns "done", indicating that the system is ready
  for the next echo command.

  Unlike the name implies, "rand0-btcminer-arm" is not a bitcoin miner.
  Instead, it just appears to be a version of "wget".

I do not understand how could even the basic fundamentals of wget fit in 51 bytes. The article contains a packet dump, so I guess I could write it to file and try to reverse engineer the binary but I suspect there's something else going on here.

Could anyone help me understand how is this happening? Is the "binary" doing a library call to network functionalities?

The author had made the mistake of being ambiguous and confused the readers a bit. I must admit, like you, I was confused at first, until I saw the PCAP dump.

First of all, the box indeed doesn't have wget

The attacker didn't use that one echo statement, he used a series of echo statements. I counted about 107 echo statements progressively building the executable rand0-btcminer-arm. At about 50 bytes each, that's about 5350 bytes. Way more than enough to achieve a simple HTTP download.

Here's a snippet of them (highlighted in red):


Does Java's implementation of OCSP and CRL checking handle intermediate CAs? I've read that Java provides OCSP and CRL checking for CertPaths via:
Security.setProperty("ocsp.enable", "true");
System.setProperty("com.sun.security.enableCRLDP", "true");

Do these implementations check for the OCSP and CRL of intermediate CAs as well, or do they only check the leaf certificate?

The source code seems to say yes. Get it from there; then look at the files in jdk/src/share/classes/sun/security/provider/certpath/. In particular, PKIXCertPathValidator.java implements the validation mechanism. In the doValidate() method, classes which will do the OCSP or CRL checking will be instantiated as OCSPChecker or CrlRevocationChecker, and they will be applied at the end on all certificates in the path (this is done by a PKIXMasterCertPathValidator instance).

Without looking at the code, this behaviour could have been deduced from the API documentation on java.security.cert.PKIXCertPathChecker: the init() method explains quite plainly that all certificates in the path will be fed to the checker instance.


Could the bcrypt-ruby binding be vulnerable? While developing a Ruby on Rails application using a commonly used authentication library named devise, I noticed from the prefix $2a$ of the produced password hashes in the application database that it's using a bcrypt variant.

I read up about crypt and bcrypt on Wikipedia and noticed that newer variants of bcrypt are supposed to produce a prefix of $2y$ because a non-OpenBSD implementation by someone named Solar Designer had a "major security flaw" in 2011 and therefore it is unclear if the $2a$ hashes were produced by a secure implemenation.

I found out that devise is using a C and Java binding named bcrypt-ruby which indeed bundles a C-implementation copied from John the Ripper which is stated to be written by a Solar Designer. Now I'm wondering if this implementation may still vulnerable to this "major security flaw".

Can anyone bring light to this topic?

Update:

The version history of the file at the crypt repository of the John the Ripper project, from which the file seems to have originated, may help answer my question.

The code you refer to has been corrected.  If you check out the source on Github vs the posted diff fix by Solar Designer, you can see that the sign-extension has been noted and corrected (lines 553 through 556).

Keep in mind that even though prefix $2a$ is not recommended, neither is $2x$ which simply states that the buggy implementation is being used -- albeit, now you know.  According to the Wikipedia entry, you want to ensure your hashes are prefixed with $2y$. However, this was not the original fix according to Solar Designer's email noting the problem.  That fix merely ensured that to REQUEST the buggy behaviour (for backward compatibility), you would explicitly use version prefix $2x$.  The original $2a$ was retained to produce NEW, CORRECT behaviour (see line 609).  Therefore, the code in ruby-bcrypt is correct, but you don't explicitly know it as per the recommendations in the Wikipedia article.


Is it possible to send a cURL request with SSL without the private key? I am developing a service for a client that based on their requirements needs to have client certificate based authentication.

They sent me 2 files, one is the certificate they will send in the request in .cer format, and the other is a ROOT CA file also in .cer format. Here are the file names:

CERT.cer
CA_ROOT.cer

I am trying to configure the access using nginx. Here is my configuration:

server {
  listen 443;
  server_name example.com;

  # SSL client certificate configuration
  ssl_client_certificate /etc/nginx/certs/CERT.cer;
  ssl_verify_client on;

  ssl_session_timeout 5m;

  ssl_protocols SSLv3 TLSv1;
  ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;

  # serve assets or request page from proxy (if asset not found)
  location / {
    try_files $uri @proxy;
  }

  # the play web server
  location @proxy {
    proxy_pass  http://localhost:9000;
    proxy_redirect off;
    proxy_buffering off;
  }
}

Although I don't know how to test this without the private key. If I had the private key I could do something like this:

curl -v -s -k --key private.key --cert CERT.cer https://example.com

Is it even at all possible to do this without the private key file? (which I don't have)

Also, please let me know if I am doing something that I shouldn't, as in no way am I an expert on the security subject

This should be a comment, but its a bit long...

You seem to be missing a basic understanding of how ssl works. It is relatively simple to configure your own certificate authority and use that to produce server and client certificates/private keys, then you just need to swap in the appropriate files when you go into production.

Its straightforward but perhaps beyond the scope of a description here.

You've not said what the trust model is (specific client certs? Client certs signed by a specific CA? Specific common names signed by a range of CAs?). It's likely that you may have to tweak the openssl config.

Will you be running more conventional ssl off the same server? That adds a lot of complications and you might be better considering a secod installation of ssl to handle one of the 2 types of traffic (e.g. using stud).

The encryption you are using is considered insecure.

You can convert the format of the files using openssl from the comand line.


Display link to admin section or not? I have a question and answers site. I have an admin section. From that section I can delete users, threads, responses, and edit various other things. I have some simple code at the start of the admin page:

   if(($session->protected_page_security()) == FALSE ||
    ($session->is_administrator() == FALSE)){
     $session->logout;
     redirect_to('../index.php');
    }

A session class has the following methods....

 public function protected_page_security() {
    if(!$this->confirm_session_is_valid() && !$this->check_login()){
  return false;
    } else {
  return true;
   }
 }

 public function confirm_session_is_valid() {
  $check_ip = true;
  $check_user_agent = true;
  $check_last_login = true;

if($check_ip && !$this->request_ip_matches_session()) {
  return false;
}
if($check_user_agent && !$this->request_user_agent_matches_session()) {
  return false;
}
if($check_last_login && !$this->last_login_is_recent()) {
  return false;
}
return true;
}

public function request_ip_matches_session() {
   if(!isset($this->ip) || !isset($_SERVER['REMOTE_ADDR'])) {
    return false;
  }
  if($this->ip === $_SERVER['REMOTE_ADDR']) {
    return true;
  } else {
    return false;
  }
}

 public function request_user_agent_matches_session() {

  if(!isset($_SESSION['user_agent']) || !isset($_SERVER['HTTP_USER_AGENT'])) {
    return false;
  }
  if($_SESSION['user_agent'] === $_SERVER['HTTP_USER_AGENT']) {
    return true;
  } else {
    return false;
  }
}

 public function last_login_is_recent() {
  $max_elapsed = 60 * 60 * 24; // 1 day
  // return false if value is not set
  if(!$this->last_login) {
  return false;
  }
   if(($this->last_login + $max_elapsed) >= time()) {
  return true;
  } else {
  return false;
  }
  }

public function is_administrator(){
            $administrator_ids = array("164");
            if(in_array($_SESSION['user_id'], $administrator_ids)){
                return true;
              } else {
                return false;
              }
            }

USER_ID = "164" is an administrator.

My question is this:

Do you think it is unwise to have a link to the admin section on the site (even if only shown for me, when I log in)? If someone can gain access to this page, they can bring down the entire database. Is it wiser to not have any link and just type the address in as a url?

I apologise for the simple question -

I am guessing it is possible for someone to find out (hack) the site file structure and "see" that there is an admin section regardless of whether there is any link to it right so maybe my question is moote.

While it may deter very amateur hackers, the concept of security by obscurity is very seldom effective at providing actual security.

A far better approach would be to restrict the admin page to an IP (yours).

Also, I assume you are using wordpress or some other content management system. My two best recommendations for improved security would be to keep the system updated and keep a secure master password.


Remote administration methods There is a requirement for users to remotely access one of my corporate servers from internet. Policy wise, i would want them to at least use 2FA for communication,eg VPN Tokens, password+SMS etc. However, i also recognized that some users may not have the budget to implement at least 2FA. Hence, would like to gather feedback from people in the industry, what could be a good enough alternative to 2FA that could also adequately enable similar type of protection for remote access.
thanks

The good news is two-factor can be free.  Google authenticator is free and mixed with FreeRadius should work with just about any access device.

It is not as fancy or secure as RSA's or some of the others but it is pretty simple to implement and does satisfy a second factor to username and password.

From what I can tell it looks to be certificate based since it does not need a server to talk to on the authentication side, just accurate time.  It does not have the extra protection of RSA for guessing OTP's or pin's but some of that can be accomplished with intruder detection on the device utilizing the authentication.

One thing to watch for, if your using your phone to access the servers and to access the OTP for GA, I do not believe it is considered a 2nd factor from a NIST perspective, as the thing you have should be separate from the device you login from unless there is a defined trusted path.

If money is a concern, it is worth a look:)


Kali Linux and Cell Phone Security Are there any built in tools/programs in Kali Linux that specifically target cell phones? Furthermore, do any of these tools/programs work remotely without sending a listener to the target?

Kali Linux has tools under the category: Hardware Hacking. smali, apktool and android-sdk. These tools are specifically intended to target Android. Although, your question was more around the idea of remote exploitation, like that offered by Metasploit.

To clarify:

Phone number (Used to identify the SIM card)
IMEI number (Used to identify the phone)
MAC address (Used to identify the physical network address)

These are all selectors which uniquely identify you. They do not necessarily allow the device to be hacked. But does allow for correlations when tracking a user. The assumption being, device location equals owners location.

WARRIOR PRIDE code name for a pair of spyware kits that can be installed on the iPhone and Android-based smartphones. See, Angry Birds and 'leaky' phone apps targeted by NSA and GCHQ for user data which outlines the framework of WARRIOR PRIDE.

  DREAMY SMURF – handles power management, which according to The
  Guardian includes "an ability to stealthily activate a phone that is
  apparently turned off"
  NOSEY SMURF – "hot mic", turning on the microphone to listen in on
  conversations
  TRACKER SMURF – high-precision geolocation
  PORUS – "kernel stealth"
  PARANOID SMURF – "self-protection"

Now we have an idea of how real programs compromise Android and iOS. We can focus on the feasibility of using a phone number to compromise the device, which is to say, not feasible. Like with targeting an IP address, we will need open ports to exploit software, and most smartphones do not run servers which will have open ports. Unless you are aware of a character string set which the SMS client will give elevated privileges to (zero-day exploit), the phone number will serve as little purpose, other than being a unique identifier.

What about when the user updates an application, could I MITM and replace the real update with a modified update containing spyware? Absolutely, but this mechanism is either deployed over HTTPS or uses signed checksum validation, like that seen with APT. So, unless you break the public-key cryptography they are using, this is not an option.

What about crafting a website that will run malicious JavaScript (or PDF) code and give browser (or elevated privileges)? Possible.

  Safari on iOS 4.0.2 '.pdf' Local Privilege Escalation
  'Jailbreak'. An exploit like this would have likely, been detected
  by noticing the browser would crash (often a buffer overflow) when
  loading a PDF under certain conditions. CVE-2010-1797

I speak about this exploit in more depth How do hackers find vulnerabilities in closed source operating systems?.

I am brought back to SMS and malicious string sets, despite this not being an area where many scenarios have been documented its still an attack vector. So, I will focus on the social engineering perspective instead. Most people will open a well-crafted SMS, email, instant message without too much extra thought. This is how you can go from simply sending an SMS to directing the user onto a malicious website you control. Some messaging apps will display a URL by fetching the HTML title header and displaying that instead. Although, this is focusing more around the ideas of phishing (hacking the person) to compromise the device. Rather than hacking the device's software.


Secure jquery ajax calls from a non secure page I could not find a clear answer, but if I have the following situation:
I browse to a page let's say http://www.example.com/index.html

Now I use a form on this page to do a postback with jquery's ajax functions to the following URL:
https://www.example.com/login.aspx (aspx could be anything, mvc, webforms, php, ruby etc).

Is this safe or not? I realize that not the whole session is secure.

Or is this safe, but will browsers complain about it? Will it be safer to use a entirely different domain? https://www.example.org/login.aspx

No, it is not secure and using another domain will not help.

An attacker can manipulate the html/javascript code on the http-page to change the destination of the ajax call to his own server. Or even better, add a second call.


Creating a domain admin account from NT\System access So I've popped a shell on a primary domain controller (PDC) which has NT\SYSTEM permissions on the box.
I've created a local admin user account using the following commands:

net user myname myc0mpl3x password /add
net localgroup adminstrators myname /add

However I'd prefer to have Domain Administrator permissions as this will make my network wide exploitation much more simple. My understanding is that this is possible, however I can't find any references or information on how.

I've also attempted using:

dsquery user -samid name.of.dom.acc.i.know | dsmod user -pwd co0mmmpl3xx

to reset the password of an account I know has permissions but that's caused my shell to freeze for some reason.

I will try and use

net user name.of.dom.acc.i.know c0mpl3dxcfd

but I'm not sure of that either.

How else can I create an account with domain admin permissions (I'd rather create one rather than re-set another account's password)?

Are there other simple privilege escalation tricks I can do via command line?

# WINDOWS: Add domain user and put them in Domain Admins group
net user username password /ADD /DOMAIN
net group "Domain Admins" username /ADD /DOMAIN

# WINDOWS: Add local user and put them local Administrators group
net user username password /ADD
net localgroup Administrators username /ADD


password brute force over ssh? (not on ssh) Can  Hydra  ssh to remote host and attempt a password list against su root?
I am trying to recover the root password to an old device. It is an old Apple jailbroken Apple device, running IOS8.
The device is somewhat slow, but have no rate limit or delays. I am able to run 150 tries/min with hydra for the ssh password.
I can log in as one user, and I could try the passwords much faster (i.e. without SSH handshake every 3 tries) using su root. But it is not possible to run hydra there, i need hydra to login and then try the commands.
Is this possible with hydra? Should I use some other tool?

Hydra does not support that mode.
The closest it comes is the Cisco Enable mode, where a telnet connection is used to log into the device and then the enable command is repeated to try different potential enable passwords.  It might be possible to write a new module by cribbing code from hydra-cisco-enable.c and hydra-ssh.c to do what you want.
Alternately, if you have expect, you can use that to write a password guessing script.


Cons of disabling live CD in bios It has been suggested that for security reasons it's a good idea to change the boot order to prevent booting from a live CD or USB. But if you lose the passwords to unlock hard drive and bios, and you cannot boot your laptop from live CD, are you in trouble?

How can you even wipe and restart your machine?

If you remove the boot from CD and USB from your BIOS boot order it does increase security. Anyone cant easily drive by boot your machine when you are not there and copy all your hashes and sensitive information.

If you lose your BIOS password there is usually mechanisms to reset the BIOS back to default. Usually this involves opening the machine and using a "jumper" to short circuit two pins.


Do I need to keep production Docker/container images? Context
My company is developing a SaaS solution that needs to conform to PCI-DSS L1 for sure, and possibly FedRAMP and other frameworks later.
We can do continuous deployment with feature flagged/canary releases, with multiple releases a day. Because of that, we don't really need explicit versioning of the releases (we do version the interfaces, APIs), so we tag our container images with the short Git SHA.
Question
Are you aware of a PCI-DSS requirement (or another widely used governance framework) that expects keeping the container images to be around e.g. 18 months?
We are concerned about the number of container images that will hang around for no practical use. We already know the Git SHA for historical investigation, and we are able to rebuild the image using that if necessary.

At the moment there are no specific PCI guidelines for container based deployments (Although it is mentioned in their cloud guidelines), and I'm not aware of any specific requirements around image retention. There are some guidelines in development, but they've not been released as yet.
It might come up in relation to incident response/forensics, but realistically I'd expect more emphasis to be placed around audit logging at the container, runtime and orchestrator level. Retention of images doesn't really make a huge amount of sense, even there.


Is it safe to encrypt multiple files with the same strong passphrase? I use GPG to symmetrically encrypt multiple files, and it would be more convenient if they all had the same strong passphrase. It's possible that someone could gain access to several of these files.

In this situation, I don't care if getting the passphrase for one of the files gives access to the others as well.

Is it safe to use the same GPG symmetric passphrase for multiple files ?

If needed, please assume --cipher-algo AES256, --s2k-digest-algo SHA512 and --s2k-count <something_big_enough>.

As stated at http://tools.ietf.org/html/rfc4880#section-13.9 OpenPG (and thus gpg) uses a variety of the CFB mode. Especially by prepending a full block of random data to the plaintext key reuse does not reveal additional information about the plaintext to an attacker.
As far as I understood gpg deterministically computes the key from the entered passphrase. (See comment from dave_thompson_085) And gpg also uses the same IV (all zeros) every time. But because of the used cipher mode the answer to your question is: yes, it is safe to use the same passphrase for multiple files if you don‘t care about the typical password reuse issues (but that‘s not the scope of this question).


How long should a random nonce be? NIST provides good guidelines on the length of keys and hashes for various algorithms.  But I don't see anything specifically on the length of a random or pseudo-random nonce (number used once).

If there is a single good answer for a variety of uses, I'd love to see that.  But to make this concrete, I'll use the common "password reset via email" situation, in which the server generates a URL with a pseudo-random path component.  It seems a bit similar to HTTP Digest Authentication, in which the example in the RFC seems to have 136 bits (dcd98b7102dd2f0e8b11d0f600bfb0c093).

I note that many folks seem to use version 4 UUIDs (which provide 122 pseudo-random bits) or this, as discussed at Are GUIDs safe for one-time tokens?, though the user has to beware the use of previous much-more-predictable UUID versions, and nasty persistent local attacks on the Windows random number generator which were mostly patched by 2008.

But ignoring the riskiness of getting tangled up in UUID versions and implementations, how many pseudo-random bits should be incorporated in the URL?

A 64-bit nonce is likely more than sufficient for most practical purposes, if the 64 bits are crypto-quality randomness.

Why is 64 bits sufficient?  Let me lay out the kind of reasoning you can use to answer this question.  I'll assume this is a single-use time-limited URL; after it is used once, it is no longer valid, and after a little while (3 days, say), it expires and is no longer valid.  Since the nonce is only meaningful to the server, the only way that an attacker can try a guess is to send the 64-bit guess to the server and see how the server responds.  How many guesses can the attacker try in the time before the nonce expires?  Let's say the attacker can make 1000 HTTP requests per second (that's a pretty beefy attacker); then the attacker can make about 1000*3600*24*3 = 228 guesses within a 3-day period.  Each guess has a 1/264 chance of being right.  Therefore, the attacker has at most a 1/236 chance of breaking the scheme.  That should be more than secure enough for most settings.


non-cryptographic hash function with output changing just as much as the input The way we know (cryptographic) hashes is mostly that they are totally different if the input is changed for just the minimum amount.

md5('This is some boring string to test with')    // d546c64928a28b5f605610a919680907
md5('This is another boring string to test with') // a74c1d74da495895bf48056ac979723a

Here you see that the hash is totally different, though I only changed one word.

What I'm looking for is a hash function that returns returns an output which is just as similar, as the inputs are similar, and just as different as the inputs are different

fn('This is some boring string to test with')     // 00dd2171b47cc2748c2874c42284737
fn('This is another boring string to test with')  // 01ed2371b47cc5748c2874c42284738
fn('The quick brown fox jumps over the lazy dog') // 27bc27999aa2c3c2452cff234feee21

See how the first two hashes are quite similar, but the third one is completely different.

I don't want just a simple error-checking mechanism that can detect slight changes though (like CRC). I want to be able to check if two hashes most probably have the a look-a-like origin, by seeing that the hashes are also look-a-likes.

My goal is to understand if it is possible to have hashes of let's say two (actual) fingerprints, and then merely based on the hashes conclude if the original fingerprints probably were from the same finger.

A long time ago I once learned such functions exist.

Can anyone tell me what these types of hashes are named, and what some examples are?

Not sure if there existing hashes that do this.  The reason being when hashes were developed, the requirement that any change in the inputs would create a large change in the output was a basic requirement of a hash.  That being said I can purpose a way to do it.

An example would be a hash that just counts the occurrences of each letter in the input. For simplification let's say this hash only takes lowercase alphabet characters.  So the length of the hash will be 26.  Each position in the hash would refer to a different character. So the first position would total up all the a', the second would hold the total of the b's...

hello world

would hash to

00011001000300200100000000

because there are no a's, no b's, no c's, 1 d, ect

a change to

hello worlds

would hash to

00011001000300200110000000

The only difference would be the count for the "s".

Obviously there are many problems with this such as you can only have a maximum of 9 instances of each letter, but this is only an example to show how a hash could show small changes in output for small changes in the input.


What are the problems with encrypted but unsigned data? In another question's answer, D.W. wrote:

  Make sure there is authenticity protection for the encrypted data (e.g., encrypt and then sign/MAC): you will need both confidentiality and authenticity protection. A very common error is to encrypt but fail to sign; this error can introduce subtle security problems

What exactly are those security problems?

A good example is the flaw on CBC, demonstrated within SSL and in particular for password recovery in a IMAP-over-SSL setup. See for details. Briefly speaking, SSL has a MAC, but a small part of it was doing things with the received encrypted data after decryption but before verifying the MAC. Namely, the receiving system was decrypting the data, checking that the padding was correct, reporting an error to the peer if that was not the case, and then only checking the MAC. The error message was different if the MAC was wrong. So the receiver (the server, in the case of the IMAPS password recovery) was leaking a single bit of information about whether the padding found after decryption was correct or not. It so happens that SSL uses a padding which is similar to the one described in PKCS#5. Details are subtle (but not mathematically hard, once you understand that XOR is commutative and associative) but it allowed the attacker, by modifying a few well-chosen bytes, to guess one by one the plain data bytes. Assuming a regular connection attempt with identical contents (typically, an Outlook Express which checks the server for new mail every 5 minutes), the attacker had 1/256 chance of guessing a new byte at each connection. At the end of the day, voila! a full password.

This case shows what may happen in the presence of active attackers and no MAC, even when the "no MAC" part is very transient; because SSL has a MAC, only it was checked too late in the process. The correction is to always check the MAC, regardless of whether the padding was good or not, and to report bad padding and bad MAC with the same error code (you have to check the MAC, because not doing it when the padding is wrong may make the server respond a bit too fast in that case, leaking the bit of information through timing). Without that correction, the server leaks some information through its behavior, be it a distinct error message or even a slight delay (or lack thereof) when responding. That's a single bit at each attempt. Yet it suffices to mount a password-recovery attack.

That attack was published in 2002. Yet, in 2010, the same bug was still present in how ASP handles encrypted cookies, allowing an active attacker to hijack a protected session in less than an hour. The attack was demonstrated as practical in 2002; in 2010, it was demonstrated as actually practiced in the field.

We do not have an exhaustive list of the attacks made possible by a lack of MAC. So the common wisdom is that there is no proper security against an active attacker when there is not a dedicated integrity check, and that's a MAC. The common mistake is to believe that in any given situation, attackers can only be passive. Wired and wireless communications are routinely subject to active attacks by even low-power bad guys (say, bored students in a cybercafe).

When doing symmetric encryption, the proper way to add a MAC is to use a combined encryption-and-MAC mode such as GCM or EAX. These are modes which rely on a block cipher (typically AES). There are other such modes, but some are patented; these two are believed not to be.

Signatures (as opposed to MAC) are an altogether distinct matter, in particular in their relationship with confidentiality.


Line Length Exception in hashcat I'm very new to cracking a password so sorry if I sound stupid.

I am trying to get my admin password from my second PC (I lost it). I did find the SAM file with kali linux and with bkhive and samdump did get the hash. I think it's a NTLM but I could be wrong (I don't now if I'm allowed to post the hash so I won't do that). I tried breaking the code with hashcat, but it gives a error (line length exception). This is the code I tried:

hashcat -m 1000 -a 0 -o cracked.txt --remove /root/Desktop/hashes.txt /usr/share/sqlmap/txt/wordlist.txt

What is wrong with it?

EDIT i get this now but is says that 0/1 is recovered and in the cracked.txt file there is nothing---->

First, an answer to the original asker's (now ancient) question.
Unlike some tools (like ophcrack), NTLM hashes need to be separated out into their LM and NTLM components for hashcat to attack them separately,
either hashes only:
$ cat lm.hashes
[lm-hash1]
[lm-hash2]

$ cat ntlm.hashes
[ntlm-hash1]
[ntlm-hash2]

... or with users (which requires using the --username hashcat parameter):
$ cat lm-users.hashes
user1:[lm-hash1]
user2:[lm-hash2]

$ cat ntlm-users.hashes
user1:[ntlm-hash1]
user2:[ntlm-hash2]

This post from Didier Stevens outlines how to use the LM cracks (case-insensitive) to then attack the case-sensitive NTLM hashes.
Second, since the number of views that this question has (3K at this writing!) is a testament to how often this error confuses people, here's a more general answer.
hashcat throws the dreaded "line-length exception" error when hashcat  receives something that it tried to interpret as a hash, but the data received is not the expected length for the requested hash type.
I phrase it in this specific way because it's important to understand that some natural activities might cause this in surprising ways. When you're working with hashcat command line, it's easy to accidentally pass it something that hashcat is expecting to be a hash, but isn't -- so much so that there is a hashcat FAQ entry for the error.
The common triggers include:

The hashes aren't the type that you think they are, so the hash length doesn't match the requested type. This is often the most common, and the first thing to check. The best way to verify is to try the same command against the corresponding example hash in the hashcat example hashes list.

The hashes have unexpected characters at the end (often whitespace).

The supplied hashes include users or salts when they aren't expected (or they don't contain those, and they are expected). For example, you might supply hashes in a "username:hash" or similar format, but hashcat can't tell if "string:string" is really "hash:salt" or something else instead (use --username if you need to work on "username:hash" hashes).

Because of a typo or mis-ordering of command-line options, you accidentally pass a non-hashes file as the first "unflagged" parameter to hashcat. This is also quite common. For example, if you accidentally forget to put -r in front of a rules file, and you haven't specified a hash file yet, hashcat will think that that first "unflagged" parameter is your target hashfile, and will try to "crack" it. (Corollary: it's a good idea to place your hashfile relatively early in your command line, before anything else that takes a file as a parameter, to reduce the chances of this)

(I saved the weirdest one for last): When you are passing a file containing a list of hashes on the command line, but the file doesn't exist. This is because of a quirk in how hashcat processes the command line. The syntax for "hashcat [literal-hash-to-crack]" and "hashcat [file-containing-hashes-to-crack"] is exactly the same. This means that if you pass a file but it doesn't exist, hashcat says to itself "hmm, that thing they asked to crack wasn't a file, maybe they're trying to specify a hash directly?". Since the filename is almost never the same length as the hashes of the target hash type, you'll get the "this is the wrong length" error when what it really means is "the file doesn't exist".

So as long as you interpret the error as "there is something wrong with my input", and you investigate each of these possibilities, you should be able to resolve any "line-length exception" errors.


How to analyze .pcap file to write a generic snort rule to detect c&c activity I am diving into snort and trying to figure out what everything does but I'm having a little trouble. I have a .pcap file I want to analyse and I know there is malicious c&c traffic on it. (Practice exercise for an online course)

The goal of the exercise is to write a snort rule(s) that is not restricted by IP address or port number (source or destination) to detect the c&c traffic.

What should I be looking for in the .pcap file to base my rules off of? (if possible please provide plenty of details in this area) Are there any specific options I should almost always include in my snort rule and why? I also want to try to mitigate false positives as well because the file is rather large and there are only a handful of malicious connections in it.

Step #1 is to identify and isolate the malicious traffic in the pcap. I assume you're using Wireshark to do this?

Step #2 Look at the isolated malicious stream and try to identify unique patterns. This could be unusual header sequences, words or strings, or query response sequences.

Step #3 Create your signature for Snort from the identified patterns. It could be a single contiguous hex pattern, or a more complex set of multiple dispersed patterns that must all exist and/or be within designated distances from each other.

The more complex the signature the less likely there will be false positives, too complex and it might be overly specific to your sample and you get false negatives.


Are images in the FROM name a risk in emails? I know about images posing a risk to security. I don't open suspicious junk emails for this reason. However, occasionally I have to check my junk email folder without clicking on an email just in case anything mistakenly went in there. I am seeing a growing number of junk emails have images in the FROM name before opening an email, such as the below screenshot.

As you can see there is a picture of a present at each side of the FROM name. I don't think these are a setting I can see when sending an email, so how are spammers getting images to show? Could such images contain tracking pixels, drive-by downloads or steganographic code?

The pictograms you are seeing in the name portion are Unicode emojis. They can be used anywhere there is an updated version of Unicode. To see a full list of the supported emojis for each version of Unicode, look here. You can copy and paste them just about anywhere, and they will display.
These do not contain tracking, they are loaded from your system locally. However, if they are embedded as an image within the body of the email, that is a different story.


Is mt_rand() suitable for generating a salt? Assumed I have to following code in order to generate a random blowfish salt for saving a new password:

$blowfishCharacters = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789./';
$salt = '';
$type = '2a';
$cost = '08';

$maxIndex = strlen($blowfishCharacters) - 1;

for ($i = 0; $i < 22; $i++) {
        $salt .= $blowfishCharacters[mt_rand(0, $maxIndex)];
}

$salt = '$' . $type . '$' . $cost . '$' . $salt;
$pass = crypt($password, $salt);

I read several discussions about this topic, but they all came to different results. mt_rand always seems to be better, but is it suitable for this purpose?

Under most conditions, a salt needs only to be unique, not cryptographically unpredictable.

So in that case, yes as long as your RNG is properly seeded. Another common technique to improve salt quality is to concatenate a random number to the current time, then hash that (e.g. SHA1), textually encode (e.g. base64), and take the first N characters. The chances of a collision there are pretty slim.

Edit to explain
Here's an explanation of what's in this techique and why:

The current time prevents repitition. As long as two salts aren't generated at the same time, they won't be the same
The random number prevents predictability. You can't know the salt ahead of time because there's an element of randomness. This obviously assumes that the random number isn't readily predictable and isn't based on the current time. More importantly, it also helps prevent collisions if two salts happen to be generated at the same time.
The hash smooths out the distribution so each bit has an equal chance of being set. It also prevents you from knowing what went in to generating the salt just by looking at the result.
You can also concatenate a secret string to the input of your hash if you're paranoid about people predicting salt values. You shouldn't have a reason to care, though.


Java vulnerability: What about OpenJDK + IcedTea? These days there is a lot of recommendations about disabling java-plugin due to a serious vulnerability. I know this topic has already been covered on this site here and here.

In the reports about the vulnerability I have read so far, they refer either to just generic Java or Oracle Java. I am asking this question since many computers in our company are running OpenJDK + IcedTea Java Plugin.

So, the question is this one:

Does anyone know if the java plugin from OpenJDK is also affected by this vulnerability?

Java 7 and OpenJDK share a lot of common code, so, as a general rule, security issues in Java 7 also apply to OpenJDK. In that specific case, it seems that the vulnerability was reported in the Debian OpenJDK package, so yes, they are vulnerable. See this question on another stackexchange site. Since Oracle seems to have fixed their JDK, chances are that the same fix will appear in OpenJDK in a few hours or days.

On the bright side, if you use OpenJDK and IcedTea, then chances are that you use Linux. Malware authors rarely target Linux systems, because there are not that many people who browse the Web from a Linux machine, and there are a lot of different "Linux systems" which make it difficult to write a piece of binary code (such as malware) which will run on most of them (the Linux ecosystem relies on source code distribution and per-distribution packaging, rather than real binary compatibility). Therefore, malware authors usually deem Linux "not worth the effort". This goes a long way towards explaining the scarcity of malware on Linux.

My gut feeling is that the fix will be available on the normal update channels way before any Linux machine is actually attacked in the wild (but you do not have to trust my guts -- personally, I don't).


Can a user's Apple Keychain be opened on a different computer? Apple uses a nice keychain.  This is used by, for example, Google's Chrome browser.

Imagine a user copies all the keychain files.

Would that user be able to unlock the keychain, if they knew the master password, on a different Mac computer running the same version of OS X?

Does any software exist to allow a user (who remembers their master password) to open the keychain on Windows or Linux?

Have any vendors attempted brute force or dictionary attacks?  (I checked Elcomsoft, and they don't appear to have a Mac Keychain product yet.)  I understand that these attacks are unlikely to be successful if the user has chosen a good password, but I also know that most people do not chose good passwords.

It is possible to open the keychain file provided that you have the password associated with it (usually, but not always the user's login password).

I have personally done this when backing up and performing a manual upgrade of my personal system, although I do not know where any software is available to open the file out of Mac OS.


Hiding IPs in a public WiFi network by ISP I logged in to a public WiFi network (Provided by one one of the leading ISPs @ Oz) and tried to run a nmap and do a network discovery(Not to do any harmful activity but just because of curiosity).

But the results shows only my IP and the Gateway IP. How this security measure is implemented ? How they hide others from me ?

http://www.howtogeek.com/179089/lock-down-your-wi-fi-network-with-your-routers-wireless-isolation-option/

  [Client isolation] confines and restricts clients connected to the Wi-Fi network. They can’t interact with devices connected to the more secure wired network, nor can they communicate with each other. They can only access the Internet.

Indeed, this is either AP isolation, or an IPS-like function in the router. My cheap  Sitecom router has a function labeled 'Block NMap scan' and it does about the same thing, depending on what scanmode i use.

However this is not done by the ISP :)

With NMap, if you're scanning the devices there, seeing just the gateway, you interrogate the LAN (local area). The ISP will usually not have a clou this is happening.
If you were scanning external devices, say, a website, this would go over WAN (wide area), this is something the ISP could see and possibly influence.


Is it normal for auditors to require all company passwords? My company is currently engaged in a security audit framed as a pentest. They've requested all admin passwords for every one of our services and all source code of our software. They want logins for Google Apps, credit card processors, GitHub, DigitalOcean, SSH credentials, database  access, and much more. Note, we've never signed a single NDA (but have been provided a statement of work) and I'm very reluctant to provide this info to them because of this.

Is this normal for a pentest? I assumed it would mostly be black box. How should I proceed?

"UPDATE*  We now have an NDA. The contract does, however, say that we can't hold them liable for anything. Still not sure if this is the right move to continue with them. In my experience, their requests aren't normal even in white box audits, and their statement of work reads in a way that doesn't make it clear if this is a white box or black box audit.

Is this normal for a pentest?

Absolutely not.  Best case scenario: they are performing "social engineering" penetration testing and want to see if you can be pressured into fulfilling a very dangerous action.  Middle-case scenario, they don't know how to do their job.  Worst-case scenario they are only pretending to be an auditing company and fulfilling their request will result in an expensive breach.

In the case of a code-audit the company will obviously need access to source code.  However I would expect a company who provides such services to already understand the sensitivity of such a need and have lots of forms for you to sign, and to offer to work in a strictly controlled environment.  A reputable security company is going to be concerned not just with protecting you (because it is their job) but also with protecting themselves from untrustworthy clients (Our source code got leaked right after we hired you: we're suing!!!!).  All this to say: any reputable security company that doesn't have you sign lots of contracts before going to work is not a reputable security company.

I can't imagine any circumstances in which handing over access to any of those things would be a good idea.

Edit RE: hidden contracts

A few have suggested that the company might have simply not told the OP about any relevant contracts/agreements/NDAs.  I suppose this is possible, but I want to clarify that the lack of a contract isn't the only red flag that I see.

As someone who has built e-commerce sites and business software that has required integration with many CC Processors, I see absolutely no benefit to giving someone else access to your CC Processor.  At that point in time they are no longer penetration testing your systems: they are penetration testing someone else's systems that you happen to use.  Indeed, giving out access credentials in such a way likely violates the terms of service that you signed when you started using your CC Processor (not to mention the other systems they are requesting access to).  So unless you have permission from your CC Processor to hand your credentials to a security auditing company (hint: they would never give you permission), giving them that access is a huge liability.

Many others here have done a great job articulating the differences between white-box and black-box testing.  It is certainly true that the more access you give security auditors, the more effectively they can do their jobs.  However, increased access comes with increases costs: both because they charge more for a more thorough vetting, and also increased costs in terms of increased liability and increased trust you have to extend to this company and their employees.  You are talking about freely giving them complete control over all of your companies systems.  I can't imagine any circumstances under which I would agree to that.


Facebook allows password + any character A few days ago, I was surprised to see that an old password of mine was working again. The present password is the old password truncated by one.

Passwords appended by any single character are now valid. Apparently, FB passwords aren't case sensitive either.

Do you think this poses a security risk?

Yes, this would pose a security risk, though it would probably be regarded as a very low risk. It is worth noting that Facebook still implements other password policies such as access to email, security questions, server side authentication mechanisms and other various things. That being said, it does still pose a risk. Often times when software companies store old accounts, and have their password policies continuously updated over time to match current security standards. If the companies are storing accounts that can be used for retrieval at a later date, the old accounts may not be up-to-date with current password policy recommendations. This is surprisingly not too unusual.

As well, Facebook implements 'features' like these to increase user experience. See: http://www.zdnet.com/article/facebook-passwords-are-not-case-sensitive-update/

The security risk still present is because it would open up a small attack vector that would allow an attacker to access an account faster than they could if policies aforementioned are not factored in. For example, if your password 5 years ago on Facebook was "Password10", and this account came back to life and did not require an update to the account before accessing the content, it would be easier to access an account by means of brute-force and others. As previously stated, the risk is very low compared to modern security policies such as lockouts, etc. Though, some security auditing companies and automated scanners might say that it is a low risk.


Bypassing file upload restrictions on php server I am conducting a penetration test on a website and am trying to prove that php code can be executed with the file upload. The website allows for file uploads but it checks for:

1: Filetype

2: Extension (Only jpeg or png)

3: File size (Max 2MB).

So, it is possible to upload a file (test.php.png), I therefore thought that adding in PHP code inside the Exif data would run but it does not, why is this?

To execute injected php code it should be possible to call targeted file directly and its extension must be in the list that server may handle for. By default it is *.php
It is possible to include any file into other php script on the server in case LFI vulnerability is exploitable in the code.


What security considerations apply to a blockchain implementation for private use? I want to know that if a company wants to implement a model of blockchain, let's say for internal transactions across its offices in different countries, what are the main and important security considerations?

I know that a centralized consensus server needs to be secure, code should be free of vulnerabilities, digital signatures and algorithms used should be secure etc.

I'm more interested in high level security considerations. What security controls should be in place.

Right now for your use case, I can only think of three.

First security consideration is, is the data you plan to put in the ledger sensitive? If yes, you may need extra steps to protect what you put in the ledger. By default, the data you write is not encrypted, and is readable by everyone. There's no built in functionality of user roles and access controls in blockchain. Everyone has the ledger, everyone can read it. Nevertheless, roles and access controls can always be added at application layer.

Second, in relation to the first consideration, you need to protect all participants from unauthorised access. Since you plan to use blockchain for internal company use, I would assume that outsiders are not supposed to have access to your ledger. Using blockchain can potentially increase your attack surface, wherein every participant is equally desirable as a target since they all have the ledger and potential to participate in the blockchain.

Third, blockchain is supposedly incorruptible through consensus, meaning it should be nearly impossible to forge or tamper an entry by any means. If your nodes are quite small, you may not get this benefit, and could make it possible to tamper or forge through collusion. This can easily be remedied by ensuring there is a large number of participants, but could in turn potentially reinforce the second consideration.

These are quite generic, since the case you provided is quite generic as well. Security controls would depend on which of these are applicable to you. Hope this helps.


John the ripper does not crack password I'd like to attack a self-created sha256 hash with john --wordlist=

So far I've done the following:

$ echo 'testpassword' | sha256sum > mypassword

removed the tail of the output with vim

$ cat mypassword
dc460da4ad72c482231e28e688e01f2778a88ce31a08826899d54ef7183998b5

penetrate with john

$ john --wordlist=list.txt --format=raw-sha256 mypassword

result:

Using default input encoding: UTF-8
Loaded 1 password hash (Raw-SHA256 [SHA256 128/128 SSE2 4x])
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:00:06 DONE (2017-01-06 12:47) 0g/s 2347Kp/s 2347Kc/s 2347KC/s
Session completed

show

$ john --show mypassword
0 password hashes cracked, 1 left

What did I do wrong? Is raw-sha256 not the right format? The test password is definitely in the wordlist.

Your string has an unintended line break at the end. Use -n to omit the trailing newline character:

echo -n 'testpassword' | sha256sum > mypassword

Otherwise you end up with a different hash:

$ echo testpassword | sha256sum
e0d7d338cb1259086d775c964fba50b2a84244ba4cd2815e9f6f4a8d9daaa656  -
$ echo -n testpassword | sha256sum
9f735e0df9a1ddc702bf0a1a7b83033f9f7153a00c29de82cedadc9957289b05  -

Then just proceed as you did.
Demo:

$ echo -n "abc123" | sha256sum | cut -f 1 -d " " > password
$ john --format=raw-sha256 password
$ john --show password
?:abc123

1 password hash cracked, 0 left

(I used cut to remove the hyphen after the hash.)


Python hazmat danger Is hazmat considered to be secure?

Here is a quote from their docs:

  This is a “Hazardous Materials” module. You should ONLY use it if you’re 100% absolutely sure that you know what you’re doing because this module is full of land mines, dragons, and dinosaurs with laser guns.

This is confusing, since there is no further explanation on that. If this statement refers to IT-security, then it's interesting that even google is using this.

The documentation you cite means only that the "average" user which has no deeper understanding of cryptography should only use the higher level cryptographic functionality. The cryptographic primitives should only be used by somebody with a deeper understanding of cryptography. Without such understanding it is easy to make serious mistakes leading to insecure software and don't even realize that these are mistakes.


Is a keyboard with updatable firmware a security risk? I am looking to buying a small mechanical keyboard for on the go and to use it with various office computers. The ones I like are the Ducky Mini and KBParadise V60. The former has a ARM Cortex-M3 processor embedded which can even receive firmware updates. I have not found anything on the latter.

With the Bad USB issues in mind where USB Sticks can receive a bad firmware that does malicious things with the data, I am a little cautious. The Ducky Mini is probably updated using some Windows tool and I have not read anything about having to about security.

It seems to me that anyone could write an “update” for this keyboard and turn it into a keylogger. Is any keyboard with sufficient processor a security risk? Would an employer be unhappy if I bring that keyboard to work?

On the other hand, are normal keyboards simple enough to prevent such an attack? If I buy the other one, can I feel on the safe side?

The important question is: where has the keyboard been ?

Basically, if the keyboard is new and fresh from the factory, then it is about as safe as such things can be. If such a keyboard has been infected with a keylogger, then it was done in the factory and you cannot realistically prevent such a thing anyway. It is up to you to not allow infection to occur afterwards; i.e., don't plug your keyboard in unknown computers.

If the keyboard has been used elsewhere by potentially malicious people, then tough luck. I would advise against buying a second-hand keyboard.


What is the difference between PEM format to DSA/RSA/ECC? (Might I confuse PEM with these)? When one creates an ECC SSH key for example, this command can be used:

ssh-keygen -o -a 100 -t ed25519

As I understand, the -o argument is used to generate:

  The private keys using a newer format opposed to the more commonly
  accepted PEM

Are these "newer formats" DSA/RSA/ECC or might it be PPK vs PEM? Sorry if I confuse SSH key formats with private SSH keys' file extensions; I wish to ask of the main difference between PEM to the "newer formats" mentioned in the quote.

First off, here's the full man page entry for ssh-keygen -o from my machine (ssh-keygen doesn't seem to have a version flag, but the man page is from February 17, 2016)

  -o      Causes ssh-keygen to save private keys using the new OpenSSH format rather than the more compatible PEM format.  The new format has increased resistance to brute-force password cracking but is not supported by versions of OpenSSH prior to 6.5.  Ed25519 keys always use the new private key format.

Seems pretty clear that this is just about the format of the file that's being produced. Also note that ssh-keygen will only store Ed25519 keys in the new format, regardless of what flags you pass in.

Since both of your questions today have had the same underlying question, let's deal with it.

  ... these "newer formats" DSA/RSA/ECC ...

Ok, so DSA, RSA, and ECC are not different formats, they are completely different algorithms and are completely unrelated to each other.

I wish I could find a better way of explaining this, but I'm not sure I can without getting too technical. Let's try this: it's a bit like saying that http and ftp are just different formats for transferring files, or .docx and .pptx are different formats of Office documents. Calling these "just format differences" is fundamentally wrong, the software is doing a very different thing in the two cases (albeit to produce the same end-result; transferring a file, or making a pretty document).

Now let's talk about formats.

So you want to save a private key in a file? PEM is a file format for storing general cryptgraphic information, but other file formats exist. PEM can be used for many things: private keys, or certificates, or the text of an email that you want to encrypt or sign. It's just a container "cryptographic stuff".

Analogy time: saving a Word document. You could save it in the old .doc format which is universally accepted by all versions of Office and also open source programs (PEM is also older and universally accepted), or you could use the newer .docx format (the -o OpenSSH format). Sometimes new features are not backwards compatible and can only be saved in the new format (like ed25519).

(Many thanks to @GordonDavisson for this analogy)

With the exception of backwards compatibility, which format you choose really has nothing to do with the contents of the file.

Examples:

PEM format with an RSA key.

Note that the message starts with -----BEGIN RSA PRIVATE KEY-----, this is standard industry-wide PEM format - any software that can read PEM will be able to read this:

$ ssh-keygen -a 100 -t rsa
$ cat .ssh/id_rsa
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAwTLkTDZUisg0M/3BDBOjrmBvJXb8cdfveGG1KQhAhFDLMp5w
XKgGFMy339m3TGB1+ekKoXnX3dcRQtpQbuFeDB59cmKpDGZz7BzfetpjeIOGCzG+
Vt2BnDf2OlKb6EE7tC3PSmFgL0nQPSyz8x7rE7CMOQEnz1tKkK9Gpttcku8ifwmd
LAHlVaTV3BIiFJN23fwe7l0czFaV98iy8YRgk/Av3gRlsBABGT5qD8wPiI4Ygpxv
UuT2kq53lhBTWO9hIth5tUU0N7x7QN6/rRSi2uHcmJYXFkpsLie697G17TN5ln3E
X5frsrjVyu0JhjvC5mlRBudSJWcWm/KrcTQxdQIDAQABAoIBAFR6nWtZ4nPhATqu
veg6+jq4vkEim1ZodrUr/FxZ2GRDM+cJctaBPk+ACPMgL099ankB1v0u2x6M+WZD
MiKZ91bTSkVnMMZUUmIvaeU9c3tx/34LnVA8gX0+1zM/hh7zz1iFI3xBwh5LZ3wo
fPNVVLOCYn5WrAK2x48mpX02tG8m0OY5kdCdFW1f6UbCGk3K9ov82yQ+JbjWydOS
ZaS7bnJCRsjDhPm/Ooe2DZ8CKHRO3DOiZAAFYqsosxM2C12+alC+hdKHoJ0pWZWe
eckZiALTENi+PzgSq4ykdBaoreeI84lpIzYQO06rrjM2/fw1x/SQsDYhCsQnNRib
sipl2mECgYEA74rBQDIEWaIVVZ72foeZYOMmAUKCLQtNxVuGl/XoMZO3evN2vbOv
Nw/nn5lVt6PRykVUUl6yb5gHvRSGtGJSB1q6pBVN1EF2sfvUep6mmpEwbSbENiAX
IftE0ap7PKT1aLKbLllwdsJlLCRMJIk07AvsulbkhSC+UmJVkfjblgkCgYEAznkE
fzmWS358MLxb0JM+4v1DO/1ne8z29ddHNppxSNj2Xjf+MMvOY4KaRQa8dMwc3Eqa
1EvPqnK6ila4L08Ai4CyWoGkkkIQBO9jO3mLp24xk6TRo002DbfJRnu4qW4zeryp
gYeFfBzwhc/IQKjXhv8AAfEUFCSYiFaWBsENuw0CgYEAwmyDyCAQqdPFrzYT6cUT
t7EGYtVhpT/cgshz6Rk9uiekL9Y2VWjnWTC+liq1iRUdLSiydRzJhYwHE+/6GaUH
4VJB1PY5soLj3TiCUHg+z4vym1VwwmGvhPRV+jt+RU26ppz5GVic0LeduINJjgoT
e1d+cAwg9PELqQCJZa5wREkCgYBPEuPZAaoAsalIVOro32uHLS1xrSPTsvSlxFO+
orleB9Ga1eDguT0KuTrx0pmcNYucBmpzgbE/ev7b+khBvgTcaGZl6R6o8OoHqdKc
NXl5nucXv1iWLPzVlhxchQd8w/qtN9HHDKrflIm9BY2Qzdj1F3XeSIDDEhzkohyE
66yhhQKBgGh9knh8SxnVxaPk0Rk/bQope9AwIDuIpfsf4KC/EPSZmMNHP8xBh8al
eymUot7Pj6dck31V4C3q74NKobY3p6fZ5t7tP9K6Br+J/FQFhvAdFAwpTD2Bks5H
fhZO5cniPpydb0YvOnoaVnb0nzXVsf1jIgPKfsCsZxoyE0jLb9oV
-----END RSA PRIVATE KEY-----

OpenSSH format with an ed25519 key:

In addition to it being shorter (because ECC keys just are that much shorter) notice that the message starts with ----BEGIN OPENSSH PRIVATE KEY-----, this is in OpenSSH-specific format that other software may or may not be able to read:

$ ssh-keygen -o -a 100 -t ed25519
$ cat .ssh/id_ed25519.o
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACC7gIlwBMp+H6VVNZSHI0in2iCU/yi67WfeFPfuyAdkBAAAAJh7nk7je55O
4wAAAAtzc2gtZWQyNTUxOQAAACC7gIlwBMp+H6VVNZSHI0in2iCU/yi67WfeFPfuyAdkBA
AAAEBHl+qBAosBAUIGuvdDR8gJN/PEhempLe4NtyKiO7hCPLuAiXAEyn4fpVU1lIcjSKfa
IJT/KLrtZ94U9+7IB2QEAAAAEm1pa2VATWlrZS1zYW1zdW5nMQECAw==
-----END OPENSSH PRIVATE KEY-----


How are stack canaries padded by unmapped pages? I was reading the wikipedia article on this subject and it states that when a program starts, the canary is calculated at random, stored in a local variable(which I presume was introduced by the compiler) and is  padded by unmapped pages but i'm  having problems understanding what that actually means. Is it that this global variable is mapped to a different page than that of the program and therefore has different access flags? If not then why can't  an attacker sneak a peek at this value?

It would be clear to say that the reference copy of the canary value is surrounded by unmapped pages. That is, the page containing the canary value has at least one unmapped page immediately before it and one unmapped page immediately after. The goal is to make it unlikely that an attacker can read or modify this value. To reach this value, an attacker needs to find a vulnerability that allows reads or writes at an arbitrary address. A buffer overflow or underflow can't reach the canary value because it would first access one of these unmapped pages and crash the program.


ssh tunneling /port forwarding/access different subnet Hi I need some good pointer  or any recommendation any docs about this below stated scenario.
During in my recent pentesting :
 My ip is 192.168.x.1(kali)
By some how I managed to get root shell on some  unix system with ip 192.168.x.21.
Now when I ifconfig in this 21 system i get eth0 & lo ,eth0 with 10.1.1.34 .
After some enumeration I found this subnet 10.1.1.X there is also some systems  behind the firewall,not directly connect from public. Now i need to test on this system to. Since my all tools are in kali, i need to connect this other system in that 10.1.1.X . I a unable to do this. Please help me to sort out this problem.

You can use Meterpreter for pivoting. There's a good tutorial described in Metasploit Unleashed.

meterpreter > ipconfig

Citrix XenServer PV Ethernet Adapter #2 - Packet Scheduler Miniport
Hardware MAC: d2:d6:70:fa:de:65
IP Address  : 10.1.13.3
Netmask     : 255.255.255.0

MS TCP Loopback interface
Hardware MAC: 00:00:00:00:00:00
IP Address  : 127.0.0.1
Netmask     : 255.0.0.0

Citrix XenServer PV Ethernet Adapter - Packet Scheduler Miniport
Hardware MAC: c6:ce:4e:d9:c9:6e
IP Address  : 192.168.1.201
Netmask     : 255.255.255.0

meterpreter > run autoroute -h
[*] Usage:   run autoroute [-r] -s subnet -n netmask
[*] Examples:
[*]   run autoroute -s 10.1.1.0 -n 255.255.255.0  # Add a route to 10.10.10.1/255.255.255.0
[*]   run autoroute -s 10.10.10.1                 # Netmask defaults to 255.255.255.0
[*]   run autoroute -s 10.10.10.1/24              # CIDR notation is also okay
[*]   run autoroute -p                            # Print active routing table
[*]   run autoroute -d -s 10.10.10.1              # Deletes the 10.10.10.1/255.255.255.0 route
[*] Use the "route" and "ipconfig" Meterpreter commands to learn about available routes
meterpreter > run autoroute -s 10.1.13.0/24
[*] Adding a route to 10.1.13.0/255.255.255.0...
[+] Added route to 10.1.13.0/255.255.255.0 via 192.168.1.201
[*] Use the -p option to list all active routes
meterpreter > run autoroute -p

Active Routing Table
====================

   Subnet             Netmask            Gateway
   ------             -------            -------
   10.1.13.0          255.255.255.0      Session 1


Danger of default router password How bad is it to not change the default home router password? Are there any concrete dangers?

Are there any attacks directly resulting out of the use of default passwords, not vulnerabilities in the firmware?[*]

You can assume that anyone legitimately connected to the router is allowed to access and change it's configuration [**].

[*] I found this vulnerability, but it seems to be a vulnerability in the router firmware (which could be prevented using anti-csrf tokens), not a direct result of using a default password.

[**] So I'm not worried about other residents or visitors that are allowed access to the network.

The wireless router is the gateway to your entire home network, from a wireless baby monitor, to the secure computers you do your banking on. Controlling this gateway gives an attacker access to the devices inside the network and to data that passes through it.

It's no surprise that home routers are a new frontier for the criminal underground and default passwords is one of the main vectors of attack. In 2011 and 2012 attackers exploited a vulnerability to change the DNS settings of more than 4.5 million DSL modems in Brazil. In March 2014 Team Cymru reported that over 300,000 home routers had been compromised and had their DNS settings changed in a global attack campaign. In September 2014, again there was a large scale attack on Brazilian routers.

Most of these attacks involved two vulnerabilities, a CSRF (Cross-Site Request Forgery) that is present in many brands of routers and default passwords. This means that visiting a malicious website will force your web browser to log into your home router and make configurations changes. This article describes a similar attack and its severe consequences.

It all started in 2007 when this attack was published. The main condition for the attack to be successful was that the attacker to guess the router password, because back then, even Cisco had 77 routers vulnerable to CSRF.

And the problem of default passwords is still real in 2014:

  Tripwire spoke to 653 IT and security professionals, and 1009 remote workers in the US and UK –
  with alarming results. Thirty percent of IT professionals and 46% of
  workers polled do not even change the default password on their
  wireless routers. Even more (55% and 85%, respectively) do not change
  the default IP address on their routers (making cross-site request
  forgery – CSRF – attacks much easier).
  (Source)

The dangers of having the internet facing admin panel with default passwords should obvious. But an open network with the admin panel open to the local network is vulnerable to local attacks. Wardriving with good antennas can cover large areas and spot many vulnerable routers.

Once it has access, an attacker can change DNS settings and intercept data for serving malware, ads or phishing. Or it can open up the internal network and attack some old unpatched Android phones, and maybe hope that one of those devices will travel and be an entry point to a different, higher value network.

Also, routers most likely store credentials for connecting to the ISP, which can be reused or abused by the attacker. I've heard of wireless routers that had one open network for guests and one password protected network. Connecting to the open network and accessing the admin panel with default credentials allowed access to the router configuration file that had the WPA key for the password protected network.

While some users are ignorant about security, there are router manufacturers that aren't ignorant about their users' security and provide unique admin passwords for each router. Most passwords are printed on the permanent sticker along the other details such as model and MAC address. This is not as secure as my recently purchased router, which had the password printed on a card and which required changing it on first use.

As Malavos mentioned in the comments, there are ISPs that lease routers with default password and even some that forbid changing those defaults passwords. I'm adding that some ISPs will change the default passwords and use it to configure the router remotely, but they will set the same password for all their clients' routers. This is problematic because that password can be recovered through hardware hacking so every router with that password can be compromised, even remotely.

Main rules for protecting wireless routers:

Update router firmware
Turn off unneeded services
Set strong admin passwords


How do I use Windows 7 virtualization features to prevent transitive trust of admin credentials? I am exploring using VMs to separate my administrative actions from standard user  actions in Windows 7.  The goal is to limit my risk and exposure when using "RunAs" to open an application or file share and separate that from any other application or file that may be on my machine.

  What is the technical process to get Windows 7 into this configuration?

It seems to me that if I can load my administrative tools onto one VM, my Office and development applications into a second VM, then I can boot into either as needed.  If I need temporary access to one environment from the other, I can simply boot up the corresponding VM and multitask all while knowing that my environments are separated.

I want to prevent the "transitive trust" that forms when I RunAs to access a file share for example, and then a malicious website infects that drive.

I am also not entirely sure I understand - so let me offer some possible solutions:

Use three separate virtual machines as described here by a rather famous security researcher. Essentially - each virtual machine is a totally separate environment, ideally speaking as if you had three separate computers. In order to effect this, you'll need a virtualisation solution of some form (virtualbox, vmware etc).
Use different accounts and don't use RunAs. You risk data leakage this way but it's a lot easier than spinning up the required virtual machine.
Use RunAs and accept the risk.
Do not use RunAs.

I should briefly talk about those virtualisation features. Those features are provided to enable XP-mode to work through Microsoft's VirtualPC.

Clearly, do not use RunAs is not acceptable and using three VMs might be a bit painful, as is constantly logging out as in 2. There might be a way you can make this work for three:

In terms of current administrator accounts, what actually happens is that your ability to act as an administrator is curtailed by privilege levels. Three components come into play - UIPI, Mandatory Integrity Control and separate desktops via CreateDesktop. How they interact is complicated:

MIC says each process is either High, Medium or Low Security. I think it also includes a DRM level - and I know it also includes a System level. In either case, the idea is that a Medium object cannot meddle with a High object. See here and here. Likewise a High object cannot read a medium object - this is no write up/no read down in action.
UIPI says that only certain messages can be sent from Low to Medium and Medium to High processes. The whole GUI model resolves around sending messages; if hardware generates a event, that's a message in your message processing routine (usually called WndProc).
CreateDesktop creates a whole new blank desktop. Sysinternal's rootkitrevealer does this, as does KeePass, as does consent.exe, your UAC dialog process.

What makes consent.exe secure is the combination - not only is the process run as NT AUTHORITY\SYSTEM (which ordinarily would not be a barrier to an Administrator user) but it also runs on a separate desktop (it takes a screenshot of the current desktop and grays it out to achieve that effect I believe) and it runs as a HIGH privilege level, meaning not only can medium/other processes not get to it if run as an Administrator, but the desktop is unique and there's nothing else on it to send messages to it.

So, you could use the mandatory integrity controls to isolate some of your processes. One drawback is that you can't easily use the CreateDesktop mechanism yourself - it's a programming instruction. You can however combine MIC with separate accounts on a single desktop. You might like to read some thoughts on that by the previously-mentioned famous security researcher. With a bit of experimentation you might be able to adapt this to your needs.


Certificate transparency: should the certificate be submitted to ct-logs if the pre-certificate is already submitted If a pre-certificate is generated and submitted to certificate transparency logs, the final certificate can include SCT receipts.

So the final certificate doesn't need to be submitted to ct-logs in order to be valid in browsers were ct is mandatory.

Advantages:

it give public confirmation that the certificate was indeed issued (and not only the pre-certificate)

Drawbacks:

it double the size of the ct-log

My question is, is there any other advantage or drawback to submit the final certificate? Or any requirement to do so? Or advice against it?

Link: https://community.letsencrypt.org/t/sct-feature-support/58101/8

it gives public confirmation that the certificate
  was indeed issued (and not only the pre-certificate)

To quote RFC6962bis (draft-ietf-trans-rfc6962-bis-28), section 3.2:

"signature" MUST be from the same (root or intermediate) CA
that will ultimately issue the certificate.  This signature
indicates the CA's intent to issue the certificate.  This
intent is considered binding (i.e., misissuance of the
precertificate is considered equivalent to misissuance of the
corresponding certificate).

Essentially, what that means is that if a precertificate in a CT log is present, then in any sense related to certificate transparency the final certificate was, indeed, issued.

Further operational details (e.g. was the certificate issued then, was the issued certificate then sent to the customer or not, has the customer received the certificate, have they deployed it, etc.) fall out of scope of the certificate transparency framework.

(It is also understood, I believe, that in case the certificate has been actually issued, and not only issued but has been actually obtained by the customer of the certificate authority, then the customer — usually referred to as a "server operator" in CT-related documents — may submit the final certificate theirselves if they have such a policy.)

Hence, there are no advantages left. Yet, the drawback you've mentioned still persists. So, the final score is 0:1 against submitting final certificates.


GET vs POST, which is more secure? I have heard of programatically difference b/w GET and POST in web applications. Asking in curiosity which is more secure, GET method or POST method in web applications, I expect answers in terms of protocols too (i.e in http and https)?

POST is more secure than GET for a couple of reasons.

GET parameters are passed via URL. This means that parameters are stored in server logs, and browser history. When using GET, it makes it very easy to alter the data being submitted the the server as well, as it is right there in the address bar to play with.

The problem when comparing security between the two is that POST may deter the casual user, but will do nothing to stop someone with malicious intent. It is very easy to fake POST requests, and shouldn't be trusted outright.

The biggest security issue with GET is not malicious intent of the end-user, but by a third party sending a link to the end-user. I cannot email you a link that will force a POST request, but I most certainly can send you a link with a malicious GET request. I.E:

Click Here for the best free movies!

Edit:

I just wanted to mention that you should probably use POST for most of your data. You would only want to use GET for parameters that should be shared with others, i.e: /viewprofile.php?id=1234, /googlemaps.php?lat=xxxxxxx&lon=xxxxxxx