TLS provides authentication with the use of certificates on its own.

TLS actually can do a number of things, but is most commonly used for establishing an encrypted session/tunnel between two end points.
It certainly can be used to provide authentication, but many of the EAP protocols that do make use of TLS only do so to encrypt the traffic between supplicant and server to provide a secure tunnel through which the authentication takes place.

Then what is the point of EAP?
...
Is EAP better in some way?

You said it yourself, "EAP is an authentication framework." EAP defines a framework that provides a standard interface within which entities are free to define their own authentication methods that can provide authentications services in whatever way they see fit within that standard framework.
The two end points (authenticator and supplicant) must be able to understand and make use of the specific method, but any intermediate devices are only required to know how to process EAP traffic. In other words, intermediate devices don't need to know anything about the actual authentication methods in use in any way.

The most notable usage of EAP is WPA. Is it advantageous to use it on wired connections too compared to plain TLS?

That is the most notable usage of EAP of which you are aware. EAP dates back to RFC 2284 published in 1998 and was designed initially for PPP (Point-to-Point Protocol) connections. It had nothing to do with wireless.
This initial EAP framework was compelling enough that in 2001 the IEEE working group for 802.1X decided to use it for the basis of it's authentication (which extended it to EAPOL or "EAP over LAN") for it's purpose.
802.1X, while initially meant for use on Ethernet networks, became the basis for network authentication on just about any medium where network authentication was required, including 802.11 in 2004 (this is also the year the EAP RFC was updated by RFC 3784). EAP is also typically used for authenticating mobile devices to cellular networks (SIM, AKA, AKA', and so on).
For a non-networking use of EAP, for those living in North America (and maybe elsewhere) most "open road tolling" systems that use transponders mounted in vehicles actually use an EAP method to "authenticate" when passing through toll collection points.
I am sure there are plenty of other examples of EAP in use in the world today as well. And most of these uses do not use WPA/WPA2.

I am having trouble understanding the point of EAP.

The point of EAP is that it allows devices to handle EAP traffic as EAP traffic without caring what the EAP authentication method in use might be. Only the authenticator (i.e. authentication server, typically RADIUS) and the authenticating client (i.e. supplicant) need to share an understanding of the EAP method in use.
Say you build a network. Your devices understand that clients that connect have to authenticate and you choose a proprietary solution that requires all devices (client, authentication server, and all intermediate devices) to understand and be able to process this authentication solution.
Now imagine that this authentication solution is flawed, or you get a new type of client that doesn't understand this authentication solution. The resolution now requires an upgrade to all your intermediate devices as well.
Instead, they will use EAP. Your network knows how to deal with EAP traffic (i.e forward to the authentication server). The client and server know how to negotiate the EAP method to use (defined by the operation of the EAP framework). If you need to change EAP methods or add clients that only know a new EAP method, all you need to adjust is the authentication server. All your intermediate devices just handle it as any other EAP traffic.
So, to give you a bit of insight, here is an example list of authentication methods used with EAP over time for various purposes and by different organizations (some of which are now obsolete or vulnerable):

PPP
PAP
CHAP
SPAP
MD5-Challenge
One-Time-Password
Generic-Token
TLS
PEAP
TTLS
LEAP
SIM
AKA
AKA'
MSCHAPv2 (not to be mistaken for PEAP/MSCHAPv2)
PAX
PSK
PWD
FAST
IKEv2
TEAP
GTC
EKE

This is by no means a complete list and I am not personally familiar with all these methods, but quite a number of these I have seen used with EAP (or other EAP methods, such as TTLS) in different capacities.


What is the pitfall to connecting with Tor on a public wifi hotspot?

Yes, it is encrypted before it leaves the system. The Tor client on your computer encrypts the data three times. The first key is shared with the guard node, the second with the middle node, and the third with the exit node. Each node strips off a single layer of encryption before passing it along. The exit node strips off the last layer of encryption and sends it off to its destination. This is called onion routing. All the public WiFi can see is opaque, triple-encrypted data being sent to a Tor guard node.

Tor has hardcoded in it a list of fingerprints which it uses to verify the authenticity of the Directory Authorities (DAs). Once it has verified the authenticity of the DAs, the DAs send the Tor client a list of Tor nodes along with their own fingerprints. Your Tor client will pick a guard from that list, verify its identity through the fingerprint provided by the DA, and then connect to it. As long as your Tor client is genuine, it will be impossible for any MITM attack to occur between you and the guard.

Tor uses three layers of AES128 in CTR mode for encryption. The HMAC used to protect integrity uses SHA256. Key exchange is done with Curve25519, with the related Ed25519 used for fingerprints. More technical information is available in Tor's NTor handshake protocol specifications.

Be aware that Tor is only a tool designed to help you stay safe, not a panacea. It will not protect you from your own OPSEC failures or an advanced adversary exploiting your browser with 0days.


It sounds like your account number is a credit card number. Conveniently, I know from experience that a five year old graphics card can exhaust a salted 10 numeric digit key with salt in 3 days, meaning an average of 36 hours to reverse a PBKDF(4096) hash. It's not looking good for you already.

You're much better off generating a random nonce to pair with the transaction and associating that nonce with the card.


How can an out-of-the-box (Windows) server not be secure?

First off, you say you have secured your website against, "any type of sql injection and the like." What this means, at best, is that you have secured it to a standard that you think is good enough at that point of time, but it may still be insecure.

I'll give you the basic overview:

Microsoft WIndows itself, when written, has many vulnerabilities, both known and unknown
All applications have vulnerabilities
Applications and operating systems are patched over time, but new vulnerabilities
are discovered
Every open port could allow an attack, depending on what vulnerabilities are present in the application listening on that port

The general guidance is that you should:

Install your platform, install the O/S and patch up to date
Remove all unneeded applications
Follow Windows hardening guide
Install only those applications needed and patch up to date
Follow hardening guides for these applications
...etc etc

You cannot secure something. You can only reduce the risk of a successful attack, and even then, this is a continuous process.

Update: rolling up comments

Although the only application you need on there is a web server, Windows out of the box has many applications listening on various ports. These should all be hidden from the outside world unless you have good reason (may be needed to connect remotely etc. in which case you need to secure that application) - and you can do this by disabling the application or blocking the port at the firewall etc.


For this reason I first ssh to P and from there I ssh again to T.

If I interpret this correctly you log into P, get a shell and then run ssh from within this shell. If P is compromised you can not trust that you get the expected terminal, not the expected shell and not the expected ssh binary. Everything can be bugged, i.e. all keystrokes (including passwords) you do can be intercepted, all input and output recorded or even modified before sending.


Is communication with printers protected?

Most of the commonly used network printing protocols are not protected against sniffing or modification. And even if the printer supports TLS protected IPP it is usually either not setup at all or not setup securely (i.e. with  certificate trusted by the client and with proper certificate validation).

In other words: the average printer setup as used by normal consumers is open to sniffing and modification. It might be different in companies which actually care about network security (i.e. most not). And, if you just interested in securing your own printer connection check if your printer support IPPS (IPP over TLS). See also How can I encrypt my print jobs?.


Is it ever possible to crack an encryption key character by character?

If an encryption system allows for character-per-character cracking, then it is awfully weak, and should not be used.

Mathematically, block ciphers are defined as pseudorandom permutations. A block cipher works over the space of blocks of length n bits; such a space has size 2n. There are 2n! permutations over that space (that's a factorial, meaning that the number of possible permutations is huge). A secure block cipher is such that it is indistinguishable from a permutation selected at random, uniformly, in the space of possible permutations: each key is supposed to correspond to such a random choice of permutation, and, crucially, all choices for all possible key values are independent of each other.

What this means, in mundane words, is that for a secure block cipher, either you have the whole key, exact down to the last bit, or you have nothing. Contrary to Hollywood depictions, an "almost good" key does not result in a "blurry plaintext": if even one key bit is wrong, you should get random junk (that is, an output which is sufficiently indistinguishable from random junk that you cannot know whether you are close to the right key or not).

Of course, if the encryption system is weak, anything goes. @Mark cites a case of "splitting" (in WPS) which is an atrocious weakness that can, indeed, be exploited for faster attacks. Padding oracle attacks also work over a byte-by-byte leak which allows for byte-by-byte reconstruction of the plaintext (not the key, but still).

Another, more technical example, is the old PKZip stream cipher: an "homemade" stream cipher which turned out, with all the unavoidability of Death in a Greek tragedy, to be weak; the stream cipher relies on several internal "keys" which can be unravelled one by one. I encourage people interested in cryptography to study that example, because it demonstrates quite well the way a cryptanalyst thinks, and why mere accumulation of operations does not guarantee security; and the attack is light enough to be implemented in practice (total cost is around 238, which is within range of a few hours of computation on a PC with decent programming, not necessarily optimized assembly).

A lot of cryptosystems from before the computer era were breakable on a per-character basis, because they had to be executed by the human brain of the operators, and such tools are not good at using large values or doing a lot of operations. The classical transposition and substitution ciphers (a very large family) tend to fall to character frequency analysis, which is, indeed, a per-character break.


Way to remove rc4 from Linux Cipher Suites

Linux is just an operating system and doesn't understand the concept of “cipher suites”. Each application that supports TLS has its own configuration regarding cipher suites.
For example, for Apache, edit the SSLCipherSuite directive in the configuration file (/etc/apache2/httpd.conf, or wherever your distribution puts it, or one of the files that it includes). For Nginx, edit the ssl_ciphers directive in /etc/nginx/nginx.conf (again, the exact location may vary).
Note that major distributions are likely to ship reasonable defaults out of the box. I would not expect RC4 to be enabled by default on a system where security updates have been applied.


Architecture dependency issue associated with malicious payloads

1. Can an x64 payload work on an x86 architecture
64-bit executables can not work on an x86 architectures because there are two many differences between the architectures.  Beyond the address space limitations there are 64-bit registers that just do not exist.  Parameters for functions are handled entirely differently.  Machine instructions operate differently.
Windows 64-bit contains a lot of code to ensure that there is compatibility for x86 programs to run on an x64 architecture, but the executables have to be written to take advantage of this.  In this case the exploit would have to be built as a 32-bit application, and utilize the WOW64 subsystem.  This subsystem is kind of like a sandbox to run 32-bit applications.  It essentially emulates a 32-bit system for the purposes of execution.
2. Is there a solution for payload delivery that does not have architectural dependencies?
Compilers build for a specific architecture.  As I stated above architecture independent code requires a some time of emulation.  For example, Java uses a virtual machine to run on multiple platforms.  This comes at a performance cost.
3. Would encoding a x64 payload with an x86 encoder create compatibility issues when executed?
I don't know what an x86 encoder is.  If you mean you're transforming x64 machine code into x86 machine code... you might as well just build for x86 to begin with.  Since it's pretty much the same thing.


Why for some SSL websites browsers show extra info, while for others dont

The basic distinction is between a certificate verifying control of a domain, and a certificate verifying the real-world entity behind the domain. With a standard SSL certificate, all that's verified is that the entity with the certificate legitimately controls that domain. It doesn't mean that that's the entity I think it is; I could register bankofamerica.co, and I can then legitimately get a domain-validated certificate for it, and that would show up as a green lock in browsers.

What that box indicates is that CAs have done more validation; EV certificates (the green box) generally require actually verifying the existence and name of the business requesting them. I could not get an EV certificate for that site that says "Bank of America" on it, because I don't have a company called Bank of America, and even if I did the actual person reviewing an EV cert application (unlike normal certs, EV certs aren't automated) would likely be somewhat suspicious at someone claiming to be a bank.

So that's the stated role of EV certs: Verifying that the server sending you a webpage is the correct server for that domain doesn't really help unless you also know that the domain is owned by the company you want to interact with. With Google and Facebook, you know already that their websites are google.com and facebook.com, so I know that I want to talk to google.com, and if I'm talking to the real google.com that's enough. With other organizations, it's not necessarily enough to know I'm talking to the real so-and-so.com; I also need to know so-and-so.com is the actual website I want to be talking to.


How Facebook recommend me a friend (no mutual friend)?

There are many possible use cases for this. Some of them are

Location data - You told that you know this person. Both of you might have been in the same location many times.
Contact Info - You have never synced your contacts online, but the other person might have. He did have your contact information.
Same University - As you told, you both are from same university.
Profile views - As paj28 said in comments, he might have viewed your Facebook profile.

  Does FB use whatsapp contacts as reference?

No. According to WhatsApp website, They share some information including phone numbers, preferences, etc... with Facebook. But they don't share your contacts and other information.

  Importantly, WhatsApp does not share your WhatsApp contacts with
  Facebook or any other members of the Facebook Companies, and there are
  no plans to do so. WhatsApp also does not share your messages with
  Facebook


Is there any explanation (other than storing plaintext) for case-insensitive passwords?

I agree with Emil that it's a question of usability. Making passwords case-insensitive puts an end to the common user error of entering the password with caps lock on.

Also, a case-insensitive password doesn't have to be stored in plaintext, it can simply be converted to lower case before it is hashed. The only security concern with having case-insensitive passwords is that it lowers password complexity, but this can be mitigated by requiring longer passwords or passphrases.


Is there an official standard and/or name for PEM certificate bundles?

There is no real standard for things in "PEM" format. There was a proposed standard called Privacy-enhanced Electronic Mail, from which the "PEM" acronym was derived; however, that standard never gained traction against its competition (PGP and S/MIME) and nobody implements it.

OpenSSL picked up PEM and "enhanced" the PEM format with extra functionalities and headers, without any actual specification or documentation worth that name, so that nowadays, "PEM" really means "whatever OpenSSL produces and can parse". Other vendors followed, e.g. Microsoft, whose software can decode PEM-encoded certificates.

The principle of PEM (Base64-encoded data, with a '-----BEGIN XXX-----' header and corresponding '-----END XXX-----' trailer) has been used for other things; PGP calls it "ASCII armor". The point of that way of doing things is to be able to locate the interesting data within a sequence of text data, regardless of the various tortures inflicted to that text as it is transferred (e.g. sent as e-mail, copy&pasted, included in a Word document, printed and scanned...). This is an important point: it means that the whole point of PEM is to be able to store the certificates together and haphazardly without having to follow a specific, precise standard. In that sense, a standard for a "PEM bundle" would be a self-contradiction: a "PEM bundle" is what you do when there is no standard.

It is not incorrect to call it a "de facto standard".

When you want to encode and send certificates, there are in fact more than two methods; possibilities include:

Encode each certificate separately, using ASN.1 DER encoding (which is standard).
Use PEM to further make these certificates more resilient to ASCII-based transfer; this also allows storing several of them in a single file (that which you call a "PEM bundle");
Store the certificates in a PKCS#7 (aka CMS) SignedData object. A SignedData is nominally a format for embedding data which is signed; but you can omit the data and include exactly zero signature, in which case you have some sort of shell that includes a field for embedding "extra certificates" (nominally, these certificates are there to help in validating the signatures). This is the reuse of an existing standard for something that the standard was not meant to do, but existing software does that. Microsoft calls that a "PKCS#7 certificate" or a "P7B file".
Use a PKCS#7 SignedData but also PEM-encode it (so you could conceptually store several of them in a single file).
PKCS#12 (also known as "PFX"). This format also allows storing other kind of objects, and includes provisions for password-based encryption, so it is commonly used to store a certificate and its private key. (Apparently, nobody ever thought of PEM-encoding a PKCS#12 archive.)

Private keys also have their own formats. For instance, PKCS#1 defines an ASN.1-based encoding for RSA private keys, that OpenSSL will gleefully use and then PEM-encode with a "BEGIN RSA PRIVATE KEY" header. That format may be further wrapped into a PKCS#8 object, which includes an ASN.1-based identifier for the algorithm, and also optional support of password-based encryption; and then, OpenSSL will also encode a PKCS#8 file, this time with "BEGIN PRIVATE KEY" or "BEGIN ENCRYPTED PRIVATE KEY" (no indication of the algorithm in the PEM header), depending on whether password-based encryption was used or not. Alternatively, the raw PKCS#1 format may also be password-encrypted, using the extensions to PEM that OpenSSL implements but does not document (OpenSSL's source code being supposed to be the specification).

To sum up: it is a mess.


Changing windows client form values at runtime

First of all, direct answer to your specific question: take a look at DDE, this can cause the VB form to change almost anything at runtime.

However, I have a better answer for you:
Odds are the VB client app is not using an encrypted protocol (such as SSL) - you can just intercept the network communications, and alter it on the wire. Or, just craft your own messages and send them to the server yourself. It's a bit fiddly, but not too difficult. Or just use something like OllyDbg to grab the data before it goes down to the wires.
(Btw, either way, even if they do encrypt the channel you should be able to get around that, since its encrypted on your client. It is a bit trickier, but still not too difficult. And if you go for OllyDbg the channel encryption is irrelevant.)
In this way it will be possible to perform your SQL Injection, and not even too difficult.

Now, I have an even better answer for you - don't even bother with SQL Injection.
It is very likely, given the simplistic architecture that was common back in VB6 apps, that your client app talks directly to the database. (On the off chance that there is an intermediate server app, this part won't help you).
If that's the case, that means that somewhere in the client app (possibly hardcoded), there are credentials to access the database directly. (If you can't find them, grab them using the previous techniques).
Once you have these credentials - just go directly to the database, using the database vendor's management tool, and have your way with it. The app does not need to be in your way at all.
Not only can you do anything you want with the data and tables, there will be no way to trace this back to you. In fact, it's highly unlikely that it will be possible to prove that anyone did anything wrong... (well, except for the missing data...)


Why does my bank use this verification method?

Login page
  Enter customer number
  Enter password

So far, this is what you're used to: username & password.

  Put debit card into their card reader
  Put in PIN for the debit card and press 'identify'
  Enter 8 digit code generated to complete the login

This is a second factor. The algorithm for generating this number is shared by the bank and your card. The secret is stored with the bank and also in your card. The computer uses the current time as a seed (I assume it is connected). From this, even if one does compromise your machine and sniff your password, they can't use it without the hardware card. The hardware device doesn't report the number back to the computer, so it can't be automatically called if you leave the card in the system.

It would be less secure to use two passwords and pick random characters. The bank I reference in talking about what constitutes two factor security used a method something like this -- multiple passwords that weren't all used at the same time. An attacker monitored the customer's computer over a period of time and walked with a lot of money.

From this, losing your card doesn't compromise your account. Somebody has to physically collect your card, so an attack can't be entirely remote. Somebody can't pick your card up off the street and access your account. They still need an account number and the password. Unless you lose your card with your account number and password written on it (to be straight-forward, we consider this the building a better idiot problem), your odds of compromise are much lower than with just a pair of passwords.


Realistic: Exploiting a computer on BIOS/ hardware level in less than an hour? (Infinite preparation time)

This video demonstrates a complete re-soldering of a laptop BIOS chip in 10 minutes: https://www.youtube.com/watch?v=HMAxv6lgSuw

Joanna Rutkowska (girl behind the Blue Pill rootkit) discusses the feasibility of a "Ring -3" rootkit of the SMM which resides on the BIOS chip: http://theinvisiblethings.blogspot.com/2009/03/attacking-smm-memory-via-intel-cpu.html

And this presentation talks about the implications of hacking the SMM, giving you full access even remotely, fully undetectable.  Even the user monitoring network connections for suspicious traffic could have an SMM rootkit fool the network card beyond the driver level: http://me.bios.io/images/6/61/Ring_-3_Rootkits.pdf

The attacker, knowing the laptop beforehand, would use the technique to hack SMM on a chip he got for cheap off eBay, then bring in the chip and a soldering iron for the actual attack.


Could a desktop application disclose location even if a VPN is used?

As you noted, "languages/keyboards" may help.

But it can be improved with "TimeZone"

Also, if the application has enough privilege, it may:

Ask the operating system what is the location
Ask the list of Wifi in range and if any one of them have a known location
If it can read your personal files it may - for example - reads pictures location metadata.

More complicated but feasible:
- If it can reads the host file, it may use domains with known geoip DNS to detect where the computer was before using the VPN

Recent example - on android: an application without the "location" privilege (nor the "picture" one, but irrelevant here) could take a picture and reads it's metadata to locate the user. So a VPN would be useless if the phone OS had register an accurate position using GPS or Wifi: https://www.checkmarx.com/blog/how-attackers-could-hijack-your-android-camera


Usually, each machine on which the mail transits:

adds a Received: header stating from where the email seems to come;
announces its name (which could be an IP address) to the next machine, which may or may not include that information in its own Received: header.

Here is an example in one of the 100+ spams that I daily receive:

X-Original-To: pornin@bolet.org
Delivered-To: pornin@bolet.org
Received: from davisandsons.net (213-238-65-230.adsl.inetia.pl [213.238.65.230])
        by arges.bolet.org (Postfix) with ESMTP id 7951068C0D4
        for <pornin@bolet.org>; Fri,  7 Oct 2011 21:49:22 +0200 (CEST)
Received: from apache by davisandsons.net with local (Exim 4.67)
        (envelope-from <minusculesxdl3@kurdogluholding.com.tr>)
        id XD1AV6-73T5L6-H9
        for <pornin@bolet.org>; Fri, 7 Oct 2011 20:46:35 +0100
To: <pornin@bolet.org>;
Subject: Re:web site
(...)

Header lines are added in "reverse order": each mail server adds its line at the beginning of the header. So here my mail server (arges.bolet.org) received a connection for a mail which, at the SMTP level, was destined to me (over the connection, the other machine sent: RCPT TO: pornin@bolet.org). As part of the SMTP protocol, that machine first sent an HELO command in which it claimed to be "davisandsons.net"; my mail server looked at the source IP address (213.238.65.230) and did a reverse DNS resolution on it, yielding "213-238-65-230.adsl.inetia.pl" (from an ISP in Poland). It turns out that "davisandsons.net" can be resolved to a quite different IP address, nominally from England.

This first Received: header was added by my mail server, so it is trustworthy. The next line, and all subsequent lines, however, were sent as is by that Polish machine which began the conversation by claiming it was in England, a blatant lie, thus not the greatest way to build mutual trust. That header could be completely phony. Assuming it is not bogus, it would indicate that the mail originated from the local machine, by a user called "apache". The probable scenario is then: the home PC of some poor guy in Poland is an infected zombie, which relays spam. The infection might have began through a poorly configured Apache Web server on that machine.

(Spamassassin rated that specific spam with a whooping 20.5 score, and I automatically zap incoming emails with a score of 5.0 or more.)


Can't understand how stuxnet was bogusly signed

It is not the certificates that have been stolen, but their private keys.

The formulation is indeed ambiguous. You should read it this way:

  Its device drivers have been digitally signed with the private keys (of two certificates) that were stolen from separate well-known companies, JMicron and Realtek, both located at Hsinchu Science Park in Taiwan

(Parentheses and emphases are mines.)

I suppose the term certificate has been added to help the reader understand that they're talking about asymmetric cryptography, certificates, and trusted third parties.


Protect IP Address and location from Twitter

VPN is enough.
You can do it in 2 ways:

subscribe to a VPN service that may allow you to choose your server from a very wide range of locations

use browser-integrated VPNs like Opera has or browser modules like browsec (which can be free or payed/premiums that allow more locations/servers to be selected).


A core dump, either of the entire system, or single executable, is the entire contents of that processes' memory, or in the case of the system, everything's memory, written out to a file. There can be a lot of data in such a dump - here's an abbreviated form of the memory space of gvim, which I'm currently running:

pmap 19133
19133:   gvim fsstate.py
0000000000400000   2184K r-x--  /usr/bin/gvim    ; program code
0000000000821000    100K rw---  /usr/bin/gvim    ; program code again
000000000083a000     52K rw---    [ anon ]
0000000000a39000     56K rw---  /usr/bin/gvim    ; more program code
0000000002469000   3592K rw---    [ anon ]
0000003d53c00000     16K r-x--  /lib64/libuuid.so.1.3.0 ; shared object
0000003d53c04000   2044K -----  /lib64/libuuid.so.1.3.0
0000003d53e03000      4K rw---  /lib64/libuuid.so.1.3.0
0000003d55000000     28K r-x--  /usr/lib64/libSM.so.6.0.1
0000003d55007000   2044K -----  /usr/lib64/libSM.so.6.0.1
...
00007f46d66c7000     20K r----  /usr/share/locale/en_GB/LC_MESSAGES/gdk-pixbuf.mo
00007f46d66cc000      4K r----  /usr/share/locale/en_GB/LC_MESSAGES/libc.mo
00007f46d66cd000     56K r----  /usr/share/locale/en_GB/LC_MESSAGES/gtk20.mo
00007f46d66db000     28K r--s-  /usr/lib64/gconv/gconv-modules.cache
00007f46d66e5000      4K rw---    [ anon ]
00007fffc9ed9000    132K rw---    [ stack ]    ; stack!
00007fffc9f9b000      4K r-x--    [ anon ]
ffffffffff600000      4K r-x--    [ anon ]

From that address space, shared objects wouldn't be dumped, but everything else, stack, heap, would be. Addresses will be relative to certain versions of shared objects and potentially with ASLR they may not line up process to process. A kernel dump can be configured to contain varying amounts of information, from small dumps to everything.

What does this tell you? Exactly the state of the system or program at the time of being dumped - what it has on the stack (and so probably which function it is in). Most core dumps also contain other useful information like what is in the registers of the processor at the time of the dump.

In terms of how you work out what is going on, EIP or RIP on x86 (x64) will tell you at exactly which memory address the process was executing. rbp or ebp will tell you where abouts on the stack your function is working. You'd expect to find local variables there. You could also potentially look for all system calls and their arguments made in a core dump.

All of this serves to tell you what is going on with a process at that specific point in time. It isn't just a tool for pen testing either; it's possible to analyse core dumps as a form of debugging applications, particularly where running debuggers is hard or impossible. For example, you might analyse a kernel core dump to work out why the kernel crashed (what was it doing when it panicked?) rather than attaching a debugger and trying again - it also allows other people to send dumps to you for analysis.

How does this help with pen testing? The same way debugging helps with pen testing. You can see what's loaded in memory, what the current state is. You can work out what a process might be doing when you took the dump and perhaps most crucially, any data stored in any executable in memory (heap, stack etc) will also end up in the core dump, including passwords stored as plaintext in memory.

What do the analysis tools do? Look for patterns and structures indicative of a potential exploit (or error, if you're after debugging). A full explanation of that is probably beyond the scope of this box - there are many books dedicated to techniques for analysing memory dumps. Much of this is also system and architecture dependent; techniques for Windows x86 are different to techniques for Linux on MIPS.

As an example of something that might be indicative of an error, here's an example AviD will really appreciate:

push    rbp
mov rbp, rsp
sub rsp, 32
mov QWORD PTR [rbp-24], rdi  ; this is a char* argument stored on stack
mov rdx, QWORD PTR [rbp-24]  ; and this is a pointer loading it into a register
lea rax, [rbp-16]            ; this is only 8 bytes further down
mov rcx, QWORD PTR [rdx]     ; load contents of rdx into rcx
mov QWORD PTR [rax], rcx     ; put those 8 bytes to rbp-16
mov rcx, QWORD PTR [rdx+8]   ; load next 8 butes
mov QWORD PTR [rax+8], rcx   ; write to rbp-8
mov rcx, QWORD PTR [rdx+16]
mov QWORD PTR [rax+16], rcx  ; write to rbp
mov rcx, QWORD PTR [rdx+24]
mov QWORD PTR [rax+24], rcx  ; write to rbp+8
mov rcx, QWORD PTR [rdx+32]
mov QWORD PTR [rax+32], rcx  ; write to rbp+16
mov rcx, QWORD PTR [rdx+40]
mov QWORD PTR [rax+40], rcx  ; write to rbp+24
mov rcx, QWORD PTR [rdx+48]
mov QWORD PTR [rax+48], rcx  ; write to rbp+32
mov rdx, QWORD PTR [rdx+56]
mov QWORD PTR [rax+56], rdx  ; write to rbp+40
lea rax, [rbp-16]

As you can see, the first space available to this function on the stack for local variables was rbp-16 and below. Above that, we've just happily clobbered a stack frame with a whole pile of data, probably causing the program to crash. However, this code may well indicate a possible exploit. Looking for patterns like that in a crash dump is what makes them useful, and moreover rip in this case will tell you exactly which memory access caused the problem, because it'll point at the offending instruction (in theory).

In case you're wondering, the offending piece of code was simply a memcpy from an unbounded buffer into a much smaller target space. The function call to memcpy was optimised out.


Whether TLS session resumption reuse the symmetric keys?

TL;DR: Secrets are reused, but encryption keys are not reused.
With TLS 1.2 and lower the master secret was reused though and the encryption keys were derived from this. But this key derivation includes connection specific random data, so the keys are specific for the connection and not for all reuses of the same session. Knowledge of master secret (for example due to an information leak like in Heartbleed) and sniffing of traffic allowed the recreation of the encryption keys though, and thus reusing the same session for too long might impact forward secrecy.
With TLS 1.3 session resumptions works completely different. Basically it just replaces the certificate based authentication with a smaller and faster PSK based authentication (with a previously shared secret), but the key exchange works as with a "full" handshake. Thus not even the master secret is reused and forward secrecy is not impacted.


How to easily remember lots of different passwords?

To remember passwords, type them often. You can remember dozens of passwords if you type them daily -- that's muscle memory, the same kind which is used by martial arts practitioners, so remembering many passwords is like being a Kung fu master (albeit in a slightly less awesome way).

Bruce Schneier, well-known Chuck Norris imitator, recommends writing down your passwords and keeping them in your wallet. This makes sense because you are both trained and highly motivated at maintaining a high level of physical security on your wallet. I would double that with a copy of the same password sheet somewhere in your safe, so that you could recover from a wallet theft (i.e. logging again in all the sites and change your password). Also, a piece of paper has no battery which needs recharging.

(Caution: your smartphone is not a good wallet. Physical security on your phone is much lower than the one you apply on your wallet. Unless you are in the habit of flourishing your wallet at arm's length while walking in the street.)


How to encode a CMS or S/MIME PEM file with OpenSSL not encrypted or digitally signed?

CMS has options for several types of messages including both signed and unsigned ones (and so does SMIME which is based on CMS) but the openssl cms -verify subcommand can only handle a signed message; -inform PEM and no -content further requires CMS (not SMIME) and 'embedded' (not 'detached') format. Even though the purpose of your command is to discard the signature, your command requires the signature be there before it can be discarded.

To create such a signed message, you must have a keypair and certificate, but since the receiving command uses the seemingly contradictory combination -verify -noverify this certificate doesn't need to be official, it can be a selfsigned (dummy) cert you create yourself, which with openssl is easy:

# to create an RSA keypair and selfsigned cert for test
openssl req -newkey rsa:2048 -keyout testkey.pem -x509 [-days N] [-subj name] -out testcert.pem
# -subj name has the form /attr=value/attr=value/... where common attrs are
# C (Country) ST (State/Province) L (Locality) O (Organization) OU (Org. Unit) CN (CommonName);
# if you don't specify -subj you will be prompted for these fields
# (unless you or someone has modified the config file on your system).
# -days N defaults to 30; for testing longer times like 10 or 20 years are popular.
# By default the keyfile is password-encrypted, and you must re-enter the password
# to use it. For test this isn't needed; to avoid it add -nodes .

Then do:

openssl cms -sign -in $datafile -signer testcert.pem -inkey testkey.pem -nodetach -outform PEM -out $outfile
# possibly add -noattr; the command you posted works for SignedData
# either with or without signedAttributes, or even a mixture,
# so I can't say whether you should test with, without, or both

(Change the filenames if needed to fit your environment or procedure(s).)


Possible to use sqlmap when URL changes after each request?

Tools are seldom written generic enough to handle obscure test-cases. It might be tempting to blame the tool for its shortcomings, but more often the problem is obscure/non-generic, and should be solved by other means.

You can solve this problem by creating a small webapp that acts as a proxy between the target application and your tool.

The tool accept the vulnerable input as a parameter, and forward it to the application as required.

Here is an untested python/flask code to illustrate how this can be done:

from flask import Flask, request
import requests

i = 0

app = Flask(__name__)
@app.route("/")
def app_proxy():
        sqli = request.args.get("sqli",None)
        data = {"somekey":"someval","vulnerableparam":sqli}
        resp = requests.post("http://target.com/login?%s-%s.FormSubmit"%(i,i+1),data=data)
        i += 1
        return resp.text, resp.status_code

app.run(host="127.0.0.1",port=8008)

After you have started the flask-app, you should be able to use sqlmap against http://127.0.0.1:8008/?sqli=value


Encrypting data within SQLite database in Java - How to store key?

When the user do the first login your software will ask for a new password.
At this time the DB should be empty.

Now you have a UserPassword and an empty DB.
So the software generate a new random DBdataKey that will be used to encrypt/decrypt the DB contents. To encrypt/decrypt use one of the many known algorithms, like AES or similar one.

Now you create 2 random salt string: PasswordSalt and DBdataKeySalt.
Store PasswordSalt and DBdataKeySalt in the DB as a clear text.

Use a hash function like pbkdf2 (or something like SHA2 or better) with UserPassword and DBdataKeySalt to obtain a DBdataKeyEncryptionKey

Now:
DBdataKey is the key you use to encrypt/decrypt the DB contents
DBdataKeyEncryptionKey is the key you use to encrypt/decrypt the DBdataKey

Use a hash function like pbkdf2 (or something like SHA2 or better) with UserPassword and PasswordSalt to create HashedSaltedUserPassword, a salted-hashed version of the UserPassword, then use DBdataKey to encrypt HasedSaltedUserPassword before storing it in the DB.

From now on you can use DBdataKey to encrypt/decrypt the data to/from the DB.

Now, when the user opens the application, you ask him for the password, then use the inputed password with DBdataKeySalt (which is stored in cleartext) to regenerate the DBdataKeyEncryptionKey, and then use the obtained DBdataKeyEncryptionKey to decrypt the DBdataKey , and so you can use the decrypted DBdataKey to read the DB.

Now use the DBdataKey to decrypt the HashedSaltedUserPassword and compare it with the one you regenerated using the inputed password and the PasswordSalt (which is stored in cleartext) just to double-check that the login information is correct.

If the user inputs the wrong password, when you use the DBdataKeyEncryptionKey to decrypt the DBdataKey the decrypt function will give you a different value (garbage). Using that (wrong) value to decrypt the HashedSaltedUserPassword will result in more garbage values, which won't match the hash.

When the user changes the UserPassword  then you only need to decrypt the DBdataKey  with the old password and re-encrypt it with the new password, but the DBdataKey won't change, so you won't need to re-encrypt the db contents when the user changes its password.

Reference: I haven't invented anything, this is just a mix of two well known techniques:

How user-login & password salting/hashing is done
How on-the-fly disk encryption can be implemented (applied to DB encryption/decryption)


For the answer to this check out RFC 2104, em mine:

  A well-known practice with message authentication codes is to
  truncate the output of the MAC and output only part of the bits
  (e.g., [MM, ANSI]).  Preneel and van Oorschot [PV] show some
  analytical advantages of truncating the output of hash-based MAC
  functions. The results in this area are not absolute as for the
  overall security advantages of truncation. It has advantages (less
  information on the hash result available to an attacker) and
  disadvantages (less bits to predict for the attacker).  Applications
  of HMAC can choose to truncate the output of HMAC by outputting the t
  leftmost bits of the HMAC computation for some parameter t (namely,
  the computation is carried in the normal way as defined in section 2
  above but the end result is truncated to t bits). We recommend that
  the output length t be not less than half the length of the hash
  output (to match the birthday attack bound) and not less than 80 bits
  (a suitable lower bound on the number of bits that need to be
  predicted by an attacker).  We propose denoting a realization of HMAC
  that uses a hash function H with t bits of output as HMAC-H-t. For
  example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function
  and with the output truncated to 80 bits.  (If the parameter t is not
  specified, e.g. HMAC-MD5, then it is assumed that all the bits of the
  hash are output.)

Truncation also reduces the amount of data transmitted over the wire so bandwidth requirements are reduced.


Are there any extra security risks with leaving wireless enabled while ethernet is connected?

Most OS prefer using ethernet if available, because it is normally faster and more reliable than WiFi. I would not rely on it, though.

For snooping, my basic stance is to consider that any network is potentially vulnerable to hostile intrusion, so if some sensitive data must leave my machine, then SSL or SSH must be used. Regardless of the presence of a cable sprouting out of the back of the computer.

Apart from snooping, a potential and amusing vulnerability induced by a machine which does both ethernet and WiFi would be if the machine acted as a router, thus granting access to the ethernet local network to an attacker who succeeded in subverting the WiFi part. Desktop operating systems do not normally act as routers (in Linux, routing must be activated explicitly, and desktop distributions do not do it by default), but I would not be overly surprised if routing abilities were activated as part of the installation of some software packages (especially virtual machine managers, and VPN software).


How to generate short fixed length cryptographic hashes?

The cryptographical hash function with output size n has √n collision with probability 50% due to the birthday paradox.

You took 3 hexadecimal digits which means you get 12 bits. After 26=64 hash generations, you will see a collision with 50% probability.

Collision in hash functions is inevitable due to the fixed-sized output space but the arbitrary length of input space. Pigeonhole Principle tells us that collision is inevitable.

If you want low collision probability you have to use larger output as 128-bit. For 128-bit we expect at least one collision in 264 hashes with 50% probability.

We are not accepting that the system is secret, we assume it is known. E-Mails are not secret and any attacker can create his code by using your source code. An attacker or a group of attackers can try to attack your system due to short token. The mitigation is increasing the token size.

For most applications using read("/dev/urandom", 16) will be fine or you can use HMAC($email, $key) without trimming. Copy and paste shouldn't be a problem for the user.

If you need higher resistance you may use digital signatures; first hash the e-mail then sign.


No. A collision for H is a pair of inputs m and m' such that m ≠ m' but H(m) = H(m'). It follows that H(H(m)) = H(H(m')), and also H(H(m)) xor H(m) = H(H(m')) xor H(m') , and so on.

Thus, any collision for H is also a collision for all your functions H2, H3, H4... These functions are thus in no way more secure than H when considering resistance to collisions. They may very well be less secure, even, since your premise is wrong:

  If the attacker could find a collission in H(X), he would need to additionally find a collission in H(H(X)) too, to be able to have a collission in H2(X) = H(H(X)) xor H(X).

This is not true. If an attacker finds a collision for H that also collides for H(H), then he gets a collision for H2. But that does not work the other way round: there is no absolute requirement for a collision on H2 to be such that it is a collision on both H and H(H).

Thus, all collisions for H are collisions for H2 (and H3, H4...) but H2 can have collisions of its own that are not collisions for H. Finding collisions on H2 can thus only be easier than finding collisions on H.


Network diagram based on Cisco ACL and other firewall rules

If you use Cisco it might be easier to build a network topology diagram using Cisco Discovery Protocol than firewall rules or ACLs even if manually done.


How to share penetration tests results + remediation plan to third party companies without exposing one's self

Normally, these kind of audits simply require an executive summary to be disclosed.
While security by obscurity is a universally recognized anti-pattern, it doesn't mean you have to disclose full details of your vulnerabilities.
Problem 1: the self assessment
I trust the professionality of your DevOps guy. Without having to offend his skills, most external companies demand a reputable third party to perform the security assessment.
Your DevOps guy can be honest and professional, and provide real insights on the security. Or your DevOps guy can be insufficiently educated on security and miss important vulnerabilities. Or your DevOps guy can be a former Volkswagen employee (please, please, allow me some humour sometimes) and pretend there are no vulnerabilities just to make a good impression.
This is why companies demand an external trusted and reputable party
Problem 1.5: the cheap assessment to save money is a clear indicator that this penetration test is unlikely to work, irregardless that it found real security holes.
If you hire a reputable security company, they will do a more thorough test.
Problem 2: what to disclose
In general, these external suppliers/customers want to get an indication of your security levels to have business with your company.
An executive summary (that is, literally, a summary made to be read by high-level executives that don't work with technical things) contains a list of known vulnerability types associated to a severity score.
It doesn't contain details on how to exploit those.
Problem 3: mitigation
Please expect the suppliers to demand you to fix high-level vulnerabilities and re-assess the sytem.
Often they require to fix vulnerabilities rated >= 6 or 7, depending on the requirements. And then you will have to go through another scan and confirm the agreed vulnerabilities are not present anymore in the system
My case
Source: I was directly involved in such an activity.
In the past years, we had a code scan from Veracode as requested by one of our US customers before deploying our code on their premises.
Veracode is not a penetration test, it is an automated code static analysis tool. We had real pen-tests but they are out of the scope of this example.
It was part of the contract to share the full report with the customer, as they happened to sponsor the scan.
Later, we had an audit request from a Swiss bank we wanted to have business with, but they didn't request to perform a security scan, they just demanded that we did and provided an executive summary.
We responded with the front page of that Veracode audit, displaying their logo and our company name. A few pages later, a table showed the list of remaining vulnerabilities (yes, we had, and yes, we fixed high-priority ones!) that were all scored < 6 out of 10. We gave that to our prospect as well.
We knew exactly where our vulnerabilities were, because Veracode highlighted file name and line number of suspect code. We never had to disclose such details to Swiss customer.
I don't know what happened next, but probably we got the contract. I should ask my Sales Account Manager for details


Is 1024bit Diffie Hellman key exchange secure?

Comparing key strength between symmetric encryption and asymmetric key exchange is like comparing apples with oranges: it is doable (they are both tasty fruits) but tricky and full of subtle details. To break DH, the best known method is trying to solve the discrete logarithm problem, for which the best known algorithm is a variant of Index Calculus which contains parts of the General Number Field Sieve algorithm (GNFS is for factorization, but discrete logarithm modulo a prime, and factorization of a big non-prime integer, are mathematically related problems). Such attack algorithms require quite a lot of horsepower, in particular lots of very fast RAM; on the other hand, breaking a symmetric key through exhaustive search (that's what we mean by "n bits of security") requires only CPU, but no RAM, and is much more easily distributed over many nodes. So the apples are CPU and the oranges are RAM. The really only common measure for both is the dollar; but asking the financial cost of breaking a 1024-bit DH key, or the financial cost of breaking an 80-bit symmetric key, is kind of meaningless, since this goes into amounts where the dollar ceases to be well-defined (as an order of magnitude, dollars can be used to measure amounts up to the US national debt, but not much higher).

These caveats did not prevent various researchers and standardization organisms from making apple/orange comparisons. This site makes a good job of listing those security estimates, with handy online calculators. As a baseline, they about all agree that 1024-bit DH is close, in security, to what a 77 to 80-bit symmetric key offers. Note that a 64-bit symmetric key was broken in 2002, and 77-bit is "only" 8192 times more difficult.

Since the best known discrete logarithm attack (IC with GNFS) has many common parts with the best known factorization algorithm (GNFS), DH with a k-bit modulus should be roughly equivalent to a RSA key with a k-bit modulus. So you should use 2048 bits for DH too.

In your list, "AES-256" is overkill (AES-128 would still be "more secure" than 2048-bit RSA or DH), but mostly harmless overkill (AES-256 is only 40% slower than AES-128).


What's the difference between X.509 and PKCS#7 Certificate?

You've evolved to mostly right, but to add several points
and expand on @CoverosGene' answer more than I felt comfortable doing in an edit:

X.509 defines a certificate (and some other things not relevant here) in ASN.1,
a (very!) general data structuring method which has several defined encodings, of which
DER Distinguished Encoding Representation is quite common and is used here.

PEM format -- for several types of data of which a certificate is only one --
is much as you say just binary (DER) data encoded in base64 (edit) broken into lines normally every 64 chars (but there are variations), plus header and trailer lines
consisting of dashes + BEGIN or END + the type of data, in this case CERTIFICATE + dashes.
Those lines look redundant to a human but they are expected and mostly required by software.
PEM (Privacy Enhanced Mail) was actually a complete standard for secure email that has now
been mostly forgotten (see below) except for its encoding format.
(edit) As of 2015 there is RFC 7468 describing in detail most use of 'PEM' formats for modern crypto data.

PKCS#7 was defined by RSA (the company, not the algorithm) as a multi-purpose format
for encrypted and/or signed data. It was turned over to IETF and evolved into
CMS Cryptographic Message Syntax in RFC 2630, then RFC 3369, then RFC 3852, then RFC 5652,
hence the wording of the Windows (inetopt) prompt. "PKCS#7" is often used to mean both
the original RSA PKCS#7 and the IETF successor CMS, in the same way "SSL" is often used for
both the original Netscape protocol and the IETF successor TLS Transport Level Security.

The .p7b or .p7c format is a special case of PKCS#7/CMS: a SignedData structure containing
no "content" and zero SignerInfos, but one or more certificates (usually) and/or CRLs (rarely).
Way back when this provided a standard way to handle (edit) the set of certificates needed to make up a chain (not necessarily in order).

PKCS#7/CMS is (are?) also ASN.1 and depending on circumstances can be either DER or BER,
a closely-related encoding with some very minor differences that most DER decoders handle.

While PKCS#7/CMS like any DER or BER object can be PEM-formatted, I've not seen any implementation other than
openssl (edit) it is rare for certs. (Java CertificateFactory can read PKCS7/CMS-certs-only from DER or PEM, but CertPath.getEncoded writes it only to DER.) In contrast both DER and PEM formats for a single cert are common.

PKCS#7/CMS is also used as the basis for S/MIME secure email (multiple rfcs starting from 5751).
Basically PEM encoded PKCS#7 into ASCII text which email systems of the 1980s could easily handle, while
S/MIME represents CMS as MIME entities which are encoded in several ways modern email systems can handle.

OpenSSL confused matters by implementing, in order: a pkcs7 command which handles
the certs-CRLs-only case not full PKCS#7; a crl2pkcs7 command which actually handles
CRLs and certs, but again not the rest of PKCS#7; a smime command which actually handles both S/MIME
and PKCS#7/CMS for most cases of encrypted and/or signed messages; and a cms command which actually handles
both S/MIME and PKCS#7/CMS for a more complete set of cases.

So I would describe the options as: a cert in PEM or DER format; a (single) cert
in a PKCS#7 container or for short just p7, and mention PEM only in the rare case it applies;
or a cert chain in PKCS#7 or p7. The semantic difference between a single cert and a cert chain
is at least as important as the format difference between a cert by itself or in a container.

And this doesn't even reach the widespread confusion between a certificate by itself (for some other entity, most often a CA root or anchor) and the combination of privatekey PLUS certificate -- or usually chain -- that you use to prove your own identity, for example as an SSL/TLS server or when signing S/MIME email. That uses the originally-Microsoft PFX Personal Information Exchange format, or its standardized form PKCS#12 or "p12".


Phong Q. Nguyen, one of the main researchers on attacks on NTRU, uses Victor Shoup's NTL library, which contains an implementation of the LLL algorithm. That's C++, not Java; but this is the kind of number crunching job where the extra efficiency of low-level languages like C++ is handy. 95% of a given application code is not time-critical, and 95% of the remaining 5% is I/O bound (network I/O, disk I/O, RAM bus I/O maybe). Most hardcore crypto jobs (in particular attacks which need a lot of muscle) live in the 0.025% of code where everything happens in CPU L1 cache, and at that place properly optimized C or C++ code is typically 2 to 4 times faster than properly optimized Java code.

Anyway, to understand attacks on NTRU you will need to grasp some rather intricate mathematics, at which point something as trivial as a change of programming language should not bother you.

A good starting point for attacking a cryptosystem is to actually implement it yourself -- having your own implementation is handy if you want to print intermediate values or similar things, but the main reason is pedagogical: the process of implementing the algorithm is what makes you understand how it works, down to its fine details. Reusing existing code will deprive you of all this learning.

(Yes, I wrote that C++ is "low-level". Sue me.)


Data on VPS is safe, or can accessed on rent VPS Virtual Server?

The owner has the access to the machine which is equivalent (or more) of physical access to a physical machine. For example, he can clone it, event silently while it is running, and then "play" with the clone in a safe sandbox environment.

There is only a very limited defense against it, for example you can use disk encryption on the virtual machine in a configuration, where the decryption keys are only in the RAM. It still doesn't avoid the data stealing from the hosting side, but significantly hardens it: he can't "play" only with the persistent disk image, but requires also to analyze your disk encryption software to extract the key from it in runtime. In the best case, you can make this data stealing so hard as cracking a binary software image.

There are various algorithms to process encrypted data without decrypting it, but this all is only a hot research topic today.

The only for sure defense against such stealing is if the sensitive data is not on the VPS. For example, the VPS can be a datastream-level gateway to an out-of-VPS service which uses strong cryptography (including MitM protection) - if the keys are unreachable from the VPS, the hosting will have no way to decode what is going on.

You have no way to do any similar hardcore trick on Windows.


Why is this SSL handshake failing with iPad?

You should try a ssldump to see what happens for a successful connection from a browser, in particular what ciphers were announced by the client and which one was chosen by the server. This tool can also be used to see what the server supports.

Another possibility is the use of extensions. In SSL/TLS, the ClientHello message can contain extensions, which servers are supposed to skip when they don't understand them. Some (buggy) servers instead refuse the connection when they see extensions that they do not support.

To see exactly what the iPad sends, down to the last byte, use tcpdump or one of these nifty graphical wrappers like Wireshark. Then you may make a small program which opens a TCP connection to the server, writes a ClientHello, and see if the server responds with an alert message or a ServerHello. By trying variants, you should be able to pinpoint what exactly makes the server unhappy with what the iPad sends (diagnosis is not healing, but that's a step in the right direction). You could use TestSSLServer's source code as basis for this program.


Can you connect to a mobile network without a SIM?

From Wikipedia: SIM card:

Authentication key (Ki)
The Ki is a 128-bit value used in authenticating the SIMs ....
The SIM card is designed to prevent someone from getting the Ki by using the smart-card interface. Instead, the SIM card provides a function, Run GSM Algorithm, that the phone uses to pass data to the SIM card to be signed with the Ki. This, by design, makes using the SIM card mandatory unless the Ki can be extracted from the SIM card, or the carrier is willing to reveal the Ki ...

Thus, by design a SIM card (or something similar, like eSIM) is designed to be mandatory for authenticating against the network. There are some weaknesses (also described in Wikipedia) which might allow to extract Ki, but even then a SIM card with Ki inside would have been needed in the first place.
Emergency calls don't require authentication though. They only require identification of the device, which can be provided without SIM. But for anything which should be payed for the billing contact need to be known - which requires authentication. And since authentication is provided by the SIM it means that there need to be an associated SIM card or eSIM.

... would it be possible to connect to the mobile network without using the SIM, by manually entering the information on the device?

There are cryptographic operations done on the SIM based on the authentication key. It is not possible to just do these simply manually, but it can be done by software: a SIM card is basically software too, only on a protected hardware.

Can this be done on an average phone?

One would need to have deep access to the software stack of the phone for this. There is no interface for this on average phone.


shellcode JMP-CALL-POP technique ( Segmentation fault (core dumped) )

ookkk the code is okay the problem is solved :D by giving writing permission for the .TEXT section ...

not work :

  ld -o addr addr.o

> [ 1] .text             PROGBITS        08048060 000060 000037 00  AX 0   0 16

work :

  ld -N -o addr addr.o

 [ 1] .text             PROGBITS        08048060 000060 000037 00 WAX  0   0 16

  -N
  --omagic Set the text and data sections to be readable and writable.


Is penetration testing included in the job of a NOC?

If you are looking for job titles, then the one you used as a tag is the most relevant: penetration tester.

SOCs and NOCs might not do any 'hacking' at all.


Is there any useful Android app for security assessments?

dSploit is great and packs tons of features and has wrappers for nmap (and other tools like hydra) and can also search the national vulnerability database. It also has many MITM attacks and login crackers(hydra). But its not available on the Play Store though. But APK can be downloaded here

Another tool worth mentioning is Interceptor-ng. Which is basically like/is wireshark for your Android device. Its available on the Play Store

Network Discovery is also pretty good and light; and can scan for hosts and open ports. Its available on the Play Store.

G-Mon is a powerful wardriving scanner and GSM / CDMA / EVDO / UMTS and LTE Netmonitor. And is great for scoping out access points. Its available on the Play Store.

WiFiKill is a "wifi jammer"/DoS tool which can deauthenticate an entire network (you need to be connected to it; just in case your wondering) or a single device. Its not available on the Play Store but can be downloaded here.

Special Mention:
bcmon is a tool(experimental) which allows monitor mode on Android devices which has the Broadcom chipset. I've never used this tool and hence can't offer much of an opinion on it. More info can be found here.

Good Luck.


Are saved passwords in browsers secure, when stored online?

As with pretty much everything that is managed by cloud providers, secrets management as a service is susceptible to hacking attacks, HOWEVER, I would trust Mozilla's and Google's secure secrets management capability and infrastructure security in general much more than keeping those secrets on tools running on my machine.
To your last question, all major cloud providers offer you the capability of complete deletion of sensitive information they store, and are legally bound to fulfil that obligation when you are using their products.


Are any TLS attacks practical for an attacker who can only observe traffic?

There are no practical feasible attacks for a purely passive attacker with severely limited resources (i.e. no government or similar) against currently used TLS standards (TLS 1.2 and better, but even TLS 1.0 is still sufficient).  This does not mean though that specific implementations of these standards might be a problem, for example due to bugs or deliberately weakened or backdoored random generators. Though at the moment there are no publicly known cases for such weaknesses.


Invisible, Non-invertable, public, robust, replicated watermarking scheme?

Quick answer: not easiliy.

Your requirement #1 is in opposition to the others.

Let's look at a counter example.  #1 requires the changes to be imperceptible to humans.  That means you cannot add to, take away from, or modify the visible image.  For starters, that opens the "analog hole", where a photo of the screen masks the watermark data.

Requirement #3 says it needs to be robust.  Developing a scheme to remove or obscure a watermark today is done in two ways.  You can compare a watermarked file to an original in hopes of deriving a way to reverse every change made by the watermarking process, allowing the attacker to write a tool to "unsign" the images.

But that's not the only valid attack.  The attacker can compare two watermarked files against each other.  Remember, the attacker doesn't need to remove the watermark data to be successful.  All he has to do is introduce enough doubt that you can't prove if the file came from the image distributed to client A or the image distributed to client B.  In a courtroom, the content producer is suing client A for copyright infringement, but he can only collect from A if he can conclusively prove it came from A and not B.  (The success rate of this attack grows even further when the attacker incorporates more watermarked copies than just two.)

If I could issue visibly different media to A and B, then the info could not be removed so easily.  Let's say it's an animated video where I have a scene with a background shelf cluttered with household stuff.  I can render it with a blue teapot in video A, and a red vase in video B, and repeat this concept in as many scenes as necessary to help with #5.  (The same concept could perhaps be done with a percussion instrument in a music track.)  Any copy will uniquely identify the two, but requirement #1 says they cannot be perceptibly different.


Lost my PGP private key, Is the backup on keyserver the samething?

A key server does not provide backups. The task of the key server is to make it possible to find the public keys of others, which means only the public keys gets published.


Why timestamping chain is better than "code signature" chain?

Timestamping is a special kind of signature already.

TS = Sign(Hash(info | X) | time)

The renewal is :

TS' = Sign(Hash(TS | info) | time)

Of course, you could sign the original info with the new certificate and not using this technique. But this sometimes might not be possible or practical. For example when dealing with a contract, you would want to prolong the validity without having the party to meet again. Furthermore, the timestamping prolongation also ensures that the content of the original document remains the same during the procedure.

See source


Is it illegal to publicly reveal security flaws in a service?

If you wish to educate other people on how to secure their site more effectively, i can see no harm in that as long as you do not mention the vulnerable site at all or even hint at it.

A number of sites detail how to perform exploits and how to secure yourself, but they never encourage users to do anything illegal or post targets because that's what gets the police involved.

If you still want to post it on a blog, i strongly suggest you see a lawyer.


How to prevent popping up a login dialogue using a malicious hotlinked image and HTTP Basic Auth header?

I think I know what's happening with you. Actually, that's exactly what I do with the image in my "about me" section in my StackExchange profiles. It's a .php file that grabs some information about the visitor (IP address, browser type, whether the visitor made the smiley happy or not, etc.). I simply rewrote the URL to show two different images that are in fact the same .php file.

If you allow people to hotlink files (especially ones automatically requested by the browser, such as images), then there's nothing you can do about this. The user's browser will connect to the other server (on which the image is hosted) and it will request the image from there. To the browser, the link genuinely points to a .png image. It cannot tell the difference, neither can your server/site.

This is a social engineering attack in which the attacker hopes that the user uses a browser that pops out an authentication dialogue for mixed contents. Sadly, Firefox is one of those browser. In a lot of the cases, if the user is presented with a login dialogue on site A that is actually requested for content loaded from site B, the user will very likely enter site A's credentials (your site) and have his account stolen.

The solution: You'll have to disallow hotlinking contents of such sort and re-upload any hotlinked images to your server and then serve them in your website from there.

(As of March 2018, Firefox is no longer affected by this issue and like Chrome will only show the popup of the loaded resources is on the same domain)


Is it possible to use one-time passwords for WI-FI?

You could configure the access point to use WPA2-Enterprise and then configure your radius server to use OTP as a password.

This would mean the user enters the OTP as a password. One thing to note, is that the client does not know its a OTP and might save the profile (which will not work next time since the OTP is spent), thus causing headaches for the users.

One thing im curious about: Why use OTP for Wifi at all if its not for hotspot payment?
A better idea would be to use a general group password to access the hotspot and the internet, but when you want to access other services (for example, internal servers, intranets, secure storage etc(, you have to authenticate to a webpage to gain access through a firewall.


Pentesting an ATM OS upgraded from Windows XP to Windows 7

I realise you didn't get an answer here - the reason for this is very simple:

There is no shortcut. You cannot make assumptions from a previous test on XP that there will be weaknesses in the same ATM running Windows 7.

What you should do is conduct your full approach, starting with PCI requirements but adding hardening expectations and best practices for Win 7, as PCI is a very low bar and while you are testing you may as well make it useful.


This story on ehackingnews says it was a result of stored XSS.
http://www.ehackingnews.com/2012/12/tumblr-worm-due-to-stored-xss.html?utm_source=dlvr.it&utm_medium=twitter


Are there any cross platform firewall solutions with a central management platform?

I believe you are looking for Security as a Service providers.

The idea is to route all the traffic through the service provider and the service provider will inspect the traffic and send a decision to the server.

I did a quick search and found the link below.
http://www.virtualizationpractice.com/security-as-a-service-is-it-safe-9929/

The link talks about 2 different providers(read the first part about cloudpassage which i believe is what you are looking for)

http://www.cloudpassage.com/features/

Cloudpassage runs a daemon on the servers and this daemon will contact the providers grid (over an encrypted channel) and all the security processes are run by the grid

The first link says that cloudpassage supports EC2 and rackspace


Yes, this is accurate.  If your version of the Android OS has known privilege escalation vulnerabilities, there is nothing stopping a rogue application from exploiting a privilege escalation vulnerability and thus escaping the sandbox (i.e., gaining unrestricted access to your phone).

This absence of security upgrades is a shortcoming of the Android ecosystem.  The ecosystem is reliant upon handset manufacturers and carriers to continue providing security upgrades, but many handset manufacturers/carriers have declined to do so, for economic reasons.  They treat the phones as disposable, and don't always show loyalty to older customers.  Once the phone is a few years old, they stop providing upgrades and focus on the latest shiny models that are being sold, prioritizing selling new handsets over supporting past customers.  This is not very eco-friendly and not particularly customer-friendly.  I think it is unfortunate, but it appears to be a fact of life.  And so it goes.

There is an excellent analysis of this phenomenom by Michael DeGusta.  Here is a infographic showing the results of his analysis:

Credits: Michael DeGusta at The Understatement.

Update (12/26/2012): Ars Technica has a nice overview of the situation with Android updates, a year later.  Unfortunately, it's not pretty: things haven't gotten any better, and many Android phones are not receiving updates.  The security risks remain.


Hping and spoofed DDoS (or DoS?) what do -U and -P mean?

No as far as syn flooding is considered you don't need those flags .. these flags are pointless when there is no tcp payload

Syn in all standard implementation of TCP/IP stack are packet with empty payload


Need a leniant browser for captive portals (WiFi and LAN)

Use a throw-away domain you don't mind the captive portal knowing (I use redirect.me.away) and when you get the certificate error for it just accept the certificate. The browser will pin that domain with the (untrusted) certificate so you won't get errors about it next time.

Finally, consider using mobile broadband instead of this nonsense, and make sure to let whoever is responsible for it how much their network sucks (most of the time they buy into off-the-shelf overpriced crap from scammy service providers because they don't know better, so if enough people complain it may encourage deployment of actually good solutions, like WPA2-Enterprise or Hotspot 2.0)


What qualifies a vulnerability that shall be published?

If there is a vulnerability in your product, your users needs to know that so they can protect themself. Who discovered the vulnerability is irrelevant for your users, so it should not affect if and how you communicate the vulnerability to them.

So if you publish security advisories, do it no matter who discovered the vulnerability.


Using Volatility Framework with Linux memory dumps

Is your "LinuxUbuntu1204x64" profile also for kernel 3.5.0-23? grepping the memory dump provided by the challenge, indeed, confirms your words that the memory has been probably dumped on a system with 3.5.0-23 kernel:

$ strings ~/Downloads/memory.dump | grep "BOOT_"
    1099:BOOT_IMAGE=/boot/vmlinuz-3.5.0-23-generic root=UUID=d45d9170-0f93-4ff4-b5a5-be89760c0d77 ro
    185123:Command line: BOOT_IMAGE=/boot/vmlinuz-3.5.0-23-generic root=UUID=d45d9170-0f93-4ff4-b5a5-be89760c0d77 ro
    185205:Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.5.0-23-generic root=UUID=d45d9170-0f93-4ff4-b5a5-be89760c0d77 ro
    195710:[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.5.0-23-generic root=UUID=d45d9170-0f93-4ff4-b5a5-be89760c0d77 ro
    221017:ernel command line: BOOT_IMAGE=/boot/vmlinuz-3.5.0-23-generic root=UUID=d45d9170-0f93-4ff4-b5a5-be89760c0d77 ro
    236853:[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.5.0-23-generic root=UUID=d45d9170-0f93-4ff4-b5a5-be89760c0d77 ro
    260767:Jul 21 21:13:16 eindbazen kernel: [    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.5.0-23-generic root=UUID=d45d9170-0f93-4ff4-b5a5-be89760c0d77 ro
    262173:Jul 21 21:13:16 eindbazen kernel: [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.5.0-23-generic root=UUID=d45d9170-0f93-4ff4-b5a5-be89760c0d77 ro
    360508:Jul 21 21:13:16 eindbazen kernel: [    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.5.0-23-generic root=UUID=d45d9170-0f93-4ff4-b5a5-be89760c0d77 ro
    806187:Jul 10 20:07:18 eindbazen kernel: [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.5.0-23-generic root=UUID=d45d9170-0f93-4ff4-b5a5-be89760c0d77 ro
    806319:Jul 21 21:13:16 eindbazen kernel: [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.5.0-23-generic root=UUID=d45d9170-0f93-4ff4-b5a5-be89760c0d77 ro
    806342:Jul 10 20:07:18 eindbazen kernel: [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.5.0-23-generic root=UUID=d45d9170-0f93-4ff4-b5a5-be89760c0d77 ro
    2524180:bcode_jmp RTC=0x%x, iter=%d, REBOOT_STATUS=0x%x
    2525925:bcode_jmp RTC=0x%x, iter=%d, REBOOT_STATUS=0x%x
    2528767:bcode_jmp RTC=0x%x, iter=%d, REBOOT_STATUS=0x%x
    2566790:bcode_jmp RTC=0x%x, iter=%d, REBOOT_STATUS=0x%x
    2850450:BOOT_IMAGE=/boot/vmlinuz-3.5.0-23-generic
    2874700:BOOT_IMAGE=/boot/vmlinuz-3.5.0-23-generic
    2874702:BOOT_IMAGE=/boot/vmlinuz-3.5.0-23-generic root=UUID=d45d9170-0f93-4ff4-b5a5-be89760c0d77 ro

Try /linux/Ubuntu_12.04_x64_3.5.0-23-generic.zip profile from here: http://git.io/volatility-profiles. You may also want to know how to create a profile by visiting the official how-to here. If you come up with some profiles, feel free to shove them into that repo.

Firing up Volatility checked out from SVN (that would be 2.3_beta) works well:

$ python ./vol.py -f ~/Downloads/memory.dump --profile=Linux_Ubuntu_12_04_x64_3_5_0-23-genericx64 linux_pslist
    Volatile Systems Volatility Framework 2.3_beta
    Offset             Name                 Pid             Uid             Gid    DTB                Start Time
    ------------------ -------------------- --------------- --------------- ------ ------------------ ----------
    0xffff88000f9b0000 init                 1               0               0      0x000000000aff1000 2013-07-21 19:19:32 UTC+0000
    0xffff88000f9b1700 kthreadd             2               0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000f9b2e00 ksoftirqd/0          3               0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000fa48000 migration/0          6               0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000fa49700 watchdog/0           7               0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000fa4ae00 cpuset               8               0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000fa4c500 khelper              9               0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000fa4dc00 kdevtmpfs            10              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000fa68000 netns                11              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000fa69700 sync_supers          12              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000fa6ae00 bdi-default          13              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000fa6c500 kintegrityd          14              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000fa6dc00 kblockd              15              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000fb00000 ata_sff              16              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000fb01700 khubd                17              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000fb02e00 md                   18              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000db90000 khungtaskd           21              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000db91700 kswapd0              22              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000db92e00 ksmd                 23              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000db94500 fsnotify_mark        24              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000db95c00 ecryptfs-kthrea      25              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000d5f0000 crypto               26              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000d7a5c00 kthrotld             35              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000d7a2e00 scsi_eh_0            36              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000d7a1700 kworker/u:2          37              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000d7a0000 scsi_eh_1            38              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000d5f5c00 scsi_eh_2            39              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000d5f4500 kworker/u:3          40              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000d5f1700 binder               42              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000f011700 deferwq              62              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000f012e00 charger_manager      63              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000f014500 devfreq_wq           64              0               0      ------------------ 2013-07-21 19:19:32 UTC+0000
    0xffff88000ee35c00 jbd2/sda1-8          201             0               0      ------------------ 2013-07-21 19:19:33 UTC+0000
    0xffff88000ee30000 ext4-dio-unwrit      202             0               0      ------------------ 2013-07-21 19:19:33 UTC+0000
    0xffff88000ec7dc00 kworker/0:3          220             0               0      ------------------ 2013-07-21 19:19:35 UTC+0000
    0xffff88000ec78000 upstart-udev-br      288             0               0      0x000000000ada3000 2013-07-21 19:19:37 UTC+0000
    0xffff88000f2ddc00 udevd                332             0               0      0x000000000ef46000 2013-07-21 19:19:37 UTC+0000
    0xffff88000c291700 udevd                496             0               0      0x000000000c2a6000 2013-07-21 19:19:37 UTC+0000
    0xffff88000c292e00 udevd                497             0               0      0x000000000c2c1000 2013-07-21 19:19:37 UTC+0000
    0xffff88000c838000 kpsmoused            546             0               0      ------------------ 2013-07-21 19:19:37 UTC+0000
    0xffff88000c4c9700 upstart-socket-      638             0               0      0x000000000d939000 2013-07-21 19:19:38 UTC+0000
    0xffff88000ee31700 dhclient3            706             0               0      0x000000000f0fb000 2013-07-21 19:19:38 UTC+0000
    0xffff88000c4cc500 rsyslogd             720             101             103    0x000000000c600000 2013-07-21 19:19:38 UTC+0000
    0xffff88000c83ae00 sshd                 729             0               0      0x000000000bbce000 2013-07-21 19:19:38 UTC+0000
    0xffff88000c4cdc00 dbus-daemon          759             102             105    0x000000000c538000 2013-07-21 19:19:38 UTC+0000
    0xffff88000d1aae00 getty                822             0               0      0x000000000c641000 2013-07-21 19:19:38 UTC+0000
    0xffff88000c62c500 getty                827             0               0      0x000000000d98c000 2013-07-21 19:19:38 UTC+0000
    0xffff88000c839700 login                831             0               1000   0x000000000f28d000 2013-07-21 19:19:38 UTC+0000
    0xffff88000c83dc00 getty                832             0               0      0x000000000d9c1000 2013-07-21 19:19:38 UTC+0000
    0xffff88000c4cae00 getty                834             0               0      0x000000000c684000 2013-07-21 19:19:38 UTC+0000
    0xffff88000d0a4500 acpid                837             0               0      0x000000000c315000 2013-07-21 19:19:39 UTC+0000
    0xffff88000c83c500 cron                 839             0               0      0x000000000d9da000 2013-07-21 19:19:39 UTC+0000
    0xffff88000d1a9700 atd                  840             0               0      0x000000000c327000 2013-07-21 19:19:39 UTC+0000
    0xffff88000da11700 login                896             0               1000   0x000000000ae44000 2013-07-21 19:19:39 UTC+0000
    0xffff88000c514500 whoopsie             901             103             106    0x000000000dae3000 2013-07-21 19:19:39 UTC+0000
    0xffff88000bb15c00 bash                 1064            1000            1000   0x000000000c6f0000 2013-07-21 19:19:46 UTC+0000
    0xffff88000af90000 kworker/0:0          1313            0               0      ------------------ 2013-07-21 19:24:35 UTC+0000
    0xffff88000af94500 kworker/0:2          1314            0               0      ------------------ 2013-07-21 19:29:36 UTC+0000
    0xffff88000af91700 kworker/0:1          1315            0               0      ------------------ 2013-07-21 19:34:37 UTC+0000
    0xffff88000af95c00 kworker/0:4          1316            0               0      ------------------ 2013-07-21 19:35:46 UTC+0000
    0xffff88000af92e00 python2              1317            1000            1000   0x000000000c6fb000 2013-07-21 19:36:09 UTC+0000
    0xffff88000d0a5c00 bash                 1454            1000            1000   0x000000000d8c8000 2013-07-21 19:36:23 UTC+0000
    0xffff88000f9b4500 flush-8:0            1552            0               0      ------------------ 2013-07-21 19:36:28 UTC+0000


Is setting logon cookies in JavaScript insecure?

This is less secure than the normal way to set cookies because you can't set the HttpOnly flag on your cookies. This means that the cookies can be read by Javascript, and this is particularly a problem if the website has an XSS vulnerability. In that case, the attacker can directly read your cookies and take over your session.


Store hashes for a finite set of strings that would be extremely time consuming to reverse via table lookup but also allow grouping

I am no expert in the field, but this seems a good use case for a Hardware Security Module which encrypts all hashes before storing them in the DB.

Using the appropriate algorithms, Identical hashes would be identical when encrypted, hence your indexing need would be satisfied.

An attacker with access to the database would be unable to rebuild the hashes. In order to build a lookup table the attacker would require prolonged access to the HSM. This should satisfy your security requirements.


No, storing it in a session variable isn't going to protect you against your hosting provider stealing it.

The session variable will either be a cookie sent back and forth with every request or a server-side session. Either way the server has access to the key and anyone who controls the server does as well.

So it doesn't add security, sounds like a major inconvenience and could expose you to other threats (like leaking the cookie to a third party).

As a general rule of thumb, API keys should be accessible to whoever's gonna use them. If the server is the one using the key, the client has no business with it.

You could store it encrypted on the server and decrypt it with your login information upon login. It's still security theater, but at least it doesn't inconvenience you (the user) beyond the initial setup.


Reasons why different antivirus engines detect same malware differently

Those results are what each vendor has chosen to call the malware internally. There is no standard form of naming a malware type.

Because of the different ways that vendors seek out and classify malware (and no, it is not always signatures), there will be differences in the ways that a vendor classifies the malware. If it can positively identify it as a certain malware (like Wannacry), then it can give it that label. If it is only classifying what it does, then it will give it a label based on its behaviour, like "ransomware", "trojan", etc.

I see one in that list where it looks like it just reported how it determined that it was likely malware without classifying it at all.


gpg4win kleopatra doesn't ask for passphrase on subsequent runs

This is controlled by the following setting:

Kleopatra Settings > GnuPG System > GPG Agent > Expire cached PINs after N seconds

Set it to 0 to make the cached password forgotten immediately.


The attacker is trying to exploit Joomla component called com_s5clanroster which is vulnerable to SQL Injection.

  An SQL injection vulnerability has been reported in Joomla Com
  S5clanroster. Successful exploitation of this vulnerability would
  allow a remote attacker to execute arbitrary SQL commands on the
  affected system.

https://www.checkpoint.com/defense/advisories/public/2014/cpai-2014-2169.html

That same component was also vulnerable to LFI:

  [o] Exploit

       http://localhost/[path]/index.php?option=com_s5clanroster&view=[LFI]
       http://localhost/[path]/index.php?option=com_s5clanroster&controller=[LFI]

http://www.securityfocus.com/bid/39503

Maybe you don't have that component installed or maybe you are running different CMS, but make sure that you check your website is up-to-date. And not only that, also check if different plugins are still maintained by author, because I saw vulnerable plugins with no updates available from author - and that is consider as a big problem.

Here is another example which can lead to another problem: Expired Domain Leads to WordPress Plugin Redirects

Consider to use ModSecurity (Open Source Web Application Firewall). How to?


It's possible that GDB is messing with your memory layout at runtime, making everything line up as you need it to.  It might be worth ensuring that core dumps are created then use GDB to do some post-mortem debugging to see if your code is actually being hit.

Alternatively EIP may be being set as expected but your payload may have moved, in which case consider a NOP sled and aim EIP for that.


Weird issue with Firewall blocking NATed packets

The firewall isn't randomly denying the packets, and it is very unlikely that they are being dropped because of a bug. In all likelihood the packets are being dropped because that is what the policy says for the firewall to do. Port 3478 is STUN, a protocol used by UDP for NAT traversal. There are some possibilities:

The traffic is authentic, and the traffic back is being incorrectly blocked by firewall rules. In this case the FW admin would need to fix the rules blocking the traffic
The traffic is authentic, and being blocked for good reasons, in which case you need to do nothing
The traffic is an attack. It could be an external party attempting to access your internal network by using crafted STUN packets. In this case the firewall is working perfectly by blocking it and the SIEM working perfectly by notifying you of the attack, in which case be happy - that's why you buy an SIEM

Which of these it is depends on whether any of your systems has attempted to connect to external host A using STUN. It so happens that you, or someone you work with, has access to internal hosts A, B, and C. Ask them to check whether those systems are attempting to connect to external host A. It also is probable that your organization pays for an outsourcer to manage your firewalls, and if so call them up and discuss the entries with them.


Can suPHP lead to security issues due to hijacking people's accounts?

(In Darth Vader's voice): NOOOOOOOOOOOOOOOOOOOOOOO

That's not the way you use or configure suPHP. Even if you somehow manage to get it run that way, it is more dangerous than useful.

suPHP is supposed to be configured at Apache (or whatever your webserver is) level. The idea is to make Apache run suPHP instead of regular mod_php.

How suPHP actually figures out under what account to run the script as is not magic; it simply sees that from the file owner. At beginning suPHP runs as root, and before running the script it just changes the user to be the one owning the file, dropping the root privileges.

EDIT after your own edit: No. Let me explain this one more time. You cannot and should not even attempt to run suPHP via PHP's shell_exec. That's not its idea. Not at all.

suPHP belongs to Apache configuration file httpd.conf, not in individual PHP scripts. There is no exception about that.

Here's suPHP configuration documentation for you.


Per https://www.php.net/manual/en/function.str-shuffle.php, str_shuffle uses PHP's internal PRNG, which is an implementation of Mersenne Twister (see http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html or https://en.wikipedia.org/wiki/Mersenne_Twister). According to Wikipedia, the standard Mersenne Twister implementation requires observing 624 iterations to be able to predict all future values. For a moderately low-traffic site, this would be easy; just write a script that logs in (or whatever else generates the output of such a function) as fast as possible, as many times as possible, until you get the desired number of outputs in sequence. Depending on how str_shuffle is implemented, a single output may involve multiple invocations of mt_rand (PHP's Mersenne Twister-based PRNG), so you might not actually need a large number of outputs in sequence if you can infer the PRNG outputs by looking at the generated strings. Conveniently, PHP is open source, so you can go look at exactly how these functions work.
Leaving that aside, though, there are other problems with the approach you've described.

An output of length 8 is simply insufficient. Even if each value was a perfectly randomly chosen byte, that's only 64 bits of entropy; while 64 bits is enough that it's not practical to brute force any particular token quickly (assuming a network connection is involved), if there are enough tokens active at once then a birthday attack can be used to find some valid token in much less time than you might think.
Even if a cryptographically secure random number generator were used, constraining the input set as done weakens the security of the output. For example, suppose the input set was "abcdefghijklmnopqrstuvwxyz0123456789", that's only 36 characters and you can guarantee that after you see a character once you won't see it again. Even if $length is 36 - the most it can be - the number of possible permutations is only 36! (factorial(36)) rather than 36^36 (what you'd get if you selected with replacement; that is, if each position's value was chosen from the entire input rather than just the characters that hadn't been chosen before), which is nearly 286 trillion times as many possibilities. Both would actually be secure enough (assuming a CSPRNG!) - 36! is about 2^138, which is plenty of entropy for most auth tokens - but it does matter. With only length 8, you'd have 36!/28!, which is ~1.22 trillion possible combinations, only 40 bits of entropy and just over 43% as many possibilities as the with-replacement approach. A smaller input set, or one the same length but including repeated characters, would be weaker still for those lengths.


It depends. Untangle has the capability of intercepting HTTPS using a man in the middle proxy (https://www.untangle.com/store/https-inspector.html). If this is enabled, the HTTPS inspector can see all HTTPS traffic. This however requires that all desktop client install a root certificate issued by the Untangle device.


Is it possible to tell if a file's message digest is MD5 or SHA-256?

No, you cannot tell just by looking at the encrypted file. The encrypted file itself is nothing more than the raw ciphertext output of OpenSSL. It does not retain any metadata (such as a hash of the key, the algorithm, or the IV) other than the salt, which is included by default. The hash algorithm used to convert the input password into the key (and IV) is not recorded anywhere in the resulting message.
Be aware that OpenSSL is not supposed to be used for secure encryption. It is a utility for testing the OpenSSL library only. It has many security weaknesses when used for encrypting sensitive data on the command line. The lack of key stretching, integrity, metadata, and unique IV come to mind.


In order to get those hashes, you need samples of the malware that you want to detect. That is one of the reasons why AV companies have very large teams to hunt for and identify malware, and why their database of hashes tends to be guarded.

For your project, you will need to find (or write) malware and collect those hashes.