I was tricked on Facebook into downloading an obfuscated script I got a notification on Facebook: "(a friend of mine) mentioned you in a comment". However, when I clicked it, Firefox tried to download the following file:

comment_24016875.jse

This is an obfuscated script which seems to download an executable (autoit.exe) and run it.

This is the part I managed to deobfuscate:

['Msxml2.XMLhttp', 'onreadystatechange', 'readyState', 'status', 'ADODB.Stream', 'open',
 'type', 'write', 'position', 'read', 'saveToFile', 'close', 'GET', 'send',
 'Scripting.FileSystemObject', 'WScript.Shell', 'Shell.Application', '%APPDATA%\\',
 'ExpandEnvironmentStrings', 'Mozila', 'https://www.google.com',
 'http://userexperiencestatics.net/ext/Autoit.jpg',   '\\autoit.exe',
 'http://userexperiencestatics.net/ext/bg.jpg',       '\\bg.js',
 'http://userexperiencestatics.net/ext/ekl.jpg',      '\\ekl.au3',
 'http://userexperiencestatics.net/ext/ff.jpg',       '\\ff.zip',
 'http://userexperiencestatics.net/ext/force.jpg',    '\\force.au3',
 'http://userexperiencestatics.net/ext/sabit.jpg',    '\\sabit.au3',
 'http://userexperiencestatics.net/ext/manifest.jpg', '\\manifest.json',
 'http://userexperiencestatics.net/ext/run.jpg',      '\\run.bat',
 'http://userexperiencestatics.net/ext/up.jpg',       '\\up.au3',
 'http://whos.amung.us/pingjs/?k=pingjse346',         '\\ping.js',
 'http://whos.amung.us/pingjs/?k=pingjse3462',        '\\ping2.js', '']

Is this an exploit on Facebook? Is it possible that my friend got a virus which targets their contacts by tagging them on malicious links? Should I report this to Facebook? If so, how?

This is a typical obfuscated JavaScript malware which targets the Windows Script Host to download the rest of the payload. In this case, it downloads what appears to be mainly a Chrome Extension (manifest.json and bg.js), the autoit Windows executable, and some autoit scripts which install them. All of these files are named with .jpg extensions on the (likely-compromised) server they are hosted, to be less-conspicuous.

The malware appears to be partially incomplete or otherwise underdeveloped or perhaps based off some other malware (quality is very low). Many of the autoit scripts don't actually do anything, and what appears to be a ZIP meant to contain a Firefox extension is actually empty. The autoit scripts are a ton of includes combined into a single file, but only one (ekl) actually has a payload at the end.

The one active autoit script which runs on infection replaces the Chrome, IE, and possibly other browser shortcuts with a shortcut to Chrome with the necessary arguments to run the malicious Chrome extension.

The Chrome extension is mainly how this malware is being propagated. It does some nasty things like blacklisting antivirus software domains, and sending Facebook messages automatically. Actually there was a webservice back end at http://appcdn.co/datajs serving some scripts which would be injected on any page a user visited based on the URL currently being viewed, which was how the Facebook messages were being posted. This service is now offline, likely taken down.

  Is this an exploit on Facebook?

Not exactly, more-like abuse of Facebook. Facebook's code hasn't been exploited, your friend just has an infected browser phishing their contacts on their behalf.

  Is it possible that my friend got a virus which targets their contacts by tagging them on malicious links?

Yep, that's exactly how this malware is spreading itself.

  Should I report this to Facebook? If so, how?

Yes, see How to Report Things in the Facebook help center.

Getting the following URL's taken offline by contacting their hosts would also be good.

http://userexperiencestatics.net/ext/Autoit.jpg
http://userexperiencestatics.net/ext/bg.jpg
http://userexperiencestatics.net/ext/ekl.jpg
http://userexperiencestatics.net/ext/ff.jpg
http://userexperiencestatics.net/ext/force.jpg
http://userexperiencestatics.net/ext/sabit.jpg
http://userexperiencestatics.net/ext/manifest.jpg
http://userexperiencestatics.net/ext/run.jpg
http://userexperiencestatics.net/ext/up.jpg
http://whos.amung.us/pingjs/?k=pingjse346
http://whos.amung.us/pingjs/?k=pingjse3462
http://appcdn.co/datajs

Unfortunately, CloudFlare still has not taken the userexperiencestatics.net URL's down though I contacted then shortly after posting this answer, and I don't know who is actually hosting these files. CloudFlare just emailed me to say they restricted access to the files, and says they will notify the host.

UPDATE:

After I and likely others reported the .jse URL to Google, they appear to have taken down the file. If you find any more copies, those should also be reported. It seems people have been receiving the files from numerous sources.

MORE INFO:

This malware and post is getting a lot of attention, so I'll add some more info to address people's questions:

  Will this file automatically run when downloaded?

Probably not unless you have configured your browser to do so. It is meant to trick you into opening it.

  Can it infect my phone, or non-Windows computer.

As far as I know, Windows is the only OS which can run this malware. As I mentioned, it uses the Windows Script Host. I don't believe even Windows phone is vulnerable, though I don't know much about Windows phone.

UPDATE ON RANSOMWARE:

Previously it was assumed the autoit scripts contained ransomware, however after further inspection this appears not to be the case. There is just a bunch of unused crypto function obscuring the actual payload, which I've mostly deobfuscated to this.

UPDATE ON CHROME EXTENSION:

The unpacked Chrome extension code can be viewed here. Details on what it did integrated above.

UPDATE FOR JSE SCRIPT:

My de-obfuscated comment_24016875.jse script can be viewed here.


Received an unsolicited two-factor security code on my phone: bad? As above, I received a code (twice!) on my phone for a security code for PayPal with no further text than the number. Should I be worried someone has successfully obtained my password and accidentally alerted me to their success, or is it more likely someone mistyped their number is mine? Are there other signs I would see if my password had been stolen somehow?

Yes, this is probably a bad sign.

First of all, though: This might simply be a phishing mail that hopes you click some link in the mail that says "report a problem with this email to Paypal", but takes you to a different website than the real paypal site and lets you enter your credentials there. So, the worst thing you can do is click on any link from this mail. You could check for the links' actual target – if they're not on servers that are unambiguously paypal.com, then you can be pretty certain this is nothing but an attempt to phish.

Go to https://paypal.com (maybe using another machine than the one you're normally using to enter your Paypal credentials, since you've got reason to assume it has been compromised), check the certificate of that website your getting looks correct, and find a contact phone number to call. Change your Paypal password from a machine you can reasonably well assume is free of malware that might try to steal your credentials.


How are whatsapp calls banned even with VPN in countries like UAE As you may know, some countries are blocking access to whatsapp calls, but users usually overcome that with a VPN service, but today even with that powerful internet anonymity solution, ISPs and telecom operators are blocking whatsapp calls even when using VPN on your phone. The question is, how are ISPs able to detect that traffic, as it's encrypted, and ban such voip services. Any technical details would be great, I actually suspect that, it's not just the ISPs whos blocking it, whatsapp it self is doing it too.

Whatsapp uses specific ports including: 5223, 5228, 4244, 5242, 5222. By monitoring packets to these ports, it is very easy for a packet filter to figure out which clients are trying to conduct a Whatsapp session. The problem is made easier because Whatsapp uses TCP, a sequential protocol. Using this protocol makes it even easier to target and interrupt.

If you are using a VPN and the server is outside of the country, then there is no way to block you, other than cutting off the entire connection to the VPN. As of this summer, the government of the United Arab Emirates decided to make VPNs illegal and is now blocking them wholesale. They do this by maintaining lists of known VPN endpoints and then blacklisting them all.

You can evade this restriction by making a custom tunnel out of the country. Be aware that doing so is a felony in the UAE.


How secure is telephone banking? The fallback for my online banking login at multiple banks is telephone banking. On the phone I can make payments, but I can also reset passwords, and several other critical security functions. Usually they authenticate me by asking relatively trivial questions, along the lines of security questions. Security questions aren't good security practice for website logins, so it seems strange that they are considered secure enough for telephone banking.

Apart from weak authentication, as far as I know, telephone calls are not encrypted. Beyond eavesdropping (which I guess is like shoulder-surfing), I imagine that it is possible for someone to tap into the call (passive MITM) and record the answers to my security questions or my PIN. Recently, I've noticed that I've been passed to an automated authentication service, but otherwise there is necessarily a MITM as the bank employee has to verify my answers/PIN manually. Not only does this mean divulging sensitive information to the employee, it implies that the data might be stored unencrypted.

So, my first question would be whether my understanding is correct, that telephone banking is less secure than online banking? If so, then why is it still so widely used, and even used as a fallback to online banking?

This is a great question.

The TLDR is; Yes, Call Centers are generally less secure than online payments. The reason for this is because of the inherent human factor in a call center - e.g. saving payment card details into notepad to process later because the payment service is down (seriously!!!).

But, there are a couple of things to address here, 1. Payment security and 2. Call security.

To start with 2. Calls are encrypted both on their way to the bank from your Telco's PBX, and again once they hit the banks DMZ, with a thing called an SBC (Session Border Controller). This has been standard since the proliferation of VoIP tech in the enterprise environment. That said, the quality of said encryption isn't great (Base64??) and relies on an assumption that both your telco and the banks telephony team are applying patches to their kit, and upgrading it when needed.

On 1, the payments / banking industry has been at the forefront of understanding the importance of getting this sh*t right for a long time because it is such a huge risk for them.

The standard for secure payments processes / infrastructure / architecture is called PCI DSS. PCI DSS was developed specifically to provide consumers like us better security when making payments. All call centers including banks, must adhere to its standards. This also applies for any other payment "endpoint" such as in store or online payments.

There are different levels of PCI compliance based on how many payments you are processing each year. Even the lowest requires 4 random audits to be conducted each year for an organisation to retain their compliance certificate.

In fact PCI DSS is almost an industry of its own these days, with companies building infrastructure and payment services to take organisations payment services "out of scope" of PCI DSS by owning all the risk.

To answer your question specifically, some of the key things outlined by PCI DSS are:

Never storing card data in plain text at rest - Tokenisation is used to overcome this.
Never storing card verification ID's like CVV or Pin - Never ever
Using the principle of least privilege

For access to network services
For access to payment GUI's (call center agents)
For access to call recordings for QA purposes

Ensuring transmission of cardholder data across public networks is encrypted - With standards like SSL / TLS
DTMF Masking - so that if you do punch in your card number from your keypad, all the beeps are monotone

I don't have enough rep to post more than 2 links, but for a better overview of what's required for telephone based payments, check out this blog post.

So, banks and call centers may store some of your payment card information at rest, as long as it is tokenised, and stored in a walled off PCI compliant network. Further, you will have basic encryption provided at the call being made, and again inside the banks telephony network, plus DTMF masking during any keypad payments.

In summary, with these standards and practices, you are more secure from a technology perspective when paying with an automated service than when you are talking to a human!

Sorry for the long post! :)


Trace source and destination of an SMS message Is it possible to trace the source or destination (location, even coordinates) of an SMS message ?
If it is, is it possible to do it even if the phone is roaming in a different country ?

There is no location transmitted within a normal SMS message (unless added by the author) so as the recipient of an SMS you won't normally be able to determine the location of the sender.

The location of a cell phone can be determined with varying precision by the Mobile Network Operator and any third parties with access to the MNO's system or data.  The location precision depends on the capabilities of the device, the cell tower(s) it connects to and the quality of the signal.

A determined and well equipped attacker may able to determine the location of cell phone independently of the MNO (by sniffing local cell traffic, using a fake cell tower or side channel attack such as observing the wifi or bluetooth connections of the device, implanting malware on the device etc) and pair this with the timestamp of the message.  (It may also be possible for an attacker to read the mssages, since the A5 stream cipher used to encrypt the message between phone and base station has been shown to be vulnerable).

One other thing to consider is that there are many different ways of sending an SMS and normal mobile phones are only one of these.  For example, MNOs and a very large number of third parties will forward SMS messages which originated from email or web based gateways. In many countries fixed line telephones can send SMS if configured correctly.

The location of the sending device may not correspond the location of actual person either. Many devices can be configured to send SMS without having any operator physically present (uses for that include alarm systems, vehicle trackers etc).


Attack vectors when running untrusted docker images What are the possible attack vectors if I am running user-submitted docker image, e.g. pull via docker pull FOO; ... docker run FOO where FOO is a user-submitted string containing the name of a Docker Hub repository?

This is not a question about simply running untrusted code inside docker containers. I actually already understand the security implications of that well enough for now. What are the additional attack vectors relevant to running untrusted images?

There's various ways that a rogue container might be able to damage the host or other containers on the network, depending on the configuration of the docker daemon.

By default all containers share the same network.  As such a rogue container can attempt to attacker other containers.  This could include attacks like ARP poisoning depending on the rights provided to the container.
On the network front, a rogue container has a potentially privileged position in your environment and could try to attack other systems on connected networks.
A rogue container can attempt to escalate privileges to compromise the host operating system.  This is generally achieved by attempting to exploit kernel vulnerabilities in the host kernel.  An important point about container isolation is that all running containers share the same kernel.
On that note, if the kernel exposes any sensitive information to the containers (e.g. information from the /proc filesystem) it might be possible for the rogue container to get access to that.
If the container is executed with certain configurations, e.g. --privileged or mapping the docker socket into the container, it becomes trivial for the rogue container to take over the host.

I'd recommend reading the CIS Security benchmark for docker to get some more information and suggestions for hardening your installation, if you're interested.


Is it possible to create an executable file by hashing a different file? Theoretically, is it possible to hash an executable file and have the output hash end up being another executable file?

I know the chances of this are unimaginably small, but I'm curious.

Well... rather than worry about the statistics, which as you mentioned is unimaginably small. Let’s take another angle.

Depending on the hash function, the output is usually 256-512 bits long, but according to this the smallest possible exec in Windows is 97 Bytes — which is 776 bits.

Hence if you’re using Sha256 or Sha512, I Guess the answer is definitely no, as there’s just not enough bits in the output to make the file.

Different hash functions that can output hashes that are at least 776 bits Long are the only ones that are possible to ever be able to make an exe by hashing another exe.

Nice theoretical question — but again, very very very Low probability.


How secure is an Activation Email? Is there any risk to an Activation Email?

My ASP.NET Site is set up so that a user has to check their Email and click an activation link which is made of a GUID created as their user ID in the SQL Membership Tables.

There is a third party application that holds an Email, a not so secret 4 digit ID Number for each potential user, so the user must use this Email and ID together in order to register an account, the account is not "approved" until they activate their account using the link in the Email sent to this Email. only employees can set the Email and ID in the third party application.

This site handles signing up for an Email Subscription of semi-privileged information, this site doesn't actually handle the emailing of the semi-privileged information.

Other than Social Engineering, what is the risk associated with this set up for user registration?

Using only their username to generate the GUID is not sufficient, how about adding a time stamp to it?

There should be a time limit to which the user has to click the link. The link should also expire upon account activation, especially if they are required to set a password upon account activation.

What if I am able to obtain the activation link, is the four digit code protected by some sort of rate limiting? This in order to prevent the 10000 requests to guess the four digit ID.


Do schools save your search history on their computers they issue out? So I received a laptop from the school and I was wondering if your logged into your own home network but signed into the computer (not in like a google account but like when your first turn on the computer you got to enter the username and password however the login for the computer is universal meaning to say it’s the same log in for all the students) if they could still receive the search history on the computer even if you were on a home network but logged into the computer with the universal login without physically having the computer in their possession and if so is it stored somewhere so they can go back and look at it? If you know the answer please let me know covid has gotten me going a little bit nuts

Is it technically possible? Yes, of course. Is it legal? Probably, but depends on jurisdiction and exact scenario. Are they actually doing it? There is no reasonable way to know for sure unless they tell you.


How fast can SHA-1 be brute forced when used with a secret? In my code I calculate hashes for known codes and a secret with SHA-1:

SHA-1(code + secret) = hash

A attacker can do statistical analysis on the database and for example guess that the code 03220 produces a specific output.

SHA-1(03220 + secret) = f24647f6573032838969db0934c63f6aa99c6173

The secret is 120 Bit long and for example Wqj5ASoan1iCjnjLeO6fL.

My question is how long it would take for an attacker to brute force the secret, when he knows the used code and output of the hash? Is it secure?

It is possible to brute-force with 7 Giga SHA1 per second on a good system. When we assume that your "secret" is indeed randomly generated (as it looks like) and is 120 bits long, we can guess the necessary time to find a match:

  possibleCombinations = 2 ^ bitsOfPassword
  expectedTimeInSeconds = (possibleCombinations / triesPerSecond) / 2

This makes about 3E18 years, so brute-forcing is clearly out of question. As mentioned, this only applies for really random "secrets". If only the SHA1 hashes are stored in the database, there should be no way to guess the "key".

I wonder what your intention is although, there are better ways to combine a key with a token (HMAC), or is it used in the context of password storage?


Does FIDO2 token works as two-factor on password-less authentication? As authentication factors, I know the following

You are (e.g. Biometrics)
You have (e.g. USB)
You know (e.g. Password)

If I use a FIDO2 certified fingerprint reader for password-less authentication with user verification required option, can I call it "Two-factor authentication by You Are, and You Have"?

FIDO2 device has Biometric information inside. If the server has no biometric information for authentication, can I call it Biometric authentication?

Fido2 can be single factor or multi-factor. From WebAuthn (a component of FIDO) Wikipedia page:

"A FIDO2 authenticator may be used in either single-factor mode or multi-factor mode. In single-factor mode, the authenticator is activated by a test of user presence (TUP), which usually consists of a simple button push. In multi-factor mode, the authenticator is activated by either a PIN (something you know) or a biometric (something you are)."

The reason is that Fido2 works by sending a challenge from the server to the client, and the client authenticates by signing that challenge and sending to the server.

Fido2 certified devices require the key to be protected at hardware level. So when a particular key signs the challenge, it proves that it comes from user's device.

A PIN or biometric then acts as the second factor used in authentication.

Both combined make it multi-factor authentication.


help understanding client certificate verification I am creating an API that only certain computers should have access to.  Communication will be via SSL between the server and the clients.  In order to verify that a client has access, I would like to create a certificate for each client, that is signed by the server.  Any clients that do not provide the certificate that is signed by the server, should be denied access.

I have an SSL certificate and key from GoDaddy.  I thought I should be able to create client certificates using this information, but everywhere I look, it seems like I need the CA certificate (from GoDaddy) to sign the client certificate and not my specific server's certificate/key.

This doesn't make sense to me, because it seems strange that I should have to go to GoDaddy and get a new certificate for every client.  I imagine that this isn't the case and that I am either doing something wrong, or don't understand completely.

So - How can I create a client certificate that is signed by my server certificate/password?

If your could provide commands (I am using openssl) to generate the client certificate from my server certificate, it would be greatly appreciated too.

Thanks!

In order to sign client certificates, you will need a CA certificate you control. Paying for one is out of the question in most cases, as global-trusted CA certificates are a security hazard for the rest of the Internet. So in these cases you have to make your own CA and create your own server and client certificates.

So let's start with a basic openssl.conf file that we will use for generation of all these certificates:

[ ca ]
default_ca  = CA_default                # The default ca section

[ CA_default ]
certs          = certs                  # Where the issued certs are kept
crl_dir        = crl                    # Where the issued crl are kept
database       = database.txt           # database index file.
new_certs_dir  = certs                  # default place for new certs.
certificate    = cacert.pem             # The CA certificate
serial         = serial.txt             # The current serial number
crl            = crl.pem                # The current CRL
private_key    = private\cakey.pem      # The private key
RANDFILE       = private\private.rnd    # private random number file

x509_extensions  = v3_usr               # The extentions to add to the cert
default_days     = 365
default_crl_days = 30                   # how long before next CRL
default_md       = sha256               # which md to use.
preserve         = no                   # keep passed DN ordering
policy           = policy_match
email_in_dn      =

[ policy_match ]
commonName      = supplied

[ req ]
default_bits        = 2048
default_keyfile     = privkey.pem
distinguished_name  = req_distinguished_name
x509_extensions     = v3_ca

[ v3_ca ]
basicConstraints     = CA:TRUE
subjectKeyIdentifier = hash

[ v3_usr ]
basicConstraints     = CA:FALSE
subjectKeyIdentifier = hash

[ server ]
basicConstraints       = CA:FALSE
nsCertType             = server
nsComment              = "Server Certificate"
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer:always
extendedKeyUsage       = serverAuth
keyUsage               = digitalSignature, keyEncipherment

[ client ]
basicConstraints       = CA:FALSE
nsCertType             = client
nsComment              = "Client Certificate"
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid,issuer:always
extendedKeyUsage       = clientAuth
keyUsage               = digitalSignature

[ req_distinguished_name ]

This config file is made for automatic generation of certificates from a batch script. If you need more control or naming options, you need to adapt it to your situation.

So for generating a CA, go to the directory where you want to make your CA, put openssl.conf there and:

PASSWORD="PUT_YOUR_CA_PASSWORD_HERE"

# Make the config CA specific
cat openssl.conf > use.conf
echo "CN=PUT_CA_NAME_HERE" >> use.conf

# Create the necessary files
mkdir keys requests certs
touch database.txt
echo 01 > serial.txt

# Generate your CA key (Use appropriate bit size here for your situation)
openssl genrsa -aes256 -out keys/ca.key -passout pass:$PASSWORD 2048

# Generate your CA req
openssl req -config use.conf -new -key keys/ca.key -out requests/ca.req -passin pass:$PASSWORD

# Make your self-signed CA certificate
openssl ca  -config use.conf -selfsign -keyfile keys/ca.key -out certs/ca.crt -in requests/ca.req -extensions v3_ca -passin pass:$PASSWORD -batch

# Cleanup
rm requests/ca.req use.conf

Now to generate a server certificate (e.g. for your web server):

PASSWORD="PUT_YOUR_CA_PASSWORD_HERE"
NAME="PUT_THE_NAME_OF_SERVER_TO_GENERATE_HERE"

# Make the config Server specific
cat openssl.conf > use.conf
echo "CN=$NAME" >> use.conf

openssl req -new -nodes -extensions server -out "requests/$NAME.req" -keyout "$NAME.key" -config use.conf -passin pass:$PASSWORD )
openssl ca -batch -extensions server -keyfile keys/ca.key -cert certs/ca.crt -config use.conf -out "certs/$NAME.crt" -passin pass:$PASSWORD -infiles "requests/$NAME.req"

# Cleanup
rm "requests/$NAME.req" use.conf

Now to generate a client certificate:

PASSWORD="PUT_YOUR_CA_PASSWORD_HERE"
NAME="PUT_THE_NAME_OF_CLIENT_TO_GENERATE_HERE"

# Make the config Client specific
cat openssl.conf > use.conf
echo "CN=$NAME" >> use.conf

openssl req -new -nodes -extensions client -out "requests/$NAME.req" -keyout "$NAME.key" -config use.conf -passin pass:$PASSWORD )
openssl ca -batch -extensions client -keyfile keys/ca.key -cert certs/ca.crt -config use.conf -out "certs/$NAME.crt" -passin pass:$PASSWORD -infiles "requests/$NAME.req"

# Cleanup
rm "requests/$NAME.req" use.conf

The only difference between generating keys and certificates for clients and servers it to prevent that a stolen client certificate can also be used to play a server and 'fool' other clients to connect to it (this only works as long as your applications support the client and server extension in certificates).


emails were send from my own email address A friend of mine has just received an email from my exactly own email adrress. What could this be and how do I stop it?

Your email provider either has a relay open on an SMTP server or they don't use SPF or DKIM records to prevent mail from being sent as domains that use their domain name.

Another possibility is that the e-mail is not from your address but the display name of the sender has been set to your e-mail address. (FROM: "you@yourdomain.com"<fake@anotherdomain.com>) This is more often the case and can create confusion for email recipients.

My advice would be to first determine if the email actually came from your email address or if it came from a fake email address using your real email address as a display name.

If the e-mail actually came from your address, look through the headers of the email your friend received to determine where it came from. You can also use the headers to check for DKIM and use online tools like DMARC Analyzer to check to see if your email provider's domain has an SPF record. If your provider does use DKIM and/or SPF and the e-mail did come from your address, then you may want to contact your provider to see if there are any issues with third-party mass-mailing vendors who have permission to send as your email address's domain.


How to scan Javascript for malicious code? We're planning to give the possibility to write community-driven extensions in javascript for our public webapp and let people to customize their instances of the application. The problem is to monitor the quality of extensions.

What would you suggest to automate this process?

Or how to scan Javascript for malicious code?

In a few words we would like to have some service like antivirus that would scan in a real time uploaded extensions for being malicious. And if it detects any suspected code it would generate an alert.

Any hint/advice is welcome! Thank you.

One approach would be to define a safe API for the extensions to use, by declaring objects implementing that API in the scope of execution for the extension. Then require the extension code to be written in a sandboxed version of Javascript, so the extension code can invoke only the safe API methods you defined and nothing more.

So, if your API consisted of an object stored in a variable api, then the code:

var x = api.frob();
x.bar();

would be allowed extension code, because api is part of your safe API, and the safe Javascript variants allow you to invoke the API that is exposed to extension code.

However, the code:

document.createElement("img");

would not be allowed, because document is not part of your safe API.

In designing the API, make sure that no exposed object has properties that could be used maliciously. To give limited access to a resource, use closures to make functions that privately reference the resource.

There are a number of projects out there that have defined a sandboxed version of Javascript you could use for this purpose: SES, Caja, ADsafe, FBJS, and others.  SES and Caja let developers write code with the fewest restrictions: it feels a lot like just writing Javascript, with a few minor restrictions (e.g., no eval, no with).  ADsafe and FBJS require the developer to learn a variant of Javascript.  SES, ADsafe, and FBJS have the best performance.  SES requires support from a very recent Javascript engine, and thus is not compatible with some older web browsers.  If the extension code will be executed on the server side, then SES may be the best bet, because you can ensure your Javascript engine is up-to-date.  If the extension is going to be executed on the user's browser, you might consider Caja if the extension is not performance-critical, or ADsafe/FBJS if it is.


New Hires get phishing emails very quickly - Reasoning and how to stop We hired a new Sales Ops member 1 week ago. Within a week he's getting emails similar to the below:

I did some research on the sender and it is a valid email, valid person, SPF/DKIM checks come through fine.   I reached out to my CEO to check to see if he knew the sender.

I know I can stop this by rejecting messages spoofing an employee, the problem is I'd be rejecting their personal emails due to the name part. Is there a way in Office 365 to detect these and stop them more  intelligently?
What are the ways some of these scammers get this data so easily so that they can send emails like this? They're always hitting my sales teams and not my operations or tech team. My team is running BitDefender with the latest updates, and running behind some strong firewalls and gateways that also scan incoming and outgoing data.

Presumably, your MX record is suffering from a directory harvest attack (DHA). There are lots of ways to do this and unless you're very savvy at pouring through your mail logs, most of them are (by design) hard to detect.
The simplest form of DHA involves SMTP vrfy and expn commands. You can block these entirely. More sophisticated attacks can involve composing emails and then never completing them (the trailing . marking the end of a data command, or even just rset or quit or dropping the connection before issuing a data command).
If you're using o365 exclusively, harvesting from the MX is less likely a concern (I assume Microsoft is savvy enough to block most DHA attempts, though they may not provide enough forensic data to determine if a DHA was attempted or how successful it was before it was cut off). Perhaps attackers have found another source of this data, like a list of your users or a compromised user system or account that attackers can access to read mail or the address book.
If your usernames are predictable, e.g. Firstname.Lastname@company.tld, an attacker can determine users by scraping a company employee listing or a site like LinkedIn. Another source of addresses is public mailing list archives.
One thing you can do is to set up a spam trap (aka a honeypot). Just make a new account for a fictional user and never tell anybody. Wait for a while to see if it starts getting mail and you'll know there was a DHA. If you don't get any bites, then your trap wasn't listed in the place(s) attackers harvest. Try to come up with what those might be and spin up new dedicated addresses (or, if you have to pay per account, add new seeding techniques to the single trap account one by one, with a few weeks between each addition so you can identify it).


How does a weakness in a random number generator lead to a compromise of the entire cryptographic process? In the news, there are several articles (here, here, and the technical point of view) which have to do with a weakness in a random number generator.

The question is somewhat twofold. What symptoms do weak RNGs exhibit? Does this mean, for instance, that several different seeds give the same result? Or am I missing what they mean by "weak"?

And, How does one go from figuring out there's a weak RNG to completely deciphering the encrypted traffic?

When you generate a private key, you do so with a source of randomness. If that source of randomness can output N different streams of bits, then, at most, you may get N different private key. This is where we like to talk of entropy, which is a measure of how big that N is. When the source of randomness is said to offer "100 bits of entropy", then it means that (roughly) N = 2100.

The attacker will want to obtain your private key. If he knows that you use a weak source with a low N (say, only 40 bits of entropy), then he can, on his own machine, enumerate all possible outputs from the random source and work out the corresponding private key.

For instance, suppose that you used a PRNG seeded with the current time, expressed in microseconds. This is the time as known by your machine. The attacker assumes that your machine is reasonably well set with the current time, say within 10 seconds. So, from the point of view of the attacker, the seed for your PRNG is known within a 10 seconds range; since the PRNG use the time in microseconds, that leaves him with N = 10000000 possible seeds. The attacker then says to himself: "IF that guy used as seed value x, THEN his code produced private key value Kx; let's see if that matches his public key... nope. So he did not use x. Let's try again with x+1 (and so on)."

So a weak PRNG is deadly in such situations.

How can you detect a weak PRNG ? Well, most of the time, you cannot. A very poor PRNG may look poor from start; for instance, if you generate two private keys and get twice the same, then there is probably something wrong... but, as the "time as seed" example shows, this is not always easy to detect: time flows continuously, so you never reuse a seed. And yet this is weak. Because weakness comes from how hard it is to guess the internal state of the random source, which is not the same as being statistically biased.

A big statistical bias is detectable and is an obvious weakness; but a PRNG can be weak without being detectable as such.

If you are a bad guy and want to make an undetectable weak PRNG, then you can take a good block cipher (say, the AES), choose some key value K, and encrypt the successive values of a counter, starting at 0. This will produce a very long stream of pseudorandom bytes which nobody will be able to prove non-random, precisely because AES is good at encrypting things. But you, as the bad guy, know K, so you can easily predict the whole stream yourself.

The only reliable way to detect a weak PRNG is to inspect the exact method by which the PRNG works, down to the low details: what physical events it gather, why can these events be considered "random", how they are mixed together with cryptographic algorithms to produce pseudorandom bytes. You cannot do that with an opaque hardware RNG, hence the current crop of rumours.


Can Tamper Data (the plugin) modify multipart requests? I'm doing some testing on my web app with Tamper Data. I've had success with Tamper Data in the past for normal HTTP post requests, but in this particular case I want to modify a post request that that has the content-type set to multipart/form-encoding.

Tamper Data shows this request as one big blog of messy escaped-ness and the text field is too small to view the entire thing or reasonably edit it. I also tried copying/pasting to a text editor, making changes, then copying/pasting back but I must not be doing something right because the web app isn't acting like it's received any form data.

Is there a setting I'm missing to have tamper data modify multipart requests like this in an easier manner? If not, any tips for doing it by hand? Thanks.

According to my experience it works fine (copy/paste and modify and CP again). However i have change only the name of the field to test a path manipulation. And it was a success.
You might have issue with your webapp.


Is it more secure to depend on a smaller set of cryptographic primitives? Just to be clear, there's two measures of security as I understand it:

Provable security in the classical sense involves reducing to a hard problem. The security is asymptotic, so a large enough security parameter gives security.

The other is concrete security, where we can say something has n bits security, meaning it takes around 2^n time to break on average. The upper bound decreases as better attacks are found, and a lower bound may be proven, though most crypto doesn't have a proven lower bound and relies on the "nobody's broken it for x years so it's probably secure" heuristic.

A cryptosystem will need multiple algorithms, which have some underlying cryptographic primitives. Is it better to rely on more of these cryptographic primitives or less? On one extreme, all algorithms use different cryptographic primitives. On the other, the entire cryptosystem may use just one cryptographic primitive. If a break anywhere implied a break on the cryptosystem, I'd think that less is better since there are less ways to attack it. Having less also means that an attack is more powerful since it can break more parts, so maybe it's not such a good idea. Which is more secure?

Just to illustrate, here's an example I came up with for some cryptosystem:

| Purpose                  | A (more)                    | B (less)              |
|--------------------------|-----------------------------|-----------------------|
| Authenticated encryption | AES-GCM                     | Keyak                 |
| Hash                     | SHA256                      | SHA3-256              |
| Key agreement            | DHE                         | ECDHE                 |
| Signature                | DSA                         | ECDSA                 |
| CSPRNG                   | Fortuna with AES-CTR,SHA256 | Fortuna with SHAKE128 |
| Asymmetric encryption    | IES with RSA,ChaCha20/12    | IES with ECDH,Keyak   |

It's exaggerated to get the point across.

A has asymptotic security from factoring (RSA) and discrete logarithm (DHE, DSA), and concrete security from AES, GMAC, SHA256, and ChaCha20/12.

B has asymptotic security from elliptic curve discrete logarithm (ECDH(E), ECDSA) and concrete security from Keccak (Keyak, SHA3-256, SHAKE128).

This doesn't account for changes over time. Perhaps in the beginning the algorithms would be chosen this way, then as new attacks came along and new algorithms were created, each application would end up with its own algorithm, whatever was best for it specifically, without considering such insignificant factors like diversity.

We do have many algorithms to choose from now, with multiple algorithms for different purposes built on the same cryptographic primitive, so at least for the first set of algorithms this might be relevant.

Hardness problems
All of these algorithms, whether simple or complex, rely on well-known and often simple "hard problems". RSA for example is actually quite complex, involving numerous extensions that are necessary to make it secure, but it is still based on the simple fact that it is easier to multiply two primes than it is to factor a semiprime. Algorithms like DSA (which exploits the discrete log problem) are similar enough that an advance in integer factorization could be used to break DSA as well. AES and countless other symmetric ciphers use the substitution-permutation network. Some ciphers like Twofish use a fiestel network. Others, like ChaCha20, use add-rotate-xor (ARX). All of these designs are well-established, and a breakthrough in solving a major problem will defeat many ciphers, regardless of how simple or complex they are.
How much does complexity matter?
This means that, in the end, the complexity of a given implementation does not necessarily say much about its security. ChaCha20 for example is an extremely simple cipher, so simple and efficient that you can bet that anything faster than it will likely be less secure, yet it is built upon well-known principals (ARX). Serpent is a very complex cipher, with multiple "features" built in to prevent possible future attacks, but it, like AES, uses a substitution-permutation network. It is also extremely secure.
Cryptography and attack surface
Cryptography is not like application security where more complex inherently means more attack surface and greater bugs. Software is traditionally built on the assumption that any bug can break the expectations of the software completely. Ciphers and other cryptographic primitives, on the other hand, are often designed with the assumption that guarantees of the time may not hold up in the future as new classes of attacks are discovered. Serpent was created with this in mind, adding not only extra features, but also increasing the number of rounds.
The world of software security and the world of cryptographic security are vastly different, and established laws in one do not necessarily apply to the other. This includes such important mottos as "complexity is the enemy of security". The only similarity between software security and cryptographic security is that crypto is typically implemented in software. Implementations may be more insecure as they get more complex (compare libnss to libsodium), but the algorithms behind them do not follow the same rules.
In addition, some examples which you claimed as being more complex and thus potentially less secure are actually the most secure. It is based on formally proven mathematical models, not just assumed hardness problems. Regardless of development of new attacks, it is thus always possible for GCM to promise an acceptable minimum level of integrity for a given secure cipher. It being complex says nothing about something as irrelevant as the security of universal hashes over binary Galois fields (which GHASH, used by GCM, is based on).
Use only what you need
If you're trying to decide how many primitives a cryptosystem needs, you're already doing it wrong. In cryptography, you should only use what you absolutely need. Not because extra complexity makes you more vulnerable, but because a system that is designed well does not need more than the situation calls for. This is why cryptographers design ciphers with typically only 128 to 256 bits, rather than something crazy like a megabit. Is a keyspace of 2^10^6 bigger than 2^256? Absolutely, but anyone proposing seriously using or designing a megabit cipher would be laughed at. The same applies to primitives used in cryptosystems. Use what you need, since using extra only demonstrates a lack of understanding of the fundamentals of cryptography.
For example, if you have a need to authenticate data, you need to use authenticated crypto, like ChaCha20-poly1305 or AES-GCM, or an HMAC. If you have no need for authentication (say, because you only care about confidentiality of data-at-rest and nothing more), then don't use authentication. If you don't need it, GCM or poly1305 will only make your implementation more bloated and slower. If you do need it, then absolutely do not forgo it for simplicity. Hell, if you only need to encrypt a single block, and with a unique key, using ECB as the mode of operation is totally fine!
But what do you need? (Obligatory warning)
If you're asking yourself this for a serious project, as opposed to just for education or fun, stop. Use a popular crypto library. The choice of primitives depends on many factors. While the hardness that is the core of each primitive is undisputed, the precise implementation details lead to a lot of gotchas. DSA for example is quite secure, relying on the hardness of the discrete log problem, but it requires a random value, k, for each signature, and if k is in any way predictable or repeated, the algorithm fails catastrophically, revealing your private key. EdDSA on the other hand is based on the same principal, but it is entirely deterministic and requires no randomness to perform signing operations.
If you don't know what you need, here are a few "hard to go wrong" options. If you want to use current and secure algorithms. These are all very fast, and quite secure:

ChaCha20 for encryption. It is uses add-rotate-xor internally and is very fast in software.

Poly1305 for authentication. It has a proven security model and can be plugged in to any symmetric cipher.

x25519 for key exchange. It uses ECDH over curve25519, and uses nothing-up-my-sleeve values (modulo p = 2^255-19).

Ed25519 for signatures. It boasts quite a few security benefits such as side-channel resistance. It uses EdDSA with curve25519.

BLAKE2 for hashing. It's not particularly special, but it's secure and is based on well-regarded security features of the SHA2 family.

ChaCha20-based CSPRNG for randomness. As long as you have a strong seed, any plaintext you throw at it will give you cryptographically secure randomness.

If, on the other hand, you need to use NIST crypto (for example due to regulations, because your marketing department really wants to use the term "military grade", or just because you don't like DJB):

AES for encryption. It has been around for a long time and shows no signs of going away. Fast hardware implementations are common.

GCM for authentication. Like poly1305, it has a proven security model, though it's a bit tricky to implement safely (another reason why you should use a crypto library).

NIST P-256 for key exchange. While it uses sketchy values internally, it's just about the only strong, standardized key exchange technique.

RSA for signatures. It is old and well established.

SHA2 for hashing. Use whatever member of the SHA2 family that provides the necessary digest size or collision resistance that you need.

SP 800-90a revision 1 for randomness. It includes a set of DRBGs (Deterministic Random Bit Generators), of which Hash_DRBG and HMAC_DRBG are considered the least controversial. Revision 1 simply removes the NSA backdoored Dual_EC_DRBG from the list.

If you simply need to use a library, go with libsodium. It is popular and uses plenty of DJB crypto, and is designed to be easy to use. Crytography is hard, and is really the only field where appeal to authority is a virtue, not a vice.


Should password reset tokens be hashed when stored in a database? Passwords are hashed so that if someone gains access to a database of passwords then they won't know what the actual passwords are and so they can't log in.

If I can get a valid password reset token however (the kind which would be emailed to a user when they've forgotten their password) then isn't this as good as a password?

I could take a token, plug it into the reset page and set the password to whatever I want and now I have access.

Thus shouldn't password reset tokens also be hashed in the database?

Yes, you should hash password reset tokens, exactly for the reasons you mentioned.

But no, it's not quite as bad as unhashed passwords, because

reset tokens expire and not every user has an active one
users notice when their passwords are changed, but not when their passwords are cracked, and can thus take steps to limit the damage (change password and other sensitive data, etc).

Additionally, as users reuse passwords, an attacker can try a cracked passwords for other accounts, such as the users email, thus increasing the damage.


Using Different Algorithms in Single PKI Assume the following Public Key Infrastructure:

|Root CA (RSA)
|-Sub CA (RSA)
|-Sub CA (ECC)

Is there any rational that explains why this would not be an acceptable implementation?

Is the prefered implementation a PKI for RSA and a seperate PKI for ECC?

As per X.509, no problem. You can mix algorithms at will. Each signature is independent.

(X.509 includes a special provision for when a CA uses DSS and issues a certificate that also uses DSS with the same group parameters, in which case the issued certificate may omit the group parameters. This is called "parameter inheritance". This is never used in practice, and was not ported to ECDSA, even though it was a possibility and was apparently envisioned at some point. This is the only case, to my knowledge, where the signature algorithms at various levels in the chain have any relationship together.)

However, you must understand that by using several distinct algorithms, you force "relying parties" (systems that must validate these chains) to implement all of them. While this is normally not a problem for desktop systems and servers and smartphones, this could be an issue for small, embedded devices that want to save on code size, and would prefer not to include code for RSA and for ECDSA.

This kind of problematic is incarnated e.g. in SSL, where client and server tell each other what kind of algorithm they support for validating signatures on certificates (see for instance the Certificate Request message). This is meant to better support small devices with little code space. Making a mixture of RSA and ECDSA in your certificate chains puts you a bit at odds with that principle. Depending on your context, this may or may not matter (it will probably not matter).

In any case, that kind of mixed chain is expected for a transition. Suppose that you start with a full-RSA world; the root CA has been distributed to all client systems (possibly at a heavy cost). Now, you take the decision to switch to ECDSA, because client software is up to it (e.g. it came with normal OS / browser updates), but creating a new ECDSA root and pushing it onto all clients will take a lot of time. So, to begin using ECDSA without breaking things for the installed base, you make cross-certificates:

oldRoot uses a RSA key.
newRoot uses an ECDSA key.
To allow people to validate certificates issued by newRoot even if they do not know newRoot as a trusted root, a cross-certificate is issued, containing the name and public key of newRoot, but signed by oldRoot.

This cross-certificate allows systems that know newRoot as a trusted root to validate a certificate with a path "newRoot->cert", and systems that only know oldRoot will use "oldRoot->newRoot->cert" (in the latter case, going through the cross-certificate). In other words, newRoot has two certificates, one self-signed (with ECDSA), the other signed by oldRoot (making newRoot an intermediate CA).

This is a fairly standard method to handle renewals with key changes, but it necessarily implies, in the case of a RSA-to-ECDSA transition, mixed-algorithm chains. Thus, the situation that you describe is not only supported but expected.

To sum up: using completely separate PKI allows for single-algorithm PKI, which may help embedded devices (only one algorithm to implement). However, mixed-algorithm PKI are a normal thing, well supported, and expected in case of PKI-wide transitions to new algorithms.


Executing perl scripts without actual file on a cpanel account Processes with arrows are from same cpanel account let say "charlie"

This account was under control of client.

Last week this server got blacklisted on emails because client run some perl script to send spam emails. (First two processes)

First two processes had same PID all the time so we killed the processes and spam emails stopped and never started again.

But last process with arrow PID changes all the time.

There is no such file on the server named "gbfcii.pl", there is no perl scripts in clients folders.

I have no idea how did they managed to do this?

gbfcii.pl It is not a file name. It is a portion of the command. You may not find the file in filesystem. After you kill the perl shell this PID's parent changed to root process.


Is XSS prevention only on the frontend enough for JSON services? We have an application with a form where user can enter a comment. The form is submitted using AJAX. Values are read also through AJAX and returned by the backend as JSON, and then parsed by JavaScript to present it on the page.

This form was vulnerable of XSS attack so we protected the application on the frontend only, we escape HTML and JavaScript characters when we parse JSON response.

We think that there is no need to do similar thing on the backend, i.e., to escape risky characters before storing them in the DB, because the JSON response will always be parsed by the frontend before rendering.

Is it correct approach or there is some threat or attack still possible?

Yes, there's a possible attack: You someday change the frontend, and stop using JSON and start using something else. The XSS stored on the database kicks in and your users are attacked.

It is a very good practice to sanitize the user input as soon as possible. I always sanitize them as soon as it reaches my code.


Is there a way to guess a shared server's control panel's version? I am performing research on the security of control panel software for shared hosting providers, and I am interested to know if there is a way to identify the version of the control panel software that the server is using, for instance, cPanel, Plesk, or DirectAdmin, by having server IP and a website that is hosted on that server?

Kinda.
There is no format of displaying version number that all control panels use and so each control panel displays the version their own unique way.

If you want to find the version for a specific control panel I suggest you do the following:

Try looking the source code, the corners of the UI, headers in the requests or even google "How to find out what version X is running?" and see if there is anything relevant there.
Look for unique actions of the control panel and compare it to the versions update log (Assuming there is one on the control panel website) to find similar actions.
Set up a script that is able to identify a version of a control panel based on unique identifiers per each version and run it to check a specific site.


Which cookies can xss have access to I clicked on a link in my android phone and I don’t know if it was an xss or not. I want to know that in the case of an xss attack, can the hacker access my whole cookies or just the cookies that belong to the website in the link address?

A XSS has only read-access to the cookies on the specific page and only to cookies which are not set httponly. Thus only these cookies can be stolen.
But a XSS can do more than just steal cookies: it can use the page as a base to send requests to other sites. In this case the browser might automatically send the cookies from the target site to the target site. This allows the XSS to impersonate the user against the target site. Details depend on attributes of the cookie (like samesite) and kind if request (simple vs. non-simple XHR).


Uploading JSP (Any kind of java code) to Tomcat without manager I'm new to this site. I have a question concerning the upload of dynamic java code into an application running on Tomcat 7.0.34.

I'm doing a penetration testing of a java website and found it's possible to upload arbitrary files with a certain upload functionality. I managed to upload an HTML file for example, which then I can access and is rendered adequately. I tried to upload a jsp file, which was possible, but won't be rendered as HTML and the java code in it isn't executed (I get the  tags returned in clear text when I request the file). There are certain limitations to the upload as well:

1) I can't choose where to upload the file

2) Files aren't referenced directly. Instead, when the path to the uploaded file is shown, a random URL is created (every time its shown, a different URL is created), like:

http://site.com/static/path/random/path/myfile.jsp

3) I don't know the real path where the files are being uploaded or if I can access it directly

Under this circumstances do you think it's somehow possible to inject and execute java code server-side? (I know it would be possible with PHP, but with java and Tomcat I don't know)

Note: I don't have access to the tomcat manager or anything like that.

As for the point (2) and for the jsp not rendered correctly, It is likely the uploaded files are stored in a database not in the fs.
Otherwise a one reason that jsp are not rendered is because tomacat is having problem locating the tag library.


Hashes of overlapping data - does it make them easier to crack even when neither is cracked Say I have strings: stringA, StringB, stringC.

And I make two hashes:
HashA = sha256(stringA + stringB)
HashB = sha256(stringB + stringC)

For the sake of the argument I'm suggesting sha256 but answering the question generically is just as good.

I'm not a strong mathematician, but suppose I were, and am trying to reverse the above hashes, and knew from an algorithm in code that there is a stringB (still unknown to me) that is the later part of the string going into HashA and the earlier part of HashB.

Can I reduce the number of permutations required, in order to figure out what stringB might have been, since in order for the two hashes to give the answers they do, from overlapping input, should it not reduce the input-space I need to bruteforce?

i.e. are the hashes weaker because of this behaviour of having the data within them overlap.

For clarity:
If stringA, stringB, stringC, and stringD are secrets.

And an attacker gets all the code / algorthm etc except for the strings, and has:

case A:
hashA=sha256(stringA+stringB) and hashB=(stringB+stringC)

or
case B: hashC=sha256(stringA+stringB) and hashD=(stringC+stringD)

I have a suspicion that in case A it's easier to construct source data to match the hashes than in caseB, but I don't know enough maths to back up my suspicion.

Further clarity: Assume the strings are salted, though with the same salt per record and hashes for that record, and that the attacker knows the salts.  The salts can be assumed prepended before the 'stringx+stringY' throughtout my text if you like.

Thanks.

I will try to put it in simple words.

Ok, first is first, hashing is a one way only algorithm. You can only go from the source to the hash and never from the hash to the source. I mean, the hash string does not have all the original information so we can't extract it. The only way to guess if an information coincide with a hash is hashing the information and comparing it against the original hash. And even in this way we will never be sure since two hash strings may collide.

[Edit after your clarification]
The CaseB is clearly more secure:

Consider than in CaseA you will only need to brute force the full space once, the second time you will need to brute force only half of the space (just the StringC part).
In CaseB you will need to brute force two times.

The full space in CaseB is N^(length(a)+length(b))+N^(length(c)+length(d), the full space in case A is N^(length(a)+length(b)+N^(length(c)) where N is the number of valid chars.

But there will be no shortcuts to find "StringB" in the case A just because it is used when computing all the hashes. You will have to bruteforce it along the StringA or along with StringB (and then you will need to know the exact length of each string and so on...)

Just as a side note... I am thinking that you may be referring to a problem with ECB block cipher mode encryption, that will be a different problem and you will have a very different response. Consider having a look to this wikipedia page.


Root SSL certificates and browser support I have given three certs to be install on nginx

AddTrustExternalCARoot.crt
PositiveSSLCA2.crt
www_example_com.crt

So I concat them into a chained cert

cat  www_example_com.crt PositiveSSLCA2.crt AddTrustExternalCARoot.crt > example.com.cert

My questions:

Is appending the AddTrustExternalCARoot.crt really needed for modern browsers?
If I skip the AddTrustExternalCARoot.crt, will there be a chance that some browsers will show a warning? Any place I see check the root certificate browser compatibility matrix?
Why SSL company still sending AddTrustExternalCARoot.crt if it is not needed.

Nominally, in pure "X.509" philosophy, the SSL client should obtain the server's certificate and all needed intermediate CA certificates in any way it sees fit, but in particular by talking to the Directory, which is the giant worldwide LDAP server which contains everything.

Unfortunately, the Directory never existed (too centralized, too complex) so practical protocols have to include some provision for sending certificates themselves. It so happens in SSL/TLS: the server sends its own certificate and a bunch of other certificates which "may help" the client. In fact, the TLS standard even specifies that the server MUST send a ready-to-validate chain:

certificate_list
  This is a sequence (chain) of certificates.  The sender's
  certificate MUST come first in the list.  Each following
  certificate MUST directly certify the one preceding it.  Because
  certificate validation requires that root keys be distributed
  independently, the self-signed certificate that specifies the root
  certificate authority MAY be omitted from the chain, under the
  assumption that the remote end must already possess it in order to
  validate it in any case.

In particular, notice that the self-signed root itself may or may not be included. This root is never needed client side (and never has been) but sending it is "traditional" (one of the myriads of traditions in IT; not useful, but mostly harmless).

The client should be able to validate the certificate chain "as is" and is allowed (as in "morally justified"), per the TLS standard, to reject the handshake if the exact chain sent by the server cannot be validated. However, the client is also allowed (and encouraged) to try to rebuild some other chain and validate that, if what the server sent was not directly usable. Modern browsers do that; they will try to use locally known intermediate CA certificates (obtained at installation, or cached), and may also download extra CA certificates, following URL found in the certificates themselves (Authority Information Access extension). At least IE on (recent) Windows will do that, but, to avoid a nasty chicken-and-egg situation, it will follow only http:// URL, not https://. These extra downloads can take some time and make the handshake less robust, in case of flaky network or timeout.

Summary: sending the root is not mandatory, but traditional (the +1 kB network overhead per full handshake is unlikely to have any significant or even detectable impact on performance). Sending the intermediate CA is nominally required, and, in practice, recommended, although modern browsers/OS may recover by using alternate certificate chain building strategies.


provable security and sandboxes Maybe this can be answered by an answer to a more general question, such as what programs can be proven secure.

Can it be (or has it been) formally proven that a sandbox is secure?

The term "sandbox" is wide, generic, and often misused and misunderstood.

Let's consider a type of sandbox, a virtual machine running under control of an hypervisor. The guest system is nominally isolated and cannot "see" the host system. However, this is relative to the implementation of the hypervisor, which is a combination of software and hardware, both of which being susceptible to bugs (hardware is always involved in that the whole thing, ultimately, runs on a CPU; I am not speaking about using or not using the AMD-V/Intel-VT opcodes). Escapes from hypervisors have happened. "Proving" the hypervisor to be correct would mean proving that it is bug-free. Proving that software is free of bugs has been a rather elusive goal for the last half century... and for hardware, even more so.

Moreover, sandboxes do not equate to safety. For a sandbox to be useful, it must have a few open doors: you run some software in the sandbox, but you will want to see the result, be it something displayed, files saved somewhere, or some network activity. When people use a Web browser in a sandbox, they want the browser to, say, actually browse the Web, so external network connections from the sandbox must be allowed; and the sandboxed browser must also have the possibility to display things, so it has an access to the graphic hardware (possibly a controlled access, but if you want 3D acceleration, strict controls become difficult). You want a sandbox because you suspect that the browser could be subverted and hijacked by an attacker. But, at that point, you have already lost (not the whole war, but significant battles nonetheless): the subverted browser, sandbox or not, is network-able and can be used as relay to attack other sites or send spam, seemingly originating from your address.

In more succint words, amputation is not the ultimately advisable type of medicine.

Let's see another kind of sandbox, the Java Virtual Machine and its support for applets. It has two main facets:

The "code" is not raw binary code for the local CPU, but "bytecode": opcodes for a conceptual, abstract machine, which lives in a non-hardware world where generic pointer arithmetics are not allowed. References have unescapable types, and array accesses are bounds-checked.
The external access facilities for the applet code are restricted: network connections can be made only to the originating server; local files cannot be read or written to; and so on.

When the bytecode must be run, it is first analyzed: the JVM implementation does a control flow analysis which formally proves (yes, in the sense of "provable security") that the code complies to the type rules for bytecode (namely, that it never calls a method on an object which does not feature that method). This allows for translation to efficient native code, without needing specialized virtualization hardware. Moreover, it protects against many types of subversion (buffer overflows are reliably detected, there is no dangling pointer or double-free because of GC-based memory management...). This kind of protection is not sufficient for "security" because you still want the access controls (e.g. blocking external connections except to the originating server) which are enforced by the system classes. The bytecode analysis is there to ensure that only the system classes are used, and are used correctly; the rest is up to the system classes.

Of course, over the history of Java, both the bytecode analyzer and system classes implementations have been found to have flaws. They are not intrinsic: what they try to achieve is not mathematically impossible. But, let's face it: bugs happen. The JVM is a rather complex piece of software which is far from being proven to be bug free. Also, the JVM runs within an operating system and on some tangible hardware, neither of which being bug-free either.

This illustrates my points:

A sandbox provides "provable security" only insofar as its implementation has no bugs. That's somewhat utopic.
What the sandbox actually provides is enforcement of a set of rules which may or, more often, may not, embody what you really mean by "security". As usual, the first step of proper security is to define clearly what you want.


SQL Injection via Unicode My team currently uses ASP.NET with MS SQL Server for our software.
Security has only become important since I started, in which there is injection vulnerabilities everywhere.

Due to current integration with Oracle and MS SQL the business decision was never to use parameterized queries.
This of course has been an issue.

Implementing Find and replace along with whitelisting of parameters has reduced this issue strongly.

My only issue is, I have read a lot about unicode and other encodings being the cause of sql injection. I dont quite understand this.
Currently we sanitise everything like this:

        Const pattern As String = "^[a-zA-Z0-9.=,:\s\\\/\']*$"
        term = term.Replace("'", "''")

        If Not Tools.ValidString(term, pattern) Then
            term = String.Empty
        End If

    Public Shared Function ValidString(ByVal source As String, ByVal pattern As String) As Boolean
        If source = String.Empty Then Return True

        Dim params As Text.RegularExpressions.RegexOptions = Text.RegularExpressions.RegexOptions.None
        Dim regex As New Text.RegularExpressions.Regex(pattern, params)
        Dim match As Text.RegularExpressions.Match = regex.Match(source, pattern, params)
        Return match.Success
    End Function

Does anyone have an example where unicode/encoded injection could be used, or just a plain example where this regular expression would fail to prevent sql injection.

Thanks

UPDATE

Can I please not have answers related to standard SQL Injection. I am strongly familiar with this already.
ALSO please stop posting saying don't use string sanitisation. There is zero resources in the company to shift all queries to parameterised queries with ADO.NET while also building in logic for it to use ODP.NET if the client uses oracle. OWASP mention the use of whitelisting of characters if parameterising is out of question, so like in the regex, only few characters are allowed. I am not blacklisting characters, as this is stupid.

There is no compliance required for the data we hold. The security is for database integrity, as it would be a nightmare if content was changed.

Our software is a very large cloud application CMS and DMS in one, where 99% of the software is used internal, and only a minority is external and is only used for public review and commenting on the documents.

From my new understanding of Unicode injection. It can only occur if the data is being encoded before being placed into the query, and therefore unicode injection only really occurs in applications with globalisation of data. I am passing raw string fields straight into the string query after the sanitisation above.

Can I please only have an answer from an expert in injection, who can back up my claim that Unicode will not apply in my circumstance?

There are cases of SQL Injections leveraging the implicit conversion of Unicode homoglyphs from Unicode character string types (NCHAR, NVARCHAR) to character string types (CHAR, VARCHAR). A character such as ʼ (U+02BC) in NVARCHAR may slip through the escaping routine and get translated to ' (U+0027) in VARCHAR, which may result in an SQL Injection when such a string is used to build an SQL statement dynamically.

However, your validation is pretty strict (only characters from the Basic Latin Unicode block and Unicode whitespace characters) and I can’t think of any case where this would fail.


Really secure webmail If I'm feeling paranoid about the CCDP (UK) - requiring ISPs to intercept communications across the internet - then what would be the most secure approach to a webmail system?

Obviously, there's some legal/political stuff (can I rely on the people running it, can I rely on the legal jurisdiction that it's located in, etc) but on a technical level, what would be a strong approach to running a webmail service that can't be cracked by an MITM attack run by my users' ISPs?

It strikes me that there are several things that will make a difference compared to a typical commercial service like Gmail:

HTTPS, using TLS v.1.2 with well-selected cyphersuite choices (I'm not sure which cyphersuites would be right).  Now that OpenSSL 1.0.1 is out, requiring TLS 1.2 is possible, though you'd lock out NSS-dependent browsers (Firefox and Chrome - which means Opera only on non-Windows OS; Safari/Win supports TLS 1.2 but not Safari/Mac).
No JavaScript (and therefore no AJAX), with possibly a tiny piece of JavaScript that prevents access to the site if JS is turned on at the client.
Deliver all content from a single domain name / IP address (no "static" domain, no ads, no Google Analytics, etc).

I'm not intending to actually implement such a service (I'm not in a suitable legal jurisdiction, for a start) but I'm sure there are other things that could be done.

Any suggestions, thoughts?

The primary things you can do are:

Use SSL sitewide.  Disable HTTP (non-SSL) access, or redirect users to the SSL version of the web site.
Use HSTS to declare to clients that they should only connect via SSL.
Make sure that all cookies have the secure flag set.  This will ensure that your user's browsers will only send those cookies back over SSL-protected connections and never disclose them over any non-SSL (HTTP) link.
Add your site to Chrome's hard-coded list of HSTS sites (the HSTS preloaded list).
Add your site's public key to Chrome's public-key pinning list, if they'll let you.
Check that your SSL server is properly configured, using standard SSL configuration checkers: e.g., SSL Labs.
Make sure that your certificate is valid.
Consider buying an Extended Validation (EV) certificate.  You could also mention somewhere in the support section of your site that you encourage users to check for the green glow in their address bar every time they visit your site.  (Probably this won't be highly effective, but it might help a little bit.)
Consider providing a link to Chrome and HTTPS Everywhere on your web site somewhere.
Configure your web server to defend against the BEAST attack.  Enabling TLS 1.2 is a good idea, but you may also want to choose carefully the preference order of algorithms, to help protect users whose browsers don't yet support TLS 1.2 (which will be essentially all of them right now).
If you provide access via IMAP, make sure you only support IMAPS (the SSL-enabled version), not the cleartext IMAP.
Enable STARTTLS on your SMTP server.
Avoid use of third-party Javascript widgets (e.g., libraries, widgets, like buttons, etc.).  Don't load external content over http.

I would not try to avoid use of Javascript.  I especially would not try to block access to users who have Javascript enabled.  That is a usability disaster, for little or no security gain.

See also Guidance for implementors of HTTPS-only sites (Server side).


Is SQL auth over windows auth a red flag? I'm working on something where using windows authentication to SQL server is difficult if not impossible. My team member is adamant that using SQL auth is much more difficult to manage and is a major red flag from a security and compliance perspective. I can definitely see how it could be more complicated than just using the domain credentials.

I don't have a lot of experience in the world of security and compliance. I'm wondering if this is universally accepted as a non-starter or if this is maybe just his preference?

Thanks!

In my experience, deferring to windows controller authentication is advantageous for a few reasons:

It simplifies removing access  - how many times has someone logged into a sparsely used vendor platform and discovered that someone terminated years ago still had access? Anecdotally, I've had instances where I didn't even recognize the name of the user, as they had been terminated years before I had even been hired.
You can build your security/access around AD group membership. Similarly to the above, this simplifies updated/maintenance and decreases the chance someone else has access to something they shouldn't.
It lowers your overhead. Adding new users is not fun, and takes time away from other stuff you could be doing. Let the person in charge of onboarding worry about that, and then automatically piggyback off their work.


Is the Java programming language used for penetration testing in practice ? If so, does the same apply to C#? Is the Java programming language used for penetration testing in practice?

I've wondered whether Java is used or can be used for penetration testing in the field (people write pen-testing suites and attacks in Java)?

If so, does the same apply to C#?

I know Python and Ruby are used a lot, but I would like to aim for specializing in Java, since it applies to many domains.

Could someone with experience in the field answer my question?

You can write penetration testing tools in Java or C#.

Armitage is evidence of this. And you can search for vulnerabilities in Java code but not vulnerabilities like buffer overflows or format strings. I don't know the name of these vulnerability types but let's say that if a condition is wrong and with given input it grants you some privileges. Also Java is good because Android has a massive entry in today's technology.


Can viruses access passwords that have been saved by a browser? Say I use Chrome on a new computer to log in to a website, and I select the option to have the browser remember the password. Then I download a straight-up smorgasbord of viruses of every kind. Can the viruses access the passwords that have been saved by my browser?

You should assume so no matter what*

When your system gets compromised you must assume that it has compromised any accounts stored on the system. You should go about changing the passwords for any accounts used on that computer in any place. You have no control over the virus, and you have no control how programs store your data so you don't know if your accounts are safe. As the general rule always assume a compromised computer means compromised accounts.

Password storage in browsers

For most browsers those passwords are stored encrypted, but since the computer is on and the infection has access to memory space it can find the key and decrypt them itself. These infections usually target the browsers specifically, but can also have a wider scope of impact.

The real attack the encrypted passwords protects against is the theft of the hard drive. However if the cipher text is in the memory then it can be found and taken.

Regarding Master Passwords and Password Managers

While convenient, these offer little protection from an infection due to the fact that the cipher text is still loaded into the memory space. These provide protection from sit down attacks, stolen hard drives, and user ineptitude.
They do not protect against an infection that has access to memory space

*:  unless you know absolutely how and what and where the infections do their work.


Scanning private IPs from outside network Is it possible with Nmap (or other tool) to scan a range of private IPs (let's say 10.0.0.0/8) but being outside any private network (using those IPs) ?

Not using a VPN or some other way to be connected as if you were local the answer is no but not because of a limitation in Nmap or any similar tool. The primary reason this won't work is because the IP range you are talking about, 10.0.0.0/8,  is considered a private internet address range per RFC1918 which is not supposed to be routed over the public Internet. In almost all cases this means it will likely be Null-Routed by all the Internet Service Providers routing traffic between your location and the potential target IP's and you will get "no route to host" warnings at best.

https://tools.ietf.org/html/rfc1918

That said there are many situations where networks are misconfigured and some connectivity leaks out a very short distance. I've seen this on small providers of metropolitan Ethernet networks and also with misconfigured MPLS networks but these were technically local connections to where I was and not something that could have been reached over the global Internet at large.


Rooted android cached password Assume you could exploit a vulnerability on an old Android 2.2, the questions are:

1- Is there anyway you could see stored passwords on that operating system, specially Facebook password.

2- Can you send a message on behalf of the Facebook user from that device from the command line ? Or in other word how you can send a message on behalf of the user.

I need this as part of my research for social network bots and I appreciate any help.

If you have a rooted device , and if any application stores password in clear text in their database , then yes , you can view them if you have root access. About sending messages as a different user ,it depends on how that particular app works . Lets consider that FB USES A DB for maintaining all the messages which needs to be sync'ed once the device is online. Since you have root access , you can make ur own entry in that particular table and messenger would happily sync it once the phone is online. All this is possible if the database of the application is not encrypted, if not , you will have to find out the encryption key and then replace the database after making the necessary modifications. To find the encryption key , you can reverse engineer the application or use run-time hooking methods , like the once offered by cydia substrate to do your bidding .


How trustworthy is SELinux? Given the ongoing leaks concerning mass surveillance and the fact that the NSA is the original developer of SELinux, I'm wondering whether that means that backdoors should be expected in there?

As every other obfuscated C contest, not at last the Underhanded C Contest, shows, well-written backdoors can elude the reviewer. And just because software is FLOSS doesn't imply people always make use of the opportunity to read the code (not to mention the vast majority that wouldn't be able to comprehend it).

In case of SELinux it's not so much about crypto as the recent NIST RNG debacle, but backdoors in there would certainly provide an inroad into seemingly secure hosts.

Need we be worried? And if not, why not?

Expecting backdoors is a bit strong...

There are several strong arguments against the plausibility of such backdoors:

Linux is used by a lot of people, including US corporations. A big part of the mandate of modern security agencies is to protect the interests of their country. In particular, the NSA shall, as much as possible, protect US corporations against spying from foreign competitors. Putting a backdoor in Linux implies the risk of allowing "bad people" (from the NSA point of view) to spy on US corporations through this backdoor.
Linux is open-source and the kernel is believed to be under rather thorough scrutiny from competent programmers. This is the "many eyes" theory. SELinux is right in the middle of all this inspection. Whether the "many eyes" theory actually holds is debatable (and debated). However, there are people who do PhD theses on SELinux, so it is not preposterous to assume that this particular piece of code was thoroughly investigated.
Any patch committed into the Linux kernel is followed through revision control. SELinux comes from the NSA and is tagged as such. If a backdoor was inserted and then subsequently discovered, it would be easy to track it back to the apparent author. A very basic protection measure is to not do such things in your own name ! If I were the NSA, I would first build up a virtual persona who is not associated with the NSA, so that even if he gets caught pushing backdoors, this will not incriminate my organization. Spy agencies know a lot about spy network segmentation. It would be singularly dumb of them to inject backdoors in their own name.

There is also a strong argument for the existence of such backdoors:

Spying on a lot of people and organizations is the core business of the NSA.

Honestly, until you find the corpse (i.e. the backdoor itself), your question is unanswerable. It is a matter of many parameters which can only be know through subjective estimates...

(Personally, I still find that backdoors in PRNG, especially hardware PRNG, are much more plausible than backdoors "hidden in plain sight".)


What statistics can be used to identify pseudorandom data? I'm working on some code that attempts to identify files whose contents appear to be "random". As such, I'm looking for statistical measures that can be used to identify such randomness.

I've implemented the following so far:

Shannon entropy of the sample (i.e. -∑ p(xi) log2 p(xi) over the sample X)
Bytewise sample variance (0.0 is a perfect score)
Bitwise mean (0.5 is a perfect score)
Bitwise mean distributed across bits 0 to 7 of each byte (looking for any significant variance)
Percentage of bytes within the range 0x20 ≤ b ≤ 0x7E (37.11% is a perfect score)
Bit-pair counts (i.e. checking for equal counts of 00, 01, 10, 11)
Repeated byte distances (i.e. looking for xx, x*x, x**x, x***x, ... patterns)

These seem to give a reasonable measure of uniform "randomness", in that 128 bytes generated by concatenating two SHA512 hashes can easily be distinguished from ASCII text or an executable file simply by looking at the statistics.

However, I'd like to know if there are any other strong indicators that I should look into that might indicate that the sample data was generated by a cryptographic PRNG.

Update: To be absolutely clear, I'm not trying to test the quality of a PRNG as a cryptographic randomness source. I'm trying to distinguish between non-random files (e.g. executables, JPEGs, archives, etc.) and random files (e.g. TrueCrypt keyfiles). My tests so far are either used as ways to identify obviously non-random data (e.g. ASCII text) and data that isn't uniformly distributed in some way. I'm looking for other ways to test this.

During the AES competition, the organizing body (the NIST) went to the trouble of running extensive statistical testings on the output of the 15 submitted block ciphers, with what was believed to be the gold standard of such tests, the Diehard tests. They found nothing, of course. Comments from cryptographers at that time were that these tests were a bit ridiculous in the context of cryptographic algorithms (unofficial comments, of course: it would be discourteous to embarrass the host of the event); it was good for Public Relations that someone runs them, but nothing worth noting was expected from it.

This illustrates the difference between statistical randomness, as is needed for instance to power big simulations of physical systems, and unpredictability, which is required for security. Consider for instance the following PRNG:

Set a counter to a 128-bit seed.
To produce the next 128 bits of the PRNG, increment the counter by 1, then encrypt that value with AES and an all-zero key, yielding the 128 bits.

This PRNG will successfully pass all the tests of the Diehard suite; it is statistically "perfect" as far as the tests are concerned (departure from pure alea might be detectable after generating about 271 bits, i.e. more than 200 millions of terabytes). However, for security, it is terrible, since it is trivial to predict future output once 128 bits of output have been observed (decrypt these 128 bits with AES and an all-zero key: this will give you the current counter value).

Summary: a cryptographically secure PRNG produces output which is indistinguishable from randomness; not only with statistical tests, but also by someone who knows exactly the specific PRNG algorithm which was potentially used. If you have a statistical tool which can show that a given sequence of bytes comes from a PRNG, then you have proven not only that the PRNG is not cryptographically secure, but also that it is awfully bad at it. Even Dave's hash is "random" from the point of view of Diehard tests.

In shorter words, your tool won't catch randomness which was generated with some expertise, but it won't catch most non-randomness from complete amateurs either. With such tools, you are not targeting "non-cryptographers who should know better than to use homemade schemes", but rather "chimpanzees who should not be allowed to touch a keyboard".

Note: good steganography tools encrypt data before stuffing it into the transport medium, precisely to avoid detection from statistical tool. Encryption also should yield bits indistinguishable from randomness.


Password reset giving clues of possible valid email addresses We have a system where if you forgot your password and want to reset it, to go to the forgot password page and enter your email address. A temporary link will be sent to your email to reset your password.

Now, when we subjected our app to penetration testing, an issue was found:

  Application is giving clues of possible valid email addresses when attempting to reset password. This functionality can be abused by simply guessing possible email address and being able to find valid ones through the error messages.

Well, there's only one field and of course its obvious that if a reset password attempt fails, it's due to an invalid email. Seems this penetration test is wrong. Are there any solutions to fix this issue besides adding an additional field (besides email) for password reset?

Don't indicate that the attempt "failed". A user (legitimate or otherwise), asks for a password reset link, and gives you an email address. All you should say here is along the lines of

  Your submissions has been received. If we have an account matching your email address, you will receive an email with a link to reset your password.

The user will still get the link (success), but attackers won't know whether a provided email address is associated with an account.


SSL AES128-GCM-SHA256 cipher vs RC4-MD5 I'm performing a bandwidth performance test with a 2048 certificates using AES128-GCM-SHA256 cipher vs RC4-MD5.

Should I expect the AES128 cipher would actually outperform the RC4-MD5 cipher?

From my initials tests, I notice RC4-MD5 handling more bandwidth. I know RC4 is generally faster and requires less cpu processing.

Yes, AES should outperform RC4, if used on a CPU that has AESNI instructions. GCM is also fast, if used on a CPU with CLMUL instructions. On my laptop with an i7-6700HQ, openssl speed -evp aes-128-gcm with openssl 1.1.0e shows 5GB/sec on a single core running at 3.4GHz. Yes, really. I expect three times that performance  if all 4 cores are used (when all four cores are used, it runs at 2.6GHz, so you get 75% of that performance per core, but x4 the cores). The profiler shows the time is spent in a function called _aesni_ctr32_ghash_6x.

RC4-MD5 are nowhere near that at 520MB/sec for rc4 and 670MB/sec for md5, which would be 0.29GB/sec combined.


SQL Injection with Filters I have a SQLite Query, which is something like:
SELECT id FROM demo WHERE name="insertname".
In this case, double-quotes are disabled, which means that insertname cannot contain double-quotes. Is there a way to somehow bypass the double-quote filter?

Some experimenting shows that double quotes signify 2 conditions comparing both against the value of the field named insertname and against the value insertname. So unlike the use of single quotes, manipulating the condition into WHERE name="name" will yield all rows, potentially allowing to bypass checks such as authentication.


KRACK - does the ability to replay broadcast and multicast frames affect all clients in a wireless network? I apologise if this is a silly question, I just want to make sure I understand the impact of CVE-2017-13078 and CVE-2017-13080 correctly. Is the following assumption true?

  If there is just one client on a Wi-Fi network that is vulnerable to
  above mentioned CVEs then the attacker may exploit that vulnerability
  and as a result any client on that network (and not just the
  vulnerable client) may be attacked with broadcast/multicast frames
  being replayed.

The KRACK white paper lists NTP UDP broadcasts as a possible example for an impact scenario.

Thank you for your answers!

Your assumption is false. KRACK is a vulnerability that allows an adversary to MitM and decrypt supposedly encrypted traffic. If one attack is successful this does not make it possible to attack non-vulnerable clients.


Is my PC safe? need help About 6 days ago my parents who aren't great with PCs got phished on gmail, and the account started spreading spam.

It had been hacked on an Argentinian IP, and then logged in from IMAP and SMTP from the UK. At the moment it was logged in from the UK, it sent spam out on the gmail contacts briefly.

We changed the password and added 2 step verification. The account has not had any attempted log ins since, and no suspicious activity.

However, since I probably have crazy anxiety problems, I am scared that malware or a virus could have gotten into the machine, however I see no signs.

• I checked msconfig for bad entries

• I scanned with MSE, Mbam, Mbam Anti rookit, Tdsskiller, Spybot, norton 360, kaspersky pure 3.0, norton pe, and it has all come clean, all on full scans.

• I dont see any suspicious activity network wise. (Kaspersky shows 34 ports listening for svchost, 11 for system, is that normal?)

• Nothing seems to be changed, and the pc runs fine.

One of my main reasons I'm worried, is that I believe my own pc was running and connected to the network when my parents got on the phishing link. And the next day it was running and connected, and my parents PC was on too.

I haven't turned my PC on since, and I have been stressing and scanning for Long time now on my parents PC.

I was even thinking about going around with my win7 install disk and formatting all the PCs..

Can anyone shed some light on this? What's the possibility my parents PC got infected? And could it have spread to other PCs?

If it helps, my situation is similar to this  Don't understand how my mum's Gmail account was hacked

If you want to be as sure as you can be, reinstalling the operation system from read only media is a good idea.


Wordlist generator for a specific pattern I know my Windows machine password is Passw0rd!. I want to generate it using crunch so that I'd know how it works.

I tried crunch 9 9 -t Passw@@@@

But here @ refers to lowercase character. I want it to be like Passw???? where ? can be any character. Is there a way to do it? I tried searching in many ways, I wasn't able to get it!

The -t of Crunch is limited to predefined static character sets:

  -t @,%^

  Specifies a pattern, eg: @@god@@@@ where the only the @'s, ,'s, %'s, and  ^'s  will
  change.

  @ will insert lower case characters
  , will insert upper case characters
  % will insert numbers
  ^ will insert symbols

You could create own combined character sets by using the -f, instead.

  -f /path/to/charset.lst charset-name

  Specifies a character set from the charset.lst

Now, that doesn't work like -t and -l, but you can use it to create the suffixes. E.g. in Kali:

crunch 4 4 -f /usr/share/rainbowcrack/charset.txt alpha-numeric-symbol32-space -o suffix.txt

After that, you can use sed to append the prefix part (Passw):

sed -e 's/^/Passw/' suffix.txt > wordlist.txt

While this could be combined to a one-liner, it might be easier to understand in these two parts.


Does endianness affect encryption keys and initialization vectors? When encrypting (specifically when using AES) content, will endianness affect how the key (and/or initialization vector) should look when encrypting/decrypting content? And could this depend on the crypto library in use (I'm using Botan)?

What I mean, if I receive a key (0123456789ABCDEF0123456789ABCDEF) from a big endian system and want to use this to decrypt data on a little endian client, would I need to alter the key in any way? The same question goes for IV though.

Thanks!

Endianess of the system does not affect these things.

You usually consider keys, blocks, etc. a stream of bytes where endianess does not matter. The same holds also for the IV.

Endianess comes into play only when using multi-byte values like words or longs.

If it helps you can think of it as all being normalized to big-endian :-)