Security Flaw,Bypassing Password.

Just read an article in this months Mac User where if you enter any charachters in emergency call,then immediately press the lock key,it opens up all your contacts,try it,worked on my unjail broken,SIM free iPhone.Bit of a flaw really.

It should be fixed next month.
<http://www.macrumors.com/2010/10/26/ios-4-1-bug-allows-access-to-iphone-contact s-and-voicemails-despite-passcode-protection/>

Similar Messages

IMessage password/Apple ID security flaw?

I'm still able to sign into iMessage on my ipad mini using an old password/Apple ID.... Why is this and how do I fix it

Sorry for the old bump.
But my issue similar and a security flaw. If I turn off imessages on my ipad, anyone can turn them on, enter the wrong password, and poof they work.
How is that that I can enter ANY password and imessages works?
Seems not secure at all. If I go on my colleagues iphone, enter my apple id (my email - duh) and the wrong password, it works there too.
How do I restrict this?

Screen Saver Password Protection - Security Flaw

Although I have always felt OS X has been a solid and secure operating system, there continues to remain one painful, and blatant security flaw. I keep thinking that Apple will address the issue, but they certainly haven't done so thus far.
Explanation:
With any good security policy, and in any secure environment, there will always be a need to "lock" (password protect) a system when not in use. That is, after 'X' period of time, the user interface is password protected so as not to allow access to the system while not in use. This is probably the most common and fundamental security measure in any environment. However, Apple's (GUI) password protection falls short in a number of ways. The only current method of password protecting the user interface is through the Screen Saver. Although at a glance it appears functional, it is a poor design and is easy to disable.
The screen saver configuration lies within two files; the ~/Library/Preferences/com.apple.dock.plist and ~/Library/Preferences/ByHost/com.apple.screensaver.<variable>.plist. It is especially important to note that both of these files are located in the users home folder, which gives them full access to the configuration files. There is absolutely nothing preventing a user from deleting these files, and thus, disabling the only mechanism to password protect the user interface. Giving the user the ability to disable or remove ANY security related configuration is a poor design.
Now initially we thought we had a solution by setting the user immutable flag on the ByHost screen saver plist using chflags. This would still allow user access, but would prohibit them from deleting the ByHost plist. Well, it sounded good in theory. However, if ~/Library/Preferences/com.apple.dock.plist is deleted, you can say goodbye to your password protected screen saver, despite locking the screen saver plist. So naturally the idea occurred to me to set the user immutable flag on ~/Library/Preferences/com.apple.dock.plist. This works, but makes it impossible to modify the Dock. Needless to say, if the Dock can't be modified, there's no point in even having it.
Now that isn't the only thing wrong with the screen saver password protection. You would expect that an administrator could unlock a users (password protected) screen saver, but you would also assume that the user was logged off as a result. Not in this case... If an admin unlocks a password protected screen saver for a user, they are now logged in as that user and have access to everything the user was doing when it was locked (email, spreadsheets, confidential information... anything). This is not the preferred method. If for some reason an admin needs to unlock a password protected screen saver, it should log off that user, not allow access to the user's session.
Finally, the biggest flaw yet. With a recent update, the password protection doesn't even work, as indicated by several people in the following threads.
http://discussions.apple.com/thread.jspa?messageID=2706417&#2706417
http://discussions.apple.com/thread.jspa?messageID=1950444&#1950444
http://discussions.apple.com/thread.jspa?messageID=2648700&#2648700
I have personally seen this issue while developing our corporate OS X image. Despite any fix or workaround, the simple fact that this has occurred is disturbing. ...As if the design wasn't bad enough, it now has the potential to stop working entirely.
Now don't get me wrong, I love OS X and prefer to work on it over any other operating system. Nonetheless, the current design for the "screen lock" is inadequate at best. For a large enterprise environment with stringent security requirements, it's far from sufficient. My hope in posting this is that someone from Apple acknowledges the design flaw and incorporates a more effective solution into the next OS.
MacBook Mac OS X (10.4.6)

One thing I forgot to mention is that "Workgroup Manager.app" is a part of the "Server Admin Tools" which can be downloaded free from Apple. Although it seems to be primarily intended to be used to configure OS X Server from an OS X Client machine, many of its functions can be used to configure the OS X Client machine itself, in the complete absence of OS X Server. Unfortunately, the 'mcx_settings' aren't really "image friendly" - as far as using them on OS X client is concerned, they are something that seem to need to be applied to user accounts individually (although it is possible to copy all of the settings at once so it isn't necessary to go through the whole configuration process for each setting for each user). I have tried tinkering and applying them to groups, but group members don't seem to automatically be restricted (I may be missing something). The "tools" are available here:
http://www.apple.com/support/downloads/serveradmintools104.html
I don't know if it would be any better than the screen saver "hot corner", but there is an option to lock the screen from the "Keychain Access" menu extra, which can normally be enabled through "/Applications" > "Utilities" > "Keychain Access.app", from its "Preferences". This setting is then stored in the "com.apple.systemuiserver.plist" file (ie independent of the "Dock"), but could in principle be controlled from 'mcx_settings' as well. The level of control seems to be incomplete - the user can still drag the item off of the menu bar, but it returns during the next login. However, it does provide convenient access to a method to lock the screen and keychains, and has a nice "padlock" icon so that its function is obvious. It is also potentially possible to assign a two-step keyboard shortcut to the "Lock Screen" item, but it would be somewhat less convenient than a direct key combo...
One other note regarding the "admin" user's ability to unlock the screensaver. The configuration file allowing the "admin" user to do this is "/etc/authorization", under 'system.login.screensaver'. Currently, the "rule" is set to 'authenticate-session-owner-or-admin'. Changing it to 'authenticate-session-owner' would be expected to remove the "admin" user's ability to unlock the screensaver, and if "Fast user switching" is available, the "admin", being unable to authenticate, should be able to switch to the "login window" from the authentication dialogue. I haven't tested this at all in "Tiger", but in "Panther", there was apparently a problem with it (which is why it had slipped my mind since at the time it was rejected as a viable option) - the person who posts here as "LittleSaint" had mentioned some problem with user logins when set up that way but I don't remember what it was, and so can't test if it has been fixed in "Tiger" (not very reassuring, and I apologize). And again, this is a setting that an "admin" would be able to reverse for themselves. Also, should "Fast user switching" become disabled for some reason, and the screen saver kicks in and the user isn't available, it might be a hassle to get back into the machine (it might be possible to do something over ssh). Nevertheless, it might be something to look in to.

Security flaw-To use CSOM/Javascript code for Custom Office365(Sharepoint Online) application

Hi,
I've developed custom application in Office365(Sharepoint Online) using CSOM/Javascript. Security team from client side has been reported one major issue to the our application that any end user can comment our CSOM/Javascript code and bypass the validation
or can update / insert into sharepoint list item using developer tool/ Console in Google Chrome(F12 Key).
Also end user can write his own separate code in console of Google Chrome (Developer Tool / F12) and can update / insert into Sharepoint List.
Note:- End user has Add, Edit, View permission on all Sharepoint List.
This is one major security flaw of the Sharepoint/Office365 to use CSOM /Javascript for writing code, to overcome this issue could you please provide me some solution.
Your help would be greatly appreciated!!!
Looking for reply.
Thanks,
Mahesh Sherkar
Web: http://Mahesh-Sherkar.com
Email: [email protected]

Hello Paras,
Did you get any solution for this? I think your website was implemented this form. Can you please tell me the way how I can achieve it? I am also facing same problem. Please reply me as early as possible.
Thanks,
Mihir

BusinessObjects security flaw left users vulnerable to attack

Audit found this web article "BusinessObjects security flaw left users vulnerable to attack" http://searchsap.techtarget.com/news/2240025968/BusinessObjects-security-flaw-left-users-vulnerable-to-attack?asrc=EM_NLN_13056439&track=NL-137&ad=804092
and they were wondering if our installation of BusinessObjects was also vulnerable. I was not able to answer for sure, so I asked our BASIS team. They said that it is not clear from the article what components are actually affected or in what patch level this is corrected.
Does anyone know specifically where the security flaw is?
Thanks,
~Matt Strehlow

Hi Denis
thanks for the reply.
Are you absolutely sure that the passage should not be in the file any more?
I've checked now 3 different installations and I've even checked the axis2.xml in the war files I found (dated 04/22/2010) and they all do contain these two lines:
<parameter name="userName">admin</parameter>
<parameter name="password">axis2</parameter>
The installation were BOXI 3.1 SP3, meaning we used the "merged" installation files that include the SP3. One of the installations I checked has even Fix Pack 3.4 installed.
The only axis2.xml file I found that did not contain this passage was from a BODI installation...
am I missing something here?
thanks for any help!
MU

Fatal Security Flaw in WRT54GS?

Sorry I don't have the hardware revision handy.
Firmware is 1.52.0. Model is WRT54GS.
I'm configured with WPA2-PSK/AES. Broadcasting my SSID. No MAC access filtering.
HTTPS access only to the config pages. Custom (not default) password. Remote management disabled.
Summary:
The router simply "forgot" its assigned SSID and reverted to broadcasting as "linksys".
It also ceased encrypting its broadcast.
I was able to log in and change it back. It retained many of the OTHER settings I had previously configured.
What causes this? Is it a known issue? Is there a fix?
Details:
Two days ago, I noticed my client (laptop) could no longer see the usual SSID that I connect to on my home network.
However, there was a new SSID in the area, named "linksys", broadcasting UNSECURED.
Coincidentally, this new "linksys" access point had the exact same signal strength that my usual access point typically had.
So, I connected to it, you know, just to see.
I was only able to access the config pages at my custom IP address (not at x.y.0.1), prefixed with the "https://" scheme identifier.
And it didn't prompt for a password. Hopefully because it recognized the cookie my browser still carried from the last time I logged in to it. But maybe because it had temporarily dropped ALL of its security measures...
It was definitely my router. Just, stripped of its usual encryption/authentication and its usual SSID.
So, I switched the SSID back to what it usually is.
And I turned the WPA2-PSK/AES encryption back on.
The router "remembered" my WPA2 passphrase, which it helpfully displayed to me as plaintext when I pulled down the "security mode" dropdown menu and selected "WPA2 Personal".
After re-configuring, it works as well as ever.
Is this a known security flaw in the WRT45GS? Because....it seems like a fatal one, as far as network security is concerned.
Is it limited to one firmware release? Is there a firmware upgrade to fix it?
(Again, I regret not having my hardware revision handy.)
Thanks.

Thanks for the reply.
Yeah, the initial configuration was done wired.
Subsequent reconfigurations were done wirelessly, on the encrypted wireless, connected via https.
Remote management was NEVER enabled (and remained disabled, even after the router's little spell of amnesia).
This particular router has been up and (mostly) stable for something like three years. For the past year, WPA2-PSK encryption ahs been enabled. The present WPA2-PSK passphrase is NOT the same as the old WEP key.
I'll assume (just for a moment) that nobody hacked the router. The only reason my router would be intresting for anyone to hack is simply because it's there. And there are half a dozen other WPA2-PSK networks and a handfull of WEP networks within shouting distance. And, if it was hacked from the outside, that would also indicate a "fatal security flaw" in the WRT54GS...
So, let's assume it just glitched out and forgot its own name for 12hrs.
Tell me more about what happens to NVRAM as it ages. Does it become less N(on) and more V(olatile) with time?
I know the router got hit by a storm-related power surge about 9 months ago. It was reset at that time, exhibited some strange behavior (not wanting to display the config web pages) and then it "settled down" after a day or two.
While it's performed fine since then, it may have sustained some subtle sort of damage at that time.
But no parameters were lost or altered in the NVRAM. And there was no obvious surge-type event to precipitate it now.
What's the life expectancy of these things anyway? Is this an early warning sign that I should upgrade to new hardware?

Security Flaw: Screen Saver Authentication

Hi,
I have found a security flaw, it exists in both Panther and Tiger. If a system has 2 accounts, the first account being active and locked through a screen saver. The second account (if administrator) can type their username/password in the authentication screen, and it will unlock the first account. This works if the first account is an administrator or not. Any administrator username/password will authenticate any other account from the screen saver authentication box. I have proven this on 2 machines, a D2.5 G5, and a 1.6 iMac G5.
Please contact me for further testing.

it's not a TECHNICAL flaw, it is however a logical flaw, yes.
Because admins are part of the sudoers files, one admin does have the permission to unlock another admin like that, the same as how when logged in with one account you can use another admin account to authorize the installation of software (why it's not necessary to be logged in with your admin account)
The behavior I suspect you desire is the behavior Windows uses, where when you use an admin account to unlock a computer, it logs out the user who locked it (assuming the admin isn't the one logged in).
I suggest you submit a feature request to Apple.

Security issue: Wakeup password glitch in Mavericks

Here is what I'm seeing:
My Macbook Air goes to sleep.
I press a key and see the password box.
Press ESC to cancel the login.
Press a key again.
The Mac wakes up without a password.
I don't know if this is just Mavericks, but I never saw this before I upgrade.

If I had it set for "Wait 5 minutes" it shouldn't prompt for a password the first time.
The original situation was that it would prompt me for a password (even though I was set to Wait 5 minutes). Then I would press ESC, wake-up again, and it wouldn't prompt for a password.
Less of a security flaw than a glitch, prompting for a password when it shouldn't.
Now that I have it set for immediate, it's supposed to prompt me for the password every time and it does.

IPhone location tracker - still a security flaw?

I hear a lot about a security flaw in the iPhone OS, allowing others to track the location of my phone without my consent and with no straightforward way to protect myself. On the internet, I see semi-legal app's offered, said to track any iPhone, "just enter the phone number".
First - is this still true? I have updated to the latest iOS5.
If not, what are the settings I need to be aware of?
If yes, has Apple announced a plan to plug that security flaw?
Short of jailbraking my phone and installing unauthorized software - what can I do about it?
/Lars

There is not, and never was, a security flaw in iOS that allows or allowed others tot track the location of the phone.
The "apps" you see are generally bogus. They are "joke" apps. They can NOT do what they appear to do. It's simply not possible.
... unless ...
If the phone is jailbroken, tracking apps can be installed. If your phone is not jailbroken, you have nothing to worry about. The only way anyone could track the location of your phone would by by accessing your iCloud account and using Find my iPhone. So long as you keep your password secure, this isn't an issue. Oh... and Find my Friends if you've agreed to share your location with someone.

Acrobat 9.2.0 Update Breaks Text Box Tool, Possibly Introduces a New Security Flaw.

Anyone have any ideas for this one?
Once we upgraded to version 9.2.0 (This is a major security release that fixes a Javascript security flaw) our text box tool no longer works the way we want it and crashes the program.
Try this:
1. Open any PDF document on a Windows XP SP3 computer with Adobe Acrobat 9.2.0.
2. Add the 'Text Box Tool' to the toolbar by right-clicking the toolbar and selecting 'MoreTools' then placing a checkbox next to the 'Text Box Tool'.
3. Click the 'Text Box Tool' on the toolbar and draw a new textbox anywhere on the PDF document.
4. Click out of the textbox to cancel typing mode, then single click back on the textbox that you just created.
5. Right-click the textbox that you created and select 'Properties..."
6. Under the 'Appearance' tab,
a. Select Style: No Border
b. Select Fill Color: No Color
c. Check the box 'Make Properties Default'
d. Click OK.
7. Click the Text Box Tool again, and draw another textbox (Since there is no border you will not see it but you will still be drawing a textbox).
8. Let go of the mouse when you are done drawing your textbox rectangle and the program will crash at this point.
Results:
1. "An internal error occurred." dialog box is displayed.
2. After clicking ok the following "Microsoft Visual C++ Runtime Library" dialog box is displayed:
"Runtime Error!
Program: C:\Program Files\Adobe\Acrobat 9.0\Acrobat\Acrobat.exe
R6025
- pure virtual function call
3. After clicking ok another dialog box is displayed:
Error signature
AppName: acrobat.exe AppVer: 9.2.0.124 ModName: acrobat.dll Offset: 000509dd
4. The same error has occurred on all five computers that we tested the new version on.
Expected results: A new textbox is created and you may start typing in text (This was the behavior in version 9.1.3).
Additional Information
At times, we need to add information to PDF files (i.e missing dates, etc). We have always used the Text Box Tool to do this with no border, and with no fill color as this is the EASIEST and FASTEST way to add information to PDF files in a precise manner. We want the fill color to be transparent so that we can fit text in between and exactly on lines easier, and so that there is not a solid background box behind the text. We want no border because a border around text that needs to go on a line looks stupid. Up until version 9.2 this procedure worked fine. Now, the program will crash. Perhaps this even adds another security vulnerability if the crash could be exploited. We want to maintain security by patching Adobe to address the JavaScript vulnerability that was addressed in version 9.2.0, however, we are not able to update our users as the new version breaks the fundamental purpose that we use Adobe Acrobat for. We are stuck with the vulnerable version 9.1.3 until this problem is addressed. Disabling JavaScript is not an option either, as we use a Java plug-in on a daily basis.
Any thoughts would be great, I have attached screenshots of the errors.

The question still is not answered.
The problem continues in Acrobat 8.1.7 for Windows, even after updating toAcrobat 8.2.0. ( I can't comment on whether recent updates to Acrobat 9 fix the problem in Acrobat 9.)
The internal error after text insertion problem occurs even with PDF documents created in Acrobat 8, i.e., not only old versions of PDF files. We have the text box insertion icon in the toolbar, and the properties set to "no color" for the box and "0" width for the text box lines, as other commentators have noted.
The problem did not exist when Acrobat 8 Pro was installed, it was introduced by one of the updaters.
The main reason we use Acrobat, rather than much cheaper PDF-creation software, is to annotate PDF files (including inputting data into spaces in standard forms).
So justify the high price of Acrobat and fix the problem please, Adobe !

Security Flaw: Since upgrading to iOS 8.3, I can by-pass passcode security by simply hitting RETURN on my bluetooth keyboard

I noticed when I typed my passcode incorrectly on my Logitech Fabric Skin Keyboard Folio, the iPad allowed me to log in. I checked again, but this time by just hitting RETURN key without entering any passcode, and again it allowed me to log in.
If I disconnect the keyboard, and use the soft keyboard on the iPad itself, it only allows the correct passcode.
Has anybody else seen this security flaw?
iPad Air
iOS 8.3

Please describe the problem in as much relevant detail as possible. The "etrecheck" fad hasn't made that step any less necessary. The better your description, the better the chance of a solution.
For example, if the computer is slow, which specific actions are slow? Is it slow all the time, or only sometimes? What other changes did you make, if any, just before it became slow? Have you seen any alerts or error messages? Have you done anything to try to fix it? Most importantly, do you have a current backup of all data? If the answer to the last question is "no," back up now. Ask if you need guidance. Do nothing else until you have a backup.

How secure is the password manager?

How secure is the password manager?
Can someone hack into it and steal my password?

You can protect stored password using master password. See:
* https://support.mozilla.com/en-US/kb/Protecting%20stored%20passwords%20using%20a%20master%20password

Compressing of data and securing it using passwords in xi

Hi,
How can we compress data in xi? How do you secure it using passwords?
thanks in advance,
Ramya Shenoy

Hi Ramya,
For compressing of data into Zip files we have a feature called AdapterModule configuration.Where in we have to configure PayLoadZipBean in the communication channel.But as far as secutiry is concerned SSL cerificates (encrytption decryption) can help you out .
Refer the following links on zipping files
http://help.sap.com/saphelp_nw04/helpdata/en/45/da9358a1772e97e10000000a155369/content.htm
/people/stefan.grube/blog/2007/02/20/working-with-the-payloadzipbean-module-of-the-xi-adapter-framework
Thanks,
Ram.

Serious security flaw found in IE

*Important Information*
A serious security flaw is found in Internet Explorer today and everybody is been advised by 'MICROSOFT' not to use Internet Explorer for any confidential banking transactions until the new patch is released.
The new patch would be released at the earliest and Microsoft advices everybody to use the browser from their rivals until the patch is released.
Click on the below link to read:
http://news.bbc.co.uk/2/hi/technology/7784908.stm

I advise everybody to use the browser from their rivals, even after the the patch is released!
I couldn´t agree more
Maybe the browser was patched now so the data is not stolen by "someone" but to Microsoft instead when surfing MSDN
</cynism>
Markus

Create Run As Accounts - Error 635 unable to securely store the password information

Hello,
I'm running on SCVMM 2012 R2.
When I try to create a new Run As Accounts the jobs fail with the error
Virtual Machine Manager is unable to securely store the password informaiton on this machine.
Ensure that the Microsoft Cryptographic Service has been installed on the VMM management server and try the operation again.
ID: 635.
I have make no modification and the server run since month without problem. I have more than 30 run as account existing.
Now I have installed all the latest patch but without any success.
All I can find is to uninstall VMM and install it back, but this is only a last resort solution for me.
Where can I find more logs information on this issue?
Regards
MCITP: Enterprise Messaging Administrator 2010 MCTS: Lync Server 2010, Configuring MCSE

I'm trying now to re-install the server but with no luck so far as the installer throw me an erro 1603 at the SSL cert creation step..
MCITP: Enterprise Messaging Administrator 2010 MCTS: Lync Server 2010, Configuring MCSE

Security Flaw,Bypassing Password.

Similar Messages

Maybe you are looking for