Can Inverse TCP Flag Scan be run as a stealth scan?

The Inverse TCP flag scan executes as follows.

Attackers send TCP probe packets with a TCP flag (FIN, URG, PSH) set, or with no flags.

When the port is open, the attacker doesn't get any response from the host, whereas when the port is closed, he or she receives the RST from the target host.

When Port is Open

 Attacker--------- (FIN/URG/PSH/NULL) ------------------ >  Victim
                       X < -------- No Response --------

When Port is Closed

Attacker--------- (FIN/URG/PSH/NULL) ------------------ >  Victim
      < -------------- RST / ACK ----------------------

Security mechanisms such as firewalls and IDS detect the SYN packets sent to the sensitive ports of the targeted hosts. But  the probe packets enabled with TCP flags can pass through filters undetected, depending on the security mechanisms installed. Inverted Technique is probing a target using a half-open SYN flag because the closed ports can only send the response back.

Advantages

Avoids many IDS and logging systems, highly stealthy

Disadvantages

Needs raw access to network sockets, thus requiring super-user
privileges
Mostly effective against hosts using a BSD-derived TCP/IP stack (not
effective against Microsoft Windows hosts, in particular)

Inverse TCP flag scanning is known as FIN, URG, PSH scanning based on the flag set in the probe packet. If there is no flag set, it is known as null scanning.


Can my internet provider/government/anyone track or see what I follow on Tumblr?

Without a VPN

Assuming that you are only using HTTPS, there will likely be a difference between your ISP and a government. This also depends on where in the world you are.

In many countries your ISP couldn't care less about what you do. In some countries though, governments make the ISP care - sadly, the UK is now one of those places.

An ISP will only have access to a log of the URL's you access so whether an ISP could track what you are following will depend on how you interact with Tumblr to follow someone.

A government, on the other hand, will probably find a way to do whatever they want if they consider it important enough.

So given that Tumblr is a public service and so subject to public scrutiny for its content and unless you live in a country with highly restrictive laws or you might be subject to professional blackmail (e.g. you are a teacher but show a liking for unpleasant subjects) and have a history of being in vocal opposition to your government, the risks would seem to be very low that anyone would really care.

With a VPN

Your ISP can no longer track you at all.

Once again though, a determined government attacker is likely to be able to eventually track you. The easiest way to do that would probably be to bug your house.

Again, the risk is generally so small as to be insignificant unless you fall into the categories outlined above.


As Chris already mentioned, an exploit could be run against the RDP server, or another gained access via another service (Telnet, SSH, Apache Server, etc...). Whether this was via a zero-day exploit or a brute force attack, is another matter.

Two exploits come to mind though, CVE-2008-4250 and CVE-2012-0002. However, without logs, I cannot know for certain. Furthermore, my answer is restricted to remote access attack vectors. Physical attack vectors have not been considered.


I'd go with the first system, there's no significant difference from the AES one; but still you need to consider other, possibly unrelated factors.

UPDATE: on second thoughts, you might want to use PKDBF2 as a "hash", in order to mitigate the chances of a successful bruteforcing.

Brute force attack

If the suffixes are known, or in general there is a known mapping between user ID and hash, then an attacker could simply enumerate all possible IDs.

For example, the attacker knows that IDs start at 1 and are at most 100,000; even using a CPU- and memory- hard algorithm, generating the hashes for all possible user-IDs and storing them into a database wouldn't take more than a few days. Using SHA1 or AES, it's a matter of minutes, perhaps even seconds. Afterwards, to know what ID hides behind a given hash, it's just a matter of looking for that hash in the list.

You might want to consider replacing sequential IDs with random ones (which can be a pain in the nether regions; and you need to handle the case where a random newId collides with a yet-to-be-replaced oldId). At that point the "possible IDs" are no longer one hundred thousand (from 1 to 100,000) but several billion trillions (from 0x00000000000000000000000000000000 to 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF). Bruteforcing will now take an impossible amount of time, and/or an impossibly large database to hold the hashes.

Correlations

Consider the possibility of non-trivial correlations between file1 and file2. While a trivial correlation would be both files containing a unique identifier, or worse still, a copy of the user ID, there might be information in both files that could allow determining the user ID, or the link between paired files; for example, a timestamp, or a invertible UUID for some resource.

This issue might extend to metadata such as mtime, or inode number, or position in the directory listing; two files created within the same second, or stored one after the other, could be tracked to the same user, even if one can't backcalculate the user ID.

You should consider archiving the files in a 2- or 3-deep structure, i.e.

/rootdir/ae/02/47/ae0247f19a8b52f.json

and using a non-atime-updating filesystem; and/or when you do change or create or delete a file, touch the whole branch (here ae, ae/02, ae/02/47 and ae/02/47/ae0247f19a8b52f.json) to a fixed datetime, such as midnight January 1st, 1970.

Initialising the repo

When transferring the files to the repository, you might want to first produce a list:

 000001-1.json      aae3799a82b9fb8ccd34c1d5aa6565b2
 000001-2.json      539c50984894084b3e3b1047eee187ae
 ...

Then you scramble the list. Once done this, for each pair on the list you move e.g. 000001-2.json to repositoryRoot/53/9c/50/539c50984894084b3e3b1047eee187ae. This way, there will be no correlation between the inodes, filesystem position or disk physical position of 000001-1.json and 000001-2.json.

Be warned that on most filesystems, this approach will appreciably increase the time required to do the copying.

Emails as IDs

This does not look very promising security-wise, because emails are often guessable and/or recycled. Much would depend on what exactly is stored on those JSON files and what the attack scenario actually is (the two cases of a hacker gaining access to a repository of embarrassing information and attempting to blackmail the owners - thus requiring to work back from the JSON to the email - and someone trying to acquire the information of a victim whose email is known, are to be handled very differently).

One possibility could be having an anonymisation table kept outside the repository:

ID                   RandomToken
lserni@gmail.com     5231b225ea0dbcced14c993523af4986
....                 ....

At that point you could use token as the "secret" password.


I think you're working on the wrong end. The server simply needs to check if the admin is authorized to edit the user right before the update. Whether or not the admin has altered the form is irrelevant and cannot really be checked, anyway. The point is that you only accept changes if the user is authorized to do them – just like everywhere else in your application.

Trying to protect the parameters is missing the point. It's also very difficult and will lead to all kinds of problems. For example, let's say an admin of group Red starts to edit user A who is indeed a member of this group at this point in time. The admin doesn't touch the form at all, but he does wait. In the meantime, user A has switched to group Blue, so the admin shouldn't be able to edit this user. However, you would probably let them do it based on the obvervation that the form hasn't been altered.


Use USB TRNG as source of randomness for OpenSSL key generation

Use /dev/[u]random by both feeding it with the entropy of the hardware random number generator and also using it with whatever consumer of random bits you want to use (also OpenSSL will rely on those interfaces). The easy way is simply piping the input to /dev/random, but this will not increase the entropy counter (the driver will have to register as an entropy source to do so).

The kernel will mix entropy from different sources: interrupts because of keyboard and mouse input, network and hard drive timing, ... If you add your hardware random number generator, you will result in a mix of entropy from all of those sources. In the end, any random number with a constant number added up will still remain random, so even if the hardware random number generator is fully predetermined, it will not break the random number generator.

At least, as soon as enough entropy from other sources was added: the only time it might result in guessable random numbers is immediately after the random number pool does not have sufficient entropy from other sources.

I strongly recommend viewing the half-hour lecture The plain simple reality of entropy -- Or how I learned to stop worrying and love urandom held at Chaos Communication Congress 2015, which has a very good explanation of how random number generators mix different sources of entropy. It also explains why you shouldn't care too much of /dev/random and its random bit counter, and use /dev/urandom instead.


Root certificate from an CA company which can be encrpyted by SoftHSM

No, I doubt that that any serious CA company could allow you to operate a CA key outside a real HSM. Additionally it is more than likely that completing a successful third-party audit of your PKI, from a technical and operational point of view, must also be mandatory requirement.

Oracle provides a PKCS#11 Cryptographic Provider for the Java Cryptographic API. However I never used this provider for serious purpose. You can find the official documentation here. This provider is part of the standard Java distribution.

Note that some HSM vendors may also ship a dedicated Java API with their HSM which better fits their product features than the PKCS#11 API. I know that Thales nCipher HSM has such a library.


How to exchange RSA public keys safely between two parties?

Get yourself a trusted key. Two easiest options are an SSL certificate ($50..$100) and a GPG key (free).

Encrypt or sign the data you send with that key. With SSL, you can just serve your data via https, but can also just sign it. With GPG, you have to build enough trust for your key, so that the receiving end is sure it's you and not an impostor.

Another option is to create a  public key to your SSH server, publish it and let people just SCP your data from there. Send them fingerprints of your SSH key via snail mail or tell verbally by Skype / phone. An impostor would have to fake your key, your server on a known domain name, and your phone / Skype / SIP contact; this should be sufficiently hard to thwart such attempts.


How does authentication work without OAuth in mobile apps?

Peter: When you use certain mobile apps (take Evernote for example), you don't get redirected to the website to grant permission to the app. Instead, you just log in with your username and password, straight inside the app.

Actually Evernote uses OAuth. OAuth2 allows different authentication workflows. The Resource Owner Password Credentials Grant does not open a website.

  Peter: So, I'm wondering how this works, and where to look to implement this. Is the password stored on the device, and sent to the website?

An Android Authenticator is able to store an authentication token as well as a password on the device. The Authenticator will use the authentication token - if available - to access your web application. If no token is available, it will try to get one with the password, which will be retrieved through a login dialog. Therefore you could avoid storing the password, but as soon as the authentication token expires the login dialog will show up. Also Google recommends avoiding to ask for passwords when possible:

  In general, we recommend minimizing the frequency of asking for user credentials—to make phishing attacks more conspicuous, and less likely to be successful. Instead use an authorization token and refresh it.

  Peter: Is this actually safe?

You may assume passwords are stored securely. Put simply, Android works like a Linux system, where every app is run by another user, so that apps cannot access each other without public APIs. Note, that a rooted Android phone weakens that mechanism.

If you want to skip implementing OAuth, you could create a more simple login service, which returns an authentication token (for example a session id), but as always when rolling out your on security system, there are many pitfalls. Therefore I advice you to look for an OAuth framework (for example Apache Oltu) and implement an Android authenticator the standard way.


Can you perform a buffer overflow and a format string attack at the same time?

Yes, you can certainly chain both of these together. For the most part, you can ignore the other exploit while working on the other; it will just affect your offsets.
Start by constructing your format string exploit at the beginning of your payload. Then, create padding from the end of that to where your buffer overflow offset is (e.g. if the needed offset is 40 bytes and your format string payload is 12 bytes, add padding of 28 bytes). After the overflow padding, add the address of secretClub.
It should look something like this (values are completely made up):
%5435325c$5%n + A*28 + secretClub

Note that user_age probably won't be on the stack since it's a global variable, so the necessary format string payload may be a little trickier than what I've illustrated.


What are the most common files to check with File integrity monitoring software?

You should monitor (nearly) all the files.

Assuming that this system is just a hash database, then there are some files you should skip:

everything in /proc (there's a lot of useful stuff in here for root kit hunters though)
log files  (there are tools will will do heuristic analysis of these files)
files which contain filesystems (this would include loop-back filesystems and database files - but you probably want to check the 'files' inside the file).
swap space

(the difficult bit is setting up a process for auditing the changes properly)


How to get client MAC address using Angular JS?

You cannot get the MAC address from the machine where the browser is running on by executing Javascript (and thus also Angular.js) inside the browser. Access to this information is restricted due to the sandbox in which Javascript is executed.


As @Lucas says in his answer, and as it says in the article the OP linked to:

  So, how does it work? Elcomsoft Forensic Disk Decryptor acquires the
  necessary decryption keys by analyzing memory dumps and/or hibernation
  files obtained from the target PC. You’ll thus need to get a memory
  dump from a running PC (locked or unlocked) with encrypted volumes
  mounted, via a standard forensic product or via a FireWire attack.
  Alternatively, decryption keys can also be derived from hibernation
  files if a target PC is turned off.

This is not new - this has always been possible, and in fact is often used by forensics teams where access to the running PC is available.

To be safe, you don't let others have access to your computer when it is on, (or off - see Evil Maid attack), ensure you don't leak information by leaving hibernation files, memory dumps or other unencrypted data around and generally follow the usual security guidance.


Smartcard authentification: encrypt/decrypt or ECDSA?

In public key cryptography you perform authentication by signing a message that the other end verifies it using your public key.

Since in your case you only need to authenticate, this is exactly what you need.


References to issues of putting backdors into opensource (like OpenBSD) by FBI or CIA

The closest thing I've seen to what you're asking (and it has nothing to do with state-sponsorship) is this speech by Ken Thompson during his Turing Award Lecture. It basically asks the question, if the gcc compiler was at one point poisoned to produce compilers which produced backdoor-ed code, and then the was used to compile gcc for a number of major distros and subsequently the code was destroyed, would we ever know?>

This is more a thought experiment on what could potentially happen if someone were to attack systems high enough up the stack. Interesting concept, there are ways to automate the output of a compiler to ensure that it's sane (assuming your tools were compiled with a good compiler...) but as far as I know they are not implemented on any of the major open-source projects.


It doesn't work because the payload is URL-encoded.

If you navigate to

https://example.com/?foo=<>"

you will see the literal characters <>" in your URL bar, but the browser has actually requested

https://example.com/?foo=%3C%3E%22

. That is, your browser always URL-encodes some characters in the query string, including quotes and angle brackets.

So, if you access location.href via JS, the payload in your example will be returned as

test%3C/option%3E%3Cimg%20src=x%20onerror=alert(1)/%3E

. This does not produce any HTML tags unless you URL-decode it first.

Note: As far as I know, all modern browsers now behave that way, but historically, some implementations have implicitly URL-decoded values for the location interface. In these browsers, your attack would have worked.


Display browser requested cipher suites from OpenSSL

Use "-brief"
You need to use the -brief command line option:
$ openssl s_server -accept 443 -cert cacert.pem -key cakey.pem -brief

Output:
Protocol version: TLSv1.2
Client cipher list: ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:0xCC14:0xCC13:0xCC15:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:SCSV
Ciphersuite: ECDHE-RSA-AES128-GCM-SHA256
Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA384:ECDSA+SHA384:RSA+SHA256:ECDSA+SHA256:RSA+SHA224:ECDSA+SHA224:RSA+SHA1:ECDSA+SHA1
No peer certificate
Supported Elliptic Curve Point Formats: uncompressed
Supported Elliptic Curves: P-256:P-384
Protocol version: TLSv1.2
Client cipher list: ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:0xCC14:0xCC13:0xCC15:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:SCSV
Ciphersuite: ECDHE-RSA-AES128-GCM-SHA256
Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA384:ECDSA+SHA384:RSA+SHA256:ECDSA+SHA256:RSA+SHA224:ECDSA+SHA224:RSA+SHA1:ECDSA+SHA1
No peer certificate
Supported Elliptic Curve Point Formats: uncompressed
Supported Elliptic Curves: P-256:P-384
GET / HTTP/1.1
Host: localhost
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.132 Safari/537.36
DNT: 1
Accept-Encoding: gzip, deflate, sdch

Note: "-brief" does not in fact mean "brief"
The Client cipher list: line is NOT displayed when leave out the -brief option.
Unfortunately the s_server documentation provides only wrong/misleading information about this parameter:
-brief
  only provide a brief summary of connection parameters instead of the normal verbose output.

Yes, that's right, in order to get more info, you need to use the "give me less info" parameter. (OpenSSL is quirky with its command line options that way.)
Further reading
There was thread about this on the OpenSSL mailing list and a developer provided the information about the -brief parameter:

Stephen Henson, 2015-03-06, [openssl-users] Getting info on the ciphers supported by a   client (Archived here.)


Which .CER file format is more secure for purposes of an AIA record?

The Authority Information Access extension, which is added into certificates issued by a given CA, should contain a URL which points at a download location for the certificate of that said CA. This is described in section 4.2.2.1 of RFC 5280, in particular with this paragraph:

  Where the information is available via HTTP or FTP, accessLocation
     MUST be a uniformResourceIdentifier and the URI MUST point to either
     a single DER encoded certificate as specified in [RFC2585] or a
     collection of certificates in a BER or DER encoded "certs-only" CMS
     message as specified in [RFC2797].

So that's either binary DER (not Base64), or a .p7b (which means PKCS#7, which is the old name for CMS). The raw DER-encoded certificate is probably better supported than the CMS object, therefore I recommend using it.


These questions are a bit broad and confusing. Email headers often look different for a host of reasons.

  what the first hop is actually describing, in the sense that it is a
  hop between the first Message Transfer Agent and the next one, meaning
  that it is not representing the hop between the machine of the user
  and the first mail exchange server, or could also represent this last
  situation? (For example I am analyzing some emails and in some cases
  the first hop is "from apache by "some domain" ", or "from user[IP
  number] by "some domain" ")

The first hop is generally the first MTA reporting it received the message. "From Apache" just means the server that sent it was running Apache. Typically, the actual users IP address, if present, is found in the X-Originating-IP field.

  if there is a hop in which there is the name of the mail exchanger and
  also the IP next to it, in an enclosed parenthesis, but it looks like
  that the IP is in another country, what does it mean?

The names you see in an email header are fully qualified domain names (FQDN). They identify a particular machine on the Internet and within that domain. The IP address in paranthesis is the IP address of that machine so if it resolves to a certain country, that is where the machine is located.

  how should SPF
  be interpreted (the check refers the machine of the sending server so
  the first hop)?

SPF puts a record in DNS with a list of all IP addresses authorized to send mail on behalf of the domain. Recipient mail clients check to see if the MTA sending the message they are receiving has an IP address that falls within those ranges. If it does, there is usually a denotation in the header that says Pass. If it does not, several things can happen depending on how the SPF policy is configured:

If the record ends in -all, messages will not be allowed through and you will see a Fail denotation in the header.
If the record ends in ~all, messages will be allowed through but they should be marked. You may see a None or SoftFail for these messages.

Other things that can be done is with regard to the hops is to check whether the FQDN's match up with the MX record for the domain. For instance, if sender Bob's domain foo-bar.com used Google to send mail, then you can expect to see Google FQDN's in his portion of the message path. This may at times require performing whois lookups on the domain names in question because they may not always be named in such a way that it will be obvious they belong to a certain organization.

Another test is to check whether the sending domain uses DKIM. If it does, and there is no DKIM signature present, that is a good indicator of a spoofed email.


How do botnets not get caught when using Gmail accounts for spamming?

Botnets often consist of thousands of machines. The largest ones count even hundreds of thousands. When one machine gets blacklisted by a service provider for spamming, another machine from the botnet is used instead.

Also, most members of botnets are machines at private internet connections which do not have static IP addresses. That makes them very hard to blacklist for two reasons: 1. the machine can start spamming again as soon as it got a new IP address and 2. the service can not hold up IP blocks for too long because they risk hitting a legitimate user when the blacklisted IP gets reassigned.


Best options for SSL inspection while maintaining Perfect Forward Secrecy

So you want to do some analysis on inbound HTTPS traffic. A common way is to use reverse proxies (commonly Apache or nginx) in front of the actual servers, install the server certificates on the reverse proxies and actually do the SSL/TLS decryption on the proxies. It gives:

client <-> Internet <-> [ router <-> { reverse proxies <-> actual servers } ]
                        |            |
                   corporate      security
                    network         zone
                     limit         limit

In this scenario, the reverse proxies shall be in the same security zone as the servers, that means that only admins should be able to spy them and the traffic between the proxies and the servers. So the traffic between the proxies and the server can safely be unencrypted (but should transport optionaly client certificates). As reverse proxies are normally simpler than application servers, it is easier to add filtering and traffic analyzis there.


What are the subfields of cryptovirology?

Are you just looking for an enumerated list of topics?  Ransomware tops the list today.  But there are other malicious attacks that involve cryptography, including evading cryptography (such as protocol-downgrade attacks), exploiting asymmetric cryptography, deliberately introduced information-leaking side channels (aka kleptography), and the use of poor or questionable encryption (especially when a more trustworthy alternative may exist.)

If you haven't already, read Malicious Cryptography: Exposing Cryptovirology by Young and Yung.  It was the first thesis specifically exploring the topic of cryptography-based malware.  The authors maintain a site at http://www.cryptovirology.com, which is more up to date.  It has a lot more information that is probably better suited to answer your specific questions.


Long handshake intolerance (SSL/TLS) - Command Line

Long handshake intolerance means that the server cannot handle ClientHello with more than 255 bytes (or in case of F5: more than 255 and less than 513 bytes). You can simulate such handshakes for example with openssl s_client by specifying an as much ciphers as needed as  to reach this size. For example I get

$ openssl s_client -connect google.com:443 -servername google.com -cipher ALL -debug
CONNECTED(00000003)
write to 0xe1b9c0 [0xe1ba40] (354 bytes => 354 (0x162))
...

This means that the initial SSL record (i.e. the ClientHello) had a size of 354 bytes since lots of ciphers are included. This is clearly more than 255 bytes and if you get a successful connection to the server with this then long handshake intolerance is not a problem. If the connection fails it might be due to long handshake intolerance but might also have different reasons. In case of F5 the symptom was that the connection simply hung, i.e. no response from server but also no immediate close of the TCP connection.

Note that the actual size of the ClientHello differs depending on the server name (-servername argument) and the ciphers available in your version of OpenSSL and maybe some added extensions.


Vulnerability scanning vs fuzzing a web application

The idea of fuzzing is to send data to the interface with not much intelligence: garbage, random input and so on. When you are using a vulnerability scanner, you usually test for well known problems. In the case of web applications: injections and so on. It is possible that a vulnerability scanner can include some sort of fuzzing as one of the tests it performs.


A Wordpress plugin stores a SMTP password in plaintext, why?

So while I understand this is different from a login situation where you can check against a password hash and don't have to store the plaintext, is there no better way for the plugin to have access to the SMTP password and not store it in plaintext?

The plugin needs to have access to the plain password in order to do SMTP authentication. While one might encrypt the password this only moves the problem since one now would need to store the encryption key somewhere accessible to the plugin.

  Does their suggestion of shifting the plaintext password's location from the database to a config file make any real difference - in general and in regard to Wordpress?

In case there is a successful SQL injection the password might be read from the database. For reading a config file instead the server either has to be configured insecurely by making this file accessible from outside or there need to be another way the attacker can access data on the server, for example using some remote code execution vulnerability. But in this case the attacker will also have access to the database too since the database credentials are also stored in some config file.

Thus, neither solution provides absolute security. But the risk of using a properly protected config file might be the smaller one.


SQL injection with a URL separated with dashes

As described in the sqlmap manual on the sqlmap GitHub page (https://github.com/sqlmapproject/sqlmap/wiki/Usage#uri-injection-point) you can insert an asterix at the spot where sqlmap should inject the payloads if that spot is in the URI.

That means:
If you want sqlmap to replace somethingid01 with the payload you would give your url like:

sqlmap -u "http://www.example.com/*-anotherthingid023"

If you want sqlmap to scan both parameters you have to replace the second one as well:

sqlmap -u "http://www.example.com/*-*"


You have a risk/cost - benefit problem here, with basically three factors:

How much you trust the person manipulating the tablet
The cost of the tablet
The potential damage of the data that was stored there being accessed.

Only you can decide the course of action that is most appropriate for your case and personal preferences.

Now, there are a few things you may do to lower the risk of potentially private data being accessed:

You can request a remote wipe of the device. If the tablet is made functional again (and able to connect to the internet), it will receive the command and wipe itself.
You can invalidate the tokens and even change the password for the accounts which are setup in the device (note this can be incompatible with the previous point). Thus, it won't be able to gather new data (eg. start receiving your new emails) and, depending on the app, may even not show data which was previously downloaded.
Obviously, you don't want to give him the passwords for the device. This may by itself be enough to avoid him accessing your data.
You invite your friend to come to your home and attempt together to fix the tablet.


If you just want to see that a SSL handshake occurs, just use a network monitor tool, like the aptly named Network Monitor from Microsoft. It will show you the details of the SSL handshake (see this answer for some details on the SSL handshake). Of course, at some point, data encryption begins, and you will then only see "encrypted application data", which is what you wanted.


How to decrypt ciphered text from public and private keys in integer format RSA?

Actually you don't really need to convert your keys or use OpenSSL. Open a Python console and decrypt your message:

>>> m = (c ** d) % n

where d is your private exponent.


Can I reclaim ex employee gmail account?

Do we, the company, have the legal
  rights to stop him from using the
  account?

(Sigh) I'm beginning to recommend lawyers a lot, but this is one of the scenarios where they will help. [Disclaimer: I am not a Lawyer, and this is not legal advice] I'm not sure what the laws are in your jurisdiction, but this appears to be a case of withholding one of the following

access to the account; this point is not cut and dry. If the employee created this account for a one-off scenario, then it depends on the laws of the land (and the interpretation) of the courts, as to how this account could be treated as belonging to the company due to its prolonged use.
work created for hire or any other materials that belong to the company (if it is resident in that account). If you do have an employment agreement that stipulates how the company owns any material created on company time, along with an agreement that also stipulates how such materials ought to be relinquished by employees on resignation, then a lawyer would be able to aid in your next course of action.

Ultimately there ought to be applicable laws for this scenario and my advice in earnest, is to speak to your lawyer on this.

More importantly, I think you ought to establish procedures for handling termination of employment. If they do not exist, establish them. But stating what measures ought to be established, is probably beyond the scope of IT Security or Application Security.

However, there are few points where your IT department (if it exists) can help. Critical accounts (e-mail accounts, NTLM/Kerberos accounts and others like your accounts with Domain Registrars) should ideally have a fail-safe mechanism to ensure that you can regain control of the account, or terminate access to the account if no longer required. In some cases, this would mean that you would have to run your own software (like an Outlook Exchange or Postfix/SendMail server, instead of relying on GMail). In other cases, it would mean that you should have access to a human being on the other side, who can immediately revoke/expire access to compromised accounts or reset passwords to them (to prevent further access by unauthorized people).


What vulnerabilities could be caused by a wildcard SSL cert?

A "wildcard certificate" is a certificate which contains, as possible server name, a name which contains a "*" character. Details are in RFC 2818, section 3.1. The bottom-line: when the server certificate contains *.example.com, it will be accepted by clients as a valid certificate for any server whose apparent name matches that name.

In the certification business for Web sites, there are four main actors:

The SSL server itself.
The vendor of the Web browser which the client will use.
The human user, who controls to some extent what the client browser will do.
The CA who issued the certificate to the server.

Wildcard certificates don't imply extra vulnerabilities for the SSL server; indeed, the SSL server has no interest in looking at its own certificate. That certificate is for the benefits of clients, to convince them that the public key contained in the certificate is indeed the public key of the genuine SSL server. The SSL server knows its own public/private key pair and does not need to be convinced about it.

The human user has no idea what a public key is. What he sees is a padlock icon and, more importantly, the intended server name: that's the name at the right of "https://" and before the next "/". The Web browser is supposed to handle the technical details of verifying that the name is right, i.e. validation of the server certificate, and verification that the name matches that which is written in the said certificate. If the browser does not do this job, then it will be viewed as sloppy and not assuming its role, which can have serious commercial consequences, possibly even legal. Similarly, the CA is contractually bound to follow defined procedures for identifying SSL server owners so that fake certificates will be hard to obtain for attackers (contract is between the CA and its über-CA, recursively, up to the root CA which is itself bound by a pact with the OS or browser vendor, who accepted to include the root CA key in the OS or browser under defined conditions).

What this amounts to, is that the browser and the CA must, in practice, pamper the user through the verification process. They are more or less under obligation (by law or, even stricter, by business considerations) to prevent the user from being swindled through fake sites which look legit. The boundary between the user's job and the browser/CA job is not clearly defined, and has historically moved. In Days of Yore, I mean ten years ago or so, browsers just printed out the raw URL, and it was up to the human user to find the server name in it. This lead forged site operators (i.e. "phishing sites") to use URL which are technically valid, but misleading, like this one:

https://www.paypal.com:payment-interface-login-session@xcvhjvb.com/confirm.html

Since human users are, well, human, and most of them read left-to-right (most rich and gullible scam targets are still in Western countries), they will begin on the left, see www.paypal.com, stop at the colon sign ("too technical"), and be scammed.

In reaction, browser vendors have acknowledged that the URL-parsing abilities of human users are not as good as was initially assumed, and thus recent browsers highlight the domain part. In the case above, this would be xcvhjvb.com, and certainly not anything with paypal.com in it. Now comes the part where wildcard certificates enter the game. If the owner of xcvhjvb.com buys a wildcard certificate containing "*.xcvhjvb.com", then he can setup a phishing site called:

https://PayPal-payment-interface-login-session.xcvhjvb.com/confirm.html

which will be accepted by the browser (it matches the wildcard name), and is still likely to catch unwary users (and there are many...). This name could have been bought by the attacker without resorting to wildcards, but then the CA employees would have seen the name with obvious fraudulent attempt (good CA do a human validation of every request for certificates, or at least raise alerts for names which are very long and/or contain known bank names in them).

Therefore, wildcard certificates decrease the effectiveness of fraud-containment measures on the CA side. This is like a blank signature from the CA. If wildcard-based phishing attempts become more commonplace, one can expect that one or several of the following measures will come into existence:

Browsers highlight only the parts of the domain name which matches non-wildcard elements in the certificate.
CA require heavier paperwork and contracts for wildcard certificates (and these will be more expensive).
Browsers deactivate support for wildcard certificates altogether.

I actually expect all three measures to be applied within the next the years. I could be totally wrong about it (that's the problem with predicting the future) but this is still my gut feeling.

Nitpickingly, we can also point out that wildcard certificates are useful for sharing the same key pair between different server names, which makes it more probable that the private key will be shared between different server machines. Traveling private keys are a security risk in their own right; the more a private key wanders around, the less "private" it remains.


I have internet at home, need to know who visited what? Possible?

You can run a local machine as the web proxy and point all others to use that for all http traffic. Squid is one option.

Another option is to setup one machine to be the DNS server, e.g, using bind. You can then collect all the DNS logs. You can set up your router to give this local DNS machine as the primary DNS server via DHCP.

Another way (albeit the hardest) is to collect all the traffic as pcap and run tcpdump (or wireshark) to parse it. This will require a switch with port mirroring or a machine with 2+ Ethernen NICs.

If you don't care about domains, you can probably make your router (if it supports it) to export traffic logs to syslog. You can then use Splunk or any other log manger to go through the IPs and reverse DNS them or use whois to figure what is the destination.


How to get MAC addresses of devices which are not in the network

If it's not in the same network, you most likely won't be able to.

MAC addresses are hardware addresses and are usually hidden behind a router unless you are on the same network or have direct access to the device. In other words, once you leave the network, unless the device(s) in question is/are directly connected to a router you will get the MAC address of the switch rather than the individual devices when querying that network.

Depending on the security of your network, you may not even be able to get the MAC addresses of devices on the same switch since they may be on different VLANs.

With that said, in your comment you asked if you could get any other information on the device(s). Without access to the network that the device is on it's pretty difficult to get any information on anything other than that of the router. Without getting too technical, unless the device has its own static IP address that you know, which is unlikely for a mobile device, if you query the network from the outside you'll get the public IP of the router, not the devices. Specifically for mobile phones, you can probably get information via Bluetooth if it's enabled on the device, but you have to be in close proximity. According to one commenter it may also be possible to sniff the device's traffic given close enough proximity. There are probably ways to gather more info, but it's probably more trouble than it's worth.

The easiest way to get information on a device on a different network is to simply join that network.

Edit: As you say in another comment, you have a WiFi adapter that someone can connect to. If the device doesn't connect to that adapter, then you can't gather any information about the device. But if the device does connect to your WiFi adapter, if it's assigning IP addresses, you will be able to see both the MAC address and the IP address you assigned, and with the MAC address you can infer roughly what kind of device it is based off the manufacturer's portion of the MAC address. If you're letting the device access the Internet, you will also be able to see all of the packets it sends through your adapter. You may be able to get some additional information specifically about the device, but it depends on the device, your WiFi adapter, the software you're using... and so on, which means there are many variables.


Risk associated with problematic linux permissions on files and libraries

Is this normal

Impossible for us to say without more data, but there are normal processes that can cause this.

  and should I be worried?

Sloppiness is a more likely explanation than maliciousness, so, not deeply.

  Are there more permission numbers that are to be avoided (outside 777 and 775)?

The numbers have meaning, and it's the meaning you need to worry about.

7 is octal for '111' which maps to 'rwx' and means 'read: yes, write: yes, execute: yes!'

5 is octal for '101' which maps to 'r-x' and means 'read: yes, write: no, execute: yes!'

You were told 777 is problematic because each digit means a different set of users: user, group, and other.  7 in the third digit means that other ('everyone not already specified') can write to the file, which is often a bad thing, because you shouldn't trust absolutely every user (including service and software users) on your system.  Especially if they're writing to a program or a library that gets loaded into a program, they can make you execute malicious code.

Likewise, a 7 in the second digit can be a bad thing if you don't trust the group that it's granting write access to.

  Is there any more efficient way to check and/or correct bad permissions on a system scale?

The best way is to use your distribution tools; see this answer which was written around SUID/SGID concerns but is equally valid for loose write permissions.  Note that this will not catch the most likely cause of accidental looseness, which is installing software modules (e.g., with pip rather than apt) with a non-restrictive umask set for that user.


Is there a field length that is too short to allow harmful SQL injection?

Without context, I'm going to presume that the author is referring to input fields in a client application. The easiest example to use would be a form in an HTML page in a web application, though what I'm about to describe is effective for virtually any type of client application.

Given this context, the answer is no, there is no maximum input field length short enough to protect you from SQL injection, because you don't control the maximum input field length. The attacker does. When the form containing the input field lives on the client (like in a browser window on the attacker's machine) it is outside of the trust boundary, and out of your control. It can be manipulated in any way the attacker wants or needs, or avoided completely. Remember, for a web app, all you get is an HTTP request. You have no idea how it was created, and no reason to believe that anything you asked the browser to do actually happened, that any client-side security controls were actually run, that anything in the request is as you intended or in any way safe.

So no, input field length is not a valid SQL injection prevention mechanism, and never, never trust input that crosses a security boundary without validating it.


How did Google Map know it was me on my mother's hardwired desktop?

Another possibility is the forum you're using used an OpenID account to sign you into the forum. Similar to what Armani was saying, at the point you login with that OpenID you'll set the cookie that lets Google know you're a user on that machine. The login on the page itself was for your mother, but the map picked up the cookie and read your profile. When you closed the browser it closed the sessions, so you weren't logged in when you tried to replicate the results.

If you go back into the forum and log in and then try to access the map check to see if you have the same results.

You can go into your Google account and restrict the types of information they keep on you. Also you can open a private browsing session in most browsers when you need to use your mother's computer to do something like check your e-mail. That way all of the cookies are cleared when you close that window.


What is the XSS auditor in Chrome/Firefox and how do I find bypasses?

It seems unlikely that all of these companies are properly sanitizing characters and after doing some research I think this could happening because of XSS auditors in Chrome/Firefox?

Chrome's XSS auditor does not actually render the payload harmless, it throws a warning preventing the user from accessing the page.

If you check the source code when you get a warning, you should see that the XSS payload is highlighted as seen in the example below.

From personal experience with participating and running bug bounty programs, you do not normally need to demonstrate an XSS auditor bypass in order for your report to be valid. In my opinion, it is not a good idea to rely on the browser's auditor, especially since not all browsers come equipped with an XSS auditor (e.g. Firefox) and new bypasses are found all the time.

  Am I correct that in some cases the website isn't encoding my XSS payload and that the auditors themselves are making assumptions about my code and preventing an alert from firing? If so, how do I avoid this?

As stated above, Chrome's XSS auditor will only throw a warning. So if you see the warning shown above, you might actually have a valid XSS vulnerability.

  [...] how do I find bypasses?

Most of the bypasses that you see online require a specific context for the payload to actually work. That being said, there have been universal bypasses in the past as seen in the Chromium issue tracker. Bypasses can be discovered via fuzzing, general experimentation, or purely by chance. On top of that, some bypasses are discovered by altering a previous bypass (See https://bugs.chromium.org/p/chromium/issues/detail?id=709365 and https://bugs.chromium.org/p/chromium/issues/detail?id=738017).

In future, what I recommend doing in order to make sure that the XSS auditor never kicks in while you are hunting, is to simply fire up Chrome using the --disable-xss-auditor flag.

If you are interested in learning more about browser XSS filter bypasses, I highly recommend taking a look at "Browser's XSS Filter Bypass Cheat Sheet
" by Masato Kinugawa.


OK, since noone is trying to answer this I have few tips. OpenSSL doesn't seem to know that.

If you need to use pipe with the private key in stdin, you can use following. E.g. to output the pubkey right away (in fact, it is useless since you don't save the privkey):

openssl genrsa 2048 | ....

openssl genrsa 2048 | openssl rsa -pubout
You can use ssh-keygen for similar thing. The following will print the pub/priv rsa key pair with empty passphrase, but afaik it's in a bit different format than the OpenSSL would give you.

ssh-keygen -t rsa -f file -P ""
And then there is the fact that using && or two separate commands should be okay for most situations.


Passing PHP code directly into JavaScript in HTML5

JSON_HEX_TAG

If you are echoing into JS inside a HTML document (as you are in your example), this is necesarry or you risk opening up a huge XSS vulnerability. Without this one, an attacker can post something along the lines of this:

</script>alert("XSS");</script>

Since PHP 5.4 this has been fixed, and slashes are escaped by default, but still, you never know what PHP version your code will run on. Better safe than sorry.

As OP points out, even in never versions of PHP you can insert a


Emerging Standards for file transfer and integrity check?

There's not much more to it than "use SSL for file transfers, use digital signatures (e.g. PGP) for file authenticity".

The recommended ciphers are AES for a symmetric cipher and RSA for an asymmetric cipher. Any SHA2 family hash should be safe as a hash function.


How to rate CVSS when PR is low but UI of admin user is required

That a low. From the spec re Privileges Required:

  This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability.

Emphasis on the attacker's privileges, not anyone else's.

However, you should also indicate that user interaction is required.


Picked up used HP Envy 5530 printer, concerned about potential security risk, am I paranoid?

If the printer is behind a NAT, computers on the Internet can not connect directly to the printer. Whether or not the printer supports IPP makes no difference.

The open ports and the missing default password do increase the attack surface, but do not indicate any vulnerabilities that can be used to access the printer. It may well be possible for an attacker to print something on the printer without permission, but I find it unlikely that the printer has malware on it.

That said, I don't know the specifics of this printer and it is impossible to say whether it is infected without further investigation.

Before connecting the printer to the network, it would be a good idea to reset factory default settings on it, and set a password.


Is it safe to send clear usernames/passwords on a https connection to authenticate users?

Yes, this is the standard practice.  Doing anything other than this offers minimal additional advantage, if any (and in some cases may harm the security).  As long as you verify a valid SSL connection to the correct server, then the password is protected on the wire and can only be read by the server.  You don't gain anything by disguising the password before sending it as the server can not trust the client.

The only way that the information could get lost anyway is if the SSL connection was compromised and if the SSL connection was somehow compromised, the "disguised" token would still be all that is needed to access the account, so it does no good to protect the password further.  (It does arguably provide a slight protection if they have used the same password on multiple accounts, but if they are doing that, they aren't particularly security conscious to begin with.)

As MyFreeWeb pointed out, there are also some elaborate systems that can use a challenge response to ensure that the password is held by the client, but these are really elaborate and not widely used at all.  They also still don't provide a whole lot of added advantage as they only protect the password from being compromised on an actively hacked server.


Using client certs issued by a third party CA

Using client certificates that are not issued by you poses some threat.

Anyone who knows the email of one of your users and can find a CA in your trust list that is not very strict about user verification, can get themselves a forged certificate with this email. Then they can access the private section.

Managing your own PKI is complicated, but can solve this issue.

Giving a signing certificate is turning the burden to the client's company, which might or might not be a good idea depending on their expertise and trust-ability to operate the PKI seriously.

At the end, the answer is always "it depends". You have to compromise between the risks and costs of dealing with the risks.


What are the privacy conerns with cloud based submission in antivirus?

This works differently depending on the AV that you are using. Some engines send the file to the cloud and generate a signature. In this case, the response is yes, they send the files to the cloud and this is a privacy issue (in some countries). On the other hand, some engines take metrics from the file and send these metrics to the cloud for post analysis or whatever. I would suggest you check the terms and conditions of the AV and you will probably find the answer. Or just ask them, specially if the information that they scan is protected and can not be transfered and things like that.


Hosting company advised us to avoid PHP for security reasons. Are they right?

It's not so much that PHP itself has security problems (assuming needed security updates), as it is there exists a lot of popular PHP-based software with rampant security problems. You could fault PHP for being a language that gives you enough rope to choke yourself, but the real problem is just how prevalent vulnerable PHP code actually is. One need look no further than the Stack Overflow PHP tag to find PHP newbies writing horrifically vulnerable code based on some atrocity of an old tutorial.

Additionally, a significant number of popular PHP software known for their rampant security flaws is based on very old code and coding practices. Many of these old practices are considered bad-practices because of inherent security problems.

  This, to me, sounds about like telling someone to never drive so they won't be in a car accident.

Pretty much yes. Better advice might be along the lines of "don't drive an old car with no airbags".

  My gut instinct is that the host is trying to shift blame onto the client for security flaws in their own system.

Not necessarily. If a user uses the same password for the WordPress site and cPanel, compromising the WordPress password also compromises cPanel. That would be the fault of the user. Hackers rarely need to get that far though, and just use a PHP shell.

  I told my client that to process the contact form they're going to need some form of dynamic scripting. (False?)

Not necessarily true. You could use a 3rd party service to handle the mail sending. Then the service handles the dynamic server scripting and take over the security implications. There are numerous such services available with varying feature sets, and they are popular for powering contact forms on statically generated sites.

  How much truth is there to the claim that using any PHP script, no matter how simple, is an inherent security problem?

Some, but not much. PHP does involve some active code, in both PHP and the server software which executes it. If there were ever a security vulnerability in that process which did not depend on specific PHP code, it could be exploited. While that risk is tiny, it's a risk a server with no such support does not have.


I saw that before. Tha accounts of your friends are probably hacked. They are sending spam or evil links to all contacts. Never click on that links. Probably that links are trying to execute javascript on your browser... trying to steal cookies or for any other evil purpose.

Your friends should change their password quickly. Or maybe their computer is infected with malware.

If is hapenning to you with ALL of your contacts... probably is your account which is hacked or what have the malware.


Which information is revealed to a network-admin when using VPN?

They would see the initial communication to setup the VPN tunnel and they would see the source and destination communication to maintain the tunnel.  But all data within the tunnel, (IE where you were routed out the other end of the VPN) would be completely hidden.

Example: VPN from A(laptop) to B(VPN device) is visible.  The fact that you access stackexchange.com across the VPN is hidden.

Keep in mind, VPN can allow "split-tunnel" which ONLY routes traffic destined for the subnets on the other end of the VPN to go through the VPN tunnel.  All other traffic would go across your coffee shop network in their plain view.  To be secure, split tunneling must be disabled.
Ref: https://en.wikipedia.org/wiki/Split_tunneling

Edit:  Some additional thoughts...if at work (not recommended) your network administrator could have a proxy/NextGenFirewall that actually intercepts encrypted connections and acts at a Man-In-The-Middle to decrypt, inspect, and reencrypt as the traffic goes through.  Doubtful this would happen other places like hotels/coffee shops.


Is the Windows paging file safe in the encrypted partition?

Microsoft (among many others) uses somewhat confusing terminology at times. In this case, "drive" is used in the sense of "drive letter". This is distinct from a "disk", which is a physical storage device. A drive's data may be stored on a physical partition, but the storage location for a "drive" is most properly called a "volume". It might be one partition, or multiple partitions (spanned, or striped, or RAID5, or whatever), or a CD-ROM, or an image file mounted from some other storage device... you get the idea. "Drive" does not refer to the entire disk; even on things like SD cards (where there's usually only one volume per physical "disk"), the disk metadata is outside of the logical volume that gets mounted and assigned a drive letter.

To directly answer the question, if your paging file is stored on an encrypted partition (which is typically your C: drive, and encrypted via something like BitLocker or TrueCrypt/CipherShed/whatever), you're fine. Well, as fine as the encryption on the partition is, but the important point is that sufficiently good whole-volume encryption is fine; you don't actually have to encrypt literally the whole disk.

The distinction Microsoft is making is between full-volume encryption (stuff like BitLocker) and more granular encryption (such as file encryption via Encrypting File System, encrypted ZIP archives, data encrypted with PGP, and so on). BitLocker is usually referred to (by MS) with either the abbreviation FVE (for "Full Volume Encryption", as in fveapi.dll or fveprompt.exe), or the abbreviation BDE (for "BitLocker Drive Encryption", as in manage-bde.exe).


At what point in their employment should security policies be explained to an employee?

The question could also be asked: "how long should an employee have access to data before they are trained in how to use and protect that data?"

For most organizations, the answer is "0 minutes". You wouldn't place an employee in front of machinery without training them, and you shouldn't place employees in front of a computer without training either.

Each organization needs to assess the risks of this, but the typical answer is that this training is done during orientation.


The REDIRECT target in iptables will rewrite the destination ip to the local ip on the incoming interface. The port will per default remain the same, by you can rewrite it using --to-port.

Extra: to redirect to a different IP, you can use the DNAT target instead using -j DNAT --to <ip>:<port>


How exploit this open redirect vulnerability in browser?

You cannot exploit this vulnerability from a browser. For non-proxy requests browsers always put the absolute path into the request which means that it will start with a slash.

The request you've sent to the site is actually a HTTP proxy requests (which would in theory also be a valid HTTP/1.1 non-proxy requests, but no browser sends it this way). The browser will send such a request to the site only if the site is configured as HTTP proxy in the browser. But even if you could somehow reconfigure the users browser to use the vulnerable site domain.com as a proxy the open redirect would not work because the user would need to actually click on the real link http://google.com in order be be redirected to again http://google.com and since the user keeps using the proxy it will just end up as a endless redirect.


Everything you send over the network is visible to anyone near you. Even if they do use MAC filtering, it doesn't help -- with no encryption on the network, you're broadcasting every packet in the clear over radio. Any wifi card capable of monitor mode can record everything you send. As André mentioned in comments, this is also potentially vulnerable to active attackers. MAC control does not protect users of the network from eavesdropping; it makes it slightly more annoying for an unauthorized user to connect to the network (this does have its uses; it discourages casual passersby from using the school network, and might fulfill some bureaucratic requirement that the school needs to follow), but that's it. At the scale of a large university, a pre-shared key would be no better (it might as well be completely public).

The only way to protect against that is to encrypt your traffic. A VPN can be a very effective way to do this; if you can connect to your school's VPN from the wifi network, this will encrypt your traffic over the air. Likewise, any site you visit using HTTPS will be encrypted, so an eavesdropper can't read your messages.

At a network level, the school has more options: the best one by far is to offer a secure network using WPA2-Enterprise, for which you log in to the network with school credentials, which are used to derive an encryption key specific to you (with WPA2-PSK, anyone else who knows the wifi password can still eavesdrop or perform active attacks; with Enterprise, they can't). For devices that don't support this (like game consoles), there's no really good option; what my school does is run a WPA2 secure network that everyone's recommended to use, and run an unencrypted MAC-controlled network for devices that just don't support the secure network. This requires some amount of infrastructure (nicer APs support it better, with one AP carrying both those networks), but it works well for security.


How do we encrypt a password using another password?

This is about real, reversible, symmetric encryption. It is not related to storing a one way hash of a password.

encryptedData = encrypt(data, key)
data = decrypt(encryptedData, key)

The very simple implementation of encrypt("bar", "foo") could return "hpg".

key is the shared secret known to both Charon and the mail service. The linked article calls this key a password.

data of course can be another password. But in this case it is not a password, but some information that Charon wants you to pass on to the mailserver. It is called Ticket. The symmetric encryption ensures that neither you nor anyone else can read it. More needs to be done in order to make it secure, but that is dealt with in later scenes of the play.

By the way Wikipedia has an explanations of Kerberos that is closer to the actual technique. The different way to present it may help to understand it.


No, you cannot secure data completely if the user has total control of the system and its hardware (and possibly a lot of money; attacking hardware can get quite expensive).

If this is just to prevent cheating, hardcoding the encryption key in an obfuscated manner (so that strings doesn't find it) should be enough though (any student breaking that probably deserves a good grade anyways).

If you are handing out the hardware along with the software (how else would you pass it to the students without internet?) you could go with the approach suggested by raz: encrypt the data with a key based on the computers hardware (eg by adding a PUF to the hardware; but again, access to the hardware means that this can be broken).

You could also look into trusted computing, which tries to achieve what you want (but still, complete access to the hardware means that it can be bypassed with enough money and time).


Is this the correct way to calculate value of safeguards in risk management?

What you have calculated is the traditional "Cost Benefit Analysis" (CBA). The calculation is:

CBA = ALE(prior) – ALE(post) – ACS

Where ACS is the Annualised Cost of Safeguard.

This is used to determine if the CBA is positive and also to estimate the projected Return on Security Investment (ROSI). If positive, then you know that the safeguard will provide more protection than it costs. The ROSI helps to qualify this safeguard against other safeguards and to weigh against other non-monetary costs that might also need to be considered.

This is not strictly "value" as you suggest in your question, but it might be understood that way.


How to study the packets sent by a keylogger

The keylogger looks to be sending email using Gmail but the SMTP communication is encrypted with TLS (SSL).

Simple Mail Transfer Protocol
    Command Line: STARTTLS\r\n
        Command: STAR
        Request parameter: TLS

Simple Mail Transfer Protocol
    Response: 220 2.0.0 Ready to start TLS\r\n
        Response code: <domain> Service ready (220)
        Response parameter: 2.0.0 Ready to start TLS

You can use Fiddler on the host running the keylogger to intercept the SMTP messages before they are encrypted with TLS (SSL). Fiddler intercepts Windows WinINET-based applications so it will not intercept all SSL connections.

  Fiddler is a Web Debugging Proxy which
  logs all HTTP(S) traffic between your
  computer and the Internet. Fiddler
  allows you to inspect all HTTP(S)
  traffic, set breakpoints, and "fiddle"
  with incoming or outgoing data.
  Fiddler includes a powerful
  event-based scripting subsystem, and
  can be extended using any .NET
  language.

If the keylogger sends email it means that it will collect keys for a certain amount of time and then send the email. Which means that it will have to store those keys somewhere. Tracking file writes for that keylogger can point you to it's cache and maybe the key file will indicate if the keylogger is targeting Runescape or the user. I recommend Process Monitor for tracking file writes.

A different way of finding the destination email address is debugging the keylogger. You could start with a memory dump and a search for strings. First you identify the keylogger process by tracking the writes that happen after key presses, then use Process Explorer to search the strings from the memory dump of the process.

OllyDBG and a bit of patience can be useful for debugging the code of the keylogger by setting breakpoints on SMTP functions and then inspecting the memory for email addresses.


Are "VPN" and "Certificate Pinning" serving different purposes for a private mobile app?

here are several scenarios to think about.

A) User loses mobile device. The pinned certificate only protects the phone so much as the built in password.
     1) user loses device to malicious internal party. Without an iOS password, 3rd party breaks into network with that users NT/LDAP credentials
     2) user loses device to external party. Strong password secures lost device

B) User loses mobile device. The VPN cannot be used by anyone else, because the token is still attached to the user.
     1) VPN token is lost with device: token is revoked by administrator
     2) Token is retained: token is bound to another device

C) Bound by fingerprint authentication in iOS.
     1) The pinned certificate would continue working as expected
     2) The VPN token serves as another layer of protection
       -------------
C2 would serve well for Government and where absolute security required
C1 would use in Banking, Finance, Health
B2 is in Education, Research, Manufacturing
B1 and above are worst-case scenarios. Plan to not have them.


The Access-Control-Allow-Origin response header indicates whether the response can be shared with resources with the given origin.

(From MDN)

When the server sends Access-Control-Allow-Origin: *, it allows any origin to access the resource in a cross-origin request. But the extent to which this is exploitable varies.

Let's say, you're logged in for online banking at https://yourbank.example/ and the site sets the ACAO header. At the same time, you're visiting an attacker-controlled site in another tab. Now, the attacker's site could load a script which issues a cross-origin request to your online banking dashboard in the background, along the lines of:

fetch('https://yourbank.example/').then(r => r.text()).then(console.log)

In that case your browser would reveal your view of https://yourbank.example/ to the attacker. However, this isn't helpful, because your browser doesn't include authentication details (i.e., the session cookies) in the request by default. So all the attacker gets is your unauthenticated view of your bank's website.

Even if the site also sends Access-Control-Allow-Credentials: true (where the attacker can usually call fetch() with {credentials: 'include'} to read the response of an authenticated cross-origin request) you're out of luck because allow-credentials has no effect when ACAO is set to wildcard (*).

So, with ACAO: * alone, you're left with less likely attack scenarios. For example, it would work on an intranet site or router interface which displays confidential information even without authentication but isn't directly accessible to the attacker. (In that case it may also be vulnerable to DNS rebinding.)


How often should secrets be regenerated for token-authentication?

The general guidelines here is; access to secret keys need to be highly restricted.  For example, if this is a hard-coded secret, then any time someone with access to source leaves the company, then the secrets need to be rotated. Clearly hard-coding secrets is bad practice, and if secrets were properly stored in an HSM/KSM/CloudHSM then there is less pressure to rotate. Keep in mind, Yahoo stored the keys to the kingdom has a hard-coded secret in source control, so that anyone with access to source could then hijack 32 million email accounts (slow clap for the Yahoo security engineers).

tldr; rotate if you ever have reason to believe that the secret has been compromised.


Removing Unnecessary Services & Packages in a MySQL Ubuntu 12.04 Server

you're going the wrong way.

for debian-like systems the right way is:

install a minimal system (e.g. from netinst)
install the hardened-packages
install wanted servers/applications

this assures to have only needed services and packages installed, no need to remove unwanted services like 10 years ago :)


Security implications of setting the broadcast flag on a UDP socket

As far as I know, sending broadcast over UDP protocol is normal. So, there is not problem to use SO_BROADCAST in setsockopt(2).

Disclaimer: The only thing you SHOULD be aware of is the tiny change of optval (in setsockopt(2)) between Linux and Solaris/sunOS environment.

snippet code example:

  static int fd = -1;
/* Use the SVR4 macros to distinguish between Solaris and SunOS */
#if defined(sun) || defined(__sun) || defined(__SVR4) || defined(__svr4__)
/* Solaris || SunOS */
  char on = '1';
#else /* defined(__linux__) */
  uint32_t on = 1;
#endif
  if ((fd = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP))== -1)
  {
#ifndef NDEBUG
    dbg_err_fputs("Cannot open datagram: \"%s\"", strerror(errno));
#else
    dbg_err_fputs("Cannot open datagram");
#endif
  }

#ifdef SO_BROADCAST
  if (setsockopt(fd, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on)) == -1)
  {
#ifndef NDEBUG
    dbg_err_fputs("Cannot set brodcast flag in socket optname: \"%s\"", strerror(errno));
#else
    dbg_err_fputs("Cannot set broadcast flag in socket optname");
#endif
  }
#endif /* SO_BROADCAST */

If your development platform is a Solaris/sunOS, then you will have to add some flags at the end of the command during compilation: -lnsl -lsocket. Depending on the Solaris/SunOS version, the socket will only work if you add the -lxnet flag... If error persists: -lresolv.


Because USB is plug and play, there are many opportunities for evil maid attacks with unrestricted port access. The article here shows how to use and human interface device to bypass the Windows lock screen: https://room362.com/post/2016/snagging-creds-from-locked-machines/

To prevent a human interface device from automatically running commands on a computer, the OS would need to be configured to ignore the USB ports. Autorunning and automounting drives should also probably be disabled, but these are usually problematic only after the computer has been unlocked. The exact method of disabling USB port access is OS dependent. Of course, if there is a bug in the OS that the attacker knows about, they may be able to circumvent the lock screen anyway. However, in the situation you presented, the biggest threat is rogue human interface devices. It only takes a few seconds for a plugged in drive to cause damage if the OS does not ignore it.

Some BIOSes also allow disabling USB ports, but I'm pretty sure that human interface devices can still connect, since it could be catastrophic to block all external control devices so early in the boot sequence.


Security implications of FileExists() from javascript in browser

You could learn a lot of interesting information about the users system this way.
This information could be used to find the correct exploit for the user, or just be collected or used as part of a system fingerprint to identify users (Even with another used browser).

Detecting the OS would be extremely simple, but also the detection of used versions of static libraries should theoretically be possible.

Most services create pid files when they start. This could be used to check if specific services are running and try to attack them (Think of some web admin panel without csrf protection).

As @TessellatingHeckler mentioned: You could also try to "bruteforce" (more dictionary attack) usernames.


Is there an advantage to applying pbkdf2 to a key that's used to generate a MAC?

Cryptography should only be used when there is no other option (SSL/TLS is a good example where cryptography is required).  An HMAC always introduces the possibility of the trivial attack (brute force).  Further more, an HMAC can also be a waste of computation effort, when compared to other solutions such as a simple Cryptographic Nonce used to reference the data.

PBKDF2 is used to stretch low entropy input,  such as human generated passwords,  to be used as cryptographic keys.  In order for PBKDF2 to be useful it will consume significant computational effort to produce the resulting hash.  An application exposing this kind of functionality is vulnerable to an Algorithmic Complexity Attack (ACA), and this would be a very serious vulnerability if this was finical software,  because DoS attacks result monetary damages.

PBKDF2 is a useful, especially for passwords, however by exposing this function to an attacker without any form of rate-limiting, creates a potential DoS condition.  SHA256 is just fine for use as an HMAC,  in fact SHA1 would be a better choice for a web application because its faster and the prefixing attacks against SHA1 do not weaken the resulting HMAC. The secret key is what is important,  and you still have to worry about offline brute-force attacks.   But that can be addressed by making the secret key 128 bytes long, which solves that problem for the life our solar system (with some comfort room!).


Should I wipe a brand new Machine and HDD ?

When you're installing an OS you'll almost always be creating partitions and formatting them anyway, so any previous data left on the drive shouldn't be an issue, unless this "data" is actually malicious and designed to exploit a vulnerability in the filesystem creation tool, but I haven't heard of such flaws yet.

The only exception would be Windows which does weird things with the MBR; I believe it doesn't rewrite it if a Windows MBR already exists on the disk and doesn't offer any way to wipe it from the installer, so if the disk had a previous Windows installation on it you will most likely be using its potentially malicious MBR.

Just to be safe (and because I like having the disks completely clean before installing an OS) I like to boot on a Linux CD and run either shred -n 1 -v /dev/sdX or issue the secure erase command with hdparm.


HTTPS enable for proxy server or web server

It's common to terminate SSL (ie. decrypt traffic) at the first point where your network receives the traffic assuming your internal network can be considered secure. Often this is at a load balancer or caching proxy.

In your scenario I'd terminate the SSL at nginx.


Are login pages with no retry counts/lockouts a security risk?

Careful!  Based on what you're saying, you've already donned the Hat, and now it's up for interpretation whether it's a Black, Grey, or White Hat.  Depending on localities, you may actually have already committed a felony.  System administrators can get very protective of their systems, and they don't always see the honest-guy-shows-you-your-lock-is-broken angle.

This may be a job for anonymous tips, unless you have a good working relationship with a staff member who could report it for you and keep your identity confidential.

It absolutely does need reporting, but don't accidentally martyr yourself being a good Samaritan.


How to decrypt Chrome saved password from "Login Data" file

Google Chrome uses the operating system's API to encrypt passwords. In windows the called function is CryptProtectData.

There are several tools for decrypting Chrome passwords, but generally they involve being logged in as the user who saved them. If instead you want to proceed from scratch, I suggest you study the Microsoft documentation on the encryption function.


No single quotes is allowed, Is this SQL Injection point still exploitable?

You may want to take a look at this paper (wayback machine link). It details some methods of bypassing such filters.

For example,  some SQL filters replace all single quotes with a pair of single quotes. However, feeding them an input containing \' can bypass this.

Also, there is Unicode smuggling, where you use a Unicode character that Java (PHP/Ruby/Python/whatever) understands as being different from a quote, but the database doesn't.

Unless you have a really, really good reason, I recommend you use the built-in escaping.


Would a password saved on paper written in a personal writing system be decipherable?

I hope this isn't an incredibly dumb question, I personally can't come up with any way it would be possible to crack this, but I want to be sure.

Being unable to come up with a way to crack your own invention isn't generally seen as an indicator for quality in security circles.

  Would it be possible for anyone to crack that?

That depends very much on how your personal writing system works, and how much additional text in this writing system is available to an attacker.

Your question is basically a cryptography question: You have a script no one except you knows, and you want to know whether it's decipherable. There are some historic parallels; for example, Linear A is an ancient writing system that remains mostly a mystery. And if you visit the British Museum, you'll see the Rosetta stone, without which we might not be able to read Egyptian hieroglyphs today.

Assuming your writing system simply replaces letters, or maybe syllables, with your own symbols, it should be fairly easy to crack given a few pages of text written in it. A simple frequency analysis would probably be enough to crack it.

However, if the only thing your attacker has is the picture of your password in your writing system, and the password is random (e.g. not a known word), then I'd say chances of successful cracking are slim. This is because unknown writing systems and ciphers are often cracked because the people working on it make correct guesses about context, and if there is no context, this doesn't work.

What could be problematic is that because a good writing system is designed to be useful, you might have made an 'e' simpler to write than, say, a 'q'. So it might be possible to make some guesses as to which symbol corresponds to which actual letter, which would reduce the number of password guesses an attacker might need to make (e.g. if he correctly assumed that the fourth letter was an 'e' and the seventh was a 't', maybe based on the shape of your symbols, he'd reduce the time needed to find the correct password by brute force (trying every possible combination of characters) by about three orders of magnitude.


Consequences of using -s and -d arguments in iptables

As I understand:

Switch -d and -s are associated by a and expression.

But.

As you're talking about a firewall, and  iptables -A OUTPUT mean iptables -t filter -A OUTPUT, this seem not to be right:

chains INPUT and OUTPUT concern packet from or to the host (firewall).

This coud be usefull if your firewall hold many different IP address and want to make condition based on wich IP is used.

Even if 10.7.53.2 is the only (local) IP of your firewall, -s switch is clearly useless.

For blocking a traversing connexion, you have to instruct FORWARD chain.

iptables -A FORWARD -s 10.7.53.2 -d 10.7.53.5 -j REJECT


Can malicious phone software mount a MITM attack on a phone call?

Yes, the "phone" itself is an application.  It can be hijacked or replaced entirely.  In fact, Android handsets are DESIGNED to do this so that you can automatically use a VOIP provider when making phone calls if you so desire.  Malware with complete device control could simply place itself as such a service and when you dialed a call, it would be connected through VOIP and the attacker.

Even without doing this, the microphone and speaker are also controlled by software and there isn't any reason that it couldn't record the input and output from there either if it has sufficient privileges to the system.


Is Java relevant to Information Security?

Programming is relevant to IT-Security; it may be subtitled as "yeah, I kinda grasp the concepts of what I am blabbing about". You cannot be a decent practitioner of IT security if you cannot imagine what occurs in a computer beyond something like "then magic occurs". This necessarily implies some basic skills at development.

The exact programming language does not matter much. In fact, if the programming language matters to you, then you don't know enough programming yet. If you want to "get into the IT-security field" then you must reach the point where your question feels ridiculous, as in "how could I have been such a twerp to ask such a silly question ?". Meanwhile, go learn how to do basic programming in at least two or three different languages (Java may be one of them); this is the path to enlightenment.


Alternative forms for special characters in terminal

Yes, this is possible. In most shells, there are plenty of ways to do this. Any way you can encode and decode something in a subshell into ASCII will work. A few examples for bash:

cd $(printf '\x2fetc')
cd $(base64 -d <<< 'L2V0Ywo=')
cd $(awk 'BEGIN{printf("%cetc",47);}')
cd $(cut -b1 <<< $HOME)etc
eval $(base64 -d <<< 'Y2QgL2V0Ywo=')

Everything in the subshell is evaluated first, so these all become:

cd /etc

There are countless other ways to do this, many far more obfuscated than anything I've put here. But if all you want to do is change directories without using a /, any of these should suffice perfectly. Note that some of these use bash-isms and are not perfectly POSIX-compliant.


For all we know the key is "dog".

You didn't say what the key is, or what the encryption algorithm is; the only information given is the cleartext, "hello", and the ciphertext, "GH6SDgsd2".

If the cleartext is changed, the resulting ciphertext will change.

If the key is changed, the resulting ciphertext will change and, again, there's no telling what the resulting ciphertext will be without knowing 1) the key, and 2) the algorithm.

Encryption software works by first converting the cleartext to a series of numbers (in a computer, text is always stored as a series of numbers). Then, the software performs one or more mathematical operations on these numbers, the operations performed depend on the encryption algorithm used by the encryption software. Common encryption algorithms include AES, Blowfish, etc. The key is a separate series of characters, or numbers, that are also used in these mathematical operations. If the same cleartext, the same key, and the same algorithm and encryption software are used, the resulting ciphertext will be the same.

Ciphertext is sent as a secret message to someone. If the receiver of the message knows the ciphertext, the key, and the encryption algorithm and software, the receiver will be able to decode the message.

If someone in possession of the ciphertext doesn't know the key, or what encryption algorithm is being used, they won't be able to decode the message, or at best it will be very difficult for them to decode the message. The difficulty involved in attempting to decode a given piece of ciphertext, without having the key, depends primarily on the length of the key. If the key is long enough, it might take many years for someone to decode the message.


General question on secure channels and implementations

The current practice assumes that general routing policies are sufficient.  This is mostly for ease of use for Ops (content-based traffic shaping, automated intrusion detection, etc, work easier on unencrypted traffic) more than anything else.  It isn't a BAD assumption - if someone owns a machine sufficient to have access to traffic sniffing, they probably could access the ssl certs for that machine.  It does mean that things are less contained than they could be.  It is a risk-management decision - do you add security and slow down your ops team?  Or go a little more open and make their life easier.
One advantage of SSL/TLS termination at the border and HTTP internally is easier access to content for intrusion detection purposes.  It is also a lot easier to have SSL dealt with in one place, rather than having to ensure trusts using wildcard certs (if using an external CA) or self-signed certs for the individual hosts (if using an internal self-signed CA).  It gets harder to do TLS internally with scaling - hosts are appearing and disappearing.  Clear is easier.  Again, this is a trade off - you need to make a decision for your environment, your content, your need for scaling and fast changes, your ops team.


It's actually byte code.

  Bytecode, also known as p-code (portable code), is a form of
  instruction set designed for efficient execution by a software
  interpreter. Unlike human-readable source code, bytecodes are compact
  numeric codes, constants, and references (normally numeric addresses)
  which encode the result of parsing and semantic analysis of things
  like type, scope, and nesting depths of program objects. They
  therefore allow much better performance than direct interpretation of
  source code.

It's a compiled program which is made out of instructions the CPU directly understands. It's often used to exploit vulnerabilities by making the vulnerable running program execute this program by overflowing it's buffer and making the return address the address which is the first instruction of the byte code program. Often you try to spawn an interactive shell with, in this case it's called shellcode.

  In computer security, a shellcode is a small piece of code used as the
  payload in the exploitation of a software vulnerability. It is called
  "shellcode" because it typically starts a command shell from which the
  attacker can control the compromised machine, but any piece of code
  that performs a similar task can be called shellcode. Because the
  function of a payload is not limited to merely spawning a shell, some
  have suggested that the name shellcode is insufficient.1 However,
  attempts at replacing the term have not gained wide acceptance.
  Shellcode is commonly written in machine code.

There's a good book about the subject named the Shellcoder's Manual.


Secure point to point remote access to NAS drive

My preferred method is SSHFS.

Your NAS server runs a SSH server which you then connect to from your remote machine. Leveraging SSHFS it will mount a drive on your remote machine via SSH (secure, encrypted) from the server you specify.

I've not used the windows client version so YMMV.

https://www.digitalocean.com/community/tutorials/how-to-use-sshfs-to-mount-remote-file-systems-over-ssh

HTH


Does secure boot protects against firmware rootkits and GPT bootkits?

It does indeed protect against GPT bootkits, and that's exactly what its job is. It doesn't protect against rootkits in the UEFI firmware itself though, as it's that very firmware that's responsible for enforcing Secure Boot.


Will hashing a password, and then splitting it into multiple db fields increase security?

This would make the password LESS secure.

Consider a 16-character password made up of a sequence of randomly chosen letters, numbers, and symbols. By itself, this password is basically "uncrackable" for all intents and purposes, even if your password database is leaked, assuming you hash the password. You could probably even use something stupid like MD5 and be OK against most attackers. Assuming a trillion password guesses per second, it would still take millions of years to crack this one password.

But now, we apply your storage method. Assume you take the first 8 characters and hashed them in one field, then take the next 8 characters and hash them for the next field.

Now you have two 8-character passwords. Each password can be cracked individually in a few minutes to a few hours, depending on the hash you use, if your password database is ever leaked, just by trying every possible sequence of 8 characters.

Assume no help at all from the fact that the password is "hiding" in two different fields. At best, you have security through obscurity; you're relying on the fact that the attacker may not know which fields to combine together. At worst, the attacker who manages to steal your password database, will also manage to steal the website code, and will know immediately which fields to grab. A basic tenet of information security is to always assume the attacker knows how your system works, and make sure the system will remain secure despite that knowledge.


Finding a specific malware sample for malware analysis purposes

Contagiodump blog and the spam folder are your best friends


Depending on your server, you might be able to disable "directory indexing", which means a person can't list out the contents of the directory. Alternatively, you can place the private images outside the document root. Create the url with a token. For the image request, use the token to look up the real image location and provide the real image.

If the token is something easily guessed, your attacker can still find the images. For example, if you use simple number like 1, 2, 3, 4, 5, I could easily guess that 6 might be a valid token.

If you use a hard-to-guess directory name, but include that in the url, that hard-to-guess name is now known.


How is time-based SQL injection different from other types of SQL injection?

It is not different in value from "regular" Blind SQL Injection, it's just different in manner of exploit.

The only real reason for going time-based (other than learning, of course), is if the other types of SQLi are not available.
Same reason you would bother with "regular" Blind SQLi, instead of regular SQLi.

"Regular" blind SQLi is dependant on getting back some value, even if it is only one bit different. It is easy to imagine a scenario where ZERO bits leak out directly, e.g. an application that scrubs the response, returns a single static response no matter what occurs in the database.

In such a situation, Blind SQLi would not help. So, you are forced to get back that single bit of information in other ways - i.e. time delay.
Now, the rest of the Blind SQLi techniques can step in, based on this one indirect bit of information.

So to answer your direct questions in reverse order:

  b) How is it that other methods fail, but Time-Based SQLi is present?

Because the application does not return even a single bit of information directly, even though it is injectable.

  a) Why would you chose to perform a Time-Based SQLi over any other method of injection as Time-Based takes so long and is arguably more detectible than other methods?

Because (b).


What is the difference between certificates held by intermediate CAs and those issued by them?

Given that one CA can issue another a certificate so that they can go on and do the same

The Basic Constraints extension can indicate that a CA cert is not allowed to issue any other CA certs, so not all CAs can create additional CAs.

  what would stop someone from using the certificate for their website to issue certificates and become an intermediate authority

The main purpose of the Basic Constraints extension is to indicate something is, or isn't, a CA (absent a Basic Constraints extension the answer is "well, it's a CA if it's self-signed"). Additionally, the issuing CA shouldn't give an end-entity certificate the KeyCertSign usage in the Key Usage extension, which is required for a CA.

RFC 3280: Basic Constraints Extension
RFC 3280: Chain building section 4

Specifically, points k, m, and n.


Programming language for network security

There is no defined blueprint on what is the best language to learn. Therefor I would like to mention two good alternatives that I (and many otheres) think is a good languages to learn in computer security.

LUA

Explanation of Lua from wikipedia: Lua is a lightweight multi-paradigm programming language designed as a scripting language with "extensible semantics" as a primary goal.

The reason I mention LUA is a good language to learn is that it is the scripting engine for MANY popular security tools. This is a very good reason alone to learn this language. Some of the langauges include:

NMAP (Network mapping tool)
Snort (Open source IDS)
Wireshark (Packet sniffing tool)
Vim (Very popular unix text editor)
Cisco ASA (firewall, IPS, VPN)
Network services tools (Apache, lightHttpd, FreePop)

On a side note: Even Blizzard major hit World of Warcraft has support for LUA scripting inside the game :) To whomever that may be relevant to.

Python

I am a bit biased on Python after I've started reading the book "Gray Hat Python: Python Programming for Hackers and Reverse Engineers". I agree with many of the points from this book why it is good to learn this langauge for a hacker (commonly known as security specialist :)).

Quoted from Amazon Python is good language to learn because:

  it's easy to write quickly, and it has the low-level support and libraries that make hackers happy.

It is also very comfortable to be able to interact on the fly with the interpreter in your Python shell.

Edit:
Graphical view of HackerNews polls on favorite/ disliked programming languages:

Edit 2:
From Digininjas poll:

Language    Number  Percentage
Python  245 81%
Bash Scripting  241 79%
Ruby    127 42%
C   123 40%
Windows Powershell  111 37%
Batch Scripting 108 36%
PHP 107 35%
C++ 66  22%
Java    65  21%
Perl    57  19%
Other   57  19%
VB  29  10%
C#  26  9%
Lua 23  8%


If you're trying to protect against mostly-benign software, this should work fine. Some software might make its own DNS calls (bypassing the OS DNS resolver, which checks the hosts file) and some will probably use direct IP addresses, but most by far will just ask the OS to resolve the names.

If you want to restrict potentially-malicious software, this is definitely insufficient. Safely containing malware is tricky, and requires sandboxing far in excess of what you've talked about here. Malware will absolutely use hardcoded IPs and/or make its own DNS queries, but it will also do things like change firewall settings (if running with sufficient privileges), scan and attack local network hosts (which may not even have DNS entries, at least not ones the malware will see or care about), and of course monitor and/or interfere with legitimate traffic from the machine.

However, between the two options, a firewall is definitely "lower level" than the hosts file. An external firewall (which might be on the same physical host, but running in the host OS of a VM or container) will work better than a local one (which might be overridden by sufficiently-privileged software), but changing a hosts file provides no actual restrictions whatsoever; it's merely (taking away) a convenience.