How can I assess the strength of user passwords in my office environment? I want to assure the compliance of password policy in my office.

Environment Intro
 My environment is all windows based (server 2003/2008) user base is not more than 400 employees. Nearly 90% of all users have windows XP O/S installed on their machines. The other 10% is divided between Vista and Windows 7. The maximum strength for password is limited to 10 characters.

Problem statement
 I want to know the easiest, fastest, and the most reliable way of testing the windows users' passwords. I have downloaded and gone through the use of many password auditing tools (l0phtcrack, ophtcrack, samsinde).

Objectives
 I want an approach which enables me to enumerate the user accounts by logging into domain controller and not having to go to each individual machine and then run the software. This activity just creates un-necessary administrative workload. Additionally, I need a software that doesn’t require booting into alternate OS (as in case of ophtcrack). Doing so would affect the performance of the users and also becomes annoying.

I want to make use of rainbow tables. The specs handed to me are not enough for me to carry exhaustive brute force attack in the time that is given to me by the senior management to complete the task.

However, I have no issue regarding storage-I can dedicate as much as 1 TB for storing rainbow tables. I would appreciate if you guys can provide me with the suitable link and guide me about the things I should consider before downloading such large size files for my use.

Updated in reference to your update:

For a password strength audit you just want to grab the domain SAM file and run your brute forcer of choice on it. If you prefer to use rainbow tables, you can just run the hashes through your rainbow table tool.

For most rainbow tables providers, the idea is that you provide a portion of rainbow table in return for a download of the larger store. A google search will find you a few options here.

A terabyte is probably a reasonable start, however it makes sense to download a range of rainbow tables relevant to your environment, so you may want to reserve a few terabytes - it is so cheap these days it makes sense to over-spec storage space.


Do large companies storing private user data ensure no single insider can abuse user data? if so, how? Let's say we have a large company X which stores private user information. For example an e-mail provider, or social network provider. I mainly have GMail and Facebook in mind. So the company has thousands of employees. Let's further suppose that X uses Linux for all their machines (from my understanding this is indeed the case with Google and Facebook for their server machines).

Now, from my understanding, X would usually have some data-centers which contain many server machines, and the user data would be stored on those machines. Let's say we have some machine with user-data on it. It may be encrypted when stored, but it should be decryptable if it is going to be returned to the user at some point. So it would seem like a sysadmin with sufficient access rights could access that user-data.

Now, I understand that in such a company most employees would not have access rights to user information, and those who do would be subject to logging of their access to resources.
However, wouldn't there always be at least one person/sysadmin who has superuser access to a given machine? and such a person could access user information and also have control of the logging functionality on that machine, so would be able to do that without traces?

Is my analysis correct? I am mostly wondering if such companies who store user data, would have such sysadmins who have superuser access to user-data and logging and so would be able to retrieve user data without leaving traces?

If this analysis is correct, who would usually have such permission? would it be just some low-ranking sysadmin? maybe only the Chief Information Security Officer?

If the analysis is incorrect, how do they set-up a situation where there is no single person/insider that is able to abuse user-data in the way I described? Some ideas I have for how this could perhaps be done: (1) require authentication from more than one person. (2) keep the user-data on one machine, with one sysadmin, and the decryption key on a separate machine which has another sysadmin (so again it would require a collusion of two insiders to abuse the data)

First off, most companies do not employ (or follow) all the necessary procedures for preventing users from accessing data that they shouldn't be able to access.

Assuming that company X does follow the necessary procedures, these procedures would be built around a few fundamental principles:

Need-to-know access
Every user has access to the information that is mandatory given their job duties. Given that this principle is followed properly, even sysadmins should not have access to user data beyond their job duties.

Separation of duties
Every user is assigned duties that are not overlapping so that conflicts of interest are avoided. For example a sysadmin that can alter user permissions can view log files but cannot delete log entries.

Four-eye principle or Two man rule
Critical procedures must be reviewed by two individuals before taking place. This ensures that a malicious insider will not act alone. For example, if a sysadmin wishes to alter user permissions, they would need authorisation from an additional sysadmin or user to do so.

Data pseudonymization or anonymization
If for any reason, sensitive data are presented to a user (i.e. a spreadsheet that presents both sensitive and non-sensitive data), the data which is not relevant to your duties will be pseudonymized (i.e. replaced with pseudonyms) or anonymized (i.e. redacted or encrypted).


Is HSTS Header Helpful For Mobile Applications? I'm using HSTS(Strict-Transport-Security Header) for web applications. As far as I know browser keeps that information and when a user tries to connect to my website, browser loads it via HTTPS directly. So MITM attacks are prevented.

I also have a mobile application which talks with a web api via HTTPS. Should I implement HSTS header for that? My opinion is it won't provide any additional security since there is no browser which keeps that HSTS header information for web api. Am I correct?

You are correct. There would really be no point here. It would only be useful if somebody chooses to directly hit the api from a browser, but if there is no use case for that, then its not necessary.


Cyber Security Training v. Cyber Security Education for Middle to High Schoolers In my community, we have one state university that offers cyber security training once a year to high school students that show interest.  Last year a student, after receiving this training, hacked his school.

Should we be training high school students or focus more on education?  Do you feel that a "all of the above" approach will help mitigate risk associated with training minors in cyber security, and if not, what training would you provide to the students if you think it would be a good idea to train them in the first place?

There is a big concern in the industry that there are not enough people to fill InfoSec employment needs and there is a push to try and attract students into these roles. So, when you say "should" there is a scope issue.

We, as an industry, need the kids who are interested to have their appetites "whet". Yes, there is a risk that they might use their knowledge for ill, but then they could also learn the same skills via YouTube. At least by having professionals doing the teaching, we can also pass on values and ethics (the "would you rather them learn this stuff on the street?" argument).

General Education is important to all students universally, but Tactics Training also has a place for those who are interested so that those kids can be guided to use that interest for good.


Altering passwords before storing Assume that I'm using bcrypt with a unique salt (or some other best practice) to hash user passwords before storing them in my database.

Is there any security advantage to be gained by character-shifting the password before encrypting?  (i.e. A -> B, a -> b, 9 -> :)
Is there any security advantage to be gained by character-shifting the hash after encrypting, excluding the ==? (i.e. AB+6/== -> BC,70==)
If there's no advantage to be gained, is there any loss of security by doing this?  Or is it a wash?

In light of the rise in attacks based on standard password patterns, does obscuring these patterns help at all?

Applying a transform on passwords before hashing them makes no direct harm to security as long as it is injective: two distinct passwords before apply the transform shall still be distinct once both are transformed. Your "character shifting" is fine for that if you do it properly (i.e. beware of transforming a byte of value 255 into a byte of value 0 which will "truncate" the password).

Indirectly, there is a bit of harm in that your extra transform is extra code, thus extra complexity, and complexity is always bad for security. Moreover, if the transform is computationally expensive, then it comes at odds with the iteration count used in PBKDF2/bcrypt (i.e. you have less CPU available, so you must use a lower iteration count).

A transform like the one you envision makes any good to the security only insofar as the attacker is not aware of it, i.e. the attacker did not do his homework. Basic, low-power attackers who just got lucky with a SQL injection attack may indeed lack the knowledge, but these attackers are not the scary ones. Your extra transform will not deter strong attackers, and that's strong attackers you should worry about.

Transforms applied after hashing have no influence whatsoever on security, except if you are using something like extra hashing, in which case you are just trying to build a custom hash function, which, as usual, is a bad idea. So don't do it. The proper way to use your CPU is not to waste it on voodoo character shifts and other rituals; instead, use your CPU to have a bcrypt/PBKDF2 iteration count as high as is tolerable for your overall application performance.


Using an active or passive scan, can I detect all devices connected to or transmitting via a Wifi network? I know that it's possible to do a passive scan on all channels to see if an access point sends a beacon. However, is it also possible to listen to general Wifi traffic on that channel and assemble a list of all active devices - both "clients" (like smartphone or laptop) and access points?

Yes, tools like tshark will show you all the packets on the channel by default. In fact, when doing some analysis, you must apply filters to restrict your search to the useful packets you are interested in (like beacons).


From a local file inclusion to a shell when file is downloaded? I've just participated in a boot2root capture the flag event where I got close to solving an item but couldn't quite get it over the line and want to learn what I could have done differently.

In the event I managed to identify a vulnerable application that would allow me to perform local file inclusion to download any file from the server, but not render it on the page. Typically in this scenario if I can render content to the page I would nc to the web server and write contents to the apache log that I would like PHP to interpret. Since that wasn't the case in this instance (as I could only download files), how could you approach receiving a shell?

LFI, will not get you a shell by itself. You need to download config files and the web application's sources, these can point you to either passwords you can use in the web app, ssh, database or help you find an exploit on a stored web app. (whiteboxing is easier)


Is Chrome in Metro Mode more secure than Chrome in Desktop Mode? With Windows 8, Microsoft introduces the Metro Apps which run in a sandbox environment, and therefore should be more secure. I would be interested to know if this higher security that the metro apps bring to the Windows OS also apply to the Chrome Browser, that is I want to know if there is any advantage from a security perspective to run Google Chrome in Metro Mode over the Desktop Mode ?

Wikipedia: To ensure stability and security, apps run within a sandboxed environment, and require permissions to access certain functionality, such as accessing the Internet or a camera. The sandbox typically provides a tightly controlled set of resources for guest programs to run in, such as scratch space on disk and memory. Network access, the ability to inspect the host system or read from input devices are usually disallowed or heavily restricted. In this sense, sandboxes are a specific example of virtualization.

Windows 8 introduces a new security sandbox, called AppContainer, that offers more fine-grained security permissions and which blocks Write and Read Access to most of the system. AppContainer is a new isolation method applied to Metro apps, which by default prevents them from reading and writing to most of the Operating System, with the exception of the app’s own AppData folder. More here.

The difference in sandboxing is not important. Chrome already allows NO access to the file system in its regular mode. You don't gain anything using appcontainer as opposed to integrity levels once you hit 'untrusted'.

I don't believe the Broker process in Metro mode is any more confined, therefor you still have a privileged broker (medium integrity/ same level of access) and an unprivileged renderer (no access in either sandbox).

Functionally, there should be no significant difference, even if the sandbox is implemented slightly differently.

edit: Some notes, because I do not have enough rep to comment:

When it runs in Metro you do not get a "double sandbox". You get the same sandbox implemented through appcontainer instead of integrity, and you get the same user tokens, etc, that are always implemented.

@Avid - "Browser sandbox != operating system sandbox... "

As a matter of fact, "browser sandbox == operating system sandbox". The operating system provides virtually all of the functionality for the sandbox - integrity levels and appcontainer are a Windows feature, not a Chrome feature.


How to crack SHA512 hexdigest passwords with John the Ripper? I've been playing with John The Ripper (JtR) to try to crack/audit a salted password that was hashed with SHA-512, with 20 interactions according to the source (for the curious, this is a Rails app, with the authlogic gem).

If I understood things correctly, JtR expects its hashes in a file, where each hash follows certain format. For SHA512, this format appears to be:

username:$6$SALT$HASH

which seems to be a format that is compatible with the passwd/shadow files.

My problem is that the hash I have in my DB is a hexdigest while it seems that the hash that JtR expects its in Base64.

Am I right in this ascertion? Is there a way to tell JtR to recognize a hexdigest hash (composed of password + salt) that was 'stretched' 20 times?

Thank you.

From your description it is not clear how the salt and the hash are encoded into the hexdigest in your DB. First, you have to extract the salt and the hash from the digest. Than, you can create the sha512-crypt which is described at http://www.vidarholen.net/contents/blog/?p=33.


Propagating certificates stored in a CNG Key Store Provider I am developing a CNG Key Store Provider (KSP) that will store keys and certificates remotely in a backend server in order to be used not only on Windows, but also on other OS without the need to export/import several times, every OS will have its own driver.

Currently I am investigating how to let Windows know that my KSP has personal certificates that must be available to other apps using the CryptoAPI, like browsers.

I have read that, when using smartcards, this procedure is done by the "Certificate Propagation Service", that notices when a smartcard is inserted, and then copies the certificates to the "MY" certificate store of current user.

How to do the propagation of certificates available in the KSP? If I call CertAddEncodedCertificateToStore asking to put the certificate in the "MY" store, will it do the trick persisting the certificate for future sessions? If so, I imagine that when some app call CryptAcquireCertificatePrivateKey with that certificate as parameter, the CryptoAPI will ask the KSP for a reference to the private key, right?

After digging a lot and making a lot of tests, I've finally found a way to "propagate" the certificate. This is what need to be done so that CryptoAPI knows that your KSP has user certificates:

Create a certificate context using CertCreateCertificateContext passing the DER encoding of desired certificate;
Create a CRYPT_KEY_PROV_INFO provInfo and set the fields:

Set pwszContainerName to a string of your choice, just to identify the key internally;
Set the field pwszProvName to the name of your provider. This is how CryptoAPI knows that the private key corresponding to this certificate is kept by your KSP;
Set dwKeySpec to AT_SIGNATURE;
The other fields can be NULL.

Associate the provInfo to the context by calling CertSetCertificateContextProperty using CERT_KEY_PROV_INFO_PROP_ID as the property ID;
Open the "MY" store by calling CertOpenSystemStore(NULL, L"MY")
Add the context to the store by calling CertAddCertificateContextToStore(hCertStore, pCertContext, CERT_STORE_ADD_REPLACE_EXISTING, NULL)

After this, the certificate will be available for use in any application compatible with the CryptoAPI, like some browsers. As an example, in Internet Explorer you can access the certificate list in: "Tools" menu > "Internet Options" submenu > "Content" tab > "Certificates" button > "Personal" tab.

Whenever the user wants to use that certificate to authenticate in a website (or other use), the CryptoAPI will call your KSP, passing a hash value to be signed be the private key.


Is there a reasonable chance of a well-funded agent obtaining raw traffic over Tor circuits If an agent has a few middle Tor relays (Am) and a few exit Tor relays (Ae), could they obtain the original traffic of some of the circuits with a reasonable probability?
Let's assume, without too much loss of generality, that Tor only uses middle-middle-exit circuits and that there are M middle relays and E exit relays.
The probability of such a circuit consisting only of nodes this agent controls then is:
P = Am/M * (Am - 1)/(M - 1) * Ae/E

According to Tor Metrics, there are just short of 7000 relays in total, with almost 2000 being exit relays. I will round these figures up into 7000 - 2000 = 5000 middle relays and 2000 exit relays.
Assuming the attacker owns 10 middle relays and 10 exit relays, the probability of them getting to control the whole circuit is
P = 10/5000 * 9/4999 * 10/2000 ~= 1.8e-8

which is very low. However, once you factor in the enormous amount of Tor circuits being established (could not find a reliable figure anywhere, will gladly edit one in if someone has it), wouldn't this agent be able to consistently get complete circuits through their relays and, as a consequence, have complete access to the data it was relaying?
I understand that some of the data through the circuits would also be using TLS, but at least some of it should be plaintext.
It may also be worth pointing out that if this is a really well-funded agent, they might have substantially more than 20 relays at their disposal.

«Since January 2020, a mysterious threat actor has been adding servers to the Tor network (...) by May 2020, they ran a quarter of all Tor exit relays» (ZDNet)
SecurityWeek clarifies the number as 380 exit nodes. See also the full Nusenu post
Note that this attacker was probably only interested in positioning exit nodes.
So yes, a well-funded agent would be able to control substantially more than 20 relays.

wouldn't this agent be able to consistently get complete circuits through their relays and, as a consequence, have complete access to the data it was relaying?

Not really a consequence. Data is encrypted to the target nodes. If you are using a plaintext protocol (like HTTP), the exit node knows the full contents of the communication. The agent only needs to be chosen as an exit node, and the previous ones are irrelevant.
If the target was a hidden service, or even just a https website, the exit node won't know the contents of the communication (it would know which https server you are communicating with, and the traffic flow, but not what was transmitted).
The point on controlling a full circuit is about deanonymizing users, in order to know not only what was sent but also the origin ip address (which might then be tracked to its physical location and the person behind that)
As for the number of circuits being established, you may be right, but the calculation won't be as simple. The tor client doesn't pick nodes at random. Most importantly, the EntryGuards will try to stick to connecting to the same nodes so that, you won't be at the mercy of many different entry node operators, only a few of them. If you were lucky picking them (they are honest), you'd be safe. See the EntryGuards FAQ


All nearby routers are blocking mine There are so many routers nearby and they are on all available channels and blocking mine. I have a cheap router, I cannot afford a better one and I cannot run a cable across the room. Every router nearby is blocking mine and on most games i have over 1000 ping and i cannot play. Could anyone help me fix this issue?

From your description the problem doesn't sound like malicious activity, but rather the common issue of wireless interference that occurs when there are too many wireless networks in a given location. When the channel you are using is "busy," meaning another access point or client is transmitting, you must wait until the channel is clear again before you can transmit. This results in high and very variable ping times.

There are two potential solutions to this. The first is to check if you are using the 5Ghz band, assuming both your access point and your WiFi adapter support it. The 5Ghz band is generally less congested than the 2.4Ghz band and supports faster speeds, with the tradeoff being worse signal penetration through walls. You can use WiFi Analyzer tools on your phone or computer to check which band you are using.

The second solution is to switch to a wired connection, but you seem to have already ruled out that possibility. Wired connections will virtually always be faster and more reliable than wireless ones.


How helpful is rkhunter? I have a software firewall implemented on my server, and I have closed all unnecessary ports. I have strong passwords, and I validate user input on my website.

With these things already in place, do you recommend I use rkhunter to help detect rootkits? Or would that be unnecessary?

Quick Answers
The quickest answers are: "defense-in-depth", and "plan for failure"

You have protections in place, but what if they fail? What if an attacker finds a way in using a method that you did not anticipate? From these perspectives, then, yes, rkhunter is necessary.

But, then you start asking, "when do I stop adding more protection?"

Right Answers
There is a calculation you have to perform about what the risks are and how probable they are, what the costs are if those risks are realized, and the costs of mitigating those risks. Every piece of protection you put in place needs to be maintained and updated, which is a cost. If those costs are lower than the costs of having an incident, then it is worth it. If not, then you are spending more than you are protecting. This quick calculation is how you determine, "is it necessary?"

Other Options
There might be other more important considerations, depending on your situation. Logging? Backups? Encryption? Ease of blowing away the server and rebuilding from known good? Web Application Firewalls? Secure web application design (apart from inputs)? Getting a good third-party review of your entire environment might highlight the more important components.

I hope these ideas help.


Zeroing empty sectors on various Linux filesystems There exist various tools for Windows filesystems (NTFS, FAT) to write zeroes or random numbers to free space on the drive/filesystem.

Do there exist tools like this for Linux filesystems like ext4 and btrfs?

There are various tools for the task. It depends on what are think exactly.

If you want to securely delete an already existing file, then the zerofree and sfill tools are for you (as you can read on @BobBrown's link). If these are not available, or you like more do things combining system functionality instead of downloading toos for everything, then there is another solution:

You set a loopback device from the file to erase (losetup /dev/loop0 /this/file/to/delete).
From this point you can pay with /dev/loop0 without the fear that it freed the block of /this/file/to/delete instead of rewriting. You can safely fill them with zeros (dd if=/dev/zero of=/dev/loop0), or with random numbers (using /dev/urandom instead of /dev/zero)m even multiple times if you want.
If you are ready, deallocate the loopback (losetup -d /dev/loop0), and you can safely delete the now rewritten file.

There is another case, if you want to make some already deleted file unrecoverable. In this case you had to ask "free" and not "empty" sectors. The problem is, that you can't address or manipulate sectors on a filesystem, which doesn't belong to any file. Even this is because it is free.

But there is a workaround. If you create a file enough big to fill the whole free _space on the hard disk if you fill it zeroes or random numbers, you will surely overwrite all free sectors in your system. So, there is very simple what you had to do: simply fill you partition with a big, empty file, until it doesn't stop with a "filesystem full" or similar error:

dd if=/dev/urandom of=/filler

...is even enough. While it works, you can even watch with some df commands, how are the things going. After /filler filled your disk with random bytes, and then the dd command stopped with the error, it is practical to sync one (to make sure everything is really overwritten), and then you can remove the /filler.

There were enough to protect from everything which a normal human can do to recover your data. If you want yet more, you had to replay that 3 or even more than 10 times. Even the NSA doesn't do more.


SSL certificate graded as C in Qualys Can you help in summarizing what would be the main threats for a web app when its SSL certificate is graded as C from the Qualys web scanning tool at https://www.ssllabs.com/ssltest/.

The summary of key findings from Qualys tool

This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B.
The server supports only older protocols, but not the current best TLS 1.2. Grade capped to C.
This server does not support Authenticated encryption (AEAD) cipher suites. Grade capped to B.
This server supports TLS 1.0. Grade will be capped to B from March 2020.

From their detailed listing

It currently supports only TLS 1.0.
It does NOT support SSL 2, SSL 3, TLS 1.1, 1.2 and 1.3

# TLS 1.0 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK    256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK    128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)   WEAK  256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   WEAK  128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   DH 1024 bits   FS   WEAK  256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   DH 1024 bits   FS   WEAK  128

Forward Secrecy Weak key exchange   WEAK

Uses common DH primes   Yes   Replace with custom DH parameters if possible (more info)
DH public server param (Ys) reuse   Yes
ECDH public server param reuse  Yes

I understand that upgrading the TLS certificate to support TLS 1.2 and 1.3;  remove support for lower versions, would decrease most of risks.

Same with applying stronger cipher suites and arranging the adequate ordering of them.

What I need to know if under the current situation, what types of attacks could this resource (Windows Server 2016) be exposed to ?

Thanks

First, you need some clarification on few concepts:

The reported problems aren't about the certificate, but the protocols your server is configured to support.
TLS protects the connection between the server and the client. The weaknesses in the older versions of the protocol doesn't expose the server software to any vulnerabilities (although it may have other vulnerabilities on its own), but may expose the data transferred between the client and the server now or in the future, if recorded traffic can be decrypted later.

The Qualys SSL Server Test explains the vulnerabilities / weaknesses quite clearly:

The reasons for the grade penalties are explained, if you click the MORE INFO >> link on the line.
The Protocol Details section also has links for (more info).

If you wish to get grade A by enabling TLS 1.2 and Perfect Forward Secrecy & disabling older protocols and weak ciphersuites, there are several tutorials you could follow. Alexander Hass is even maintaining a PowerShell script that can do this for you:

Setup Microsoft Windows or IIS for SSL Perfect Forward Secrecy and TLS 1.2


Are there any known attacks for a laptop with the wifi connection turned off? I recently got a new laptop. As I usually do, I removed the wifi module from it, since I intend to use it in public places such as my college and I don't need any sort of connectivity outside my home.

The reason I do this is because there is no physical switch for the wireless connection on the laptop and I feel insecure if it is simply disabled via software. Several friends and relatives have told me I may be too paranoid since obviously 'you can't do anything to a laptop if the wifi connection is turned off'.

I've always been of the 'You not knowing about it doesn't mean it isn't possible' opinion, so I'd rather be safe than sorry, but this sparked my curiosity about this issue.

Has anyone successfully attacked a computer via wireless while it was disabled via software? What are the risks of having a wifi module inactive but installed and powered?

If it is turned off in software, it isn't listening for anything and may very well even be powered off.  There would be no way for someone to attack it since it wouldn't respond to any attempt to connect with it.  It wouldn't even be listening.


UAC and Windows Services A user has a PowerShell script that does some things that require administrative access on Windows Server 2012 with UAC enabled.

When they run the script as a Local Administrator, it fails with access denied. But if they elevate their permissions and run the script as an administrator, it works. So far, so good.

Now, they have a custom Windows Service that runs the PowerShell script. The Windows Service is configured to run under the same Local Administrator account (i.e., not Local System/Network Service/etc.). The script fails with access denied, as if the account isn't an administrator. On older versions of Windows, the script works fine.

How does UAC apply in the world of Windows Services? I assumed that a Windows Service that was run under a custom local administrator account would always be "elevated", but in this case it seems that isn't true.

When they run the script as a Local Administrator, it fails with access denied.

Then this means that being a "Local Administrator" is not sufficient to run the script. This proves that "Local Administrator" does not cover the full set of rights on the machine. In the context of UAC, a "Local Administrator" does not have the full rights of an "administrator" (as seen by the OS), but, when it asks to do something which requires administrative rights, the UAC intercepts the call and instead of just unceremoniously rejecting the request with an error code, it prompts the user. If the user says "yes, go on", then the process is granted elevated rights. From the point of view of the process, everything works as if it had been a "true administrator" all along.

Services do not run in a session, but "as a service". This means that there is no user to prompt. Therefore, UAC, as configured by default, cannot grant "true administrator" rights on demand.

Apparently, you can configure UAC to never prompt, and instead grant the rights (which basically nullifies the security benefits, if any, of UAC); see for instance this blog post). A better solution would be to run the service as an account which is already a true administrator, not the cheap imitation going under the pompous name of "Local Administrator".


Is it possible to execute a command on the local computer in meterpreter? While running meterpreter handler, is it possible to execute a command on the local computer?

That wasn't mentioned in the output of help command. I also tried !ls and to no avail.

Is it possible then?

http://www.offensive-security.com/metasploit-unleashed/Meterpreter_Basics#execute

  The 'execute' command runs a command on the target

http://www.offensive-security.com/metasploit-unleashed/Meterpreter_Basics#shell

  The 'shell' command will present you with a standard shell on the
  target system.

If you want to run the command on the attacker host press Ctrl+Z to background the Meterpreter shell, and issue your command in the Metasploit shell. You can return to Meterpreter with the session command.


Question about Teamviewer and visible IP address I have read conflicting things about this and was hoping to get a definitive answer to my question which is this - If I am dialing in to an associate's computer via Teamveiwer, is there any way possible that my IP address can be detected or any other identifiable bits of information from my end (browser footprints, user agent, mac address, etc;)?

I would much appreciate your input, thanks in advance.

I believe Teamviewer connections are shoveled through the Teamviewer servers.  Otherwise, I wouldn't know how most client edge devices would know to route to a client using PAT/NAT.

But yeah, like the other answer stated, it would be straightforward to check the open connections yourself to inspect the IP handle.

As for your other questions.

  browser footprints

I'm not sure what you mean by this one.  Are you talking about referring website and general tracking information? I would suppose your best bet would be to browse in Incognito/Private mode or any of those specialty anti-tracking browsers.

  user agent

I wouldn't see how, but I suppose it is possible the teamviewer client could leak/expose this information, though I'm not sure what it'll get you outside of the client version.  All in all, I wouldn't count on that information to be confidential.

  mac address

MAC Addresses change as you hit each switch, Those MAC tables are how the switches forward the packets.  A cursory look, this may help you understand.


does mailto require opt-out when user sending initial request for information from website? Everything I have been reading on mailto: requirements has been that the company sending the email or using a website form submitting information.

My situation is: on the company website, a lot of information on various topics is presented.  The website does have a policy statement on all pages. If visitors want additional information, they use the link to initiate the email to the company email address.  The website does use the HTML mailto: to prepopulate the company email address.

Is an opt-out required when the visitor sends the email to the company\ requesting the additional information?

As mentioned by @deviantfan in a comment, your premise seems wrong.

So, suppose someone writes you askign for additional information (eg. I am moving to Finland next month, do you have a store there?). Let's assume they have dutifully read your privacy policy, which is nevertheless unlikely.

What is the opt-out you think may be required? IANAL, but it seems trivially to me that (unless there is some weird case that needs to be taken into account) you can reply to them (No, sorry, we have no local presence there).

Were you perhaps going to add that person into a mailing list so they get daily/weekly/monthly mails about your products, despite having expressed no desire for that (or only implicitly by sending you an unrelated mail)? I don't recommend doing that, but in that case, I certainly would mention in the reply that they would start receiving your spam unless they opted-out. Are you even automatically adding to such mailing list any mail that you receive? (even worse, since the email could be spoofed)

If you don't use that address for a mailing list (the most common context for including an opt-out… link?), there would be no need to state how to opt out of such non-existent mailing list. You may wish to state nevertheless that the provided data is being stored according to the regulations of EU directive 2016/679 and they may access, etc. by doing XYZ (probably not needed at all, but your legal department may wish you to include such reminder anyway).

And all of this has no relationship at all with OWASP. The OWASP Top 10 Application Security Risks, published in 2017, were

Injection
Broken Authentication
Sensitive Data Exposure
XML External Entities (XXE)
Broken Access Control
Security Misconfiguration
Cross Site Scripting (XSS)
Insecure Deserialization
Using Components with Known Vulnerabilities
Insufficient Logging & Monitoring

As you see, none of them is relating to opting out. You seem to be confusing two completely different lists of recommendations.


How does a firewall doing HTTPS inspection verify the servers certificate? I have a question about HTTPS inspection. As per Checkpoint website:

  In outbound HTTPS inspection, when a client in the organization initiates an HTTPS connection to a secure site, the Security Gateway:

  Intercepts the request.
  Establishes a secure connection to the requested web site and validates  the site server certificate.
  Creates a new SSL certificate for the communication between the Security Gateway and the client, sends the client the new certificate and continues the SSL negotiation with it.
  Using the two SSL connections:

  It decrypts the encrypted data from the client.
  Inspects the clear text content for all blades set in the Policy.

  >    3. Encrypts the data again to keep client privacy as the data travels to the destination web server resource.

HI want to enable HTTPS insection in fortigate FW but i did not get enough information in their website about so i am checking the same in Checkpoint's website. But i ended up in having more doubts.t

How FW validates Server's Certificate?
To verify the Certificate FW shd have trusted Root Certificates, if its not verifiying then there is no use of enableing HTTPS inspection as we    are not able to authenticate Server itself.
To encrypt the data firewall should generates the Session key, FW encrypts the session key using public key of Server and sends to server. This key is used for Encryption and Decryption of Data.
Client PC also should generate the session key for encryption and decryption, Does client generates same key as generated by Firewall?
Two tunnnels will establish once inspection is enabled, which keys are using to Encrypt/Decrypt the data in System end and Firewall End...

... because firewall does not have trusted root certificates.

The firewall does have a set of trusted root certificates. They are not necessarily exactly the same as the client has in the browser but there will be overlap for the commonly used CA. And it might even be intentional to let the firewall trust  less CA then the browser does.


Is the HTTP method OPTIONS secure nowadays? I've read How to exploit HTTP Methods:

  OPTIONS - this is a diagnostic method, which returns a message useful mainly for debugging and the like. This message basically reports, surprisingly, which HTTP Methods are active on the webserver. In reality, this is rarely used nowadays for legitimate purposes, but it does grant a potential attacker a little bit of help: it can be considered a shortcut to find another hole.

  Now, this by itself is not really a vulnerability; but since there is no real use for it, it just affects your attack surface, and ideally should be disabled.

  NOTE: Despite the above, OPTIONS method IS used for several legitimate purposes nowadays, for example some REST APIs require an OPTIONS request, CORS requires pre-flight requests, and so on. So there definitely are scenarios wherein OPTIONS should be enabled, but the default should still be "disabled unless required".

This post is a bit old now. What's up today with the OPTIONS methods? Most of the scans show that it's a vulnerability. Is it really dangerous?

I have no choice to use OPTIONS for some of my apps. What can I do to secure it?

I would say implementing the OPTIONS method, in itself, is not a significant security risk. Yes, it nicely enumerates which other methods are implemented by a server, but it is in the handling of those other methods that the potential for danger lies, not in the reporting that they are handled.
For example, the TRACE method can be a vector of attack. If you implement OPTIONS, and it includes TRACE in its response, a potential attacker can use OPTIONS to discover that TRACE is supported then decide to try and launch an attack on TRACE. However, if OPTIONS is not implemented, or it lies and says TRACE is not implemented, the attacker could still decide to try and mount an attack using TRACE. In fact, they are probably just as likely to not use the OPTIONS command at all and simply see if an attack on TRACE will work.
You should focus on making sure that potentially unsafe methods (such as TRACE) are disabled or suitably protected, ahead of worrying whether OPTIONS tells an attacker they exist.

The OSWAP GitHub page on Test HTTP Methods starts by listing the eight HTTP methods defined by RFC 2616 (HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS and CONNECT) but only mentions four that should be disabled (or sufficiently protected):

More specifically, the methods that should be disabled are the following:

PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim's server as a file repository.
DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack.
CONNECT: This method could allow a client to use the web server as a proxy.
TRACE: This method simply echoes back to the client whatever string has been sent to the server, and is used mainly for debugging purposes. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman (see links at the bottom of the page).

If an application needs one or more of these methods, such as REST Web Services (which may require PUT or DELETE), it is important to check that their usage is properly limited to trusted users and safe conditions.

And while it highlights how the OPTIONS command can be used by a tester to determine potential vulnerabilities:

How to Test
Discover the Supported Methods
To perform this test, the tester needs some way to figure out which HTTP methods are supported by the web server that is being examined. The OPTIONS HTTP method provides the tester with the most direct and effective way to do that. RFC 2616 states that, “The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI”.

Execution of a test-script only highlights the TRACE method as risky:

The same test can also be executed using nmap and the http-methods NSE script:
C:\Tools\nmap-6.40>nmap -p 443 --script http-methods localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2015-11-04 11:52 Romance Standard Time

Nmap scan report for localhost (127.0.0.1)
Host is up (0.0094s latency).
PORT    STATE SERVICE
443/tcp open  https
| http-methods: OPTIONS TRACE GET HEAD POST
| Potentially risky methods: TRACE
|_See http://nmap.org/nsedoc/scripts/http-methods.html

Nmap done: 1 IP address (1 host up) scanned in 20.48 seconds

The rest of the OSWAP page discusses potential security problems (e.g. the potential of using TRACE to exfiltrate cookies tagged httpOnly into JavaScript), but does not talk of OPTIONS being a security concern.


How secure is my system? I am creating an application that allows a user to create an account, with a password, and have a set of public and private keys symmetrically encrypted with the password, so that they can be retrieved later when necessary, but only if the password is correctly entered.

For both the password and the key pair, I am creating a salt derived from OpenSSL's random number generator.

For the password, I am using bcrypt to encrypt with the aforementioned salt.

For the key pair, it's a little more complicated. I am using OpenSSL with aes-128-ctr to encrypt the pair, and the key for aes is derived from the password and the salt. Specifically, here's the code I am using in Ruby:

iter = 20000
key_len = 16
key = OpenSSL::PKCS5.pbkdf2_hmac_sha1(password, salt, iter, key_len)
# unhashed password and salt from before

cipher = OpenSSL::Cipher.new('AES-128-CTR')
cipher.encrypt
cipher.key = key
iv = cipher.random_iv
cipher.iv = iv
encrypted = cipher.update(data) + cipher.final #key pair

My question is, is this system secure? Am I using best practices? As far as I can tell, I am, but I also want an outside opinion to ensure I'm not missing something major. If necessary I can provide the code for the password hashing, which is done using Ruby's bcrypt library.

Edit: I want to clarify in case it is asked that I'm not asking about the validity of my code but the security of the code.

The whole setup seems kosher to me. But I feel that too little is known about the application itself; did you consider the possibility of the password being leaked, or the decoded keys?

On some (web-based) systems, you'd have to "store" some or all of that data in a session object, which could well mean that the information is archived in plain text in a file on disk, or a key-value pair server, potentially accessible by other users as well as rogue processes, and possibly remaining accessible long after the user has logged out and disconnected. On such platforms you'd need to manually sanitize your data structures as far as possible; also, key-value assignment is non-trivial and typically requires a fairly unguessable session ID generator (which most aren't; unguessable, I mean).

You appear to already know about this, but I'll refer to session fixation nonetheless. Also, memory databases and key-value stores might, for performance's sake, not properly initialize their memory and allow an attacker to recover sensitive data; typically you use low level API to request a 4K block, and read off it before initializing it. If the server did its homework properly you'll get 4096 zeroes. If it did not, you'll get whatever was stored in that block by the user before you (I saw this happen in a BANK, of all things).

Then, access to those databases must be protected or secured somehow - a third party shouldn't be able to access data it has no right to (for example by enumerating stored datasets and querying their contents). On some systems you could use a different, totally unrelated (and vulnerable) virtual host to gain access to the content of such a keystore, by misdirecting the server into retrieving the wrong keyvalues. This caused an error, but sometimes the error text included precious information:

We're sorry. There is no document called
    *?=|1395481948749|1346625
   |lserni
   |62609098affb79cd2e7c31b6793b539e
   |Fl==SPQR].
(Error: DB001A key was not found)
Try using the Search function, or contact us with the details of this issue.

Hypothetical example, attack #1

website process with PID 12345 connects to keyserverd:
    >> "store value '<PRIVATEKEY>' into key 'pk-12345-1395494389'"
    << "OK"

rogue process espies PID 12345 and knows the timestamp. It also connects:
    >> "Get me key 'pk-12345-1395494387'"
    << "ERROR: no such key"
    >> "Get me key 'pk-12345-1395494388'"
    << "ERROR: no such key"
    >> "Get me key 'pk-12345-1395494389'"
    << "OK: <PRIVATE KEY>"

This may happen during the process lifetime, or can happen afterwards. Unless of course:

    >> "Logging out. Delete key pk-12345-1395494389"
    << "OK"

Hypothetical example, attack #2

Just as before, but this time the API is more complicated (at low level, of which you might not be aware):

application (to library): "Store value '' into key 'pk'"

library: generates unique pk-12345-1395494389
library: connects
library: requests 1880 bytes for pk-12345-1395494389

server: allocates 1880 bytes plus necessary housekeeping structures
server: returns handle 123

library: stores '' into handle 123
...

application (to library): "Delete value 'pk'"

library: determine pk-12345-1395494389
library: deletes pk-12345-1395494389

server: marks 1880 bytes as "free" but DOES NOT OVERWRITE THEM
server: destroys handle 123

attacker: request 1880 bytes for key "pwn"

server: allocates 1880 bytes plus ... and these are THE SAME BYTES FREED
      A MOMENT AGO

attacker: does NOT write anything to key 'pwn'
attacker: read content of "pwn" memory block
 (sometimes this is not allowed, but the memory is nonetheless accessible
  in some roundabout way. Some other times it isn't, but you can't count on
  getting a break)
attacker: finds "" (or sometimes "@#£!VATE KEY>")

In such a case:

    >> "Logging out. Store '##[...1.8Kb of #'s...]###NICE TRY!'
                into key pk-12345-1395494389"
    << "OK"
    >> "Delete key pk-12345-1395494389"
    << "OK"

is slower, but more secure ("memory shredding" or "memory scrubbing").

In such a scenario, storing data to the database is as good as having passwords in cleartext; actually it's worse, because while a user must have file system access to the database files or authentication to the database server in order to reap the passwords, in many instances keystores are designed for "we're among friends" access, and anybody with local access can retrieve data (e.g. Redis "is designed to be accessed by trusted clients inside trusted environments"). This is OK, mind you, as long as you know what's happening and take countermeasures. After all, the Internet is insecure and yet here we are creating websites - but we use authentication and SSL when we need them, for we know of the insecurity. With Redis for example we could turn on authentication; now the attacker has to have both local access and the password, but the password is in the webapp files, so he needs read access to those files, too. If we make it so that this equals to impersonating the webapp user, we're (more or less) done: because a local attacker with webapp impersonation capabilities could just ask the password to any user and/or mount a man-in-the-middle attack. Of course this is all very, very rough; you need to examine your own workflow and ask yourself, "What could one do who arrived at this point? What else could he do? How do I take him out? How do I keep him out?".

Desktop applications also have their own insecurities related to password and plaintext data persistence both in memory and on disk (you have to treat specially the sensitive memory region to prevent it from being cleartext swapped on disk, and have to scrub the memory manually before freeing).


Defense in depth vs low complexity - Balancing point? I've asked a few questions relating to schemes for various security-related functions, and posited schemes to accomplish those goals. In the responses, I see a conflict between two fundamental principles of IT security; "defense in depth" (make an attacker break not one, but many layers of information security) and "Complexity is the enemy of security" (the KISS principle).

The question IMO is obvious; when does one of these two take priority over the other? You can't have both in the extreme; adding layers necessarily increases complexity of the system, while simplifying security typically "thins" it. There's a spectrum in between "ideal" complete simplicity and "ideal" infinite depth, and thus a balance to be struck. So, which of these, when they conflict, is generally to be preferred in the design of an information security scheme?

This is written from the perspective of a software developer and project manager, who often needs to deal with sensitive  data in apps that I am involved in creating.

Defense In Depth is not necessarily at odds with the principle of simplicity.  Simplicity is difficult, and it's not what you'd think.  Simplicity doesn't necessarily mean lack of effort.

It can (and in this case, I think it usually means) not using complex, home-grown mechanisms when established practices/tools exist.

It can also mean keeping your systems simple to reduce the attack surface area, or make them less attractive targets by not storing the type of data that people want to steal.

There is a true art, as well as science in finding the right balance of simplicity vs. functionality, but in my experience, when it comes to simplicity, simplicity in some aspects is one of the keys to defense-in-depth.

The essence of what I'm going to try to get at here is that the amount of time you spend defending your application should be proportional to the sensitivity of the data contained within, and the size of the attack surface area.

Here are two ways that simplicity adds to defense in depth by subtracting something.

Carefully deciding whether you should store sensitive data in the first place

One of the most blindingly obvious truths about protecting sensitive data is that if you don't have sensitive data, you don't need to protect it.
When developing systems/software, the most basic thing you can do to increase relative the security of your system is to do so by limiting the sensitive data in the first place.
By deciding not to store unnecessary sensitive data, you are making it simpler, but exercising defense-in-depth by considering defense as a part of your initial requirements gathering phase

Reducing the attack surface area

Similar to the above, but this time looking at features.  Every single user input control - text-box, drop-down list, etc, is a potential "window" that, if unprotected, can be an entry point for an attacker.  If you're failing to validate input or failing to sanitize output, that control may be vulnerable to any number of well-known attacks.  As a developer, I can tell you that when creating large, complex sites/forms, it's easy to miss a validation control here or validate something incorrectly there.
The business might want a fancy interface that has all sorts of bells and whistles, but the benefit of having that interface/feature should be weighed against the cost of securing it, and the downside of the increased attack surface area.

Also, keeping security simple doesn't necessarily mean limiting your defenses to fewer defenses.  Keeping security simple simply means don't make it harder than necessary.  Ways you can keep security simple and still have defense-in-depth include:

Having secure defaults.  Establish your normal defenses.  You can have fifty layers of defenses, but if you know what your baseline is, you are still keeping it simple by just following the normal routine.
Using established best practices.  Similar to the above, for almost every type of I.T. activity, there is already an established set of best practices.  Simply following those instead of coming up with wild schemes of your own keeps things simple.
Using established, trusted tools.  Of course, no tool is foolproof, but if you're adding layers of defense, using established tools instead of coming up with your own or using lesser-known, unsupported tools keeps things simpler in the long-run.  You'll have better documentation, a wider user community for support, and greater likelihood that when there's a problem, it'll get patched quickly.

Defense-in-depth is about layers of security.  Keeping each layer as simple as possible is the key to applying the principle of keeing it simple to a defense-in-depth strategy.


My email is listed as recovery email for an unknown Google account I just received a "New sign-in" notification email from Google, saying

  Hi UNKONWN_PERSON,

  Your Google Account UNKONWN_ACCOUNT@gmail.com was just used to sign in from SOME_BROWSER on SOME_OS

Where UNKONWN_PERSON and UNKONWN_ACCOUNT are total strangers to me. They have no resemblance to mine and even belong to a different culture.

The email also explains:

  You received this message because MY_EMAIL_ADDR is listed as the recovery email for UNKONWN_ACCOUNT@gmail.com. If UNKONWN_ACCOUNT@gmail.com is not your Google Account, click here to disconnect from that account and stop receiving emails.

Where MY_EMAIL_ADDR is my email address, to which the message was sent.

While clicking the disconnect link seems the obvious action, I am not sure that this is enough. It seems unlikely that my address was added as recovery email by mistake, so I am wondering if UNKONWN_PERSON or someone else had any malicious intent

The disconnect link doesn't look like a phishing one, it is in this form:

https://accounts.google.com/AccountDisavow?adt=SOME_HASH

The devils are in the details.

This message is yet another variant of malicious spoof spam mail tries to trick you to click the link that says "click here to disconnect".

If you hover over the URL, you will see the actual URL are NOT from Google, but some unknown site or shorten URL that will trigger a screen that downloads a malware(AKA Computer virus) or phishing site to trick you to enter Google username and password.

(UPDATE)
there is another possibility mentioned here. Somebody accidentally enters your email address as recovery email (either due to typo or other reasons)
It is mentioned here in google product forum.  If you read through the message, you will notice most people will ask you DON'T CLICK any HTML link from an email.

If somebody wrongly enters their recovery email address, their Gmail account will not be activated. So you don't need to do anything with it.

That email actually is a terrible google email registration process that shouldn't be crafted in the first place. It just gives spammer ways to phish users: pour in tons of similar spam, people will think clicking the link will "fix" the spamming problem.

Perhaps this kind of email should be marked as "SPAM" to warn Google mail developer.


What are the differences between "simple" UAC and two user accounts on Windows? I'm currently thinking about increasing security on my Windows machine.

As part of this harderning I considered the least-privilege principle and want to apply this on Windows using two different user accounts: An administrator account and a normal user account (for everyday usage).

Now I asked myself:

Does using two different accounts actually increase security as opposed to running a (single admin) user account + UAC?

Short Answer
Use a limited account for performing the day to day activities and have a separate account with administrative privileges for performing tasks that require elevated privileges.
Long Answer
User Access Control is not considered a security boundary by Microsoft. The reason is that due to the design of Microsoft Vista and later, processes hold only a limited privilege token when launched and explicitly require elevated privileges which are protected by the UAC in a default state. As you can see, as long as the process don't request elevated privileges, UAC won't come into play. It means a malware will have access to everything the user account has access to without requiring any elevated privileges. The data of the user is much more important than getting NT AUTHORITY\SYSTEM privileges.
Another thing which needs clarification is the Always Notify setting of the UAC. It is generally understood that UAC in the default state i.e. "Notify only when programs try to make changes to my computer" can be bypassed in a lot of ways. Exploitation frameworks such as Metasploit has dedicated modules to achieve the UAC bypass in the default state where the process is silently elevated without any UAC consent dialogue. However, the same is true for the Always Notify setting as well. For example, take a look at technique outlined here. A brief summary of the technique is instead of asking for elevation interactively, register the process to the Task Scheduler with the logged in user. In Microsoft terminology, it is called S4U (service for user). The task when executed will have elevated privileges without requiring any consent from the user of privilege elevation and this is true even if the UAC is set to the highest security setting which is Always Notify.
Conclusion
UAC is beneficial in a lot of ways if the user don't have administrative privileges. Have a separate limited user account where every time elevated privileges are required, the user will be asked by the UAC prompt for the administrator user's password. If the user already have administrative privileges, UAC is of little use.


What approach would you choose to defend againt DDoS attacks from Nginx level? I use Nginx compiled with the Naxsi module to protect against some vulnerabilities (SQL injection and cross-site scripting). Now I need to apply a layer of poor man's DDoS protection at this level.

I read a lot to come to the conclusion that there are three recommended approaches: two modules for Nginx and the option to use a TCP/HTTP load balancer (like HAProxy). The modules I'm referring to are testcookie and anddos. Apparently, you can combine the power of both.

What would you recommend not only from a security perspective but also considering the performance point of view?

I would also recommend using:

ngx_http_limit_req_module to limit RPS, and fallback to 503 on burst cap hit optionally. It does very well with exploited zombie browsers DDoS;
agressive caching for anonymous users (with next bullet applied maybe) and for target location (in case it is not random) to eliminate FastCGI passes;
use power of LUA module and bash-fu to integrate with iptables, to block zombies on a system level to prevent concurrent UDP/SSH/whatever-flood (you may consider using ipset utility to handle large sets of zombie IPs which iptables will fail to process fast enough).


Requiring Authentication to Exit I've often wondered why facilities do not require authentication as a default on exit. Beyond the oblivious reasons:

Fire safety policies would require a panic mechanism to override the access control.
Additional cost of authentication mechanisms at an exit point.

Some places do, but most do not from the viewpoint that they are only concerned about who is getting into the place.

Places I've worked where authenticating those leaving was the norm included:

A manufacturing facility, who was also checking bags and pockets to detect if you were trying to steal product. Who got checked was randomly determined by the system. This made it so that you could not collaborate with guards to smuggle out loot.
A coal mine, where knowing who was still inside the mine during fires/emergencies was essential to knowing who still needs to be rescued. A side effect of this was that it made clocking in/out for friends impossible.
One company was concerned about people leaving a swipe card on top of the reader, so before a card could be used to re-enter the place, it had to be used to swipe out.

One place that used swipe cards for leaving was a variation of time clock for employees. Some were 2-swipe employees ("in" in the morning, and "out" when leaving at night), and some were 4-swipe employees (in addition to "in" in the morning and "out" at night, you were expected to swipe in and out for lunch). The 2-swipe folks were expected to work 50 hour weeks and were paid a little more than 4-swipe employees. This company was regulated as a bank and had the side effect that the 2-swipe employees always took 2+ hour lunches.


If I send a fax from an unsecure endpoint to a secure endpoint, is the data secure? I am very technical, but I do not know much about fax. I was told to send a fax to somebody with some very private information, and not to worry because they had a secure fax line.

That's all well and good, but I do not have a secure fax line. Does this matter? Or am I in the right not wanting to send this data to them via fax.

I wouldn't much care if the line were secure, I'd want the connection to be secure.

Consider the possible ways your data could be intercepted:

If you send from a fax machine at your office, the line could be tapped in the corporate wiring cabinet, or anywhere between the machine and the cabinet.
If you send from home, the line could be tapped at the network interface.
The line could be tapped between the network interface and the CO.
A rogue phone company employee could be listening.
A government could be listening ("lawful intercept").
The same set of taps could be in place between the CO and the receiver.
When the fax rolls off the receiver's machine, if the machine is not in a physically secure location (e.g. a locked office), then a casual snooper might see your info.
If the fax is stored electronically instead of printed directly onto paper, it could be "stolen" from the electronic storage system.

So the answer is no, the data is not secure. You need to be able to establish an encrypted connection to the receiver, and (if it is very sensitive) you want to understand how they will be handling the data once it has been received.


Google Chrome is redirecting before visiting a shopping website I notice every few days (~5 days) that when I try to open an Amazon.in URL, before opening that URL, Chrome opens a different link which looks like an affiliate link. This link redirects to the actual URL. The link is given below. After it does so, it will stop behaving like this for next few days.

Is my computer infected?

Here is what Chrome opens before redirecting to Amazon: http://redirect.afflepay.com/aff_c?offer_id=1021&aff_id=1250&url=https%3A%2F%2Fwww.amazon.in%2Fgp%2Fproduct%2F1841591572%2Fref%3Ds9_qpp_gw_d99_g14_i7_r

Most probably it's a malicious extension
Sometimes when you install software, the installer installs extensions to your browsers along with it. If you have recently installed a software from an untrusted site, it could have installed this extension on your browser.

You can try the following things:

Visit Amazon from some other browser to see if it's only a chrome problem
Check the extensions on all the affected browsers to see if there is any extension that you don't remember adding
If that doesn't solve your problem then go the advanced browser settings and check for any funny business


Recommended symmetric key usage period Let's assume that there are two nodes A and B connected over a network. Both have a single pre-shared symmetric key (e.g., AES-128) and exchange messages.

What is the recommended period, until the key should not be used anymore? Can they go on forever?

Is there a maximum number of messages after which a rekeying should occur?

Is there a difference between the different attack models like ciphertext-only and chosen-plaintext?

Thanks!

Exact answer depends on the involved mode of operation, but most of them begin to exhibit unwanted structure when about 2n/2 blocks have been processed, when the underlying block cipher uses n-bit blocks. The fundamental reason for this is that a block cipher like AES is a permutation: any two distinct input blocks are encrypted into two distinct output blocks, always; whereas a pseudorandom function may send two inputs to the same output value, and this ought to become apparent when 2n/2 or so input values have been processed. This is a variant on the so-called birthday paradox.

When that limit is reached, consequences again depend on the involved mode, but they should not be ignored.

In the case of AES, n = 128 (AES uses 128-bit blocks), so you are good for 264 blocks of 16 bytes, which is about 300 millions of terabytes -- in practice, "forever". That's the exact reason AES was defined to use 128-bit blocks, whereas most block ciphers of that era (3DES, RC2, RC5, Blowfish, IDEA...) used 64-bit blocks: so that the 2n/2 limit is pushed sufficiently high to cease to be inconvenient.

There is Tradition, though. For a long time, cryptography was used without computers, relying on algorithms which were quite weak and prone to reveal secrets through statistical analysis. Moreover, cryptography was an exclusively military and diplomatic tool, in a context where it had to be assumed that a substantial proportion of field agent were, at any time, working for the enemy. Both characteristics called for frequent key renewal, to overcome leakage through poor algorithms, and to contain the damage arising from corrupt insiders. In most modern situations, things don't go that way: we have good algorithms which don't leak, and under normal conditions there is no attacker within your systems (and when there is, you have already lost and key renewal won't help). However, you will encounter a lot of standards and guides and "best practices" which mandate renewal after having encrypted some arbitrary amount, usually in the gigabytes range -- the amount is rarely justified, and the whole concept is a remnant of a troubled past.


At Starbucks, is my MAC address sent when I accept the terms of service for free Wifi? Recently, I overheard by chance some technically savvy guys saying that when you accept the terms of service in order to use the "free" WiFi at Starbucks (which you pay for when you buy some coffee), the popup window actually performs an HTTP operation that sends the computer's WiFi MAC address in the URL in an HTTP GET request to the service that Starbucks has contracted with, e.g. "GoogleStarbucks". Why do they do that? Are they actually recording all of the customers packet traffic? If so that is a serious privacy violation!

I heard this happens on a Macbook, but I assume iPhones as well and I am curious if Windows and Linux users can confirm here in this forum that it happens to them too.

Concern #1: That Starbucks is recording all traffic for some MAC addresses.

Concern #2: That Starbucks is sending the MAC address to some services e.g. if you log in to an anonymous email account, it's provided somehow.

Concern #3: That the popup is running Safari / JavaScript that is specially allowed to obtain the MAC address, and that WebKit may have a vulnerability that lets others access this datum.

Concern #4: That Starbucks is recording my daily patterns e.g. which Starbuckses I go to and when, and selling it to the highest bidder.

Concern #5: Retailers are sharing this information, so that if someone with a given MAC goes to Starbucks, that same MAC is tracked in other stores that the shopper happens to pass by e.g. in a mall.

A MAC address more-or-less* uniquely identifies a network card, and is only accessible to other devices on the local (non-routed) network.  So yes, the Starbucks network can and does know your MAC address, and certainly could be sending it up into their database somewhere.

Concern #1: That doesn't mean they're "recording traffic" (although, of course, they could do that as well).  It just means they're taking a fingerprint of your device and making note of the fact that you were there.

Concern #2: It's unlikely they're sending the address to anyone but their own database.  There's usefulness for them to track who uses their network, how often, and at which locations.  There's very little usefulness in supplying that address to anyone else, and good reasons (your concerns among them) not to.

Concern #3: They might very well use Javascript to populate your MAC address into the submission you send when you agree to use their network.  Nothing nefarious there - remember, they own the network, they know your MAC address, and could do whatever they wanted with that information without routing it through your browser.  If you wanted you could mess with it if they're sending it through your browser - although, of course, you could mess with the system by changing your MAC address anyway.

Concern #4: Unless you pay with cash each and every time you go to Starbucks, your MAC address is the least traceable thing about you.

In summary: don't worry about it.  They're doing standard consumer-level tracking, and you're a consumer.

Note* While a MAC address is intended to uniquely identify a network card, many cards allow the address used to be reconfigured.  You can probably set your MAC address to whatever you'd like, as long as it doesn't match another MAC address in use at another network.  So you could use a different MAC address each time you went to a Starbucks and thwart their tracking.  That's why I refer to it as consumer-level tracking - it's cheap, easy, and while it can be tricked it's not worth most people's time to do so.


Disable Perl for some/most Linux users? One of my server's web accounts got hacked a couple of times. Each time someone downloaded a Perl script via some phpBB forum and used the Perl script to do whatever they wanted to do (mostly connect to IRC and start DDoS attacks according to the script's code).

I would like to disable Perl for most (not all as some processes I use are using Perl) or some specific users.

How can I do it properly? I am using Debian.

I agree with Gilles that disabling perl is not effective security; as there are numerous other ways you could be attacked (e.g., a python script; a bash script; a php script; an executable) and that restricting /usr/bin/perl to certain users groups may have side effects (e.g., that program that calls a perl script as an ordinary user).

However as an aside, the straightforward way if you have an application in linux that you want to restrict to certain users, you first, create a group, then add users to that group.  The following commands accomplish this in ubuntu (creating the perl group and adding user1, user2, user3 to it:

sudo addgroup perl
sudo adduser user1 perl
sudo adduser user2 perl
sudo adduser user3 perl

Now find where perl currently is (which perl which on my system was /usr/bin/perl) find what it's perl's ownership and permissions currently are (ls -l /usr/bin/perl on ubuntu by default set to owned by user root and in group root) with everyone having read/execute permissions, which you should disable for other users unless they are in the perl group:

sudo chgrp perl /usr/bin/perl
sudo chmod o-rx /usr/bin/perl

Note that an attacker on your system who isn't a member of the perl group, if they can get to a terminal could upload their own version of the perl executable (or if you didn't remove read access to other users; they could have just copied it) to some local/tmp directory, set the executable bit on it (if they can run chmod), and then use that run perl script's off their own executable.


Why does McAfee think Stack Exchange is malicious? I was surfing Stack Exchange today on my phone and clicked on a question that linked to skeptics.stackexchange.com and was promptly greeted with McAfee telling me the site is malicious. I've vistited the site before and haven't had any trouble.  Can someone one please enlighten me as to how mobile McAfee determines a site is dangerous?

My phone is a Verizon droid turbo running Android 4.4.4. The AV appears to be Verizon Support and Protection which seems to be using McAfee SiteAdvisor.

Attached are screenshots of the warning pages I was redirected to and a screen shot of the AV about page.

Can someone one please enlighten me as to how mobile McAfee determines
  a site is dangerous?

This can be found in the SiteAdvisor Site Ratings Policies:

  What Is Rated? How Is It Rated?

  We test the following attributes of a
  site. Red, yellow, and green scores are computed from the outcome of
  these tests.

  Downloads We test downloadable software that is hosted by and directly
  linked to from a site. We use our award-winning McAfee anti-virus
  engine to determine if the file includes malware, such as viruses,
  Trojans or adware. We also test for program behaviors that we deem to
  be risky or merit a cautionary note. Behaviors can include resetting
  the browser's home page, adding toolbars or desktop shortcuts or
  contacting 3rd party Web servers. Based on these results, we score the
  site's downloads accordingly.

  E-mail practices We test sites for e-mail practices by entering a
  valid, unique personal e-mail address into a site's e-mail form. Then
  we measure any mail that is received at this unique address. We score
  the site according to the quantity of mail received as well as the
  "spamminess" of those e-mails. Spamminess is a measure of the mail's
  commercial content, as well as the presence of tricks used by spammers
  to try to escape detection by spam filters.

  Browser exploits We perform tests to detect the presence of exploits
  on a site. An exploit is any content that forces a web browser to
  perform operations that the user does not explicitly intend.

  Web reputation McAfee tests websites for web reputation using the
  TrustedSource™ system. This system collects security data from tens of
  millions of sensors located in more than 120 countries. McAfee's
  proprietary technology analyzes traffic and linking patterns, website
  behavior, content analysis, site registration and hosting, to develop
  an overall reputation rating for the website.

  Annoyances When we visit a site, we record how many pop-ups occur and
  how many cookies we receive. In addition, we monitor prompts to change
  a browser's home and search page settings.The presence or cookies is
  only noted. Cookies do not affect a site's score.

  E-Commerce McAfee tests sites for the following e-commerce issues:

  Phishing: We use proprietary, award-winning real-time phishing
  software to evaluate whether the site in question is attempting to
  mimic a legitimate business or financial institution.

  Scams: We use a variety of criteria to determine whether a site in
  question is engaged in questionable business practices, such as
  selling rogue anti-spyware.

  Links (online affiliations) We collect information about the URL links
  posted on a site to determine whether the site is affiliated or
  effectively directing traffic to another site. We rate a site based on
  our estimation of the risk users could experience if they used these
  links to be led to other risky sites.

As for what triggered the rating for the site you are trying to access, we can't really tell as the SiteAdvisor rating itself does not seem to provide any further information on what specifically was wrong with the site (no mention of the attributes that they supposedly use to determine the safety of the website).

A simple search for 'siteadvisor false positive' on Google should reveal that SiteAdvisor has a notable history of providing misleading ratings and taking embarrassingly long times to resolve complaints. Given the reputation of StackExchange sites, the rating for the site in question is also probably just a false positive.


SSL Labs report question: Is "Insecure Renegotiation" possible if weak cipher suites are not available on server? On one server, we have removed weak cipher suites and insecure protocols to try to pass SSLScan / SSL Labs.  One outstanding problem is Insecure Renegotiation.
I read that:

  The Apache Software Foundation has reported an issue that may occur when
   the SSLCipherSuite directive is used to upgrade a cipher suite.
   Particular sequences of per-directory renegotiations may cause a weaker
   cipher suite being used in place of the upgraded one.

  If this issue were to occur, flaws in weaker ciphersuites could be
  exposed. This could threaten the integrity of SSL transactions
  negotiated  between a vulnerable server and the client. This could
  provide an  opportunity for passive attackers in a position to observe
  such a  transaction.

My question is if we have removed the weak cipher suites, is it not true that there are no weak cipher suites left to renegotiate to and this becomes a non-issue (except that the grade is still an F and that looks bad)?

"Insecure Renegotiation" is not about cipher suite selection; it is about a kind of Man-in-the-Middle attack that goes thus:

Attacker connects to the server and performs a first handshake.
Attacker pushes some data (e.g. an HTTP POST request).
Client connects to attacker and sends its initial handshake sequence.
Attacker forwards the client handshake messages to the server and back. From the point of view of the client, this is the initial handshake; from the point of view of the server, this is a renegotiation within the context established initially with the attacker.
From that point onward, the attacker blindly forwards data back and forth. The server initiates some authentication mechanism with the client.
The server erroneously considers that the authentication result covers the complete dialogue, including the data that the attacker pushed before the renegotiation. As a result, the server may apply the attacker's request as if it came from the authenticated client.

RFC 5746 is a mechanism (a TLS extension) that aims at making initial handshake and renegotiation handshake distinct. If supported by both client and server, then the server, in the scenario above, will notice that the ClientHello in the second handshake is tagged as "initial", not as "renegotiation", and will thus reject the attempt. When some report tells you that your server does "insecure renegotiation", it really tells you that your server does not support RFC 5746. This is completely unrelated to cipher suite selection, and there is no change in your list of cipher suites that will do anything for or against that; this is an orthogonal setting.

One may note that allowing insecure renegotiation does not necessarily imply an exploitable hole. It really depends on how the server handles user authentication, in particular with regards to renegotiations. Conceptually, a server who receives an unauthenticated request may initiate a renegotiation (e.g. with certificate-based client authentication) and then, after the second handshake, send an HTTP redirect so that the client sends the request again. In such a case, there would not be any problem with lack of support of RFC 5746. However, existing Web servers do not operate that way, hence a common need to "strengthen" renegotiations systematically at the TLS level.

(In general terms, the problem with renegotiations is that SSL/TLS provides security only in the chronologically forward direction, while users of SSL/TLS, i.e. Web server, commonly assume that security extends backwards as well, even across renegotiations. RFC 5746 fixes a known, explicit attack modality, but it is unclear -- or at least undocumented -- whether it really ensures backward-facing authentication up to the initial handshake.)


SSRF when user input is appended to hostname Is it considered a SSRF vulnerability (or is it dangerous at all) if the backend of an application fetches a URL that is somewhat based off of user input, in a way similar to this

get("https://thehostname.com/a-directory/" + userinput)

So, because the hostname is hardcoded before the user input, it shouldn't be possible to scan the internal network or anything, right?

Without an open redirect vulnerability in https://thehostname.com/*, I don't see how you could pull anything off with that.

Edit: In the specific scenario that I am asking this question for, the server only responds with a true/false/error, indicating whether the content type of http response is a pdf, or if it failed to fetch the page (404, or host is down).

As mentioned in the comments, always sanitize user input.  Always assume the user may be malicious.  While your snippet doesn't appear to be directly exploitable, you should also consider that not all URL parsers behave the same and the library you're using may affect what sort of exploitation you may be vulnerable to.

In a perfect world, you may be safe, but it's always good to do additional checks just to be sure.  For example, if you only want users accessing certain pages, you should set up a white list.  If they're not supposed to access subdirectories, make sure no slashes exist in the URL (encoded or otherwise).


If TCP is more "secure" than UDP, how would a practical UDP "attack" look, for example during the initiation of a MS RDP connection? In accordance to the recent question Why is TCP more secure than UDP?. How would an "attack" look when it comes to the practical aspect? A great example would be the use of TCP or UDP for Microsoft Remote Desktop (RDP) sessions using the mstsc command in Windows.

It's known to usually have way better user experience and speed when using UDP instead of TCP. As Steve Sether answered the point especially is to have an established connection first. Also he stated it depends on the application's implementation which seems a bit like a blackbox to me.

If TCP is more "secure", how would a practical UDP "attack" look, for example during the initiation of a MS RDP connection? In other words, would it technically be possible to spoof anything during initiation of such session over UDP, that would not be possible using TCP?

UDP is deemed "less secure" due to the fact that it is stateless. When you send a UDP packet, you have no guarantee it will arrive. You also have no guarantee the person sending you the packet is who they say they are. However you are guaranteed that the packet will be routed to the receiver, or lost.

The MS-RDP protocol from my knowledge uses TCP, though there was an option to also use UDP alongside. Authorization itself is performed over TCP. Once access has been granted, UDP traffic will be allowed. Authorization also includes exchanging a key for symmetric encryption, ensuring data confidentiality.

If you want to know how a UDP attack looks, take a look at DNS Reflection Attacks. Because UDP is stateless, it's trivial to modify the source IP address. An attacker can send a small packet to a DNS server, causing the server to send back a response that's much larger than the request. However since the request is forged, the server actually sends the packet to the target system. Do this repeatedly, and you've launched a denial of service attack.


intentionally vulnerable virtualbox or vmware appliances for practicing mobile pentest? Is there any virtualbox or vmware appliances or anything like metasploitable that one can use to practice mobile pentest without the real hardware?
I can find those for traditional ethernet but what about mobile, especially phone network like 3g/lte and also others like wifi, bluetooth etc.

Thanks.

There are vulnerable mobile apps that one can run in an emulator,
simulator, or on device. (*)
There is a testing ground for smart grid and industrial controls
    systems which includes an RF test ground component. It's called
    SamuraiSTFU, a nameplay on the original SamuraiWTF guest VM for testing vulnerable web applications. I think WTF stands for Web Testing Framework while STFU stands for Security Testing For Utilities (i.e., smart grids and control engineering systems). (**)
I agree that there should be a guest VM to practice the full mobile
stack including carrier technology such as 3G and LTE, however this
is a gap that can be filled. Start a project to do it yourself!

(*) A short list of available apps include iGoat, "Damn Vulnerable" apps of other kinds, the Exploit-Me labs from Security Compass, and most importantly the amazing work behind OWASP GoatDroid and the Sieve APK app intended to be a testing ground for the Drozer mobile attack framework. Ideally, a person interested in the security footprint of the mobile space would utilize a variety of open source apps (available by searching the Internet) or by building their own apps that expose the full functionality of the vendor SDKs.

(**) The particular components in SamuraiSTFU that cover RF technology generally focus on technologies that are not specifically 3G or LTE. Thus, I might recommend instead that you check out a variety of other resources including a book that came out last week called "Getting Started with OpenBTS" (O'Reilly Press) which mentions the Ettus Research and other GSM network hardware/software that can run production, but amateur, carrier-like networks.

Other important titles include: "Hacking and Securing iOS Applications", "Bulletproof Android: Practical Advice for Building Secure Apps", "Android Security Internals", "Mac OS X and iOS Internals: To the Apple's Core", "Android Security Cookbook" -- as well as a few titles that you may or may not be able to get early access to: "The Mobile Application Hacker's Handbook" and "iOS Application Security: The Definitive Guide for Hackers and Developers", but that will be out soon available from bookstores such as Amazon or services such as SafariBooksOnline or Books24x7. There are a few books that I left out of this list because there are quite a lot and perhaps too numerous to list right here right now.

Just as an aside, I do a lot of mobile and payment (e.g., digital wallet) testing for my full-time job, about 8 years in these specific industries. So I've been penetration testing mobile devices and platforms since the original iPhone was released. I have had a keen interest in NFC technology, especially Secure Element and TEE sub technologies involved in the mobile payment space directly (the Android Internals book mentioned above touches on these a little bit).

For a more complete set of resources covering 3G and earlier technologies in terms of security issues one would expect to hear about as exploitable from a penetration testing perspective, be sure to check out all of these:

http://www.zjulian.com/look-at-that-backend
http://events.ccc.de/congress/2014/Fahrplan/events/6531.html
http://events.ccc.de/congress/2014/Fahrplan/events/6122.html
http://events.ccc.de/congress/2011/Fahrplan/events/4663.en.html
http://events.ccc.de/congress/2010/Fahrplan/events/4090.en.html
http://events.ccc.de/congress/2010/Fahrplan/events/4151.en.html
http://events.ccc.de/congress/2009/Fahrplan/events/3555.en.html
http://events.ccc.de/congress/2009/Fahrplan/events/3654.en.html
http://events.ccc.de/congress/2008/Fahrplan/events/2997.en.html
http://events.ccc.de/congress/2002/fahrplan/event/495.en.html
http://media.ccc.de/browse/congress/2014/31c3_-6249-en-_saal_1_-201412271715-_ss7_locate_track_manipulate_-_tobias_engel.html#video
http://blog.ptsecurity.com/search/label/telecom


How does my ipcamera work despite UPnP disabled on home router? Recently I bought an IPcamera in order to test its security. Unfortunately, it just has 2 ports open :

554/tcp RTSP
5000/tcp UPnP

I was pretty sure the ipcamera would poke my router and open up internet facing port (that's what UPnP is suppose to do, right?) through which I can test further but unfortunately that is not the case.

My home router (D-Link) has UPnP disabled by default. I explicitly enabled UPnP on the router to test for open ports but ipcam is not opening any port facing internet.

  Question:

If ipcam is not opening internet facing port then what is UPnP used for in the ipcam ?
Why is ipcam not opening external port even after UPnp enabled in router?

It just opens an outbound connection to the server, like a regular user would to upload to youtube or stream to twitch.


How do I securely transfer information between airgapped systems? I'm trying to take information that's on Computer A, write it onto some form of persistent storage, and copy that information onto Computer B. Both will be running a relatively recent version of Windows 10. The computers may be hundreds of feet to tens of miles from each other.
My current plan to accomplish this is using USB flash drives. My threat model does not involve state level actors, merely people knowledgeable enough to use USB malware.
I'd like to know:

Alternatives to USB, for example if we have a serial port available
Where to find the state of the art as far as group policy for disabling any kind of execution of code that comes in over USB
Antivirus or otherwise that similarly protects the computer from USB based malware

The systems must be airgapped, and they must have this information transfer occur. The information is on the order of tens of MB, and will only be transferred about once every 24 hours. The device used for the transfer may be destroyed after a single use if that improves the security. We're not concerned so much about the integrity of the data (it's already encrypted + ECC formatted), more the possibility for Computer A to be infected with malware from the USB while it writes the data out.

I don't know the classification/confidentially level of the data that needs to be moved from Computer A to Computer B.  You did state that these systems must be air gapped, so I will assume that the information is critical thus it needs to be protected.

Option 1:
Save the required information to an Iron Key. Mail the Iron Key to Computer B location for data transfer.  Iron Keys are not perfect, but they do use AES 256-bit hardware encryption, have password protection and use onboard anti-virus scanning and active malware defenses.
Pros:
This solution is more secure than a stand USB drive.  The odds of getting infected by malware are low.
Cons:
Requires multiple Iron Keys, which cost about $130 a piece.
Requires mailing costs and potential delays in deliver

Option 2:
Save the required information to a flash memory card in an encrypted format. Mail the memory card to Computer B location for data transfer. Destroy the flash memory card.
Pros:
Flash memory cards are very cheap, so you can use a card once. The odds of getting infected by malware are low.
Cons:
Requires multiple cards.  30 cards cost about as much as a single Iron Key
Requires mailing costs and potential delays in deliver

Option 3:
Save the required information to an [Iron Key.] Use a non-air gapped system to securely transfer the files to a non-air gapped system at Computer B location.  Save the files to another Iron Key.  Upload the files to Computer B and erase the files from the Iron Key.
Pros:
Fastest method to move files between Computer A and Computer B.
Cons:
Requires 2 Iron Keys at both location
Requires a secure non-air gapped system at both location.  This system could a MacBook, which is stored in a safe until needed.  It could also be iPad pro, which could be used to transfer the files.
Overall this method is the most expensive, but it is the fastest and can be highly secure depending on the security controls established.


What is the distinguishing point between a script kiddie and a hacker? When I think of a script kiddie I think of someone who might barely research a tool then point it at a website - things like the recent question about LOIC come to mind when I think of that. A hacker (either black/white/grey), I imagine, is much more methodic and plans his route - they're running this system, with that IDS, and these security measures - so their attack is hopefully more pinpointed, less noisy, and more effective.

What I'm having trouble with is distinguishing between the two - a script kiddie might use metasploit, Cain & Abel, or Nessus, but a hacker or pentester would probably use them as well. What distinguishes these two? I know the script kiddie most likely won't know what's going on, but to what extent does the hacker need to know what's going on to not be considered a 'script kiddie'?

For example I like security and I am really interested in learning about it. I know about various tools such as metasploit, nessus, cain, hamster/ferret, wireshark, nmap, LOIC, etc. but I don't use them because I don't know how, or quite understand how exactly they work. I've been setting up a network of VMs to play with and do it responsibly. If that's considered being a script kiddie, what would be the defining line between a script kiddie and a hacker?

It really depends on your point of view.

From the outside, the "script kiddie" is, nominally, the wannabe attacker who uses tools written by other people (the "scripts"), without really understanding what is going on. Everybody uses tools written by other people (if only operating systems, C compilers, libraries...), but some people have a certain understanding of how things work internally, and could, at least potentially (if free time was free), rewrite these tools from scratch.

The script kiddie himself does not think of himself as a "script kiddie", of course. In his view, he is an "elite hacker", and the other people are script kiddies. The expression "script kiddie" is meant as a disparaging designation, to insist on the alleged youth of the individual and its associated inherent shame. To consider youth as shameful by nature, you have to be young. Old people don't think of youth as a disgusting fact to hide, but as a lost treasure. When somebody uses the expression "script kiddie" too often, you can often infer that this somebody is himself not very old, and a metaphorical scripty smell probably lingers around his person.

A more neutral, less emotionally charged classification would be about competence. Attackers are more or less competent at what they do. Just like anybody. The less competent attackers, which other script kiddies are prone to point out and mock as "script kiddies", will run their tools (collected on the Internet), and if the off-the-shelf tools don't succeed in the attack, they soon give up. More competent attackers will adapt their tools to the specific situation; they see the tools more as a generic framework for attacks than the actual instruments.

Given the above, to avoid being seen as a script kiddie, the trick is to distantiate yourself from the kiddie term, not from the script. Scripts, and, more generally, tools, are neutral. It is the maturity of your reactions, or lack thereof, which will mark you as a script kiddie or not. Despite what is usually believed on the subject, it has very little to do with technical skill; it is a matter of communication, of public relations. Be cool, don't whine, and you will never be a script kiddie.