How hard is it to intercept SMS (two-factor authentication)? A lot of two-factor authentication mechanisms use SMS to deliver single-use passphrase to the user. So how secure is it? Is it hard to intercept the SMS message containing the passphrase? Do mobile networks use any kind of encryption on SMS?
I found an interesting article regarding two-factor authentication and the ways it could be attacked.

GSM includes some protection through cryptography. The mobile phone and the provider (i.e. the base station which is part of the provider's network) authenticate each other relatively to a shared secret, which is known to the provider and stored in the user's SIM card. Some algorithms known under the code names "A3" and "A8" are involved in the authentication. Then the data (as sent through the radio link) is encrypted with an algorithm called "A5" and a key derived from A3/A8 and the shared secret.
There are several actual algorithms which hide under the name "A5". Which algorithm is used depends on the provider, who, in turn, is constrained by local regulations and what it could license from the GSM consortium. Also, an active attacker (with a fake base station) can potentially force a mobile phone to use another variant, distinct from what it would have used otherwise, and there are not many phones which would alert the user about it (and even fewer users who would care about it).

A5/0 means "no encryption". Data is sent unencrypted. In some countries, this is the only allowed mode (I think India is such a country).
A5/1 is the old "strong" algorithm, used in Europe and North America.
A5/2 is the old "weak" algorithm, nominally meant for "those countries who are good friends but that we do not totally trust nonetheless" (it is not spelled out that way in the GSM specifications, but that's the idea).
A5/3 is the newer algorithm for GPRS/UMTS.

A5/3 is a block cipher also known as KASUMI. It offers decent security. It has a few shortcomings which would make it "academically broken", but none really applicable in practice.
A5/2 is indeed weak, as described in this report. The attack requires a fraction of a second, subject to a precomputation which takes less than an hour on a PC and requires a few gigabytes of storage (not much). There are technical details, mostly because the GSM protocol itself is complex, but one can assume that the A5/2 layer is breakable.
A5/1 is stronger, but not very strong. It uses a 64-bit key, but the algorithm structure is weaker and allows for an attack with complexity about 242.7 elementary operations (see this article that I wrote 12 years ago). There have been several publications which turn around this complexity, mostly by doing precomputations and waiting for the algorithm internal state to reach a specific structure; although such publications advertise slightly lower complexity figures (around 240), they have drawbacks which make them difficult to apply, such as requiring thousands of known plaintext bits. With only 64 known plaintext bits, the raw complexity is 242.7. I have not tried to implement it for a decade, so it is conceivable that a modern PC would run it faster than the workstation I was using at that time; as a rough estimate, a quad core PC with thoroughly optimized code should be able to crack it in one hour.
The size of the internal state of A5/1, and the way A5/1 is applied to encrypt data, also make it vulnerable to time-memory trade-offs, such as rainbow tables. Again, see the Barkan-Biham-Keller article. This assumes that the attacker ran once a truly massive computation, and stored terabytes of data; afterwards, the online phase of the attack can be quite fast. Details very quite a bit, depending on how much storage space you have, how much CPU power is available for the online phase, and how long you are ready to wait for the result. The initial computation phase is huge but technologically doable (a thousand PC ought to be enough); there was an open distributed project for that but I do not know how far they went.
SMS interception is still a specific scenario. It is not a full voice conversation; the actual amount of exchanged data is small, and the connection is over after a quite short time. This may limit the applicability of the attacks exposed above. Moreover, the attack must be fast: the point of the attack is to grab the secret password sent as a SMS, so that the attacker can use it before the normal user. The attacker must be quick:

The server typically applies a short timeout on that password, such as a few minutes. SMS transmission is supposed to be a matter of a few seconds.
The user is not patient (users never are). If he does not get his SMS within five minutes, he will probably request a new one, and a well-thought two-factor authentication system on the server would then invalidate the previous one-time password.

Things are easier for the attacker if he already broke the first authentication factor (that's why we use two-factor authentication: because one is not enough). In that case, the attacker may initiate the authentication request while the target user is blissfully unaware of it, and thus unlikely to raise any alarm if he fails to receive a SMS, or, dually, if he receives an unwanted SMS (the attacker may do the attack late at night; the attacked user will find the unwarranted SMS only in the morning, when he wakes up, giving a few hours for the attacker to enact his mischiefs).
GSM encryption is only for the radio link. In all of the above, we concentrated on an attacker who eavesdrop on data as sent between the mobile phone and the base station. The needed radio equipment appears to be available off-the-shelf, and it is easily conceived that this scenario is applicable in practice. However, the SMS does not travel only from the base station to the mobile phone. Its complete journey begins at the server facilities, then goes through the Internet, and then the provider's network, until it reaches the base station -- and only at that point does it get encrypted with whatever A5 variant is used.
How is data secured within the provider's network, and between the provider and the server which wants the SMS to be sent, is out of scope of the GSM specification. So anything goes. Anyway, if the attacker is the provider, you lose. Law enforcement agencies, when they want to eavesdrop on people, typically do so by asking nicely to the providers, who invariably comply. This is why drug cartels, especially in Mexico and Colombia, tend to build their own cell networks.


Will data be seen if an insecure packet is sent to an offline server? If a website is running on on https no http:80 is listening, if a browser issued a request to http://website.com, could this info be seen via MITM attack?

If the website is not listening on port 80 and the address http://website.com (or whatever URL, assuming website.com here means the domain that is listening on port 443 and not listening on port 80) is entered in the browser then you will only see a couple TCP SYN packets, not the HTTP request. This is because the TCP connection is attempted but not completed and so no HTTP protocol request gets sent.

On the other hand if the website redirects HTTP to HTTPS (and so is listening on port 80 and 443) then the initial HTTP request will be seen and will receive a 302 (redirect) response.


Appsec Standards Organizations? I'm a Java EE developer and I was wondering if anybody has had experience with the OWASP Project and could weigh-in as to how it measures up as a security standards organization. They have a huge website with multitudes of documents, sub-projects, frameworks/APIs, etc., and I just want to be sure that they are well-regarded before I start heading down the path of learning about it from the ground-up. I would hate to spend the next couple of weeks investing time & energy in this group only to find out that they aren't credible for whatever reason.

Are there other project bodies that are also open source that I should consider, as well?

OWASP itself does have a large number of projects, some at greater maturity than others.
As an organisation OWASP does have key initiatives which have been accepted globally, so you wouldn't be alone in choosing to learn more.

My main market includes global banks and other financial services organisations, as well as some other industries such as oil and gas, and aside from standards such as PCI-DSS, ISO 27001 etc, the single de-facto standard across their web security teams is the OWASP Top Ten.

ESAPI is also extensively used across the IT Security space, along with a few others.


Reconcile IMAP4 RFC with No RC4 RFC RFC 3501 states:

  IMAP client and server implementations MUST implement the TLS_RSA_WITH_RC4_128_MD5.

RFC 7465 states:

  o  TLS clients MUST NOT include RC4 cipher suites in the ClientHello
       message

  o  TLS servers MUST NOT select an RC4 cipher suite when a TLS client
       sends such a cipher suite in the ClientHello message.

  o  If the TLS client only offers RC4 cipher suites, the TLS server
       MUST terminate the handshake.  The TLS server MAY send the
       insufficient_security fatal alert in this case.

I don't see anyway to reconcile these two RFCs. I have seen that Google has turned off RC4 on its email servers and is requiring TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, but that's not necessarily interoperable with the rest of the world.

Is there an update to RFC 3501 coming that changes the mandated TLS cipher suite?

I don't see anyway to reconcile these two RFCs

There are two ways to reconcile them:

Choose Security (RFC 7465) over Backwards Compatibility (RFC 3501)
Choose Backwards Compatibility (RFC 3501) over Security (RFC 7465)

  I have seen that Google has turned off RC4 on its email servers and is
  requiring TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, but that's not
  necessarily interoperable with the rest of the world.

Google chose option #1.  They probably took a census of all their IMAP traffic, reviewed the Client Cipher Suites being suggested, saw that either nobody or a negligibly small number of clients would be impacted, and then shut off RC4.

  Is there an update to RFC 3501 coming that changes the mandated TLS
  cipher suite?

Doubtful.  RFCs require common sense.  It is to be expected that narrow technical recommendations like mandated ciphers in an otherwise large specification will be overridden by later, more specific RFCs.  Nobody's going to go revise the IMAP RFCs just to make sure they reflect current TLS practice; everybody is expected to vote with their feet with current TLS practice.

This is all in line with the special status of RFCs - they're rules, which everybody has to follow, except when they aren't or they don't.  The only force an RFC has is the critical mass or people paying attention to it.


CA with lower key size than issued certificates If a root certificate has a 2048 bit key is it correct to assume that if a certificate request signs a request made by a 4096 bit key and generates a certificate that the security has been weakened to some degree.

For example if a client application is encrypting the data (HTTPS) then, since the issued certificate has a 4096 bit private key / cert that the strength of the encryption / confidentiality of the HTTPs connections aren't weakened, only the trust associated with the CA?

The strength of the key in the CA certificate is only relevant for the strength of the signature on the issued certificate. A weak enough CA key means that somebody could find the matching private key and would then be able to create arbitrary certificates which look like they were issued by the CA.

Thus a weak CA key does not affect the strength of the encryption or the strength of the key exchange but it weakens the authentication part of the TLS handshake. This means that the client more likely considers a server as the correct one even though it is an attacker which was able to create a fake certificate which essentially means a possible man in the middle attack.

Still, the 2048 bit RSA key in your example is still considered strong enough at the moment so it is not actually considered a practically relevant weakness currently.


Guidelines for time for encryption key regeneration I am looking at using a third party key distribution protocol. I do not have much details of the internals itself. However I am required to configure the time for regeneration of the (128 bit symmetric keys used for encryption. Are there any standard mechanism to determine that. I understand that regeneration will be depend on the volume of data / or time duration so that we reduce the chances of an attacker capturing and breaking the key. But I could not find more details after searching the internet. Thanks for any answers

No, there aren't any standard formulas. The reason for that is that e.g. an AES-128 key may be used for very large amounts of data. Modes of encryption, protocol requirements and requirements on the data itself however do pose limits and those limits are usually much lower than the one for the symmetric cipher.

Say that you could use an AES key to encrypt 2^48 blocks in CBC mode. In that case you could encrypt 2^52 bytes or 4.503.599.627.370.496 bytes or about 4.5 peta byte if I'm not mistaken. And that's for CBC mode, the block cipher itself should have higher limits.

So the question is more how much separation you require between the protected blobs of data.


Heartbleed check for mobile and mobile apps I have run a heartbleed detector from Lookout on my Android phone. It says:

  The version of openSSL is affected by the heartbleed bug but the
  vulnerable behaviour is not enabled.

What does it mean by not enabled?

I can see /system/lib/libssl.so file on the phone and found openssl on it. It shows 1.0.1c. Does that mean my phone is vulnerable to heartbleed bug?

My other question is: How I can check whether a particular Android app is vulnerable to heartbleed or not? I don't want to use any third party app. I have seen https://github.com/musalbas/heartbleed-masstest/blob/master/ssltest.py but I want to do it with an app. I don't know the domain name the app is communicating to. Are the app bundle the OpenSSL libraries with apk, If yes how to find the version of OpenSSL being used.

@Solution: I have wriiten python module which takes an APK and it do the check for openSSL version and heartbeat extension.

import zipfile
import os
import re

def heart_bleed(tempdir, msl_outputfile):
    parrent_tempdir = tempdir.split('tmp')[0]
    sslpattern = re.compile("1.0.1[a-f]")
    flagssl = False
    flagheartbleed = False

    msllst_heartbleed = []
    msc_vulid = "heartbleed"
    msc_infoseverity = "Info"
    msc_medseverity = "Medium"
    apkpath = ''
    if (parrent_tempdir):
        for root, dummy_dirs, files in os.walk(parrent_tempdir):
            for allfile in files:
                if allfile.endswith(".apk"):

                    apkpath = os.path.join(root, allfile)

        #print(apkpath)
        with zipfile.ZipFile(apkpath, "r") as msl_apkread:
            for i in msl_apkread.namelist():
                if i.endswith(".so"):
                    data = msl_apkread.read(i)
                    if "part of OpenSSL" in data:
                        start = data.index("part of OpenSSL")
                        resultdata = str(data[start:start+40])
                        sslversion = re.findall(sslpattern, resultdata)
                        if sslversion:
                            flagssl = True

                            if "tls1_heartbeat" in data:
                                flagheartbleed = True

        if flagssl and flagheartbleed:
            print("The App is using OpenSSL version " + sslversion[0] + " which is vulnerable to Heartbleed and Heartbeat extension is enabled."))
        elif flagssl or flagheartbleed:
            print("The App is using OpenSSL version " + sslversion[0] + " which is vulnerable to Heartbleed but Heartbeat extension is disabled."))

Please comment is it right to do ?

Heartbleed is a bug with the 'heartbeat' function within vulnerable versions of SSL. That's why the name 'heartbleed'. Your check is saying that your version is vulnerable, but the heartbeat function is not enabled.


What function is used to generate client random in TLS I've been learning TLS. During the Client-Server Hello their random values are shared. The client generates a 28 byte random and combine it with 4 bytes of epoch time to generate a 32 byte random token. How do they compute these random?

Simply calling the system random generators such as /dev/random or are there any other function in browser to do this? What about the server random?

The source is not specified in the standard, making it implementation-dependent.

According to RFC 5246 § 7.4.1.2 for TLS 1.2, randomness is only described as:

  28 bytes generated by a secure random number generator.

This means it will be entirely implementation-dependent. Any function that produces secure random data can be used. For many modern browsers, the implementation involves requesting a random seed from the operating system (for example, using /dev/urandom on Linux), and then using that to power an in-process cryptographically secure random number generator.

What actually constitutes "secure random numbers" is specified in BCP 106, a document that provides advice for generating random numbers, the source of the random numbers, how to test the random numbers, etc. This is meant merely as a declaration of best practices and is not mandatory. However, common operating systems tend to follow these practices when collecting random numbers that are exported to userspace applications, such as web browsers.


RSA maximum bytes to encrypt, comparison to AES in terms of security? What is the maximum number of bytes for encrypting a plaintext message using RSA that is reasonably secure and also efficient and would AES be better for the same size in bytes? The encryption doesn't have to be public by the way, I'm just wondering if AES is just as good on a short message as it is on a large document. Basically the message or document would be sent encrypted but the key would never be made public. I guess that would also defeat the purpose of RSA but I've read a few times online that RSA is good for short messages and AES is good for long ones.

RSA, as defined by PKCS#1, encrypts "messages" of limited size. With the commonly used "v1.5 padding" and a 2048-bit RSA key, the maximum size of data which can be encrypted with RSA is 245 bytes. No more.

When you "encrypt data with RSA", in practice, you are actually encrypting a random symmetric key with RSA, and then encrypt the data with a symmetric encryption algorithm, which is not limited in size. This is how it works in SSL, S/MIME, OpenPGP... Regularly, some people suggest doing "RSA only" by splitting the input message into 245-byte chunks and encrypting each of them more or less separately. This is a bad idea because:

There can be substantial weaknesses in how the data is split and then rebuilt. There is no well-studied standard for that.
Each chunk, when encrypted, grows a bit (with a 2048-bit key, the 245 bytes of data become 256 bytes); when processing large amounts of data, the size overhead becomes significant.
Decryption of a large message may become intolerably expensive.

When encrypting data with a symmetric block cipher, which uses blocks of n bits, some security concerns begin to appear when the amount of data encrypted with a single key comes close to 2n/2 blocks, i.e. n*2n/2 bits. With AES, n = 128 (AES-128, AES-192 and AES-256 all use 128-bit blocks). This means a limit of more than 250 millions of terabytes, which is sufficiently large not to be a problem. That's precisely why AES was defined with 128-bit blocks, instead of the more common (at that time) 64-bit blocks: so that data size is practically unlimited.


Padding oracle - Vulnerable Version of ASP.NET I would like to install the vulnerable version of ASP.NET for testing purposes. I've thought about it and I guess the best way would be to delete/disable some security updates to make that possible. Currently I'm running windows XP with all security updates installed.

On the following link http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx I've seen that the 3.5 ASP.NET security update was KB2416471, but I didn't found that update on my system, so I guess it must have the newer version of ASP.NET 3.5 installed which already has this fixed.

Any idea how would I get my hands on the system that is still vulnerable to the Padding Oracle on the ASP.NET Forms Authentication cookie to test it?

I would suggest running a virtual machine with external network disabled, and install a fresh OS from an old ISO image which predates the fix. Disabling external network prevents automatic installation of updates; it also blocks "Windows activation" so you will have only a few days or weeks to try it (but you can "stall" the clock between runs: since the VM has no external network, it has no way of cross-checking its knowledge of the internal clock).

If the VM technology is VirtualBox, use "Host-only networking" as described in the manual. This will allow your own desktop system to access the server in the VM.


Manually sending PIN Change/Unblock Command to IC card In the EMV documentation (EMV Book 3 Section 6.5.10), the PIN Change/Unblock command provides the option to change or unblock a card's PIN, and also handles resetting the PIN Try Counter (EMV tag 0x9F17) along the way. This command is an issuer script, meaning it is sent by the issuing bank to an ATM or a POS which then forwards it to the card thereby resetting the counter and optionally changing the PIN.

Referring to the details in the photo above, what would happen if I were to manually send this command to the card, setting P2 as '00' and padded the Data field as jargon bits? Would this succeed in resetting the PIN Try counter?
Unfortunately, the EMV docs don't really shed light on this command like they do in others. I'm interested in the exchange of data that happens between the card and the terminal AFTER the terminal forwards the PIN Change/Unblock command APDU from the issuer script to the card.
I would also really appreciate it if anyone can point me to a software tool where I can simulate this or similar EMV scenarios.
P.S: See Guessing PIN code of smartcard using brute force and offline reader and https://stackoverflow.com/questions/53645555/pos-emv-card-pin-change for added context if needed.

PIN CHANGE/UNBLOCK is the post-issuance command that can only be sent using issuer script. Issuer encrypts issuer script by the session key derived from "Script encryption key". The MAC is also generated over the encrypted blob using session key derived from "Script MAC key".
Both script encryption key and script MAC key are present in the card.
Issuer script is sent with the Issuer Authentication Data as shown in EMV Book 4, 12.1.3 - Authorisation or Financial Transaction Response. This happens after terminal issues first Generate AC (Application Cryptogram) command and the card responds with Authorization Request Cryptogram (ARQC) for online approval.
Without script keys, the card will reject the script. Card also has replay protection to prevent reusing the captured response from earlier transactions.

I'm not aware of any step in the typical EMV contact transaction where the card actually decrypts the cryptogram sent from the bank ~or the terminal~.

The Issuer Authentication Data contains Authorization Response Cryptogram (ARPC) to verify approval/rejection.
ARPC = MAC(ARQC || CSU || Proprietary Authentication Data)
CSU = Card Status Update (contains data sent to the ICC to indicate whether the issuer approves or declines the transaction, and to initiate actions specified by the issuer. Transmitted to the card in Issuer Authentication Data)
Issuer Authentication Data = ARPC || CSU || (optional) Proprietary Authentication Data


What are possible approaches and arguments for securing corporate IT systems with most computers being portable? I was employed  as the only system administrator by a company where half of computers are portable ones being taken away for work at home, business trips, visits to clients, etc. having access to practically everything while connected to internal corporate networks.

And most users of computers, even desktops, are administrators. In Windows workgroup(s), no Active Directory/Domain Controller.

Update: 35+ Windows 7, XP, Vista workstations and two Windows 2003 servers, one running for terminal services (serving to all the
accounting applications), another Windows 2003 Server is for websites/portal and external
access from internet. The office (internal networks) is distributed over 2 main locations (one is the
main office and another is producing facilities in another city) and
the main office has 2 buildings with communication over WiFi.
The employees (sellers, accountants, lawyers) plug portable computers into internal cable network while at office
See mor eonformation on my specific situation in my question How to make sure that previous sysadmin has not compromised corporate IT security? [closed]
Update End

What are the most urgent first steps for securing/re-organizing such IT corporate infrastructure and arguments to convince the top management in their necessity?

Trust nothing.  All mobile devices should be placed on their own network segment,  which is doesn't have access to the entire infrastructure.  This untrusted network should be treated no differently than the open internet.  Make sure you expose only the services that are needed to this untrusted network.

Make sure all mobile devices have anti-virus software.  I am still skeptical of anti-virus software for phones.  Make sure devices are updated regularly.


Is there any reason to show the same message for invalid username as password? I've seen a security question/requirement that a website login return the same error message for invalid password as for non-existent user. The idea being that this it makes it impossible to discover valid usernames by scanning the error messages.

In cases where self-signup is available, does this make any difference? You can't allow signup with the same username twice, so an attacker could just attempt to sign up with usernames until a valid username is found.

Thanks

If there's at least one way to discover which user names are available on the site, it then means that you can try to brute-force/dictionary-attack/social engineer those specific accounts. In the case you described then it doesn't make any tangible security difference to try to hide the error reason on the login page, since it's trivial to discover the real reason otherwise.

Depending on what's more important to you, you can either make your login process more user (and attacker) friendly, or instead try to secure your registration (or any other) process that might reveal which accounts exist on your system.

When defending against such cases related to the the authentication process for a typical web application, you should normally take into account the following routes:

Signup/Registration - this can reveal which accounts are available as well as allow flooding your system with fake/stale accounts, name-squatting etc. Captcha can usually provide good protection, as well as timeouts, but won't stop manual, slower attacks. I would also suggest not giving hints about username availability or the success of the registration process. You can just say "Thanks for registering. A confirmation email will be sent shortly to confirm the account" (or something like that)
Login page - this is the obvious point, and where most applications already have fairly standard protection, including good-practice of non-revealing errors etc. Slowing down the login process, or monitoring abuse can also help. Lockout for failed logins is also a possibility, but then you're more prone to denial-of-service attacks.
Forgot password - this is often neglected when considering information leakage. When someone puts their email/username in the forgot password field, you should probably respond with the same message regardless if the email/account is known or not. Note that this might create support issues ("I put in my email and your system said it's sending me a reset email, but I didn't get anything...")
Account details/email changes - many applications allow you to, e.g. change your email address or even account name. This would also potentially leak out whether or not a given account or email address already exist or not. Same rules apply here.


How to find out if my MBR has Evil Maid code? If Truecrypt Bootloader will remain visually the same, how can I find out if it was infected?

The first thing that comes to mind would be some sort of custom bootable USB stick that you keep with you. When you come back to your computer you first insert and boot from it, and it could scan your disk's MBR for changes. The USB device could then report a change and rewrite the MBR if needed.

You could consider using a software solution that once booted, would detect if a change occurred after the fact, but it's possible that would be too late as you can't be sure what the MBR virus will do. If it's truly a simple evil maid then maybe it just records the password you entered in, which you could change and possibly be fine, but that is a risk you probably don't want to take. There are many MBR viruses that do much more damage than recording passwords like the evil maid attack.


Register confirmation email with plain password Yesterday I registered on a site that looked good and secure enough, or at least it was.

The problems are:

When filling registration from, the password was 8 characters max!!
After completing, I received a register confirmation email, with my complete information, including my password!

Now, I've unlinked that site from my email, but I'm wondering:

What danger can come from this?
Can this affect my email in anyway?
If my email is linked to social websites, will that be dangerous?

or that's just acceptable and legitimate?

If they have restricted the max password length to 8 characters, it demonstrates that they are not correctly or safely hashing it into their database. So all of the data you have entered can be considered compromised.

It would be helpful to share the site so that others can avoid it.

If you use that password for anything else, change it everywhere else straight away.

If the site in question has any information about you, I recommend changing that information straight away to something random.

Afterwards, write to them and ask for all of your information to be removed from their systems immediately. Explain to them politely why you are doing this.

What danger can come from this?

All of the information you've entered must be considered compromised since they have clearly demonstrated a complete lack of understanding or care about the data.
Can this affect my email in anyway?

As Mirko says, if you've used the same password then you need to change it immediately. Otherwise, the main "danger" is from spam from compromised customer databases.
If my email is linked to social websites, will that be dangerous?

It isn't really dangerous but it may expose you to more spam. Spam can, of course, be dangerous in itself. You might also be exposed to cyber bullying or stalking depending on how vulnerable you might be to such things.


Block An IP Address Scanner On Mac I'm working on an prototype that can spot network scanners, which is working and it spits out the IP address of the scanners, but I need to block them now.

Is there any way to block an IP address from the terminal, it needs to be done automatically by the app so preferably some terminal command that I can fire off and block the IP address from making any incoming connection to any port on the computer.

I'm not sure which direction to go with this, is there some native way to do this or will I need something extra?

The most simple way to block traffic by IP address is to use pf (man pf.conf). Here's a simple script to help you get started.

Warning Be sure to read the manual pages for more information and before running this.

# enable: sudo pfctl -e -f pf.rules
# disable: sudo pfctl -d
set block-policy drop
set fingerprints "/etc/pf.os"
set ruleset-optimization basic
set skip on lo0
scrub in all no-df
table <blocklist> persist
block in log
block in log quick from no-route to any
pass out proto tcp from any to any keep state
pass out proto udp from any to any keep state
block log on en0 from {<blocklist>} to any

You can use pfctl -t blocklist -T add 1.2.3.4 to add hosts to the blacklist and pfctl -t blocklist -T show to view the blacklist itself. To view the pf log, create a network interface with sudo ifconfig pflog0 create and dump its packets with sudo tcpdump -ni pflog0.


What does the last single quote of the sql injection query: ' or "1"="1" ' mean I couldn't fully grasp why the last single quote of the sql query: ' or "1"="1" ' is necessary. So I understand the part until the last single quote '. The first single quote enables to inject the sql and the or "1"="1" part enables the query to always return true. However, I don't understand why the last single quote is necessary to inject the sql.

Think about where the injected string is going. It's being concatenated into a SQL query at a point that is wrapped in string delimiters. String delimiters always need to be paired; if they aren't then the DB engine will detect an unclosed string and reject the query rather than execute it.

An example:

Original SQL "template", before concatenation: SELECT * FROM Users WHERE AccessToken=' + secretParam + ' and you control the content of secretParam.
After concatenation with a real secret, like DEADBEEF: SELECT * FROM Users WHERE AccessToken='DEADBEEF'; this is a valid SQL query.
When using the "correct" SQL Injection string: SELECT * FROM Users WHERE AccessToken='' or "1"="1" ''. In theory, this will return any user whose access token is an empty string (probably nobody) or for whom 1 equals 1 (everybody, the app will probably just take the first record). In practice, though, the DB might not like the empty string hanging out (the final '') after the second test (the or "1"="1") in the WHERE clause; it'll depend on the DB engine what it does with that.
When using your shorter injection string: SELECT * FROM Users WHERE AccessToken='' or "1"="1" '. Now your query ends with a single quote to open a new string, but not only is this string in an unexpected place, it is never closed. Even a forgiving DB that doesn't mind an unexpected string (perhaps concatenating it with the preceding one) will consider this query to be syntactically invalid and reject it.

There are various other ways of dealing with this, especially for DBs that won't tolerate an unexpected string. You can incorporate the quotes in the template to do what you expect, using an injection like ' OR ''=', which would produce SELECT * FROM Users WHERE AccessToken='' OR ''=''; this has the same effect as above (swapping a test of whether the string "1" is itself for whether the empty string is itself) but leaves no dangling apostrophes/quotes or unexpected strings. It's also nice if there are additional tests or clauses after the insertion point, and you want them to be processed correctly.

Alternatively, you can terminate the query after your insertion. For example, many DB engines use -- (two hyphens) as a single-line start-of-comment indicator, similar to // in languages such as C or JavaScript, or # in shell scripts, Python, etc. Thus, you can make your attack string ' or "1"="1" -- and the generated SQL would be SELECT * FROM Users WHERE AccessToken='' or "1"="1" --'; this is a valid SQL statement containing two tests in its WHERE clause, and a single-character comment of ' at the end of the query. That's especially helpful of the query contained additional clauses or restrictions that you wanted to get rid of.


Scanning for files than have been encrypted by CryptoLocker I am just asking in case someone has already done the analysis. A customer has a large set of network drives that were mapped to a CryptoLocker infected machine. The infection itself has been treated. I am looking for a tool or just a binary pattern to match to verify that a file is not encrypted based on a header/identifying characteristic of some sort in the file itself.

Yes, I know the list of encrypted files is in the infected machine's registry.  We are looking for direct verification.

To clarify: We know what extensions could be affected, I am just looking for a way to check if a specific file is encrypted without having a human double clicking on it.  Millions of files potentially affected so a manual test is not an option. Thus far my fallback is good ol' "file" which will give me a confirmed OK, but only on some file types.

I haven't found any commonalities between sample encrypted files yet, other than "that looks random".

We created a free scan tool that finds CryptoLocker encrypted files dumps the list into a CSV file. This is handy when trying to figure out what files need restored from backup.

http://omnispear.com/tools/cryptolocker-scan-tool


Adfs saml credential provider Wanted to see if the following is feasible or is there a way out?

My situation, computers have internet access always (assumption)
I want to write a credential provider with a browser embed and talk to an external saml shib Idp
After saml token is released by shib Idp, I want to submit to AD
Here is where I am in a dilemma: can AD release SID and other info to credential provider to open desktop windows (i.e. In leu of traditional login Userid password submitted to AD via windows login)? If so what version and what config changes I need to make ?

Any documentation you can point to me?

Appreciate any inputs from your end

No, not really. Or sorta, I guess, but it's not usable.

You can fake it by creating a local token, which will eventually create a session and get to the desktop, but you're crippled because Windows doesn't have an AD ticket. As such, you can't reach anything on the domain, and anything requiring Kerberos or NTLM auth will fail in spectacular ways.

Additionally, you can't get a ticket (safely -- anyway) from AD for a user, and you can't make one, without actually authenticating to AD proper. The issued SAML token has no relationship to the ticket, so AD wouldn't know what to do with it.

One thing you could consider is creating an SSPI package on both the client and DC, which would exchange a SAML token for a Kerberos ticket, by virtue of the fact that AD has the necessary permissions to do anything it wants. The catch though is that everyone needs the package, and everyone needs to understand how to use the package.

On top of all that, opening a browser session in the Credential Provider context is downright scary because they run as SYSTEM.


Security of linux shred utility If I am trying to destroy a single file, what is the best method?

shred -uvz -n500 file
dd if=/dev/null of=file
dd if=/dev/zero of=file

I hexdumped a file that was in the middle of shredding, and it was appropriately mangled with what shred said it was writing, but is it secure?

For the sake of this experiment, let's assume any cached versions of this file and anything else that may connect to this file are completely gone. The only remaining trace of the file is the command ran from my history...

Depending on the filesystem, physical device, etc., those will have varying levels of effectiveness.  I'll take a look at each one, and generally I'm assuming ext4 on magnetic hard disk, as it's the most common default Linux FS right now.  I'm also assuming recovery starts immediately after the command completes: i.e., there are no intermediate writes to this filesystem.

  shred -uvz -n500 file

500 passes is overkill.  Generally, it's believed that a single pass is sufficient on modern drives (Source 1, Source 2, Source 3), so the 3 passes shred offers by default should be plenty.  Of course, this assumes that you're overwriting in-place (the same disk blocks) which is true of default ext4 setups.  If you have odd mount options (like journal=data) you'll find this isn't true anymore, and any form of overwriting won't be enough unless you overwrite the entire partition.

  dd if=/dev/null of=file

/dev/null gives EOF upon reading.  Consequently, this just truncates the file, which is equivalent to echo -n ''>file.  All of the data blocks will remain on disk, and can be recovered.  If the file is not fragmented (all data blocks are consecutive) this is trivial, if it is fragmented, it may take much more work to reconstruct the file.

  dd if=/dev/zero of=file

By default (unless conv=notrunc is passed), dd opens the output file with O_TRUNC, which causes the filesystem to immediately de-allocate the existing blocks of the file, then starts writing, triggering new allocations.  Will these be the same blocks as freed by the truncation?  Maybe, maybe not.  It depends on how much space is free, whether the file was fragmented, and your mount options both now and at the time the file was created.  (Switching extents on/off would be a big difference.)  Also, this command, as given, doesn't specify any point to stop -- you'll keep writing until the partition is full.  (Which actually gives you a good chance of overwriting your data blocks, but will probably take much longer than is desirable.)

Finally, you didn't specify what media you're doing this on.  I assumed a magnetic disk above because the answer is much more straight forward.  On an SSD, it's a completely different world.  Wear leveling means you're never going to be overwriting the same blocks, and there are many blocks that exist but aren't visible from the operating system.  Even the built-in security features of SSDs won't necessarily erase your data.  In the case of an SSD, my best recommendation is to encrypt with a strong passphrase, and when you're ready to recycle the drive, hit it with both an overwrite of zeros and an ATA secure erase.  Between the two, there's a very good chance you'll have destroyed the master key, and even if you haven't, forensic recovery will be highly doubtful.


SMS based authentication, handling recycled phone numbers? If a site requires you to authenticate with only a phone number and a one time login code, what safeguards can be put in place such that when I change my phone number and the phone company recycles it, that the person who has my old phone number doesn't accidentally or maliciously gain access to my account on that site?

To clarify, the login screen for this site says "enter your phone number", when you do it sends you a text message with a code, the screen then says "enter the security code". Upon doing so correctly, you are now considered authenticated.

I am not sure of a way to prevent a recycled phone number from gaining unwanted access to an account.

This is assuming that the person who actually owns the account has left it without de-activating it or changing their phone number. This is also assuming the daily traffic for the site is in the tens of thousands range.

SMS authentication works well as part of a 2-factor authentication scheme, on it's own? Not so much.

If the phone number and the value of the code sent in the SMS are the only things required to login then this is vulnerable not just to recycled numbers but anyone who knows the number and can read SMS's sent to it.

Since you were specifically asking about recycled numbers then really the only ways to defend against this threat model are either for user to ensure that they deactivate the link between the account and the phonenumber of for the operator of the site to use a service which provides phone number deactivation information such as PhoneID:

https://www.telesign.com/products/phone-id/

This uses data from telco providers to indicate when a number has been dactivated or changed hands etc.


Emails on iOS and public Wifi On iOS, you enter your password, once, and you can then check your emails via the email app.

Does the app send the password everytime it updates your email?

Is it secure to check your emails this way while connected to a public wifi?

Yes, the app stores your password an uses it to authenticate every time it queries your mail account. This is no different from a stationary mail client like Outlook or Thunderbird.

The password is not transmitted in clear over the network. It is either sent through a TLS encrypted connection or used in a challenge/response authentication scheme. So it is reasonably secure against interception.

In a public WLAN, there's an increased possibility of man-in-the-middle attacks, so you should make sure that your device is reasonably secure against that, for example by properly checking TLS certificates. If in doubt, use a VPN tunnel. This holds for all network services, not just E-mail.


Using metal business card holders as RFID wallets I have been reading about RFID technology and products.  Are metal business and/or credit card holders viable substitutes for RFID wallets? Are all metal wallets Faraday cages?

The simple answer: yes.

A metal case, whether it is solid or a fine enough mesh will block RFID.


How can a seamless cloud storage service be Zero-knowledge? Cloud based storage services like Dropbox and Google Drive are a cause for concern when it comes to privacy. They store encryption keys for your files on their servers. Therefore, anyone who manage to get access to their servers, whether it be a hacker or employee, will be able to get your keys and by extension your files.

On the other hand, services like BoxCryptor or Viivo offer a layer of end-to-end security ontop of Dropbox or Google Drive, while services like SpiderOak or Sync offer this security built in.

However, these services are seamless. That is, all you have to do is download, install, login, and they immediately start working. There is no key given to you to memorize or download. Yet they say that you own the key and the keys are not stored on their servers.

How is it possible that both the keys are not stored on their servers (Zero-knowledge), and you do not have to keep/memorize the keys yourself (seamless)?

The service can create a random encryption key on the client and then encrypt that key with your password, the service will never have access to your plain-text password.


NVidia update service creates local account on system. Does anyone know the users password? Nvidia update service has created a local user on several of my boxes. Does anyone know its password? I recon it could possible be leveraged as an entry way for an attacker.

Details:

wmic useraccount list full

AccountType=512
Description=Used to deliver NVIDIA program updates
Disabled=FALSE
Domain=Stationary
FullName=UpdatusUser
InstallDate=
LocalAccount=TRUE
Lockout=FALSE
Name=UpdatusUser
PasswordChangeable=TRUE
PasswordExpires=FALSE
PasswordRequired=TRUE
SID=S-1-5-21-3740843305-4162061290-2760509455-1004
SIDType=1
Status=OK

EDIT:
I've dumped the hash now and it looks like this:

UpdatusUser:"":"":AAD3B435B51404EEAAD3B435B51404EE:F100FC1DF3A5300A5C265BDC7CD81E39

The hash starting iwth AAD3 and ends with 4EE is just LM hash for blank password and in this case it means that the password is over 14 characters and it cannot be stored as LM hash. The last hash (F100) is the NTLM hash which I would like to see cracked :)

NVidia seem to have done a reasonable job of locking this down appropriately.

I ran cain and abel, and dumped the service accounts password from LSA, it is using a very random looking password comprised of > 15 characters, using upper and lower case alphanumeric and specials like _(!, etc.

Additionally, the account is added to the deny log on locally security policies, so they appear to have thought about security on this.  This is far better than having a service run under system with way more privileges.


Are Java (web-based) applications security threat? We see two types of Java web-based applications:

Simple applications, asking to be allowed (Yes/No) to use the microphone, etc.
Heavy, complete applications, asking to Allow/Block (like online Youtube downloaders, etc.)

Are both of them a serious security threat for users?

Java exploitation: I think the most popular way to exploit systems with almost zero effort is with malicious Java applets. Used in conjunction with social engineering - almost every person instinctively clicks the 'Run applet' dialog. Even if you don't look at attacks involving SE, there are always exploits for the Java Browser Plugin freely available (IIRC, Oracle was phasing out the plugin. Don't remember the current status. Might be worth a look for you.)

tl;dr: Yes. All of these are possible attack vectors, either in combination with SE or through exploitation of unpatched systems or usin private exploits.

Just copied this over from your other Q.


How does DNS / router safety checking work? Tools such as this are used to check whether your router is infected with malware that redirects your traffic via bad guys' DNS servers. How can these tools tell which DNS servers are actually used and whether they are legit or not? Answers to a similar question indicate that the tool makers are maintaining black lists of known bad servers. This doesn't seem feasible to me. Another point which isn't discussed is how exactly the tools know which DNS server made the request. A bad server doesn't necessarily send a direct request to the DNS server which owns the domain. So how does this whole thing work, exactly?

Looking at tcpdump output and debugger output from running the tool, it appears that the page retrieves this URL:

https://dnscheck.sc.fsapi.com/prod/v1/router-checker

and gets a response that looks like this:

{
  "ping_url" : "https://[arbitrary string].names.dnscheck.sc.fsapi.com/prod/v1/result?apikey=[arbitrary string]&output=dns"
}

The arbitrary string in the hostname and the API key seem to change with each request.

... GETting that URL returns output like this:

{
  "asn" : "12008",
  "asn_org" : "NeuStar, Inc.",
  "isp" : "NTT America",
  "org" : "NeuStar",
  "continent_code" : "NA",
  "continent_name" : "North America",
  "country_code" : "US",
  "country_name" : "United States",
  "registered_country_code" :
  "US",
  "registered_country_name" :
  "United States",
  "dns_ip" : "165.254.23.143",
  "known_public_dns" : "Norton ConnectSafe",
  "verdict" : "uncertain"
}

.. so it looks like they've got a server set up to monitor the source of DNS lookups (which is why you get your own custom/random hostname to look up) and then make a report about the entity that made the request.

The example I show here is from Firefox, which is apparently being intercepted by a Norton service I didn't install; if I make the same request from Chrome, it shows data that identifies the request as coming from my upstream net provider.

So, as discussed in your question and the comments to your question, it looks like a smart bad DNS provider could just pass through all of their requests to Google or another upstream DNS provider, and this tool probably wouldn't catch them.


Should I expose HTTP status code 500 on a REST application? In my Spring MVC 3 application, I am following REST patterns and lots of logic is based on HTTP status codes. For instance 500 defines a server error. But OWASP modsecurity says not to expose this status code.

I don't understand why a 500 status code would be bad?
I see even Google showcases 500 properly.

An error 500 indicates that the server had an internal error. It normally means one of two possibilities:

either a component is down - ok, the error will disappear as soon as it is up again
or an exceptional condition is not correctly processed by the application

The occurence of an error 500 should always be followed by an action: if a component was down, it must be repaired or restarted, and if an exceptional condition was not filtered, the application needs a fix.

A problem occurs with applications that do not process exceptional conditions, and are poorly supervised and maintained. If an attacker sees an error 500 that consistently happens in certain requests, it is an indication that the application could not process it, and did not process the error condition either. Maybe a slight variation could make bad things happen...

But simply replacing the 500 code with say a 400 is not a true solution: it only hides the real problem. If I was doing a black box penetration test (with no access to code), I just would not rely on the value of the error code and try all known weaknesses, so hiding an internal 500 with a 400 would not protect the application. And I really believe that serious hackers will think the same...

In a professional world, the 500 errors should be analyzed, and when caused by an non processed exceptional condition, a ticket should be filled to the developper team. For an internal application, an error 500 should mean (explicitely or implicitely) this is an unexpected error, please contact support


Accessing user accounts without asking for their password I don't like asking my (windows network) users for their passwords, it doesn't seem like a good security practice. I also want to train my users to never give their password to anyone if they ask for it. But there are certain things that I just need to do while logged into a person's account. How does everyone handle this situation? Do they inconvenience the users by resetting their password and making them come up with a new one? Or is the practice of asking for users passwords the best way to do this?

Firstly as per @EricG most of the administration should be handled using a network administrator account, using group policies and the like.

If you need access to a users logged-in session the best way to approach this is to have the user login to their machine and then hand you the keyboard. That way you never learn there password, and the user can observe the steps you take. As noted in the comments this can also be done by various remote support, screen and session sharing applications.


Registration Email Hijacking (Please read the update at the end)

I am trying to find out how to send user registration emails securely. I read answers on this question:

I don't intend to send passwords in  emails, but I was considering something similar to this answer (temporary links).

However, I keep asking myself the same question someone asked in comments to that answer:
"So what's stopping the link in the email from being hijacked by a middle-man who uses the link to reset the user's password?"

UPDATE: Sorry, I wrote this in a haste (I need something done "yesterday"). I am basically concerned with email hijacking in general. What actually happens is this:

Someone creates a Tenant (an organization) account. This is standard registration and I am doing it with a temporary link that is sent to the user.
Admin user is created in the first step.
Admin user later creates other accounts. This part is where I am concerned about email hijacking.

I could send a temporary password to the new user. I also considered 'invitation' email, where the new user would get a temporary link where they could insert their password (the link would be deleted after that).

I am not happy with either solution, because I feel like someone could hijack the email and either read the temporary password or use the temporary link to insert their own password before the user does.

I hope this makes my question more clear. If not, please tell me and I'll try to improve it.

I'm going to take this question as to "how do you stop MitMs from intercepting temporary links" whether those links are for email confirmations or to initiate password resets, because email is considered insecure.

Well the answer is around the fact that not all Men-In-The-Middle are created equal.

It might well be the fact that the email in transport is sent unencrypted (although nowadays opportunistic encryption is utilised), however the point in its journey that is most risky for occurances Men-In-The-Middle is usually encrypted.

e.g.

server --> Local SMTP server --> User's SMTP Server --> User

The most likely scenario for a MitM to sit is between the User's SMTP Server and the User. However, these days encryption is more or less universal for this link. For example, if you get your email via Gmail or Outlook (Hotmail), you connect to your provider via HTTPS, meaning that any MitM on the unsecure coffee shop network you retrieve your email from is protected. Same with Outlook connecting to Exchange Online, as the connection is encrypted. Protection here is most critical as all it takes is one rogue user with ARP spoof in order to intercept all traffic.

A MitM placing themselves at other points in the delivery chain is much harder, therefore it is an acceptable risk for most sites to send out temporary, single-use tokens via email.


Openssl NID to IANA value I am trying to parse the signature algorithm off a certificate using Openssl's APIs. Currently I am using the X509_get_signature_info function to get the hash/digest nid and the pkey nid. However, these nids seem to be exclusive to Openssl, whereas I am looking for the IANA value of said signature algorithm. (IANA values of signature algorithms) For example, I am looking for an Openssl api that converts the nid of the hash algorithm md5, which is 4 according to this file, to the iana value of this hash algorithm, which is 1. I would be surprised if this API did not exist, given that Openssl has to transform their nid to the iana value in order to send this hash algorithm over the wire.

Yes, NIDs are OpenSSL only.
The separate encodings and registries for the hash and signature parts of TLS 'SignatureAndHashAlgorithm' only apply to TLS1.2. The IANA page section you link, and the immediately following one, phrase this a bit obscurely as 'prior to 1.3'. However, sigalgs did not exist prior to 1.2, so the only protocol that is prior to 1.3 and not prior to 1.2 is 1.2. TLS 1.3 changes the definition of 'SignatureScheme' to be a single 2-byte value, with most (not all) of the pairs defined in 1.2 preserved, but new values added that do not fit the 'hash byte, signature byte' format. EdDSA is defined for TLS1.2 by RFC8422 with 'hash'=8 to mean no separate hash, and that same first byte 8 is also used in TLS1.3 for RSASSA-PSS which does hash the data as a separable step but also uses the hash in MGF1 so it arguably isn't fully 'separate'.
OpenSSL doesn't need to 'convert' any cert signature to the TLS wire type(s), and doesn't. Rather, for protocols 1.2 and 1.3 it determines whether to use a certificate by comparing the NIDs (or sometimes even more-compressed CERT-array indexes) for each configured/offered/shared sigalg to the potential certificate(s). It does allow configuring the sigalgs to be offered and accepted, and SSL_[CTX_]set1_[client_]sigalgs does accept pairs of NIDs. However, this data is then used only for the protocol; AFAICS there's no supported way of getting it back out.
ObSec: MD5 is broken; don't use it in certificates. Or for almost anything else.


Using a bastion server: how to model an emergency entrance? I have set up a bastion server (A) that acts as the only "hallway" to enter a bunch of other private VPS's (B). That is to say: the private machines only accept SSH-connections from (A) on a non-standard port, which is a hard firewall rule, and only accept these connections from (A) using a specific user and a specific key.

I was wondering which strategy I should use for emergencies where for instance the bastion (A) goes down, gets compromised or in somehow gets useless. It would make my private VPS's (B) inaccessible for ever.

Should I allow for the (B) machines to be accessed through another IP address than the bastion (A) as well? I don't have the infrastructure to allocate whole IP blocks, so permissions based on ranges won't work for me.

Any thoughts?

This is just an expansion of what @schroeder said in the comments.  You can access (A) or any of (B)'s without SSH if you are using a decent provider.

Most VPS services allow a console login.  The console login is not performed through ssh but through a getty (or agetty, mgetty or other variant) process talking to the virtualisation supervisor.

As an example that I often use (and so do most VPS services), the KVM virt-manager has a virsh console command.  Then the VPS provider only needs to pipe input and output of that process into the web/app console.  The

  PasswordAuthentication no

in /etc/ssh/sshd_config is never used by that method since the sshd process is not being touched.

As for the security considerations of this method, they're in your VPS provider court.  Most providers provide a pretty decent set of checks before you can login into the console (linode, digital ocean and AWS are three that I did use the console and I could configure dual factor auth).  That said, this is simply analogous to going into a server room and connecting a physical console to the console port of your machine.


How does Medium know my Google searches? I searched for "Adele's weight loss" today and up popped the article "How to support your fat friends?" in my news feed on Medium. I literally have read nothing about fat people on Medium and it just popped up today.

In Medium's Privacy Policy Effective Date: 31 Dec 2019, Medium tracks quite a bit of information

such as what pages you view (including how much of a given page and for how long)
your use of product features (like Save to Medium, highlights, follows, and applause)

Most importantly the part where you are concerned with. It is possible that you linked Google with Medium!

  When you create your Medium account, and authenticate with a third-party service (like Twitter, Facebook, Apple or Google) we may collect, store, and periodically update information associated with that third-party account

Under Tracking & Cookies,

  Some third-party services that we use to provide the Service, such as Google Analytics, may place their own cookies in your browser.


Is passing sensitive data through the process environment secure? Recently, I have been looking for the possibility to pass sensitive information from one process to another (at process startup time) without passing it through the command line or without using a filesystem entry. This is on Linux but the question applies to other systems, too.

In particular, the password to access a MySQL server shall be passed down from a script to the MySQL client. To do so, you can pass it over the command line (-pPASSWORD), but this is nasty as a simple process listing will then reveal the password to all other users. In this precise case, the MySQL client program is friendly enough to overwrite the command line text, replacing the visible password string by XXX but this is a smelly solution.

I thought about use the process environment instead. The script sets the password in the process environment, the started subprocess can then read it from there. Indeed, the MySQL client allows this and looks for the environment variable MYSQL_PWD. This looks pretty secure and also elegant, as a process environment cannot be consulted by anyone but root and the process owner, at least as far as I know.

However, the MySQL 5.1 manual states:

  This method of specifying your MySQL password [via the environment] must be considered extremely insecure and should not be used. Some versions of ps include an option to display the environment of running processes. On some systems, if you set MYSQL_PWD, your password is exposed to any other user who runs ps. Even on systems without such a version of ps, it is unwise to assume that there are no other methods by which users can examine process environments."

The question then is: Is passing sensitive data through the process environment really insecure? Are there systems that allow consultation of another process' environment with no verification of permissions? Clearly, the superuser can grab the password at will, but then again, he doesn't need it in the first place.

To answer my own question:

It seems that some systems are, or rather were indeed insecure, leaking environment information to other processes.

A similar issue to the present one is raised on github by user 'mitchblank' for the 'mosh' application (mobile shell). The author writes:

  Background: in the process image argv[] and envp[] are stored in the same way, next to each other. In "classic" UNIXes /usr/bin/ps was typically setgid "kmem" (or similar group), which allowed it to dig around in /dev/kmem to read information about the active processes. This included the ability to read the process arguments AND the environment, of all users on the system.

  These days these 'privileged ps hacks' are largely behind us: UNIX systems have all come up with different ways of querying such information (/proc on Linux, etc) I think all(?) of these consider a process's environment only to be readable by its uid. Thus, security-sensitive data like passwords in the environment aren't leaked. However, the old ways aren't 100% dead. Just as an example, here's an example from an AIX 5.2 machine I have access to...."

  ....

  Today, mosh seems to be only on Linux/OSX/FreeBSD but if it catches on I'm afraid it will end up on some platform that still uses the old-school UNIX "everybody can see anybody's environment variables" model.

I have been unable to confirm the existence of any system that permitted the leaking of environment variables (A work for historians and people having access to old installations.)

Looking around shows that in 2000, environment variables were indeed considered sensitive, i.e. potential problems would have been flagged, see CERT vulnerability 22404. Indeed the above-mentioned mentioned AIX 5.2 weakness was a bug (Since fixed. Unfortunately there is no detailed information about this on the Internet as far as I can find apart from this IBM technical bulletin)

CERT and RISKS forum yield nothing about environment variables being implemented in an insecure manner or being exploited at any point in time.

I am not sure whether other programs pass sensitive data around (GPG does not), but the MySQL manual's admonishment seems to be over the top.


OpenVPN username and password authentication only - unsafe? Is it safe to only use username and password (and server certificate) for OpenVPN connection authentication? Are username or password ever transmitted in plaintext to the OpenVPN server? I found a (german) website which claims so:

Original Text:

Achtung: Dieser Schutz ist ohne Verschlüsselung sinnlos, da Username und Passwort unverschlüsselt übertragen werden! Es ist in jedem Fall zu empfehlen, die zusätzliche Authentifizierung nur in Verbindung mit der zertifikatbasierten Authentifizierung und Verschlüsselung zu nutzen

English translation:

Warning: This protection is meaningless without encryption because username and password are transmitted unencrypted! It is recommended in any case to use the additional authentication only in conjunction with the certificate-based authentication and encryption

I used wireshark to prove this is true but I could not find my username nor password in plaintext in any OpenVPN package.

I am using OpenVPN server version 2.3 on a Ubuntu 14.04 host.

The user name and password are encrypted; this is confirmed in the OpenVPN documentation:

  OpenVPN 2.0 and later include a feature that allows the OpenVPN server to securely obtain a username and password from a connecting client, and to use that information as a basis for authenticating the client.


Must a system be insecure against physical access? If so, why? Inspired by: Why don't OSes protect against untrusted USB keyboards?
Related: What can a hacker do when he has physical access to a system? (I address the points of its main answers below.)

There seems to be an old adage "if the bad guy gets physical access, the computer is no longer yours". My question is, is that just hardware manufacturers suck at security, or is there an intrinsic reason that is true. Can you create systems that are secure against physical access?

Now, keeping your data secure is easy: encryption and/or hashing. What I'm talking about is keeping the device secure such that you can still trust it.

Really, it doesn't seem much different then software security. All you have to do is:

Require any hardware add-ons to be approved by the user before being trusted:

Use Privelege Separation. Just like when you download an app, the OS tells you what permissions it needs, you could have a computer tells you what permission the hardware needs. That way if you have a thumb-drive that requires keyboard access, you'll know something is up.
Establish public-private key encryption between the computer and hardware. This would defeat key-loggers and other security threats.
Just like we have certificates for websites, you can have certificates for hardware (keyboards and monitors it particular).
As an extra layer, put all ports in the front, where the user can see them.

Make the system physically durable, so the attacker can't rewire/insert malicious components inside the system.

You can make it also shatter completely or something if it does break, so its obvious something is up. Basically, make it tamper evident.

Glue it/lock it to the ground so the system can't be replaced.

Just as an extra layer, make the computer prove itself to the user's phone, somehow. Perhaps they the user's phone and computer have setup a system that can thwart Man-in-the-Middle attacks (for example, the phone tells the user the password, but signs it with the computers public key).

Is there any other reasons I'm missing, particularly ones that make physical security completely impossible, or do hardware manufacturers just suck at security? (Even if the above aren't completely full proof, they seem like a step in the right direction.)
- To prevent against spy cams, make the monitor VR Goggles, that has an encrypted connection to the computer (again, resistant to man in the middle). (Okay, this is a little fanciful, but so are spy cams.)
- Actually, one way to eliminate a lot of attack vectors is to make the room sound proof and X-Ray proof (if you are worried about that stuff), and then only allow authorized persons in. You run into all the same problems as above, but know its a lot simpler, and its an extra layer.
 - Even just putting a lock on the keyboard can prevent physical key loggers.

I believe my question rules out the answers of Methods for protecting computer systems from physical attacks and What can a hacker do when he has physical access to a system?.

Bonus Question: Are there any systems that are secure against physical access?

The fundamental answer is the market doesn't really want to pay for general purpose computers that are secure against physical attacks.  You propose making tradeoffs, and those tradeoffs involve engineering costs and operational costs which only a small number of buyers care about.

Some computer systems try to make these tradeoffs (for example, the Xbox) because there's a market reason (reducing game piracy).  ATM makers and voting machine makers have generally chosen to put their machines in locked cabinets.

Of course, most ways of mitigating threats are subject to further attacks.  Locks can be picked, glue can be scraped or dissolved, and so an attacker can perhaps modify the system even after all this work is done, which puts additional pressure on the economics.

Another solution is to go for tamper-evidence over tamper-resistance, and that's the approach that credit card terminal makers generally use.  Of course, there, tamper-evidence begs the question of "evident to whom, and how are they trained?"  Tamper evidence is another point along the economic spectrum.


How risky is connecting to a hidden wireless network? According to something I spotted something in a set of directions for connecting to a hidden wireless network from windows 8 found here (located under Step 1 > "Troubleshoot connection problems" > "How do I connect to a hidden wireless network?"):

  A hidden wireless network is a wireless network that isn't broadcasting its network ID (SSID). Typically, wireless networks broadcast their name, and your PC “listens” for the name of the network that it wants to connect to. Because a hidden network doesn’t broadcast, your PC can't find it, so the network has to find your PC. For this to happen, your PC must broadcast both the name of the network it's looking for and its own name. In this situation, other PCs “listening” for networks will know the name of your PC as well as the network you’re connected to, which increases the risk of your PC being attacked. (emphasis added)

I had always believed that hidden wireless networks were actually safer than normal ones, because only those who already know of the network are able to connect to it, so an attacker wouldn't be able to connect to it to listen to your traffic.

Are hidden networks actually more risky, as the paragraph says, and if so, what measures can be taken to help mitigate the risk?

Also, I know that there are some countries where publicly broadcasting home networks are actually illegal, and hidden networks are the only option for wireless.  If broadcasting networks are safer, why are they illegal in some places?

The risk here is in believing that a "hidden SSID" changes anything to the security. A non-hidden SSID means that the router will shout at regular intervals "hello everybody, I am Joe the Router, you may talk to me !". A hidden SSID means that the client machine (not the attacker's machine) will shout at regular intervals "Hey, Joe, where are you ? Please respond !". Either way, assuming that the SSID (here, "Joe") is not known to any attacker would be overly naive.

A point that could be made is that when the SSID is hidden, then an attacker may assume that the SSID is valuable in some way; so, when your PC connects, your PC shows that it knows the valuable SSID, and thus is also a valuable target in some sense. Not that it would change much things in practice: attackers will attack everything in range anyway, as a matter of principle.


How does ransomware get the permissions to encrypt your disk? Recently, my employer blocked access to Gmail, Yahoo Mail, etc., because an employee downloaded an email attachment which contained ransomware and got their disk encrypted.

QUESTION : How does ransomware get the root/admin permissions to encrypt your disk?  Presumably, the person who downloaded it had to have entered the admin/root password at some point.

Ransomware doesn't get root/admin permissions, because it does not need to.

It does not encrypt the disk or files protected by the operating system (executables, configuration, credentials), it encrypts files created and stored by the users (data); and all it requires to do so, is the same level of access as the users themselves.

Just like a user would create a password-protected zip and delete the original file, so does ransomware (except, it keeps the password in secret and makes sure the original file is really inaccessible).

That's the whole reason why ransomware is so successful, it encrypts what is the most valuable for users and companies: their work.


Looking for feedback on my REST-style API authentication design and two-factor authentication Authentication

The authentication is going to be signature-based. The signature will be generated using:

HMAC_SHA256(SHA1(secret_key) + '#' + request_data + '#' + utc_timestamp)

The utc_timestamp will also be included into the X-Timestamp header or into the URL using the _timestamp parameter. The request_data will contain all parameters (URL and POST) and API-related headers. All these data will be lowercased, sorted and joined using = and &.

Generally, the REST API will support three authentication schemas:

API keys based – the signature will include the special secret key associated with the particular API key. Will use the X-API-Key header or the _api_key URL parameter and the X-API-Signature header or the _signature URL parameter.
User credentials based – the signature will use the password as the secret key. Will use the X-API-Signature header or the _signature URL parameter and the staff_name URL parameter.
Session based – the signature will use the user's password or a specially generated code (more details below)... Will use the X-Session-Signature header or the _session_signature URL parameter and the X-Session-ID header or the _session_id URL parameter.

Please note, that the specification allows to use User credentials and Session at the same time (i.e., their headers and parameters do not conflict).

Session

Disclaimer: Yes, I know – sessions are not RESTful, as they are stateful... However, our product requires sessions for some functionality, and in the interests of simplicity we want to maintain one API/protocol – so I am not looking to get into a RESTful debate. I prefer to think, that a session is just a resource, which you need to maintain while working with the API.

The session will be just a resource: /api/v1/session.

So, the standard procedure:

To create a session a client application will need to send a POST request using the staff credentials authentication, which has been described above: POST /api/v1/session&staff_name=s-andy.
The server will reply with 201 Created and will deliver the session id in the response body.
Afterwards the client application will use this session id and the staff password to access API.

Having gotten a request with particular session id the server will update the last access time of the appropriate session resource.

But our users will also have an option to use the two-factor authentication. In the UI after logging in such users will be requested to enter the verification code, which will come to their mobile devices. When designing the authentication I thought that it would be great to have some special 'secret' instead of the user password for the session. Then it dawned upon me – why not using this verification code?

So the flow for two-factor authentication will be:

A client application sends a POST request using the staff credentials.
Server initiates the verification code generation and delivery and returns 202 Accepted with the session id, but the session is not verified yet.
Within 30 seconds the client application sends any request using the session id in the X-Session-ID header or in the_session_id URL parameter and the verification code as the secret for generating the signature.
Having gotten such request the server updates the session making it verified and saves the verification code (a.k.a. one-time password) as the secret key for this session.
Afterwards the client application will use the session id and the verification code (as the secret key) to access API.
When the session times out, and, therefore, gets deleted, or when the user deletes the session (i.e., performs logout), the session id and the "one time password" become unusable.

I wanted to use this community of experts as a sounding board for this two-factor authentication idea; can you see any pitfalls that I cannot?

The problem is that what you call verification code is actually a Two-Factor Token. Tokens are normally short (like 6-7 characters).

So you'll do:

HMAC_SHA256(SHA1(TOKEN) + '#' + request_data + '#' + utc_timestamp)

And token is too short.

I also don't understand what a verified session_id vs an unverified session_id looks like.

The biggest problem is that this authentication scheme seems unnecessarily complex. Complexity and security are mostly opposites.

The way we suggest our customers (www.authy.com) to do two-factor auth is:

User sends a POST request with their credentials.
Server validates credentials. If correct the server generates a 256 bit string and saves it on to the database as well as returns it back to the browser. We'll call this string "otp".
The user is petitioned his two-factor token.
In the POST request of step 3 there will be:

hidden_field otp -> which comes back from the server on step 2
   text-field   two-factor-token -> which the person gets from his mobile app
At this point on your server you verify the two-factor token and the otp. If correct you
create the session and reset the otp so it can't be used again.


ROP resistant gadgetless binaries G-Free: defeating return-oriented programming through gadget-less binaries

This paper describes what seems like a really cool technique to prevent ROP attacks if the source is availible. They use an assembly preprocessor getween gcc and the assembler to remove or protect all possible free branches (returns and indirect jumps). They claim to have <3% (1% average) speed/performance impact.

They modify instructions or add no-ops to change alignment so that unintended/unaligned branch instructions are eliminated. To protect legitimate returns and jumps, they encrypt the return address with a random runtime key in the function prologue and decrypt it by XORing it just before the return. This is supposed to prevent the return satement from executing successfully unless the entry point was at the beginning of the function itself.

My question is how will return address encryption prevent ROP gadgets from being used? The key/cookie is stored on the stack just above the return address, so what is to prevent the attacker from modifying the gadget chain on the stack to also include a key 0x00000000 after each return address?

The paper seems to have got 73 citations and no one has mentioned anything like this as far as I can see so I must be missing something. Can someone throw some light on how the protection code for legitimate jumps and returns work?

(I know that this is a long question requiring the reading of a long paper, but I hope that at the very least whoever reads this finds the paper as cool as I did)

Update

This is apparently the same (or very similar) technique used in StackGuard and ProPolice. Can anybody tell me how they fare against memory disclosure vulnerabilities? I can't seem to figure out for sure. What I do find either mentions them in passing or just trumpets their virtues.

Return address encryption prevents ROP gadgets from being used because the attacker won't be able to predict the value of the key, so the attacker won't know what to write on the stack to cause the return instruction at the end of one gadget to transfer control to the next gadget.

Remember how ROP attacks work.  The attack involves executing a sequence of ROP gadgets.  The attacker has to arrange memory so that these gadgets will be executed in the desired sequence.  In a ROP attack, the attacker does this by overwriting the stack to contain a bunch of fake stack frames, where each stack frame contains whatever stack data will be needed/expected by a single gadget.  Each ROP gadget ends in a RET (return) instruction, so the corresponding fake stack frame contains a saved return address that will be used by the RET instruction: when you execute the gadget, when it gets to the RET instruction, the RET instruction will pop off the "return address" on the stack and jump to it.  So, the attacker arranges the contents of the stack so it has one fake "return address" for each gadget, and the fake "return address" has a value that is the address of the first instruction of the next gadget to execute.

In a standard ROP attack, this works, because the attacker knows the address of each gadget and can write those addresses onto the stack.

With G-Free's return address encryption, this attack no longer works.  The attacker can't store the address of the gadget onto the stack; instead, the attacker needs to store an encrypted return address (namely, the encryption of the address of the next gadget).  Without knowing the encryption key, the attacker won't know what to write.

So, without knowing the encryption key, ROP attacks don't work, because the attacker can't chain the gadgets together.

P.S. I agree with you.  G-Free is indeed awesome.  I wish I had a compiler flag that let me compile a program with G-Free; it is a very cool defense, with modest performance impact.


Is SHA-1 encryption? I have read that SHA-1 is a cryptographic hash function. On an exam, SHA-1 was given as a possible one-way encryption algorithm. Does SHA-1 require a key as input? Is a key required to qualify as "encryption"?

By definition, a hash function is not encryption.

  Encryption is the process of encoding messages (or information) in such a way that eavesdroppers cannot read it, but that authorized parties can.

and

  Hash function is an algorithm that takes an arbitrary block of data and returns a fixed-size bit string, the cryptographic hash
  value, such that any change to the data will (with very high
  probability) change the hash value.

Encryption provides confidentiality while hash functions provide integrity.

Hash functions are used alongside encryption for their integrity capabilities.


When is a private and public key given to a user, and why can the private key not get hacked? Trying to understand assymetric encryption. To my knowledge, it deals with the key management problem by having each user have their own private key and public key. But when is this private and public key pair generated for the user? Does each user have a unique and persistent private and public key?
Also, why are hackers unable to get a private key?

[Sorry in advance for the long explanation, but you've asked good questions about a complex topic.]
Asymmetric encryption uses a keypair consisting of a public and private key; each pair of keys are generated together at the same time.
Asymmetric means "not the same".  In cryptography, we use it to mean "What the public key of a keypair encrypts, only the corresponding private key can decrypt."  The pair of keys are mathematically related to each other, but knowing the public key does not enable anyone to figure out the private key.  You can think of it this way: the public key lets you create a math equation so hard that only the private key can solve it.
Asymmetric cryptographic algorithms allow me to publish my public key, and then anyone can use it to encrypt data.  But only my private key can decrypt the message encrypted with my public key.  And when I say publish a public key, I mean just that -- the encryption is so safe I can literally paint my public key on a billboard if I want.
The public key is only half of my keypair.  What do I do with my private key?  I must keep it secret.  Otherwise, anyone with my private key can read those secret messages meant only for me.
When do I create a keypair?  Obviously I have to create it and "publish" my public key before you can encrypt any data to send to me.
So if I have a keypair, and I publish my public key; and you have a keypair and you publish your public key, we can then each encrypt messages to send to each other.  As long as we keep our private keys safe, nobody knows what we're saying to each other.  Although they can still see me sending messages to you, and they can see you sending messages to me, nobody else can read them.
But immediately a problem springs to mind: if someone publishes a public key and says "This key belongs to SuperDuperStore; please encrypt your credit card and send it to them", how do you know if that public key really belongs to SuperDuperStore, and not EvilHackers?
The primary way that's been solved is through the use of "digital certificates", and this is where it gets more complicated.  A certificate uses another form of asymmetric cryptography known as a digital signature.  The digital signature uses a keypair just like our encryption, but instead the private key is used to create a "signature" of your public key.  The signature is a big number that only the signer's private key can create, but anyone with the signer's public key can verify it.  The signature and the public key are put together in a specially formatted data structure called a certificate.  So if you know you have a copy of the signer's certificate (containing SuperDuperStore's public key), you can use the signer's public key to verify that only the signer could have created the signature.
We call these signers of other people's keys "Trusted Certificate Authorities", or CAs for short.  Their job is to prove to everyone that a public key really belongs to SuperDuperStore by signing those certificates.  They do this by verifying that each request to sign a public key really came from SuperDuperStore, or Sangstar, or John.  Once they verify the request, they digitally sign your certificate request and send you back the signed certificate.
But now it's turned into a chicken-and-egg problem - how do you trust that you have the CA's real public key?  First, we have the CA sign their own public key, creating what is called a self-signed certificate.  It's a secure document, but how do we know it's not just self-signed by EvilHackers?  By only trusting delivery of those self-signed certificates to trustworthy entities.  That copy of Windows, or MacOS, or Firefox, or Chrome, or Android, or iOS, or Linux that you're using right now?  It was shipped to you with over a hundred trusted self-signed certificates pre-installed.  Any self-signed certificate that's not already on the list wasn't signed by a trusted CA, and your browser or computer will reject it, warning you that it is not a legitimate certificate.
Finally, you asked if these keys are persistent, or if they're constantly changed.  The answer is on the signed certificates containing the public keys.  Each certificate has a "Not After" (expiration date) field, and once a certificate is too old, it is no longer trusted by anyone else.  Before that happens you'll want to get a new certificate and publish it; it turns out this is usually a good time to generate a new keypair, too.


Cloud services - A window to outsourcing illegal activities? Recently I was exposed to a number of stories where alleged illegal activities (for this case, we can take brute-force) are outsourced to the cloud, and are run by the cloud providers. The providers, e.g Amazon, can be used for the sole purpose of malicious activity - For instance, renting a strong machine with a big number of processors and letting it run some sort of a brute-force, whether offline (a given file to crack) or over the internet.

A real example: (This site), owned by moxie - Supplies cloud services to crack WPA handshakes, and there is no need here to elaborate on the consequences and meaning of the availability of such service.

The question here is a bit blurred, but still important (in my opinion) - Doesn't it cross the line a bit? Of course some legitimate network administrators might use this service for their own organization and for a legit purpose, but I think there is a big window here for criminal activity.

Services and tools are entirely amoral, i.e. they are neither moral or immoral. We, as people, often place moral value on these tools' intended and actual use. Such reasoning is somewhat fallacious, since we cannot pre-judge the intent of every possible user. Any tool intended for "good" might be subverted for "evil", and vice versa.

A screwdriver can be used to construct a cupboard, but it might also be used to stab someone. A gun can be used to oppress, but it might also be used to protect. These are simplistic examples, but the point is that the tool itself has no moral value. Our actions are what carry moral value.

The cloud is merely a concept, which makes this abstraction all the more meaningless. Whilst the term has been heavily bastardised by salespeople, the real meaning of "cloud computing" is simply placing some computational task into a distributed system. Since the task can be anything, we cannot pre-judge intent, therefore it is amoral. Thus, we should not judge such services by their potential misuse.

Sure, the bad guys can use "the cloud" for bad stuff. It opens up new attack models and improved financial efficiency when performing distributed attacks. But is that not the same for any other technology? Brain-computer interfaces, webcams, smart-phones, tablets, smart-meters (electricity / gas), SCADA, Ajax, Facebook, etc. can all be subverted for immoral means, but it doesn't mean we should stop using them. Cloud computing is no exception. It goes the other way, too - tools like oclHashcat, BeEF, Metasploit, nmap, sqlmap, etc. can be used for "evil", but they're also amazingly useful for penetration testers.

In the end, we need to just accept that these services and tools exist, and that attempting to place moral value on them is an exercise in futility. Focus your efforts on identifying the potential problems and finding solutions.


When a company asks to test physical security, what are some techniques one could use to gain entry? When a company asks to test physical/infrastructure security, what are some techniques one could use to test employees?

This could include good excuses to gain access to some hardware/software.

The art of social engineering is all built around trust, so first you need to plan out how you can gain the trust of the target. This is different in every organisation, so unfortunately no-one can really tell you what you should do, but knowing some war stories may help inspire you. I recommend the book 'The Art Of Deception' by Kevin Mitnick as a brilliant source of war stories.

Some common social engineering tactics I personally like are:

Dropping USB sticks infront of the lobby to try and entice an
employee to use them internally.
Creating fake parking tickets, and sticking them on an employees windows with a URL to 'view further information regarding the offence'.
Just asking - you will be amazed how many times just asking the right person for information will work.

Regarding physical security, again it is difficult to know what will work best without first having information on the target, sometimes it's possible to just walk right up to the rack and start plugging in cables, other times it takes more planning to explain why you need access to a server room.

One thing that you should be doing when planning your physical security test is researching the environment, do you know anyone in the company? Are you likely to be identified by anyone as a penetration tester? Is there a security desk between you and the server room? How many employees work in the building? Are you likely to be spotted should you sit down next to an employee that you have never met? These kinds of questions should be considered before walking into the building.

Lastly, always be confident in what you are doing, there is nothing more of a giveaway than someone who is stumbling over their words when being questioned about what it is they are doing. Remember that you only get 1 shot at this, so being able to think on your feet will be a huge benefit.


How to find all the microphones in a room? "Smart" devices are all around us nowadays and many of them have built-in mics which can be be misused to spy on you in cases when the device is hacked (which is rather probable to happen as there are countless and growing vulnerabilities in all the software and hardware and botnets grow and flourish).

The question is how to find all the mics to take care of them a way or another?

Laptops and phones are the obvious hits. Smart TVs, set-top-boxes and game consoles, different kinds of video cameras etc may contain tiny built-in mics with (if that is a visibly advertised feature) or without you knowing.

Is there a way to find them all? E.g. by detecting magnets or something...

This is very broad without a context. If you simply define a microphone as a device able to record sounds, it will be very hard, because microphones can use various technologies, and you will only be able to protect you from technologies.

microphones sending in real-time what they hear: the common attack against them will be a wave scanner to detect their emission - that will be the easier part
common microphones with local storage. Depending on the technology used, you could try to detect the magnetic fields generated by the electronic machinery, but they can be low and hard to isolate from the ambient noises generated for example by modern lamps, not speaking of other electronic devices: do not hope to detect them at a large distance
laser microphones: glass windows can be used as a passive microphone with a device analyzing its vibrations through a laser. It is easy to detect a glass window, much harder to detect whether it is actively spyed
you could even build a purely machanical microphone by copying the disks ancestors: a horn to capt the sound, a needle attached to its top writing on a wax disk moved by a spring. Ok, it will be much bigger than an electronic device could be, but you would not detect it by the same tools...